Token TransparencyKlima Protocol - H2 2026
kVCMInitial · B1 v1.3 · Filed 23 Jul 2026Complete
Token

Project & Team

01

Description of Project

Provide a concise narrative that clearly states each of (a)–(e) below.

  • (a) Problem the project solves — The problem the project is solving.
  • (b) Operational priorities — Provide a high-level description of how the project expects to support ongoing development and operations over time.
  • (c) High-level project overview — How the project works at a high level.
  • (d) Primary token functions — The primary functions of the token (e.g. gov participation).
  • (e) Control surface reliance — If any, briefly describe the anticipated or possible evolution of the protocol's governance/control model.

(a) Problem the project solves

Voluntary carbon markets settle transactions through bilateral, often manually negotiated processes. A credit (a tradable unit representing one verified tonne of CO2-equivalent avoided, reduced, or removed) typically changes hands through a broker or direct negotiation between a supplier and a buyer, with pricing and available inventory visible only to the parties involved in that specific trade. This makes price discovery slow and inconsistent across the market, and it means buyers and sellers often cannot see comparable terms elsewhere before transacting.

Klima Protocol provides continuous, rules-based execution for carbon credit intake and retirement. Rather than negotiating terms bilaterally, suppliers and buyers interact with smart contracts that publish execution rates and capacity in real time, based on parameters set by protocol supply and demand characteristics and governance rather than by a counterparty's individual judgment. This does not replace registries, standards bodies, or brokers, who continue to originate, verify, and distribute credits. It adds a transparent settlement and pricing layer that existing market participants can transact against.

(b) Operational priorities

The ecosystem maintains a capital base of over $3 million, held across diversified assets: USDC, ETH, veAERO and carbon credit offtake agreements. Klima Protocol's carbon credit liquidity aggregation and retirement routing services are fully functional. Klima Protocol's infrastructure and carbon liquidity serves as a foundational blockchain-enabled software layer for other builders leveraging smart contracts in the carbon market. Scaling adoption of this technology across both the supply and demand side of the market is the primary operational priority post-deployment of the protocol. This includes additional integrations with carbon registries (the primary issuer of the carbon credits that the protocol facilitates), as well as deploying demand-side infrastructure (e.g. x402, MCP, and Web2-based APIs) to scale overall ecosystem throughput.

(c) High-level project overview

Klima Protocol operates two linked flows. On the supply side, holders of whitelisted carbon credits (credit types the protocol has approved for use, see 1(e)) deliver those credits to the protocol and receive kVCM in return. On the demand side, buyers pay kVCM to retire credits from the protocol. Retirement is the act of permanently removing a credit from circulation so it can be claimed and cannot be resold or double-counted; within Klima Protocol, retirement is the only way credits leave the system; there is no mechanism to withdraw credits for resale or speculation elsewhere. The rate at which credits are exchanged for kVCM (the execution rate) and the volume the protocol can process before that rate moves (the capacity) are both set algorithmically, based on market parameters, and that token holders may influence through governance rather than through case-by-case negotiation. Because every participant transacts against the same published terms, there is no bilateral price negotiation and no information advantage to being better connected or better resourced than another participant. The result is a standing, observable market for spot carbon credits that operates independently of manual intermediation.

(d) Primary token functions

kVCM is the protocol's primary settlement token. Its supply is uncapped: new kVCM is minted when suppliers deliver carbon credits to the protocol, and existing kVCM is burned when credits are retired. Holders can time-lock kVCM to receive base accrual and incentive rewards, and to allocate their holdings toward specific carbon classes, which weights those classes within the protocol's inventory and influences execution rates. K2 is a fixed-supply token (100,000,000 total) used for incentives and for governing execution capacity. Holders can lock K2 to receive kVCM and K2 incentives, and to allocate holdings toward carbon classes, which determines how much volume the protocol can process for that class without materially moving its execution rate. In short: kVCM allocations shape price (the execution rate), and K2 allocations shape depth (the capacity).

(e) Control surface reliance

