The Reserve
3.3. The Reserve: Governance, Treasury & Distribution
The Reserve protocol is the coordination and strategic layer of the 3 ecosystem. It governs the strategic asset reserve (The Vault), manages the distribution of all protocol revenue, and coordinates ecosystem expansion through a user-sentiment-driven governance model.
3.3.1. Native Governance Tokens: 3Fi & VW3
3Fi Token (ERC-20): The protocol's "equity" token and the fundamental unit of governance power.
Distribution: 3Fi is minted exclusively alongside GUILD via the GuildSwap FARM mechanism, following the 3Fi Distribution Curve defined in Section 3.1.2. 100% of the supply is distributed by the time 33 billion GUILD are issued.
Sunset Rights: In a protocol sunset scenario, 3Fi holders have a pro-rata claim on the entire treasury of The Holding Contract.
VW3 (Vote Weight 3): The active, non-transferable governance weight used to influence the Distribution Engine and PODs. VW3 tokens can only be held by whitelisted smart contracts (e.g., the Distribution Contract, PODs, Arbitrage Engines).
Minting: 4 VW3 are minted for every 1 3Fi minted, maintaining a constant 4:1 ratio between total VW3 and total 3Fi supply.
Accrual & Management: Users stake 3Fi to linearly accrue VW3 over time, up to a maximum of 4 VW3 per 3Fi over a 4-year period. Upon claim, the VW3 is sent to the Distribution Contract, not the user's wallet. The user allocates this VW3 weight from the Distribution Contract to whitelisted destinations (PODs, Arbitrage Engines). To withdraw staked 3Fi, a user must first return the corresponding VW3 to the Distribution Contract, following a First-In-First-Out (FIFO) model that incentivises returning the maximum VW3 balance.
Unclaimed VW3: Any VW3 that is minted but not yet claimed by stakers is automatically allocated to augment the voting weight of the Creditors POD, giving 3Bond holders a default, strategic influence.
3.3.2. The Distribution Engine & Revenue Fork Logic
The Distribution Engine receives crvUSD from the Settlement Contract (surplus revenue after pledge allocations) and executes a deterministic fork to allocate it between strategic reserves and stakeholder distributions.
Input & Conversion:
revenueCrvUSDis received viadistributeRevenue()and is immediately swapped for ETH.Legends' Fee: A fixed percentage (e.g., 9%) of the ETH is segregated and distributed to active Legend Nodes as a service fee.
State Check: The engine compares
ActualReserves (AR)to theReserveRequirement (RR)defined by the active Reserve Requirement Curve (RRC).Fork Logic:
Fortify Mode (
AR < RR): 33% of the remaining ETH is sent to The Vault to bolster strategic reserves. 67% is sent to the POD distribution pool.Thrive Mode (
AR >= RR): 100% of the remaining ETH is sent to the POD distribution pool.
POD Distribution: ETH in the POD pool is distributed to each Purpose-Oriented Distributor (POD) in proportion to the total VW3 weight allocated to that POD.
3.3.3. Purpose-Oriented Distributors (PODs)
PODs are smart contracts that receive and manage streams of ETH from the Distribution Engine. Each POD has a defined purpose (e.g., funding development, incentivising liquidity). The initial set includes:
Developers POD: Funds core protocol development and maintenance.
Creatives POD: Funds ecosystem growth, marketing, and community initiatives.
Creditors POD: Distributes yield to Aged 3Bond holders.
Reserve Booster POD: Automatically sends its share back to The Vault (accelerating reserve growth in Thrive Mode).
Liquidity Booster POD: Funds external liquidity incentives for GUILD pairs. The system is designed for the permissionless creation of new PODs via governance.
3.3.4. Legends: The Final Security Layer
Legends are a fixed set of 333 privileged seats within the ecosystem, acting as its ultimate security council and guarantors.
Acquisition: Requires a two-step process managed by a future Legend Master Node:
Reservation: A user deposits an escalating quantity of Aged 3Bonds into the Master Node to reserve a Legend Node deployment slot.
Activation: The user deploys a Legend Node and supplies it with a specific set of high-level 3.NFTs (e.g., 9 NFTs from 3 specific CDP NFT Collections) to activate it.
Privilege: Active Legend Nodes receive a direct, fixed share (e.g., 9%) of all ETH generated by the protocol, segregated after revenue conversion and before the Distribution Engine's fork logic.
Power: Legends hold unique veto and resume capabilities across the three core protocols (e.g., can resume proposals paused by VW3 holders).
3.3.5. The Vault & Reserve Requirement Curves (RRCs)
The Vault: A secure contract holding the protocol's strategic reserve of ETH. This is the unencumbered, intrinsic backing for the GUILD currency.
Reserve Requirement Curves (RRCs): Phased, policy-driven functions that define the
ReserveRequirement (RR)at any point in the protocol's lifecycle. An RRC specifies key performance indicators (KPIs), such as a target ratio of ETH-to-GUILD, guiding the system from bootstrap (RRC_Phase1) to maturity (RRC_PhaseN). Transitioning to a new RRC is a governance action that formally marks a phase change.
3.3.6. The Arb. Master Node & Arbitrage Engines
Arb. Master Node: Manages the crvUSD capital from Adolescent 3Bond sales (after the 1% settlement allocation and rebate). It drip-feeds this capital linearly over 30-90 days to specific Arbitrage Engines.
Arbitrage Engines: Contract pairs (one per approved derivative asset, e.g., sdCRV) that facilitate the GuildSwap ARBITRAGE function.
Function: Allows users to sell a discounted derivative asset for an immediate crvUSD payout from the Engine's funded balance.
Governance: VW3 holders allocate weight to specific Arbitrage Engines. The Arb. Master Node distributes its drip-fed crvUSD to each Engine in proportion to its allocated VW3 weight.
Arbitrage Fee: A fee payable in GUILD is charged on each arbitrage trade. The fee scales exponentially based on the discount captured, acting as a circuit breaker. Projects can "donate" GUILD to their specific Engine to subsidise this fee, incentivising arbitrage for their token.
Last updated