Ethereum.org — Transactions

Transactions from ethereum.org is the official Ethereum Foundation explainer of how transactions work at the protocol level. It is the primary-source documentation rather than a third-party explainer, which is part of what makes it useful — when there are technical questions about how transactions are constructed, validated, and executed, the ethereum.org docs are the canonical reference.

The piece is technical but accessible. Most readers can work through it in 20-30 minutes and come out with a meaningfully better understanding of what is actually happening when you press 'send' in your wallet.

The lifecycle of a transaction

A transaction goes through several distinct phases. Understanding each phase clarifies why certain things happen the way they do.

Construction. Your wallet builds a transaction object containing: the recipient address, the amount to send, the gas limit (maximum gas you authorize spending), the priority fee, the nonce (a per-account counter), and any data payload (for contract interactions).

Signing. Your wallet uses your private key to sign the transaction. The signature proves you have authority to spend from your address. The signature is cryptographically tied to the transaction's specific contents — any change to the transaction would invalidate the signature.

Broadcasting. Your wallet sends the signed transaction to one or more Ethereum nodes. Those nodes propagate it to other nodes across the network. Within seconds, your transaction is in the mempool — the global queue of pending transactions — across the entire Ethereum network.

Inclusion. A validator selects your transaction from the mempool and includes it in the next block they propose. The validator's selection is typically based on the priority fee you offered (higher fees get priority).

Validation. Every other node on the network independently validates the block: checks signatures, confirms balances, verifies the transaction follows protocol rules. If valid, the block is accepted into the chain.

Finality. After a few blocks (or after attestation in the proof-of-stake system), the transaction is considered final. Reversing it would require an attack on the network's consensus, which becomes increasingly expensive with each subsequent block.

Understanding these phases clarifies many things that confuse new users. Why does my transaction say 'pending' for a while? Because it is in the mempool waiting for inclusion. Why was my transaction 'replaced'? Because you submitted a higher-fee version. Why did my transaction 'fail' but I still paid gas? Because the validator did the computational work even though the outcome was a revert.

Transaction types

Ethereum supports several transaction types:

Standard ETH transfer. Send ETH from one address to another. Costs 21,000 gas. Simple and predictable.

Contract interaction. Send a transaction to a smart contract address with a data payload that specifies which function to call and with what parameters. Gas cost varies by what the contract does — anywhere from tens of thousands to millions of gas.

Contract deployment. Deploy a new smart contract. The transaction data contains the contract's bytecode. Typically expensive (hundreds of thousands to millions of gas).

Wrapped transactions. Some advanced patterns use a contract to wrap multiple operations into a single transaction (atomic execution). Examples include flash loans, account abstraction operations, and meta-transactions.

The distinction matters because contract interactions can fail in ways that simple ETH transfers cannot. A contract might revert because it ran out of gas, hit a require statement that failed, or encountered a state condition that prevented the operation.

What happens on a contract call

When you interact with a smart contract (signing a token approval, swapping tokens on Uniswap, depositing into Aave), the mechanism is:

Your wallet constructs a transaction whose to field is the contract address (not a person's address) and whose data field contains the encoded function call (which function to invoke and what arguments to pass).

You sign the transaction with your private key.

When a validator picks up the transaction, they execute the contract's code with the specified arguments. The contract's code might read state, modify state, call other contracts, or revert.

If the contract reverts (for any reason), the state changes are rolled back but the gas spent on executing up to the revert is still charged.

This is why failed transactions cost gas. The validator did the computational work; that work has a cost; the cost is paid regardless of whether the operation succeeded.

The nonce mechanism

Every Ethereum address has a nonce — a counter that increments with each transaction sent from that address. The nonce serves two purposes:

Replay protection. Each transaction is unique because of the nonce. You cannot submit the same transaction twice — the second submission would have the wrong nonce and would be rejected.

Transaction ordering. Transactions from the same address must be processed in nonce order. If you submit transaction with nonce 5 before nonce 4, the nonce-5 transaction sits in the mempool until nonce 4 is included.

The nonce mechanism is mostly invisible to users but explains some confusing behavior. Why is my newer transaction not being processed? Possibly because an older transaction with a lower nonce is stuck. Why can I 'cancel' a transaction by submitting a zero-value transfer to myself with the same nonce? Because the protocol will only include one transaction per nonce per address.

Layer 2 transactions

Transactions on layer 2 networks (Arbitrum, Optimism, Base) follow the same conceptual structure but with different mechanics:

Users submit transactions to the L2 directly. The L2 sequencer orders them, executes them, and batches the results. Periodically (every few minutes to hours depending on the L2), the L2 commits a summary to Ethereum mainnet.

For users, the experience is similar to Ethereum mainnet but with much lower fees (pennies vs. dollars) and similar finality times (seconds to minutes on the L2; longer for full mainnet finality).

The full security guarantees of L1 mainnet are inherited only after the L2's commitment to mainnet is fully finalized. For high-value transfers, this means waiting longer.

The practical takeaway

For most users, the practical takeaways from understanding transaction mechanics:

Transactions are atomic. A transaction either succeeds completely or fails completely. There is no partial execution. This is what makes complex DeFi operations safe.

Failed transactions cost gas. Always verify what a transaction does before signing. If it will revert, you pay for nothing.

Nonce ordering matters. If your wallet shows a transaction stuck pending and others not progressing, check the nonce sequence. Sometimes you need to replace a stuck transaction with a higher-fee version.

Priority fees affect inclusion speed. During congestion, higher priority fees mean faster inclusion. Modern wallets auto-estimate, but you can manually adjust.

Confirmations build security. For small everyday transactions, one confirmation is enough. For meaningful transfers, wait for several confirmations to ensure finality.

These mechanics seem technical but they govern every interaction you have with Ethereum and its compatible networks. Understanding them once means never being confused by transaction behavior again.