Liquity V2

Liquity V2 is a CDP-based lending and stablecoin protocol that extends the original Liquity design on Ethereum, but with a more flexible interest-rate and collateral framework. 1. Basic Identification

• Name: Liquity V2
• Category: Non-custodial lending / CDP stablecoin protocol (successor to Liquity v1)
• Website: Not verifiable as of 2026-08-28.
• Docs: Not verifiable as of 2026-08-28.
• Chains: Ethereum (no credible evidence of other deployments).
• Launch date: Public mainnet deployment date is not clearly stated in independent sources; Not verifiable as of 2026-08-28.
• Native / primary token: V2 continues to use LUSD (overcollateralized stablecoin) and LQTY (fee-capture / incentive token) in design narratives, but explicit V2 token changes vs v1 are not independently specified; Not verifiable as of 2026-08-28. Because Dune MCP is unavailable and there is limited independent coverage, all on-chain specific metrics and addresses are Not verifiable as of 2026-08-28. 2. Main Contracts & Explorer Verification
• Exact core contract addresses (e.g., V2 TroveManager, StabilityPool, BorrowerOperations, or equivalent) for Liquity V2 on Ethereum cannot be confidently identified or cross-checked across at least two independent sources without relying on self-reported protocol info.
• Not verifiable as of 2026-08-28.
• Consequently, explorer verification status (Etherscan verified-source flags) for Liquity V2 contracts is also Not verifiable as of 2026-08-28. 3. Fork Lineage & Design Changes
• Liquity V2 is consistently described in secondary commentary as an evolution of Liquity v1, which is itself a well-known Ethereum protocol enabling zero-interest borrowing against ETH with algorithmic stability mechanisms.
• Independent sources frame V2 as introducing more flexible interest-rate policy and updated risk parameters compared with v1, but do not supply detailed technical diffs or formal fork declarations.
• There is no clear evidence from auditors or independent researchers that Liquity V2 is a direct Solidity-level fork of another upstream protocol beyond its own Liquity v1 codebase; Not verifiable as of 2026-08-28. 4. Audits & Malicious-Modification History
• Public audit reports specifically titled for “Liquity V2” (as distinct from Liquity v1) are not findable across major auditor repositories; Not verifiable as of 2026-08-28.
• No independent records of malicious modifications, rug-pull code patterns, or exploit history tied to “Liquity V2” deployments are observable in mainstream analytics or incident databases; Not verifiable as of 2026-08-28. Given these gaps, Liquity V2 should be treated as poorly documented from an independent-risk perspective until verified contract addresses, audits, and launch details are available from at least two non-protocol sources.

Liquity V2 appears to be a real, live product rather than a simple landing page: the main site points users to an active app at liquity.app/borrow, while the docs describe the protocol, borrowing flow, and technical resources in detail. The documentation site is mature enough to expose markdown versions, a complete index, and separate pages for FAQ and technical audits, which is a stronger signal than marketing-only docs. The product surface also looks functional: Liquity’s own guide says users can deposit collateral (ETH, wstETH, rETH) to mint BOLD, and the site says frontends are hosted by the community, including Liquity.App, DeFi Saver, and LQTY.IO. That suggests a multi-frontend setup rather than a single template landing page. Open API: yes, there is a public API surface. GitHub and APIs.io both indicate api.liquity.org publishes JSON feeds for protocol stats, website data, and governance data. This is a meaningful maturity signal because it supports machine-readable integration, though it is still an off-chain API rather than a proof of on-chain state. What cannot be fully verified from the gathered sources: live deposits/withdrawals in production, broken links, fake metrics, or template-site signs are not verifiable as of 2026-08-28 without direct interactive testing and chain checks. The site and docs are consistent with a live protocol, but that does not by itself prove current user flows are error-free. Overall: Liquity V2 looks like a mature, deployed DeFi protocol with active docs, multiple frontends, and a public API; the remaining UX health checks are Not verifiable as of 2026-08-28.

Bold smart contract audit / code assessment. The supplied summary says the audit focused on functional correctness, rounding issues, and external integrations, and that prior issues in zappers, rounding in debt shares, and Balancer/leverage-zapper integrations had been resolved. The provided excerpt does not include the exact critical/high/medium issue counts for this report, so those counts are Not verifiable as of 2026-08-28 from the supplied text. Fix status: the summary explicitly states the cited issues were resolved. Bytecode-match / deployed-code coverage: Not verifiable as of 2026-08-28.

