A cryptocurrency transaction is not verified by one central checker or by one yes-or-no test. It passes through a sequence of independently performed checks: the wallet constructs and signs an instruction, receiving nodes decide whether to accept and relay it, a block producer selects and orders it, other nodes validate the proposed block and resulting state, and the network’s consensus rules determine which history becomes canonical or final.

These stages explain why a transaction can have a hash but remain pending, appear in a block but not yet meet a business’s confirmation policy, or be validly included even though a smart-contract call reports failed execution. The exact rules differ across networks, so Bitcoin and Ethereum are useful examples rather than a universal specification.

Verification is a sequence, not one event

The word verified is used for several different states:

  1. Authorized: the transaction contains signatures or other proofs that satisfy the asset’s spending rules.
  2. Admitted: a node considers the transaction eligible for its local pending pool and relay policy.
  3. Included: a producer has placed it in a proposed block.
  4. Executed and block-valid: nodes have checked the transaction under current state and accepted the proposed block’s result.
  5. Canonical: fork-choice rules currently select the block as part of the network’s recognized history.
  6. Final or sufficiently confirmed: the network or the receiving application treats reversal risk as acceptably low under a stated policy.

The wallet constructs and signs the transaction

A wallet begins with the intended action: transfer an asset, call a smart contract, create an approval, or perform another state change. It assembles network-specific fields such as the destination, amount, asset or contract, fee parameters, and a replay-protection value.

In an account-based network such as Ethereum, a transaction includes a nonce that orders transactions from the sending account. Ethereum’s documentation describes a signed transaction as including the recipient, value or input data, gas limit, fee fields, nonce, and signature according to its transaction type. The signature lets nodes recover or verify the authorizing account.

In Bitcoin’s UTXO model, each input references a specific unspent transaction output. The spender supplies data and signatures that satisfy the previous output’s locking conditions, and new outputs define where value can be spent next. A transaction cannot validly spend the same UTXO twice in the same accepted history.

A valid signature proves that the required signing authority approved the signed data under the protocol’s cryptographic rules. It does not prove the signer’s legal identity, that the receiving address is correct, that a contract is safe, or that the transaction is commercially sensible.

Before signing, the wallet should present the actual network, recipient, asset contract, amount, fee limits, contract method, permissions, and any other material effect. Once signed, changing protected fields invalidates the signature.

A node performs admission checks

The wallet sends the serialized transaction to a node, which performs preliminary checks against its current view of the network. Common checks include:

  • Is the encoding and transaction type recognized?
  • Does the signature or spending script satisfy the authorization rules?
  • Is the sender’s nonce or the referenced UTXO valid for the current state?
  • Are the inputs unspent, the balance sufficient, and outputs within permitted value rules?
  • Are gas, size, fee, timing, and resource limits acceptable?
  • Does the transaction conflict with another pending or confirmed transaction?
  • Does it satisfy the node’s local relay and mempool policy?

The last point is important. Consensus rules determine what every conforming node must accept as valid in a block. Policy rules determine what an individual node is willing to keep or relay before block inclusion. Bitcoin’s testmempoolaccept documentation, for example, distinguishes consensus violations from policy rejection. A transaction can be consensus-valid yet absent from a particular node’s mempool because of fee, size, replacement, or other local policy.

The pending transaction propagates

After accepting a transaction, a node can announce it to peers. Each receiving node performs its own checks before storing or forwarding it. This peer-to-peer process spreads a valid candidate across the network and makes it available to block producers.

A mempool is local, not a single global queue. Two nodes can hold different pending sets because they received different transactions, use different policies, restarted, evicted low-priority entries, or observed conflicts in a different order. Bitcoin’s developer guide explicitly notes that unconfirmed transactions have no permanent status and are held in non-persistent memory.

Broadcast therefore means only that one or more nodes have seen the transaction. It does not guarantee universal propagation, block inclusion, execution success, or finality. A transaction may be dropped when it no longer meets policy, replaced under network rules, invalidated by a conflicting confirmed transaction, or remain unknown to the producer that creates the next block.

A block producer selects and orders transactions

A miner or validator constructs a candidate block from transactions available to it. Eligibility for the mempool does not require inclusion. The producer must fit the block’s resource limits and may prioritize transactions using fees, dependencies, private order flow, application requirements, or other permitted strategies.

