Chain mechanics for operations

In one line

“Included in a block” and “final” are different events about 13 minutes apart on Ethereum. Everything an operator reads comes through an RPC node that can lag or lie, and everything an operator sends is public before it lands.

Why it exists

A database commit is one event: after it returns, the row is there. A blockchain has no single machine that decides, so it reaches agreement in stages.

Proof of work (Ethereum until 2022) never gave a hard guarantee. A block got safer with every block built on top of it, and services waited for “N confirmations”.
Proof of stake (Ethereum since September 2022) added real finality. Validators vote on checkpoints, and once two thirds of the stake has voted, the block cannot be reverted without destroying a very large amount of staked ETH.
The mempool exists because transactions must reach whoever builds the next block. It is a public gossip network, so pending transactions are visible to everyone. Searchers and builders make money from ordering them: MEV, maximal extractable value.
RPC providers exist because running a node is work. Most services read the chain through someone else’s node, which makes that node a trust boundary.
L2 rollups move execution to a faster chain run by a sequencer and post batches to Ethereum. That adds a new failure: the sequencer can stop.

How it works

Finality

Time is cut into slots of 12 seconds. Each slot has one proposer, which may produce one block.
32 slots make an epoch: 6.4 minutes.
Validators vote on the first block of each epoch as a checkpoint. A checkpoint with votes from two thirds of the stake is justified.
When the next checkpoint is justified on top of it, the earlier one is finalised. In normal operation that is about two epochs after the block: roughly 12.8 minutes.
Before finality, the chain can reorganise: a block is replaced by a competing one, and its transactions go back to the mempool or vanish.

Drawn to scale. "Included in a block" and "final" are different events: for about 13 minutes a deposit can disappear in a reorg.

Rule for crediting deposits: credit on finalised, or on N confirmations scaled to the amount.

Nonces

Each sender has a strictly increasing nonce. A transaction with nonce 7 cannot land before nonce 6.

Stuck transaction: resend with the same nonce and a higher fee to replace it, or send a zero-value transaction to yourself with that nonce to cancel it.
One owner: one signer service owns nonce allocation for each hot address. Parallel senders cause gaps and double-sends.

Mempool and MEV

The public mempool is visible to searchers. They place their own transactions before and after yours (a sandwich) or copy a profitable one. Send liquidations and large trades through private relays, and always set a slippage limit and a deadline.

Oracles

From Chainlink latestRoundData, check all of these before using the price:

answer > 0
updatedAt is within the feed’s heartbeat
the decimals are what the code assumes
on an L2, the sequencer is up

Fall back or pause on a stale price.

L2s

Withdrawals. Optimistic rollups hold withdrawals to L1 for a challenge period of about 7 days, so fraud proofs can be submitted.
Sequencer downtime. While the sequencer is down, prices on the L2 stop updating and users cannot react. Check Chainlink’s sequencer uptime feed before trusting prices or allowing liquidations: the feed’s answer is 0 when the sequencer is up and 1 when it is down. After it comes back, wait for a grace period before liquidating.

RPC trust

An RPC can lie or lag. Before a money decision, compare two or more providers plus your own node on block hash and balances. KelpDAO (April 2026) is the case: a verifier’s RPC nodes were poisoned, and it attested a message that never existed. See Key and signer attacks.

Compare

How settled is a transaction

These are also the block tags that the JSON-RPC API accepts.

State (block tag)	Meaning	Typical delay on Ethereum	Can it be undone	Use it for
`pending`	In the mempool, not in a block	0	Yes, it may never land	Nonce allocation, UI feedback
`latest`	In the newest block this node knows	Up to 12 s	Yes, by a reorg	Display, small amounts
`safe`	In a justified block	Minutes	Only with a large part of the stake misbehaving	Medium amounts
`finalized`	In a finalised block	About 12.8 min	Not without burning at least a third of all staked ETH	Large deposits, bridge releases

Ways to submit a transaction

Path	Who sees it before inclusion	Protects against	Cost
Public mempool	Everyone	Nothing	None; fastest propagation
Private relay (Flashbots Protect, MEV Blocker)	The relay and the builders it forwards to	Sandwiches and copy-cat front-running	You trust the relay; inclusion can be slower
Public mempool with slippage limit and deadline	Everyone	Bounded loss per trade, no stale execution	The trade can still be sandwiched up to the limit
Commit-reveal	Everyone sees a commitment, not the content	Copying and front-running of the content	Two transactions and a delay

Where to read the chain from

Setup	What you trust	Fails when	Cost
One RPC provider	That provider completely	It lags, rate-limits or returns wrong data	Lowest
Two or more providers, compared	That they do not fail the same way	They share upstream infrastructure	More requests, comparison logic
Own node	Your own operations	It falls behind the head or its disk fills	Hardware and on-call
Own node plus two providers, compared on block hash	No single view	All three are wrong together	Highest; the right default for money decisions

Rollup types

Type	How L1 knows the L2 state is correct	Withdrawal to L1	Examples
Optimistic rollup	Assumed correct unless someone proves fraud in the challenge window	About 7 days	Arbitrum, Optimism, Base
ZK rollup	A validity proof is verified on L1	After the proof is verified	See the ethereum.org page in Sources
Third-party bridge instead of the canonical one	The bridge’s own verifiers	Minutes	See Bridges

What breaks

The commands use cast from Foundry. $RPC_A and $RPC_B are two different providers.

Symptom	Cause	Check
A credited deposit disappeared	Credited before finality, then a reorg	`cast block finalized -f number --rpc-url $RPC_A` and compare with the deposit’s block number
Two systems disagree about a balance	One RPC lags or lies	`cast block latest -f hash --rpc-url $RPC_A` against the same call on `$RPC_B`; then compare `cast block-number` on both
Transactions from a hot wallet stop landing	Nonce gap or a stuck low-fee transaction	`cast nonce $ADDR --block latest` against `cast nonce $ADDR --block pending`
Two transactions went out with the same nonce	Two senders share one address	One signer service per address owns the nonce
A liquidation or trade got a much worse price than quoted	Sandwiched in the public mempool	Check the two transactions around yours in the block; switch to a private relay
Liquidations fired on an old price	Stale oracle	`cast call $FEED "latestRoundData()(uint80,int256,uint256,uint256,uint80)"` and compare `updatedAt` with the current time
Mass liquidations right after an L2 outage	No sequencer check or no grace period	Read the sequencer uptime feed the same way: `answer` 1 means down, `startedAt` is when the status changed
Withdrawal from an optimistic rollup “takes a week”	The challenge period	Expected; plan liquidity around it

The raw JSON-RPC call for the finalised block, without Foundry:

curl -s -X POST -H 'content-type: application/json' \
  --data '{"jsonrpc":"2.0","id":1,"method":"eth_getBlockByNumber","params":["finalized",false]}' \
  "$RPC_A"

Monitor head lag (the difference between your node’s block number and a provider’s) and alert on oracle heartbeat misses.

Keywords

finality, finalised, justified, safe head, slot, epoch, checkpoint, proof of stake, Gasper, Casper FFG, reorg, confirmations, block tag, latest, safe, finalized, pending, nonce, nonce gap, replacement transaction, stuck transaction, mempool, MEV, searcher, block builder, sandwich attack, front-running, private relay, Flashbots Protect, MEV Blocker, slippage, deadline, commit-reveal, oracle, Chainlink, latestRoundData, updatedAt, heartbeat, staleness, sequencer, sequencer uptime feed, grace period, optimistic rollup, challenge period, fraud proof, ZK rollup, validity proof, RPC, RPC provider, RPC poisoning, head lag, eth_getBlockByNumber, cast block.