# Welcome to the Klima Protocol Open-source, rules-based infrastructure for carbon markets. ### **Klima Protocol documentation** Explore the documentation to understand how to interact with the Klima Protocol and use its features effectively. Documentation is divided into five **handbooks** and a **reference** section. Click on the tiles below to get started.
Cover image
Carbon buyer’s handbookOffset carbon emissions by retiring carbon credits directly from Klima./files/ZczQtnjICaIp6hJCyhh9/pages/aOjs4gC5WzIpifbjuGsn
Carbon seller’s handbookSell your carbon credits to Klima and get paid instantly./files/WKgD3m9ugGZXbXEuvEio/pages/cjjAIantplQ4zwPm3Kb2
Liquidity provider’s handbookParticipate in Klima’s liquidity markets./files/McuwUfG3OsgEo7ewfiGH/pages/89aqf4WOr2PLSsiy1z03
Governance handbookPut your kVCM and K2 tokens to work./files/txlYZgFx1vDX0fn4FFFQ/pages/5U4ZCumezbqLJTYjY8dJ
Developer’s handbookBuild with Klima and bring the carbon market to your users./files/pQ2hYrDStpAYpwCwRsi2/pages/s5Y4fX4dsxHBCbWTIOUI
ReferenceLearn the Klima Protocol’s design and tokenomics./files/YDk0g0KE90lUFJOPC9i4/pages/4Pd1W6NRNoWXqSIuL31V
# What is Klima? Klima is open, rules-based market infrastructure for carbon markets, delivering transparency and real-time execution for carbon credit retirements. {% hint style="danger" %} **Non-investment notice**\ Klima is market infrastructure, not an investment product. Participation does not confer ownership of protocol-held assets or any right to redeem, withdraw, or monetise carbon credits, which may only be accessed for retirement via irreversible destruction. {% endhint %} ### Introduction Today’s spot carbon markets are fragmented, slow, and opaque. These structural issues prevent the market from scaling into a reliable, accessible market and restrict capital flow to high-quality climate projects. The core challenges are well-known: * inconsistent standardisation * limited fungibility * fragmented liquidity * opaque pricing * slow settlement * lack of trust and comparability Klima exists to address them. By providing transparency and standardisation, and a transparent incentive mechanism for those who contribute. The infrastructure takes no fees or retained surplus. *** ### How Klima Works Klima coordinates carbon market activity through open-source smart contracts on the [Base network](https://www.base.org/): * **Dynamic market parameters:** The protocol automatically adjusts execution rates and eligibility constraints based on live market inputs (e.g. new supply, retirement demand). * **Supplier-centric:** Suppliers sell carbon credits directly to the protocol at programmatically determined, real-time prices ([Carbon seller’s handbook](/carbon-sellers-handbook/overview-for-carbon-suppliers)). * **Instant retirement:** Buyers purchase carbon retirement certificates at guaranteed, real-time rates ([Carbon buyer’s handbook](/carbon-buyers-handbook/overview)). * **Always-on:** Liquidity providers supply continuous market depth, enabling market access and consistent execution ([Liquidity provider’s handbook](/liquidity-providers-handbook/overview)). * **Incentive-driven value flow:** Protocol incentives are used to encourage liquidity provision, usage, and system integrity ([Governance handbook](/governance-handbook/overview)). The result is a coordinated, credibly neutral, rules-based market. *** ### What Klima Enables **Standardised carbon classes** * Credits with shared characteristics are grouped into transparent carbon classes, improving comparability and accessibility. **Real-time, rules-based execution** * Smart contracts price and settle transactions continuously based on live market inputs, reducing dependence on intermediaries. **24/7 market access** * Users can transact across a range of whitelisted carbon credits, at any time, with low slippage and consistent execution quality. **Transparent market data** * Pricing, inventory composition, flows, and value distribution are visible onchain. Market participants and auditors can inspect, analyse, and build on the data in real time. **Impact over extraction** * The Klima Protocol charges no fees and does not extract value. Protocol incentives are allocated according to transparent, pre-defined rules to support participation and system operation. # Roadmap & Timeline The Klima roadmap from 2021 to 2026, covering onchain carbon markets, Carbonmark, Base network migration, kVCM/K2 launch, and the first Klima Protocol app. The Klima Protocol is set to fully launch early in 2026, marking the culmination of a four-year evolution from an innovative DeFi carbon protocol into a sustainable, transparent, and open climate infrastructure that facilitates efficient, global carbon markets. {% stepper %} {% step %} ### 2021: **Foundation and onchain carbon market innovation** * KlimaDAO launched on Polygon in October 2021 as a pioneering carbon-backed DeFi protocol. It quickly grew its treasury to hold over 20 million tokenised carbon credits, jump-starting the development of an onchain carbon market and reaching a peak market capitalisation of $1.1 billion. > **Key milestone:** Establishment of the first large-scale decentralised carbon finance protocol. > {% endstep %} {% step %} ### 2022: **Scaling carbon market infrastructure and product expansion** * Despite market headwinds, including a major registry pausing blockchain integrations, KlimaDAO scaled its carbon market infrastructure by facilitating large-scale carbon offset retirements. * To promote real-world adoption, KlimaDAO expanded its product suite with Klima Infinity, the Carbon Dashboard, the Climate Pledge Portal, and the Carbon Retirement Aggregator. * By year-end, KLIMA’s circulating supply surpassed 1 million tokens, and reported over 500,000 tonnes of CO₂ offset through its infrastructure. > **Key milestone:** Major expansion of product offerings to drive adoption despite market challenges. > {% endstep %} {% step %} ### 2023: **Ecosystem consolidation and marketplace launch** * Focus shifted to strengthening infrastructure and consolidating the ecosystem. * KlimaDAO developed and launched Carbonmark, a comprehensive carbon credit marketplace aggregating tens of millions of credits from hundreds of projects. Carbonmark became the primary interface for market participants, improving transparency and trading efficiency. > **Key milestone:** Launch of Carbonmark, centralising carbon credit marketplace activity. > {% endstep %} {% step %} ### 2024: **Network migration and governance evolution** * KlimaDAO successfully migrated its protocol from Polygon to the Base blockchain, addressing issues of high gas fees and improving transaction throughput while aligning closer to Coinbase’s ecosystem. * The DAO established KlimaDAO Japan, launching Japan’s first tokenised carbon marketplace compatible with the Government of Japan's J-Credits system. * Carbonmark enhanced its functionality by expanding registry integrations, introducing credit fractionalisation, automating purchase and retirements via API, and improving marketplace features. * By mid-2024, KlimaDAO and Carbonmark facilitated the retirement of over 1 million tonnes of carbon credits on behalf of customers, demonstrating significant real-world climate impact through its digital infrastructure. > **Key milestone:** Migration to Base and geographic expansion with KlimaDAO Japan. > {% endstep %} {% step %} ### 2025: **Klima 2.0 white paper and Fair Launch** * By 2025, Carbonmark handled over 12,000 carbon retirement transactions per month, leveraging KlimaDAO's liquidity to support operations. * KlimaDAO created the Klima Foundation, marking the beginning of the shift to a more resilient organisational structure. * The Klima 2.0 white paper was released, introducing new concepts for onchain carbon, including a dual-token architecture comprising the tokens kVCM and K2. It proposed a more autonomous design for accruing carbon credits, decentralised liquidity mechanisms, and a new, more codified governance framework. * The Klima 2.0 Fair Launch ran through to Q4, culminating in the Token Generation Event (TGE) for kVCM, where participants were able to claim Klima's new tokens. The Klima 2.0 TGE was designed to prioritise its long-term community, with no preferential VC terms, and a clean launch onto Aerodrome with liquidity supported via Klima's own assets, not third-party market makers. > **Key milestone:** Publication of Klima 2.0's white paper and successful Fair Launch event. > {% endstep %} {% step %} ### 2026: Klima Protocol launch * Following the TGE, the protocol's utility tokens traded on Base DEXs including Aerodrome and Hydrex, setting the stage for the full deployment of the infrastructure layer. * On February 24 the Klima Protocol officially launched its new application, completing the transition from KlimaDAO to a fully decentralised, scalable climate finance infrastructure. > **Key milestone:** Official launch of the Klima Protocol and decentralised carbon market price discovery. > {% endstep %} > {% endstepper %} # Overview for Carbon Buyers Retire carbon credits through Klima at programmatically determined, real-time execution terms. Receive blockchain-verifiable proof of retirement via Carbonmark and optionally link beneficiary details. ### Overview The Klima Protocol does not resell carbon credits. It facilitates the **retirement** of eligible credits. Retirement permanently consumes the environmental claim associated with a credit and cannot be reversed. If you are seeking to compensate for emissions; whether for yourself, your organisation, or your customers, this section explains how to retire carbon credits using the Klima Protocol. #### Functionality for Buyers * Retire supported carbon credits at quoted, real-time execution terms. * Receive a publicly verifiable proof-of-retirement certificate via Carbonmark. * Associate beneficiary details (e.g. name, purpose of retirement). * Select from supported carbon classes, vintages, and methodologies. #### Important Limitations * The protocol does not provide transferable credits. Only retirement is supported. * Retirements are permanent and irreversible. Refunds are not possible once executed. * Not all retirements include certificates from external registries. Some credits originate natively onchain (e.g. CMARK), while others may have been permanently removed from registries prior to protocol handling (e.g. UCR). *** ### Why Use Klima for Carbon Retirement? Klima provides rules-based, onchain infrastructure designed to make carbon retirement accessible and operationally efficient. #### Programmatic Settlement Retirements execute via smart contracts without bilateral negotiation or manual reconciliation. Settlement is finalised onchain upon successful execution. #### Continuous Execution Terms The protocol applies transparent, rules-based mechanisms to service retirement demand across supported carbon classes. Execution terms update continuously based on observable supply and retirement activity. #### Onchain Traceability Protocol activity is recorded on a public blockchain. This provides a transparent and auditable record, from credit intake through retirement. # Why offset carbon with Klima? Offset carbon with Klima for fast, programmatic settlement, deep onchain liquidity, real-time pricing, and transparently traceable retirements on a public blockchain. Klima’s raison d’être is to make the retirement of carbon credits as accessible and operationally simple as possible, in order to maximise the real-world impact of carbon markets. Retiring carbon credits via the Klima Protocol provides several practical advantages, primarily derived from its rules-based, onchain execution model. ### **Programmatic settlement** Carbon retirements are executed via smart contracts, allowing buyers to complete transactions without bilateral contracting, manual reconciliation, or delayed settlement. This removes counterparty dependency and enables retirement to be finalised in seconds rather than days or weeks. ### **Continuous pricing and availability** The protocol applies a rules-based liquidity mechanism to service retirement demand across supported carbon classes. Pricing parameters update continuously based on observable supply and retirement activity, reducing uncertainty around execution terms. ### **End-to-end traceability** All protocol activity is recorded on a public blockchain, providing a verifiable chain of custody from carbon credit issuance on the originating registry, through protocol handling, to the final consumption of the credit’s environmental benefit. # Retirement Guide TO-DO: Demonstrate the retirement flow once front end is ready. # Overview for Carbon Suppliers Supply eligible carbon credits to the Klima Protocol at programmatically determined execution terms, with automated settlement. {% hint style="warning" %} Note: Carbon credits supplied to the protocol are not acquired for resale or trading and may only be accessed through irreversible retirement. Once supplied, credits are permanently removed from circulation and cannot be re-acquired or transferred. {% endhint %} ### **Overview** * Transfer a batch of eligible carbon credits to the protocol at quoted, real-time execution terms. * Receive settlement in USDC (a dollar-denominated stablecoin), or * Elect to receive kVCM, which may be used to access retirement functionality or participate in protocol coordination signalling. #### Important Limitations * Credits supplied to the protocol are **not resold or traded**. They may only be accessed for irreversible retirement. * All transfers are final. Once secured by the protocol, credits are programmatically locked until retired. * Only whitelisted credits are currently supported. * Credits must be in tokenised form. * Execution terms may update as other participants interact with the system. Currently supported registries: * EcoRegistry * Puro.Earth * Carbonmark Direct Issuance (CMARK) * Regen * UCR Under evaluation registries: * Social Carbon * International Carbon Registry (ICR) * Rainbow *** ### **Why Supply Carbon to Klima?** Klima provides structured, rules-based infrastructure for routing eligible carbon credits into retirement markets. It is designed to reduce friction in execution and settlement compared with traditional bilateral processes, enabling project developers to find a route to market, and tap into carbon credit retirement demand. #### Programmatic Settlement Carbon supply is executed via smart contracts. Eligible credits are transferred and settled according to predefined rules, without bespoke contracting or manual reconciliation. #### Continuous Execution Terms The protocol applies transparent intake conditions and execution parameters based on observable supply and retirement activity. Suppliers can view applicable execution terms at the time of transfer. #### Demand Connectivity Retirement demand may originate from direct smart contract interaction or through third-party integrations. Platforms such as Carbonmark provide APIs that enable marketplaces and service providers to facilitate retirement using protocol-supported credits. #### Traceability All protocol activity is recorded on a public blockchain. This provides a transparent record from credit intake through final retirement. # Supplier Guide To do: screenshots of liquidating a credit once the front end is ready. {% hint style="info" %} The full protocol and app are scheduled for release in January 2026. The actions described below will become available at that time. {% endhint %} {% hint style="info" %} COMING VERY SOON: [Carbonmark.com](http://carbonmark.com/) will make it easy to instantly liquidate your credits to Klima for USD, via digital dollars like USDC. Until then, this guide is for users who already know how to operate a blockchain wallet on the Base network. {% endhint %} # Overview for Liquidity Providers Provide liquidity to kVCM trading pairs to support access, receive a pro-rata share of trading fees generated on Aerodrome, and, where applicable, become eligible for protocol-defined incenti {% hint style="warning" %} Providing liquidity is a voluntary activity to support market operation. Liquidity provision is not an investment product and does not guarantee returns. {% endhint %} ### **Overview** All carbon interactions within the Klima Protocol are mediated via the kVCM token. To support efficient access and execution, liquidity is concentrated in two primary trading pairs: * **kVCM<>USDC:** a stablecoin pairing that allows all users to enter or exit the ecosystem via dollar denominated settlement assets. * **kVCM<>K2:** A protocol-token pair enabling conversion between kVCM and K2. Liquidity for these pairs is hosted on [**Aerodrome**](https://aerodrome.finance/) a decentralised exchange on the Base network. Any user holding the assets required for a given pair may provide liquidity. #### **1. Provide liquidity on Aerodrome only** Users may supply liquidity directly via Aerodrome’s standard interface without interacting with the Klima Protocol. Liquidity providers receive a pro-rata share of trading fees generated by the pool. **kVCM<>USDC Pool:** * **0.3% fee** per trade. * 90% of fees distributed to liquidity providers (for unstaked positions).1 *If a user provides 10% of pool liquidity and the pool generates $1,000 in trading fees during a given period, the user would receive approximately $90, subject to pool mechanics and position status.* **kVCM<>K2 Pool:** * 0.01% fee per trade * 90% of fees distributed to liquidity providers (for unstaked positions) 1 This assumes user positions are **not “**staked**”** on Aerodrome**.** User positions that **are** staked on Aerodrome will receive 100% of trading fees, denominated in Aerodrome's native AERO token instead of the principal deposit tokens, according to Aerodrome's own rules. [Learn more.](https://aero.drome.eth.limo/docs) #### **2. Provide Liquidity Through the Klima Protocol** Users may deposit eligible, unstaked Aerodrome LP positions into the Klima Protocol: * Deposited LP positions remain on Aerodrome. * Trading fees continue to accrue according to Aerodrome’s mechanisms. * Deposited positions may become eligible for protocol-defined incentives, subject to predefined lock conditions and standard durations. Summary: * Trading fees are claimed via Aerodrome. * Protocol incentives (if applicable) are claimed via the Klima interface. * Incentive distribution follows deterministic, rule-based logic. * Participation does not confer ownership rights, profit-sharing rights, or claims on protocol-held carbon. *** ### **Risks** Providing liquidity involves material risks, including but not limited to: * **Token price volatility:** Asset values may rise or fall. * **Impermanent loss:** Divergence in token prices may reduce the value of a liquidity position relative to holding the assets separately. * **Smart contract risk:** Liquidity positions rely on open-source smart contracts deployed on Base. * **Market risk**: Trading volumes, liquidity depth, and incentive conditions may change over time. * **Regulatory risk:** Participation may be subject to jurisdiction-specific requirements. Participants should carefully assess these risks before providing liquidity. # Overview for Stakeholders Understand how the Klima Protocol’s dual-token system and governance support carbon pricing signals, protocol coordination, and non-extractive participation. {% hint style="warning" %} Participation in the Klima Protocol does not confer ownership, profit rights, redemption rights, or claims on protocol-held carbon. Governance signals influence protocol parameters but do not create obligations, guarantees, or entitlements for participants. {% endhint %} ### Introduction The Klima Protocol is open infrastructure for the carbon markets, designed to improve market outcomes through transparent, rules-based mechanics. The protocol acts as a central hub for carbon, bringing together liquidity, vote-lock governance, a user-aligned incentive model, and an accessible architecture. The Klima Protocol is user-owned and user-governed. It charges no fees and does not retain surplus; protocol incentives are distributed according to predefined, transparent rules. All who interact with the protocol operate on the same terms. The protocol is deployed on the Base blockchain, where all activity, pricing, settlement, and inventory state occur in real time. Carbon market participants can interact directly with the protocol, integrate with its liquidity layer, or build new applications on top of it. ### Protocol mechanics The Klima Protocol prioritises liquidity, transparency, and coordinated participation across the carbon markets, addressing the fragmentation and opacity common in today’s OTC-dominated environment. To achieve this, the Protocol distributes protocol incentives according to predefined, transparent rules, without retaining surplus, to participants who: * Provide liquidity: ensuring low-slippage entry and exit for carbon users; or * Participate in carbon pricing: determining how the protocol values different carbon classes. User votes generate pricing signals that inform protocol parameters governing eligibility, pricing bounds, and intake limits for carbon projects as per their alignment with different classes of carbon. Carbon acquired by the protocol becomes available to buyers of retirement certificates only. Incoming supply and retirement demand shape the inventory that is made available for retirement demand: a live, onchain reflection of market activity. The inventory is visible at all times, allowing voters to refine future pricing parameters based on what the market supplies, retires, and how valuations evolve. ### Tokens The Klima Protocol uses two governance tokens and interacts with a variety of tokenised carbon credits. {% hint style="info" %} Tokenomics refers to the economic model and structure surrounding a digital token within a blockchain project, encompassing aspects like total supply, distribution methods, and incentives for holders or users. It outlines how tokens are created and used to drive value, such as through staking rewards, governance voting, or transaction fees. {% endhint %} #### kVCM – Portfolio & pricing * Floating supply (starting at 20 million), expanding and contracting as carbon is acquired or retired. * Functions as a unit of account and pricing reference for protocol-facilitated carbon retirement. * Can be locked to signal pricing preferences and eligibility constraints. #### K2 – Risk & capacity * Fixed supply of 100 million, distributed programmatically as incentives. * Can be locked to vote on system capacity & stability. #### Carbon tokens – Underlying assets * Tokenised representations of specific carbon credits. * Grouped into carbon classes for efficient pricing and allocation. * Handled by the protocol for the sole purpose of facilitating retirement when users request certificates. #### Shared mechanics * All carbon is priced in kVCM terms only. * All trades settle in kVCM. * Participants may acquire or dispose of kVCM via the kVCM<>USDC liquidity pool. * Vote-locked kVCM and K2 and liquidity providers receive incentives. * Incentives are the sole value distribution mechanism; there is no extraction layer. *** ### Incentives Klima distributes protocol incentives to participants who provide defined services to the ecosystem, such as liquidity provision or governance signalling, according to transparent, rules-based mechanisms.
FunctionCommitmentIncentives
Time-lock kVCMUntil duration (maturity. 90- day increments.).Variable incentive accrual, calculated daily according to protocol rules.
User-lock K248 hours.Variable incentive distribution, calculated daily.
Stake liquidityUntil maturity. 90 day increments.Variable incentive distribution, calculated daily.
# How to acquire tokens? Acquire kVCM and K2 at current market prices via Coinbase or Aerodrome, and learn what you can do with your tokens next. {% columns %} {% column width="58.333333333333336%" %} {% hint style="info" %} All contracts and tokens for the Klima Protocol are deployed on the [Base etwork](https://docs.base.org/get-started/base) {% endhint %} {% endcolumn %} {% column width="41.666666666666664%" %}
{% endcolumn %} {% endcolumns %} {% hint style="danger" %} This guide is not financial or investment advice. Buying or holding tokens involves financial risk. {% endhint %} ### Summary kVCM and K2 are ERC20 tokens. There are two primary ways to acquire them: #### **1. Buy them on** [**Coinbase.com**](https://www.coinbase.com/) **using your preferred payment method.** * This is the **easiest way** to get kVCM and K2. * Coinbase may charge a small fee. * The tokens will be held in your Coinbase Exchange account. If you want to connect to the Klima Protocol app and put your tokens to work, you will need to transfer them to a Web3 wallet that you control (for beginners, we recommend [Base App](https://www.coinbase.com/wallet)). #### **2. Swap tokens directly on** [**Aerodrome.finance**](https://aerodrome.finance/swap?from=0x833589fcd6edb6e08f4c7c32d4f71b54bda02913\&to=0x00fbac94fec8d4089d3fe979f39454f48c71a65d\&chain0=8453\&chain1=8453)**.** * This is the **most cost-effective way** to get kVCM and K2. * This requires you have a wallet with ETH and funds to swap (USDC, ETH, etc.) * Fees are avoided because Aerodrome is the primary *Decentralized Exchange* or “DEX” where trading for K2 and kVCM takes place. ### Tutorials #### How to buy kVCM and K2 on Coinbase Coinbase makes it very easy! {% columns %} {% column width="41.66666666666667%" %} 1. Log on to your Coinbase account 2. Search for the token names: “*Klima Protocol kVCM*” or “*Klima Protocol K2*”. 3. Follow the instructions to purchase your desired quantity with your preferred payment method. {% endcolumn %} {% column width="58.33333333333333%" %}
{% endcolumn %} {% endcolumns %} #### How to buy kVCM and K2 with your wallet You may choose to swap directly on Aerodrome using your own Wallet. This allows you to retain custody of the tokens without an intermediary like Coinbase. This also ensures you are getting the best possible market rate with minimal fees. {% hint style="info" %} This tutorial assumes you have set up a Web3 Wallet with a few cents worth of ETH on Base. It also assumes you have starting funds (USDC, ETH, etc.) ready to swap. If your funds are on a different network like Ethereum or Polygon, you can move them to Base [using a token bridge](https://docs.base.org/base-chain/network-information/bridges-mainnet). {% endhint %} {% columns %} {% column width="41.66666666666667%" %} 1. Visit [aerodrome.finance/swap](https://aerodrome.finance/swap?from=0x833589fcd6edb6e08f4c7c32d4f71b54bda02913\&to=0x00fbac94fec8d4089d3fe979f39454f48c71a65d\&chain0=8453\&chain1=8453) 2. Select your token to sell, and token to buy. 3. Connect your wallet. 4. Submit the transaction to “Approve spend”. 5. Submit the transaction to Swap. {% endcolumn %} {% column width="58.33333333333333%" %}
{% endcolumn %} {% endcolumns %} Aerodrome performs automatic routing so you can sell any token and receive kVCM or K2 at the best price. Beware that large swaps will impact the price of the token itself. Always confirm addresses on our official [Contract addresses](/links/contract-addresses) page. ### Now what? What can you do with the kVCM or K2 tokens you have acquired? Yield-bearing locks and carbon class governance will open with the full protocol launch in January 2026! Until then, you can head to Aerodrome and put your tokens to work by providing liquidity. Make sure you understand the risks of being a liquidity provider before proceeding. # Overview of Carbon Classes Learn how the Klima Protocol organises individual carbon credits into structured “carbon classes.” {% hint style="warning" %} Carbon classes define eligibility and execution parameters only. They do **not** create fungible financial instruments, redemption rights, or secondary trading markets. {% endhint %} ### What Is a Carbon Class? A carbon class groups carbon credits with sufficiently similar characteristics to enable structured intake and retirement under shared execution terms. Credits within a class must share relevant attributes, such as: * Methodology * Technology type * Certification standard * Geography * Vintage * Registry Classes allow comparability across credits while preserving project-level specificity. Suppliers and buyers interact with the protocol through these classes: * **Suppliers:** Provide eligible tokenised credits into a class at the prevailing execution rate. * **Buyers:** Access credits from a class for irreversible retirement at the prevailing execution rate, either directly or via third-party interfaces.
Although classes standardise execution terms, users may select specific underlying credits within the class when supplying or retiring. For example, a carbon supplier holding Biochar Project 1, could supply that credit to the Biochar carbon class if they are happy with the current execution terms, without needing to hold Biochar Project 2 or 3. Similarly, a user looking to retire carbon credits could choose to retire Biochar Project 3 only (i.e. they would not to receive a randomised unit from within the class).
### Dynamic Structure Carbon classes are not static. They may evolve to reflect changes in methodologies, registries, or market conditions. For example: * A new methodology may be added to an existing class. * A methodology may be deprecated for future intake while existing inventory remains eligible for retirement. * A new class may be created to separate credits previously grouped together. Changes affect eligibility for future intake. Credits already held by the protocol remain available only for retirement. *** ### Whitelisting Framework Whitelisting determines which credits are eligible for protocol intake under a given carbon class. Whitelisting may involve: * Creating a new carbon class * Adding credits to an existing class * Restricting new intake for specific credits Eligibility criteria may include: * Certification standards * Methodology relevance * Vintage parameters * Geography * Public issuance and retirement data * Registry approval for blockchain integration Note: All integrated credits require explicit permission from the originating registry to mitigate double-counting risk and ensure compliance with registry terms. *** ### Governance & Process The initial whitelisting process will involve consultation with ecosystem partners. Proposals and feedback will be documented publicly. Over time, governance mechanisms may incorporate structured token-based coordination. All proposals, feedback, and decisions will be published prior to implementation to maintain transparency. *** ### Carbon Classes at Launch
Carbon classWhitelisted projectsLiquidity at Launch
Ocean Alkalinity EnhancementLimenet – CMARK02~14 tonnes
Biochar

