CarbonTwin

Overview: 11,468 listings screened, and the largest finding (GS7538 and VCS1931) drawn as a mirrored vintage chart.
Findings: 18 same-asset pairs with a shared vintage, shown with registry badges, the shared years and the overlap volume.
Finding detail: vintages issued by both registries, the model verdict, and the facts found in both records.
Contract demo: an in-browser EVM replays the pair; after linking, a new 2021 issuance reverts with DoubleIssuance.

Track

Carbon Markets & Emissions Transparency. CarbonTwin addresses double counting across registries: the same project listed in two registries, with both issuing credits for the same vintage year.

Inspiration

Each carbon registry checks serial numbers inside its own books, and no registry sees the others. When a project moves from one standard to another, or is listed with two, the public summary data can show both registries issuing credits for the same years, and no one is assigned to reconcile them.

What it does

Screens all 11,468 listings in Berkeley's Voluntary Registry Offsets Database and proposes 1,989 cross-registry pairs with similar names in the same country.
Adjudicates 450 of those pairs with an open-weight model (Gemma 4 12B, running locally): all 287 that share a vintage, plus the highest-scoring others. For each pair the model answers same asset, different asset, or unclear. A second pass must cite facts found in both records, and code checks every cited value against the source.
Reports 18 pairs that both passes confirmed and that were issued credits for at least one common vintage, about 2,486,944 tCO₂e counting the smaller side.
Enforces with a Solidity contract that records issuances per listing and vintage. When the auditor links two listings, the contract emits a conflict for every vintage both registries issued and refuses any later issuance of those vintages by the second registry.
Anchors the report: each finding is hashed into a Merkle tree, the root is stored on-chain, and any finding can be checked against it.

The demo replays a real pair through the contract in an EVM that runs in the browser, so judges can try it without a wallet.

Who it is for

Registries and meta-registries that need to reconcile listings with each other, rating agencies and buyers doing due diligence on a project before purchase, and researchers who study the voluntary carbon market.

Scale and adoption

Screening all 11,468 listings, including reading the spreadsheet, takes under ten seconds on a Mac mini (Apple M4). The 450 model calls ran on the same machine at no cost, so each new release of the database can be rescreened. Registries would not need to change their own systems: they post issuance claims to one shared contract, and anyone can read the conflicts it records.

How it was built

Data: Voluntary Registry Offsets Database v2026-06 (Berkeley Carbon Trading Project, CC BY 4.0).
Screening: Python, pandas and scikit-learn; character n-gram TF-IDF within each country, with developer, site, type and capacity feeding a pre-score.
Adjudication: Gemma 4 12B QAT through llama.cpp at temperature 0, JSON-schema output, two passes.
Contract: Solidity 0.8 compiled with solc 0.8.37; eleven tests on an in-memory EVM (ethereumjs, Cancun), including checks that every published finding proves into the report root.
Web: Vite and plain JavaScript; viem for ABI encoding; the browser demo runs the same bytecode.

Challenges

The first model pass sometimes stated details that appeared in only one of the two records. The fix was a second pass that lists each shared fact with the value from each record, plus a code check that drops any value it cannot find in both. Generic shared facts (country, project type, methodology) still let different plants of one developer through, so pairs whose names carry different numbers or distinguishing words now go to a review list instead. Only pairs that survive every check count as findings.

Limits

The summary data has no serial numbers, so overlap is measured per vintage, and a registry transfer can split a year legitimately. Every finding is a reconciliation question for the registries, not a claim of fraud.

Why a blockchain

No registry runs the others' books, and none should have to trust a database that another registry controls. An append-only contract that every registry can write to and anyone can read is the smallest shared record that makes a cross-registry overlap visible and lets the second issuance be refused.

What's next

Registries could post issuance claims directly, keyed by serial-number hashes rather than vintage totals, so the check runs before credits reach buyers. The Climate Action Data Trust already aggregates registry data; CarbonTwin's matching and vintage-level check could run on top of such a shared index.