Mint

What “mint” means on EDMA

• Trade: minting an EMT (Event/Milestone Token) — a non-transferable receipt that says a gate passed. It is the switch that later lets money flip Locked EDSD → Unlocked EDSD.

• Tokens: minting a PoV-backed unit (e.g., Energy 1 MWh, Carbon 1 tCO₂e, hourly attributes) — a transferable/retirable asset bound to a dossier.

Mint does not move cash and it never burns fees. Money moves (and burns happen) at Settle/Release, not at Mint. Rule stays: No EMT, no funds.

A. Trade — EMT mint

• Purpose (plain): record that a milestone really happened, in a way the settlement contract can trust.

• Inputs to the Gate (single call): order_id, stage, schema_id (the checklist name); PoV hash (canonical dossier); Role-signed attestations (e.g., Inspector, Terminal/Carrier, DC/3PL), each referencing the same PoV hash; Uniqueness key for One-Claim (e.g., {BL, seal, containers_subset}); Funding precondition for post-production gates (must-fund before shipping: required Locked EDSD present)

• What the Gate checks: Checklist match (files & fields for this stage); Role-diverse quorum, active keys, freshness windows; Equality: all counted signatures bind to the same PoV hash; One-Claim reserve (free → reserve now; taken → revert); Funding present (where required); No revocation on counted attestations

• Atomic flow (one transaction):

  1. PASS → One-Claim RESERVE succeeds

  2. Mint EMT for {order, stage, sublot} with pov_hash, claim_id

  3. One-Claim FINALIZE (locks uniqueness)

  4. Emit EMTMinted (human-readable proof for explorer/receipts)

• What does not happen at mint: No flip of funds (that’s Settle/Release); No protocol fee charge; no EDM burn; No off-platform cash-out enablement

• Typical failure codes: E_PENDING_FUNDS · E_SEAL_MISMATCH · E_LOT_LIST_MISMATCH · E_TEMP_OUT_OF_RANGE · E_QUORUM_MISSING · E_STALE_ATTEST · E_ONECLAIM_TAKEN.

• API (balanced): POST /v1/trade/proof/{order_id}/{stage} → { pass|fail, reason, gate_pass_id? }; POST /v1/trade/release/{order_id}/{stage} consumes gate_pass_id (handled in Settle)

• Webhooks: pov.gate.pass · pov.gate.fail · oneclaim.finalized · trade.milestone.passed (EMT minted)

• Ledger impact: a new EMT entry with pov_hash / claim_id. No fee line; no burn line.

B. Tokens — asset mint

• Purpose (plain): create an evidence-bound, listable unit (e.g., 1 MWh, 1 tCO₂e, hourly attribute) that can later settle or retire.

• Inputs to the Gate: schema_id, token category (Energy/Carbon/Hourly), quantity (fixed); PoV hash for the dossier (device/time window, method/region/vintage, project/serial, etc.); Role-signed attestations (registry/oracle, metrology/sensor OEM, auditor); Uniqueness key for One-Claim (e.g., {program, project_id, vintage, unit_serial} or {device_id, start_ts, end_ts, quantity_Wh})

• Checks & flow: identical pattern to Trade: PASS → One-Claim RESERVE → TokenMinted → One-Claim FINALIZE (all atomic). The token stores pov_hash, claim_id, method/region/vintage (or device window), and attestor refs.

• What does not happen at mint: No protocol fee charge; no EDM burn; No settlement or retirement (that’s Settle / Retire)

• API: POST /v1/tokens/mint (via Gate) → { token_id, pov_hash, claim_id }; Later: POST /v1/tokens/settle or /retire (see next tx types)

• Webhooks: tokens.token.minted · oneclaim.finalized

• Ledger impact: token appears with PoV/One-Claim metadata; no fee/burn yet.

Security & invariants

• PoV-first. No mint without a Gate PASS bound to a canonical PoV hash.

• Atomic uniqueness. One-Claim reserve→finalize is inside the same tx as mint; duplicates can’t leak.

• Append-only lineage. Corrections mint new EMTs/tokens with replaces: old_claim_id; we never erase history.

• No money early. Mint never flips Locked EDSD or burns; settlement/release does.

• Idempotent. The same (order, stage, sublot) or token_id won’t mint twice; replays are safe.

Operator checklist

• Keep stage/token schemas human-readable; list exactly what “pass” means.

• Use registered attestors; verify their keys are active.

• Ensure every attestation references the same PoV hash.

• For Trade post-production gates, fund before you mint (or expect E_PENDING_FUNDS).

• If you see a fail, fix that field (seal photo, lot list, temp range) and resubmit; Mint pauses only this claim.

Quick comparison

Mint of…	Moves cash?	Fee/Burn?	One-Claim	Event
EMT (Trade)	No (cash moves at Release)	No	Yes (atomic)	EMTMinted
Token (Tokens)	No (cash moves at Settle)	No	Yes (atomic)	TokenMinted

Plain recap

Mint records the fact, not the money. PoV proves the dossier, One-Claim guarantees uniqueness, and the asset contract (EMT or token) emits the truth the rest of the system relies on. Cash waits for Settle/Release, and burns happen there—not here. That’s why the rail stays honest and predictable: facts first, then cash. No EMT, no funds.