Anatomy of an ETH Transaction: Every Step, Every Party

Disclaimer: This article is for informational and educational purposes only and simplifies underlying technical concepts for clarity. It is not financial, investment, tax or legal advice. Figures for fees, prices and timings are illustrative.

Anatomy of an ETH transaction: this article follows a single, simple payment of 0.1 ETH from one person to another, step by step and second by second, to show how the different Ethereum concepts fit together in practice.

The Scenario

Sara wants to pay her friend Omar 0.1 ETH for a freelance design job.

1. Sara buys ETH with dollars on a licensed exchange.
2. She withdraws it to her own self-custody wallet.
3. She sends 0.1 ETH from her wallet to Omar's wallet on Ethereum's main network.
4. Omar later moves the ETH to his exchange account and sells it for dollars.

The heart of the article is step 3, the transfer itself. Steps 1, 2, and 4 show how exchanges connect the traditional financial system to Ethereum.

The journey of Sara's money, from dollars back to dollars, with three Ethereum transactions in the middle.

The Cast

A single 0.1 ETH payment touches more than a dozen distinct parties, most of whom Sara will never know about.

Stage 0: Getting ETH From an Exchange

Before Sara can pay Omar, she needs ETH in her own wallet, and getting it there involves the traditional banking system, a regulated exchange's private records, and one Ethereum transaction.

Opening an Account and Depositing Dollars

1. Identity checks (KYC). Sara signs up with a licensed exchange. Because regulators require it, she uploads her government ID, takes a selfie for verification, and may answer questions about her income and why she is investing. The exchange screens her against sanctions lists.
2. Bank transfer. Sara sends $370 from her bank account to the exchange's bank account. Her bank sees a normal transfer to a licensed company.
3. Credit. When the exchange receives the dollars, it credits Sara's account balance in its own database.

Buying ETH: No Blockchain Involved Yet

Sara places an order to buy ETH. The exchange matches her with a seller in its order book, and her account now shows, say, 0.12 ETH.

Here is a crucial detail: nothing has happened on Ethereum yet. The trade happened entirely inside the exchange's private database. Sara owns a claim on ETH that the exchange holds for her, in wallets it controls. This is the custodial model: the exchange holds the keys.

Behind the scenes, the exchange keeps most customer ETH in heavily secured "cold" storage, often split across multiple keys and approvers, and a smaller amount in "hot" wallets for daily withdrawals. Regulators in many countries require customer assets to be kept separate from the exchange's own funds.

Withdrawing to Her Own Wallet

Sara wants to control her ETH herself, so she withdraws it to her MetaMask address.

1. Address check. The exchange may ask her to whitelist the address, confirm by email and two-factor authentication, and declare that the wallet is her own. Under the "travel rule" adopted by regulators worldwide, exchanges must collect information about who is on each side of a transfer, and some ask customers to prove they control a self-hosted wallet.
2. Risk screening. The exchange's compliance software checks that the destination address isn't linked to sanctioned or criminal activity.
3. The on-chain withdrawal. The exchange's hot wallet sends 0.12 ETH (minus a withdrawal fee) to Sara's address. This is an Ethereum transaction in its own right, going through every step described in the rest of this article, except that the exchange's systems do the signing. Exchanges often send many customers' withdrawals in quick succession or batches.
4. Arrival. Within a minute or so, the ETH appears in Sara's wallet. She now holds it directly: she controls the keys, and no company can freeze it.

Now the main event begins.

Step 1: Getting Omar's Address

The payment starts off-chain, with Omar telling Sara where to send the money, and the wallet quietly checks that the address hasn't been mistyped.

Omar opens his wallet and copies his address, for example 0x8ba1f109551bD432803012645Ac136ddd64DBA72, and sends it to Sara on WhatsApp. Alternatively, he could share an ENS name like omar.eth.

When Sara pastes the address, her wallet runs two quiet checks:

• Format check. A valid address is 0x followed by exactly 40 hexadecimal characters: 0–9 and a–f, in upper or lower case.
• Checksum check. Notice the mix of upper- and lower-case letters in Omar's address. That pattern isn't random: it's calculated from the address itself, under a standard known as EIP-55. If Sara accidentally changes one character, the capitalisation pattern no longer matches, and most wallets warn her.

If Omar had sent omar.eth, Sara's wallet would ask the ENS smart contracts on Ethereum which address that name currently points to, a free "read" that doesn't need a transaction.

Step 2: The Wallet Builds the Transaction

When Sara enters "0.1 ETH" and taps Next, her wallet gathers information from the network and assembles a transaction: a small, structured message with about ten fields.

The Wallet Asks the Network Some Questions

Sara's wallet doesn't store the blockchain itself. It sends questions to its RPC provider, a company running full Ethereum nodes, using a standard interface called JSON-RPC:

The Transaction, Field by Field

The Affordability Check

The wallet checks that Sara can cover the worst case: value plus gas limit × max fee.

0.1 ETH + (21,000 × 2 gwei) = 0.1 ETH + 0.000042 ETH = 0.100042 ETH

Sara has 0.1195 ETH, so she can afford it.

The Confirmation Screen

The wallet now shows Sara a summary: send 0.1 ETH to 0x8ba1…BA72, on Ethereum, with an estimated network fee. Using today's likely prices:

21,000 gas × (0.5 gwei base fee + 0.1 gwei tip) = 12,600 gwei = 0.0000126 ETH, about $0.04 if ETH is $3,000

Many wallets also simulate the transaction first, running it against the current state to preview exactly what will change, and warn if the destination is a known scam address or a contract that can't receive ETH.

Step 3: Signing

When Sara taps Confirm, her wallet uses her private key to sign the transaction, producing a mathematical proof that she authorised exactly this payment, without ever revealing the key.

What Happens Inside the Wallet, in About a Millisecond

1. Packing. The wallet packs the fields from Step 2 into a compact string of bytes, using a standard encoding format called RLP.
2. Fingerprinting. It runs those bytes through the Keccak-256 hash function, producing a 32-byte fingerprint. Change even one digit in any field, and the fingerprint becomes completely different.
3. Signing. It combines the fingerprint with Sara's private key using the ECDSA signature method on the secp256k1 curve, the same cryptography Bitcoin uses. The result is a signature made of three numbers, called r, s, and v (or y-parity).
4. Assembling. The signature is attached to the transaction. The finished, signed transaction is only about 110 bytes, smaller than this paragraph.
5. Naming. The signed transaction is hashed again to produce its transaction hash, such as 0x5c50…e4b2. This becomes its permanent ID, which Sara can use to look it up on Etherscan.

A Surprising Detail: There's No "From" Field

Look back at the table in Step 2: nowhere does it say "from Sara." That's because the signature itself proves who sent it. Anyone can use the transaction and its signature to mathematically recover the public key that signed it, and from that, Sara's address. The network trusts mathematics, not a label.

Why This Is Secure

• The private key never leaves Sara's device. Only the signature is sent out.
• The signature only fits this exact transaction. If an attacker intercepted it and tried to change the recipient or the amount, the signature would no longer match, and every node would reject it.
• It can't be reused. The nonce (0) means it can only ever happen once, and the chain ID (1) means it only works on Ethereum's main network.

If Sara Used a Hardware Wallet

The unsigned transaction would be sent to the device over USB or Bluetooth. The device would display the recipient, amount, and fee on its own screen, and Sara would press a physical button to approve. The signing happens inside the device's secure chip, so even a computer infected with malware can't get the key, though it could try to trick Sara by showing her a different transaction, which is why she should always check the device's screen.

Steps 4 and 5: Broadcasting and Waiting

Sara's wallet hands the signed transaction to the network, which checks it and spreads it from computer to computer around the world within seconds, where it waits to be picked up for a block.

Step 4: The First Node Checks It

The wallet sends the signed transaction to its RPC provider with a request called eth_sendRawTransaction. The provider's node, running an execution client such as Geth, immediately checks it:

