Question
Provide a concise narrative that clearly states each of (a)–(e) below.
Response
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.
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.
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.
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).
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.
Question
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.
Response
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. |
Full Name | Official Title | Prior Experience |
|---|---|---|
Alex Taylor | Council Member | Co-founder Offsetra, Klima. Energy market consultant. |
Thomas Contin | President | Lawyer. |
Full Name | Official Title | Prior Experience |
|---|---|---|
N/A | N/A | N/A |
Question
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).
Response
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.
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.
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.
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.
N/A. No DAO or onchain governance entity exists that could hold dissolution authority.
Question
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.
Response
Klima Foundation (Stiftung), Switzerland.
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.
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.
The Foundation has no governance rights over DevCo and may only decide whether to continue or discontinue ecosystem funding.
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).
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.
Question
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.
Response
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.
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.
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)).
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.
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)).
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.
Response
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 | Yes | 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 |
Question
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.
Response
N/A
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
Question
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.
Response
Market Maker Name | Token Allocation Committed | Term Duration | Structure Name |
|---|---|---|---|
No MM deals. | N/A | N/A | N/A |
Question
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.
Response
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 |
Question
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.").
Response
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 |
Question
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").
Response
No exploits affecting tokenholders or protocol funds as of 2026-07-22
N/A
N/A
N/A
N/A
N/A
Question
Describe material risk factors across the three categories below. Each category includes prompts to address at a minimum.
Question
Identify to the best of your ability the token's current deployments across chains, including project-issued deployments, project-endorsed representations, and, if possible, documented third-party wrapped or bridged representations.
For each entry, provide:
Multiple entries on the same chain are permitted.
Definition: A protocol-level asset is an asset whose balances and transfers are handled directly by the blockchain's core rules, rather than by a token smart contract. For protocol-level assets without a token contract address, enter "No contract address" and identify the asset and chain.
Response
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.
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 | Yes | 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 | Yes | 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 | Yes | 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 | No | 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). |
No further airdrops planned.
Response
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.
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.
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).