There are two areas of centralized discretion in the protocol today. The first is whitelisting: the decision to approve a given carbon credit type, registry, or standard for use on the protocol. A small number of credit types were whitelisted at launch with the agreement of the relevant registry or standard. Beyond that initial set, no new whitelisting decisions have yet been required. As adoption grows and additional registries and standards seek integration, this process will involve more judgment, including decisions about credit groupings and quality criteria. The intention is to run this through onchain governance (forum discussion followed by a Snapshot vote) rather than through the current team-level decision-making, with the timeline depending on how actively carbon market participants engage with the protocol and give consent to its integration with their systems. The second is upgrade authority. The protocol's smart contracts are currently upgradable, requiring sign-off from both Klima Foundation and a multisig held by Carbonmark FZCO (see Sections 4(e) and 5(e)). This is a deliberate design choice rather than an oversight: carbon markets are complex, real-world systems with behavior that cannot be fully specified in advance, and the protocol is still early in proving its execution model against live market conditions. Retaining the ability to make corrections and refinements during this period is intended to protect carbon market participants from unintended mechanism failures, rather than to preserve discretionary control for its own sake. The long-term intention is to move toward immutability once the protocol's execution model has been tested against real market conditions and the transfer functionality for tokenized carbon credits is sufficiently standardized across other key market infrastructure (e.g. carbon registries); in addition to sufficient development and traction providing reliability and comfort to carbon market stakeholders.

02

Known Project Team

For each existing entity: Labs/DevCo (e.g., Founder, CEO, CTO, COO), Foundation (e.g., President, Executive Director, CFO, COO), and DAO / onchain governance leadership (if applicable) list the: (a) full names, (b) official titles, (c) and prior experience of key team members. For any non-existent entity, explicitly mention it does not exist. External links may be included but they will not factor into the score.

Labs / DevCo

Full Name

Official Title

Prior Experience

Drew Bonneau

MD

Co-founder Offsetra, Klima. Carbon market specialist.

Brice Walsh

Head of Product

Enterprise consulting, Head of Product in Start-up environments.

Foundation

Full Name

Official Title

Prior Experience

Alex Taylor

Council Member

Co-founder Offsetra, Klima. Energy market consultant.

Thomas Contin

President

Lawyer.

DAO / Onchain Governance

Full Name

Official Title

Prior Experience

N/A

N/A

N/A

03

DAO Structure

Provide a structured description of the DAO's governance, powers, and economic rights. If a DAO does not exist, state so. Address the lettered items below. Even if there is no DAO, there must be an answer to (d).

  • (a) IP ownership & control — State what IP the DAO owns or controls (e.g., codebases/repos, trademarks/brands). Note any license if relevant.
  • (b) Contract/admin powers — List on-chain or administrative authorities and limits: pause/upgrade roles (e.g., multisig pause), governance-executor authorities, and the method of authority for each (e.g., veto, majority, super-majority).
  • (c) Locked-token rights (conditional) — If locking/staking for additional rights exists, explain the additional rights and what tokenholders can and cannot decide. If no locking mechanism exists, leave absent.
  • (d) Value accrual & holder rights — If any, describe the current rights of tokenholders over revenue distribution and the treasury.
  • (e) Dissolution authority — State who can dissolve/wind up the DAO and by what mechanism (e.g., on-chain vote threshold, board resolution of a legal wrapper).

(a) IP ownership & control

N/A. No DAO or onchain governance entity currently exists at Klima Protocol; see Section 2. IP and code ownership sit with the entities described in Sections 4 and 5.

(b) Contract/admin powers

Held jointly, but not within DAO. Protocol upgrades require sign-off from both Klima Foundation and a 3/5 multisig controlled by Carbonmark FZCO (see Sections 4(e) and 5(e)). Neither entity can unilaterally authorize a change.

(c) Locked-token rights (conditional)

Klima Protocol has no DAO or onchain governance entity, so this section describes token-based parameter signalling rather than organizational governance. Holders of kVCM and K2 can lock their tokens to participate in this process. Locked kVCM signals which carbon classes should be weighted in the protocol and influences execution rates; locked K2 signals how much capacity the protocol allocates to a given class. Locking either token also makes a holder eligible for protocol incentives, denominated in kVCM and K2. This is a mechanism for collectively setting protocol parameters and demonstrating decentralised onchain systems within the context of carbon markets, rather than a corporate or DAO governance structure. It does not confer ownership of the protocol, a claim on protocol-held carbon credits, or any right to profit distributions. Signalling through locked tokens influences how the protocol executes; it does not create obligations, guarantees, or entitlements for the participants involved.

(d) Value accrual & holder rights

