Registry mirror
What a “registry mirror” is
A registry mirror links an external program’s unit (e.g., Verra/GS carbon serial, I-REC/GO energy certificate) to the same, single claim on EDMA. It does not create new value; it maps an outside serial to our on-chain lineage so you can trade or retire the asset on EDMA and hand auditors one page with both worlds aligned.
Short rule: mirror = mapping + proof, not a second issuance.
How a mirror is created
Push (preferred): the external registry (or its authorized connector) attests the serial → EDMA. The attestation is a role in the Attestor Registry (e.g., REGISTRY_VERRA) and references the PoV hash and the external serial.
Pull: EDMA’s connector reads an issuance/retirement from the registry API, bundles the evidence (issuance cert, serial block), and asks the registry role to countersign.
The mirror record is then written on EDMA, bound to the same PoV dossier, and the serial becomes unique via One-Claim—you can’t mirror or sell it twice here.
What we store
A mirror is a small, immutable header plus append-only status. It’s anchored in receipts and on the proof page.
{
"mirror_id": "mirr_VERRA_2025_00012345",
"schema_id": "TOKENS.CARBON.VCM.v1",
"claim_id": "0x…", // One-Claim id for this unit
"pov_hash": "0x…", // sha256(canonical dossier)
"program": "VERRA", // or GS/I-REC/GO
"project_id": "VCS-1234",
"vintage": "2024",
"serial": "VCS-1234-2024-00012345-00012345",
"registry_sig": "base64url(...)" , // attestor signature
"created_at": "2025-03-12T09:20:00Z",
"status": "ACTIVE" // PENDING | ACTIVE | FROZEN | REPLACED | REVOKED
}ACTIVE: external issuance is recognized and bound to this claim_id.
FROZEN: external program signaled a problem; EDMA blocks actions until corrected.
REPLACED/REVOKED: append lineage and freeze the old record; nothing is deleted.
What the mirror allows
You may list/settle/retire the mirrored token on EDMA (Tokens marketplace rules apply: 4% fee; 50% burn in EDM at settlement/retirement).
You get a proof pack that shows EDMA lineage and the external serial, with the registry’s attestation.
You cannot: mirror the same serial twice, wrap into multiple markets simultaneously, or bypass PoV. If it isn’t proven, it doesn’t mirror; if it’s mirrored, it’s one claim here.
Read vs write authority
Registry role attestation is the write authority (who can say “this serial equals this dossier”).
Everyone else reads/uses the mirror after it’s ACTIVE.
If the registry later revokes or amends, it sends a revocation (see PoV: Revocation). EDMA freezes only what depends on the mirror and records a replacement if one is issued.
Flow you can follow in ops terms
Mint/Convert (Tokens): PoV-backed unit exists (e.g., 1 t or 1 MWh).
Mirror: registry attests the external serial to this claim_id (status=PENDING → ACTIVE).
Use: list, settle, or retire on EDMA; receipts include the serial and burn hash.
If registry changes: EDMA flags FROZEN; ops see why; either replace with the corrected serial (append-only) or cancel per program rules.
API and events
POST /v1/registry/mirrors (registry role only) — create a mirror; returns mirror_id.
GET /v1/registry/mirrors/{mirror_id} — read mirror + status + lineage.
POST /v1/registry/mirrors/{mirror_id}/revoke|replace (registry role) — change status; link replacement.
Webhooks: registry.mirror.created — mirror ACTIVE (claim_id, program, serial). registry.mirror.frozen — EDMA blocked further use pending correction. registry.mirror.replaced — new serial/record linked; downstream actions resume. tokens.settlement.posted / tokens.retirement.proofpack.ready — include mirror fields and the burn hash.
One-Claim and “first use” on EDMA
If a unit was already settled/retired on EDMA, a later mirror to the same external serial is still allowed only to annotate the existing claim (not to create a new one).
If a mirror arrives first and points to a claim_id, only that claim can settle/retire this serial here. Duplicate attempts revert with E_ONECLAIM_TAKEN.
(Section 13.2 First-Seen Rules covers inter-platform precedence; on EDMA the check is absolute.)
Revocation & replacements
Revocation is append-only: we never delete mirrors. If a registry withdraws or re-issues:
Freeze the mirror; show a red banner and reason.
Replace: the registry posts a new mirror entry with the corrected serial; EDMA links replaces: old, unfreezes downstream use.
Compensate (if already retired): record the registry’s compensating action (replacement/extra retirement) on the proof page; your original receipt stays, with an addendum.
Security, privacy, and audit
Signatures: registry attestor keys live in the Attestor Registry; EDMA verifies role, key, and freshness.
Privacy: mirrors carry serials and program ids—never raw documents; evidence lives in the vault; PoV hash anchors the dossier.
Audit: proof pages show mirror id, program, serial, registry signature hash, claim_id, pov_hash, and every settlement/retirement burn. Auditors can replay state from L1 blobs and request signed links to evidence.
Governance knobs
Governance can add/retire program connectors, rotate registry keys, set SLA for mirror propagation, and define freeze policies (how quickly mirrors halt use when a revocation hits).
It cannot weaken PoV or One-Claim, skip must-fund before shipping, or discount the 50% burn.
Operator checklist
Create or convert the unit first; mirror second.
Verify the program and serial are exactly as issued; mismatches will freeze the listing.
If a mirror freezes, open the record; the banner shows the registry reason and the corrective path.
File receipts with the mirror id and burn hash; that’s what finance and audit will ask for.
Plain recap
Last updated