Singletonne

Inspiration

When I saw this hackathon, it connected to UN goals I care about: SDG 13 (Climate Action), SDG 12 (Responsible Consumption and Production), especially its target on companies reporting honestly on sustainability, and SDG 16, which calls for transparent, accountable institutions. All three matter a lot for Africa and for building a more sustainable world.

Carbon markets are where those goals meet. Africa is betting on them. The Africa Carbon Markets Initiative, launched at COP27 with Nigeria among its backers, aims for 300 million credits a year by 2030, about $6 billion in revenue and 30 million jobs. That only works if buyers trust the credits.

The quickest way to destroy that trust is double counting: the same tonne of CO₂ sold twice, or claimed by two companies. The market's own integrity body, the ICVCM, makes "no double-counting" one of its ten core principles. Yet certificates still travel as PDFs, registries keep separate records, and a buyer holding one has no neutral place to check whether those exact serial numbers were already sold or retired. I wanted to build that place.

Track alignment

Track 1: Carbon Markets & Emissions Transparency. The track asks for more trust, transparency and efficiency in carbon markets, where lack of transparency, double counting and complex verification undermine credibility. Singletonne tackles all three:

It delivers two of the track's suggested builds outright, blockchain-based carbon credit verification and smart contracts that prevent double counting, and its public API, transfers and on-chain retirement records are the trust layer a transparent trading platform would build on.

What it does

Singletonne is a shared carbon-credit registry where every tonne can be counted only once.

• AI reads the certificate. Upload a Verra-style retirement or issuance certificate (PDF or image). Gemini extracts the registry, project, vintage and serial range, and rates the credits on additionality, permanence, baseline integrity and verification, in plain language. Fixed rules then double-check its reading; Verra serial numbers, for example, encode the exact block of tonnes.
• The AI vouches, the owner submits. The server signs an EIP-712 attestation of what the AI found, tied to one specific wallet. Neither the AI nor the user can register credits alone, and the attestation can't be edited or reused by anyone else.
• The smart contract decides. It refuses any serial range that overlaps credits already registered, including retired ones, any certificate registered before, and any second retirement. Retired credits can never move again.
• Anyone can check. Every batch has a public page with a QR code. Buyers can check a serial range before paying, and auditors can check a certificate without uploading it, because it's hashed in their own browser.
• It measures its own impact. Every refused attempt is recorded after the server re-runs it against the contract, so the registry shows the tonnes of double claims it has blocked.
• Other platforms can plug in. A public API lets marketplaces and audit tools ask the contract whether serials are free before they list or settle a trade.

How I built it

• Smart contract: Solidity 0.8.28 with OpenZeppelin 5 (AccessControl, EIP-712, Pausable), built and tested with Foundry. Deployed on Ethereum Sepolia at 0xdC955ED5A8eB2b5Ca428d21046d643a050d076a2.
• AI: Gemini on Vertex AI through the @google/genai SDK. It reads the PDF directly and returns structured JSON validated against a schema.
• App: Next.js 16 (App Router), MongoDB with Mongoose, and viem with MetaMask for wallet actions. Hosted on Vercel.
• Trust model: the contract is the source of truth. MongoDB is only an index that can be rebuilt from chain events at any time. The server reads every transaction receipt from the chain itself rather than trusting what the browser says.
• Shared helpers: the same JavaScript code computes hashes, project keys and signatures in the app and in the contract tests, so the two can't drift apart.

Challenges I ran into

• The testnet changed under me. Sepolia's Glamsterdam upgrade (October 2026) raised the gas cost of storing contract code. My first deployment simulated fine locally but ran out of gas on-chain. I fixed it by taking gas estimates from the live network instead of local tooling.
• Slow AI reads. Reading a certificate took about a minute, too long to sit and stare at a spinner. I made processing asynchronous: uploads return instantly with a private, resumable link, the AI works in the background, and the page shows live progress and sourced climate facts. I also lowered the model's thinking level and reused earlier readings for identical files.
• RPC limits. Free RPC plans allow only a few blocks per event query, which made pages take 15 seconds to load. I moved chain syncing out of the page request and made it remember the limit the RPC accepts.
• Certificates that hide their text. Some Verra PDFs draw their values instead of storing them as text, so ordinary text extraction finds nothing. Gemini reads the page visually, and a deterministic serial-number parser cross-checks what it reads.
• Refusals leave no trace on-chain. A rejected transaction records nothing, so I had the server re-run each refused call against the contract and store it only if the contract really rejects it. Nobody can fake a "blocked" entry.

Accomplishments that I'm proud of

• The contract enforces the rule itself. Double counting isn't prevented by a database check or a promise, but by code anyone can read and verify.
• Thorough testing. 33 Foundry tests, including a 1,000-run fuzz test of the overlap rule, plus 49 end-to-end checks covering upload, registration, blocked double claims, transfers, retirements and the public API.
• Real certificates, end to end. It reads publicly published Verra certificates, registers them on Sepolia, and blocks a re-saved copy of the same credits.
• A design where AI helps but doesn't rule. The AI reads and rates; the contract decides.
• Privacy where it matters. Verifying a certificate never uploads it.

What I learned

• Double counting takes several forms. Double selling, double claiming and double issuance across registries are different problems. A contract can block overlapping serials outright, but spotting the same project on two registries needs AI-assisted matching. Being honest about that boundary made the design better.
• AI is excellent at messy documents but needs guardrails. Pairing it with fixed rules and an on-chain referee is what makes its output trustworthy.
• Test against the real network. A testnet can change mid-hackathon, and local gas estimates can be wrong.
• Waiting is a UX problem, not just a performance one. A progress screen that explains itself and lets people leave beats a faster spinner.

What's next for Singletonne

• Partial retirement: splitting a batch when only part of it is claimed.
• More serial-number parsers: Gold Standard, ACR and Climate Action Reserve, so every registry gets the same deterministic check Verra has.
• Direct registry imports: pulling issuance records from registry APIs, not just certificates.
• Bulk import: a background queue so brokers can register whole portfolios at once.
• Mainnet or an Ethereum layer 2, with attestations from several independent verifiers instead of one key.
• Article 6 flags: marking credits used toward national targets under the Paris Agreement.
• Pilots with African project developers and buyers, so credits from the continent carry proof that each tonne was counted once.

Built With

• gemini
• next
• node.js
• sepolia
• solidity