The protocol captures no dollar revenue and charges no fees payable to the Foundation or DevCo. Any value accrual to token holders is denominated entirely in kVCM and K2, and arises through two channels: incentive issuance to locked and staked holders, and the underlying mint/burn dynamics of kVCM.

Locked holders are eligible to receive kVCM and K2 incentives on the terms described in Section 3(c). As above, this reflects protocol-native rewards for participation, not equity-like rights, profit share, or a claim on protocol assets.

All participants are subject to the same incentive terms; there are no preferential conditions for any individual entity. All users may select their own lock periods.

(e) Dissolution authority

N/A. No DAO or onchain governance entity exists that could hold dissolution authority.

04

Primary Foundation

For the Primary Foundation do the following independently. If an entity does not exist, state that explicitly. Items (a)–(f) apply only if that entity exists; state explicitly that the entity doesn't exist. Definitions: The primary Foundation and DevCo can be explained as those entities which are directly involved in the issuance of the native token at launch.

  • (a) Entity — Type and jurisdiction.
  • (b) IP ownership & control — What IP the entity owns/controls (repos/code, trademarks/brand; license optional) and an explanation of any subsidiary entities.
  • (c) Powers over DAO, treasury, protocol-controlled resources, and token administration — If any, describe the current powers over DAO governance, treasury actions, protocol-controlled resources (e.g. revenue), token administration, or reward parameters, and the method/threshold for each.
  • (d) Powers over DevCo — Explain whether the foundation can exert direct or indirect influence over decision-making of the DevCo.
  • (e) Contract/admin powers — Pause/upgrade/governance-executor authorities and the method/threshold for each (e.g., veto/majority/super-majority; "3/5 multisig").
  • (f) Current economic arrangements and distribution policies — Describe any current governance-approved, contractual, or programmatic mechanisms, if any, by which protocol-controlled resources, treasury assets, fees, revenue, rewards, or token distributions may be directed to this entity, its equityholders, contributors, or other participants. If no such mechanism currently exists, state that explicitly. Do not discuss hypothetical future dividends, repurchases, or distributions unless formally adopted.

(a) Entity

Klima Foundation (Stiftung), Switzerland.

(b) IP ownership & control

Klima Foundation's role is limited to stewardship and ecosystem funding, in pursuit of development of decentralized infrastructure that improves transparency and participation in carbon markets. The Foundation does not itself hold the protocol's code, repositories, or brand; these sit with Klima Fintech Ltd (BVI). Carbonmark FZCO independently undertakes blockchain development and operational activities relating to the protocol. Funding provided by the Foundation does not entitle it to specific deliverables, ownership of resulting intellectual property, or exclusive rights in protocol developments.

(c) Powers over DAO, treasury, protocol-controlled resources, and token administration

The Foundation has no unilateral control over the protocol's treasury, smart contracts, or token administration; those are described in Sections 3 and 5. Its principal lever is financial: it may provide ecosystem grants and funding support to independent contributors, including Carbonmark FZCO, but does not direct day-to-day protocol operations and receives no proprietary rights in resulting developments.

(d) Powers over DevCo

The Foundation has no governance rights over DevCo and may only decide whether to continue or discontinue ecosystem funding.

(e) Contract/admin powers

The protocol is currently upgradable. Any upgrade requires sign-off from Klima Foundation, in addition to the multisig approval process described in Section 5(e).

(f) Current economic arrangements and distribution policies

The Foundation does not itself conduct commercial activities, generate protocol revenues, charge fees, or provide services to users of the protocol. The primary mechanism for distribution of treasury assets (kVCM and K2) to participants happens programmatically, through protocol code, rather than through Foundation discretion -- although the Foundation may elect to from time-to-time to support the ecosystem. The Foundation holds its own position of long-duration, time-locked kVCM and K2 within the protocol, which it uses the same way any other holder would: to help set execution rates and capacity, and to support liquidity. It accrues incentives on identical terms to every other participant, with no preferential rate or access. The allocation of tokens it received at TGE are as described in section 6.

05

Primary Dev Co

