Sequencer
What can go wrong (and what can’t)
The sequencer orders L2 transactions, builds blocks, and posts batches/blobs to Ethereum. It can delay or censor ordering for a time; it cannot make the application break its law. Even on a bad day, the following remain true in contracts: No EMT, no funds · One-Claim uniqueness · Must-fund before shipping · Locked EDSD → Unlocked EDSD only on proof · 50% of each protocol fee burns in EDM at release/settlement. Mis-ordering can’t mint an EMT, flip funds early, bypass One-Claim, or skip burns.
Risk surface (plain language)
Censorship / starvation: A valid tx (e.g., proof submit, release) is held back or not included promptly.
Downtime / degraded liveness: Blocks slow or stall; batch posting to L1 is delayed.
Mis-ordering / MEV-like behavior: Non-critical txs are reordered for advantage. (Our policy forbids extractor lanes for settlement; see “Fairness.”)
Compromise / misconfiguration: Keys or software are compromised; an upgrade regresses inclusion logic.
These affect latency and user experience. They do not change admissibility (PoV/EMT), cash control (Locked/Unlocked EDSD), or final economics (burns, caps).
Guardrails already in place
The rollup is Optimistic with EIP-4844 blobs. If the sequencer behaves, you get seconds-level operational finality and minutes-level anchoring to L1. If it doesn’t, the system has brakes and exits.
Forced inclusion (L1 inbox): Anyone can push a stuck tx (proof, EMT, release, forced exit) through the L1 inbox; the next batch must include it.
Permissionless exits: Users can withdraw EDM/EDSD to L1 after the challenge window even if the sequencer is offline.
Priority for proof→release: We publish a small, documented boost for txs that finalize already-verified milestones so money isn’t starved by noise. No private lanes.
Active–passive failover: Hot standby with health checks; automatic promotion on failure; public status page.
Timelocked upgrades: Any change to ordering/inclusion logic is queued behind a 72h timelock with public diffs.
Application brakes: Even perfect ordering can’t move cash early: Gate PASS + EMT + One-Claim + must-fund are hard checks in contracts.
Fairness & MEV policy
No sold “priority.” Settlement paths use public endpoints; we don’t sell inclusion.
FIFO inside a lane, proof-aware boost for EMT→release. The queue is first-come first-served; transactions that finalize a passed milestone get a lightweight, published priority.
No extractor side-channels. Operators may not reorder for economic gain. Violations are cause for rotation/slashing once multi-operator is live.
Explorer shows block timestamps, tx order, and when the boost path was used.
Detection → response → recovery
Detection:
Block delay (target ≤2s, alert >5s), batch lag (alert >10 min), inbox depth (forced-inclusion used), and censor alerts (stuck proof/release beyond SLO).
Webhooks:
infra.block_delay,infra.batch_lag,infra.inbox_forced_inclusion.
Response:
Marketplaces retry with idempotency keys; if flagged “censored,” offer L1 forced inclusion path in UI/API.
Sequencer ops fail over to the hot standby; investigate host / network / config; publish incident banner and ETA.
Governance/Sec Council can apply a module-scoped pause (≤72h) for opening new gates if software needs a hotfix; already-minted EMTs and releases resume automatically when healthy.
Recovery:
Resume normal inclusion; post-mortem published; any forced-inclusion txs show on Explorer with a badge. Nothing in application state was allowed to leap ahead of proof.
Business impact matrix (readable at 2am)
Failure mode
What you feel
What doesn’t change
What to do
Censorship / starvation
Proof/Release tx waits
PoV law, One-Claim, Locked/Unlocked, 50% burn
Use forced inclusion; watch status page; receipts appear once included
Downtime
Blocks stall; batches delayed
Funds remain Locked; no early release or burn
Failover auto-promotes; ops banner shows ETA; no money moves until healthy
Mis-ordering / MEV
Non-critical txs reorder
EMT/settlement ordering is proof-aware; no private lanes
Report; Explorer shows ordering; policy breach triggers rotation
Bad upgrade
Unexpected rejects/latency
Timelock prevented instant harm; brakes intact
Roll back via timelock; module pause if needed; public diff
KPIs & SLOs (so you know we’re inside the lines)
Block time (p50 / p95): ≤ 2s / 4s
EMT→release latency (p50 / p95): ≤ 5s / 15s
Batch to L1 (median): 2–10 min under load
Forced inclusion resolution: < 30 min to land in next batch
Censor false-positive rate: < 0.5% of txs flagged
Availability: ≥ 99.9% monthly
These are posted on the status page; missed SLOs appear with root cause and fix.
Operator checklist (balanced prose + bullets)
If Release is stuck and the banner shows PENDING_FUNDS, fund first; the Gate won’t pass without Locked EDSD.
If Block delay/batch lag alarms and you must clear a milestone, hit the forced-inclusion option (UI/API); plan exits around the challenge window.
Do not resubmit without an Idempotency-Key; duplicates are ignored, but retries without keys can clog queues.
Reconcile once receipts arrive: fee line, EDM burn hash, and Locked/Unlocked totals should match the ledger.
For bridges, prefer to retire on EDMA; if retiring elsewhere, ensure a finality proof returns before you rely on it.
Governance & roadmap (how we reduce this risk over time)
Multi-operator rotation with on-chain randomness; slashing for mis-ordering/censorship.
PBS-style proposer/builder separation for L2 once mature.
Inclusion lists for critical calls and auto-fall-back to L1 inbox on extended delay.
Regular drills (failover, forced-inclusion, exit) with public success metrics.
Foundations stay outside governance: no vote can release money early, reuse evidence, or reduce burns.
Plain recap
Last updated