Fraud/validity proofs

There are two families of proofs that secure an L2: fraud (fault) proofs and validity (zk) proofs. They answer different questions than PoV.

  • PoV admissibility: decides business truth: did the milestone really happen; is this the only claim?

  • Fraud/validity proofs: decide state correctness: did the L2 apply its rules and post the right state to Ethereum?

Think of it as: PoV says “allowed or not.” Fraud/zk say “computed correctly or not.” You need both.

Where EDMA is today

  • EDMA runs as an Optimistic Rollup anchored to Ethereum.

  • We publish our state to L1; there’s a challenge window during which anyone can contest a batch with a fault proof.

  • Once the window closes, the batch is economically final on L1.

  • Day-to-day operations never wait for that window; bridges/permissionless exits do.

This choice gives us mature tooling, EIP-4844 blob DA, and fast, cheap operations—while we build toward validity proofs where they add real value.

What fraud proofs are

  • Scope: L2 execution correctness (ordering, state transitions, balances).

  • Outcome: if a batch is proven faulty, it is rolled back; the canonical chain adopts the corrected state.

  • What users feel: operational receipts on L2 remain your daily source of truth; withdrawals to L1 respect the window and won’t finalize while a challenge is active.

What they don’t decide: whether a shipment happened or a credit is unique—that’s PoV + One-Claim at the app layer.

What validity proofs are

  • Scope: the same state-correctness questions fraud proofs cover, plus invariants we care about.

  • Outcome: faster L1 certainty when proofs are used; less reliance on economic challenges.

  • Roadmap use in EDMA: we’ll start where zk gives clear wins without slowing business clocks.

What neither fraud nor zk decide

  • No EMT, no funds: a slice can’t flip Locked EDSD → Unlocked EDSD without the gate passing.

  • One-Claim: duplicate evidence cannot finalize anywhere on EDMA.

  • Must-fund before shipping: after Pre-Ship EMT, the buyer tops up or nothing ships.

  • 50% burn: per event, at release; never discounted by proofs.

If a batch is challenged

  • On L2: your operational receipts don’t vanish. Releases were guarded by PoV/EMT and stand as business truth.

  • On L1: withdrawals wait; the dispute game runs. If the challenger wins, the batch is replaced with the corrected one.

  • For money on the rail: Locked EDSD stays locked; no slice flips without EMT. Already-unlocked slices came from EMTs, so they were admissible; the corrected batch re-anchors them.

  • For you: keep operating on L2 (trucks move, tokens settle). Plan L1 exits around the window; the status page shows active challenges.

The invariants we already enforce (and plan to prove)

  • Conservation of EDSD: per order, sum(Locked) + sum(Unlocked) = funded – refunds.

  • No early leakage: off-platform cash-out is impossible until the seller’s schedule completes and no advances are outstanding.

  • Correct fee accounting: per event, the protocol fee line is within caps; exactly 50% is burned in EDM; the remainder routes to treasury lines.

  • EMT monotonicity: a stage can mint at most one EMT per sub-lot; EMTs must appear in the correct order.

  • One-Claim global uniqueness: the claim key (e.g., {BL, seal, containers} or token serial) finalizes at most once across the rail.

  • Assignment/cash-out limits: 1% fee only when a funded-on-proof assignment settles; 0.5% cash-out only when the schedule completes.

Fraud proofs catch violations post-fact; validity proofs will certify these invariants up-front at the batch level.

Where we will use zk first

  • Fee/Burn correctness: prove that every recorded event charged the right fee, respected caps, and burned exactly 50% in EDM.

  • EDSD conservation per order/pool: prove that Locked/Unlocked never exceed funding and that replacements/cancels balance exactly.

  • EMT issuance correctness: prove that a given EMT could only mint once per stage/sub-lot and only after the checklist passed.

  • One-Claim set membership: prove that a claim key is unique in the global set without revealing unrelated entries.

  • Selective-disclosure claims: zk-attest “temperature stayed within band” or “shelf-life ≥ X” without leaking raw values—still bound to the same PoV hash.

These proofs anchor to L1 along with our blobs so auditors can verify them offline.

Threat model and how proofs intersect with PoV

  • Bad evidence: still blocked by PoV; proofs don’t make fake docs true.

  • Duplicate claims: still blocked by One-Claim; zk can certify uniqueness concisely.

  • Sequencer mis-order/censor: forced inclusion and permissionless exits keep you safe; fraud/zk prove state, not fairness.

  • DA failure: we rely on Ethereum blobs; if a blob is missing, the batch doesn’t finalize.

Operator guidance

  • Treat L2 receipts as operational truth. They’re already guarded by PoV/EMTs and One-Claim.

  • Plan L1 exits around the challenge window; the status page shows live batch/DA status.

  • Keep your evidence files; reconcile their hashes with the PoV hash on the proof page and the blob index when you audit.

  • Watch the Explorer for burn hashes and (as we roll them in) zk certificates on invariants.

Drawing

Plain recap

Fraud/validity proofs protect state correctness; PoV protects business truth. Together they give you an L2 where facts unlock cash in seconds, state anchors to Ethereum in minutes, and—regardless of disputes or upgrades—the settlement law never blinks: No EMT, no funds.

Last updated