For the Primary DevCo do the following independently. If an entity does not exist, state that explicitly. Items (a)–(f) apply only if that entity exists; state explicitly that the entity doesn't exist. Definitions: The primary Foundation and DevCo can be explained as those entities which are directly involved in the issuance of the native token at launch.

  • (a) Entity — Type and jurisdiction.
  • (b) IP ownership & control — What IP the entity owns/controls (repos/code, trademarks/brand; license optional) and an explanation of any subsidiary entities.
  • (c) Powers over DAO, treasury, protocol-controlled resources, and token administration — If any, describe the current powers over DAO governance, treasury actions, protocol-controlled resources (e.g. revenue), token administration, or reward parameters, and the method/threshold for each.
  • (d) Powers over Foundation — Explain whether the DevCo can exert direct or indirect influence over decision-making of the Foundation.
  • (e) Contract/admin powers — Pause/upgrade/governance-executor authorities and the method/threshold for each (e.g., veto/majority/super-majority; "3/5 multisig").
  • (f) Current economic arrangements and distribution policies — Describe any current governance-approved, contractual, or programmatic mechanisms, if any, by which protocol-controlled resources, treasury assets, fees, revenue, rewards, or token distributions may be directed to this entity, its equityholders, contributors, or other participants. If no such mechanism currently exists, state that explicitly. Do not discuss hypothetical future dividends, repurchases, or distributions unless formally adopted.

(a) Entity

Carbonmark FZCO, Dubai Multi Commodities Centre — provides blockchain development services. Klima Fintech Ltd, BVI — owns the codebase and GitHub repositories; token issuance and operator of infrastructure.

(b) IP ownership & control

Carbonmark FZCO provides blockchain development services and operationally manages the multisig referenced in 5(e) via its contractors. Klima Fintech Ltd (BVI) is the legal owner of the codebase and GitHub repositories (due to be open sourced in 2026 under MIT license, subject to final security audits), and holds ultimate legal ownership over the multisig's underlying authority, even though day-to-day administration sits with Carbonmark.

(c) Powers over DAO, treasury, protocol-controlled resources, and token administration

Protocol upgrades require a 3-of-5 multisig approval, in addition to sign-off from Klima Foundation. The multisig is operationally managed day-to-day by Carbonmark FZCO's contractors; Klima Fintech Ltd (BVI), as legal owner of the codebase, holds ultimate legal authority over it. Neither Carbonmark nor the Foundation can authorize an upgrade alone (see Sections 3(b) and 4(e)).

(d) Powers over Foundation

Carbonmark FZCO has indirect influence over Klima Foundation, as one of the primary operators of the technology the Foundation funds, but holds no formal governance rights over the Foundation. Klima Fintech Ltd has no influence over the Foundation.

(e) Contract/admin powers

Protocol upgrades require a 3-of-5 multisig approval, controlled by Carbonmark FZCO (and administered by Klima Fintech), in addition to sign-off from Klima Foundation. Both approvals are required; neither Carbonmark nor the Foundation can authorize an upgrade alone (see Sections 3(b) and 4(e)).

(f) Current economic arrangements and distribution policies

Carbonmark receives grants or ecosystem funding to support independent protocol development at a rate of $40,000 per month. Funding is provided in furtherance of the Foundation's mission of supporting transparent and accessible carbon market infrastructure. Klima Fintech Ltd may receive funding from ecosystem entities from time-to-time to cover general administrative costs.

Token Supply & Allocations

06

Initial Allocation

Ticker

Date

Allocation Category Name

Recipient Type

Allocation %

Allocation Tokens

TGE Unlock %

TGE Unlock Tokens

Cliff Months

Cliff Unlock %

Linear Vesting Months

Cadence Months

Circulating Treatment

Notes on what each category is used for

If applicable: Contract / Wallet address

kVCM

2025-10-15

kVCM - KLIMA holders

Community

77.50%

15,500,000

100.00%

15,500,000

0

100.00%

0

0

No

Distribution of kVCM to community members that held KLIMA & participated in "Fair Launch".

0xa79cd47655156b299762DFE92A67980805ce5a31

kVCM

2025-10-15

kVCM - Late comer migration

Community

10.00%

2,000,000

100.00%

2,000,000

Conditional

Distribution of kVCM to community members that did not participate in "Fair Launch".

kVCM

2025-10-15

kVCM - Klima Foundation

Treasury

10%

2,000,000

100.00%

2,000,000

0

100.00%

0

0

Conditional

Klima Foundation kVCM allocation (voluntarily locked in Protocol to contribute to carbon parameters)

kVCM

2025-10-15

kVCM - 01x consulting FZE

