Anatomy of a Layer 2 Transaction: ETH and USDC on Base, End to End

Disclaimer: This article is for informational and educational purposes only and simplifies underlying technical concepts for clarity. It is not financial, investment, or security advice. Fees, timings, and other figures are illustrative or approximate and change over time.

This article follows two payments on Base, a Layer 2 built on Ethereum, from the moment money leaves an exchange to the moment it returns to Ethereum, showing what happens on the Layer 2, what happens on Ethereum, and who is involved at every step.

On Ethereum's main network, Ethereum's own validators process every payment directly. On a Layer 2, the same payments feel almost identical to the user, but behind the scenes the work is split in two: a sequencer processes the transactions quickly and cheaply, and Ethereum later records and secures them. Understanding that split is the key to understanding Layer 2s.

The Two Transaction Types

The Scenario

Sara has started using Base because fees are a fraction of a cent.

1. Getting on: Sara moves ETH and USDC onto Base, either straight from her exchange or through the official bridge from Ethereum.
2. Type A: Sara pays her friend Omar 0.1 ETH on Base.
3. Type B: Sara pays Lion City Components 500 USDC on Base for some parts.
4. Getting off: Omar moves his ETH from Base back to Ethereum's main network.

Base, run by Coinbase and built on the open-source OP Stack, is used as the example because it's the most widely used consumer Layer 2. Other optimistic rollups, such as OP Mainnet and Arbitrum, work in a very similar way; zero-knowledge rollups differ mainly in how they prove correctness.

1. The Cast

A Layer 2 payment involves two sets of players: the Layer 2's own operators and contracts, which handle the transaction first, and Ethereum's validators and contracts, which record and secure it afterwards.

Off-Chain and Users

On the Layer 2 (Base)

On Ethereum (Layer 1)

Governance and Oversight

2. The Architecture

Base is a separate blockchain with its own blocks, balances, and fees, but it writes its data and its claims about its state to Ethereum, and Ethereum's contracts decide what can leave Base.

Three ideas make this work:

1. Execution happens on Base. Ethereum's validators never run Sara's individual transactions. Only Base's sequencer and Base nodes do.
2. Data lives on Ethereum. Every Base transaction ends up, compressed, in data posted to Ethereum. Anyone can use that data to rebuild Base from scratch, which is what makes Base a rollup rather than an independent blockchain.
3. Ethereum is the judge. Claims about Base's state are posted to Ethereum and can be challenged there. Ethereum's bridge contracts only release funds when a claim has survived the challenge period.

3. Getting Funds onto Base

Sara can get ETH and USDC onto Base in two main ways: by asking her exchange to send them directly to Base, or by using the official bridge from Ethereum, which involves an Ethereum transaction and a special "deposit" on Base.

Route 1: Withdraw Directly from an Exchange to Base

This is the simplest and most common route.

1. On her licensed exchange, Sara chooses to withdraw ETH and USDC and selects Base as the network. Choosing the wrong network here is one of the most common beginner mistakes.
2. The exchange runs its usual withdrawal checks: two-factor confirmation, address whitelisting, travel-rule information, and risk screening.
3. The exchange sends the funds from its own wallet on Base in an ordinary Base transaction, which goes through the steps described later in this article.
4. The funds arrive within seconds.

The exchange can do this because it keeps a stock of ETH and USDC on Base, topping it up behind the scenes. Sara never touches Ethereum's main network.

Route 2: The Official Bridge from Ethereum

Suppose Sara already holds ETH on Ethereum's main network and wants to move 0.2 ETH to Base herself.

On Ethereum (Layer 1):

1. Sara uses Base's official bridge app and connects her wallet on Ethereum.
2. Her wallet builds an Ethereum transaction calling a deposit function on Base's bridge contract on Ethereum, sending 0.2 ETH with it.
3. This is an ordinary Ethereum transaction and goes through the usual steps: signing, the mempool, builders, a proof of stake proposer, attestations. Sara pays Ethereum gas for it.
4. When it executes, the bridge contract locks Sara's 0.2 ETH on Ethereum and emits an event recording a deposit for Base.

