First-seen rules
What “first-seen” means
When more than one party tries to monetize the same fact (a shipment event, a token serial) across systems, we need one canonical “winner.” EDMA solves this in two layers:
Inside EDMA: the first transaction that finalizes a claim (via PoV PASS + One-Claim reserve→finalize in the same transaction) is first-seen. All later attempts revert.
At the edges (registries/other chains): we reconcile mirrors and external serials with a simple precedence policy and clean freeze/replace paths—so you never end up paying twice or retiring twice.
Short rule: first to finalize the claim wins; everything else must link or stop.
A. Inside EDMA — single source of truth
Finalization, not submission. We measure first-seen by finalization (the tx that passes the Gate, mints the EMT/token, and finalizes One-Claim), not by when someone “submitted” a file.
Atomicity: the One-Claim reserve→finalize and EMT/token mint occur in the same transaction as the Gate PASS. There is no cross-block “hold” that a race could slip through.
Ordering: the L2 block time (and tx index) defines operational first-seen; the L1 batch anchors economic first-seen after the challenge window.
Tie-breakers: two txs using the same claim_id cannot both finalize; the second reverts with E_ONECLAIM_TAKEN—even if it lands in the same block.
Operator takeaway: if your claim finalized, you own the fact on EDMA. Nobody else can mint/settle it here.
B. With external registries — mirrors and precedence
External programs (Verra/GS/I-REC/GO, etc.) have their own “first” for a serial. EDMA respects that by mirroring the serial to the same EDMA claim and applying predictable freeze/replace rules.
Mirror-first (external before EDMA): If the registry attests a serial to EDMA before any EDMA settlement/retirement, that mirror binds the serial to a single claim_id here. Only that claim can settle/retire this serial on EDMA. Duplicate attempts revert (E_ONECLAIM_TAKEN).
EDMA-first (EDMA before mirror): If EDMA has already finalized a PoV-backed token and later receives a registry mirror for the same serial, the mirror annotates the existing claim (it does not create a new one). Receipts now show both lineages.
Conflict (mirror points elsewhere): If a mirror arrives pointing the serial to a different EDMA claim than the one already settled/retired, EDMA freezes further actions and opens a revocation case. The registry must issue a replacement or compensating action. Proof pages record both entries (append-only).
Revocation downstream: If the registry later revokes or re-issues a serial we mirrored, EDMA freezes only what depends on it and records a replacement mirror on correction. Already-retired units follow the program’s corrective path (replacement/compensating retirement), linked on the proof page.
What never happens: we do not create two independent on-EDMA claims for the same external serial.
C. Cross-chain / cross-platform
Single home, single truth: Each asset/claim has one canonical chain of record (EDMA). Any bridge must carry a non-fungible proof back to EDMA; bridged representations rely on the EDMA claim_id.
Inbound first-seen: if an inbound bridge brings a proof of prior finalization elsewhere, EDMA treats it like a mirror—it must bind to a single claim_id or be refused.
Outbound: if you export a representation, EDMA locks the local token to prevent double use until the representation is returned/burned (or the bridge posts a finalized external proof we accept).
Collisions: if the same off-chain evidence appears bridged from more than one source, One-Claim still prevents duplicate finalization here; the second inbound proof is rejected and a conflict ticket opens.
D. Time sources and drift
Operational first-seen (EDMA): L2 block time and tx index of the finalization tx.
Economic finality: L1 batch anchoring after the challenge window.
Registry clocks: for mirrors, we record registry attestation time (their signed timestamp). We don’t adopt external clocks to break ties inside EDMA; they only inform freeze/replace decisions if a registry later contradicts our state.
Governance knobs: max accepted time-skew for attestation windows; SLA for “mirror must be posted within X days of external issuance” or the listing shows a yellow “awaiting mirror” flag.
E. Exceptions you will see
Duplicate attempt on EDMA: reverts with E_ONECLAIM_TAKEN. Outcome: instruct the party to link to the existing claim or file a replacement (if theirs is corrective).
Mirror arrives late: allowed; it annotates the existing claim (no new value).
Mirror points to a different EDMA claim: EDMA freezes further actions and requires the registry to post a replacement mirror; proof page shows both entries, with the replacement labelled.
Post-retire registry change: EDMA issues/records a compensating retirement or replacement per program; your original receipt stands with an addendum.
Bridge double-entry: second inbound proof is refused; if already reflected elsewhere on EDMA, it’s a no-op.
F. API & events
GET /v1/oneclaim/{claim_id}: status (FREE|RESERVED|FINALIZED) + lineage.POST /v1/registry/mirrors(registry role) — create; returns mirror_id.POST /v1/registry/mirrors/{id}/revoke|replace: adjust; links replacement.
Webhooks:
oneclaim.finalized— a claim became canonical on EDMA.registry.mirror.created— serial → claim bound (ACTIVE).registry.mirror.frozen|replaced— freeze/resume path, reason included.
G. Operator checklist
On EDMA: finalize first to secure your fact (PoV PASS + One-Claim + EMT/token mint).
With registries: mirror as soon as the external issuance exists; late mirrors annotate, not create.
If frozen: read the banner, escalate to the registry connector, and expect a replacement or compensating action; EDMA never pays twice.
For bridges: keep EDMA as home; treat bridged forms as representations that must reconcile to the claim_id here.
Plain recap
Last updated