A transaction is a signed message that tells the network to do something. On Bitcoin, a transaction transfers UTXOs from one set of addresses to another and is signed by whoever controls the inputs. On Ethereum, a transaction can transfer ETH, call a smart contract function, deploy a new contract, or do several of these in sequence within a single call — all authorised by a signature from the sender’s private key. Either way, the transaction is the atomic unit of activity: every state change on a blockchain happens as a consequence of a transaction being included in a block.
A valid transaction contains enough information for the network to verify that the sender is authorised (via the signature), that the transaction is consistent with the current state (the sender has enough balance, the nonce is correct), and that the requested action is well-formed (the gas limit is sufficient, the function call has valid parameters). Nodes that receive a transaction check it against all these rules before relaying it to peers or including it in a block. An invalid transaction gets dropped without being forwarded, and the sender does not pay any fee for it because it never made it to a block.
The Lifecycle of a Transaction
A typical Ethereum transaction goes through roughly the following steps from creation to confirmation.
Construction. Your wallet software builds the transaction object — to address, value, data, gas limit, max fee per gas, max priority fee per gas, nonce, chain ID — based on what you are trying to do. For a simple ETH transfer, this is straightforward. For a contract interaction, the wallet has to encode the function call into the data field according to the contract’s ABI.
Signing. Your wallet hashes the transaction data and signs it with your private key using ECDSA on the secp256k1 curve. The signature is attached to the transaction as the v, r, and s values, and it proves that whoever signed the transaction knew the private key.
Broadcasting. The signed transaction is sent to a Ethereum node — typically via an RPC endpoint like Infura, Alchemy, or your own node. The node validates the transaction and, if it is valid, relays it to its peers. Within a few seconds, the transaction has propagated to most of the network’s mempool.
Mempool waiting. The transaction sits in the mempool waiting to be included in a block. If the gas price is high enough to be competitive with other pending transactions, it gets picked up by a block builder quickly. If it is too low, it can sit there for minutes, hours, or until it is dropped entirely.
Inclusion. A block builder includes the transaction in a block and the block gets proposed by a validator. The block is broadcast to the network and attested to by other validators.
Confirmation. After enough subsequent blocks have been built on top of the one containing your transaction, the transaction is considered confirmed. For Ethereum, finality comes within about 13 minutes under normal conditions. For Bitcoin, each additional confirmation reduces the already-tiny probability of a reorg, and 6 confirmations (roughly an hour) is the conventional threshold for large transfers.
Gas and Fees
Every transaction pays a fee in the native currency of the chain, proportional to the amount of computation it requires. On Ethereum, this is the gas model: each operation has a fixed gas cost, the total gas used by a transaction is the sum of the operations it performs, and the fee is gas used × effective gas price. The sender specifies a maximum fee they are willing to pay, and if the transaction uses less gas than the limit, the unused portion is refunded.
Gas pricing became more complex with EIP-1559, which introduced a base fee that is burned (rather than paid to validators) and a priority fee (a tip) that goes to the validator who includes the transaction. Wallets handle the complexity automatically in most cases; users see a single “transaction fee” estimate and can either accept it or adjust the speed/cost tradeoff manually.
Bitcoin transactions pay fees based on bytes (more accurately, virtual bytes after SegWit) rather than gas. The logic is the same in spirit — more complex transactions cost more because they take more block space — but the specific accounting is simpler because Bitcoin’s scripting system is much more limited than Ethereum’s.
Failed Transactions
One of the more confusing things for new Ethereum users is that a transaction can fail while still charging gas. If your transaction runs out of gas halfway through execution, or if it encounters a revert instruction in the contract code, the state changes are rolled back but the gas already consumed is still paid. The transaction appears in the block marked as “failed” or “reverted” on block explorers, and the sender sees a deduction from their balance without the intended action having taken place.
Failed transactions happen for several reasons. The gas limit was too low for the actual computation required. A contract function was called with invalid parameters (wrong token, insufficient allowance, slippage too tight). A race condition caused the transaction to be invalid by the time it was included (someone else beat you to a limited-availability action). A contract had a bug that caused it to revert for unexpected inputs. In each case, the user has spent gas for no useful outcome, and the cost can be substantial on a congested network.
Learning to read a failed transaction on Etherscan — to see the exact revert reason, understand which contract call failed, and figure out what went wrong — is one of the practical skills that separates experienced Ethereum users from confused ones. Modern wallets are better at pre-simulating transactions and warning users when a transaction is likely to fail, but the underlying problem has not been fully solved, and failed transactions remain a routine part of interacting with complex DeFi protocols.