Liquity V2 Part 1: A New Chapter for Decentralized Stablecoins

If you’ve been following stablecoin innovation, you’ll know that few protocols have left a mark as strong as Liquity.
With BOLD and the Liquity V2 lending protocol, the team behind LUSD is back — staying true to its original principles while introducing a set of fresh design choices that deserve a closer look.

A solid legacy

Liquity V1 and LUSD set a new benchmark.
Praised by Bluechip — a stablecoin rating agency — as “the safest stablecoin protocol ever built”, LUSD stood out for its immutable architecture, minimal governance, and strong censorship resistance.
Even today, it remains one of the most credible algorithmic stablecoins in DeFi

What made LUSD particularly unique was its ability to maintain a $1 peg without relying on centralized assets. Unlike USDC or USDT-backed stablecoins, LUSD used only ETH as collateral and leveraged overcollateralized debt positions (Troves) to ensure solvency. Its design avoided many risks that traditional algorithmic stablecoins faced, like cascading liquidations triggered by sudden price shocks, while preserving full transparency for auditors and users alike.

BOLD carries forward that DNA with a few important commitments:

• Immutable / non-upgradable protocol logic — once deployed, it can’t be altered.

• Backed by exactly three hardcoded ETH-pegged assets (WETH, wstETH, rETH) — no reliance on centralized stablecoins like USDC or USDT.

• Governance stripped down to the bare minimum.

These aren’t cosmetic changes, they hardwire decentralization into the system from day one.

For auditors and developers, this immutability is both a blessing and a responsibility. There’s no patching a deployed contract; every detail must be audited, tested, and validated before launch. The system’s security guarantees rely entirely on correct deployment, which makes understanding every nuance of the protocol essential.

V1 set the bar. V2 raises it.

Where V1 favored a simple, single-collateral model, V2 introduces a more modular architecture without compromising its founding principles.

Borrowers can now set their own interest rate, anywhere between 0.5% and 250%. And one of the most impactful innovations is the arrival of Batch Troves.

In V1, each Trove was entirely independent. In V2, users can opt into a batch structure, where a dedicated manager contract oversees a group of Troves. The batch applies a single interest rate to all its Troves, while still keeping each user’s position separate. This shared structure streamlines management and simplifies liquidation logic.

V2 also expands the collateral set. Beyond ETH, it accepts WETH and two leading liquid staking tokens — wstETH from Lido and rETH from Rocket Pool.
Each collateral type is fully isolated, with its own TroveManager, StabilityPool, and BorrowerOperations contracts. This separation contains risk within each collateral branch while keeping the system cohesive.

By isolating collateral types into separate branches, the protocol ensures that a sudden failure in one asset (for example, a large price swing in rETH) cannot directly threaten other branches. From a security perspective, this modularity makes the system easier to audit, and it allows developers to add new collateral types in future forks without compromising existing branches.

The CollateralRegistry ties everything together. It tracks all supported collateral types, manages redemption entry points, and ensures that BOLD remains fully redeemable: users can always swap x BOLD for $x worth of WETH and LSTs (minus fees) directly with the system.
During redemptions, the registry routes withdrawals to the most undercollateralized branches — a design that helps restore the peg and reduce unbacked debt.

CollateralRegistry: Coordinating Multi-Collateral Redemption

A key component that enables BOLD’s multi-collateral design is the CollateralRegistry. This contract acts as the central coordinator for all supported collateral types, managing their trove managers and handling redemptions in a consistent, predictable manner

At deployment, the registry is initialized with:

• The BOLD token contract,

• An array of supported collateral tokens,

• Corresponding trove managers for each collateral.

The constructor ensures there’s at least one and at most ten collateral types, and stores them in immutable variables, emphasizing the protocol’s non-upgradability and predictability. Each trove manager is isolated to its branch, reinforcing risk segregation.

The core function of the registry is redeemCollateral. When a user redeems BOLD for underlying assets, the registry:

1. Collects the unbacked portions of all collateral branches. Only branches that are redeemable (e.g., TCR > SCR) contribute.

2. If no branch has redeemable unbacked debt, it falls back to proportional redemptions across all branches, ensuring users can still redeem.

3. Computes a redemption rate based on the amount redeemed and the time-decayed base rate. This mechanism discourages rapid, repeated redemptions that could destabilize the system.

4. Calls each trove manager to execute the actual collateral redemption. Finally, the redeemed BOLD is burned, maintaining the system’s supply equilibrium.

From a design perspective, CollateralRegistry is elegant in its simplicity:

• Independent collateral management: Each LST collateral is mapped to its branch-level TroveManager, allowing separate handling of different collateral types.

• Controlled redemption routing: BOLD redemptions are split across multiple Troves based on their share of “outside” debt, with a cap on iterations per collateral to maintain efficiency.

• User-protected fees: Redeemers set a maximum acceptable fee percentage to prevent unexpected fee increases due to transaction ordering.

Overall, CollateralRegistry is a key component of BOLD’s multi-collateral model. It centralizes collateral mapping and redemption routing, enabling modular expansion while ensuring predictable redemptions and maintaining system stability.

In the next parts of this series, we’ll dive deeper into how Troves and Batch Troves function, explore the multi-pool system that underpins BOLD’s stability, and dissect the mechanisms that maintain the $1 peg. Understanding these layers is crucial for anyone looking to audit, fork, or simply interact with the protocol safely.