Cryptocurrency infrastructure is the collection of technical components and operating roles that lets a crypto network process activity and lets applications interact with it. Its main functions include defining protocol rules, coordinating network participants, and—in some architectures—separating network functions across layers. The precise arrangement varies by system, so a layer map should be treated as a way to trace responsibilities, not as a universal blueprint.

What cryptocurrency infrastructure includes

Infrastructure refers here to the systems and functions that support network operation and application access, rather than the application’s user-facing purpose. A useful conceptual map starts with protocol rules and participating nodes: together, they support agreement on network activity. Additional systems may provide application access or organize network data, while wallets and custody arrangements determine how transaction authorization is handled. These categories describe functions; one deployment may combine them, and another may distribute them among different systems.

The boundaries matter because a component’s name does not tell you what it actually does. A network node’s role is not the same as an application’s role, and a system that presents data to an application is not necessarily the system that establishes the network’s agreed record. Likewise, custody describes a control arrangement, not a protocol function. To understand an architecture, ask which component performs each task and what other components it depends on.

Some architectures explicitly divide network functions. In the modular model described by Celestia, execution, settlement, consensus, and data availability can be assigned to specialized layers. This is one architectural approach, not a requirement for all crypto systems. The function names help describe where work occurs, but they do not alone establish how a particular deployment implements or secures each function. source

Protocols, networks, and transaction execution

A protocol is a set of rules that participating software follows. Nodes are network participants that use those rules; Ethereum nodes, for example, use a consensus mechanism to agree on new blocks and the continuing chain. Consensus means agreement about the chain’s progression. Validation concerns whether activity conforms to the relevant protocol rules. These functions work together, but they are not interchangeable, and their details differ across networks. source

A transaction can cause a network state change when processed under the applicable rules. The exact processing model depends on the protocol; it should not be assumed that all networks organize execution, agreement, and verification in the same way. This distinction is useful when diagnosing a problem: an application’s view of an action and the network’s processing of that action are separate responsibilities, even when they are connected in a user workflow.

A further distinction is data availability. In the Ethereum explanation of the concept, availability means that network participants can obtain the transaction data needed to independently verify summarized state changes, without requiring every participant to process all data in the same way. Availability is therefore a specific requirement for verification; it is not identical to application indexing or long-term archival retrieval. source

Ethereum rollups provide one example of function separation. A rollup separates transaction execution from the base layer while posting data to Ethereum, where base-layer consensus establishes the published record. The details of a particular rollup still depend on its design. The example illustrates why architecture should be examined by function—where execution occurs and where data is posted—rather than inferred from a broad label. source

How users and applications reach crypto networks

Applications need ways to interact with network functions, but the supplied evidence here does not define a universal wallet, node-access, or indexing architecture. It does support a useful boundary: Ethereum nodes participate in consensus on new blocks and the continuing chain, while rollups can place execution off the base layer and publish data to Ethereum. Those protocol roles should not be conflated with whatever user interface or application component presents an action or its status.

When mapping a real system, trace separately where a user action is prepared, where authorization occurs, where network activity is submitted, and where the application reads its information. Then verify those roles against documentation for the specific implementation. The function map alone cannot establish that an application uses a particular access interface, that it indexes records, or that its displayed data is current. Those details require evidence about the actual system and should not be filled in by assuming that every crypto application has the same stack.

Custody, key control, and operational boundaries

Custody and key control are important operational boundaries, but the available evidence for this article does not establish a general definition of wallet custody, self-managed keys, third-party key control, or recovery practices. It would therefore be inaccurate to infer who controls keys, who can authorize transactions, or how recovery works from a protocol or layer diagram alone.

For a specific architecture, identify the documented key-control and signing arrangement before assigning responsibility. Treat security, recovery, and availability as implementation-specific questions requiring current documentation and evidence for that system. The network’s consensus or data-availability design, by itself, does not establish the security or recoverability of a wallet or service.

Follow a transaction across the infrastructure stack

A practical way to trace a transaction is to follow its responsibilities rather than assume a fixed sequence of products or services. Start with the application action and determine which component prepares it and which component authorizes it. Next, establish how the action reaches the network and which protocol rules govern processing. Finally, identify where the application obtains information about the resulting activity. The exact components and order depend on the implementation, and this article’s evidence does not support a universal signing or submission workflow.

For an Ethereum rollup, the supported architectural distinction is that execution occurs off the base layer while data is posted to Ethereum, where base-layer consensus establishes the published record. This lets an evaluator ask concrete questions about where execution happens and where the relevant data is published, without presuming that the application interface, key custody, or data display is part of the rollup itself. source

Keep data availability separate from the application’s presentation of data. Participants’ ability to obtain transaction data needed to verify summarized state changes is one function; an application’s ability to display a convenient record is another. The first is a protocol-related availability concern in the cited model, while the second must be assessed in the context of the application and its data sources. source

Questions to ask when evaluating an architecture

Use a responsibility map to make an architecture legible:

  • Which protocol rules govern activity, and which participants use a consensus mechanism to agree on network history?
  • Are execution, settlement, consensus, or data availability assigned to distinct layers, or does the documentation describe a different arrangement?
  • For a rollup, where does execution occur, and where is data posted for base-layer consensus?
  • Which documentation establishes who prepares, authorizes, and submits user actions, and where the application gets its information?
  • What system-specific evidence describes key control, security, recovery, and operational dependencies?

Do not treat labels as proof. The modular model and Ethereum rollup example explain particular ways to assign functions; neither establishes that every project uses the same architecture. Likewise, a statement about one layer cannot by itself prove another component’s security, availability, custody arrangement, or recovery process. When documentation does not answer a question, record it as an unresolved system-specific detail rather than extending a narrow architectural claim into a broader assurance.

This approach produces a neutral map of cryptocurrency infrastructure: identify each function, locate it in the documented system, and distinguish network responsibilities from application and custody responsibilities. It explains how layers can interact while preserving the limits of what a general architecture description can establish.

Sources and references