Ecosystem

2.50%

500,000

0.00%

0

24

100.00%

0

0

No

Locked in kVCM / K2 liquidity pool for 24 months.

0xBD7564D90393d6FD2960a182356eD59086CA2B8c

kVCM

2025-10-15

K2 - Foundation

Treasury

4.50%

4,500,000

100.00%

4,500,000

0

0.00%

0

0

Conditional

Locked for Protocol governance, and providing K2 / kVCM liquidity

0xa79cd47655156b299762DFE92A67980805ce5a31

kVCM

2025-10-15

K2 - 01X Consulting FZE

Ecosystem

2.50%

2,500,000

0.00%

0

0

0.00%

24

1

Conditional

Locked in LP

0xBD7564D90393d6FD2960a182356eD59086CA2B8c

kVCM

2025-10-15

K2 - Fair Launch

Community

40.00%

40,000,000

0.00%

0

0

0.00%

48

1

No

Incremental unlocks for fair launch participants (note S Curve rather than linear). Becomes circulating incrementally, assuming claims are made.

kVCM

2025-10-15

K2 - Protocol incentives

Community

40.00%

40,000,000

0.00%

0

0

0.00%

48

1

No

Incremental unlocks for Protocol lockers (note S Curve rather than linear) .

kVCM

2025-10-15

K2 - pKlima holders

Private / VC

3.00%

3,000,000

0.00%

0

0

0.00%

48

1

No

Allocation for original private round on Klima 1.0. Incremental unlocks for Protocol lockers (note S Curve rather than linear). Becomes circulating assuming claims are made.

kVCM

2025-10-15

K2 - Ecosystem grants

Ecosystem

10.00%

10,000,000

0.00%

0

0

0.00%

48

1

Conditional

Ecosystem grant fund to support builders around ecosystem. None distributed as of 20th July 2026. Becomes circulating assuming they are distributed, subject to 48 month vest (note S curve rather than linear).

07

Airdrop Process

Address each of the following sub-items based on the project's airdrop status. If a sub-item does not apply to the project's situation, state that explicitly.

  • (a) Planned but not yet executed airdrop — If the project has planned but not yet airdropped, commit to publishing a recipient wallet list in a public channel and provide it to Blockworks quarterly until the initial TGE airdrop is fully completed. Additionally, generally state the possible target user segments (e.g., "stakers of X," "Aave users") and the allocation method (e.g., proportional to ve-balance or net position).
  • (b) Executed airdrop — If the project has already airdropped, point to a per-address source such as CSV/TSV/JSON files, a Dune table, a full Merkle dump, GitHub repo files embedding per-address allocations, or RPC endpoints that expose claim/amount data; explorer links alone do not count. Additionally, clearly state covered user segments (e.g., "stakers of X," "Aave users") and the allocation method (e.g., proportional to ve-balance or net position).
  • (c) No airdrop planned or conducted — If the project does not plan to conduct an airdrop for TGE and has never conducted one, state so plainly (e.g., "We have never conducted an airdrop to date and do not plan to execute one").

(d) Planned but not yet executed airdrop

N/A

(d) Executed airdrop

Klima Foundation executed a one-time distribution of 250,000 K2 tokens, drawn from the Foundation's own token allocation (see Section 6), to encourage user engagement with the protocol's first kVCM maturity roll-over event.

Covered user segment: kVCM holders with an unlock scheduled at the first maturity date who elected to roll their position over to a later maturity rather than unlock and exit.

Allocation method: Proportional to the amount each user rolled over, with a multiplier applied per the Protocol's existing discount curve used for native token incentive distributions — the same curve applied elsewhere in protocol-native incentive mechanics, not a bespoke formula created for this event.

Execution method: Manual, off-chain transfer to recipient wallet addresses (not an onchain claim contract or Merkle distribution).

Purpose/discretion: A discretionary Foundation activity intended to drive engagement with, and understanding of, the roll-over mechanic — not a recurring or planned distribution program.

Spreadsheet: https://drive.google.com/file/d/1tdACP3tjSNRWs9rB1hZD1zdi30jWnKiG/view?usp=sharing

(e) No airdrop planned or conducted

No further airdrops planned.

Transactions & Market Structures

08

Market Maker Agreements & Deals