On Base (Layer 2):

5. Every Base node, including the sequencer's, constantly reads Ethereum. Its rollup software spots the deposit event.
6. After waiting a short time for the Ethereum block to settle, the sequencer must include the deposit at the start of a Base block as a special deposited transaction, a transaction type that only Ethereum can trigger.
7. That deposit transaction creates 0.2 ETH on Base in Sara's address. ETH on Base is always matched by ETH locked in the bridge on Ethereum.

The whole process usually takes a few minutes.

Why Deposits Are Guaranteed

The sequencer can't ignore a deposit. Base's rules say every deposit made on Ethereum must appear on Base within a set window, measured in hours. If the sequencer failed to include it, every honest Base node would include it anyway when rebuilding the chain from Ethereum data. This is also Sara's escape hatch, covered later: if the sequencer ever refused her transactions, she could submit them through Ethereum this way.

Bringing USDC Across

For USDC, Sara would avoid the generic bridge, which would give her a bridged version of USDC. Instead, she would use Circle's burn-and-mint system, the Cross-Chain Transfer Protocol (CCTP): USDC is burned on Ethereum and native USDC is minted on Base.

4. Type A, Steps 1 and 2: Building and Signing an ETH Transfer

Sara's wallet builds and signs her 0.1 ETH payment to Omar almost exactly as on Ethereum, with two differences: a different network ID, and a fee made of two parts, one for Base's work and one for Ethereum's storage.

Same Keys, Same Address, Different Network

Sara's address is the same on Base and Ethereum, because it's derived from the same private key. But her balances and her transaction counter (nonce) are completely separate on each network. Her wallet switches to Base and asks a Base RPC provider for her Base balance, her Base nonce, and current Base fees.

The Transaction, Field by Field

The Two-Part Fee

This is the most important difference. Sara pays for two separate things:

The Layer 1 data fee is calculated by a built-in contract on Base, a fee oracle, which tracks Ethereum's current prices. It's charged automatically on top of the gas fields Sara sets, and the wallet adds both parts together on the confirmation screen. Since blob space became cheaper, the Layer 1 data fee for a simple transfer can be smaller than the execution fee; check a recent transaction on basescan.org for current figures.

Signing

Signing works exactly as on Ethereum: the fields are packed, fingerprinted, and signed with Sara's private key. The only difference is the chain ID. Because the signature covers 8453, this transaction is valid only on Base. If someone copied it to Ethereum's main network, every node there would reject it, so a payment on one network can never be replayed on another.

5. Steps 3 and 4: The Sequencer Takes Over

Instead of spreading through a public mempool to a randomly chosen validator, Sara's transaction goes straight to one operator, Base's sequencer, which orders it, executes it, and confirms it within a fraction of a second.

Step 3: Sending to the Sequencer

1. Sara's wallet sends the signed transaction to its Base RPC provider.
2. The RPC node checks it, as on Ethereum: valid signature, chain ID 8453, correct nonce, and enough ETH to cover the value, the execution fee, and the Layer 1 data fee.
3. The node forwards it directly to the sequencer. There's no public mempool gossiped between thousands of nodes. Only the sequencer sees pending transactions.

This has two effects worth discussing. It reduces the chance of public front-running bots spotting Sara's transaction, but it means one company, Coinbase as the sequencer operator, sees and orders every transaction first.

Step 4: Ordering and Building a Base Block

Base produces a new block every 2 seconds, and the sequencer decides what goes in it. Every Base block is built in a fixed order:

Executing Sara's Payment

The sequencer's execution client runs Sara's transaction exactly as Ethereum would: checking the nonce, moving 0.1 ETH from Sara to Omar, and increasing Sara's Base nonce from 0 to 1.

The fee is where Base differs. On Ethereum, the base fee is burned. On Base, it isn't.

The 200-Millisecond Confirmation

Base doesn't make Sara wait the full 2 seconds. Since mid-2025, the sequencer publishes a partial block update called a Flashblock every 200 milliseconds. Sara's transaction appears in the next one.

