The world will need a voluntary carbon market that is large, transparent, verifiable, and environmentally robust. Today’s market, though, is fragmented and complex. Some credits have turned out to represent emissions reductions that were questionable at best. Limited pricing data make it challenging for buyers to know whether they are paying a fair price, and for suppliers to manage the risk they take on by financing and working on carbon-reduction projects without knowing how much buyers will ultimately pay for carbon credits. Overall, the market is characterized by low liquidity, scarce financing, inadequate risk-management services, and limited data availability. - McKinsey TSVCM report.


Climat is creating a framework for a web3 native carbon registry. Existing carbon registries are centralized databases that maintain balances of issued and retired carbon credits. A Web3 native registry can bring existing and new registries onto Blockchain. Instead of centralized databases, registries databases are now maintained by registries on a smart contract. The contract manages carbon credit issuances, trade, retirement; in Blockchain speak, these are: Carbon credit token generation event (TGE) + Token minting, token transfers, Token burning. This can allow any of the DeFi/AMM/Perp/Options Dapps to use the carbon credit tokens (CCT) as collateral on their platform; in addition, potential buyers/liquidity providers would be able to view full traceability of the details of the project and regular tech based MRV details.

Climat Blockchain

The native registry based tokenization of carbon credits would open up the market of ~$200billion of DeFI to authentic carbon credits. Another benefit is fractionalization of credits - for example if 10 credits are minted, then even 0.1credits can be bought/sold in DeFi since this might be more accessible to all retail investors across the globe. The credits would immediately be able to bridge to DeFi apps, which brings about global liquidity and price discovery to the credits. Projects that haven’t yet been verified are termed as provisional projects. These projects can also be tokenized and DeFi could act as a means of financing for these projects till they generate carbon credits and a pledge via a smart contract can be provided to investors.

If there are any issues with the project, the MRV enables registries to not mint further tokens. This would be the first time a registry is natively minting CCTs on-chain; this prevents double counting of credits or misrepresentation of the underlying credits - for example if 1000 credits are minted on a centralized database and 5000 credits are tokenized, it is difficult for users to discern the linkage between the token and the underlying credits. Having all data from origination to retirement on-chain provides full traceability to tokenized credits.

Extension of the Climat framework

As per our framework, each project that generates carbon credits is a separate ERC20 Token. ERC721 or NFTs will not work as each token of a project will be fungible unlike an NFT which is Non-Fungible. As the Blockchain, Climat will be using the Polygon Blockchain and will initially be a Dapp (Decentralized Application) on Polygon. Post launch and participant onboarding, Climat will branch into a Polygon Supernet Blockchain, meaning Climat will in essence be it’s own Blockchain with it’s own validators. Validators can collect fees from transactions on the Climat Blockchain. We would approach sustainability focused companies/organizations to be validators once there are enough Dapps on Climat, which makes it financially viable for these organizations.

This framework can also be extended to other types of credits such as biodiversity credits. In addition, tech based MRV can be added to the framework to directly add data into the Blockchain, hence removing any possibility of data linkage/modification.

Climat carbon credit smart contract architecture

Standard ERC20 contract
  • Project name/Token name
  • Project ID/Token ID

Registry contract
  • Project name
  • Project ID
  • Verifier
  • Registry that issues the Token
  • Type of Token - carbon, plastic, biodiversity
  • Type of project - NBS, energy.
  • Total Tokens to be issued (this can vary depending on project performance)
  • Tokens minted on monthly/quarterly/annual basis


Pre-Tokenization workflow
  1. Project created on Climat by PD (Project Developer)
  2. Submitted for Screening
  3. Internal Climat screening - accepted
  4. Potential Verifier selected by PD
  5. Verifier provides report
  6. Registry views the verified project
  7. Project under review in registry
  8. Registry verifies and submits the report.
  9. Registry assigns Total tokens to PD
  10. Registry mints tokens from crediting period till date
  11. Registry regularly mints Tokens
  12. PD gets tokens in their wallet

Tokenization workflow

Registry contract deplotes standard ERC20 contract
Registry contract gets the contract address of the ERC20 contract and type of contract (to accommodate later changes to make ERC721 contracts as well)
Creation of project token, minting of token to project developer - done by registry
Mint call happens to ERC20, and other info like total supply goes to ERC20 contract
Burn/retirement happens on ERC20
Token transfer is also ERC20 token functionality
Registry contract is the admin of the ERC20 contract

Private key management

Pilot version: In the first version, the Climat team will manage the private keys for project developers and the registry.
Version 1: PD and Registry can choose to create their own wallet and Climat will transfer ownership to their wallet.
Version 2: Social key recovery mechanisms in place for PD, registry, verifier.

Integration with Carbon exchanges

When an order comes onto any carbon exchange, the exchange has to tell the registry to call the transfer/burn contract on the ERC20 token.
The workflow remains the same as it is, but registry contract now calls the ERC20 contract to update ownership rather than only their database.
Climat will provide a simple SDK to the registry to interact with the Blockchain smart contracts.
Version 1: Registry updates their database then updates ownership on the contract.
Version 2: Registry updates the smart contract directly, hence holding the registry on the contract itself rather than a database.
APIs and SDKs created by Climat allows exchanges to create wallets for customers and facilitate trade of tokens on the behalf of the customer.
Exchanges are free to charge any fees they want, while each trade is charged a 0.05% fee by the contract for Climat.

Role of the registry

Maintain Blockchain wallets for sellers and buyers.
Buyers/sellers can also maintain their own wallets if they wish.
Registry administers Token generation of projects.
Registries mint tokens on Token contract and transfer to project developers’ account.
Registry charges minting fees to project developers.

Climate risk model

In addition to showcasing provisional and registered projects to potential buyers, Climat is working on integrating climate risk models that showcases potential risk to projects from climate related natural disasters. The Climate risk model gives a “risk score” for existing/provisional carbon credit projects that determines the potential risk of damage to the project due to climate disasters. Initially it is a dashboard that shows: project location live images through open source satellite images, social media feeds + news that tags the project location, historical climate issues with the location, predicted future climate related potential disasters near the location through rcp 8.5 models.

Why blockchain

  • Immutable database, full traceability.
  • No double counting of credits.
  • Global registry linked immediately to global DeFi platforms resulting in liquidity and price discovery for carbon credits.
  • 24/7 global markets.
  • Decentralized governance process on setting rules for verification.
  • Creating standards for carbon credits like erc20 or erc721 to accommodate multiple standards and additional benefits.
  • Uniform pricing on a single chain.
  • Interoperable registry possibly with compliance markets.