Projects must disclose all material terms of market-making arrangements that affect token liquidity. If the project has no agreements or deals with market makers, state that explicitly; doing so earns full credit. For each market maker, include in a table: (a) Market maker's name — the market maker's name; (b) Token allocation or loaned amount — the token allocation or loaned amount as a percentage of total supply; (c) Duration/term of agreement — the duration/term of the agreement; and, where applicable, (d) Name of agreement structure — label the financial vehicle being used in the agreement (i.e. loan, option/call, retainer model) without describing trading strategy or expected outcomes. If the project has no agreements or deals with market makers, state that explicitly; doing so earns full credit. If no native tokens were loaned or allocated to market makers, state that explicitly; cash/fiat retainers or fees are not required for this item.

Market Maker Name

Token Allocation Committed

Term Duration

Structure Name

No MM deals.

N/A

N/A

N/A

09

CEX / DEX Agreements & Deals

Projects must disclose all material terms of centralized or decentralized exchange listings that affect token liquidity. For each listing, include in a table: (a) Exchange name / DEX pool — the exchange name (and, for DEX, the specific pool/pair); (b) Token allocation for listing — the token allocation supplied or committed for listing as a percentage of total supply; (c) Term Duration — the duration/term of any listing lockups, liquidity, or incentive programs; and, where applicable, (d) Native-token listing fees — whether any listing fees were paid in native tokens, with amounts (tokens or % of supply), recipients, and any vesting or lock terms tied to the partnership. If the project has no agreements or deals with CEX or DEX, state that explicitly; doing so earns full credit; cash/fiat fee amounts are not required for this item.

Exchange Name

Token Allocation Committed

Term Duration

Native Token Listing Fees

Aerodrome

2,500,000 K2 & 500,000 kVCM

Held by 01X Consulting FZE as compensation for advisory/consulting services (see Section 6). Locked in an immutable 24-month Aerodrome LP position per the terms of the advisory agreement

N/A

Aerodrome

N/A (strategic veAERO acquisition)

This is a Foundation treasury holding, not an exchange listing commitment of Klima's own tokens, and is also disclosed as a treasury asset in Section 1(b).

N/A

Financial Disclosures & Risks

10

Prior Token Sales & Fundraising

Disclose all prior token sales by the Project — including fundraising rounds, any material OTC sales to investors, and any discounted market-maker sales. For each sale, provide: (a) Series Name; (b) Early-Stage Investment Instrument used (i.e. SAFT, STAMP, SAFE, SAFE+Token Warrant, etc.); (c) Date of sale (at least month & year); (d) Number of tokens sold (or % of total supply); (e) Vesting schedule. If no prior sales occurred, state that explicitly (e.g., "No prior fundraising, OTC, or discounted MM sales have occurred.").

Series Name

Investment Vehicle

Date Of Sale

Number of tokens sold

Vesting Schedule

Seed (KlimaDAO; legacy project)

"pKLIMA" (pOHM fork)

September 2021

22,232

Supply based

11

Previous Exploits Affecting The Native Token

If any, list prior exploits or incidents that directly affected the token, token supply, tokenholder balances, token contract, minting controls, burn mechanics, or custody of token supply. This question is not asking about general protocol, application, or smart contract exploits unless the incident directly affected the native token itself. If no prior incidents, state this explicitly (e.g., "No exploits affecting tokenholders or protocol funds as of YYYY-MM-DD").

  • (a) Date & component affected — Date (YYYY-MM or YYYY-MM-DD), chain(s)/component affected.
  • (b) Exploit vector summary — Plain-language summary of the exploit vector (what the hack was).
  • (c) Quantified impact — Quantified impact (assets/tokens affected or a clear "no loss of funds" statement).
  • (d) Remediation/response taken — Remediation/response taken (patches, upgrades, governance actions, compensation).
  • (e) Current status — Current status (resolved, in litigation, under investigation, refunded, etc.).
  • (f) References (optional) — Link(s) to post-mortem/advisory/PR.

(a) Date & component affected

No exploits affecting tokenholders or protocol funds as of 2026-07-22

(b) Exploit vector summary

N/A

(c) Quantified impact

N/A

(d) Remediation/response taken

N/A

(e) Current status

N/A

(f) References (optional)

N/A

12

Material Risk Factors (Regulation, Technology, Token Economics)

