# Governance 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.