Data availability
What “data availability” means for EDMA
We anchor the facts that move money—proof hashes, EMT mints, fee/burn lines, and Locked→Unlocked EDSD deltas—to Ethereum. Big documents (COA PDFs, BL + seal photos, temp logs, inspection files) live off-chain under access control; their hashes live on-chain. Anyone can reconstruct the state from L1 blobs; authorized parties can retrieve the underlying files via signed links. That’s the balance: public verifiability for the facts that matter; private handling for sensitive evidence.
The split
We keep this simple so ops, auditors, and regulators all understand it the same way.
On-chain (L2 → L1 blobs/state roots):
PoV hash for each gate check (the commitment to the evidence set)
EMT id and stage metadata (which gate passed, when, for which sub-lot)
State deltas: Locked→Unlocked EDSD per slice; assignment settlement; cash-out enabled
Fee & burn lines: per event, with the burn hash in EDM
One-Claim map updates (the uniqueness key/claim reference)
Off-chain (evidence vaults, role-gated):
COA/QA reports, PSI PDFs, BL + seal image, temp logs, customs EDI, DC QA photos
Brand authorization letters and program/registry confirmations
Any PII or commercially sensitive documents
Files are stored redundantly; the chain holds their content hashes. Signed URLs (short-lived) deliver access through the API; webhooks never include raw files.
How blobs keep the rail auditable
Batches post to Ethereum as EIP-4844 blobs on a steady cadence (≈ 2–10 min under load). Those blobs carry the commitments listed above and the Merkle roots needed to prove inclusion. If you need to re-build any timeline:
Pull batch indices from L1 and fetch the blobs.
Verify PoV hashes, EMT ids, Locked/Unlocked EDSD deltas, and burn hashes.
Request evidence by hash (authorized role) to view the underlying file set.
Compare the file hashes to the on-chain PoV hash.
You now have an end-to-end proof: evidence → PoV hash → EMT → release → burn.
Auditors don’t have to trust our UI; they can walk the chain.
Evidence privacy and selective disclosure
We never put PII or raw evidence on the chain. Instead:
Hashes on-chain; files off-chain: The contract checks hash equality; the vault serves files with short-lived signed links.
Field redaction & salts: Where a file contains PII (e.g., warehouse contacts), we redact those fields; the hash commits to the redacted version.
Selective disclosure / ZK wrappers (roadmap): Prove facts like “shelf-life ≥ X”, “temp in range”, or “origin in {A,B}” without revealing raw values.
If a regulator needs raw files, their account is whitelisted for the relevant hashes; the proof page records access.
What a money-moving record actually contains
Releases are more than numbers; they’re small dossiers tied to blobs. A settlement/release record shows:
the stage and EMT id that triggered payment,
the PoV hash and which validators signed,
Locked EDSD and Unlocked EDSD amounts for that slice,
the protocol fee applied, the burn hash in EDM, and the treasury half,
links to the public proof page and expiring evidence URLs (for authorized roles).
That’s why finance and audit stop arguing; they read the same artifact.
Data availability for EDSD reserves (Proof-of-Reserves)
While funds are Locked EDSD, the platform holds ~75% in short-dated treasury bills and ~25% in cash. We publish:
a daily reserve summary (totals per order, per stage, outstanding Locked vs Unlocked),
a PoR attestation (bank statements/custodian confirms hashed and anchored),
a simple ladder view (T-bill maturities, cash buffer),
an alert if coverage drifts (Reserve mismatch, Buffer low, Ladder drift).
All of this references on-chain commitments so third parties can re-compute the totals.
Failure modes and how we recover
Sequencer outage: forced inclusion via the L1 inbox ensures critical txs (proof, EMT, release) can still be posted; exits are permissionless after the challenge window.
Vault unavailable: files are replicated across regions; signed links failover; hashes on-chain allow re-hydration from mirrored stores.
Revocation after pass: the slice and downstream slices pause; the revised PoV hash supersedes the old one; the Dispute Pack on the proof page shows the delta.
We never burn ahead of proof, and we never release a slice without an EMT. Those brakes are separate from DA.
Developer surface
API:
GET /v1/evidence/{hash} (signed URL), GET /v1/proof/{emt_id} (summary with PoV hash), GET /v1/ledger/{order_id} (fee/burn/Locked-Unlocked deltas).Webhooks: trade.milestone.passed, trade.release.posted (includes burn hash), tokens.settlement.posted, fee.burn.posted, treasury.interest.accrued.
Explorer: human pages backed by the same data; every record links to the L1 blob index and burn tx.
What stays invariant
The rail is useful because the facts are public and the files are private—with a clean bridge between them. We don’t move money without proof, we don’t accept duplicate evidence, and we don’t hide what burned or when.
No EMT, no funds—releases require an EMT.
One-Claim—the same evidence cannot be used twice.
Must-fund before shipping—after Pre-Ship EMT, the buyer tops up; no funding, no BL.
50% burn of each protocol fee in EDM, posted with a hash per event.
PoR & blobs—state and commitments live where anyone can verify them.
That’s data availability on EDMA: the ledger you can verify, the files you can retrieve, and a payment you can defend.
Last updated