Sending Transactions on Ethereum
Understanding the Architecture Behind Every Transaction

How Ethereum Processes Your Transactions

On Ethereum, every state change starts with a transaction: a cryptographically signed instruction from an externally owned account (EOA) that tells the network what to do. A transaction can be a simple ETH transfer (sending ether directly from one address to another), a contract call (invoking a function on a deployed smart contract, such as a token swap or an ERC-20 approval), or a contract deployment (publishing new bytecode to the chain). All three follow the same lifecycle. When you hit "Send" on a wallet like MetaMask, your transaction doesn't fly straight to "the blockchain." It first travels as a JSON-RPC call to an Ethereum node, a server running client software that speaks the Ethereum protocol. Most users never run their own node; instead, they rely on RPC providers such as Infura, Alchemy, or QuickNode, which expose public JSON-RPC endpoints. These providers maintain clusters of nodes and route your eth_sendRawTransaction request to one of them. The receiving node validates the transaction (checking the nonce, signature, and gas), drops it into its local mempool (the waiting room for pending transactions), and gossips it to peer nodes across the network. From the mempool, a validator (previously called a "miner" before The Merge) picks it up, includes it in a proposed block, and submits that block to the consensus layer (the Beacon Chain), where other validators attest to it. Once the block reaches finality, your transaction is permanently part of the canonical chain. Under normal network conditions, the entire journey from hitting "Send" to being included in a block takes roughly 12 to 15 seconds (one slot), while full finality requires about 12 to 15 minutes (two epochs). If the network is congested or your gas tip is too low, your transaction may sit in the mempool for longer before a validator picks it up. The diagram below illustrates this flow from your wallet all the way to on-chain finality.

1 Your Wallet MetaMask / DApp JSON-RPC eth_sendRawTransaction 2 RPC Provider Infura / Alchemy / QuickNode routes to node On-Chain (Ethereum Network) 3 Ethereum Node Execution Client Geth / Nethermind Consensus Client Prysm / Lighthouse Engine API validates & adds yours! Mempool (pending transactions pool) gossip to peers N N N N N N selected for inclusion 4 Validator proposes a new block builds & signs 5 Block #N txs, receipts, state root, gas used ... submitted to chain 6 slot k slot k+1 your tx! slot k+2 * * slot k+3 ... validators attest Beacon Chain (Consensus Layer) Finality! ~12 min

What Happens Step by Step

Let's break down the journey of a transaction through the Ethereum network:

1. Transaction Creation & Signing

Your wallet (e.g., MetaMask) constructs a transaction object containing the recipient address (to), the amount of ETH to send (value), gas parameters, an optional calldata field (data), and a nonce, which is a sequential counter that tracks how many transactions your account has sent. For a simple ETH transfer, the data field is empty and value carries the amount; for a contract call (e.g., a token swap), value may be zero while data encodes the function selector and its arguments; for a contract deployment, the to field is left empty and data contains the contract bytecode. The nonce plays a critical role in ordering and replay protection. The wallet then signs this transaction with your private key, producing a raw transaction byte string. To understand how wallets derive keys and how the signing process works under the hood, see Ethereum Wallets & Transaction Signing.

2. JSON-RPC Call to the Provider

The signed transaction is sent via eth_sendRawTransaction to an RPC endpoint. If you're using a provider like Infura, they receive the call and forward it to one of their managed Ethereum nodes.

JSON-RPC
{
  "jsonrpc": "2.0",
  "method": "eth_sendRawTransaction",
  "params": ["0xf86c...signed_tx_data"],
  "id": 1
}

3. Validation & Mempool

The execution client (e.g., Geth) validates the transaction: it checks the signature, ensures the nonce is correct, and verifies the sender has enough balance to cover the gas. If valid, the transaction enters the node's mempool and is propagated to other nodes via the peer-to-peer gossip protocol.

4. Block Proposal

A validator selected by the consensus protocol (via the Beacon Chain's randomized selection) builds a block from the mempool transactions, prioritizing those with higher gas tips. The execution client executes each transaction and computes the new state root. Since Ethereum produces a new block every 12 seconds (one slot), your transaction will typically land in the very next block if it offers a competitive gas tip.

5. Attestation & Finality

Other validators attest to the proposed block's validity. After enough attestations accumulate across epochs (roughly 12 minutes), the block reaches finality, at which point the transaction is irreversible and permanently recorded on the Ethereum blockchain.

This flow applies to every type of transaction on Ethereum: simple ETH transfers (where ether moves from one address to another with no contract logic involved), contract interactions (where a function on a deployed contract is invoked, such as swapping tokens on Uniswap or approving an ERC-20 allowance), and contract deployments. The only differences are the fields populated in the transaction object; the lifecycle from wallet to finality is the same. To learn what smart contracts are and how they execute on the EVM, see Ethereum Smart Contracts.