---
title: "Liquity"
url: "https://caper.network/wiki/daos/stablecoins/liquity"
updated: 2026-09-10
license: CC-BY-4.0
license_url: "https://creativecommons.org/licenses/by/4.0/"
---

# Liquity

| Project | Liquity |
| --- | --- |
| Category | Decentralized borrowing protocol · collateral-backed stablecoin |
| Chain | Ethereum |
| V1 launched | [5 April 2021](https://www.liquity.org/blog/liquity-goes-live-on-ethereum-mainnet) |
| V2 (BOLD) launched | [23 Jan 2025](https://www.liquity.org/blog/liquity-v2-is-live); [redeployed 19 May 2025](https://www.liquity.org/blog/liquity-v2-redeployment) |
| Stablecoins | LUSD (V1) · BOLD (V2) |
| Token | LQTY — 100M fixed supply, fee-capture/staking token, **not** a governance token in V1 |
| Governance | **Governance-minimised** — immutable core with no admin key; V2 adds a single narrow lever (LQTY-staked incentive voting) that cannot touch core parameters |
| Primary sources | [liquity.org](https://www.liquity.org/features/governance-free) · [docs.liquity.org](https://docs.liquity.org) · [GitHub](https://github.com/liquity/bold) |

**Liquity** is a decentralized borrowing protocol on Ethereum whose defining choice is the near-total _absence_ of governance. Where most DAO-adjacent protocols concentrate power in a token vote, Liquity's rules are fixed in immutable smart contracts with [no admin key and no way for anyone to alter the system](https://www.liquity.org/features/governance-free). That makes it the clearest real-world example of the **minimal-governance pole** on the [DAO governance spectrum](/wiki/dao-governance/concepts/fundamentals/dao-governance-models) — a useful foil to the vote-escrow and treasury-heavy models catalogued elsewhere in this wiki, and a live case study in the tradeoff between adaptability and capture-resistance. Its closest sibling is [Reflexer’s RAI](/wiki/daos/stablecoins/reflexer-rai), which lands at the same immutable, ungoverned core from the opposite direction — deliberately removing governance rather than never granting it.

## Governance-free by design

Liquity V1 has [no admin key, no upgradability, and no token vote over its parameters](https://docs.liquity.org/liquity-v1/faq/general). Instead of humans voting on monetary interventions, the protocol adjusts its own borrowing and redemption fees algorithmically: a _base rate_ rises with redemption volume and decays over time, so fees respond to market pressure without a committee. The team's own framing is blunt — the design makes [“human interventions redundant”](https://www.liquity.org/features/governance-free).

Crucially, [the LQTY token is not a governance token](/wiki/dao-governance/concepts/treasury/dao-tokenomics): it captures protocol fee revenue and rewards Stability Pool depositors and front-end operators, but it grants no vote over the rules ([Liquity docs](https://docs.liquity.org/liquity-v1/faq/general)). This separates Liquity sharply from the one-token-one-vote norm — there is simply nothing to vote on, so a large LQTY holder cannot capture the protocol the way a whale can capture a token-weighted DAO.

## The mechanism

Liquity V1 issues **LUSD**, a USD-pegged stablecoin, against ETH collateral with an unusually low [110% minimum collateral ratio](https://docs.liquity.org/liquity-v1/faq/general) and **no ongoing interest** — borrowers pay a one-time fee (0.5%–5%) rather than a recurring rate. The peg is defended by three algorithmic backstops instead of a governance dial:

- **Redemptions at face value.** Anyone can always swap LUSD for $1 of underlying ETH, which arbitrages the price back toward the peg ([docs](https://docs.liquity.org/liquity-v1/faq/general)).
- **The Stability Pool.** LUSD deposited into the pool absorbs liquidated collateral, with depositors compensated in ETH plus LQTY — a permissionless, always-on liquidation engine that needs no keeper vote ([docs](https://docs.liquity.org/liquity-v1/faq/general)).
- **Fellow borrowers as backstop.** If the Stability Pool is ever exhausted, debt and collateral are redistributed across remaining borrowers, so the system stays solvent without an emergency governance action.

## Liquity V2 (BOLD): the smallest possible governance surface

[Liquity V2](https://www.liquity.org/blog/liquity-v2-is-live) launched in 2025 with a new stablecoin, **BOLD**, multiple collateral types (ETH and LSTs), and user-set interest rates. It keeps the immutability commitment — [core protocol parameters remain immutable after launch](https://github.com/liquity/V2-gov) — but adds _one_ narrowly scoped governance module, and nothing more.

Through [Protocol Incentivized Liquidity (PIL)](https://docs.liquity.org/v2-faq/lqty-staking), LQTY stakers vote on where to direct roughly **25% of protocol revenue** as liquidity incentives. Voting power is time-weighted (longer stakes weigh more), votes run in [weekly epochs starting Thursdays 00:00 UTC](https://www.liquity.org/blog/voting-in-liquity-v2), proposing a new initiative needs ≥0.01% of voting power plus a 100 BOLD fee, and initiatives below a 2% vote share for four consecutive epochs can be permissionlessly unregistered. This is explicitly a Curve-style incentive market — complete with [bribe markets](https://www.liquity.org/blog/bribe-markets-in-liquity-v2-strategic-value-for-lqty-stakers) echoing the [Convex/Votium vote-buying dynamic](/wiki/daos/lending/convex-finance) — but bolted onto an otherwise ungovernable base layer. The governance module [“has no control over any of the core protocol parameters”](https://github.com/liquity/V2-gov): it can only decide where the incentive budget flows.

The immutability commitment cuts both ways. When a [Stability Pool issue was found after the January 2025 launch](https://www.liquity.org/blog/liquity-v2-redeployment), the team could not patch in place — an immutable protocol has no upgrade switch — so V2 had to be _redeployed_ from scratch on 19 May 2025 after further audits. Governance-minimisation buys capture-resistance at the cost of adaptability; there is no committee to blame, and also no committee to fix a bug.

## Where it sits on the governance spectrum

Liquity matters to DAO design precisely because it is the extreme case. Most of this wiki's ecosystem entries — [Curve](/wiki/daos/dexs/curve-dao), [Convex](/wiki/daos/lending/convex-finance), and the wider vote-escrow cluster — answer “who decides?” by engineering ever-more-elaborate vote-weighting. Liquity answers it by [removing the attack surface](/wiki/dao-governance/concepts/analysis/dao-security-and-governance-attacks): an immutable contract cannot be governance-captured, socially engineered into a malicious upgrade, or drained by a hostile proposal, because there is no privileged action to seize. The cost is rigidity — the parameters that suit 2021 are the parameters you keep, and fixing anything means shipping an entirely new protocol and migrating users. It is a deliberate bet that a small, fixed, well-audited rule set beats a flexible one that can be turned against its users. For the opposite pole — a stablecoin whose borrow rate, mint caps, and peg backstop are all live governance votes — see [Aave’s GHO](/wiki/daos/stablecoins/aave-gho).

## How Caper approaches this

Caper sits at the opposite pole from Liquity, and the contrast is instructive. Liquity protects a fixed monetary policy by making the protocol _ungovernable_; Caper makes governance the entire point but ties it to something a whale cannot cheaply buy. In a [caper](/wiki/foundations/what-is-a-caper) the treasury _is_ the governed object, and a member's [vote weight](/wiki/governance/voting) is `(held × votes) / (vote_supply × circulation)` — a product of tokens held and a **soulbound, non-transferable proof-of-participation** earned 1 per ballot cast and 0.01 per XRD of gross trade value (verified against `compute_vote_weight` in `contracts/common/src/lib.rs` and the `DIVISIBILITY_MAXIMUM` vote token in `contracts/core/src/caper_dao.rs`). The same figure sets each member's share of the treasury on exit — the weight itself, not a pro-rata slice by balance. What a whale cannot cheaply buy is not the record itself — buying on the curve earns it — but another member's, because it never leaves the account that earned it.

Both designs reject plutocratic one-token-one-vote — but from opposite directions. Liquity removes the decisions so they cannot be captured; Caper keeps every decision on-chain and anchors it to earned, un-rentable stake, so a fixed rule set isn't needed to stay capture-resistant. Liquity's immutability-vs-adaptability tradeoff is the price of having no governance at all; Caper accepts governance and spends its effort making that governance hard to buy.