If any check fails, the node rejects it immediately and Sara's wallet shows an error, with nothing spent. Here, everything passes. The node replies with the transaction hash, and Sara's wallet shows "Pending."

Spreading Through the Network

Ethereum has no central server. Its nodes are connected in a peer-to-peer network: each node is linked to a few dozen others. The node that received Sara's transaction announces it to its peers. Each peer independently re-checks it, adds it to its own waiting area, and announces it to its own peers. Like news spreading through a crowd, it reaches most of the network's thousands of nodes within a few seconds.

No node simply trusts another. Each one checks everything itself, which is why one dishonest node can't sneak an invalid transaction through.

Step 5: The Mempool

Each node keeps unconfirmed transactions in a waiting area called the mempool, short for memory pool. There's no single, official mempool; each node has its own, though they're usually very similar.

• Ordering: transactions are generally prioritised by the tip they offer. Sara's 0.1 gwei tip is in line with others, so she's in a good position.
• Capacity: mempools have limits. In a busy period, very low-fee transactions can be pushed out and dropped.
• Visibility: the mempool is public. Block explorers, analysts, and automated trading bots can all see Sara's pending transaction. For a simple payment that doesn't matter, but for trades it lets bots "front-run" them. That's why some wallets offer private transaction services that send transactions straight to block builders instead of the public mempool.

For Sara, the wait is usually short: with a normal fee, a transaction is typically included in the next block or two, within about 12 to 24 seconds.

Steps 6 and 7: Choosing a Proposer and Building the Block

Every 12 seconds, proof of stake picks one validator at random to propose the next block, and in most cases that validator buys a ready-made block from a specialist builder, who has included Sara's transaction because her tip makes it worth including.

Step 6: Ethereum's Clock and the Random Choice

Proof of stake runs on a strict clock:

• Slot: 12 seconds. Each slot has room for one block.
• Epoch: 32 slots, or 6.4 minutes.

For every slot, the consensus layer chooses one proposer at random from all active validators, with the chance weighted by how much ETH each has staked. The randomness comes from a value called RANDAO, which every block proposer contributes to by mixing in its own signature, a value no one else can predict in advance, which makes it very hard for any single validator to control who comes next.

The schedule is known a little in advance, about one epoch ahead, so the chosen validator's software is ready. At the same time, every active validator is assigned to vote (attest) once per epoch, so each slot has its own committee of tens of thousands of validators who will check the block.

Say the proposer chosen for the slot that will include Sara's payment is validator #482,113, run by a staking company on a server in Germany. It doesn't matter where it is; any validator anywhere could be chosen.

Step 7: Building the Block

The proposer has two options:

Option A: build it locally. Its own execution client picks the best-paying transactions from its mempool, up to the block's gas limit, and builds a block.

Option B: buy a block from a builder. Most validators, roughly nine in ten blocks, use software called MEV-Boost, which lets specialist block builders compete to supply the most valuable block.

Here's how option B works, in the seconds before the slot begins:

1. Searchers scan the mempool for profit opportunities, such as price differences between exchanges, and send bundles of transactions to builders.
2. Builders combine those bundles with ordinary transactions from the mempool, like Sara's, arranging them to make the block as valuable as possible. Sara's transaction pays a tip, so including it earns money, and there's plenty of space.
3. Each builder sends its block to a relay with a bid: "I'll pay the proposer this much for including my block."
4. The relay checks the block is valid and passes only the header and bid to the proposer, keeping the full contents hidden so the proposer can't steal the builder's work.
5. The proposer picks the highest bid and signs the header, committing to it.
6. The relay then releases the full block and broadcasts it to the network; the proposer usually publishes it too.

The proposer commits to a block before seeing its contents, which protects the builder and keeps the process fair.

What's Inside the Block

The block has two layers, reflecting Ethereum's split since The Merge:

Sara's transaction might be, say, number 87 of 180 in the block.

Step 8: Executing the Transaction

When the block is built, and again on every node that receives it, the execution client runs Sara's transaction step by step, moves the ETH, settles the fee, and records the result.

Inside the Execution, in Order

Two details worth noticing:

• Step 7 would be different if Omar used a smart wallet. His address would then be a contract account, so its code would run when ETH arrives, using more than 21,000 gas, and Sara's wallet would have estimated a higher gas limit. Since the 2025 Pectra upgrade (EIP-7702), even an ordinary account can have smart-wallet code attached, with the same effect.
• Plain ETH transfers don't produce event logs. Token transfers do, which is how wallets and explorers track them. For plain ETH, explorers simply read the transaction itself.

Balances Before and After

Sealing the Result

After all 180 transactions in the block have run, the execution client calculates a single fingerprint of the entire state of Ethereum, every balance and every contract's data, called the state root. It goes in the block header.

Every node that receives the block runs every transaction itself and calculates its own state root. If even one balance differs by one wei, the fingerprints won't match, and the node rejects the block. This is how thousands of independent computers stay in perfect agreement without trusting each other.

In each node, the consensus client passes the block's transactions to the execution client through a connection called the Engine API, essentially asking, "Is this block valid?" The execution client runs it and answers yes or no.

Step 9: Spreading the Block and Voting

The proposer publishes the block at the start of its slot. As soon as nodes receive it, Sara's payment shows as "confirmed," and within seconds tens of thousands of validators check it and vote that it's valid, the first step towards finality.

Inside One 12-second Slot

What an Attestation Contains

Each validator's vote does two jobs at once:

• A vote for the head: "This block is the current tip of the chain." If there were ever two competing blocks, every node would follow the one with the most stake voting for it. This rule is called LMD-GHOST.
• A vote for checkpoints: a vote linking the most recent justified checkpoint (usually the first block of the previous epoch) to the first block of the current epoch. These checkpoint votes are what lead to finality in the next step. This part is called Casper FFG.

Validators sign with a special type of signature (BLS) that can be combined: thousands of signatures can be merged into one, which is how Ethereum handles so many votes without overwhelming the network.

Sara Sees "Confirmed"

Sara's wallet has been asking its RPC provider, "Is there a receipt for this transaction yet?" Now there is; the receipt exists as soon as the provider's node has received and executed the new block, before the validators have even voted. Her wallet changes from Pending to Confirmed, usually 12 to 24 seconds after she tapped Confirm. Omar's wallet, checking his balance, shows 0.1 ETH arriving.

Technically, the payment is now in a block with strong support but is not yet final. Before finality, a block can in rare cases be replaced if the network briefly disagrees, known as a reorganisation, or reorg. With proof of stake, deep reorgs are extremely unlikely, and a payment with even one confirmation is very safe for everyday amounts.

Step 10: Finality

About 15 minutes after Sara's payment is included, enough validators have voted on the surrounding checkpoints that reversing it would require destroying at least a third of all staked ETH, so it's considered final.

How Finality Works

Finality happens epoch by epoch, using the checkpoint votes from Step 9:

1. The epoch containing Sara's block ends. Epochs last 32 slots (6.4 minutes), so this takes anywhere from a few seconds to 6.4 minutes. The first block of the next epoch becomes the checkpoint that covers Sara's block, because it comes after it.
2. Justified: when validators holding at least two-thirds of all staked ETH have voted for that checkpoint, which happens during that next epoch, it becomes justified.
3. Finalised: when the checkpoint of the epoch after that is also justified, the earlier one becomes finalised, along with every block before it, including Sara's.

Finality usually arrives two to three epochs, about 13 to 19 minutes (typically around 15), after the block is included.

What "Final" Really Means

To reverse a finalised block, attackers would need validators holding at least a third of all staked ETH to sign conflicting votes. Those votes would be provable cheating, and those validators would be slashed. With over 40 million ETH staked, that's a penalty worth many billions of dollars. This is economic finality: reversal isn't mathematically impossible, but it would be ruinously expensive and obvious to everyone.

Why It Matters in Practice

Different parties wait for different levels of certainty:

Step 11: Who Got Paid, and What Was Burned

Sara paid about four US cents in network fees; most of it was destroyed, a small tip flowed through the builder to the proposer, and validators across the network earned newly issued ETH for securing the block.

