What is Liquity?
Learn what Liquity is, how its BOLD stablecoin and Troves work, and why its immutable, governance-free borrowing model appeals to ETH users.

Introduction
Liquity is a borrowing protocol that lets people lock crypto collateral and mint a USD-pegged stablecoin against it. The interesting question is not just what it does, but why its design feels different from many other lending protocols: Liquity is built around the idea that core borrowing infrastructure should run without ongoing admin control or governance intervention once deployed.
That design choice shapes almost everything else. If a protocol cannot be tuned every week by token holders or a multisig, then the rules for borrowing, liquidation, redemptions, and incentives have to do more work up front. Liquity’s promise is simple in user terms: if you hold ETH or certain staked-ETH assets and want liquidity without selling them, you can deposit that collateral, mint the protocol’s stablecoin, and manage the position on-chain. But under the surface, the protocol is trying to solve a harder problem: how to keep a crypto-backed stablecoin usable and reasonably stable while relying as little as possible on human discretion.
In Liquity V2, the stablecoin is BOLD, and the supported collateral is WETH, wstETH, and rETH. Users open collateralized debt positions called Troves, choose their own borrowing interest rate, and can also use the system for leveraged exposure through looping. The result is a system aimed at a specific kind of user: someone comfortable with on-chain borrowing, price volatility, and liquidation risk, who values self-custody, predictable rules, and capital efficiency over hand-held convenience.
How can I get dollar liquidity without selling my ETH?
| Option | Ownership | Upside exposure | Liquidity | Trust model | Main risk |
|---|---|---|---|---|---|
| Sell ETH | No; you sold | Lose future upside | Immediate | Exchange custody | Locked in market price |
| Borrow BOLD (Liquity) | Keep ownership | Retain upside | Instant minting | Protocol rules, immutable | Liquidation risk |
| Borrow on pooled lending | Keep ownership | Retain upside | Depends on pool liquidity | Governance-controlled protocol | Parameter or admin changes |
The problem Liquity solves is easy to state. Many crypto holders want cash-like liquidity, but selling ETH creates a different exposure profile: once you sell, you no longer own the asset, and you may give up future upside. A collateralized borrowing protocol offers another path. You lock the asset, keep economic exposure to it, and borrow against it instead.
Liquity’s version of this model is overcollateralized borrowing. You deposit more value in crypto than the amount of stablecoin you mint. That excess collateral is the safety buffer that protects the system if collateral prices fall. In V2, the stablecoin you mint is BOLD, which is designed to be redeemable for $1 worth of protocol collateral. That redeemability matters because it gives the peg a hard anchor: BOLD is not merely intended to be worth about a dollar; the protocol gives holders a path to exchange it against underlying collateral at face value, subject to protocol mechanics.
At the user-facing level, the experience starts with a Trove. A Trove is your individual debt position: it holds your collateral, your BOLD debt, and the interest rate you chose for that position. If you later add more collateral, repay BOLD, mint more BOLD, or adjust your chosen rate, you are modifying that Trove rather than interacting with a pooled margin account. That makes the position legible: your risk lives in one place, and its solvency depends mainly on the relationship between your collateral value and your debt.
How does Liquity V2 manage Troves, collateral branches, and user‑set rates?
| Collateral | Yield | Capital efficiency | Oracle dependency | Best for |
|---|---|---|---|---|
| WETH | No staking yield | Standard LTV | Simple price feed | Conservative borrowers |
| wstETH | Accrued staking yield | Higher LTV potential | Staking oracle required | Stakers needing liquidity |
| rETH | Rocket Pool staking yield | Higher LTV potential | rETH oracle required | Users preferring decentralization |
Liquity V2 is a multi-collateral system. Instead of one single pool of collateral, it is organized into collateral branches, each tied to a supported asset and parameterized separately. The protocol’s technical design uses a top-level registry to map these branches and route certain system actions across them. This matters because WETH, wstETH, and rETH do not have identical risk profiles. Staked ETH derivatives can bring extra yield and capital efficiency, but they also bring extra dependency on the staking protocols and their price behavior.
A simple way to understand borrowing on Liquity is to follow a borrower who holds wstETH. They deposit wstETH into a Trove and mint BOLD. At that moment, they have not sold the wstETH; they still have price exposure to it, and they also still carry the debt they just created. They might use the BOLD as spending liquidity, swap it into other assets, or loop it back into more collateral to increase exposure. If the collateral price rises, their position becomes safer. If it falls enough, the safety buffer shrinks, and liquidation risk increases.
What makes V2 unusual is user-set interest rates. Rather than having the protocol impose a single borrowing rate on everyone, each borrower chooses the annual interest rate on their Trove. Conceptually, that turns borrowing cost into a market variable the borrower actively manages. A borrower who wants to minimize carry might choose a lower rate, but that choice is not free of consequences elsewhere in the system. Liquity’s design uses these borrower-set rates as a core revenue source for BOLD holders and related liquidity mechanisms, and they also interact with the protocol’s redemption logic.
The intuition is that Liquity is trying to create a live market between two sides: borrowers who want cheap leverage or liquidity, and holders or depositors who want yield and peg stability. Instead of governance committees steering that market, the protocol leans on redemptions, interest-rate choice, and liquidation rules to coordinate behavior.
How do redemptions restore the BOLD peg and who is affected?
In many stablecoin systems, the peg is discussed mainly in terms of market confidence. Liquity adds a stronger mechanism: redemption. A BOLD holder can redeem BOLD for $1 worth of protocol collateral. That creates a reason for the market price to gravitate back toward parity when BOLD trades below a dollar. If BOLD becomes cheaper than face value on the market, arbitrageurs can buy it and redeem it through the protocol.
That is the high-level function. The implementation is more specific. In V2, redemptions are routed across collateral branches according to each branch’s outside debt, which is the branch’s total BOLD debt minus the BOLD sitting in that branch’s Stability Pool. In plain language, the protocol aims redemptions toward the parts of the system where debt is less buffered by stability capital. This is not just bookkeeping. It is a way of using redemptions both to support the peg and to reduce pressure where the system is relatively more exposed.
There is also an important user consequence here. Redemptions can affect borrowers even if they are not being liquidated. In V2, a Trove is not necessarily closed by redemption. A position that gets redeemed down below the minimum debt can become a so-called zombie Trove with restricted behavior until it is adjusted back above minimum debt. So the borrower’s risk is not only “will my collateral ratio fall too far?” but also “how does my position behave if the system is actively using redemptions to defend the peg?”
What does the Stability Pool do during liquidations and what do depositors earn?
If redemptions help defend the peg, the Stability Pool helps absorb bad debt during liquidations. Each collateral branch has its own Stability Pool. Users deposit BOLD into it, and that BOLD is used to offset debt from undercollateralized Troves when liquidations happen. In exchange, depositors receive the seized collateral from those liquidations, along with protocol yield.
The mechanism matters because liquidation is the moment when a collateralized lending protocol proves whether its accounting is real. When collateral prices fall sharply, unsafe positions must be resolved fast enough that the system does not accumulate unbacked debt. Liquity’s model is to use the Stability Pool as the first line of absorption. That makes the pool economically attractive to users who are willing to hold BOLD and take liquidation-event exposure in return for yield and collateral gains.
In V2, branch-level interest accrual is also turned into fresh BOLD system yield, with a portion sent to the branch Stability Pool and the remainder routed for liquidity incentives. The broader economic idea is that borrower interest should not vanish into a treasury waiting for governance decisions. Instead, protocol revenues are directed back into the parts of the system that support peg stability, BOLD demand, and on-chain liquidity.
This gives Liquity two natural user groups. Borrowers are here because they want liquidity or leverage against ETH-like collateral. Stability Pool depositors and BOLD holders are here because they want yield tied to protocol activity and liquidation mechanics. The design only works if both sides show up: borrowers create demand for BOLD and generate revenue, while depositors and holders provide the balance-sheet support that makes the stablecoin more credible.
Why choose an immutable, governance‑free lending protocol and what are the trade‑offs?
| Model | Admin control | Upgradeability | Fixability | Best for |
|---|---|---|---|---|
| Governance-free (immutable) | No admins or multisig | Immutable after deploy | Bugs hard to fix on-chain | Users avoiding insiders |
| Governance-upgradeable | Admins or token holders | Parameters or code can change | Bugs patchable via governance | Users valuing flexibility |
Liquity is explicit about being immutable and governance-free at the core protocol level. The attraction is straightforward: fewer privileged actors means fewer ways for insiders to change the rules, capture value, freeze users out, or introduce governance risk after launch. For users who distrust protocol politics as much as smart-contract risk, this is a real product feature, not a slogan.
But the trade-off is equally real. If a protocol cannot be upgraded, then mistakes are harder to fix, and parameters cannot be adjusted as market conditions change. Liquity’s own materials emphasize that the protocol cannot be changed or upgraded once deployed, and that price oracles are its key external dependency. So the trust model shifts rather than disappears. You trust fewer humans, but you become more exposed to the quality of the initial design, the correctness of the code, and the robustness of oracle inputs.
The frontend model reflects the same philosophy. Liquity does not run its own frontend; users access the protocol through independent interfaces. That improves decentralization at the access layer, but it also means users must choose a frontend operator themselves and evaluate its trustworthiness and functionality. For an experienced DeFi user, that may feel natural. For a newcomer expecting a single official app, it is a meaningful usability hurdle.
Which users benefit most from Liquity and what risks should they manage?
Liquity is strongest for users who already want to stay long ETH or staked ETH and need liquidity without unwinding that position. It is also attractive to users who care about high borrowing capacity and are comfortable managing leverage actively. The protocol advertises borrowing up to high loan-to-value levels and supports one-click looping, which can increase ETH or LST exposure quickly.
That same strength is also the main danger. High capital efficiency means thinner safety margins. A borrower using aggressive leverage is making a strong bet that collateral prices will not move against them too far or too fast. Supporting wstETH and rETH expands utility for staked-ETH holders, but it also means users must think beyond ETH price alone. They are taking layered risk: the borrowing protocol, the collateral asset, the oracle system, and the staking protocol behind the LST.
So Liquity is not designed for someone looking for a bank-like savings product with hidden complexity removed. It is designed for users who want transparent, on-chain credit against ETH-linked assets, and who are willing to manage the consequences themselves. That includes active borrowers, leveraged ETH bulls, arbitrageurs, and yield-seeking BOLD or Stability Pool participants.
Conclusion
Liquity is best understood as a bet that collateralized borrowing can be run by hard rules instead of ongoing management. You lock ETH or staked ETH collateral, mint BOLD, and interact with a system built around Troves, user-set rates, redemptions, and Stability Pools.
What makes it memorable is not just that it lets you borrow against crypto. Many protocols do that. What makes Liquity distinctive is the combination of immutable design, borrower-controlled rates, and redemption-driven peg mechanics. If you want liquidity without selling your ETH and you prefer protocol rules over protocol politics, that is the reason Liquity exists.
How do you evaluate a DeFi lending or collateral market before using it or buying related tokens?
Evaluate a DeFi lending or collateral market by verifying its collateral rules, liquidation mechanics, revenue flows, oracle model, and upgradeability; these factors determine the real risk you take when using the protocol or buying related tokens. Use Cube Exchange to research on‑chain metrics and official docs, then trade tokens if your assessment supports it.
- Check which collateral types the protocol accepts and their branch parameters (min collateral ratio, min debt, whether LSTs like wstETH or rETH are supported).
- Review liquidation and peg defenses: confirm Stability Pool size, redemption routing rules (e.g., outside debt logic), TCR thresholds, and whether redemptions can create zombie positions.
- Inspect revenue and incentive flows: verify borrower interest mechanics (user‑set rates), how interest is converted to protocol yield, and whether revenue splits are finalized in the docs or code.
- Verify oracle and governance risk: identify primary price feeds and fallbacks, read audit findings about oracle edge cases, and confirm whether core contracts are immutable or upgradeable.
- If you decide to buy a token, fund your Cube account, choose limit or market orders to control execution (use limit for thin markets), set order size relative to on‑chain liquidity, and monitor position post‑trade for protocol updates or on‑chain events.
Frequently Asked Questions
Liquity is a crypto‑backed borrowing protocol where users lock ETH or supported staked‑ETH (WETH, wstETH, rETH) in an individual Trove to mint the dollar‑pegged stablecoin BOLD; it targets users who want on‑chain liquidity or leverage without selling their ETH and who prefer predictable, governance-free rules over frequent parameter changes.
Each borrower selects the annual interest rate for their own Trove, so borrowing cost is a borrower‑chosen market variable that influences both individual carry and protocol revenue; the whitepaper and docs describe the concept but do not publish exact limits or the low‑level settlement mechanics, which remain unspecified in public docs.
If BOLD trades below $1, arbitrageurs can buy it on market and redeem it for $1 worth of protocol collateral, which creates a hard peg anchor; in practice redemptions are subject to protocol constraints (for example redemptions were disabled for the first 14 days after launch and are blocked when system TCR < 110%), so real‑world redemptions can be limited by on‑chain rules and system state.
Redemptions in V2 are routed across collateral branches according to each branch’s outside debt (defined as the branch’s total BOLD debt minus the BOLD held in that branch’s Stability Pool), so the protocol directs redemptions toward branches with proportionally less stability buffer.
Each collateral branch has its own Stability Pool where users deposit BOLD; that BOLD is used first to offset debt from undercollateralized Troves during liquidations, and depositors receive the seized collateral plus protocol yield as compensation for taking liquidation exposure.
Redemptions do not always close a Trove - if a Trove’s debt is reduced below the protocol minimum by redemptions it can become a "zombie Trove" with restricted behaviour until the owner brings it back above minimum debt, so borrowers are exposed to redemption‑driven state changes even if they aren't being liquidated.
Troves in the V2 codebase are represented by TroveNFTs and are therefore transferable on‑chain, enabling composability and transfer of positions rather than keeping every Trove locked to a single owner address.
Liquity relies on external price oracles and the codebase includes fallback and timeout logic (e.g., Chainlink/Tellor fallbacks and minimum age constraints), but oracle behaviour introduces known attack and edge‑case vectors (price frontrunning, stale feeds) and auditors recommend operational playbooks because some mitigation and response procedures are off‑chain or not fully finalized.
Branch interest accrual is converted into fresh BOLD yield with a share sent to the branch’s Stability Pool and the rest directed toward liquidity incentives, but the exact allocation splits and some numeric parameters are marked as TBD in the public repo/docs, so the final revenue distribution is not fully finalized in public materials.
Related reading