Carbon Retirement Over HTTP: The Klima x402 Endpoint

Klima Protocol now operates an x402 endpoint, co-developed with Carbonmark, that lets any AI agent or ordinary HTTP client retire tokenised carbon credits on the Base blockchain through the Klima Protocol Retirement Aggregator. The endpoint discovers available carbon liquidity, quotes live prices, prepares the retirement transaction, and resolves a public Carbonmark certificate once the retirement confirms, in addition to registry certificates for credit types where supported. This post explains what the endpoint does, where the x402 standard came from, and why payment rails that machines can use matter for the carbon market.

Why carbon retirement was never built for software

Retiring a carbon credit has historically been a human process wrapped around institutional infrastructure. A buyer identifies a project, negotiates access through a broker or marketplace, opens a registry account or relies on an intermediary who has one, settles payment through banking rails, and waits for the retirement to be recorded. Each of those steps assumes a human is in the loop to carry out these manual processes and communication steps. The overall flow, and its individual steps, cannot be completed by a piece of software acting on its own.

That assumption is becoming a constraint on the market's future scalability. Software agents now execute real tasks end to end: they book services, manage cloud workloads, procure inputs, and reconcile accounts. An organisation that wants its systems to compensate for emissions as they occur (per shipment, per flight booked, per unit of compute consumed) has had no way to plug carbon retirement into those systems, because the market's interfaces were designed for procurement cycles rather than transactions. The gap is structural: carbon demand increasingly originates inside software, whilst carbon settlement still happens outside it.

What is x402? A payment standard three decades in the making

The x402 standard takes its name from HTTP status code 402, "Payment Required", which was reserved in the original HTTP specification in the 1990s and then sat unused for roughly three decades. The web's designers anticipated that clients would one day pay for resources natively, over the same connection used to request them, but no payment infrastructure of the era could settle machine-to-machine transactions instantly and programmatically. The code remained a placeholder.

Coinbase revived it in May 2025, publishing x402 as an open standard that puts the dormant status code to work. The flow is deliberately simple: a client requests a paid resource, the server responds with 402 and machine-readable payment terms, the client signs a stablecoin payment authorisation (a stablecoin being a digital token designed to hold a fixed value, typically one US dollar), and retries the request with that authorisation attached. Settlement happens onchain in seconds, without accounts, API keys, or card networks. Cloudflare and Coinbase subsequently announced a foundation to steward the standard in September 2025, and in April 2026 the Linux Foundation launched the x402 Foundation as the standard's neutral home, with a membership spanning payment networks, cloud providers, and onchain infrastructure. The standard has been adopted rapidly across the agentic-payments ecosystem because it solves a general problem: it gives software a way to pay for things.

For the carbon market, the relevance is direct. If a retirement can be requested, priced, paid for, and proven over HTTP, then carbon retirement becomes a capability any application or agent can embed: not a procurement project but a function call.

What the Klima x402 endpoint does

The Klima x402 endpoint exposes the protocol's retirement infrastructure on Base mainnet through five interfaces, each doing one job. Reads are free and never move funds; the only cost of a retirement is the onchain protocol fee, which is computed by deterministic rules and collected by the settlement contract inside the retirement transaction itself.

• Discover: lists the carbon classes and credits currently retirable, each with registry, vintage, available liquidity, and a reference price in USDC per tonne. Filters allow an agent to ask, for example, for everything retirable at or under $20 per tonne.
• Quote: returns the live onchain price for a specific tonnage, including the protocol fee, the total, and a suggested maximum input with a slippage buffer, alongside a plain-language summary. Where the caller does not specify a credit, the protocol selects the most liquid credit in the class that can cover the requested amount.
• Prepare: hands back the unsigned transaction data (a token approval followed by the retirement) for the caller to submit as one atomic batch from their own wallet.
• Certificate: resolves the public Carbonmark certificate for a confirmed retirement, the shareable record of project, vintage, tonnage, and beneficiary.
• Manifest: a standard discovery file at /.well-known/x402.json that x402 directories and agent crawlers index automatically, so agents can find the service without being pointed at it.

The distinction between reference prices and executable prices is worth noting, because it reflects how the protocol actually works rather than how a brochure would describe it. Discovery returns a marginal price, accurate near one tonne; larger orders move along the protocol's automated market curve, and a 100-tonne retirement in a thin class can cost several times the quoted spot rate per tonne. The quote interface exists precisely so that a caller, human or machine, always sees the true cost of their size before committing. Execution terms are quoted from live protocol state, not set by any intermediary: no party discretionarily prices, allocates, or reverses a retirement.

Retirement through the protocol is irreversible by design. A retired credit is permanently burned; it cannot be undone, refunded, resold, or reused, and credits supplied to the protocol are handled solely for retirement rather than held for trading or speculation. The certificate's beneficiary name and public message must therefore be set before the transaction confirms, because the record cannot be edited afterwards. Retirements can be as small as a thousandth of a tonne, which matters for the embedded use cases discussed below.

