Rollup type
What we run today
EDMA operates as an Optimistic Rollup anchored to Ethereum. We chose this because it’s EVM-equivalent, cheap with EIP-4844 blobs, and production-proven for the traffic patterns our rail needs—many small proofs, frequent releases, simple state updates. Blocks confirm in seconds on L2; batches and state roots post to L1 on a steady cadence.
In one sentence: Ethereum secures ordering and data availability; PoV secures admissibility—No EMT, no funds.
How finality works
Think in two layers of “done”:
Operational finality (L2): what your team feels. A gate passes, the EMT mints, Locked EDSD → Unlocked EDSD, and the receipt appears—usually within a few seconds. This is enough to move trucks, clear a stage, or release a token settlement.
Ethereum finality (L1): the batch with your transaction is posted to Ethereum. After the challenge window (governed, e.g., 7 days), the batch is economically final on L1. Withdrawals/bridges to L1 respect this window; day-to-day ops do not need to wait for it.
Business runs on the L2 timeline; cross-chain withdrawals and permissionless exits respect the L1 window.
Why Optimistic
A short rationale, then the knobs you can care about.
Optimistic gives us the lowest friction path to what matters for RWA: fast confirmations, low fees, mature tooling, and hard guarantees on data availability. We can keep milestones snappy without inventing new cryptography—and we inherit Ethereum’s security.
EVM-equivalence: use standard Solidity, tooling, audits.
Blobs (EIP-4844): cheap, durable data availability for evidence/event logs.
Forced inclusion: an L1 inbox ensures anyone can push a tx into a batch if a sequencer censors.
Failover: active-passive sequencer with health checks; emergency mode falls back to L1 forced inclusion.
What the fault-proof story is
We run with fault-proof ready infrastructure and a challenge window on L1 roots. As general-purpose fault proofs harden across the ecosystem, we enable them with a timelocked upgrade—no app changes needed. Until then, your operational safety comes from three pillars:
PoV at the app layer (admissibility): milestones pay only when checklists pass.
DA on Ethereum (availability): every batch is published in blobs; proofs can be reconstructed from L1.
Permissionless exits (escapes): bridge contracts let you force-withdraw even if the sequencer goes dark.
Where zk fits
Validity proofs will arrive where they add real value without slowing day-to-day trade:
ZK attest bundles: for One-Claim and schema integrity (batch-verify large sets).
ZK privacy wrappers: for sensitive fields (prove “shelf-life ≥ X” or “temp in range” without revealing raw files).
ZK rollup path: is on the roadmap for specific circuits; the base chain remains EVM-equivalent so your contracts and integrations don’t change.
Data & evidence on a rollup
Evidence files (COAs, BL + seal photo, temp logs, PSI reports) live off-chain under access control; the chain stores hashes and receipts. Batches commit those hashes and state transitions (EMTs minted, Locked/Unlocked EDSD deltas) to Ethereum as blob data and state roots.
Off-chain artifacts: stored in signed vaults; API returns expiring links; webhooks never carry raw files.
On-chain anchors: PoV hash, EMT id, fee/burn lines, and order/listing state changes.
Explorer: human pages you can share with auditors—who checked what, when it paid, and the burn hash.
Censorship resistance & escapes
We assume bad days and design for them.
Forced inclusion: if a sequencer refuses a tx, anyone can push it via the L1 inbox; the next batch must include it.
Permissionless exit: bridge contracts allow you to force-withdraw EDM/EDSD to L1 after the challenge window, even if the sequencer is offline.
Read-only truth: because data sits in blobs, you can reconstruct state off-chain if you need to audit independently.
Safety rails that never move
EDMA’s settlement law isn’t a rollup setting; it’s the application rule that keeps money honest. No governance or upgrade can change it.
No EMT, no funds.
One-Claim across the rail.
Must-fund before shipping: after Pre-Ship EMT, top-up precedes pickup/forwarder/BL.
Locked→Unlocked EDSD only on proof: off-platform cash-out at schedule completion.
50% of each protocol fee burns in EDM at the event: hash posted.
Performance & cost targets
We keep numbers simple so ops can plan.
Block time (L2): ~2s; typical EMT→release latency < 5s.
Posting cadence (L1): batches every ~2–10 min under load.
Fees: Tokens 4% per settlement (2/2 default split); Trade 0.5% per milestone with per-tranche caps; 50% burns at the event.
Gas: covered by a Paymaster; users don’t need ETH. Costs remain in the pennies per event with blobs.
What this means for teams
Developers: write standard contracts; call simple APIs; subscribe to webhooks. No custom proving logic.
Operators: treat L2 receipts as operational truth; withdrawals/bridges to L1 follow the challenge window.
Auditors: rely on public proof pages, burn hashes, PoV/EMT ids, and blob-anchored data to reconstruct state.
Plain recap
Last updated