How is a transaction verified on a cryptocurrency network? Using Ethereum as a bounded example, the answer involves several distinct questions: which account authorized the transaction, what execution produces, whether the transaction belongs in a validated block, and how the network reaches agreement. A single word such as verified can hide those differences.
The distinction matters most when a contract operation fails. An included transaction can have failed execution. Conversely, a successful execution status alone does not independently establish every result a person hoped to achieve. This explanation follows ordinary Ethereum transactions; it is not a universal description of every cryptocurrency or an exhaustive validation algorithm.
1. Signing establishes account authorization
An ordinary Ethereum transaction carries a signature generated using the sender’s private key. That signature authenticates authorization by the key associated with the sender. The ordinary from field identifies the sender address. These are statements about account authorization, not proof of a person’s identity, understanding, or satisfaction with the eventual result.
The transaction also has a nonce: a sequentially incrementing counter indicating the transaction number from that account. This gives the transaction an account-specific number. Defining that field does not provide the complete rules for checking nonces, replacing pending transactions, or handling every transaction type.
The primary reference for these fields is Ethereum’s transaction documentation. Read its signing explanation narrowly: authorization by a private key should not be expanded into a general claim that the requested operation is safe or will achieve its intended purpose.
2. Broadcasting and execution are different stages
The documented lifecycle describes broadcasting the transaction and placing it in a pool of pending transactions. This is a simplified account of propagation. It does not promise that every node receives the transaction or that the transaction will eventually be included.
Ethereum’s execution client executes broadcast transactions in the Ethereum Virtual Machine, or EVM. Execution addresses what the instructions do under Ethereum’s execution rules. Inclusion addresses whether the transaction becomes part of a validated block. Transactions must be included in such a block, but the requirement itself is not a promise of inclusion.
Re-execution is also visible in the documented full-sync process: a node regenerates blockchain state incrementally by executing every block from genesis. That is a concrete example of reconstructing state through execution rather than merely accepting a claimed result. The qualification matters: this description applies to full sync. Other synchronization modes can begin from trusted checkpoints or handle historical data differently.
Ethereum’s nodes and clients documentation explains these execution and synchronization roles. They should not be turned into a claim that every node always replays all history.
3. Consensus goes beyond one node’s result
Ethereum’s consensus client implements proof-of-stake agreement using data validated by the execution client. Execution validation and network agreement therefore have connected but distinct roles.
The transaction lifecycle also distinguishes a block’s inclusion from later justification and finalization. These are separate stages, rather than interchangeable labels for the first appearance of a transaction in a block. The overview does not supply a guaranteed completion time or justify a claim of unconditional progression.
A deduction follows from these premises: because execution supplies validated data for network agreement, and finalization is a separate stage, one node’s local execution validation alone does not establish network finality. This is an inference from the separation of roles, not a quoted consensus rule or a specification of voting thresholds.
When evaluating an explanation of verification, ask which stage it actually establishes. A description of local execution cannot, by itself, answer the later question of network finality.
4. Read execution status separately from inclusion
For Ethereum receipts that report status, the value is 1 for execution success or 0 for execution failure. The receipt’s blockNumber identifies the block containing the transaction. That block field alone does not establish finality. The status description also has a historical boundary: the supplied documentation distinguishes pre-Byzantium receipts that instead report a state root.
These fields support another explicit deduction. A receipt identifies a containing block while separately allowing a failure status. Therefore, inclusion in a validated block does not imply successful execution. The network can accept a transaction whose execution fails.
The Ethereum JSON-RPC documentation supplies these receipt definitions. A further interpretive limit follows from the status definition: a binary execution result does not independently compare the outcome with every objective a person had in mind. Establishing a particular intended contract result requires evidence of that result, beyond the status field alone.
This distinction explains why a broad statement such as the transaction was verified can leave the most relevant question unanswered. Was account authorization established, was inclusion established, or did execution succeed?
5. REVERT rolls back the affected execution
REVERT aborts the affected EVM execution, marks it as failed, and rolls back that execution’s state changes. The scope of that sentence is essential. It should not be expanded into an assertion that all gas, fees, nonce effects, or unrelated outer effects are restored.
A normally executed REVERT does not consume all remaining gas. That does not mean execution was free or that previously consumed gas was restored. There is also an explicit exception: insufficient gas to cover REVERT, or a stack underflow, makes the instruction behave as an out-of-gas exception consuming all gas in the affected execution context.
EIP-140, which specifies REVERT, also describes a failure indication returned to the caller when a callee reverts. From the execution-scoped rollback rule and that caller/callee distinction, a limited deduction follows: a callee’s REVERT alone does not establish rollback of every caller effect. The caller’s subsequent behavior and the whole transaction’s outcome require their own evidence.
6. A hypothetical example and interpretation checklist
Hypothetical example: Maya authorizes an ordinary Ethereum transaction for a contract operation she expects to complete a task. The transaction is broadcast and later included in a validated block. Its receipt identifies that block but reports status 0. Inclusion and execution failure are compatible; the signature and block inclusion do not turn the failed execution into a successful one.
Suppose the affected execution used REVERT. Its state changes are rolled back within that execution’s scope, subject to the gas qualifications above. If the example instead had status 1, the field would establish execution success, but would not independently prove Maya’s entire intended outcome. These are illustrative alternatives, not reports of a real transaction.
Use this checklist to assess a transaction-verification explanation:
- Identify the network and keep Ethereum-specific conclusions within that scope.
- Separate sender authorization and nonce fields from claims about execution results.
- Distinguish broadcasting, block inclusion, and later consensus stages.
- Interpret receipt execution status separately from its containing block.
- Keep REVERT rollback scoped to the affected execution and retain its gas exceptions.
- Ask what evidence establishes the particular intended contract outcome.
For a separate explanation of how transaction evidence is displayed, see how to read an Ethereum transaction in a block explorer.
Educational material prepared with AI assistance. Candidate claims and evidence mappings require independent editorial review.