PUR-527-2023

PUR-718-2024

~100 tonnes
Avoided Deforestation

ECO-22

ECO-114

~20,000 tonnes
Regen – City Forest Credits

REGEN-C02003-2022

REGEN-C02004-2021

REGEN-C02006-2022

~2,000 tonnes
UCR - SolarUCR-80-2021
UCR-170-2021
UCR-81-2021
UCR-50-2021
UCR-433-2023
UCR-367-2022
UCR-420-2023
UCR-356-2022
UCR-419-2023
UCR-285-2023
UCR-436-2023
UCR-438-2023
UCR-437-2023		~87,000 tonnes
UCR - WindUCR-121-2022
UCR-341-2022
UCR-150-2021
UCR-320-2022
UCR-164-2022
UCR-423-2022		~254,000 tonnes
### Current Carbon Class Data Up-to-date information concerning current carbon liquidity, carbon classes, carbon credit retirement data, and more, is accessible via our Ecosystem Dashboard. *Note that this dashboard is currently being relaunched--a link will be provided here once that process is completed.* # Regen Network Credits This page explains how Regen Network registered credits are made available in Carbon Classes, what happens when you retire, and how to interpret your retirement receipt. ### What you’re actually buying Some credits in Klima are **REGEN NETWORK credits mirrored to Base**: * **Regen Network is the registry of record** for these credits. * On Base, you interact with an **ERC-20 representation** of those credits. * The ERC-20 exists so trading and retirement can happen with **fast settlement** on Base, while the underlying credit provenance remains anchored to Regen. {% hint style="success" %} **Key point:** Base activity is real and verifiable on-chain, but the **canonical registry retirement** is executed on REGEN on a **periodic sync schedule**. {% endhint %} ### How the mirroring model works {% stepper %} {% step %} ### Escrow on Regen Network (backing) Regen Network sets aside a specific quantity of underlying credits in a dedicated account to ensure that they can not be consumed or transferred for any other reason. This account is public and transparent, making it easy to verify. {% endstep %} {% step %} ### 1:1 issuance on Base (representation) Carbonmark mints an ERC-20 token on Base that represents those escrowed Regen Network credits **1:1**. {% endstep %} {% step %} ### Supply into Klima Carbon Classes Holders of the Base ERC-20 tokens can choose to sell them to the Klima Protocol. {% endstep %} {% step %} ### Retirement on Base + periodic sync to Regen Network When you retire on Base: * The Base token is retired on-chain (the token is removed from circulation and a retirement event is emitted). * Regen Network later executes the matching retirement on Regen Network during the next sync cycle. {% endstep %} {% endstepper %} ### What happens when you retire #### Immediately (Base) Your retirement produces: * An on-chain retirement transaction on Base (timestamped, verifiable). * A retirement receipt reflecting the Base retirement details (quantity, token, transaction reference). #### Later (Regen Network) Regen Network performs reconciliation on a schedule: * Base retirements are aggregated per token since the last checkpoint. * Equivalent underlying credits are retired on Regen Network. * Reconciliation records are maintained to map Base totals → Regen Network retirement actions. ### Timing expectations * **Contractual minimum:** Regen Network syncs **at least monthly** * **Operational target:** **weekly** when feasible If you have an internal reporting deadline (audit, client delivery, compliance memo), plan around the **monthly minimum** unless you have explicit confirmation a weekly sync has occurred. ### What your retirement receipt proves #### Your receipt is evidence of: * A completed retirement of the **mirrored token on Base** * On-chain proof: transaction hash, timestamp, quantity, and token identity on Base * A committed operational process to retire the equivalent credits on Regen Network during the next sync window #### Your receipt is not immediate evidence of" * A per-transaction Regen Network retirement entry at the moment you retire on Base * A registry retirement ID that is instantly available and linkable from the receipt ### How double counting is prevented This model is designed to prevent the same underlying credits from being sold/retired through multiple paths: * **1:1 backing:** mirrored tokens minted on Base must be backed by escrowed Regen Network credits. * **Dedicated escrow accounts:** underlying credits used for mirroring are set aside specifically for this integration. * **Base retirements drive required Regen Network retirements:** the Base retirement totals define what must be retired on Regen Network in reconciliation. * **Exception handling:** if an invariant is violated (e.g., minted > escrowed), sales/retirements may be paused while the discrepancy is resolved. ### How to verify a retirement When you need “proof” quickly, here’s what you can provide right away: 1. **Base transaction reference** * The retirement transaction hash and timestamp (Base). 2. **Asset identity** * The ERC-20 token contract address on Base. * The token symbol and batch/vintage labeling used in Klima. 3. **Quantity and unit** * Retired amount in **tCO₂e** (always include units). 4. **Registry framing** * A one-line statement that Regen Network is the registry of record and registry retirement occurs on a periodic sync cycle. If your counterpart requires the registry entry, provide the Base proof immediately and follow up after the next sync window with the Regen Network-side retirement reference. ### Supported Regen Network credit types During launch, only specific Regen Network batches are included. **Token naming convention**\ `REGEN-{category_id}{project_id}-{vintage_end}` * `C02` is a category ID and is included. * Vintage shown is the **end** of the serial range. | Project | Regen Network project ID | Regen Network serial / range | Token format | | ------------------------------------- | ------------------------ | ----------------------------- | ------------------- | | Buena Vista Heights Conservation Area | C02-003 | C02-003-20200630-20220629-001 | `REGEN-C02003-2022` | | Harvey Manning Park Expansion | C02-004 | C02-004-20210102-20211207-001 | `REGEN-C02004-2021` | | St. Elmo Preservation Project | C02-006 | C02-006-20210216-20210215-001 | `REGEN-C02006-2022` | ### Glossary * **Mirrored credit (Base):** ERC-20 representation of an escrowed Regen Network credit. * **Registry of record:** The authoritative registry where the underlying credit exists and is ultimately retired (Regen Network). * **Retirement (Base):** On-chain retirement of the mirrored token on Base (verifiable immediately). * **Retirement (Regen Network):** Canonical registry retirement performed on Regen Network during reconciliation. * **Reconciliation / sync:** The periodic process mapping Base retirements → Regen Network retirements. ### FAQ
“Why doesn’t the registry retirement appear immediately?” Because this POC uses **periodic reconciliation** rather than per-transaction registry retirement.
“Is my retirement still valid?” Your Base retirement is valid and verifiable immediately. The Regen Network retirement is the registry follow-through executed during the next sync window.
“What if I need my Regen certificate quickly?” Assume sync happens in minimum 1-month intervals. We can not provide any hard guarantees for sync time. However, your Carbonmark certificate serves as a guarantee that the credit was consumed and that you've already claimed the environmental benefit.
# Overview for Developers Build with Klima using permissionless functions to automate carbon retirement, fetch real-time execution quotes, execute supply and retirement transactions, and analyse market data via the Carbonmark. All Klima Protocol functions are permissionless, meaning they can be automated and integrated into any software system. Examples include: * Programmatically retiring carbon credits for your customers or your organisation. * Integrating access to retirement-eligible carbon credits into existing applications or storefronts. * Fetching real-time execution quotes for carbon supply and retirement. * Analysing carbon market activity and protocol state via onchain data. * Building automations or alerts based on protocol pricing signals and activity. For now, try experimenting with the [Carbonmark API](https://docs.carbonmark.com/) which already supports many of these capabilities today. # Protocol overview The Klima Protocol is open, rules-based infrastructure designed to support carbon credit intake and retirement through transparent execution terms and onchain settlement. {% hint style="info" %} For the mathematical specification of the Klima Protocol, see the [white paper](http://whitepaper.klimaprotocol.com/). For the technical specification, see the [code on GitHub](https://github.com/klimadao). {% endhint %} {% hint style="warning" %} Participation in the Klima Protocol does not confer ownership, profit rights, redemption rights, or claims on protocol-held carbon. Carbon credits handled by the protocol may only be accessed through irreversible retirement. {% endhint %} ### Introduction Klima prioritises transparency and coordinated participation in a market often characterised by fragmentation and bilateral negotiation. There are three ways that users can interact with the protocol: 1. **Submit coordination signals:** indicate carbon class preferences through governance. 2. **Carbon execution:** supply or retire carbon credits with the protocol against live, transparent execution rates. 3. **Provide liquidity:** contribute to the ecosystem's liquidity, enabling users to enter or exit the system. Coordination signals inform the protocol's execution parameters for carbon credit intake and retirements. Carbon suppliers may supply eligible credits to the protocol when the quoted execution rate meets their preferences. Carbon credits handled by the protocol are made available exclusively for irreversible retirement. The protocol does not facilitate secondary trading of unretired credits. Supply and retirement activity shape the protocol’s carbon inventory: a live, onchain record of available carbon for retirement.
*** ### Carbon Inventory Carbon credits differ by geography, registry, methodology, technology, and vintage. The protocol groups eligible credits into defined **carbon classes**. When supplied, an eligible credit is assigned to a carbon class based on its characteristics. Carbon classes may evolve over time according to protocol rules.
Within a class, credits share identical execution terms. When a retirement is requested, the quoted execution rate reflects the class parameters at that moment. Execution parameters adjust according to observable supply, retirement activity, and coordination signals. *** ### Coordination layer The protocol combines observable activity with participant signalling to update execution parameters in real time. This is achieved through three mechanisms: #### 1. Standardised Unit of Account The protocol uses kVCM as the unit of account for protocol-facilitated carbon activity: * Execution terms are expressed in kVCM units * kVCM is minted when eligible carbon is supplied * kVCM is burned when carbon is retired This mint-and-burn mechanism functions as internal accounting. It does not confer ownership rights or claims over carbon assets. #### 2. Supply & Retirement Dynamics Execution rates reflect carbon inventory depth relative to observed retirement activity. Carbon classes with lower available inventory relative to demand require more kVCM per tonne for execution. Classes with deeper inventory require less. This ties execution terms to system state rather than discretionary input. #### 3. Participant signalling kVCM holders may time-lock tokens and allocate them to specific carbon classes. Allocations influence the relative execution terms of a class. Signal weight scales with the quantity and duration of locked tokens.
This mechanism enables parameters to be influenced without granting ownership rights, profit claims, or asset control. *** ### Liquidity Layer Participants must be able to acquire or dispose of kVCM to interact with the system. This is facilitated through decentralised liquidity pools, primarily: * kVCM ↔ USDC * kVCM ↔ K2 Liquidity providers deposit token pairs into decentralised pools and receive a share of conversion fees.
Liquidity positions may optionally be deposited into the protocol and become eligible for protocol-defined incentives. *** ### Incentive System To encourage sustained participation, the protocol distributes native token incentives according to predefined rules. When tokens are locked for governance signalling or liquidity participation, they become temporarily unavailable for transfer.
Incentive distribution reflects: #### 1. Amount and Duration Incentive allocation increases with greater token commitment and longer lock durations, according to protocol formulas.1 1 The quantity of incentives as a function of commitment time is given in [Section 3.1.1](https://whitepaper.klimaprotocol.com/#sec-synthetic-yield-and-forward-delivery-curve) of the Klima Protocol white paper. #### 2. Relative Participation Incentive distribution between signalling and liquidity adjusts automatically based on the proportion of tokens committed to each function. These adjustments are rule-based and non-discretionary. *** ### K2 Token While kVCM influences execution terms, K2 provides a mechanism to signal system capacity tolerance. Participants may allocate K2 to carbon classes under short-duration locks.
Higher K2 allocations reduce the sensitivity of execution terms to new intake or retirement activity. This allows a class to accommodate greater transaction volume before execution parameters adjust materially. K2 does not represent ownership or claims on carbon assets. *** ### Aerodrome Liquidity Infrastructure Liquidity pools are implemented using Aerodrome infrastructure on Base. Participants deposit token pairs and receive LP tokens representing pool positions. Liquidity providers receive a share of conversion fees generated by pool activity. LP positions may optionally be locked within the protocol and become eligible for protocol incentives according to predefined rules.
# Governance What allocation does, how it shapes the protocol, and when doing nothing is perfectly fine. If you’ve locked **kVCM** and/or **K2**, you may see an option to **allocate** those locked tokens to **carbon classes**. This page explains what allocation does, why it exists, and how to make a reasonable choice when market information is limited. ### The short version Allocation is how stakeholders **collectively guide the protocol**. When you allocate locked kVCM to a carbon class, you increase the weighting of that class in the protocol's inventory. When you allocate locked K2, you help that class handle more activity without materially shifting its execution rate. Allocation has almost nothing to do with individual incentives. If you're unsure, doing nothing is a perfectly valid choice. ### What allocating actually does A **carbon class** is a curated grouping of similar carbon credits (e.g. a specific removal type, or a category like avoided deforestation) with shared execution terms. Allocating your locked tokens to a class doesn't give you carbon credits, and it doesn't create any claim on inventory. What the allocation process does to is add your market signal to the collective. The protocol reads the aggregate of all stakeholders' allocations and uses that to set parameters for each class. There are two types of allocation.
### kVCM allocation → inventory weighting Allocating time-locked **kVCM** to a class increases that class's **weighting** in the protocol's carbon inventory. In aggregate, kVCM allocations determine the execution rates at which the protocol takes in and retires carbon for each class. A class with **no** kVCM allocated to it has no defined execution rate, meaning the protocol cannot process carbon supply or retirement for that class. ### K2 allocation → execution capacity Allocating locked **K2** to a class increases the protocol's **capacity** to handle carbon activity in that class without materially shifting its execution rate. In practice, more K2 allocation means the difference between intake and retirement terms stays tighter, even as volumes grow. **In simple terms:** * **kVCM** allocation collectively answers: *How much weight should this class carry in the inventory?* * **K2** allocation collectively answers: *How stable should execution terms be for this class as activity scales?* ### Why allocate? Allocation exists so that stakeholders — not a central authority — can guide which carbon classes the protocol supports and how it supports them. It is a coordination mechanism built into the protocol's rules-based model. There are a few reasons you might choose to allocate: **You want the protocol to hold more of a particular class in its inventory.** For example, if a type of carbon credit aligns with your values—say, durable removals or community-based projects—you may want to allocate kVCM to that class to increase its weighting in the protocol. The more kVCM a class has, the more active it can be. **You want the protocol to operate more smoothly for a particular class.** If you expect a class to see growing activity and you'd like its execution rate to remain stable as it scales, allocating K2 to that class increases its capacity. This helps the protocol handle volume without large shifts in the terms between intake and retirement. **You want to ensure a class remains active.** For the protocol to process carbon intake or retirement for a class, that class needs kVCM allocated to it — without it, there's no defined execution rate, and the class is effectively inactive. If you care about a particular class staying functional, allocating even a modest amount of kVCM helps ensure the protocol can continue to operate around it. #### Why *not* allocate Choosing not to allocate is a reasonable position. A few common reasons: **You're not sure which classes you'd want the protocol to prioritise.** Carbon quality is nuanced and evolving. If you don't want to take a stance on questions like permanence, methodology, or additionality, staying unallocated avoids signalling a preference you're not confident in. **You don't feel strongly about protocol direction right now.** Locking tokens already participates in the system. Allocation is optional coordination on top of that. **You'd rather wait.** Allocation can be a "later" decision. If the available information doesn't support a confident choice, leaving tokens unallocated is entirely valid. Staying unallocated does not mean missing out on earnings. Allocation is about guiding the protocol, not about individual returns. ### Common questions #### If I allocate, do I own carbon credits in that class? No. Allocation influences protocol parameters and class prioritisation. It is not a claim on inventory or a redemption right. #### Does allocation affect what I earn? Allocation is a coordination mechanism. It shapes how the protocol operates, not what individual stakeholders receive. #### If I don't allocate, am I hurting the protocol? Not automatically. Locking tokens already contributes to the system. Allocation adds an additional layer of collective guidance on top. #### Can I allocate later? Yes. If you feel under-informed now, you can leave your tokens unallocated and revisit the decision when you have a clearer view. #### What if everyone allocates to the same class? That reflects community consensus — but it also creates concentration risk. Stakeholders who value long-term resilience across a diverse set of classes may choose to allocate to less popular classes as a counterbalance. #### What if I want to "set and forget"? That's fine. If you have a clear view of which classes you'd like the protocol to support, you can allocate accordingly and leave it. There's no need to actively manage allocations — though it's worth revisiting if new classes are added or class definitions change. # Governance (Archived)
A brief overview of carbon class governance is as follows: * Carbon classes do not define the price of a given credit within the protocol; they define the basket of credits that can be influenced by Protocol mechanics. * kVCM and K2 holders vote across classes to signal: * carbon acquisition preferences (portfolio weight) * the rate of carbon acquisition and disposal (portfolio capacity) * These governance signals affect: * protocol purchasing behaviour * supply diversity * long-term portfolio exposure * which classes grow or shrink over time * Overall carbon pricing is influenced by: * kVCM and K2 governance allocations * kVCM token price * supply and demand for each class * the protocol’s acquisition and retirement traffic * Classes **should** reflect long-term potential for: * transaction volume * growing liquidity * price appreciation * relevance to major buyers (e.g. due to compliance market applicability) * Misallocating purchase power may result in the protocol holding assets with insufficient demand or stagnant pricing. For more detail on the role of carbon classes within the Protocol, visit [Overview of Carbon Classes](/carbon-class-handbook/overview-of-carbon-classes). ### Whitelisting Whitelisting carbon means defining which carbon credits may enter the ecosystem via a carbon class, as follows: * Whitelisting or expanding a class allows new carbon types to enter the system. * Creating a new class may allow a number of new or existing carbon credits to be integrated into Klima. * Whitelisting of classes is the primary non-economic governance input within Klima. * Over time, the whitelisting process may evolve to allow token-voting delegations; or a formal advisory council with voting power. * Initially it is a centralised process undertaken by the Klima Protocol team, through engagement with market stakeholders. ### Initial governance approach * The main engagement route around carbon class curation will be taken bilaterally between the Klima Protocol team and members of its Partnership Programme. This includes: * Anaxee * Regen * ICR * Super Biochar * UCR * A quarterly RFP is issued to partners for their feedback on new and existing classes. * Whitelisting will be “demand led”: new whitelisted classes (or credits) must have justification that there is legitimate demand. * Partners and the Protocol team will also consider attributes such as: * Certification standard, ICROA status, CCP labels. * Methodology relevance to compliance schemes (e.g., CORSIA). * Vintage criteria. * Geography and project type. * Publicly available data on liquidity and volume. * **All credits must have permission from the host registry to technically integrate with their system.** ### Transparency * Open-source governance principles emphasise inclusivity, clarity, and auditability – whilst the initial process will be centralised, it will be conducted with maximum transparency, ensuring all market stakeholders understand the process, and can react to decisions fairly. * All RFPs, feedback and decisions will be published publicly on the Klima Protocol forum. * Submissions may be anonymised at the request of the participant. # Liquidity Learn how Klima’s kVCM liquidity pools internalise carbon inventory, route all economic activity through a single fungible token, and let users provide the liquidity that powers the system.
### Overview * Klima does not develop liquidity for carbon on external infrastructure (OTC venues, AMMs, Order Book Exchanges): the Protocol itself holds all carbon liquidity **internally.** * Instead, all economic activity in Klima is facilitated via the kVCM and K2 tokens, users may want to acquire tokens to interact with the Protocol, or find themselves holding tokens and wanting to exit, after interacting with it. * The Protocol therefore incentivises Liquidity Providers to contribute tokens to its trading pairs across two pools to facilitate activity: * kVCM<>USDC Liquidity Pool:
 * entry and exit point to the ecosystem * facilitates carbon exchange with Protocol (i.e. USDC ↔ kVCM ↔ Carbon) * kVCM<>K2 Liquidity Pool: * entry and exit point to K2 token * Allows LPs & voters rebalance positions ### Liquidity utilisation – Examples Liquidity providers (and the token Liquidity Pools they contribute to) enable all core flows to be executed, as follows: #### **Carbon suppliers (sellers)** * **They want to:** Sell carbon credits to the Protocol at the real-time bid price and leave the ecosystem with USD * **How it works:** They receive kVCM directly from the Protocol, in exchange for carbon * **The role of liquidity:** Swap the kVCM the receive in return for carbon, for USDC to exit the ecosystem\* * **Pool:** kVCM<>USDC #### **2. Carbon buyers (retirements)** * **They want to:** Purchase carbon retirements at the real-time purchase price * **How they do it:** Pay kVCM in return for a retirement certificate * **When they use liquidity:** Acquire kVCM for USDC to pay for the retirement1 * **Pool:** kVCM<>USDC 1 Note: USDC<>kVCM liquidity pool routing may be handled automatically by third-parties to reduce friction for users who are unfamiliar with Web3 wallet management and custody. [Carbonmark](https://carbonmark.com/) will provide this service shortly after Klima’s launch. #### **3. Carbon governance participants (depositors)** * **They want to:** Influence Protocol carbon parameters * **How it works:** Deposit kVCM or K2 into the Protocol to steer carbon pricing and capacity * **The role of liquidity:** Acquire kVCM or K2 with USDC * **Pools:** kVCM<>USDC and kVCM<>K2 #### **4. Governance participants exiting** * **They want to:** Exit their principal position, or earned incentives. * **How it works:** Tokens are de-allocated and withdrawn from the Protocol and held liquid * **The role of liquidity:** Swap kVCM or K2 for USDC to leave the ecosystem * **Pools:** kVCM<>USDC and kVCM<>K2 #### **5. Liquidity providers** * **They want to:** Earn incentives for providing liquidity to the Klima Protocol. * **How it works:** Tokens are deposited into the Protocol's Liquidity Pools. * **The role of liquidity:** Allow new Liquidity Providers to enter / exit. * **Pools:** kVCM<>USDC and kVCM<>K2 ### Deep dive: liquidity design #### Klima separates liquidity into two distinct layers. * **Carbon liquidity:** is fully internalised: the Protocol itself holds all carbon inventory. It sets reference prices using transparent user inputs and supply-and-demand parameters, and evaluates carbon classes on a like-for-like basis. * **Economic liquidity:** kVCM is the Protocol’s standardised unit of account — all value exchange (i.e. carbon sales, retirements, and governance allocations) is routed through the token. This creates a unified quoting convention for carbon, and an execution layer for Protocol interactions. #### **Standardised, capital-efficient market structure** * Standardising all economic flows through a single Protocol token simplifies routing, improves execution consistency, and creates a liquid reference price for carbon classes. * Prioritising deep liquidity in one fungible asset enables the Protocol to maintain an always-on, liquid market in service of carbon credit transactions. * Driving value exchange through kVCM, whilst maintaining carbon liquidity internally means that carbon trading itself does not need to be outsourced to external infrastructure. Avoiding the associated risks and costs across of maintaining carbon liquidity for carbon across order book infrastructure, OTC markets, and AMMs. #### **User-focused liquidity design** * Liquidity provision is one of the three core functions in Klima 2.0’s incentive distribution system ([alongside locking kVCM and K2](/governance-handbook/overview)). The Protocol favours user-contributed liquidity rather than external rent-seeking intermediaries, supporting a decentralised and incentive-aligned liquidity base for the ecosystem. #### **Intended outcomes** * **Scalability:** The Protocol can lean on its issuance and incentive mechanisms to scale-up liquidity and meet carbon demand without needing to raise or borrow significant external capital (i.e. carbon, dollars). This supports a more competitive ecosystem with lower structural costs. * **Value distribution:** Lower structural costs, with no need to payback loans or prioritise Venture Capital returns, in-turn allows value to be distributed to participants rather than internalised by the Protocol. This upholds the Protocol’s core design principle of impact over extraction. #### **Market prices and USDC** * USD is the dominant reference currency in carbon markets. Therefore, the only external asset that the Protocol maintains alignment with is USDC via the kVCM<>USDC pool, ensuring: * Users can interpret protocol-level carbon pricing (quoted in kVCM) in familiar USD terms. * Correlation between protocol tokens and high-beta crypto assets is minimised.