Bold Core smart contract audit. The report covers the Solidity implementation of Liquity V2 at repo liquity/bold, commit aa8361269bb505de06afbe5a6646160cc9a935ef. Coinspect’s public blog highlights two significant findings: BOLD-01 (approval reset renders Leveraged Zappers unusable) and BOLD-05 (a single-oracle failure can halt redemptions across all branches, potentially causing a depeg). The supplied PDF excerpt does not enumerate severity counts beyond those named findings, so critical/high/medium totals are Not verifiable as of 2026-08-28 from the provided text. Fix status: not clearly stated in the supplied sources. Bytecode-match / deployed-code coverage: Not verifiable as of 2026-08-28.

Core protocol audit I. The report covers Liquity v2 (BOLD) smart contracts in the private repo liquity/bold, branch dev, at commit 2a859733eff540aae2996d13b06a9c5d334e7616. The audit found several accounting bugs, mostly around batch interest delegation, but no critical severity issues. The report recommends further testing and potentially a second audit before deployment. Fix status: the later Dedaub re-audit says the second audit mainly examined updates after this initial audit and reviewed some fixes from this phase, but a full issue-by-issue closure list is not provided in the supplied sources. Bytecode-match / deployed-code coverage: Not verifiable as of 2026-08-28.

Core protocol audit II. The report covers Liquity v2 (BOLD) smart contracts in liquity/bold at commit 96fa8431dd74765cd4e5e59f4669f8c967ce91b6, focusing on updates after the first Dedaub audit. The report states no critical, high, or medium severity issues. Fix status: the report indicates prior findings had been addressed before this re-audit, but no additional issue remediation table is given in the supplied sources. Bytecode-match / deployed-code coverage: Not verifiable as of 2026-08-28.

Governance audit (re-audit). The report covers the Liquity v2 governance repository liquity/V2-gov at PR #17 commit 549877d976781b390207e0faacbc567a614c9681, including BribeInitiative.sol, CurveV2GaugeRewards.sol, ForwardBribe.sol, Governance.sol, UniV4Donations.sol, UserProxy.sol, and UserProxyFactory.sol. The supplied excerpt states no critical severity issues. It also says the fixes from included issues were mostly reviewed in a later full re-audit. The excerpt does not provide complete high/medium counts, so those are Not verifiable as of 2026-08-28. Bytecode-match / deployed-code coverage: Not verifiable as of 2026-08-28.

Liquity has an active bug bounty program for Liquity V2, with submissions routed through Cantina. The current V2 bounty page shows a program start date of 1 Jul 2025 and lists rewards by severity for liquity/bold and liquity/V2-gov: Critical up to $125,000 / $25,000, High up to $62,500 / $12,500, Medium up to $12,500 / $2,500, and Low as discretionary; the page also says actual rewards are at Liquity’s sole discretion. For results, the sources provided do not report a public tally of paid findings, total payouts, or disclosed confirmed vulnerabilities for the active V2 program. That is Not verifiable as of 2026-08-28 from the supplied sources. Liquity’s earlier, broader bug bounty began on 19 Feb 2021, covered all smart-contract components of Liquity at the time, and used CVSS v3 scoring with rewards ranging from $500 to $50,000; Liquity later states that the V1 bug bounty was discontinued with the launch of Liquity V2.

Liquity V2’s main external dependency is Chainlink price oracles; the protocol itself states that collateral price oracles are its sole external dependency, and audits confirm that oracle failure, stale prices, or invalid values can trigger branch shutdowns and impair liquidations/redemptions. Dependency / counterparty profile:

