Ethereum
Hyperliquid
Solana
Arbitrum
BNB Smart Chain
Base
Polygon
TRON
Sui
MegaETH
Tempo
Monad
Avalanche
Aptos
Ronin
zkSync Era
Optimism
Sonic
Unichain
Fantom
Gnosis Chain
Refer and earn
Discord
Telegram
X (Twitter)Base transaction lifecycle: sequencer, finality, and RPC
TL;DR
Base transactions move through five confirmation stages — from a 200ms sequencer preconfirmation to full Ethereum finality at ~15 minutes. Speed is the product, but speed isn’t finality.
Most bugs on Base trace to one mistake: reading latest (2s, reversible) where the code needed safe (5–10 min, batch on Ethereum) or finalized (15–20 min, validators signed off). Withdrawals back to Ethereum wait an additional 7 days for fraud challenges.
Pick the confirmation tier whose failure mode you can live with.
How Base got here
By 2022, Coinbase had a problem that every fee spike on Ethereum made worse. Their users wanted to swap, mint, and move money on-chain, but L1 gas was eating the experience alive. The obvious fix was a chain of their own. The unobvious part was how to get there without spending three years writing a rollup from scratch.
So they didn’t. They picked up the OP Stack, already audited, already EVM-compatible, already running Optimism in production, and used it as the foundation for Base. The trade-off was deliberate: ship something real in months, accept that the sequencer — the node that receives transactions, orders them, and builds blocks — would be a single Coinbase-run node on day one, and lean on Ethereum for the parts that actually need to be trustless.
Base was announced in February 2023 and went live on mainnet on August 9, 2023. Within a year it was the busiest Ethereum Layer 2 by daily transactions. No native token, no separate gas asset, no governance theater. Just a chain that settles to Ethereum and gets out of the way.
Two decisions from that origin still shape every Base transaction today:
- One sequencer, run by Coinbase. Speed over decentralization. Your transaction has one way in.
- A 7-day withdrawal window, from optimistic rollup design. Deposits feel instant. Exits feel slow.
One more was added later, once the UX gap became obvious:
- Flashblocks, shipped mid-2025, cut the confirmation wait from 2 seconds to 200ms without changing the underlying architecture.
The path of a Base transaction
1. Submission via RPC
You sign a transaction in a wallet or backend, send it to a Base RPC endpoint, and it lands in the sequencer’s mempool. Base has one sequencer (Coinbase), so unlike Ethereum there’s no public mempool gossip. The sequencer has no public mempool, so an RPC endpoint is the only way in. Slower endpoints mean later inclusion.
2. Flashblocks: a 200ms preconfirmation
Every 200ms, Base’s sequencer emits a partial block update called a Flashblock. Flashblocks went live on Base mainnet in July 2025 and were built by Flashbots as an add-on to the OP Stack. They give your UI something to render long before the next 2-second block is finalized.
A Flashblock is a preconfirmation. Coinbase has accepted the transaction but hasn’t finalized a full block. Treat Flashblock state as a hint for UX, like showing a balance change or animating a swap result. Reading it needs a Flashblocks-aware endpoint that subscribes to the stream over WebSocket. Chainstack offers one at Flashblocks on Base via Chainstack RPC.
3. Sequencer block: the soft confirmation
Every 2 seconds, the sequencer finalizes a full block and your transaction gets a receipt. This is what most code calls “confirmed” today, and what eth_blockNumber returns by default. You can read its state with the latest block tag.
At the latest stage, the only entity that has committed to this block is Coinbase’s sequencer. The data hasn’t been posted to Ethereum yet — it lives entirely on Base’s infrastructure. If the sequencer resets or rolls back, these blocks can be rewritten. Transactions you saw in a latest block could end up in a different position, or not included at all. This is what a sequencer reorg looks like: not a malicious attack, usually just a restart or a bug, but the result is the same — state you read from latest no longer matches the chain.
In normal operation this rarely happens. But “rarely” is the wrong frame when the cost of being wrong is money. If you’re displaying a balance in a UI, a brief flicker from a reorg is annoying but recoverable. If you’re crediting a user deposit, releasing held funds, or recording a payment as settled, a reorg means you acted on state that no longer exists. The safe block tag exists precisely for this: it only advances once the batch has landed on Ethereum, removing the sequencer’s ability to reorder it.
4. Batch posted to L1 and the safe tier
Every few minutes, Base’s batcher service compresses a span of recent blocks and posts the data to Ethereum. Since EIP-4844 (an Ethereum upgrade from March 2024), Base posts these batches as blob data rather than calldata. Blobs are a cheaper way to attach large chunks of data to an Ethereum transaction — Ethereum nodes store them temporarily and delete the raw data after around 18 days. But before deletion, a cryptographic fingerprint of each blob is permanently recorded on-chain, which is enough to prove the data existed and was committed to. The sequencer also posts a state root for those blocks via the proposer contract.
What gets posted is enough to reconstruct the state. If the Base sequencer disappeared tomorrow, anyone could replay the L1 data and rebuild the chain.
Once the batch lands in an Ethereum block, Base nodes mark the corresponding L2 blocks as safe. You can read that state with the safe block tag in any standard JSON-RPC call. Coinbase can no longer reorder or drop these transactions — doing so would require reorging Ethereum itself, which is theoretically possible but extremely rare in practice.
5. L1 finality and the finalized tier
About two Ethereum epochs (~13 minutes, depending on slot position) after the L1 block holding the batch is included, that block gets finalized by Ethereum’s validator set. Base nodes then mark the corresponding L2 blocks as finalized.
This is a stronger guarantee than safe. At the safe stage, an Ethereum reorg — however unlikely — could still undo the block. Once finalized, Ethereum validators have collectively signed off on that block being permanent. Reversing it would require a catastrophic consensus failure: corrupting or slashing over a third of all Ethereum validators simultaneously. In practice, this is treated as impossible.
6. The 7-day fault-proof window
Withdrawals from Base to Ethereum wait 7 days. Base shipped permissionless fault proofs on October 30, 2024, which means anyone can challenge a fraudulent state root during this window. If a challenge is submitted, smart contracts on Ethereum run the verification and act as the final judge — if the fraud proof holds, the bad state root gets rejected. Deposits from L1 to L2 don’t wait. Only exits do.
End users feel this part of the lifecycle the most. A deposit feels instant, a withdrawal feels broken. UX should communicate the delay up front.
Why this matters for builders
Treat Base like Ethereum and you’ll ship bugs. Apps that credit users on latest lose money when the sequencer rolls back. Withdrawal flows surprise users when they discover the 7-day exit. Indexers miss reorgs because Base’s WebSocket stream doesn’t behave the way Ethereum’s does. Each has the same cause: the wrong confirmation tier for what the code was doing.
Confirmation tiers cheat sheet
| Tier | Time | What it means | Use it for |
|---|---|---|---|
| Flashblock | 200ms | Sequencer preconf, no block yet | UI feedback, gameplay |
| latest | 2s | Sequencer block, no L1 data | Display balances |
| safe | ~5–10 min | Batch on Ethereum | Payments, swaps |
| finalized | ~15–20 min | L1 block finalized | Bridge accounting, treasury |
The general rule: pick the lowest tier whose failure mode you can absorb. A reverted UI animation is fine. A reverted USDC transfer is not.
RPC design implications
Your app talks to Base through an RPC endpoint. Every query you make, whether checking a balance, reading a log, or fetching a transaction receipt, hits that node and gets answered based on whatever state the node has at that moment.
The problem is that “what state the node has” depends on which confirmation tier you’re reading from. And most RPC methods let you choose — they just default to the most recent tier, which is also the least reliable.
Pick the right block tag
When you call methods like eth_getBalance, eth_call, eth_getLogs, or eth_getTransactionReceipt, you can pass a block tag alongside your request to tell the node which confirmation tier to read from: latest, safe, or finalized — the same tiers covered above.
Most RPC libraries default to latest if you don’t specify, which is wrong for releasing held funds, or recording a settlement. Those actions need safe at minimum.
The staleness is the cost: reading at safe means your answer is ~5–10 minutes behind the tip of the chain. For most financial logic, that trade is worth it. For real-time UI updates, it isn’t. The key is to be intentional — know which tag you’re using and why.
A common mistake is mixing tiers without realizing it. An indexer might fetch the latest events with latest for speed, then key the database records by block hash. If the sequencer later reorgs those blocks, the hashes in your database no longer exist on the canonical chain. You read at one tier, stored at another, and the mismatch corrupts your data.
Handle sequencer reorgs
A sequencer reorg happens when the sequencer discards blocks it already broadcast and replaces them with a different set. This isn’t an attack — it usually happens when the sequencer restarts or fixes a bug. But the effect on your code is the same: blocks you saw as latest might disappear, and their transactions might reappear at a different block height or not at all.
If your indexer reads at latest, there are two reliable signals to watch for reorgs:
- removed: true on log subscriptions. When you subscribe to logs via eth_subscribe(“logs”, …), the node emits removed events for any log that belonged to a reorged-out block. This is the standard JSON-RPC mechanism and it works reliably — as long as your WebSocket connection stays live. If the connection drops during a reorg, you will miss the removed events and wake up with stale state. On reconnect, re-fetch logs from the last block hash you trust rather than resuming from the latest block number.
- Block hash conflicts on newHeads. Subscribe to eth_subscribe(“newHeads”) and track the hash for each block height you process. If a new head arrives at a height you’ve already seen with a different hash — that’s a reorg. Roll back everything you stored for that height and above, then reprocess from the new canonical block.
These two signals together cover the reorg surface.
Conclusion
Base moves fast by design. The sequencer takes your transaction in 200ms, a block lands in 2 seconds, and the chain handles more daily transactions than any other Ethereum L2. That speed is the product, and it works — until you write code that assumes speed means finality.
Every stage in the lifecycle exists because something can still go wrong at the stage before it. The sequencer can roll back. The batch might not land on L1 immediately. Even an Ethereum block can be reorged before validators sign off. Each confirmation tier is a reduction in that risk, not an elimination of it — until finalized, where the remaining risk is effectively zero for any practical purpose.
The bugs that burn builders on Base usually trace back to one misstep: using latest in a place that needed safe, or skipping reorg handling because it “never happens in practice.” The fix is the same in every case — match the confirmation tier to the consequence.
Getting that match right also depends on the endpoint behind it. Chainstack’s Base RPC supports every tier covered here, plus a dedicated Flashblocks-aware WebSocket for 200ms preconfirmations — so you can match the right guarantee to each call without juggling providers.
FAQ
It depends on what you mean by “finalize.” A Base transaction moves through several stages: the sequencer accepts it within 200ms (via Flashblocks), includes it in a block within 2 seconds, posts it to Ethereum in roughly 5–10 minutes, and Ethereum finalizes that block after about 15–20 minutes. For most financial applications, the practical answer is 15–20 minutes — that’s when reversal becomes effectively impossible. For UI feedback, 2 seconds is usually enough. For payments and settlements, the 5–10 minute safe tier is the right cutoff.
These are block tags you pass to JSON-RPC methods to control which confirmation tier your query reads from. latest returns the most recent sequencer block — fast (2s) but reversible if the sequencer reorgs. safe only advances once Base’s batch has been posted to Ethereum, removing the sequencer’s ability to reorder those transactions — this takes roughly 5–10 minutes. finalized goes one step further: it only advances after Ethereum’s validators have signed off on the block, making reversal catastrophically unlikely — around 15–20 minutes. Most RPC libraries default to latest. For anything involving money movement, you should be explicit about which tag you need.
Flashblocks are 200ms preconfirmations emitted by Base’s sequencer before a full 2-second block is produced. Built by Flashbots as an add-on to the OP Stack, they went live on Base mainnet in July 2025. When the sequencer includes your transaction in a Flashblock, it has accepted the transaction but hasn’t finalized the block yet — so Flashblock state is a strong hint, not a guarantee. The main use case is UI responsiveness: showing a balance update or animating a swap result without waiting 2 seconds. Reading Flashblock state requires a WebSocket connection to a Flashblocks-aware endpoint.
Yes. Base is an Ethereum Layer 2 built on the OP Stack, the same open-source framework that powers Optimism. It processes transactions off Ethereum mainnet to keep fees low, then periodically posts compressed transaction data back to Ethereum as proof of what happened. Ethereum acts as the settlement layer — it stores the data needed to reconstruct Base’s state and enforces the rules via fault proofs. Base launched on mainnet in August 2023 and is operated by Coinbase, though the underlying protocol settles trustlessly to Ethereum.
Additional resources
