Berkeley Voluntary Registry Offsets Database
One project, two registries, the same vintage issued twice?
CarbonTwin screens every listing in Berkeley's database of the major voluntary carbon registries, has a model judge whether two listings describe the same physical asset, and records the answer in a smart contract that refuses a second issuance of the same vintage. On GitLab, a release steward agent keeps the audit current as the database is republished.
- ScreenTF-IDF name matching, developer, site and type checks across … listings
- AdjudicateA model reads both listings and returns a JSON verdict with a reason: Gemma 4 12B, run locally, for the published run; a GitLab Duo flow for pairs that are new or changed in a later release
- AnchorEach finding is hashed into a Merkle tree; the root is stored on-chain
- EnforceLinked listings share one asset key, so a second registry cannot issue the same vintage
Results
Findings
A finding means the adjudicator judged both listings to be the same asset and both registries issued credits for at least one common vintage. Registry transfers can legitimately split a vintage, so each finding is a reconciliation question for the registries, not a verdict of double counting.
| Listings | Country | Overlapping vintages | Overlap (tCO₂e) | Model verdict |
|---|
On-chain
Contract demo
Replays the selected finding through CreditClaimRegistry.sol: each registry records its real issuances, the auditor links the two listings, the contract reports the overlapping vintages, and a new issuance for a linked vintage is refused.
Selected: —
Pick a finding, then deploy.
How it works
Method and limits
Data
Vintage issuance per listing comes from the registries' public records as compiled by Berkeley. Serial numbers are not in the summary data, so overlap is measured per vintage, using the smaller of the two issuances.
Matching and adjudication
Pairs are candidates when names are similar within the same country (character n-gram TF-IDF, cosine ≥ 0.62). Every pair with a shared vintage, plus the highest-scoring others, went to the model, which sees name, developer, site, type, methodology, status, vintage profile, notes and description for both listings. It is told that phases, different capacities and different sites mean different assets. A second pass must list facts present in both records; code drops any it cannot find.
What the contract adds
Registries keep their own systems. They post issuance claims keyed by listing and vintage. Once an auditor links two listings, they share an asset key: past overlaps become events anyone can see, and future overlaps revert with DoubleIssuance.