• Oracle risk: High. Liquity V2 prices ETH and LST collateral via Chainlink feeds, with branch shutdown on failure/staleness; this creates direct exposure to oracle outages, freeze events, or delayed updates.
• Manipulation risk: Medium to high on LST branches. Liquity’s own repo says it uses multiple price sources and takes the minimum/maximum in some operations to reduce upward manipulation risk, but LSTs can still face thin liquidity, few venues, and smart-contract/exchange-rate risks.
• Collateral dependency: The system supports ETH, wstETH, and rETH as collateral, so exposure is to Ethereum-native assets and their underlying protocols (Lido/Rocket Pool) rather than bridges, custodians, or RWA issuers.
• Bridge / custodian / RWA / CEX exposure: Not verifiable as of 2026-08-28 from the gathered sources; no evidence here of direct bridge, custodian, RWA issuer/SPV, or CEX/MM dependence.
• Stablecoin dependency: BOLD is described as Ethereum-native and “completely on-chain,” so the principal stablecoin risk is endogenous protocol/peg risk, not dependence on an external fiat-backed stablecoin. Failure / depeg / insolvency scenarios:
• A Chainlink failure or stale price can cause branch shutdowns, prevent normal borrowing, and make redemptions or liquidations occur at wrong prices until shutdown logic engages.
• Audit and repo materials note that oracle failures can lead to excess liquidations, excess minting, or redemption dysfunction, which can pressure the BOLD peg.
• For LST collateral, an adverse event in the underlying staking protocol or exchange-rate feed could impair collateral valuation and intensify liquidation/redemption losses.

Liquity V2 is organized so that users keep direct control of their own collateral and stablecoins rather than handing assets to a custodian. The official docs say users retain full control over their assets, minters can always withdraw collateral, and BOLD cannot be frozen. In practice, collateral is deposited into smart contracts to open a Trove, and the protocol mints BOLD to the user’s Ethereum address; this is a non-custodial, contract-based arrangement rather than third-party custody. Liquity V2 is also immutable and has no upgradeable admin path or treasury-based custodian role, and governance is limited to directing protocol incentives, not controlling user funds.

The main measurable impact reported publicly was outflows rather than a confirmed direct loss: Cointelegraph cited more than $17 million in 24-hour outflows after the warning, while The Defiant cited about $30 million over two days; these figures reflect liquidity exits, not a documented exploit loss to users.

Liquity V2 had a Stability Pool (“Earn”) issue disclosed on Feb. 12, 2025; the team said the protocol continued to work as expected, no users were known to be impacted, and the issue appeared isolated to the Stability Pool, with a redeployment/patched version planned.

Liquity V2 is organized to minimize centralized key control. The core protocol contracts are described as immutable and Ethereum-native, with no upgrade governance over the borrowing system itself. Governance in V2 is limited to allocating 25% of protocol revenues to external initiatives through an LQTY-based voting system; it does not control core protocol parameters or contract upgrades. For interest-rate management, Liquity V2 uses an Autonomous Interest Rate Manager (ARM) rather than a human admin key. The ARM consists of three batch manager contracts on Ethereum Mainnet—one per collateral type—and a single management canister on the Internet Computer. Each batch manager has a pre-registered externally owned account (EOA) owner, and that EOA is the only address authorized to perform interest-rate adjustments on behalf of delegating loans. So, key management is split into two layers: core protocol control is effectively removed by immutability, while the only explicit privileged operational key described in the sources is the ARM owner EOA for rate updates.

Liquity V2 on Ethereum appears to be non-upgradeable at the protocol logic level: Liquity’s audit/blog states the deployment is intended to be immutable and that upgrading smart contracts is not an option, while the docs’ risk disclosure also says there are no upgradable code, no upgradable parameters, and no timelocks. The governance address is documented as 0x807def5e7d057df05c796f4bc75c3fe82bd6eee1. Liquity’s documentation further states there are no manual pause, freeze, or shutdown functions; instead, markets can enter automatic shutdown under extreme collateral-price stress or oracle failure. That means the main admin-risk profile is not discretionary owner control, but *system design / oracle / market-health risk*. What this implies for user exit and freeze risk: users can still exit in normal and stressed states through repayment/redemption mechanics; Liquity says collateral withdrawal remains allowed when paired with sufficient debt repayment, and after shutdown users can redeem BOLD against collateral. So the protocol is designed to reduce rug/freeze risk by removing discretionary admin switches, but *branch shutdown conditions* still create a functional freeze on new borrowing for a market under extreme conditions. Proxy / admin architecture: the web evidence available here does not verify a proxy-admin or upgrade-admin role for Liquity V2; the available sources instead point to an immutable deployment and no upgrade path. The Etherscan result shows an ERC1967Proxy pattern exists somewhere on Ethereum, but that result is not sufficient to bind it to Liquity V2 without contract-by-contract confirmation, so the proxy-admin type is Not verifiable as of 2026-08-28. Role/function map:

• Owner / emergency pause: no manual pause/freeze/shutdown admin function disclosed; Not verifiable as of 2026-08-28 for any privileged pause key.
• Upgrade / proxy admin: no upgradeability claimed; Not verifiable as of 2026-08-28 for any upgrade key because no on-chain verification was available in this run.
• Fee / oracle / strategy controls: protocol docs mention borrowing-fee mechanics and oracle-driven shutdown thresholds, but any privileged controller for these is Not verifiable as of 2026-08-28. Worst case if keys were compromised: based on the sourced documentation, there is no disclosed admin key that can directly upgrade, pause, or freeze the core protocol; the realistic worst case is therefore *oracle corruption or governance-layer compromise*, which could misprice risk parameters indirectly, rather than a classic “admin drains funds” rug via upgrade rights. Architecture diagram: Users -> Troves / branch markets -> BOLD / collateral registry -> oracle inputs -> automatic CT/ST shutdown logic -> redemptions If you want a stricter, contract-by-contract risk memo, the missing piece is on-chain verification of the deployed addresses and any proxy/admin slots; that is Not verifiable as of 2026-08-28 in this run.

Liquity V2 is an upcoming / successor version of the Liquity protocol; most team information today derives from the original Liquity organization rather than a separately established V2 entity. Liquity V2-specific on-chain or corporate facts are Not verifiable as of 2026-08-28. ## Founders & Key Team

• Founder / CEO: Liquity was founded by Robert Lauko, a former researcher at the DFINITY Foundation with a law background from the University of Zurich and prior focus on decentralized systems and digital assets.
• CTO / Co-founder: Aleksandar Matanovic is commonly referenced in technical leadership roles; Liquity’s early materials emphasize an engineering-heavy team drawn from Swiss / European tech circles.
• Team operates under Liquity AG, a Swiss corporation domiciled in Zurich, Switzerland, indicating a real registered legal entity and office presence.
• The project emphasizes being “fully decentralized and immutable,” but the organization around it is a conventional company rather than a pure anonymous DAO. ## Public vs. Anonymous; Credibility
• Founders are public, not anon: Lauko and other team members are named across interviews, conference talks, and LinkedIn/GitHub footprints; that materially reduces typical “anon DeFi” risk.
• Liquity has been live since 2021 as a major Ethereum-based collateralized debt protocol (LUSD), with multi-year operational history and significant TVL during major market cycles.
• As of today, Liquity/Liquity V2 show no widely reported protocol-level hacks or catastrophic smart contract exploits in major industry coverage. ## Prior Projects & Track Record
• Lauko’s prior work at DFINITY and academic/legal research background are documented and pre-date Liquity, providing an institutional pedigree rather than a short-lived DeFi-only identity.
• There is no evidence of participation in failed/hacked high-profile DeFi projects; publicly traceable track record is largely Liquity-centric plus DFINITY research. ## Jurisdiction, Office, and Business Reality
• Liquity AG is registered in Switzerland (an onshore jurisdiction with established fintech and crypto regulatory engagement), which supports the view of a real business with a physical presence, not just a web-front.
• Liquity’s funding and early backers include recognizable crypto VCs (e.g., Polychain, Dragonfly, etc.), per historic announcements—these are unverified marketing claims for Liquity V2 unless corroborated by independent capital/registry filings. ### Liquity V2-specific reality check
• Separate incorporation, team changes, or new entities specifically branded Liquity V2 are Not verifiable as of 2026-08-28. Any assumption that Liquity V2 is run by a different or anonymous team would be speculative.

Liquity V2 has a generally strong *protocol reputation* in DeFi: its website and Liquity’s own launch post emphasize an A- Bluechip rating, a five-week audit contest with 800+ researchers, multiple re-audits, and a live mainnet launch. Independent commentary is more mixed: Hindenrank rates Liquity V2 B- and specifically cites a confirmed Stability Pool bug that required redeployment and says the protocol’s design can create herd-like redemption risks if borrowers cluster at similar interest rates. On *audits and security*, secondary sources report substantial review coverage, including multiple audit firms; DeFi Sentinel says Liquity has 9 audits on record and names firms such as Trail of Bits, Coinspect, and ChainSecurity. A GitHub repo exists for the Liquity v2 monorepo, which supports that the codebase is publicly maintained, but that alone does not prove security quality. On *sentiment*, the tone is polarized: positive sources describe Liquity as a pioneering, immutable borrowing protocol with no major hack history, while critical sources focus on the V2 redeployment event and the risk of clustered redemptions. On *fraud/rug/insolvency allegations*, I found no credible evidence of a fraud, rug pull, insolvency, or fund-loss allegation in the provided sources. The strongest negative item is the reported bug/redeployment issue, but the sources describing it say it was non-exploitable and did not result in user fund losses. On *legal/regulatory/sanctions*, I found no substantive allegations, enforcement actions, or sanctions references in the provided results. Not verifiable as of 2026-08-28. *Unresolved concerns* are mainly technical and reputational: the novelty of the V2 interest-rate mechanism, possible rate-herding/forced-redemption cascades, and the fact that some reputation scores rely on aggregators with different methodologies.

