PoV admissibility
What PoV does
Proof-of-Verification (PoV) is the admission gate for money and assets on EDMA. It answers two questions before anything changes state:
Did the thing really happen?
Is this the only claim on that evidence?
If the answer to either is “no”, the contract refuses the action. In Trade, that means no EMT → no release. In Tokens, that means no settlement. Admissibility is enforced in code, not in policy.
The flow in one line
Source → Verify → Gate → EMT (or Settle)
Source: a real event leaves evidence: production inspection, BL + seal photo/number, customs EDI, DC receipt & QA, temperature logs; or a metered/verified token record.
Verify: independent roles attest to that evidence (inspector, terminal/carrier, DC/3PL, oracle).
Gate: the PoV contract checks that attestations match the exact checklist written in the contract/listing and that the same evidence hasn’t been used elsewhere.
EMT/Settle: on pass, the stage EMT mints (Trade) or the token settles (Tokens). The slice flips Locked EDSD → Unlocked EDSD, the receipt is issued, and the burn posts.
What the Gate actually checks
Checklist match: every required field is present and valid for this stage/listing: lot list, COA, BL number, seal number & photo, container IDs, customs codes, DC QA, temp ranges.
Attestor quorum: attestations arrive from the right mix of roles (e.g., inspector + terminal/carrier + DC/3PL), with active keys and within the SLA window.
Evidence equality: all counted attestations bind to the same evidence hash (canonically serialized); any mismatch fails the gate.
One-Claim: the evidence key (e.g., {BL, seal, containers} for On-Board or {token serial} for Tokens) has not been finalized elsewhere on EDMA.
Funding precondition (Trade): for stages after production, required top-ups are present as Locked EDSD (must-fund before shipping).
Revocation status: none of the counted attestations has been revoked or expired; if a later revocation appears, downstream slices freeze.
Pass → EMT/settle. Fail → a clear reason and a fix path (upload the correct file, re-inspect, apply the variance rule).
How evidence and attestations are bound
Canonical evidence: we compute a stable hash over the canonical form (sorted JSON + file digests). The PoV hash commits to “what was checked”.
Attestations: roles submit signed statements that reference the same PoV hash and the same order/listing. Keys live in a role registry; expirations and revocations are on-chain.
Transport: signed uploads via API; the chain stores hashes, not raw files. Files sit in vaults with signed URLs; webhooks never carry private payloads.
Trade vs Tokens: same law, different objects
Trade: the object is a stage of a shipment (e.g., Pre-Ship, On-Board, Arrival). A pass mints the stage EMT, flips the relevant slice Locked → Unlocked EDSD, posts the fee line, and burns 50% of that stage’s fee in EDM.
Tokens: the object is a verified unit (e.g., Energy 1 MWh, Carbon 1 tCO₂e). A pass authorizes settlement/retirement; the 4% fee applies, and 50% of it burns in EDM.
In both, One-Claim prevents duplicate use of the same evidence anywhere on EDMA.
Revocation and freezes
If a counted attestation is revoked later, EDMA freezes only the dependent future slices. Paid slices stay paid; the proof page records the change and the fix path.
If a gate fails up front, the stage remains red with a plain-English reason. The Dispute Pack (checklist, files+hashes, timeline, variance math) guides the fix.
When the record is clean, the EMT mints and the slice releases; the history shows what changed and when.
Threats we assume
Forged or tampered evidence: We bind attestations to hashes; redactions or edits change the hash and fail equality. Randomized file digests on upload protect against trivial substitutions.
Attestor collusion: We require distinct, independent roles; governance sets SLAs, rotation, and penalty schedules; professional roles post bonds that can be slashed for misconduct.
Replay / duplicate claims: One-Claim rejects reuse of {BL, seal, containers} (Trade) or {serial/registry key} (Tokens); a duplicate simply cannot finalize.
Stale or late evidence: Windows are enforced in the checklist; submissions outside the SLA fail.
Censorship of proof tx: L1 forced inclusion ensures a proof/EMT transaction can be pushed into the next batch if a sequencer stalls.
Formal properties
Safety (no unauthorized release): If the checklist does not match or One-Claim is already taken, EMT cannot mint and Locked EDSD cannot flip.
Liveness (when you do the right thing, it clears): If all conditions hold and funding is present, the EMT must mint; releases complete within seconds (operational finality).
Uniqueness: The same evidence cannot create two EMTs or two settlements; One-Claim enforces a single canonical consumer.
Non-repudiation: Receipts and public proof pages show hashes, roles, and burn transactions; auditors can reconstruct the state from L1 blobs.
Privacy and selective disclosure
Raw documents stay in vaults; the chain anchors hashes.
We redact PII when possible and commit to the redacted form.
Where needed, ZK wrappers can prove statements like “temp stayed in range” or “shelf-life ≥ X” without revealing values; the PoV hash ties the ZK proof to the same dossier.
How PoV, EMT, and EDSD interlock
PoV Gate: decides admissibility (pass/fail).
EMT: is the only switch that flips a pre-assigned slice Locked EDSD → Unlocked EDSD.
No EMT, no funds: keeps money where it belongs until facts arrive.
Off-platform cash-out: is blocked until the seller’s schedule completes; in the meantime, Unlocked EDSD can pay in-platform invoices immediately.
Operator checklist
Write plain-language checklists into the MPA or listing.
On the floor: capture the evidence that satisfies that checklist (photos, PDFs, EDI, logs).
Submit via API/UI; watch the gate flip and funds release; use receipts for ERP and audit.
If red, read the reason, fix, and resubmit; the rail pauses only what’s affected.
Plain recap
Last updated