A retired carbon credit is a string of letters and numbers in a database somewhere. That is the awkward truth at the heart of voluntary offsetting. The credit started life as a project — a stand of mangroves on a Mozambican coast, a cookstove programme in Rwanda, a methane capture rig at a landfill in Karnataka — and it ends life as a row marked "retired" in a registry ledger. Between those two states there is a paper trail, and the question for anyone serious about carbon-positive claims is whether that paper trail can be inspected by a stranger without a password. At IMPT we decided early that the answer had to be yes.

What verifiable retirement actually proves

Let's start with what the registries do and don't tell you. Verra runs the VCS programme. Gold Standard runs its own. Both maintain serial-numbered registries where each tonne of avoided or removed CO₂ has a unique identifier — vintage year, project ID, methodology, country, and a status field that moves through issued, transferred, and retired. When a credit is retired, that status is final. It cannot be transferred again, sold again, or counted again. That is the whole point.

What verifiable retirement proves is narrow but important: that a specific, serialised tonne, attributed to a specific project under a specific methodology, has been taken out of circulation on behalf of a named beneficiary. It proves the tonne is no longer a tradeable asset. It proves who asked for the retirement. It proves the date and the registry of record.

What it does not prove is the underlying climate integrity of the project that issued the credit. It does not prove the baseline was conservative. It does not prove the additionality argument was sound. It does not prove the monitoring reports were accurate. Those questions live upstream of the registry and are properly the domain of validators, auditors, and — increasingly — independent ratings agencies. A retirement record is an honest receipt for a transaction. It is not a quality certificate for the underlying tonne.

I labour the point because a lot of carbon-marketing copy elides it. "Verified by Verra" is not a synonym for "high quality." It means the project followed a Verra methodology and was issued credits accordingly. The retirement layer is the bookkeeping. The integrity layer is upstream. Both matter. They are not the same thing.

Why we plug directly into the registries

IMPT.io retires one tonne of CO₂ for every hotel booking made on the platform, and we pay for that tonne out of our commission. That commitment only means something if the retirement is real, traceable, and inspectable by the customer who triggered it. So from the start the architecture had to plug into the source-of-truth registries rather than rely on a broker's spreadsheet.

The Verra integration and the Gold Standard registry connection give us two things. The first is direct read access to project metadata — vintage, methodology, country, co-benefits, validator — so we can present a faithful description of what a customer's tonne actually represents. The second is a retirement workflow that produces a public, registry-issued retirement record with a serial number anyone can look up, including the customer.

The customer side is simple by design. After a booking, the confirmation includes a retirement reference. Click it and you land on the registry's own public retirement record, on the registry's own domain, with the serial range, the project, the vintage, the retirement date, and the beneficiary. We are deliberately not the source of truth. The registry is. We just hand you the door key.

The shape of a carbon registry API

A few notes for engineers, because the carbon registry API surface is less standardised than people assume. Verra and Gold Standard expose different endpoints, different authentication flows, different rate limits, and different concepts of what an "account" is. Retirement is not a single atomic call across registries. It is a sequence — credit selection, transfer to a retirement account, retirement instruction, beneficiary metadata, confirmation polling. Each step can fail in its own interesting way.

The patterns we settled on:

• Idempotency keys on every retirement request. A booking ID maps to one retirement attempt. Retries are safe. No double-retiring under network jitter.
• State machines per retirement, not per booking. The booking is done the moment the customer pays. The retirement is a separate, durable workflow that can take minutes or hours and must survive deploys.
• Reconciliation jobs that walk the registry, not our database. Every night we ask the registries what we retired today, and we match that against what we think we retired. Drift gets a ticket.
• Beneficiary metadata that is human-readable. The retirement is on behalf of the customer's booking, identified in a way they can verify without us in the loop.
• An on-chain anchor. We write a hash of the retirement record on-chain so the link between booking and retirement cannot be quietly rewritten. The registry remains the legal source of truth. The chain is a tamper-evident witness.

That last point is where blockchain earns its place in this stack and nowhere else. We do not pretend the chain is the registry. We do not tokenise tonnes that already exist as registry serials. We just notarise the linkage so a reader five years from now can confirm the booking made on Tuesday corresponds to the serial retired on Wednesday corresponds to the project issued in a given vintage.

The offset audit trail, end to end

An offset audit trail is only as good as its weakest hop. Ours runs as follows. A customer makes a booking. The booking is recorded with a unique reference. A retirement workflow opens against that reference. Credits are selected from a pre-funded inventory under our retirement account at the relevant registry. The retirement instruction is issued to Verra or Gold Standard with the booking reference embedded as beneficiary metadata. The registry confirms with a serial range and a public retirement URL. We hash that confirmation and anchor the hash on-chain. We expose the registry URL and the on-chain anchor on the customer's confirmation page and in their account history.

Anyone — customer, journalist, auditor, regulator, sceptic — can walk that chain in either direction. From the booking forward to the registry. From the registry serial back to the booking, via the on-chain anchor. There is no step that depends on trusting IMPT's word for it. That is the whole design intent.

We were not first to think along these lines. The wider voluntary market has been moving toward this kind of transparency for several years, partly under pressure from journalism that exposed double-counting and partly because corporate buyers got tired of being unable to defend their claims in public. The interesting work now is making the trail not just available but legible. A serial number is technically public. A serial number presented next to a project description, a methodology, a vintage, and a one-click registry link is actually useful.

What this does not solve

None of the above tells you whether a given tonne should have been issued in the first place. Methodology quality varies. Some baselines are tighter than others. Some project types — improved forest management at certain scales, some renewable energy in mature grids — have come in for legitimate criticism. A robust retirement layer cannot rescue a weak issuance layer. We choose project portfolios with that in mind, lean toward methodologies and project types with stronger track records, and rotate as the science and the ratings move. We will get some of those calls wrong. Anyone honest in this space will.

The other thing the audit trail does not solve is the deeper question of whether offsetting belongs in a corporate climate strategy at all. The defensible position, and the one IMPT operates from, is that reduction comes first and offsetting handles the residual. A hotel booking has an unavoidable footprint until aviation, ground transport, and building energy decarbonise in earnest. While that work goes on, retiring a verifiable tonne for each booking is a real, finite contribution. It is not a substitute for the harder work upstream. It is a receipt that the residual was addressed, not waved away.

What to do this week

If you are a buyer of carbon credits at any volume, ask your provider for a sample retirement record this week and try to verify it without their help. Open the registry. Search the serial. Read the project page. If you cannot complete that loop in five minutes from a public browser, the offset audit trail is not working, regardless of what the marketing says. If you are a developer building offset functionality into a product, plug into Verra and Gold Standard directly, treat retirements as durable workflows rather than fire-and-forget calls, and publish the registry URLs to your end users. At IMPT we are continuing to broaden the project mix behind the per-booking tonne, tightening the reconciliation between bookings and serials, and getting the customer-facing retirement record into a shape where a teenager could verify it on a phone. That, more than any claim we could make on a homepage, is what carbon-positive has to mean if the words are going to keep their meaning.