The sequencer signs each full block and shares it over Base's own peer-to-peer network, where every Base node receives it, executes it, and updates its copy of Base's state. Omar's wallet shows 0.1 ETH, and Sara's shows the payment as confirmed.

What "Confirmed" Means at This Point

This is a soft confirmation: a promise from the sequencer. No validators have voted, no data is on Ethereum yet, and in rare cases, such as a sequencer bug, recent Base blocks can be replaced. For everyday amounts this is very safe, but the stronger guarantees arrive in the next steps.

6. Step 5: Batching and Posting to Ethereum

Every few minutes, Base's batcher gathers the latest Base blocks, including Sara's payment, compresses them, and posts them to Ethereum as a blob transaction, the step that turns a sequencer's promise into a public, permanent record.

What the Batcher Does

1. Collects all the Base blocks produced since its last post, often thousands of transactions from many users.
2. Extracts the transactions, not the resulting balances. Anyone can recalculate the balances by re-running the transactions, so only the transactions need storing.
3. Compresses them heavily. A simple ETH transfer like Sara's shrinks to roughly 100 bytes or less.
4. Packs the compressed data into one or more blobs, the special data containers added to Ethereum in 2024. Each blob holds about 128 kilobytes.
5. Signs and sends an Ethereum transaction carrying those blobs to Base's batch inbox address on Ethereum. Only the batcher address registered in Base's system configuration contract is accepted.

The Batcher's Ethereum Transaction

This is a real Ethereum transaction, a newer type designed to carry blobs, and it goes through the same steps as any other Ethereum transaction. The batcher pays two Ethereum fees:

These costs are what Sara's Layer 1 data fee reimbursed. Spread across thousands of transactions, each user's share is tiny.

How Base Nodes React

Every Base node watches Ethereum for new data in the batch inbox. When the batch containing Sara's block appears in an Ethereum block, Base nodes mark it as safe: it is no longer just the sequencer's word, because the data is now on Ethereum for anyone to check. This typically happens within about 5 to 10 minutes of Sara's payment.

7. Step 6: What Ethereum's Validators Do with the Batch

Ethereum's validators handle the batcher's transaction exactly like any other: a randomly chosen proposer includes it, committees check and vote, and after about two epochs it's final. Crucially, they confirm the data exists, but they never run Sara's payment themselves.

The Proof of Stake Process

What Ethereum's Validators Know, and Don't Know

Finality on Base

Once the Ethereum block containing the batch is finalised, Base nodes mark Sara's Base block as finalised too. Reversing it would now require reversing finalised Ethereum history, which would mean validators losing a huge amount of staked ETH. This typically happens about 15 to 20 minutes after Sara's payment.

Blobs Don't Last Forever, but They Don't Need To

Ethereum's consensus nodes keep blob data for about 18 days, then delete it to save space. The fingerprints stay on Ethereum permanently. Base nodes, block explorers, and archive services copy the data well before then, and 18 days is longer than the window needed for anyone to check it and raise a challenge.

8. Independent Verification: Rebuilding Base from Ethereum

Anyone can run a Base node that ignores the sequencer entirely and rebuilds every Base block from the data on Ethereum, which is what stops the sequencer from quietly rewriting history.

How a Base Node Rebuilds the Chain

A Base node's rollup software runs a process called derivation. It reads Ethereum block by block and gathers three ingredients:

1. Batches posted by the authorised batcher to the batch inbox, which it decompresses back into Base transactions.
2. Deposits recorded by Base's bridge contracts on Ethereum, such as Sara's 0.2 ETH.
3. Ethereum's own block information, used for each Base block's first transaction.

From these, it reconstructs exactly the same Base blocks, in the same order, and its execution client runs every transaction to calculate the same balances, including Omar's 0.1 ETH. If two honest nodes start from the same Ethereum data, they always reach the same result.

Three Levels of Certainty

Every Base node tracks three "heads" of the chain, each more certain than the last:

What If the Sequencer Said One Thing and Posted Another?

