Sequencer

What the sequencer is

The sequencer is EDMA’s traffic officer: it orders L2 transactions, builds blocks, and posts batches and state roots to Ethereum. It does not decide who gets paid or what is valid at the application level—that is enforced by PoV and EMTs. If a transaction tries to release money without passing a gate, it simply fails at the contract: No EMT, no funds.

In short: the sequencer controls ordering; PoV controls admissibility.

What the sequencer actually does

A few lines to set context, then the parts ops will feel every day.

• Ordering & block production: Collect transactions (RFQs, awards, funding, proof submits, EMT mints, releases), order them, and produce L2 blocks (~2s target).

• Batching to Ethereum: Post blobs/state roots on a steady cadence (~2–10 min under load) for data availability and L1 anchoring.

• Inclusion rules: Respect forced-inclusion and anti-censorship lists (see below); keep a fair queue so proof→release paths aren’t starved.

• Gas orchestration: Work with the Paymaster so users don’t need ETH; gas remains tiny and pass-through in EDM/EDSD.

• Priority paths: Give proof/EMT→release a light, documented boost over non-critical calls so money flows immediately after gates pass.

What it cannot do: bypass PoV, mint EMTs, move Locked EDSD early, skip burns, or accept duplicate evidence. Those are blocked in contracts.

Fairness & MEV policy

We aren’t building a trading casino; we’re settling real-world cashflows. Our policy is simple:

• No private lanes for settlement: Everyone uses the same public endpoints; we do not sell “priority inclusion” for EMT→release.

• FIFO + proof-aware boost: Within a lane, the queue is first-come, first-served; transactions that finalize an already-verified milestone receive a small, published priority so cash is not held back by noise.

• No extractor side-channels: The sequencer or its operators may not front-run, insert, or reorder for economic gain. Violations are grounds for rotation and slashing (once multi-operator is live).

All ordering and priority logic is visible in the Explorer (block timestamp, tx ordering, and which path received boost).

Censorship resistance & forced inclusion

We assume bad days and design for them.

• L1 inbox (forced inclusion): If a sequencer censors a transaction, anyone can push it through the Ethereum inbox; the next batch must include it.

• Permissionless exit: Users can force-withdraw EDM/EDSD to L1 after the challenge window even if the sequencer is offline.

• Inclusion lists: Governance can publish bounded inclusion lists for critical flows (e.g., EMT mint, release, forced withdrawal) so these calls cannot be starved.

Liveness, failover, and maintenance

• Active–passive failover: Hot standby with deterministic state; automatic promotion on health-check failure; post-mortems are public.

• SLA targets: Block production ~2s, EMT→release latency <5s p50, batch to L1 ~2–10 min.

• Maintenance windows: Announced in advance, with forced-inclusion available throughout.

• Observation & alarms: We publish realtime status (blocks, batch lag, inbox depth); flags include block_delay, batch_lag, censor_alert (triggered when an inbox push is used).

Data availability & evidence flow

• To L1 blobs/state: PoV hashes, EMT ids, release deltas (Locked→Unlocked EDSD), fee lines, burn hashes.

• Off-chain vaults: COAs, BL + seal photos, temp logs, inspection PDFs, customs EDI. The chain holds their hashes.

• Explorer: Human pages show who attested, when it paid, and the burn transaction—no raw docs in public payloads.

How “proof → release” stays snappy

There are two clocks: business and chain. We make the business clock feel instant, without cheating.

• When attestors finish, a proof submit hits the sequencer.

• The PoV Gate checks the checklist; if it passes, the EMT mints in the same block or the next.

• The release call flips Locked EDSD → Unlocked EDSD and posts the burn; receipts are returned immediately.

• The batch lands on L1 a few minutes later; you don’t wait for that to move trucks or record cash.

Security boundaries

• Application brakes: Even perfect ordering can’t move money early: PoV/One-Claim/EMT guard rails stop it.

• Chain brakes: Batches are in blobs on Ethereum; anyone can reconstruct state.

• Exit brakes: Force-inclusion and permissionless exit keep user funds retrievable in worst-case scenarios.

• Timelocked upgrades: Any change to sequencer software affecting ordering or inclusion has a 72h timelock with a public diff.

Roadmap to decentralization

• Phase 0 (today): single operator with hot standby; forced-inclusion + status pages; governance oversight.

• Phase 1: multi-operator rotation with on-chain randomness; shared signing for batch roots; public audit trails for rotations.

• Phase 2: proposer/builder separation for L2 (PBS-style), so builders compete on block construction while proposers ensure fairness.

• Phase 3: open sequencer set or shared-sequencer integration, with slashing for censorship and mis-ordering.

Throughout all phases, PoV/EMT/Locked-EDSD rules are unchanged—decentralization shouldn’t change how money earns the green tick.

What teams need to remember

You treat L2 receipts as operational truth; the sequencer’s job is to keep those arriving in seconds and to anchor them to Ethereum in minutes. If something stalls, forced-inclusion and exits keep you moving. And no matter who runs the box, the rule on this rail never blinks: no EMT, no funds.