Liquity V2 Part 2: Diving Deeper – Troves, Batch Troves, and the Trio of Pools

The Mechanics of Troves and Batch Troves in Liquity V2

At the core of BOLD, users still interact with Trove positions — overcollateralized debt accounts similar to those in Liquity V1. Each Trove records the amount of collateral a user deposits and the corresponding BOLD debt issued. Every collateral type (WETH, wstETH, or rETH) maintains its own isolated Trove system, managed independently. Users can choose their own interest rate, giving them flexibility to manage debt exposure according to their risk preferences.

Liquity V2 also introduces Batch Troves, which group multiple individual Troves under a single management layer. While collateral is stored individually per Trove, the total batch collateral is tracked in the Batch struct for informational purposes. The BatchManager sets a single interest rate for all Troves in the batch, constrained within an immutable range defined at registration. Each Trove in a batch is also subject to a batch management fee, which is fixed and known in advance.

Batch Troves enforce stricter collateral requirements via the Buffer Collateral Ratio (BCR), which sits above the Minimum Collateral Ratio (MCR). Troves can only join or be modified within a batch if their collateral ratio exceeds MCR + BCR. This safeguard, implemented in _requireICRisAboveMCRPlusBCR, prevents Troves from immediately becoming liquidatable after adjustments. Only a genuine price drop can trigger liquidation, preserving system stability.

This dual-layered approach — individual Troves and optional batch-level coordination — provides flexibility for users and integrators while maintaining decentralization and transparency.

---

The Trio of Pools: Stability, Active, and Default Pool Mechanics

At the heart of Liquity V2 lies a subtle but powerful design: the interaction between the Stability Pool, the Active Pool, and the Default Pool. Together, they orchestrate liquidations, collateral redistribution, and systemic stability in a way that preserves the elegance of V1 while making the protocol more adaptable.

1. The Stability Pool: First Line of Defense

The Stability Pool is where users deposit BOLD to secure the system. Users deposit BOLD tokens and earn rewards from liquidations and interest payments. Borrowers pay interest on their loans, with 75% distributed to Stability Pool participants and 25% allocated to the InterestRouter for protocol stakeholders.

When liquidations occur, the pool’s offset() function uses deposited BOLD to repay liquidated Troves’ debts. Two variables, P and S, efficiently track compounded deposits and accumulated collateral gains in O(1) time, ensuring proportional distribution of collateral to participants. The pool always maintains at least 1 BOLD token (MIN_BOLD_IN_SP) to prevent complete depletion.

The flow of yield and incentives can be summarized visually (Figure 1). It illustrates how individual Troves and Batch Troves direct 75% of interest to the Stability Pool, while the remaining 25% flows to LPs via the InterestRouter.

Figure 1: Visual representation of yield flow from individual Troves and Batch Troves. 75% of yield goes to the Stability Pool, rewarding BOLD stakers, while 25% flows through the InterestRouter to incentivize BOLD LPs.

2. The Active Pool: The Collateral Reservoir

The Active Pool is the central ledger for a branch’s total collateral and aggregate BOLD debt. It manages interest distribution, minting yield during system operations and splitting it between the Stability Pool (75%) and the InterestRouter (25%). Efficient tracking is achieved through two variables:

• aggWeightedDebtSum — sum of Troves’ debts weighted by interest rates

• aggRecordedDebt — total system debt including accrued interest

Interest is calculated as:

interest = aggWeightedDebtSum timeElapsed / (ONE_YEAR DECIMAL_PRECISION)

This avoids iterating over individual Troves while keeping debt accurate. The Active Pool also handles batch management fees, calculates the average interest rate for new borrows (aggWeightedDebtSum / aggRecordedDebt), and supports collateral transfers to the Default Pool or redeeming users through sendColl and sendCollToDefaultPool.

Beyond interest, the Active Pool also:

• Handles batch management fees, keeping group operations efficient.

• Calculates the average interest rate for new borrows.

• Transfers collateral to the Default Pool during liquidations or directly to users during redemptions, via the functions sendColl and sendCollToDefaultPool.

In short, the Active Pool is the system’s collateral reservoir, keeping balances accurate, scalable, and resistant to manipulation while forming the foundation for all debt accounting.

3. The Default Pool: The System’s Safety Net

The Default Pool acts as a temporary holding area for collateral and BOLD debt from liquidated Troves pending redistribution. It maintains:

• collBalance — total collateral from liquidated positions

• BoldDebt — total associated BOLD debt

Rather than redistributing assets immediately, the system defers redistribution until an active Trove operation occurs (borrow, redeem, or liquidation). Pending rewards are then transferred to the Active Pool and applied to the Trove’s position. This deferred approach reduces gas costs, decouples liquidation from redistribution, and preserves system stability while maintaining fair allocation of liquidated assets.

This design is particularly resilient during cascading liquidations, since multiple Troves can be processed together without burdening the system with repeated state updates.

In short, the Default Pool is the safety net and router of liquidated collateral. By buffering flows between the Active Pool and the Stability Pool, it makes liquidations efficient, fair, and gas-conscious — protecting both depositors and the system’s overall stability.

---

With Troves, Batch Troves, and the Trio of Pools working in concert, Liquity V2’s BOLD protocol achieves a balance of resilience, efficiency, and decentralization. In the next section, we’ll explore how the stabilization mechanism works, the batch-level interest optimization, and redemption dynamics.