Suppose the sequencer showed users one version of a block but posted different data to Ethereum. Base nodes would follow the Ethereum version, and the shared version would be discarded. The sequencer can't make users accept a history different from the one recorded on Ethereum.

This is why exchanges, payment providers, and serious businesses often run their own Base nodes rather than relying only on an RPC provider: they can check everything themselves.

9. Step 7: State Proposals and Fault Proofs

Posting the data proves what transactions happened; but for funds to leave Base, Ethereum also needs a trustworthy claim about the resulting balances, and that claim is made by a proposer and can be challenged by anyone.

Why a Second Step Is Needed

Ethereum's bridge contracts hold all the ETH locked for Base. When someone like Omar wants to withdraw, the bridge needs to know whether Base's state really shows that Omar is entitled to it. Ethereum's validators haven't run Base's transactions, so they can't know on their own.

The Proposal

At regular intervals, roughly every hour, a proposer posts a state root to Base's dispute game contracts on Ethereum: a single fingerprint summarising all of Base's balances and pending withdrawals at a particular Base block. The proposer must lock up a deposit, called a bond, with the claim.

Since October 2024, Base's proof system has been permissionless: anyone can propose and anyone can challenge.

The Challenge: A Fault Proof

Every honest Base node can calculate what the correct state root should be. If a posted root is wrong, any challenger can dispute it:

1. The challenger posts a counter-claim on Ethereum, with its own bond.
2. The two sides play an interactive game, repeatedly splitting the disputed stretch of computation in half, "Do we agree up to the halfway point?", until they disagree about a single step.
3. Ethereum itself then executes that one step using a small virtual machine built into the dispute contracts, and declares the winner.
4. The loser forfeits its bond to the winner.

Why It Takes About Seven Days

A state root settles only if it survives a challenge period of at least three and a half days. Withdrawals then face an additional waiting period, making about seven days in total. The extra time gives the Security Council a window to step in if the proof system itself were found to have a bug. That backstop is why L2BEAT rates Base as Stage 1 rather than Stage 2.

The "Optimistic" Idea, in One Line

Note that none of this delays Sara's and Omar's payment on Base. It only matters when funds move from Base back to Ethereum, as in Section 11.

10. Type B: A USDC Transfer on Base

Sara's 500 USDC payment to Lion City follows the same Layer 2 path (sequencer, batcher, Ethereum), but inside Base it's a call to Circle's USDC contract, so it uses more gas, posts more data, and carries Circle's controls with it.

Native USDC on Base

Circle issues USDC directly on Base, through its own contract at 0x8335...2913. It's built the same way as USDC on Ethereum: a proxy contract with 6 decimals, the same functions, and the same administrative roles. Its supply is separate from Ethereum's, and Circle's reserves back the combined total.

Building, Signing, and Sending

Sara's wallet builds a transaction that goes to the USDC contract on Base, not to Lion City:

The fee is still paid in ETH on Base, so Sara needs a little ETH there even to send USDC, unless she uses a smart wallet whose app sponsors the fee, or a signed authorisation that a payment service submits for her.

Signing and sending to the sequencer work exactly as for Type A.

Inside the Sequencer

The sequencer's execution client runs the USDC contract's code: the proxy looks up the current implementation, the transfer function checks that USDC isn't paused and that neither Sara nor Lion City is blacklisted, confirms Sara has enough, then lowers Sara's balance and raises Lion City's inside the contract's storage, and emits a Transfer event. Lion City's wallet picks up the event within a fraction of a second.

From there, the batch, Ethereum, and fault-proof steps are identical to Type A. Ethereum's validators handle the same kind of blob transaction and never learn that a USDC payment was inside.

Type A and Type B Compared

11. Getting Funds Out of Base

Getting onto Base takes minutes, but getting off through the official bridge takes about a week, because Ethereum must be sure Base's state is correct before releasing locked funds. Most people therefore use faster routes.

Omar's Options for His 0.1 ETH

The Official Withdrawal, Step by Step

Omar chooses the official route, the most trust-minimised option.