Liquity V2 is a *yet-unlaunched / not publicly specified* follow-up to Liquity Protocol; as of 2026‑08‑28, there is no independently verifiable, detailed economic model for a deployed “Liquity V2” on Ethereum. Deployment / basic facts

• Searches for “Liquity V2”, “Liquity v2 Ethereum”, “Liquity v2 docs” and “Liquity v2 contract” return references to the existing Liquity Protocol (LUSD, V1), upcoming discussion of “future versions”, but no confirmed V2 contracts, docs, or audits on Ethereum.
• No separate “Liquity V2” listing appears on major analytics platforms (DeFiLlama, Token Terminal) beyond the known Liquity/LUSD protocol.
• No Etherscan‑verified contracts clearly labeled “Liquity V2” with associated docs or ecosystem recognition are visible. Given that, all the requested economic‑model elements below are Not verifiable as of 2026‑08‑28:
• Strategy / design (how Liquity V2 generates yield, leverage, or market exposure): Not verifiable as of 2026‑08‑28.
• Assets in/out; collateral composition (accepted collateral types, stablecoins, LSDs, or restaked assets): Not verifiable as of 2026‑08‑28.
• Yield sources; organic vs subsidized (fees, funding rates, external staking, incentives): Not verifiable as of 2026‑08‑28.
• Market‑neutral vs directional exposure; leverage/looping/restaking: Not verifiable as of 2026‑08‑28.
• Lock‑ups, withdrawal mechanics, gates, limits (queues, cooldowns, liquidity constraints): Not verifiable as of 2026‑08‑28.
• Fee structure & protocol revenue (who pays, who receives, how revenue is split): Not verifiable as of 2026‑08‑28.
• TVL (total/by product/by chain) and trend, APY history/volatility/sustainability: Not verifiable as of 2026‑08‑28. The only reliable economic‑model information available relates to Liquity (current LUSD protocol, often referred to as V1), which is a zero‑interest borrowing protocol against ETH with stability pool rewards and liquidation fees. Any attempt to extrapolate that design to a hypothetical “V2” would be speculative and not suitable for institutional risk analysis. For an institutional process, Liquity V2 should be treated as pre‑launch / undefined until:
• Audited contracts are deployed and verified on Ethereum explorers.
• Independent analytics (e.g., DeFiLlama) list Liquity V2 separately with contract mappings.
• Formal docs describing the economic model are published and corroborated by third‑party analysis.

Liquity V2’s *reserve/treasury* is not publicly verifiable as a distinct treasury account structure from the provided sources; the protocol materials describe a borrowing system with collateral branches and Stability Pools, but do not document a separate treasury size, custody model, or reserve policy in the retrieved results. The only on-chain-adjacent balance proxy visible in the sources is protocol TVL/depth, which is reported at roughly $72M on Ethereum by DefiLlama/Bathymark, but that is not the same thing as a treasury and does not establish controllable reserve assets. What *is* verifiable from the sources is that Liquity V2 is a multi-collateral Ethereum protocol supporting ETH, wstETH, and rETH, with separate collateral branches and Stability Pools per branch. The documentation does not identify treasury or reserve addresses, nor does it state any custody arrangement, on-chain reserve composition, or governance-controlled reserve vaults in the retrieved material. Because Dune MCP is unavailable in this run, on-chain balances via Dune are not verifiable as of 2026-08-28. Likewise, reserve control, formal reserve policy, and attestations are Not verifiable as of 2026-08-28 from the available sources. If you need a risk memo, the defensible statement is: Liquity V2 appears to be primarily a *non-custodial CDP/stability-pool system* rather than a protocol with a clearly disclosed treasury/reserve wallet structure, and the retrieved sources do not provide evidence of a segregated treasury balance or attestations.