# Incentives
# Token Distribution The Klima Protocol uses two native tokens and onchain carbon tokens to operate its infrastructure. ### Summary #### kVCM * Floating supply (starting at 20 million), expanding and contracting as carbon is acquired or retired. * Serves as the medium of exchange for all carbon trades with the Protocol. * Can be locked to influence carbon class execution rates. #### K2 * Fixed supply of 100 million, distributed programmatically as incentives. * Can be locked to vote on carbon class capacity. #### Carbon tokens * Tokenised representations of specific carbon credits. * Grouped into carbon classes for efficient pricing and allocation. * Acquired by the protocol and retired when users redeem certificates. #### Shared mechanics * All carbon is priced and executed in kVCM terms only only. * Participants can engage with, or withdraw from the ecosystem, via the kVCM<>USD liquidity pool 24/7. * Vote-locked kVCM, user-locked K2, and liquidity providers may receive protocol incentives in accordance with pre-defined rules. ### Initial State #### **kVCM** * Initial kVCM token distribution: 20 million. * Floating supply. | Cohort | Proportion | Quantity (M) | Note | | --------------------------------------------- | ---------- | ------------ | ---------------------------------------------------------------------- | | KLIMA Holders (Fair Launch participants) | 77.5% | 15.5 | Via Fair Launch claim function | | Latecomers migration contract (KLIMA holders) | 10% | 2 | To enable remaining KLIMA conversion to be converted at a reduced rate | | Treasury | 10% | 2 | For liquidity & future carbon allocation needs. | | 01X Consulting FZE (“01X”) - | 2.5% | 0.5 | Per contractual agreement, compensation for model development. | #### K2 * Initial K2 token distribution: 7 million. * Final distribution: 100 million. * Fixed supply. | Cohort | Proportion | Quantity (M) | Note | | ------------------------ | ---------- | ------------ | ------------------------------------------------------------------------------------------------- | | Treasury | 4.5% | 4.5 | Locked in kVCM/K2 LP (24 months), or held in reserve. | | 01X | 2.5% | 2.5 | 24 month lock providing LP in kVCM/K2 | | Fair Launch Participants | 40% | 40 | Allocated proportionally against Fair Launch (distributed over 48 month period — see white paper) | | Programmatic Incentives | 40% | 40 | Protocol native incentive (distributed over 48 month period — see white paper) | | Ecosystem Grant Reserve | 5% | 5 | TBD | | Product Development Fund | 5% | 5 | TBD | | pKlima Holders | 3% | 3 | Distributed over 48 month period — see white paper | # Glossary # Protocol Implementation & Upgrade Transparency This document explains how the protocol’s software implementation is maintained, upgraded, and secured over time. ### 1. Core Economic Operation The core economic behaviour of the Klima Protocol, including execution logic, carbon intake conditions, retirement functionality, and incentive distribution, is governed by deterministic smart contracts and participant inputs. Day-to-day protocol operation does not involve discretionary decision-making over: * individual transaction execution, * execution rates, * allocation of carbon assets, or * distribution of protocol-defined incentives. All participants interact with the same predefined rule set under equivalent conditions. ### 2. Implementation Controls The current implementation includes administrative and upgrade mechanisms. These mechanisms exist for technical and security purposes, including: * addressing software vulnerabilities, * migrating or upgrading contracts where necessary, * improving technical reliability, security, or operational resilience * maintaining compatibility with evolving technical standards. Administrative controls are not used to manage individual user positions, selectively alter execution outcomes, or provide preferential economic treatment. ### 3. Upgrade Principles If upgrades or migrations occur: * Changes will be publicly disclosed in advance where practicable. * Modifications will apply uniformly to all participants. * Historical transactions and completed retirements will not be retroactively altered. Upgrades relate to software implementation, system integrity, and long-term sustainability. They do not constitute discretionary portfolio management or asset management on behalf of participants. ### 4. Experimental Infrastructure The Klima Protocol is experimental infrastructure operating within an evolving technological and regulatory landscape, and market context. Upgradeability is a feature of responsible system development and risk management. While the implementation may evolve, economic outcomes continue to arise from predefined rules and participant interaction rather than active asset management or engineered financial returns. Participants should understand that interacting with the protocol involves engagement with evolving open-source software infrastructure.
# Fair Launch Klima's Fair Launch ran from April 2025 until October 2025. A final window for genuine legacy KLIMA holders who missed the it can convert KLIMA into kVCM at a fixed 1 : 1 rate. Fair Launch participants can visit the app at: [launch.klimaprotocol.com](https://launch.klimaprotocol.com/) ### Overview The Klima 2.0 Fair Launch opened on 25 April 2025, giving legacy KLIMA holders a structured way to migrate from the old tokenomics into the new protocol. The primary migration window ran for six months, and the new protocol tokens, kVCM & K2, went live in October 2025. The protocol fully launched in February 2026. The Late Comers Provision is a final, time-limited safety net for holders who did not migrate during that window, whether they missed the announcements, were disengaged, or only re-engaged after the new protocol launched. To support these holders, the Klima Foundation reserved 2,000,000 kVCM. The intent was simple: anyone who missed the window should still be able to transition on fair terms, rather than being forced to accept a poor secondary-market rate between KLIMA and kVCM. This provision is closing. By the closing date below, holders will have had roughly 18 months to migrate. Demand for the late-comers route has been minimal, and the reserved liquidity is better put to use within the protocol than left idle indefinitely. ### Who this is for You are eligible if all of the following are true: * You hold legacy KLIMA tokens. * The KLIMA you wish to redeem has been held continuously in the same wallet since before the Fair Launch began (25 April 2025), and can be verified on-chain. * You want to convert your KLIMA into kVCM on fixed terms rather than via the secondary market. If you already migrated during the Fair Launch, this provision does not apply to you. #### Why the holding requirement exists The provision exists to give genuine legacy holders a fair exit, not to create a trade. A fixed 1:1 rate, offered to anyone, would let people buy cheap KLIMA on the secondary market and redeem it for kVCM at par, capturing the spread at the Foundation's expense. To prevent this, only KLIMA held continuously since before 25 April 2025 is eligible. KLIMA acquired after the Fair Launch opened does not qualify, regardless of when or how it was obtained. The eligible amount is capped at the balance the wallet held immediately before the Fair Launch began; later additions to that wallet are not eligible. ### Closing date The Late Comers Provision closes on 1st September 2026 or when the reserve is finished. After this date, the reserved kVCM will be returned to the Foundation and placed in a long-term lock for protocol governance.\ \ No further late-comer redemptions will be accepted. To convert after closure, your only route will be the open secondary market, at whatever rate prevails there. If you intend to use this provision, contact us before the closing date. Allow time for the verification and processing steps described below, last-minute requests may not complete before the deadline. ### Exchange ratio Redemptions are made at a fixed rate: **1 KLIMA → 1 kVCM** The rate is flat and does not change with market conditions, the amount held, or the timing of your request. Every legacy KLIMA token redeemed under this provision receives one kVCM. ### How to redeem The process is handled manually so that holdings can be verified before any tokens are issued. 1. Email us at stating that you wish to redeem under the Late Comers Provision. 2. Verification. The team will verify, on-chain, that the wallet has held the KLIMA continuously since before the Fair Launch began (25 April 2025), and will walk you through the steps needed to prove ownership of that wallet. Only KLIMA meeting this holding condition is eligible. 3. Conversion. Once verified, the eligible KLIMA is exchanged for kVCM at the 1:1 rate and the kVCM is delivered to the wallet that originally held the KLIMA. Please include enough detail in your first email to get started, the wallet address holding your KLIMA and the approximate amount you wish to redeem are a good start. The team will reply with anything further they need. ### After closure Once the provision closes on the date above: * The reserved kVCM returns to the Foundation. * No further redemptions are accepted under these terms. * Legacy KLIMA can still be traded on the open market, but no longer at the fixed 1:1 rate offered here. ### FAQ **Why is this closing now?** Holders have had roughly 18 months to migrate since the Fair Launch opened in April 2025. Take-up of the late-comers route has been very low, and the reserved liquidity is more useful active within the protocol than held in reserve indefinitely. **What if I miss the closing date?** You can still convert KLIMA to kVCM on the secondary market, but not at the fixed 1:1 rate. The whole purpose of this provision is to give you a fair, fixed alternative before that window shuts — so reach out early. **Is the 1:1 rate negotiable or variable?** No. It is fixed at one kVCM per KLIMA for every redemption under this provision. **Why must I have held the KLIMA since before the Fair Launch?** Because a fixed 1:1 rate offered to anyone would be an arbitrage opportunity. Limiting eligibility to KLIMA held continuously since before 25 April 2025 ensures the provision serves the genuine legacy holders it was meant for, not opportunistic traders. **I bought more KLIMA recently. Can I redeem that too?** No. Only the balance held in your wallet from before the Fair Launch began is eligible. Anything acquired afterwards must be traded on the open market.
# Bug Bounty Programme Effective date: 21st July, 2026 Last updated: 21st July, 2026 Status: Active ### 1. Overview Klima Protocol operates a standing, self-hosted bug bounty program covering vulnerabilities that place Protocol or user funds at risk. The program is intentionally narrow: it rewards Critical (and, at the Protocol's discretion, High) severity findings only. We do not pay rewards for Medium, Low, or Informational findings. Researchers who responsibly disclose non-critical issues will be credited if desired, but no monetary reward will be issued. This structure exists so that researcher attention is concentrated where it protects users most. This program is run under the Primacy of Rules: the terms on this page govern all submissions and payouts in full. ### 2. Scope #### 2.1 In-scope assets Klima v2 mainnet deployment contracts on Base mainnet are in scope. #### 2.2 Out-of-scope assets * Legacy KlimaDAO (1.0) contracts on Polygon * Frontend websites, documentation sites, Discord, and other off-chain infrastructure * Third-party contracts and dependencies (e.g., Aerodrome pools, bridges, oracles not deployed by the Protocol), except insofar as a flaw in our integration with them causes a Critical impact * Testnet deployments and mock/test files *** ### 3. Rewardable impacts Only the following impacts qualify for a monetary reward: #### Critical * Direct theft of user or Protocol funds (principal), whether at rest or in motion * Permanent freezing or destruction of user or Protocol funds * Unauthorized minting of $kVCM or $K2 * Unauthorized upgrade of any proxy, or takeover of admin/owner privileges * Manipulation of AAM pricing or accounting resulting in direct extraction of value from the Protocol #### High (discretionary) * Theft or permanent loss of unclaimed yield or rewards * Temporary freezing of user funds requiring intervention to resolve All other impacts — including griefing without attacker profit, gas inefficiencies, front-running of individual transactions, and theoretical issues — are not rewardable. *** ### 4. Rewards | Severity | Reward | | -------- | ------------------------------------------------------------------------- | | Critical | 10% of funds directly at risk, minimum $2,500, up to a maximum of $20,000 | | High | Up to $5,000, at the Protocol's sole discretion | * "Funds at risk" is calculated as of the time and date the report is submitted. * Rewards are denominated in USD and paid in USDC on Base. * Where the vulnerable contract can be paused or upgraded to prevent the impact, only the initial attack (before intervention) is considered when calculating funds at risk, and severity may be adjusted accordingly. * If multiple reports describe the same underlying vulnerability, only the first valid submission (by timestamp) is eligible. * One reward per underlying root cause, regardless of the number of attack paths described. *** ### 5. Submission requirements To be eligible for a reward, every submission must include: 1. A working proof of concept (PoC). A runnable test or script (e.g., Foundry/Hardhat fork test against Base mainnet state) demonstrating the exploit end-to-end. Descriptions, hypotheses, and AI-generated reports without a working PoC will be closed without review and are not eligible for reward. 2. A clear written description of the vulnerability, root cause, and impact. 3. The specific in-scope asset(s) affected. 4. A suggested remediation (optional but appreciated). Submit to: We will acknowledge receipt within 3 business days and provide a substantive response (accepted / rejected / more information needed) within 14 days. *** ### 6. Rules of engagement Security research conducted in good faith under this program is authorized, and the guidelines below exist to keep that research safe for you, for our users, and for the Protocol. We ask that you follow them: * No testing on mainnet or public testnets. All testing must be performed on local forks. * No denial-of-service attacks, spam, or automated traffic against Protocol infrastructure. * No phishing or social engineering against contributors, users, or partners. * No exploitation beyond the minimum necessary to demonstrate the vulnerability. Never access, modify, or exfiltrate funds or data belonging to others. * No public disclosure of an unpatched vulnerability. Coordinated disclosure only, after a fix is deployed and with the Protocol's written agreement. * Do not attempt to extort or condition disclosure on payment beyond the published reward terms. #### Safe harbor Klima Protocol considers security research conducted under this program in good faith to be authorized conduct. If you make a good-faith effort to comply with these guidelines, we will: * Consider your research authorized, and not pursue or support any legal action against you in connection with it; * Work with you to understand and resolve the issue quickly; and * Treat a good-faith, unintentional deviation from these guidelines as forgivable — an honest mistake in the course of good-faith research does not by itself forfeit safe-harbor protection, provided you did not cause harm to users or the Protocol, and you promptly disclose and remediate any such deviation. Safe harbor does not extend to conduct that is not in good faith, including: theft or retention of funds beyond a demonstrated proof of concept, extortion or conditioning disclosure on payment beyond the published terms, deliberate harm to users, public disclosure of an unpatched vulnerability, or initiating an exploit. Nothing in this section is a waiver of any rights of third parties, and it cannot authorize conduct that violates applicable law; where a good-faith researcher nonetheless faces third-party or legal action, we will make clear publicly that their research was authorized under this program. *** ### 7. Ineligible findings The following are explicitly not eligible for reward, regardless of framing: * Bugs already identified by auditors * Any finding without a working PoC * Issues in third-party dependencies or infrastructure * Theoretical vulnerabilities without a demonstrable, economically rational on-chain attack path * Attacks requiring privileged access (admin keys, multisig signers, governance majority); these are trust assumptions, not vulnerabilities, unless the report demonstrates how that access is obtained by an attacker * Attacks relying on external market conditions (e.g., oracle prices moving, liquidity being drained by third parties) without a Protocol-level flaw * Gas optimizations, code style, best-practice deviations, and informational findings * Vulnerabilities already mitigated by deployed pause/upgrade mechanisms where no funds can actually be lost * Sybil attacks on governance requiring capital outlay exceeding the attack's proceeds * Findings from automated scanners or AI tools submitted without validation and a working PoC *** ### 8. Eligibility * Open to anyone, except: current contributors and contractors of Klima Protocol / Klima Foundation; former contributors within 12 months of their engagement ending; and anyone who participated in the development or audit of the affected code. * Researchers must not be subject to sanctions (OFAC/UNSC) or resident in a jurisdiction where participation or payment would be unlawful. * Basic KYC (name, country of residence, wallet address) is required before payout of any Critical reward. *** ### 9. Payment process 1. Report validated and severity agreed. 2. Fix developed and deployed (researcher may be asked to verify the fix under embargo). 3. KYC completed. 4. Payment issued in USDC on Base to the researcher's provided address within 60 days of validation. 5. With the researcher's consent, credit published on the Security Acknowledgements page. *** ### 10. Lower severity findings We genuinely appreciate reports of lower-severity issues, and we will: * Acknowledge and review them on a best-effort basis * Credit the researcher publicly (with consent) We will not pay monetary rewards for them, negotiate exceptions, or respond to escalation attempts. *** ### 11. Program changes Klima Protocol may amend scope, rewards, or terms at any time. Changes apply prospectively; submissions are governed by the terms in effect at the time of submission. Reward caps will be reviewed as Protocol grows. ***
# Contract addresses These are the official contract and wallet addresses for K2, kVCM, the new Klima Protocol, and the legacy KlimaDAO system. Protect yourself by only using the links and addresses provided here. {% columns %} {% column width="58.333333333333336%" %} {% hint style="info" %} All contracts and tokens for the Klima Protocol are deployed on the [Base etwork](https://docs.base.org/get-started/base) {% endhint %} {% endcolumn %} {% column width="41.666666666666664%" %}
{% endcolumn %} {% endcolumns %} ### Tokens
NameAddress
kVCM
0x00fBAC94Fec8D4089d3fe979F39454F48c71A65d
K2
0x59081d974a0C635Fae3e8195F34f879B591B6519
### Liquidity Pools Add liquidity on [Aerodrome.finance](https://aerodrome.finance/liquidity?query=0x00fBAC94Fec8D4089d3fe979F39454F48c71A65d).
NameAddress
kVCM/USDC
0x5C0D76fab1822bDeb47308eD6028231761ED723E
kVCM/WETH
0x5e710Fe3C079182a6a2be9cA3c200317d6C34A5D
kVCM/K2
0x578f2f191C6b67D547bACA166B6B2aa9Dc8CB691
### Smart Contracts
NameAddress
FairLaunchClaim
0x88C0815B50060155179bbA3866CF30Fb18BdA787
FairLaunchStaking
0xea8a59D0bf9C05B437c6a5396cfB429F1A57B682
### 🕸️ Legacy & Deprecated Contracts
NameNetwork
KLIMA TokenPolygon
0x4e78011ce80ee02d2c3e649fb657e45898257815
KLIMA TokenBase
0xdcefd8c8fcc492630b943abcab3429f12ea9fea2
sKLIMA TokenPolygon
0xb0C22d8D350C67420f06F48936654f567C73E8C8
wsKLIMA TokenPolygon
0x6f370dba99E32A3cAD959b341120DB3C9E280bA6
Retirement AggregatorPolygon
0x8cE54d9625371fb2a068986d32C85De8E6e995f8