Two ways to retire, including one with no wallet infrastructure at all

The endpoint supports two integration paths, and the difference between them is where much of the practical significance lies. The first path is self-directed: an agent or application calls discover, quote, and prepare, then signs and submits the returned transaction batch from its own Base account, paying its own network gas. This suits integrators who already operate onchain infrastructure and want full control of submission.

The second path removes that requirement entirely. In the relay flow, the caller signs a single standard token authorisation (the same signature format any x402 payment uses) covering the retirement cost, the protocol fee, and a gas reimbursement, all slippage-buffered. A Klima executor then submits the transaction onchain and is reimbursed out of that signed budget, with any unused buffer refunded in the same transaction. The signer needs a balance in USDC or kVCM and nothing else: no ETH for gas, no prior approvals, no Base account. For a conventional company whose treasury holds a stablecoin balance, or an agent operating with a constrained wallet, the entire lifecycle of a carbon retirement collapses into one HTTP exchange and one signature.

For agent builders the fastest route is the Klima plugin for Base MCP, the toolkit that lets AI agents operate wallets on Base. A user can instruct an agent in plain language, for instance "retire 2 tonnes of carbon under $15 per tonne, beneficiary Acme Corp", and the agent runs discovery, quoting, and preparation, presents the cost, submits the batch under a single approval, and returns the certificate URL as proof.

What agentic payments enable in the carbon market

The immediate use cases follow from making retirement callable. An e-commerce platform can retire a computed tonnage per order at checkout and attach the certificate to the receipt. A logistics or travel system can compensate per shipment or per booking as each transaction settles, rather than reconciling an annual estimate months later. A software company can tie retirement to metered usage, compensating compute or API consumption continuously. In each case the granularity that once made micro-retirement uneconomic (the paperwork was the same for one tonne as for ten thousand) disappears, because the marginal cost of an additional retirement is a transaction rather than a process.

The more consequential use cases are the ones where no human is in the loop at all. An autonomous agent managing an organisation's operations can hold a carbon budget and spend it against live prices, retiring more when prices are favourable and pausing when a class is thin, under rules its operator sets. Sustainability reporting changes character too: because every retirement resolves to a public, timestamped certificate naming the beneficiary, an auditor or counterparty can verify a company's claims directly against the public record rather than against a PDF. Impact becomes a live, verifiable data feed.

It is worth being precise about what this is not. The endpoint is not a trading venue, and the credits reachable through it are not inventory: they can only be retired, never withdrawn, resold, or held for appreciation. The protocol's tokens confer no ownership of or claim on protocol-held carbon, and nothing in the system offers yield or returns. What x402 adds is not a new financial surface but a new access surface: a way for software to reach an existing, rules-based retirement mechanism.

A foundation for climate finance, not just a feature

Step back from the individual use cases and a structural point emerges. Two layers had to exist before carbon retirement could become embedded infrastructure, and each is inert without the other. The first is liquid, standardised carbon supply: Klima's carbon classes group credits with sufficiently similar characteristics under shared execution terms, so that a machine can ask for "biochar at market" rather than negotiating a bespoke bilateral trade. The second is a payment and access standard that software everywhere already speaks: x402 over HTTP. Blockchain-enabled liquidity without machine-usable rails serves only crypto-native users; machine-usable rails without standing liquidity have nothing to execute against. Together they make carbon retirement composable, in the way that mapping, payments, and messaging became composable when they moved behind open interfaces.

Composability is how the next wave of carbon-market innovation gets built by people other than Klima. A climate-fintech product, a corporate treasury tool, an ERP sustainability module, or a machine-to-machine marketplace can now treat verified carbon retirement as a component, the way developers treat payment processing as a component, without operating registry relationships or market infrastructure of their own. Every one of those integrations routes retirement demand through transparent, rules-based execution to the projects supplying credits: demand that originates in software still ends as finance delivered to climate projects. The market's long-standing frictions of fragmentation, opacity, and slow settlement are not argued away here; they are engineered around, one interface at a time. For the broader picture of how Klima and Carbonmark are building this market structure on Base, see Bringing Carbon Markets Onchain. On Base.

How to get started

The endpoint is live on Base mainnet and free to call. Developers can start with the discovery interface at x402.klimalabs.com, review the integration documentation and the Base MCP setup guide on the Klima Labs tooling site, and test a small retirement end to end (the minimum is one kilogramme of carbon). Agent builders can install the Klima retirement plugin for Base MCP and drive the full flow in plain language. Direct onchain integration with the Retirement Aggregator remains available for callers who do not want the HTTP layer at all. We invite carbon buyers, developers, and agent-platform builders to try the flow and tell us where it should go next.