External keeper/relayer not redundant
Liquity V1 + V2 (LUSD / BOLD)'s assessment for RD-F-062 — scored green on the v1.7.0 rubric. The evidence below is the curator's reasoning for this score.
Evidence summary #
Liquidations in Liquity v1 and v2 are permissionless -- any Ethereum address can call liquidate() when a trove falls below minimum collateral ratio. No single keeper or relayer dependency. No Gelato, Chainlink Automation, or custom keeper in core liquidation path. Stability Pool is primary liquidation venue (automated contract-to-contract). Redistribution is secondary. Both are fully on-chain with no external keeper.
Sources #
- GitHubLiquity Bold TroveManager -- permissionless liquidationliquity/bold TroveManager.sol -- liquidate() and urgentRedemption() are public functions callable by any addressretrieved 2026-05-16
- Liquity v2 FAQ -- liquidation mechanismLiquity v2 general FAQ -- permissionless liquidations confirmedretrieved 2026-05-16
Methodology #
Determine whether the protocol depends on a single keeper or relayer (Gelato, Chainlink Automation, custom) with no redundancy or failover.
See the full factor methodology and distribution across all protocols →