Describe material risk factors across the three categories below. Each category includes prompts to address at a minimum.

  • (a) Regulatory, Legal & Tax Risks — Describe how evolving laws and regulations could affect the project by answering, at a minimum, questions like:
  • Impact of Regulatory Change on TGE and Listings: (If applicable) How could evolving or conflicting laws and regulations affect your ability to complete the TGE, deliver tokens to purchasers, and list or maintain the token on trading venues in key jurisdictions?
  • Entity-Level Regulatory Impact: (If applicable) How could regulatory or legal changes impact your core entities (Foundation, DevCo, DAO, affiliated service providers), including enforcement actions, licensing requirements, or forced changes to structure or operations?
  • Tokenholder Tax Treatment: (If applicable) What uncertainties exist around how tokenholders may be taxed, and make clear that tokenholders are responsible for understanding their own tax obligations?
  • Jurisdictional & User Access Restrictions: (If applicable) If the project restricts access for certain jurisdictions or user types (e.g., U.S. persons, sanctioned countries, retail vs. professional), what are those restrictions and what risks do they create for users and for the project?
  • (b) Protocol, Technology & Security Risks — Describe risks to network and contract reliability, correctness, and safety by answering, at a minimum, questions like:
  • Bugs and Design Flaws: (If applicable) What bugs, design flaws, or implementation errors could exist in your core protocol code, smart contracts, and any bridges, rollups, or oracles that you depend on, and how could these lead to loss of funds or disruption of the protocol?
  • Security Measures & Their Limitations: (If applicable) What security measures have you taken (audits, formal verification, bug bounties), and what types of failures might these measures still fail to detect or prevent?
  • (c) Token Economics, Unlocks & Incentive Risks — Describe how the token's economic design and supply schedule could affect holders by answering, at a minimum, questions like:
  • Critical Economic Assumptions: (If applicable) Which economic assumptions (e.g., staking yields, fee revenue, liquidity incentives, MEV capture, demand for blockspace) are critical for protocol security, utility, and governance, and what happens if those assumptions fail?
  • Governance Control over Monetary Policy & Rewards: (If applicable) To what extent can governance change monetary policy, fee parameters, or reward allocations (e.g., inflation rate, treasury flows, incentive programs), and how could such changes adversely affect tokenholders?

(a) Regulatory, Legal & Tax Risks

Klima 2.0's TGE and initial token distribution are complete, which removes the class of risk associated with an ongoing or future issuance (e.g., an incomplete raise being reclassified mid-process, or purchasers left holding claims against an unfinished offering). No VC or derivative-instrument round (e.g., SAFT, warrant) took place that could create future delivery obligations or contractual liability tied to regulatory change. kVCM and K2 are not listed on any centralized exchange, so the project bears no counterparty risk from a CEX delisting decision driven by regulatory pressure. Liquidity exists only via decentralized venues.

The more durable exposure is not to the TGE mechanics themselves but to the regulatory treatment of the underlying carbon credit market. Klima has deliberately restricted its scope to spot transactions (credit delivery and retirement) and has not built futures, forwards, or other derivative exposure into the protocol, specifically to avoid inviting commodity-derivatives regulatory scrutiny without appropriate licenses. If regulators later determine that spot carbon credit activity itself constitutes a regulated activity (for example, if voluntary carbon credits are reclassified as securities, or another regulated instrument in a major jurisdiction) this could affect the legality of accessing the protocol for users in that jurisdiction, independent of any action Klima takes.

The Klima Foundation (Switzerland) and Klima Fintech Ltd (BVI) operate in jurisdictions with developing but not fully settled digital-asset regulatory frameworks. Carbonmark FZCO (Dubai Multi Commodities Centre) operates under UAE virtual-asset rules, which continue to evolve. Carbonmark holds a blockchain development / DLT services license; if any jurisdiction determines that Foundation, DevCo, or Carbonmark activities require such licensing, this could force changes to structure, require new registrations, or in a severe case, restrict the entities' ability to operate as currently structured.

Protocol-native incentives (kVCM and K2) are likely to constitute taxable income in many jurisdictions at the time of receipt, with potential further tax consequences on disposal. Tax treatment varies materially by jurisdiction and by the tokenholder's individual circumstances (residency, entity type, holding structure). Klima does not provide tax advice, and tokenholders are solely responsible for determining and meeting their own tax obligations, including income, capital gains, and any reporting requirements applicable to them.

