How a Transaction Gets Into a Block, Step by Step

The gap between pressing confirm and seeing a confirmation contains more machinery than the interface suggests.

Stage one: construction

Your wallet builds the transaction: sender, recipient, amount, data payload, nonce, gas limit, and fee parameters.

The nonce is a counter ensuring transactions from your address execute in order. It is the source of a specific class of confusion, since a stuck low-nonce transaction blocks everything behind it.

Stage two: signing

Your private key produces a signature over the transaction data. The key never leaves the device; the signature proves authorisation without revealing it.

On a hardware wallet, this happens on the device, which is why the device’s screen showing the correct destination matters. It is the only display the compromised computer cannot alter.

Stage three: broadcast

The signed transaction goes to a node, which validates it locally: is the signature valid, does the sender have the balance, is the nonce correct, is the fee at least the base fee.

An invalid transaction is rejected here and never reaches the network. This is why some errors appear instantly.

Stage four: propagation

The node relays to its peers, which relay onward. Within a second or two most of the network holds it in the mempool.

Stage five: selection

A builder or miner assembling the next block selects transactions from their mempool, generally maximising fee revenue and any value available from ordering.

This is where waiting happens. A transaction offering a competitive fee is selected quickly; one offering less waits until the queue clears.

Stage six: execution and inclusion

The transaction executes as part of block construction. State changes are computed, gas consumed is measured, and the result is recorded.

If execution reverts, the transaction is still included, marked as failed, and the gas consumed is still charged. This is the stage that surprises people: a failure is recorded on-chain rather than simply not happening.

Stage seven: confirmation

The block propagates and subsequent blocks build on it. Each one makes reversal less likely, and after enough of them the transaction is settled by whatever standard applies to that chain.

Where failures occur

Stage	Failure	Cost
Three, validation	Invalid signature, wrong nonce, insufficient balance	Nothing
Five, selection	Fee too low, transaction waits or is evicted	Nothing unless it eventually confirms
Six, execution	Out of gas, slippage exceeded, contract reverted	Full gas consumed

The costly failures are all at stage six, and all of them are visible on the confirmation screen before signing. Gas limit, slippage tolerance and what the transaction actually calls are displayed, and reading them takes eight seconds.

What this explains

Why a stuck transaction cannot be cancelled by closing the app: it has already propagated and exists on hundreds of machines.

Why a replacement must use the same nonce: it is replacing a specific queue position.

Why failed transactions cost money: work was performed.

Why deposits to a venue take longer than one block: the venue waits for confirmations, and the number it waits for is published by platforms such as a venue that supports immediate withdrawal, so the timing is predictable rather than mysterious.