BDR-001: On-Chain Finality: Use Ethereum-Finalized Blocks
| Status | Proposed |
| Date | 2026-04-10 |
Context
The backoffice reads on-chain state (supply, mint/burn history) and makes operational decisions based on it — reserve validation, supply publication, and eventually issuance/redemption settlement. Every one of those flows needs a clear answer to: when is a transaction final enough to act on?
Base is an OP Stack optimistic rollup on Ethereum. Transactions pass through several finality stages before they become irreversible. Choosing the wrong threshold introduces either double-spend risk (too early) or unnecessary latency (too late). Today, each component makes its own ad-hoc assumption. We need a single documented definition.
Base finality levels
| JSON-RPC tag | Guarantee | Typical latency |
|---|---|---|
unsafe | Sequencer inclusion only — no DA or L1 confirmation. Can be reordered or dropped. | ~2 s |
safe | Block data posted to Ethereum (DA). Reorg requires an L1 reorg before finalization. | 5 – 10 min |
finalized | Corresponding L1 epoch reached Ethereum Casper FFG finality. Reorg requires compromising Ethereum's economic security. | 13 – 30 min |
Industry reference points
Circle (USDC) is the only major stablecoin issuer with documented L2 finality handling. Their API defines two states: CONFIRMED (sequencer inclusion / soft finality) and COMPLETED (L1 finality), explicitly noting that CONFIRMED on L2s means trusting the sequencer prior to Ethereum finality. CCTP cross-chain transfers take 13–19 min, aligning with Ethereum finality. (Circle — Blockchain Confirmations)
Among exchanges, OKX explicitly documents that L2 deposits (Base, Optimism, Arbitrum) are completed based on L1 status and block confirmations — not L2 block count alone. (OKX — Deposit Completion Times)
Regulatory context
MiCA does not prescribe a specific number of confirmations or finality model. It requires that issuers maintain adequate operational risk management (Art. 45) and that settlement is "firm and irrevocable" without specifying a technical threshold.
The EU Settlement Finality Directive is being adapted for DLT systems via the DLT Pilot Regime (Regulation 2022/858). No final standard for blockchain finality has been published.
Proposal
The backoffice treats all on-chain data as unconfirmed until it reaches finalized status (Ethereum Casper FFG finality, 13 – 30 min latency). A single finality threshold keeps the system simple and avoids ambiguity between components.
This applies to mint/burn event processing, reserve validation snapshots, supply publication, and any action that produces an externally visible commitment. Mints and burns are supply-changing operations — acting on a non-final event would corrupt supply tracking if the block reverts. Using finalized adds no user-facing latency since these are internal processing steps.
During an Ethereum finality stall the system pauses processing until finality resumes. Operators should treat this as expected behaviour, not a bug.