Following Sara's 0.0000126 ETH Fee

About 83% of Sara's fee was burned; the rest became part of the builder's payment to the proposer.

Everyone Who Earned Something From This Block

Penalties That Didn't Happen

If a committee member had been offline at second 4, it would have missed its reward and received a small penalty. If the proposer had signed two different blocks for this slot, it would have been slashed. In Sara's slot, everyone did their job, which is what happens the vast majority of the time.

Step 12: Omar Receives It and Cashes Out

Omar's wallet shows the ETH within seconds; turning it back into dollars means one more Ethereum transaction into his exchange, a wait for finality, and the traditional banking system again.

Omar Checks the Payment

Omar's wallet shows his new 0.1 ETH balance by asking its own RPC provider. He can also paste the transaction hash into Etherscan, which shows every public detail: the block number, the time, Sara's and Omar's addresses, the 0.1 ETH value, the gas used, the base fee burned, the tip, and how many blocks have been added since.

Anyone in the world can see this information. It doesn't show their names, but if someone links an address to a person, for example through an exchange record or a public post, they can see that person's whole history. This is why Ethereum is described as pseudonymous, not anonymous.

Depositing to His Exchange

Omar decides to convert the ETH to dollars.

1. A deposit address. His exchange gives him a deposit address that is unique to his account, so the exchange can tell whose deposit is whose.
2. Another transaction. Omar sends his ETH from his wallet to that address. Because the network fee comes out of the same balance, he can't send the full 0.1 ETH: his wallet's "Max" button sends 0.1 ETH minus the fee, about 0.09999 ETH. This new transaction goes through every step in this article again, from building and signing to finality.
3. Monitoring. The exchange runs its own Ethereum nodes, watching every new block for payments to its customers' deposit addresses. It spots Omar's deposit within seconds.
4. Waiting for finality. The exchange shows the deposit as "pending" until its required number of confirmations, often around finality, about 13 minutes.
5. Compliance screening. Blockchain analytics software traces where the ETH came from. It can see that it came from Sara's wallet, which was funded by a licensed exchange, a clean history. If the funds had passed through a sanctioned address or a known hack, the exchange might freeze them and investigate, as anti-money laundering rules require.
6. Credit. Omar's exchange balance increases by about 0.09999 ETH in its internal database.
7. Sweeping. Later, the exchange moves the ETH from Omar's deposit address into its own consolidated, secure storage, using yet more on-chain transactions that Omar never sees.

Back to Dollars

1. Omar sells his ETH on the exchange's order book. Like Sara's purchase, this happens only in the exchange's database, not on Ethereum.
2. He requests a withdrawal to his bank account.
3. The exchange sends the dollars by ordinary bank transfer, usually arriving the same day or the next working day.

The Full Timeline at a Glance

From the moment Sara taps Confirm, her payment is visible to Omar in under half a minute and final in about a quarter of an hour.

The core payment, from Sara's tap to finality.

Compare this with an international bank transfer, which might take one to three working days and pass through several correspondent banks, each able to delay or block it.

What Can Go Wrong, and Where

Most problems with a simple payment happen before it reaches the blockchain, in Sara's hands, and many of them can't be undone once the transaction is final.

How It Differs on a Layer 2

If Sara paid Omar on a Layer 2 such as Base instead, the experience would feel almost identical but faster and cheaper, because a single sequencer handles her transaction first and Ethereum's validators only see it later, as part of a batch.

Key Takeaways

Sources and Further Reading

• Ethereum wallets
• EIP-55: Mixed-case checksum address encoding
• ENS documentation
• EIP-1559: Fee market change for ETH 1.0 chain
• Ethereum Yellow Paper (signing and transactions)
• Proof-of-stake (ethereum.org)
• Glamsterdam Testnet Announcement (Ethereum Foundation blog)
• EIP-7702: Set code for EOAs
• ERC-20: Token standard
• Gasper: how Ethereum reaches finality (ethereum.org)
• Optimistic rollups (ethereum.org)