The Grove

3.2. The Grove: Programmable Asset Management

The Grove protocol provides a generalized vault infrastructure for managing yield-bearing assets. Its core innovation is a Signal system that allows depositors to programmatically control the reinvestment path of their yield, creating a graph of composable yield flows. This enables complex, multi-step strategies while maintaining individual user custody and autonomy.

3.2.1. Core Architecture: Pools, Deposits, and Balances

The Grove organizes assets into Deposit Pools, each connected to an external yield strategy (e.g., a staking contract).

  • Pool Types:

    • Compoundable Deposit Pools (CDPs): Accept deposits of a single "native" asset. Rewards can be auto-compounded within the pool (SELF_COMPOUND) or boosted to other pools (BOOST).

    • Liquid Deposit Pools (LDPs): Architecturally identical to CDPs but with a key constraint: they cannot SELF_COMPOUND. Rewards generated in an LDP must be boosted (BOOST) to another CDP. This creates enforced yield redirection and allows for strategic upgrades (an LDP can be governance-upgraded to a CDP).

  • Balance Architecture: Each user's position in a pool is comprised of two distinct, fungible balance types:

    • Parent Balance: The principal amount originally deposited by the user plus any amount migrated from the user's Child Balance within the same pool. A user may migrate Child Balances to the Parent Balance to change that capital's behavior from "always self-compound" to being subject to the user's chosen Signal (SELF_COMPOUND or BOOST).

    • Child Balance: Yield that has been auto-compounded (SELF_COMPOUND signal) from the user's Parent Balance (or from another user's boosted rewards). Child Balances are tracked separately, always self-compound, accruing yield to their own balance, and cannot be directly redirected via Signals. They can only be harvested, migrated to the Parent Balance, or composed into a 3.NFT.

3.2.2. Signals: Directing Yield Flow

A Signal is a per-deposit instruction that dictates how rewards generated by its Parent Balance are processed.

  • Signal Commands:

    • SELF_COMPOUND: Rewards generated by the Parent Balance are used to grow the depositor's Child Balance within the same pool. This is the default growth mechanism for CDPs.

    • BOOST(Target_Pool): Rewards generated by the Parent Balance are redirected to become a Parent Balance deposit in a specified target CDP. This diversifies yield across asset types. This is the only available signal for LDP deposits.

  • Key Property: A user's Child Balance is independent of their Parent Balance's signal. Child Balances automatically SELF_COMPOUND, creating a recursive growth path.

3.2.3. The Harvest & Reward Processing Cycle

Yield is not automatically claimed. It must be processed through a community-driven harvest cycle, which respects the aggregate signals of all depositors.

  1. Master Harvest: Any user can call harvest(poolId) for a specific CDP/LDP. This function collects all accrued reward tokens from the external strategy into the Grove's reward distributor contract.

  2. Reward Deck & Process Routes: The harvested rewards are listed by asset type. For each reward asset, the system calculates the possible process routes based on the aggregation of all depositors' signals for that pool.

  3. Processing a Reward Route:

    • Case 1 (On-Reward): If the reward asset matches the pool's native deposit asset, the balance is sent directly back to the pool via an onReward() call, where it is distributed pro-rata to depositors according to their signal (increasing either their Child Balance or being boosted).

    • Case 2 (Swap & On-Reward): If the reward asset differs from the native asset, it is first swapped to the native asset of the destination pool (determined by the BOOST signal path) before the onReward() call is made.

  4. The Protocol as a Depositor: The Protocol Held Assets (PHA) are represented as deposits in CDPs/LDPs. The protocol receives yield and sets its own signals, participating in the system identically to external users.

3.2.4. 3Receipts and 3.NFTs

  • 3Receipts (ERC-20): Represent a user's claim on their Parent Balance in a specific Deposit Pool. The associated Child Balance is a virtual balance tracked internally by the smart contract; it is minted as ERC-20 tokens only upon migration to the Parent Balance or upon a claim/harvest action. 3Receipts are used for light, pool-specific governance.

  • 3.NFTs (ERC-721): Created by locking 3Receipts. This action changes the signal of the underlying assets to a LIQUIDATION_PATH.

    • Liquidation Process: 3.NFTs are grouped into collections by asset type. A user can call liquidate(collectionId) for a specific 3.NFT collection. This function: a. Retrieves the compounded Child Balances owned by the NFTs in that collection. b. Swaps these balances for crvUSD. c. Distributes the crvUSD pro-rata to the owners of the NFTs in the collection via an onReward() call to a dedicated pool.

    • Protocol Treasury Automation: The protocol locks its PHA into 3.NFTs. This ensures a portion of the ecosystem's yield is automatically converted to crvUSD (the system's base cash asset) upon liquidation, funding the Settlement Contract and Distribution Engine.

3.2.5. The Holding Contract

The Holding Contract is the protocol's main treasury wallet. It holds:

  1. The Protocol Held Assets (PHA) – the underlying yield-bearing derivative tokens (e.g., sdCRV, cvxCRV) as detailed in the protocol's asset table.¹

  2. The crvUSD generated from liquidating protocol-owned 3.NFTs. It acts as the primary depositor in Grove pools and the source of liquidity for the system's stability and distribution mechanisms.

¹ A detailed, live-view table of assets held is maintained at: https://docs.3.finance/protocols/the-grove/psus/holding-contract

PreviousThe GuildNextThe Reserve

Last updated