Crypto infrastructure is the collection of technical and financial systems that lets people create accounts, inspect balances, price assets, submit transactions, trade, safeguard keys, and settle obligations. A visible wallet or investment product may depend on dozens of services that its user never directly sees.
The useful question is not whether a product is onchain or offchain. It is which component performs each job, what trust that component introduces, and what happens when it becomes unavailable or reports the wrong result. Infrastructure analysis turns a polished interface into a map of operational dependencies.
What you will learn
- Identify the major layers between a user interface and blockchain settlement
- Explain how layer 1, layer 2, data availability, bridges, and oracles differ
- Trace failures across technical, financial, and organizational dependencies
The base network and its access layer
A layer 1 network defines the rules for valid transactions, orders them through consensus, and stores or commits to the resulting state. Nodes independently run the protocol software, verify blocks, and expose local data. Validators or miners have additional duties in proposing or producing blocks, but a node is not automatically a block producer.
Most applications do not maintain every node they need. They send JSON-RPC requests to an internal node cluster or an external provider. The RPC interface translates questions such as a balance lookup or transaction submission into methods a node understands. It offers access to the chain; it does not replace consensus or make a submitted transaction final.
Scaling, data, and cross-chain movement
A layer 2 executes transactions under its own ordering process and derives security or settlement properties from a layer 1. Rollups publish transaction data or commitments and proofs to a base chain according to their design. Data availability means participants can obtain the data needed to verify or reconstruct state; it is distinct from storing convenient historical queries.
Bridges carry messages or representations of assets between systems that do not share one state machine. A bridge may lock an asset on one chain and mint a representation elsewhere, or authorize liquidity providers to pay recipients. Its security depends on message verification, contracts, signers, and finality assumptions, not simply on both connected chains being secure.
Data, execution, and asset control
Indexers transform blocks, logs, traces, and contract calls into queryable records. Explorers present some of those records to humans. Market-data vendors normalize venue prices, while oracles deliver selected external or computed facts into smart contracts. An oracle is a publication mechanism with a methodology, update policy, and governance process, not an all-knowing source of truth.
Execution venues match orders or route transactions, custodians control signing systems, and settlement services coordinate final asset and cash movements. A company can outsource these functions while retaining responsibility for vendor selection and recovery planning. Legal ownership, possession of keys, account records, and onchain balances can belong to different parts of the arrangement.
How to evaluate the stack
Begin with a system-flow diagram. Mark where a user instruction originates, which service authenticates it, where prices and chain data enter, who can sign, which network orders the transaction, and when the business treats it as final. Record every manual approval and every external service on the path.
Then test control and substitution. Ask whether the operator can run its own node, switch RPCs, reconcile an indexer against chain data, replace an oracle, withdraw from a custodian, or settle through another venue. A dependency is more dangerous when failure is correlated, detection is slow, and replacement requires new contracts or client migration.
Common misconceptions
“Infrastructure is a background commodity, so the application is the only part that matters.”
Access, ordering, data, signing, and settlement services determine whether the application can operate and whether users see accurate results. Their controls and failure modes shape the product directly.
“If a transaction uses a blockchain, every dependency in the transaction path is decentralized.”
A transaction may pass through one interface, RPC provider, sequencer, oracle, bridge, custodian, or venue. The base network's architecture does not automatically distribute those surrounding services.
Risks and limitations
- Concentration risk arises when many applications rely on the same node provider, cloud region, oracle, custodian, or bridge.
- Integrity risk arises when stale, manipulated, or incorrectly normalized data drives displays, collateral decisions, or automated execution.
- Recovery risk arises when credentials, signing policies, vendor contracts, or state cannot be moved to a replacement service quickly.
- Composability risk arises when one failed contract or network dependency blocks several otherwise healthy products at once.
Key takeaways
- A crypto product is a chain of access, data, execution, control, and settlement dependencies.
- Nodes verify protocol rules; RPC services provide applications with an interface to nodes.
- Layer 2, data availability, and bridges solve different problems and introduce different assumptions.
- Indexers, explorers, market data, and oracles should be checked against their source and methodology.
- Resilience depends on detection, fallback, reconciliation, and the practical ability to switch providers.
Primary and further reading
Test your understanding
Score at least 2 out of 3 to complete this lesson. Explanations appear after you submit.