1. Start on Base. Omar calls the withdrawal function of Base's built-in bridge contract on Base, sending 0.1 ETH. This is an ordinary Base transaction, processed by the sequencer like any other. The 0.1 ETH is removed from his Base balance, and a withdrawal record is written into a built-in Base contract called the message passer.

2. Wait for a state root. Within about an hour, a proposer posts a state root to Ethereum covering the Base block that contains Omar's withdrawal record.

3. Prove on Ethereum. Omar's wallet or the bridge app submits an Ethereum transaction to Base's bridge contract on Ethereum, with a cryptographic proof showing that his withdrawal record is included in that state root. Omar pays Ethereum gas for this.

4. Wait about seven days. The challenge period runs. If anyone proves the state root wrong, Omar's proof is cancelled and he'd need to prove again against a correct root.

5. Finalise on Ethereum. After the waiting period, Omar sends a second Ethereum transaction. The bridge contract checks that the state root survived unchallenged and releases 0.1 ETH from the locked funds to Omar's address on Ethereum.

Every Ethereum step here goes through Ethereum's full proof of stake process.

How Fast Bridges Skip the Wait

A fast bridge has its own stock of ETH on Ethereum. When Omar sends ETH to the bridge on Base, a relayer sends him the same amount, minus a fee, on Ethereum straight away. The bridge then takes on the week-long wait itself, or simply rebalances its stock between networks. Omar gets speed; the bridge earns a fee and takes the risk. Bridges have been major hacking targets, so trust matters.

Lion City's USDC: No Week-Long Wait

If Lion City wanted its 500 USDC on Ethereum, it would use Circle's burn-and-mint system: USDC is burned on Base, Circle confirms the burn, and native USDC is minted on Ethereum. Because Circle issues USDC on both networks, there's no need to wait for Base's fault-proof period. It usually takes minutes.

12. Following the Money

On a Layer 2, most of each user's fee goes to the network's operator rather than being burned, while the operator in turn pays Ethereum, mostly in burned blob fees, for the security and storage it provides.

Where Sara's Base Fees Go

Who Earns What

Comparing Sara's Costs on Each Layer

This is a long-running debate in Ethereum: Layer 2s make Ethereum cheap to use, but they capture most of the fee revenue themselves, and only a small amount flows back to Ethereum.

13. When the Sequencer Fails or Misbehaves

Because one company runs Base's sequencer, it can go down or, in theory, ignore certain users, but it can't steal funds or rewrite history recorded on Ethereum, and users have an escape hatch through Ethereum itself.

What the Sequencer Can and Can't Do

Outages

Base has had block-production stalls caused by sequencer problems, lasting tens of minutes. During an outage, no new Base transactions are processed. Funds remain safe, but users can't move them on Base until the sequencer recovers, which matters for anyone who needs to act quickly, for example during a market crash.

The Escape Hatch: Forced Inclusion Through Ethereum

If the sequencer ignored Sara, she could go around it:

1. Sara sends an Ethereum transaction to Base's bridge contract on Ethereum containing the Base transaction she wants to make, whether a payment or a withdrawal.
2. Like the deposit in Section 3, it's recorded on Ethereum.
3. Base's rules require it to appear on Base within a set window, measured in hours. If the sequencer refused, honest Base nodes would include it anyway when rebuilding Base from Ethereum.

It's slower and costs Ethereum gas, but it means the sequencer can delay users, not trap them.

Upgrade and Governance Risk

The deeper trust question isn't the sequencer but who can change Base's contracts on Ethereum. Base's multisig can upgrade the bridge and dispute contracts and change the sequencer, and a Security Council can act in emergencies. Users rely on these groups not to misuse those powers. This is why L2BEAT rates Base Stage 1: users are meaningfully protected by fault proofs, but not yet fully independent of the operators.

14. Timeline, Confirmation Levels, and What Can Go Wrong

On Base, a payment is visible in a fraction of a second, backed by Ethereum within minutes, final in about a quarter of an hour, and withdrawable to Ethereum through the official route in about a week.

The Timeline for Sara's Payments

The Same Journey on Both Layers

What Can Go Wrong

Key Takeaways