Protocol Overview

1.1 What is Carbon?

Carbon is a Meta-Yield veDEX (vote-escrowed decentralized exchange). It introduces a revenue-linked emissions model where token issuance scales directly with trading fee revenue, replacing the fixed-schedule inflation common in ve(3,3) forks.

The protocol's defining feature is the Diamond veNFT, a permanently locked voting position that uses algorithmic analysis to direct a portion of emissions toward high-demand liquidity pairs. User governance operates alongside the Diamond veNFT, with both voting independently each epoch.

1.2 Core Thesis - Blockchain Alignment

Every blockchain has a DEX. None have infrastructure that strategically deepens liquidity to capture the volume that already exists on-chain. Pools are typically created reactively, voted on by mercenary capital, and incentivized without regard for where volume actually flows.

The result is shallow liquidity on high-demand pairs, wasted emissions on low-demand ones, and volume that routes through competitors.

Blockchain alignment is the principle that a DEX should deepen liquidity on the pairs that matter most to the chain. Carbon implements this through the Diamond veNFT, which supplements user votes by directing its portion of emissions toward the highest-demand pairs identified through on-chain volume analysis, asset correlations, and routing paths.

1.3 Key Differentiators

• Emissions are revenue-backed, not schedule-based
• Algorithmic liquidity direction via Diamond veNFT
• Permissionless gauge creation with economic friction
• Hard cap supply with terminal buyback phase
• Dual governance (user votes + protocol-aligned Diamond veNFT)

Tokenomics

2.1 CARBON Token

The CARBON token serves as the protocol's governance and emissions token. It can be locked to mint veCARBON (as a veNFT) for voting power and fee participation.

2.2 Supply Distribution

Allocation percentages TBD.

The total supply is hard-capped. After full distribution, no new tokens are ever minted. The protocol transitions to a buyback-only model (see Section 2.5).

2.3 Emission Budget Calculation

Each 7-day epoch, the emission algorithm determines the next epoch's token budget based on three inputs:

1. Prior epoch trading fee revenue - primary input
2. CARBON token price - market valuation signal
3. Volatility - risk adjustment factor
4. CARBON liquidity depth - determines how many tokens can be safely emitted without excessive price impact

Emissions are capped at 40-70% of the prior epoch's trading fee revenue. This creates a direct link between protocol economic activity and token issuance.

Behavior by market condition

2.4 Revenue Coverage

The protocol targets a revenue coverage ratio above 1x across all scenarios.

Projected cumulative figures:

2.5 Buyback Terminal Phase

After the full 210M supply is distributed, emissions cease permanently. Revenue that previously funded emissions redirects into market buybacks of CARBON. This creates a zero-dilution terminal state where the protocol continuously removes circulating supply using trading fee revenue.

veCARBON Mechanics

3.1 Locking

Users lock CARBON tokens to mint a veCARBON position, represented as a veNFT. Lock duration determines voting power (time-weighted).

3.2 Revenue Streams for Lockers

veCARBON holders earn from three sources:

1. Trading fees - share of protocol trading fee revenue
2. External bribes - incentives posted by projects seeking gauge votes
3. Early-unlock penalties - 50% of penalties from users who exit locks early

3.3 Voting

Voting occurs once per 7-day epoch. veCARBON holders allocate their voting power across one or more gauges. Emissions for the next epoch are distributed proportionally based on total votes received by each gauge.

3.4 Early Unlock

Users can exit a lock early by paying a 50% penalty on their locked CARBON.

Penalty distribution:

This mechanism discourages short-term lock farming while rewarding long-term participants and strengthening the protocol treasury.

Diamond veNFT

4.1 Overview

The Diamond veNFT is a permanently locked (blackhole) veNFT position owned by the protocol. It cannot be unlocked, transferred, or sold. Its voting power grows over time through protocol revenue mechanisms.

4.2 Funding Sources

The Diamond veNFT's voting power increases through two mechanisms:

1. Gauge creation fees - 50% of all gauge creation fees
2. Early-unlock penalties - 50% of all early-unlock penalties

This creates compounding protocol-owned voting power that strengthens each epoch.

4.3 Algorithmic Vote Allocation

Each epoch, a custom algorithm analyzes on-chain data to determine how the Diamond veNFT casts its votes. Inputs include:

• Volume analysis - which pairs carry the most trading volume
• Liquidity depth - where Carbon's liquidity is thin relative to demand
• Asset correlations - related pairs that benefit from shared depth
• Routing paths - aggregator and router behavior patterns

The algorithm directs the Diamond veNFT's votes toward pairs where deeper liquidity translates directly into more volume routed through Carbon.

4.4 Revenue Flywheel

The Diamond veNFT creates a self-reinforcing cycle:

User governance and the Diamond veNFT operate independently. Users vote freely with their veNFTs. The Diamond veNFT supplements those votes with protocol-aligned allocation.

Gauges

5.1 Permissionless Creation

Any project can create a gauge on Carbon. There is no approval process, committee, or insider requirement. Access is permissionless with economic friction.

5.2 Creation Requirements

A gauge can be created by meeting one of two requirements:

5.3 Scaling Fee Mechanism

Gauge creation fees scale higher as total gauge count grows. This introduces economic friction against low-signal pools and prevents incentive sprawl across too many gauges.

The scaling function ensures that early gauges are inexpensive to create, while later gauges require increasingly significant commitment.

5.4 Fee Distribution

5.5 Purpose

The gauge system serves two functions:

1. Open access - any project can participate without permission
2. Quality filtering - economic friction prevents gauge pollution and preserves APY concentration on high-routing pairs

Emissions Model - Meta-Yield

6.1 Definition

Meta-Yield is Carbon's emissions framework. Unlike traditional veDEX models where emissions follow a fixed decay schedule, Meta-Yield ties emissions directly to protocol revenue.

Fixed-schedule emissions (traditional)

Meta-Yield emissions (Carbon)

6.2 Self-Throttling Behavior

In slow periods (low volume, declining revenue), the emission algorithm automatically reduces output. Fewer tokens enter circulation when there is less economic activity to back them.

In growth phases, emissions scale proportionally with on-chain activity. More volume, more fees, more emissions, but always tethered to real cash flow.

6.3 Hard Cap Enforcement

Regardless of revenue growth, total emissions can never exceed the 210M hard cap. The algorithm distributes remaining supply over time, but the ceiling is absolute.

6.4 Zero Unbacked Inflation

At no point does the protocol emit tokens without corresponding revenue. The revenue coverage ratio (cumulative revenue / cumulative emission value) is designed to remain above 1x.

Pool Architecture

7.1 Pool Types

7.2 Fee Structure

Trading fees are collected on every swap. Fee distribution:

Governance

8.1 Dual Governance Model

Carbon operates with two classes of voters:

Both vote independently. User votes are never overridden or constrained by the Diamond veNFT. The Diamond veNFT adds protocol-aligned votes on top of user governance.

8.2 Epoch Cycle

8.3 On-Chain Transparency

All governance actions are on-chain:

• Vote allocations are publicly visible
• Diamond veNFT votes are verifiable
• Emission budgets are deterministic given inputs
• Revenue-to-emission ratios are auditable

Technical Architecture

9.1 Chain

EVM-compatible chain Chain selection TBD.

9.2 Smart Contract Components

Contracts not yet deployed.

9.3 Epoch Automation

Each epoch boundary triggers:

1. Fee collection and distribution
2. Emission budget calculation (revenue, price, volatility inputs)
3. Vote tallying (user veNFTs + Diamond veNFT)
4. Emission distribution to gauges proportional to votes
5. Diamond veNFT vote recalculation for next epoch

Risk Considerations

10.1 Smart Contract Risk

All contracts will undergo third-party audits before mainnet deployment. Audit firm TBD.

10.2 Oracle Risk

The emission algorithm requires price feeds. Oracle dependency and fallback mechanisms are under design.

10.3 Diamond veNFT Centralization Risk

The Diamond veNFT introduces protocol-directed voting, which could be perceived as centralization. Mitigations:

• Algorithm is deterministic and verifiable on-chain
• User votes are never overridden
• Diamond veNFT voting logic is open source
• Protocol cannot manually override algorithmic votes

10.4 Revenue Dependency

If trading volume drops to near-zero for extended periods, emissions approach the minimum floor but never exceed revenue backing. The self-throttling mechanism prevents emission of unbacked tokens.

Glossary