Under a Bitcoin crash below $10,000, Liquity V2’s Ethereum borrow markets would face sharply higher liquidation and shutdown risk, but the exact protocol-level impact is not verifiable as of 2026-08-28 because on-chain exposure by collateral branch and live collateral ratios are unavailable here. Liquity V2’s documented design says each borrow market has a Critical Threshold (CT) that restricts new debt creation, and a Shutdown Threshold (ST) that shuts the market and leaves only trove-closing and redemption pathways active. For this stress case, the relevant mechanism is branch-level containment: Liquity V2 can shut down a specific collateral market if collateral value falls enough, and the docs explicitly say extreme collateral drops can create bad debt and, in the worst case, a partial inability to redeem BOLD one-for-one against collateral. The protocol also notes there is no manual pause/freeze/shutdown function, so the response is automated rather than discretionary. Liquity V2 supports borrowing against multiple collateral types, including staked ETH variants such as wstETH and rETH, which means a Bitcoin crash is not the direct collateral shock; the real risk is a broader crypto drawdown that also hits ETH and liquid staking assets. The repo also notes downward price manipulation risk is contained to the affected branch, reinforcing that losses are intended to be branch-specific rather than automatically protocol-wide. Operationally, the key question for an institutional risk review is whether the Ethereum branches remain above CT/ST under a correlated market shock. That cannot be confirmed from the provided sources, so the current exposure, liquidation buffer, and branch TVL split are Not verifiable as of 2026-08-28.

Under a 20% depeg of the largest collateral, Liquity V2’s Ethereum branch risk depends on which collateral is largest: ETH, wstETH, or rETH. Liquity V2 uses separate collateral branches with independent safety and shutdown thresholds, so the stress impact is branch-specific rather than protocol-wide. For the ETH branch, the documented liquidation floor is materially tighter: ETH Troves can be liquidated at a maximum LTV of 90.91% (minimum collateral ratio 110%), and the branch enters Safety Mode below 150% TCR and shuts down below 110% TCR. If ETH were the largest collateral and its oracle-marked price fell 20%, the branch would likely move deeper into critical/shutdown territory if it was already running near these thresholds; however, the exact post-shock TCR cannot be computed from the provided sources alone because current on-chain branch balances and debt are Not verifiable as of 2026-08-28. For the wstETH/rETH branches, Liquity’s docs show a somewhat different risk envelope: these branches have a 160% CCR and 120% shutdown threshold, and a documented liquidation loss profile of up to 20% of debt (16.67% of collateral) in redistribution cases. A 20% collateral depeg is therefore closer to the protocol’s documented stress boundary for these branches than for ETH, but whether it actually triggers shutdown depends on the branch’s live TCR, which is Not verifiable as of 2026-08-28. The key risk mechanism is that if a branch’s TCR drops below its shutdown threshold, Liquity V2 can freeze new borrowing and rely on redemptions to burn BOLD and clear debt; if the price oracle itself fails, shutdown can also occur. I cannot verify the largest-collateral share on Ethereum, nor the resulting loss of TVL/exposure, because on-chain data access is unavailable in this run and must be treated as Not verifiable as of 2026-08-28.

For Liquity V2 on Ethereum, a “top counterparty insolvent” stress is best mapped to the protocol’s liquidation / undercollateralization path, because Liquity V2 is not a bilateral counterparty network and does not disclose a designated “top counterparty” exposure. The protocol’s documented failure mode is that severe collateral loss or oracle failure can push a market below its safety thresholds, leading to shutdown and possible bad debt; in that case, some BOLD may become unredeemable against sufficient collateral. Expected loss path: a borrower or collateral branch becomes undercollateralized, first triggering borrowing throttles at the Critical Threshold and then market shutdown at the Shutdown Threshold; if collateral is still insufficient, remaining debt becomes bad debt and is not fully covered by collateral. Who absorbs the loss:

• Stability Pool depositors absorb losses first when liquidations can be offset by SP.BOLD; their BOLD is used to cancel borrower debt and they receive seized collateral.
• If the Stability Pool is insufficient, active Troves absorb the remaining loss through redistribution of debt and seized collateral (minus gas compensation).
• If the market is shut down with residual undercollateralization, the system / BOLD holders bear the residual loss through impaired redemption value, i.e. some BOLD may not be redeemable 1:1 against collateral. Compensation: liquidators/offset participants receive collateral and liquidation rewards via the Stability Pool mechanism; in redistribution cases, active Troves are not “compensated” for absorbing debt, but the protocol’s liquidation logic applies collateral and gas compensation rules to limit the shortfall passed onward. Impact path through smart contracts: adverse price/oracle inputs update collateral ratios; if ICR falls below MCR, liquidation can occur; if SP has enough BOLD, debt is offset and collateral is distributed to SP depositors; if not, the remainder is redistributed to active Troves; if TCR falls below shutdown thresholds, borrowing is disabled and redemptions are triggered, with remaining bad debt potentially persisting after shutdown. Not verifiable as of 2026-08-28: the protocol-level exposure to a specific “top counterparty” on Ethereum, and any chain-wide concentration metrics.

For Liquity V2, a DAO/owner fraud scenario is not verifiable as of 2026-08-28 from the available sources. The documentation describes Liquity V2 as having no manual pause, freeze, or shutdown functions, and says shutdown is only automatic under extreme risk conditions, which is inconsistent with a centrally controlled owner-emergency model. The technical docs also list a governance contract, but the provided materials do not establish owner-controlled minting, treasury-drain powers, or any confirmed fraudulent action by the DAO or owners. What *is* verifiable is that Liquity V2’s own risk disclosure explicitly warns that severe collateral failure or oracle failure can cause market shutdown, bad debt, and possible loss of redeemability—i.e., protocol risk rather than governance fraud. The audit-related materials provided focus on code and governance review, but they do not evidence fraud or malicious owner behavior. So the correct stress-scenario assessment is: no confirmed DAO/owner fraud vector is evidenced in the supplied sources; only protocol-design and market-risk failure modes are documented.

Liquity V2’s primary yield source for BOLD Stability Pool depositors is borrower interest paid in BOLD, with the protocol directing roughly 75% of that interest revenue to Earners; liquidation gains are an additional but secondary source of yield. In a stress scenario where that primary source is negative over the last 30 days, the result is not a negative payment stream from the protocol itself but a loss of expected yield from borrower interest, which can materially reduce or eliminate total SP returns over that period. For Ethereum specifically, the protocol documents that Liquity V2 can restrict borrowing, trigger shutdown of a collateral market, and force redemptions if collateralization deteriorates or if an oracle fails; these protections are designed to contain extreme stress, but they also imply that borrower-interest yield may compress sharply in adverse conditions. The available sources do not provide a 30-day on-chain measurement for Ethereum SP yield, so the claim that the primary yield source was negative over the last 30 days is Not verifiable as of 2026-08-28. In institutional risk terms, the relevant takeaway is: if borrower-interest inflows turn negative on a 30-day basis, Liquity V2’s SP economics become dependent on liquidation gains and any remaining positive interest income, while market shutdown/redemption mechanics may further impair yield continuity.

Liquity V2’s governance is real but narrowly scoped: it is designed to allocate the protocol’s incentive portion to external initiatives, not to upgrade the core protocol or broadly control user funds. The official docs state governance is “solely tasked with distributing Protocol Liquidity Incentives” and that the smart contracts are immutable and not upgradeable. The governance repo says LQTY holders stake and vote in weekly epochs to direct the 25% incentive portion to permissionless “Initiatives,” with rewards distributed pro rata to qualifying initiatives. For control surface, the evidence points to: frontend/docs and governance code maintained by the Liquity org, core contracts immutable, and no documented admin key over the core protocol in the materials reviewed. The governance contract address is published in official docs, but a definitive signer list, threshold, or timelock for a controlling multisig is Not verifiable as of 2026-08-28 from the available sources. Likewise, a Dune-based concentration check of voting power/top holders is Not verifiable as of 2026-08-28 because on-chain query access was unavailable in this run. Governance mechanics are described as permissionless initiative registration, time-weighted voting power from staked LQTY, weekly epochs, and veto ability in the final day of each epoch. That makes the DAO economically meaningful, but structurally limited: it governs incentive routing rather than protocol custody or upgrade authority. I could not verify a company-controlled legal entity, jurisdiction, registration number, directors, or ToS with sufficient confidence from the gathered sources; those items are Not verifiable as of 2026-08-28. If you want, I can next produce a tighter control map from the repo/docs only, or a separate legal-entity check once tool access is available.

