# 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: 1. Pull batch indices from L1 and fetch the blobs. 2. Verify PoV hashes, EMT ids, Locked/Unlocked EDSD deltas, and burn hashes. 3. Request evidence by hash (authorized role) to view the underlying file set. 4. Compare the file hashes to the on-chain PoV hash. 5. 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.