Crypto assets are digital assets, while a blockchain network is one possible system for recording and updating transactions involving them. In a digital payment, the asset is what the parties transfer or receive; the network supplies rules and infrastructure for processing and recording that activity. Wallets, custodians, applications, and users have distinct roles, so the exact payment flow depends on the arrangement and network.

A crypto asset is a digital asset that can be transferred between users in a blockchain-based arrangement. The asset and the network are related, but they are not interchangeable: the asset is what a payment concerns, while the network is a system for processing and recording activity under its rules. The description does not establish that every asset is issued, transferred, or supported in the same way.

A blockchain is a tamper-evident and tamper-resistant digital ledger implemented in a distributed fashion. In a payment context, it can provide a shared record of activity. That technical description does not, by itself, establish what an asset represents, what rights a holder has, or whether the asset can be redeemed. Those questions depend on the particular asset and arrangement, and should not be answered merely by identifying a blockchain record.

Blockchain networks and payment arrangements can also serve different purposes. A network may process transactions involving an asset, but that does not mean every activity associated with the asset occurs on-chain. An application may initiate or route payment instructions, and associated services may provide additional steps. The degree to which an arrangement relies on those components varies; do not assume that every component or asset is recorded directly on a blockchain.

A practical first distinction is therefore between the thing involved in the payment and the system used to record or process it. A second distinction is between the network and the surrounding services. Keeping these separate helps prevent a common conceptual error: treating “crypto” and “blockchain” as synonyms, or treating a record on a network as a complete description of the payment arrangement.

How a crypto payment moves from sender to recipient

A general payment model includes a sender, a recipient, an asset, a means of authorization, and a network or other system that processes the instruction. The sender prepares an instruction and authorizes it according to the applicable method. The network then processes it under its rules and may update its record. This is a conceptual sequence, not a universal transaction format or guarantee that every payment follows identical stages.

Ethereum provides one example of a network-specific lifecycle: a transaction can be broadcast, remain pending, be included in a block by a validator, and later undergo justification and finalization. These terms describe stages in that network’s process; they should not be applied as universal labels to other networks. Likewise, a user interface’s indication that a transaction was sent should not automatically be interpreted as the recipient’s payment being complete.

For another concrete but narrower example, Bitcoin confirmations indicate increasing confidence in a transaction’s place in the chain, rather than an immediate or absolute guarantee against reversal. The degree of confidence depends on confirmations and operating conditions. This illustrates why a payment operator must define what evidence and conditions it accepts for its own workflow instead of assuming that “confirmed” has one uniform meaning across systems.

The network record is only one part of a payment experience. A merchant or application may have its own order-processing steps and acceptance conditions. A transaction record alone does not establish that an external payment obligation has been legally discharged, that identities have been verified, or that disputes and errors can be resolved. The network can process an instruction under protocol rules without determining every real-world consequence of that activity.

The roles of wallets, keys, and network rules

A wallet is software, hardware, or a service used to generate, manage, store, or use cryptographic keys and blockchain addresses. The term does not mean that the wallet physically contains a blockchain asset. Its role is to help interact with the relevant system, and the details vary by wallet and custody model.

In a self-custody arrangement, the user controls the private keys and recovery material needed to access the user’s crypto assets. With third-party custody, a provider manages access to private keys on behalf of customers. These models allocate key responsibilities differently. The word “wallet” alone does not show who controls the keys or what recovery process is available, so those details must be established for the particular service.

Keys are relevant to authorization, but authorization is not the same as identifying the person who made a payment. A valid signature can support an attribution to control of a key for a transaction, but it does not, by itself, identify the human, organization, device, or service controlling that key. A network can validate an authorization according to its rules without establishing the real-world identity of the person behind it.

Network rules determine which transactions are valid and how accepted activity updates the shared record. A wallet or application may prepare or present an interaction; a custodian may manage key access; a user authorizes an action; and network participants process activity according to protocol rules. Some services may combine roles, but the roles remain conceptually distinct. When reviewing a payment flow, ask which component performs each step rather than attributing every action to “the blockchain.”

What changes between crypto payment designs

Payment arrangements can differ in the asset involved, how transactions are processed, and who controls access to the relevant keys. They can also involve steps outside the network, such as a service that initiates or routes instructions. A general description of crypto payments does not establish that different assets, networks, or providers share the same process or operational responsibilities.

Cross-network transfers add another distinction. Separate ledgers maintain separate records; an asset is not physically moved from one ledger to another. Depending on the bridge design, mechanisms such as locking, releasing, minting, burning, or swapping may coordinate value across chains. The exact accounting and redemption path depends on that design. A reader should therefore determine whether a proposed flow stays within one ledger, uses a bridge, or includes conversion through another service, rather than treating all routes as an ordinary transfer.

Fees and settlement characteristics also require network- and service-specific evidence. For example, Ethereum transaction fees depend on computational gas used and fee parameters; base fees adjust with block usage, and priority fees can affect inclusion incentives. This is an Ethereum-specific description, not a general rule for all payment networks. It also does not establish the total cost of a payment arrangement, which may include charges outside the network.

Network suitability is a separate operational assessment. Relevant considerations include the required transaction flow, confirmation and finality expectations, capacity, fee behavior, application integration, dependencies, and operational requirements. These considerations do not establish comparative performance or suitability for every network. They provide questions to investigate using evidence for the particular system and use case.

Questions to resolve before applying the foundations

Before evaluating a real payment flow, identify the participants, asset, network, wallet or custody arrangement, and any conversion or cross-network step. Then map who prepares and authorizes the transaction, which system processes it, what the recipient checks, and which event counts as completion for the relevant workflow. This separation helps clarify where protocol behavior ends and application, provider, merchant, or user responsibility begins.

Claims about jurisdiction, regulation, tax, availability, yields, security, recovery, or compliance need current, specific evidence for the relevant asset, service, place, and arrangement. This explainer does not establish those facts for a particular payment. It also does not recommend a product or network. Its purpose is to provide a conceptual map: distinguish asset from network, key authorization from identity, and a network record from the wider payment process. With those boundaries clear, readers can identify which technical and operational questions require separate investigation.

Sources and references