Order matters. In an account model, earlier transactions can change balances, nonces, contract storage, prices, or permissions used by later transactions. In a UTXO model, two candidates that spend the same output conflict. A producer must choose an ordering that produces a valid block state.

Other nodes validate the proposed block

When a proposed block reaches peers, nodes do not have to trust the producer’s claim that it is valid. They check the block header, parent reference, producer eligibility or proof, resource limits, transaction structure, and every consensus-relevant state transition.

Ethereum’s block documentation explains that nodes re-execute transactions from a proposed block and compare the resulting state change with the block’s commitments. A transaction can be properly authorized and included but still run out of gas or encounter a contract condition that causes its execution to revert. In that case, the receipt can report failure while the transaction itself remains part of the block and the network fee is still accounted for under Ethereum’s rules.

Bitcoin full nodes check that inputs reference spendable UTXOs, scripts and signatures satisfy spending conditions, values obey consensus rules, no input is double-spent within the accepted history, and the block itself satisfies proof-of-work and structural requirements.

If a transaction or the resulting block violates consensus rules, a conforming node rejects the block even if the proposer spent resources creating it. Independent validation is what separates a valid proposal from an accepted ledger update.

Consensus chooses history and establishes finality

Nodes can temporarily see competing valid blocks near the head of a chain. A fork-choice rule determines which branch each node currently treats as canonical. The rule is part of the network’s consensus design, not a decision made by an explorer or wallet company.

In proof-of-work systems such as Bitcoin, additional blocks add cumulative work to one branch. Each block after a transaction’s block is commonly described as another confirmation. Reversal generally becomes less likely as more work accumulates, but the protocol does not attach the same explicit finality label used by some proof-of-stake systems.

Ethereum proof of stake separates inclusion from finality. Validators attest to checkpoint blocks, and the finality mechanism upgrades checkpoints through justified and finalized states when its voting conditions are met. A transaction can therefore be included in the current head before its block is finalized.

A receiving application must define its own acceptance policy. A low-value retail payment, exchange deposit, bridge transfer, and irreversible delivery may use different thresholds. The policy should identify the network, required state, reorganization handling, and timeout behavior instead of relying on a universal number of confirmations.

Why a transaction can be pending, dropped, failed, or reversed

These common labels describe different conditions:

  • Pending: one or more nodes know the transaction, but it is not yet in an accepted block.
  • Dropped: a node removed it from its local mempool or never accepted it; another node may still retain it.
  • Replaced or conflicted: another valid transaction uses the same account sequence or spends the same input under the network’s rules.
  • Included and successful: the transaction is in a canonical block and its intended state transition completed according to the protocol.
  • Included but execution failed: the transaction is in a block, but a contract call or resource condition reverted the requested state change. This distinction is prominent on programmable networks.
  • Reorganized: a previously observed block is no longer on the selected branch, so its transactions may return to a pending pool, appear in another block, or become invalid.
  • Finalized: the network has reached its protocol-defined finality state, where reversal would require violating strong consensus assumptions or penalties.

Wallet and explorer labels can simplify these categories. Operational systems should inspect the machine-readable receipt, block reference, canonical-chain status, confirmation or finality state, and actual asset-transfer events.

How to verify a transaction independently

Start with the exact network. The same-looking address or transaction identifier on another chain is not evidence of the intended transfer. Then verify:

  1. Transaction identifier: derive it from trusted wallet or node output, not an unsolicited message.
  2. Canonical block: confirm the transaction is included in a block currently selected by the network.
  3. Execution status: check whether the requested state transition succeeded, failed, or partially produced protocol-defined events.
  4. Actual transfers: inspect native-asset and token movements, recipient, amount, contract addresses, and fees rather than relying only on a displayed function name.
  5. Confirmation or finality state: apply a network- and risk-specific acceptance policy.
  6. Source independence: when material, compare an explorer with a trusted node, RPC endpoint, or separately operated data provider.
  7. Application settlement: confirm that the merchant, exchange, bridge, or contract has recognized the deposit under its own rules.

An explorer is a convenient index of blockchain data, but it is not the consensus network. A green label on one website is weaker evidence than a result reproduced from the canonical state through an independently trusted node.

Transaction verification is therefore a pipeline: authorization, state validation, local admission, propagation, ordered execution, block validation, fork choice, and finality. Knowing which stage has actually completed prevents a pending hash, an internal account entry, or a provisional block from being mistaken for settled cryptocurrency value.

Sources and references