The platform requires KYC verification, implemented via zk.me, a privacy-preserving identity solution. Klima and its operating entities do not have visibility into underlying user identity data; however, zk.me retains the ability to decrypt and disclose that data in response to a valid regulatory request. Access is restricted for users from OFAC-sanctioned jurisdictions. These requirements were adopted at the request of carbon market stakeholders (e.g., registries, standards bodies) rather than being imposed by a specific regulator, and Klima's stated intention is to conform to the expectations of those stakeholders as the market matures. This creates a risk that KYC/access requirements could tighten further as carbon market institutional participants set stricter expectations, potentially narrowing the addressable user base beyond what current smart contract logic requires.

(b) Protocol, Technology & Security Risks

Klima Protocol's execution logic is governed entirely by smart contracts deployed on Base. As with any smart-contract system, there is a risk of bugs, design flaws, or implementation errors in the core protocol code that could affect execution rates, capacity calculations, token issuance, or the integrity of the carbon inventory. Because the protocol currently remains upgradable (see Section 1(e)), identified issues can be corrected, but this also means tokenholders are exposed to the risk of an upgrade being executed incorrectly, maliciously, or without adequate testing, mitigated in part by the requirement for joint sign-off from Klima Foundation and the Carbonmark-administered multisig described in Sections 3(b), 4(e), and 5(e).

The protocol has undergone a third-party audit: https://hashlock.com/audits/klima-protocol.

A bug bounty programme addressing critical bugs is operational: https://docs.klimaprotocol.com/reference/bug-bounty-programme.

The codebase is not currently open source. The protocol intends to release it under an MIT license in 2026, subject to completion of final security audits. Until then, the closed codebase may limit independent, external research and scrutiny of the protocol by the broader open-source community.

(c) Token Economics, Unlocks & Incentive Risks

The protocol's core economic assumption is that token-based signalling, kVCM allocations shaping execution rates and K2 allocations shaping capacity, will produce carbon pricing and liquidity outcomes that are viable for real-world supply and demand, without a human operator adjusting parameters in response to market conditions. This assumption has not yet been tested at scale against the full range of conditions a live carbon market can produce: sudden shifts in credit supply, demand shocks from large corporate buyers, or periods of low participation that leave too few tokens locked to generate meaningful price signals. If token-based coordination fails to track real-world carbon market conditions accurately, the protocol's published execution rates could diverge materially from prices available elsewhere in the market, to the detriment of suppliers or buyers transacting through it.

Governance over execution rates and capacity is exercised by whoever holds and locks kVCM and K2 at a given time. This creates a concentration risk: if token holdings become concentrated among a small number of participants, those participants could disproportionately influence execution terms for specific carbon classes, within the bounds the protocol's code allows. Klima Foundation and DevCo hold positions in both tokens and participate in this signalling process on the same terms as other holders (see Sections 4(f) and 5(f)), which reduces but does not eliminate this risk relative to a design where insiders hold no position at all.

Separately, kVCM's supply is uncapped and expands or contracts with carbon intake and retirement activity, while K2 has a fixed supply distributed on the schedule described in Section 6 -- holders should understand that neither token confers ownership of the protocol, a claim on protocol-held carbon, or a right to profit distribution; "value", to the extent it exists, is a function of incentive issuance and mint/burn dynamics tied to protocol usage, not of an underlying revenue stream.

The Foundation currently retains discretionary authority to execute one-off distributions from its own token holdings (e.g., the K2 roll-over incentive disclosed in Section 7(b)) without a codified protocol rule or onchain governance vote. While such distributions to date have been directed at genuine protocol users under terms consistent with the Foundation's normal accrual (see Section 4(f)), this reflects the same pre-DAO control-surface concentration already disclosed in Section 1(e).

This Token Transparency Filing is provided for general informational purposes only. Blockworks reviews completeness only and does not verify or warrant the accuracy of individual answers. Klima Protocol is solely responsible for the content, accuracy, and legality of its disclosures.

Newsletter

The Breakdown

Decoding crypto and the markets. Daily, with Byron Gilliam.

Blockworks Research

Unlock crypto's most powerful research platform.

Our research packs a punch and gives you actionable takeaways for each topic.

SubscribeGet in touch

Blockworks Inc.

133 W 19th St., New York, NY 10011

Blockworks Network

PodcastsNewslettersEventsRoundtablesAnalytics