Liquity V2 appears to be operated by Liquity AG in Zurich, Switzerland, based on the site footer, but that is a website attribution rather than a full legal-entity disclosure for the protocol itself. The protocol documentation describes Liquity V2 as a decentralized borrowing protocol and states that BOLD “can never be frozen,” which is a design claim rather than a legal exemption from regulation. On restrictions and compliance, the strongest directly relevant public terms found were on a separate Liquity-related site stating users must not be residents/citizens/agents of comprehensively sanctioned jurisdictions, must not be sanctioned persons, and must comply with AML, counter-terrorism financing, and sanctions laws; however, because this is not clearly the canonical Liquity V2 legal page, it should be treated as unverified marketing claim until linked to the protocol’s own entity and terms. The same source also states Connecticut law governs those terms. For KYC/AML, I found no protocol-level requirement that Liquity V2 users undergo KYC, and no public evidence of on-chain identity gating in the materials reviewed; Not verifiable as of 2026-08-30. The documentation instead frames Liquity V2 as permissionless/decentralized. For classification, Liquity V2 is best described here as a decentralized borrowing/stablecoin protocol rather than a regulated custodial intermediary, but that does not eliminate potential legal exposure for front-end operators, affiliated entities, or users under local AML/sanctions regimes. The BUSL licensing announcement suggests the software is not simply public-domain code, which matters for intellectual-property structure, but it is not itself a regulatory classification. I found no confirmed court cases, sanctions actions, or regulator warnings specific to Liquity V2 in the materials reviewed; Not verifiable as of 2026-08-30. Data-protection details were also not clearly disclosed in the protocol materials reviewed; Not verifiable as of 2026-08-30. Legal structure vs actual risk: the public materials support a decentralized protocol narrative, but the presence of an identifiable Swiss entity, separate terms with sanctions language, and a non-protocol-specific legal framework mean the practical legal risk is likely concentrated in affiliated operators, interfaces, and jurisdictional access, not only in the smart contracts themselves.

Yes. The stablecoin used by Liquity V2 is BOLD, and public market data shows it has traded above and below its $1 peg, so a depeg event did occur. However, based on the available web results, the *number of separate depeg episodes* is not verifiable as of 2026-08-28 because the results only provide isolated price snapshots rather than a complete price history or intraday time series. The latest clearly visible below-peg data in the results is an all-time low of $0.9649 on 2025-11-27, which is a depeg of about 3.51% below $1. Earlier in the Liquity V2 rollout, Liquity warned users to exit the Stability Pool amid an investigation, but the retrieved sources do not prove that this warning coincided with a BOLD price depeg.

Liquity V2’s top risks on Ethereum are: oracle failure/staleness, which can misprice collateral and trigger unfavorable or delayed liquidations/redemptions or branch shutdowns; collateral drawdown / undercollateralization risk, where a severe price drop can create bad debt and, in the worst case, a bank-run dynamic on BOLD redemptions; redemption concentration risk, because borrowers who choose similar interest rates can be redeemed in clusters; smart contract / protocol-complexity risk, since V2 adds multi-collateral branches, self-set rates, and Stability Pool mechanics that expand attack surface; and liquidation risk for leveraged borrowers if collateral prices fall quickly. Liquity’s own docs also state there is no manual pause/freeze/shutdown, only automatic branch shutdown for extreme collateral or oracle events, and a confirmed redeployment incident in external analysis suggests implementation risk is non-trivial. The most material risks are protocol-level, not chain-level, and the protocol docs say Liquity V2 is native to Mainnet with no cross-chain risk.

Liquity V2’s top strengths are: immutable, on-chain design with no manual pause/freeze/shutdown and no governance overhead; user-set interest rates that let borrowers control borrowing costs and adapt to market conditions; multi-collateral support for ETH and liquid staking tokens (wstETH and rETH), which expands use cases while staying within crypto-native collateral; sustainable real yield and revenue passthrough, because protocol revenues are directed to Stability Pool depositors and liquidity providers rather than a treasury; and strong peg/redemption mechanics for BOLD, including the ability for stablecoin holders to redeem for protocol collateral, which supports confidence in the $1 peg.