DeFiPunk'd

Lido

Liquid Staking

TVL $17.6B
Type Liquid Staking
Chains Ethereum, Solana, Moonbeam, Moonriver, Terra
View on DeFiLlama ↗
Control — tentative orange Ability to exit — tentative orange Autonomy — tentative orange Open Access — tentative green Verifiability — tentative green Control Exit Autonomy Open Access Verifiable
Control criteria
Upgradeability Upgradeable Bug bounty immunefi.com Governance forum research.lido.fi Docs docs.lido.fi
About

Lido is a liquid staking protocol on Ethereum where users deposit ETH and receive stETH, a rebasing ERC-20 token representing their staked position plus accrued rewards. Deposited ETH is pooled and delegated to a DAO-curated set of professional node operators via the StakingRouter, with validators never having direct custody of user funds. stETH holders can redeem ETH natively through the WithdrawalQueueERC721 or trade on secondary markets. Governance is conducted by LDO token holders via Aragon on-chain voting, with a Dual Governance mechanism allowing stETH holders to veto or delay DAO proposals through an escrow-based signaling system.

Risk analysis

One card per dimension, sorted by severity. Only Verifiability and Autonomy carry automated signals in Phase 0. See methodology for scope.

Audit a dimension yourself · DEFI@home Contribute an LLM-run assessment — any model, any dimension. Three agreeing runs merge automatically into the public record.

DEFI@home is a distributed audit network modeled on SETI@home: instead of CPU cycles, it crowdsources LLM reasoning. Paste a slice prompt into Claude, ChatGPT, Gemini, or any browsing-capable model, and submit the JSON output as a pull request. The quorum bot merges it once ≥3 independent runs (from different models) reach the same grade — no single model, and no single contributor, can move the needle alone. How it works →

  • Address discovery 120 addresses on file · 1 run Submit run ↗
  • Verifiability ✓ 4/4 models agree AI-only weak green — total support weight 0.32 below confidence floor (1.5) Submit run ↗
  • Control ✓ 4/4 models agree AI-only weak orange — total support weight 0.43 below confidence floor (1.5) Submit run ↗
  • Ability to exit ✓ 4/4 models agree AI-only weak orange — only 1/4 sources have a public chat share link; total support weight 0.32 below confidence floor (1.5) Submit run ↗
  • Autonomy ✓ 4/4 models agree AI-only weak orange — total support weight 0.32 below confidence floor (1.5) Submit run ↗
  • Open Access ✓ 4/4 models agree AI-only weak green — only 0/4 sources have a public chat share link; total support weight 0.32 below confidence floor (1.5) Submit run ↗
  • Audit all 5 dimensions · one prompt Submit run ↗
  1. Verifiability tentative 4/4 models agree AI-only 3/4 with chat share link
    Bytecode verified on Etherscan (proxy + implementation), public source repo, and exhaustive recent audits from multiple top-tier firms through Dec 2025
    Verdict

    Choosing green because: (1) proxy and implementation contracts are source-verified on Etherscan — the 'Similar Match' on the stETH Aragon AppProxyUpgradeable proxy is explicitly permitted under V1 rules, and all implementation contracts (stETH impl, WithdrawalQueueERC721 impl, wstETH) are independently verified; (2) the public repo lidofinance/core exists and its contract source corresponds to explorer-visible source; (3) the audit portfolio is exceptionally broad and recent — Certora, MixBytes, Consensys Diligence, and Composable Security all completed V3 or ongoing-system audits in Nov-Dec 2025, within the 6-month freshness window. The orange steelman (6-month boundary for V2.1) is weaker because there have been multiple targeted re-audits and deployment validations through mid-2025 for the live contracts, and the green conditions are all satisfied.

    Steelman argument
    Steelman argument The 'Similar Match' on a well-known Aragon proxy pattern is explicitly carved out as not a verification gap per V1 rules; all implementation contracts have verified source code on Etherscan; the audit portfolio is massive (70+ reports) and includes recognized top-tier firms with reviews dated as recently as December 2025, well within the 6-month window; the public source repo (lidofinance/core) content visibly corresponds to the deployed source.
    Evidence (6)
    V1
    stETH proxy (0xae7ab96520DE3A18E5e111B5EaAb095312D7fE84) is verified on Etherscan using the EIP-897 DelegateProxy (Aragon AppProxyUpgradeable) pattern — a 'Similar Match' on a well-known proxy pattern per V1 rules, which does not constitute a verification gap. The current implementation is recorded as 0x6ca84080...A8bB6a600, with a previously recorded implementation at 0x17144556fd3424edc8fc8a4c940b2d04936d17eb which is independently source-verified on Etherscan. The WithdrawalQueueERC721 proxy (0x889edC2eDab5f40e902b864aD4d7AdE8E412F9B1) is an OssifiableProxy (EIP-1967), verified; its current implementation 0xe42c659dc09109566720ea8b2de186c2be7d94d9 (WithdrawalQueueERC721) is also independently source-verified. wstETH (0x7f39C581F595B53c5cb19bD0b3f8dA6c935E2Ca0) is a non-proxy contract verified on Etherscan.
    V2
    The public source repository github.com/lidofinance/core contains Lido.sol (0.4.24) and WithdrawalQueueERC721.sol (0.8.9) whose content visibly corresponds to the source code visible on Etherscan for the deployed contracts. A direct bytecode diff was not performed; this limitation is recorded in unknowns.
    V3
    The lidofinance/audits repo (fetched 2026-04-24) lists 70+ audit reports. Most recent reports covering core Lido V2/V3 contracts: Certora Lido V3 Audit (12-2025), Certora Lido V3 Formal Verification (12-2025), MixBytes Lido V3 Security Audit (12-2025), Consensys Diligence Lido V3 Security Audit (11-2025), Composable Security Oracle V6/V6.0.2 (09-2025), Ackee Blockchain Community Staking Module v2 (09-2025), Statemind Dual Governance Escrow Fix (08-2025), Certora Dual Governance v1.0.1 Hotfix Review (08-2025). These reports are all within 6 months of the analysis date (2026-04-24), satisfying the freshness requirement. The stETH implementation v2 was audited as part of the Lido V2 campaign (04-23 Certora, Hexens, Statemind, MixBytes) and the V2.1 release (10-2024 MixBytes, Ackee).
    V4
    Auditors represented across the audit portfolio include: Certora (formal verification), MixBytes, Ackee Blockchain, ChainSecurity, Statemind, Sigma Prime, OpenZeppelin, Hexens, Oxorio, Quantstamp, Runtime Verification, Composable Security, Nethermind, Code4rena, Pessimistic. All of Certora, MixBytes, Ackee Blockchain, ChainSecurity, Statemind, Sigma Prime, OpenZeppelin, and Quantstamp are recognized firms on the prompt's list. The most recent V3 core audit cycle (Nov-Dec 2025) specifically included Certora, MixBytes, Consensys Diligence, and Composable Security.
    V5
    The most recent audits in the repo (12-2025) are titled 'Lido V3 Audit Report' and 'Lido V3 Formal Verification Report', indicating they cover a V3 upgrade that is currently in RC (pre-release) per the GitHub releases page. The currently deployed mainnet contracts remain at V2/V2.1. The V2.1 release (tag c19480a) was audited in 10-2024 by MixBytes and Ackee Blockchain, approximately 6 months prior to the analysis date. This is on the boundary of the 6-month threshold; however, Statemind's GateSeal Deployment Validation (03-2025) and Statemind's Dual Governance Deployment & Voting Script Review (06-2025) and Escrow Fix Review (08-2025) confirm ongoing post-deployment monitoring. No material unreviewed post-audit drift was identified for V2.1 deployed contracts.
    V6
    For every proxy assessed: stETH proxy (EIP-897 / Aragon AppProxyUpgradeable) — current impl 0x6ca84080...A8bB6a600 recorded as verified with 'Similar Match' (well-known proxy pattern per V1 rules); prior impl 0x17144556fd independently verified. WithdrawalQueueERC721 proxy (OssifiableProxy/EIP-1967) — impl 0xe42c659dc independently verified. No case of a verified proxy with unverified implementation was found.
    Why is this consensus tentative?
    • total support weight 0.32 below confidence floor (1.5)

    A fresh independent run can strengthen (or overturn) the verdict.

    Run your own prompt Submit run ↗
    Sources claude-sonnet-4-6 url ↗ gemini-3-pro no url gpt-5.5-thinking url ↗ grok-2 url ↗ View raw submissions ↗
  2. Control tentative 4/4 models agree AI-only 3/4 with chat share link
    DualGovernance adds 9-day normal path, but a time-limited insider-heavy Emergency Committee can collapse DG back to a 5-day Aragon-only path
    Verdict

    Choosing orange because the DG Emergency Committee (4/7 activation, active until ~July 2026) can collapse DualGovernance, creating an uncontested path of only 5 days (Aragon Voting alone) — below the 7-day green threshold. The normal 9-day path would merit green, and the temporary nature of the Emergency Committee is a meaningful mitigant, but grading on the fast path per the rubric requires acknowledging the sub-7-day route that currently exists. Additionally, the 5% LDO quorum is low by DAO standards. The DG Emergency path is further constrained: it requires 4/7 activation first, then 5/7 execution — a meaningful barrier in practice, but not a hard time-delay in the smart-contract sense.

    Steelman argument
    Steelman argument The DG Emergency Committee (a time-limited 4/7 insider-heavy multisig) can collapse DualGovernance, reducing the effective uncontested fast path to just 5 days of Aragon Voting — below the 7-day threshold — and the 5% LDO quorum is low enough that a concentrated holder could drive harmful votes through once DG protection is removed.
    Evidence (6)
    C1
    Core protocol contracts (stETH, WithdrawalQueue, StakingRouter, etc.) are proxies whose admin/owner is the Aragon Agent (0x3e40D73EB977Dc6a537aF587D48316feE66E9C8c). Since DG activation via Vote #189 (~July 4, 2025), the Agent's RUN_SCRIPT_ROLE and EXECUTE_ROLE from Aragon Voting were revoked and re-routed through the DualGovernance Executor, so only DG-submitted proposals can call Agent.forward. The LidoLocator (0xC1d0b3DE6792Bf6b4b37EccdcC24e45978Cfd2Eb) is the on-chain address book; each proxy points to an OssifiableProxy with the Agent/DAO as admin. wstETH (0x7f39C581F595B53c5cb19bD0b3f8dA6c935E2Ca0) is non-upgradeable. The EmergencyProtectedTimelock (0xCE0425301C85c5Ea2A0873A2dEe44d78E02D2316) is the current final arbiter for proposal execution.
    C2
    Core contracts use the OssifiableProxy (ERC-1967 style) pattern. The proxy admin for protocol proxies is the Aragon Agent (0x3e40D73EB977Dc6a537aF587D48316feE66E9C8c). Upgrades must flow through Aragon Voting → DualGovernance Executor → Aragon Agent → proxy upgrade call. Implementation contracts are immutable; only proxies are upgradeable. wstETH is fully immutable.
    C3
    Normal upgrade execution path (uncontested): (1) Aragon Voting (0x2e59A20f205bB85a89C53f1936454680651E618e): 5 days total (72h main phase + 48h objection phase, confirmed from lido.fi/governance and blog.lido.fi). Vote requires >5% of LDO supply quorum + simple majority. (2) DualGovernance / EmergencyProtectedTimelock (0xCE0425301C85c5Ea2A0873A2dEe44d78E02D2316): minimum 3-day pending delay then 24h schedule-to-execute window before proposal can be called = ~4 days. (3) Aragon Agent (0x3e40D73EB977Dc6a537aF587D48316feE66E9C8c): executes the forwarded call. Total uncontested fast path: ~9 days. DG Emergency path: if the 4/7 Emergency Activation multisig enables Emergency Mode, proposals can then be executed by the 5/7 Emergency Execution multisig, and Emergency Reset can be triggered, which disables DG and hands governance back to a TimelockedGovernance backed by Aragon Voting. After reset, the path is just Aragon Voting (5 days) with no additional DG timelock — below the 7-day green threshold. On-chain delay constants (AFTER_SUBMIT_DELAY = 3 days, AFTER_SCHEDULE_DELAY = 24h) were cited from lido.fi/governance and blog.lido.fi; on-chain read-contract values not directly fetched this run — see unknowns.
    C4
    Multisigs with reachable control: (a) GateSeal Committee (0x8772E3a2D86B9347A2688f9bc1808A6d8917760C, 3/6): can trigger GateSeal pause on WithdrawalQueue, ValidatorExitBus, VaultHub, PredepositGuarantee for limited periods; single-use per GateSeal contract; signers are ajbeal, eboadom, michwill, thedzhon, George, kadmil — all Lido community/ecosystem contributors. (b) Emergency Brakes Ethereum (0x73b047fe6337183A454c5217241D780a932777bD, 3/5): can pause Easy Track pipeline and disable L2 bridge deposits/withdrawals; does not affect core protocol upgrades. (c) DG Emergency Activation multisig (4/7): can activate DG Emergency Mode blocking permissionless execution; signers include Alexandr T (Lido DAO Tech — insider), Kirill M (Lido ValSet — insider), Yuri T (Lido stETH — insider), Dmitry Zaharov (MixBytes), Isaac Patka (SEAL), Josef (Ackee Blockchain), Shelly (Certora) — 3/7 are Lido-affiliated insiders, 4/7 are auditors/security researchers. (d) DG Emergency Execution multisig (5/7, same signers): can execute DG proposals in Emergency Mode and trigger Emergency Reset. (e) Tiebreaker: 'multisig of multisigs' with Ethereum Ecosystem (3/5), Builders (3/5), Node Operators (5/7) subcommittees; requires ≥2 subcommittees — last-resort only after governance paralysis. The DG Emergency Committee is a temporary failsafe for the first year post-deploy (expires ~July 2026).
    C5
    Aragon Voting (0x2e59A20f205bB85a89C53f1936454680651E618e, LDO token 0x5A98FcBEA516Cf06857215779Fd812CA3beF1B32): voting period 5 days (72h main + 48h objection, confirmed from lido.fi/governance and blog.lido.fi); quorum: >5% of total LDO supply must vote yes; support: simple majority of votes cast. These values (voteTime, minAcceptQuorumPct, supportRequiredPct) were sourced from lido.fi/governance and blog.lido.fi rather than a direct on-chain Read Contract call this run — see unknowns. DG adds a minimum 3-day pending + 24h schedule delay on top of the Aragon vote for all protocol upgrade proposals (except Easy Track operations).
    C6
    Emergency powers: (1) GateSeal Committee (3/6) can pause WithdrawalQueue and other contracts for up to 6 days per GateSeal; this is a fast, single-use emergency pause with no timelock. (2) Emergency Brakes multisig (3/5) can pause L2 bridges and Easy Track instantly with no delay. (3) DG Emergency Activation Committee (4/7) can activate DG Emergency Mode instantly, blocking permissionless proposal execution — time-limited to 1 year post-deploy (~July 2026). (4) DG Emergency Execution Committee (5/7) can then execute or trigger Emergency Reset. None of these powers allow arbitrary contract upgrades: GateSeal and Emergency Brakes are pause-only; the DG Emergency multisigs affect the governance layer only. After Emergency Reset, governance reverts to Aragon Voting (5-day cycle).
    Why is this consensus tentative?
    • total support weight 0.43 below confidence floor (1.5)

    A fresh independent run can strengthen (or overturn) the verdict.

    Run your own prompt Submit run ↗
    Sources claude-sonnet-4-6 url ↗ gpt-5.5-thinking url ↗ gemini-3-pro no url grok-2 url ↗ View raw submissions ↗
  3. Ability to exit tentative 4/4 models agree AI-only 1/4 with chat share link
    Finalized-claim exits always open; new-request placement pausable up to 11 days by 3/6 GateSeal multisig or indefinitely by DAO governance vote
    Verdict

    Choosing orange because: claims of already-finalized exits are not pause-gated (ruling out red), but two distinct pause vectors remain: (1) the 3/6 GateSeal Committee can unilaterally pause new request placement and finalization for 11 days — above the ≤7-day green threshold — and (2) governance (Lido DAO Aragon vote) can in theory pause indefinitely by assigning PAUSE_ROLE and calling pauseFor(PAUSE_INFINITELY), satisfying the orange condition 'claims-of-finalized are exempt but new-request placement can be paused indefinitely by governance.' Dual Governance and the auto-resume design of PausableUntil are meaningful mitigants but do not bring this to green because the GateSeal itself exceeds the 7-day cap and indefinite DAO governance pause remains theoretically reachable.

    Steelman argument
    Steelman argument Claims of already-finalized withdrawals are categorically not pause-gated per the source code and documentation, so users with finalized positions can always retrieve ETH on-chain; meanwhile, indefinite pause of new request placement requires a full Lido DAO governance vote (120+ hours, now also subject to Dual Governance veto by stETH holders), and the only unilateral emergency actor (3/6 GateSeal Committee) is hard-capped at 11 days with auto-resume.
    Evidence (7)
    E1
    Four request-placement functions exist: requestWithdrawals(uint256[] amounts, address owner), requestWithdrawalsWithPermit(...), requestWithdrawalsWstETH(uint256[] amounts, address owner), requestWithdrawalsWstETHWithPermit(...). Two claim functions exist: claimWithdrawal(uint256 requestId) and claimWithdrawals(uint256[] requestIds, uint256[] hints). The finalize() function is called exclusively by the AccountingOracle via FINALIZE_ROLE, not directly by users.
    E2
    All four requestWithdrawals* functions and finalize() call _checkResumed(), reverting when the contract is paused. By explicit contract documentation and code comment, claimWithdrawal and claimWithdrawals do NOT call _checkResumed() and remain available even while the contract is paused. The finalize() function is additionally gated by onlyRole(FINALIZE_ROLE), so oracle-driven finalization also halts under pause, meaning new requests cannot be finalized during a pause but already-finalized requests remain claimable.
    E3
    PAUSE_ROLE = keccak256('PAUSE_ROLE'). The currently active PAUSE_ROLE holder with operational use is the GateSeal contract at 0x8A854C4E750CDf24f138f34A9061b2f556066912 (expiry 12 Sep 2026), which can only be triggered by the 3/6 GateSeal Committee multisig at 0x8772E3a2D86B9347A2688f9bc1808A6d8917760C. The GateSeal is configured for 11 days seal duration. The pauseFor(_duration) function accepts PAUSE_INFINITELY (uint256 max) as a duration, so any PAUSE_ROLE holder can pause indefinitely; the GateSeal is the only verified time-capped PAUSE_ROLE path. Whether the Lido DAO Aragon Agent also holds PAUSE_ROLE directly (enabling a governance vote to call pauseFor(PAUSE_INFINITELY)) could not be confirmed on-chain without reading the live role membership from the contract; this is flagged in unknowns.
    E4
    Emergency path: GateSeal contract (3/6 multisig, one-time use per GateSeal instance, hard-capped at 11 days by its immutable seal_duration, auto-resumes, expires 12 Sep 2026). If GateSeal is triggered and the DAO cannot pass a fix within 11 days, the queue auto-resumes. Governance path: Lido DAO Aragon vote (now 120-hour duration per Vote #184, two-phase) can pass any action including extending a pause via a new PAUSE_ROLE grant and calling pauseFor(PAUSE_INFINITELY), subject to the Dual Governance veto mechanism (stETH holders holding ≥1% of total staked ETH in escrow can delay execution for at least 5 days, with escalation to rage-quit). These are two distinct actor classes with very different timescales and veto surfaces.
    E5
    Withdrawals follow a FIFO queue finalized in daily batches by AccountingOracle. Typical finalization time is 1–4 days in normal conditions (Lido documentation). No hard daily withdrawal cap is encoded in the WithdrawalQueue contract itself; throughput is limited by available ETH in the Lido buffer plus validator exit speed. Under bunker mode (severe slashing), finalization rate is further restricted by OracleReportSanityChecker. No documented hard maximum queue duration was found; under extreme demand the wait could extend to weeks. The queue itself can be paused (blocking new request placement and new finalization) but individual request IDs already in a finalized state remain claimable at any time.
    E6
    No permissionless escape-hatch or forced-exit mechanism exists in the WithdrawalQueue contract. Users who cannot wait for the queue can exit via secondary markets (DEX swap of stETH/wstETH for ETH) but this is an off-chain/market-dependent path. Dual Governance provides stETH holders a rage-quit path to reclaim staked ETH by exiting validators en masse, but that is a governance escalation mechanism, not an individual user escape hatch.
    E7
    The WithdrawalQueue contract (0x889edC2eDab5f40e902b864aD4d7AdE8E412F9B1) is a verified proxy on Etherscan. Both requestWithdrawals and claimWithdrawals are callable directly via Etherscan's Write Proxy tab or any Ethereum wallet with ABI interaction. No dependency on lido.fi frontend exists for on-chain exit.
    Why is this consensus tentative?
    • only 1/4 sources have a public chat share link
    • total support weight 0.32 below confidence floor (1.5)

    A fresh independent run can strengthen (or overturn) the verdict.

    Run your own prompt Submit run ↗
    Sources claude-sonnet-4-6 no url gemini-3.1-pro no url gpt-5.4-thinking no url grok-2 url ↗ View raw submissions ↗
  4. Autonomy tentative 4/4 models agree AI-only 3/4 with chat share link
    ~0% principal loss risk under oracle failure; oracle committee (5-of-9) with onchain sanity limits mitigates most attack vectors, but full ZK second opinion not yet live and canonical-bridge wstETH on L2s introduces bounded yield/access risk (~2-3% TVL) | impacted TVS under worst unmitigated scenario: ~2-5%
    Verdict

    Choosing orange because the primary unmitigated risk is oracle committee failure (liveness or limited collusion), which cannot cause principal theft under current sanity limits but can materially degrade yield accrual and delay withdrawals over multiple reporting cycles — the ZK second opinion oracle that would close this gap is not yet activated on mainnet (confirmed April 2026 governance forum post). Additionally, wstETH on BNB Chain via Wormhole+Axelar represents a non-canonical bridge trust assumption for a small fraction of TVL. These factors fit Stage 1: external dependency failures are bounded and recoverable (no principal loss) but the full mitigation stack is incomplete. The green steel-man is close — Dual Governance is live, sanity checks are strict, and oracle resilience was demonstrated in practice — but the absent ZK second opinion means the protocol has not yet achieved the 'all critical dependencies have documented active fallbacks' bar for green.

    Steelman argument
    Steelman argument Lido's oracle committee (5-of-9 quorum) is the primary off-chain dependency, and while the OracleReportSanityChecker strictly bounds per-report harm to ~0.19% TVL per day, a sustained oracle failure or compromise could degrade yield and delay withdrawals over multiple reporting cycles without triggering principal theft; the ZK second opinion oracle that would harden this is not yet wired on mainnet; and wstETH on BNB Chain via Wormhole+Axelar (~small fraction of TVL) introduces a third-party bridge trust assumption that could freeze cross-chain wstETH but not L1 principal.
    Evidence (8)
    A1
    Lido's core contracts on Ethereum mainnet call no external price oracles (no Chainlink, Pyth, or Redstone feeds). The AccountingOracle reads Beacon Chain validator balances as reported by the oracle committee and enforces them through OracleReportSanityChecker (0xf1647c86E6D7959f638DD9CE1d90e2F3C9503129). The only EVM-external call path is the Ethereum Deposit Contract (0x00000000219ab540356cBB839Cbe05303d7705Fa), which is the base-chain substrate. No AMM pool, lending pool, or external feed is called in the happy-path staking/withdrawal flow. The Chainlink CCIP integration introduced in Oct 2024 is for cross-chain staking UX (deposit from L2 and receive wstETH) — it is not called in the core stETH accounting or withdrawal path on L1.
    A2
    The AccountingOracle and ValidatorsExitBusOracle rely on a 9-member off-chain oracle committee with a 5-of-9 quorum (HashConsensus at 0xD624B08C83bAECF0807Dd2c6880C3154a5F0B288 for Accounting and 0x7FaDB6358950c5fAA66Cb5EB8eE5147De3df355a for Exit Bus). Members are known professional entities (including Chorus One, Stakefish, P2P, etc.) selected by DAO vote. A single compromised key (Chorus One, May 2025) caused no user impact because 8 of 9 oracles kept reporting. The OracleReportSanityChecker (LIVE on-chain) enforces hard limits: max ~0.19% TVL per-day negative rebase (post LIP-23), max 10% annual balance increase, and a withdrawal vault balance cross-check. Even a 5-of-9 malicious coalition is limited by these bounds to a <5% per-report loss (further bounded by Dual Governance timelock). The DepositSecurityModule guardian committee (initially ~6 known node operators + Lido dev team) guards against deposit front-running; a single guardian can pause deposits unilaterally. Node operator set for the Curated Module has 36 independent operators with ~1% soft cap each and growing DVT/CSM participation (~5% of stake via Community Staking Module as of early 2026). Validator slashing risk is well-mitigated by diversification.
    A3
    Lido on Solana was sunset in Oct 2023 (frontend ended Feb 2024). Lido on Terra was wound down after the Terra collapse. Lido on Moonbeam and Moonriver are retired. Active cross-chain exposure today: wstETH is bridged to Arbitrum, Optimism, Base, and other L2s via DAO-recognized canonical bridges (OP Stack canonical bridge for Optimism/Base at 0x76943c0d61395d8f2edf9060e1533529cae05de6, Arbitrum canonical gateway). BNB Chain uses a Wormhole+Axelar joint bridge. These bridges carry wstETH representing approximately 2-5% of total Lido TVL (L1 stETH represents ~95%+ of TVL). Canonical OP/Arbitrum bridges inherit Ethereum security; BNB Chain wstETH via Wormhole+Axelar introduces a third-party trust model. Failure of the Wormhole+Axelar bridge could freeze BNB-wstETH but cannot affect L1 principal. DataBus contracts (Gnosis Chain, Base, Optimism, Polygon) are used as a communication layer by oracle daemons but do not hold TVL.
    A4
    Not applicable. Lido is not a restaking or LRT protocol and does not nest collateral from other protocols. stETH represents direct Ethereum validator stake. No collateral chain beyond depth-1 (ETH → Lido validators).
    A6
    Multiple fallback and circuit-breaker mechanisms are LIVE on-chain: (1) OracleReportSanityChecker (0xf1647c86E6D7959f638DD9CE1d90e2F3C9503129) enforces max annual balance increase, one-off CL balance decrease cap (~0.19%/day post LIP-23), and withdrawal vault balance cross-check — LIVE and enforcing. (2) GateSeal contracts (0xA6BC802fAa064414AA62117B4a53D27fFfF741F1 for VEB+TWG; 0x8A854C4E750CDf24f138f34A9061b2f556066912 for Withdrawal Queue; 0x881dAd714679A6FeaA636446A0499101375A365c for VaultHub/PredepositGuarantee) allow emergency one-shot pauses — LIVE. (3) Dual Governance with dynamic timelock (EmergencyProtectedTimelock 0xCE0425301C85c5Ea2A0873A2dEe44d78E02D2316) — LIVE since July 2025, provides minimum 3-day + up to 45-day delay for contested governance actions, including oracle address swaps. (4) LIP-23 second opinion oracle interface exists in OracleReportSanityChecker code and was adopted in V2.1 (2024), but the ZK second opinion oracle is NOT YET wired/activated on mainnet as of April 2026: per the Lido governance forum (April 2026), integration is paused pending 0x02 migration and Ethereum hardfork stabilization. This is state (ii) — DEPLOYED interface, not yet activated. Positive token rebase is also capped per PositiveTokenRebaseLimiter. Bunker Mode activates if excess slashing is detected, limiting withdrawals to prevent first-mover advantage.
    A7
    Lido's core protocol is deployed on Ethereum L1. No sequencer, DA committee, or L2-specific liveness dependency exists for the primary staking, rebase, or withdrawal flow. wstETH liquidity on L2s is subject to OP/Arbitrum sequencer liveness, but this affects only users who hold L2 wstETH — it does not affect L1 principal or yield accrual.
    A8
    Oracle daemons (9 known entities) are permissioned and not truly permissionless. If all 9 oracle operators stop running, stETH rebases stop and the withdrawal queue cannot be finalized (no new exit requests triggered), degrading yield accrual and liquidity. This is a recoverable liveness failure (principal stays intact; governance could add new oracle members via Dual Governance), not a catastrophic principal loss. DepositSecurityModule guardian bots (Deposit Security Committee) must attest each deposit batch; if all guardians stop running, new deposits halt but existing stakers are unaffected. No liquidation-bot-style dependency exists (Lido has no borrowing market).
    A9
    The DAO (via Aragon Voting + Dual Governance) can: add new staking modules to StakingRouter (potentially calling untrusted external contracts), change oracle committee members, change OracleDaemonConfig parameters, and update OracleReportSanityChecker limits. All such actions now route through the EmergencyProtectedTimelock (0xCE0425301C85c5Ea2A0873A2dEe44d78E02D2316) with Dual Governance, giving stETH holders a minimum 3-day observation window and up to 45-day veto delay if >1% stETH is escrowed in dissent. A rage-quit blocking execution until all dissenting stakers exit ETH is triggered at 10% stETH in the veto-signaling escrow. This is a meaningful exit window given that the Ethereum withdrawal queue for Lido at current scale takes days to weeks. The dependency surface is governance-mutable but now protected by a live timelock with a credible user-exit path.
    Why is this consensus tentative?
    • total support weight 0.32 below confidence floor (1.5)

    A fresh independent run can strengthen (or overturn) the verdict.

    Run your own prompt Submit run ↗
    Sources claude-sonnet-4-6 url ↗ GPT-5.5 Thinking url ↗ gemini-3.1-pro no url grok-beta url ↗ View raw submissions ↗
  5. Open Access tentative 4/4 models agree AI-only 0/4 with chat share link
    Core stETH staking and finalized withdrawal claims are contract-accessible without user allowlists or KYC; frontend restrictions found were passive ToS only.
    Verdict

    Choosing green because the evidence supports permissionless contract-level admission for the core user flows and documents independent/direct contract access, while the only verified access restriction is passive ToS language and no A3-active frontend enforcement was observed in the fetched official interface.

    Steelman argument
    Steelman argument The strongest green argument is that the deployed stETH and WithdrawalQueue user-facing functions admit deposits, withdrawal requests, transfers, and finalized claims without allowlists, KYC, per-address sanctions checks, or operator pre-approval, and the only verified frontend restrictions are passive ToS clauses with documented direct-contract alternatives.
    Evidence (12)
    A1
    User-facing stETH entry via submit(address) is external payable and mints to msg.sender without a whitelist/KYC modifier; staking can be globally paused or rate-limited by governance roles, but the inspected entry point does not gate by user identity.
    A1
    Withdrawal request placement functions requestWithdrawals, requestWithdrawalsWstETH, and permit variants are public/external and check the global resumed state and amount constraints, not an address allowlist; pause/resume roles affect global availability rather than per-user admission.
    A1
    Withdrawal claim functions claimWithdrawalsTo, claimWithdrawals, and claimWithdrawal require the caller to own the relevant request and require finalization, but do not require a whitelist, KYC status, or privileged operator approval to claim already-finalized requests.
    A2
    Deposit/mint admission is unconditional at the user submit layer when staking is not globally paused and capacity is available; downstream validator deposits are performed asynchronously by the DepositSecurityModule, which is a liveness/operation dependency rather than an operator approval needed to admit the user's mint.
    A2
    Withdrawal request placement is admitted directly through WithdrawalQueueERC721; finalization is performed as part of the AccountingOracle/Lido accounting process, but claim of finalized requests remains user-callable by the request owner.
    A3
    The official Terms of Use include passive eligibility, restricted-territory, sanctions-list, and VPN/circumvention clauses, including the verbatim clause: "Use of a virtual private network (e.g., a VPN) or other means by ineligible persons to access or use the Interface is prohibited".
    A3
    A static fetch of https://stake.lido.fi/ rendered the staking interface content and links without a visible block banner, KYC wall, wallet-screening rejection, HTTP 451, or named sanctions-screening provider in the fetched page content.
    A3b
    The stake interface exposes an IPFS/version link, but the Terms define the Interface broadly and prohibit ineligible access and VPN/circumvention, so official redistributions are not treated as independent access paths.
    A3b
    Lido's Terms and official interface documentation explicitly state that users can interact without the Interface by using blockchain systems, wallets, validator nodes, block explorers, code repositories, or direct smart-contract interaction; the official staking FAQ also says stETH can be obtained by interacting with the smart contract directly and through other integrations.
    A4
    In the inspected core stETH submit and WithdrawalQueue user paths, no onchain sanctions/blocklist check was identified; the visible restrictions are ToS-level representations rather than contract-level OFAC/blocklist enforcement.
    A5
    Read access is permissionless through public view functions and block explorers; write access for user deposit, withdrawal request placement, transfer, and finalized claim is not identity-gated, although some protocol operations such as pausing, resuming, validator deposits, oracle reports, and finalization are privileged or committee/governance-operated.
    A6
    The ToS eligibility section states verbatim that users represent they are not residents/citizens/entities of Crimea, Cuba, Donetsk, Iran, Luhansk, North Korea, Syria, or other embargoed/sanctioned territories, are not sanctions-listed persons, have not received assets from sanctions-listed blockchain addresses, and do not intend to transact with restricted territories or sanctions-listed persons.
    Why is this consensus tentative?
    • only 0/4 sources have a public chat share link
    • total support weight 0.32 below confidence floor (1.5)

    A fresh independent run can strengthen (or overturn) the verdict.

    Run your own prompt Submit run ↗
    Sources gpt-5.5-thinking no url claude-sonnet-4-6 no url gemini-3.1-pro no url grok-4-preview no url View raw submissions ↗

Stage

Preview of the Phase-3 maturity framework. DeFiPunk'd will adopt DeFiScan v2's stages verbatim; the section is rendered below in its intended shape so the structure is visible today.

Lido has not yet been assessed under the DeFiScan v2 stage framework.
The walkaway test is the central criterion. Once stages land, protocols reach Stage 1 only if users can exit in the presence of malicious operators even when the emergency council disappears.
Scope of assessment
Stages are assessed per-protocol against DeFiScan v2's criteria: governance structure, upgradeability path, timelock durations, emergency-council scope, and the walkaway test. The analysis depends on onchain discovery (roles, owners, timelocks) and deeper review of deployed contracts — neither of which DeFiPunk'd automates at Phase 0.
Stage 0 requirements pending
Governance is largely off-chain, contracts are upgradeable with short or no timelock, and the protocol depends on a multisig or team with full discretion. At Phase 0 DeFiPunk'd does not automatically evaluate these; the assessment lands with crawler-based onchain discovery.
Stage 1 requirements pending
Users can exit or opt out on their own terms even if the team disappears. Upgrades run through a meaningful timelock with an emergency security council clearly scoped. The walkaway test is the headline criterion.
Stage 2 requirements pending
Protocol is fully permissionless and immutable, or upgrades require a supermajority of token holders with a long timelock and no emergency override. This is the terminal stage of the DeFiScan v2 framework.
Learn more about DeFiScan v2 stages →
Stages are an opinionated assessment of maturity, not a rating of security or safety. A protocol can sit at Stage 2 and still carry substantial technical or economic risk; the framework exists to incentivize decentralization, not to rank protocols.

Contract surface

Every contract in scope for this protocol — pooled from DeFiLlama's TVL adapter (mechanical) and DEFI@home discovery submissions (LLM-curated). Verified-source flags come from Etherscan + Sourcify; owner / multisig metadata is read on-chain when available. Reviewer audit context, not a slice score. A lending protocol's adapter set will list third-party collateral tokens alongside its own contracts; attribution is the grader's job.

  • 124addresses
  • 5verified source
  • 4proxies

TVL adapter pinned at 683d369. Sourcecode fetched 2026-05-06. Control fetched 2026-05-07.

Arbitrumgovernance (Arbitrum Governance Bridge Executor)0x1dca…1a29discovery———governance
Arbitrummultisig (Emergency Brakes Arbitrum — 3/5)0xfdcf…de34discovery———multisig
Arbitrumother (L2ERC20TokenGateway proxy — Arbitrum)0x07d4…1b82discovery————
Arbitrumtoken (WstETH ERC20Bridged proxy — Arbitrum)0x5979…0529discovery———token
Basegovernance (Base Governance Bridge Executor)0x0e37…eacfdiscovery———governance
Basemultisig (Emergency Brakes Base — 3/5)0x0f9a…0725discovery———multisig
Baseother (L2ERC20TokenBridge proxy — Base)0xac9d…87abdiscovery————
Basetoken (WstETH ERC20Bridged proxy — Base)0xc1cb…e452discovery———token
ethereumMaticToken0x7d1a…ebb0TVL✓———
ethereumnull0x0000…0000TVL✗———
ethereumAppProxyUpgradeable0xae7a…fe84TVL + disc✓proxy—token
ethereumTransparentUpgradeableProxy0x9ee9…8599TVL✓proxy——
Ethereumadmin (Admin Executor for Dual Governance timelock)0x23e0…7021discovery———timelock
Ethereumfactory (GateSeal Factory)0x6c82…4a24discovery———factory
Ethereumfactory (Staking Vault Factory — deploys stVault instances)0x02ca…175adiscovery———factory
Ethereumgovernance (Aragon Agent proxy — DAO execution agent)0x3e40…9c8cdiscovery———governance
Ethereumgovernance (Aragon Token Manager proxy)0xf73a…3249discovery———governance
Ethereumgovernance (Aragon Voting proxy — on-chain LDO-weighted voting)0x2e59…618ediscovery———governance
Ethereumgovernance (Dual Governance main contract)0xc1db…486ediscovery———governance
Ethereumgovernance (EasyTrack — optimistic governance for routine ops)0xf021…3feadiscovery———governance
Ethereumgovernance (Emergency Governance — fallback governance contract)0x5533…7ccediscovery———governance
Ethereumgovernance (Lido DAO Kernel proxy — Aragon DAO kernel)0xb8ff…88dcdiscovery———governance
Ethereumguardian (CS GateSeal — emergency pause for CSM)0xe168…adb3discovery———guardian
Ethereumguardian (GateSeal for ValidatorExitBus and TriggerableWithdrawalsGateway)0xa6bc…41f1discovery———guardian
Ethereumguardian (GateSeal for VaultHub and PredepositGuarantee)0x881d…365cdiscovery———guardian
Ethereumguardian (GateSeal for WithdrawalQueue)0x8a85…6912discovery———guardian
Ethereummultisig (Bug Bounty Reserve Multisig)0x9eb8…4071discovery———multisig
Ethereummultisig (Community Lifeguards Multisig)0x6fac…dff4discovery———multisig
Ethereummultisig (Community Staking Module Committee)0xc52f…880fdiscovery———multisig
Ethereummultisig (Delegate Oversight Committee)0x1360…8727discovery———multisig
Ethereummultisig (Dual Governance emergency activation committee)0x8b78…5f45discovery———multisig
Ethereummultisig (Dual Governance emergency execution committee)0xc779…18afdiscovery———multisig
Ethereummultisig (Ecosystem BORG Foundation stablecoins committee)0x5589…5ad6discovery———multisig
Ethereummultisig (Emergency Brakes Ethereum — 3/5 — pauses bridges and EasyTrack)0x73b0…77bddiscovery———multisig
Ethereummultisig (Finance Ops — legacy, not in bug bounty scope)0x48f3…9abbdiscovery———multisig
Ethereummultisig (Gas Supply Committee)0x5181…5a53discovery———multisig
Ethereummultisig (GateSeal Committee — 3/6 — triggers GateSeal pause)0x8772…760cdiscovery———multisig
Ethereummultisig (Labs BORG Foundation stablecoins committee)0x95b5…5f3fdiscovery———multisig
Ethereummultisig (LEGO Committee — grants disbursement)0x12a4…9030discovery———multisig
Ethereummultisig (Lido Alliance BORG Foundation Operational)0x606f…d942discovery———multisig
Ethereummultisig (Liquidity Observation Lab — Ethereum)0x87d9…12b5discovery———multisig
Ethereummultisig (Relay Maintenance Committee — MEV relay allowlist)0x98be…c37ddiscovery———multisig
Ethereummultisig (Reseal Committee — can re-seal paused contracts)0xffe2…9081discovery———multisig
Ethereummultisig (Rewards Share Committee)0xe2a6…2c8cdiscovery———multisig
Ethereummultisig (Simple DVT Module Committee)0x0863…40f7discovery———multisig
Ethereummultisig (stVaults Committee — EasyTrack caller for OperatorGrid and VaultHub factories)0x18a1…ffffdiscovery———multisig
Ethereummultisig (Tiebreaker Builders Sub Committee)0x3d3b…2951discovery———multisig
Ethereummultisig (Tiebreaker Core Committee — DG last resort)0xf656…e2f5discovery———multisig
Ethereummultisig (Tiebreaker Ethereum Ecosystem Sub Committee)0xbf04…4baediscovery———multisig
Ethereummultisig (Tiebreaker Node Operators Sub Committee)0xdbfa…715cdiscovery———multisig
Ethereummultisig (Token Reward Program TRP Committee)0x8345…b759discovery———multisig
Ethereummultisig (Treasury Management Committee — Stonks)0xa02f…d647discovery———multisig
Ethereumoracle (AccountingOracle proxy)0x852d…3ceediscovery———oracle
Ethereumoracle (CSFeeOracle proxy — Community Staking Module oracle)0x4d40…f7fbdiscovery———oracle
Ethereumoracle (HashConsensus for AccountingOracle)0xd624…b288discovery———oracle
Ethereumoracle (HashConsensus for ValidatorsExitBusOracle)0x7fad…355adiscovery———oracle
Ethereumoracle (LazyOracle proxy — V3 lazy oracle)0x5db4…ad6cdiscovery———oracle
Ethereumoracle (OracleReportSanityChecker)0xf164…3129discovery———oracle
Ethereumoracle (ValidatorsExitBusOracle proxy)0x0de4…5c6ediscovery———oracle
Ethereumother (Accounting proxy — oracle report application and reward distribution)0x23ed…cddfdiscovery———oracle
Ethereumother (Aragon ACL proxy — permission registry)0x9895…37bbdiscovery———governance
Ethereumother (Burner proxy — holds stETH to be burned on oracle report)0xe76c…573adiscovery———oracle
Ethereumother (CrossChainController proxy — BSC a.DI governance forwarding L1)0x9355…9a7cdiscovery———governance
Ethereumother (CSAccounting proxy — CSM bond accounting)0x4d72…e5dadiscovery————
Ethereumother (CSFeeDistributor proxy)0xd99c…18d0discovery————
Ethereumother (CSModule proxy — Community Staking Module)0xda7d…a83fdiscovery————
Ethereumother (Curated Node Operators Registry proxy)0x5503…28d5discovery———factory
Ethereumother (DepositSecurityModule — prevents deposit frontrunning)0xffa9…72fddiscovery————
Ethereumother (Dual Governance Config Provider)0xa169…b5efdiscovery———governance
Ethereumother (EVMScriptExecutor for EasyTrack)0xfe59…f977discovery————
Ethereumother (Insurance Fund)0x8b3f…de35discovery————
Ethereumother (L1 TokenBridge proxy — Linea canonical bridge L1)0x051f…3319discovery———bridge
Ethereumother (L1ERC20Bridge proxy — ZKSync L1 bridge)0x4152…5989discovery———bridge
Ethereumother (L1ERC20TokenBridge proxy — Base L1 bridge)0x9de4…1e72discovery———bridge
Ethereumother (L1ERC20TokenBridge proxy — Lisk L1 bridge)0x9348…9fcfdiscovery———bridge
Ethereumother (L1ERC20TokenBridge proxy — Mantle L1 bridge)0x2d00…468bdiscovery———bridge
Ethereumother (L1ERC20TokenBridge proxy — Mode L1 bridge)0xd0de…3f2adiscovery———bridge
Ethereumother (L1ERC20TokenBridge proxy — Swellchain L1 bridge)0xecf3…4121discovery———bridge
Ethereumother (L1ERC20TokenBridge proxy — Zircuit L1 bridge)0x912c…6c79discovery———bridge
Ethereumother (L1ERC20TokenGateway proxy — Arbitrum L1 bridge)0x0f25…8e5adiscovery———bridge
Ethereumother (L1Executor proxy — ZKSync governance L1)0xff7f…47f2discovery———governance
Ethereumother (L1LidoGateway proxy — Scroll L1 bridge)0x6625…f504discovery———bridge
Ethereumother (L1LidoTokensBridge proxy — Optimism L1 bridge)0x7694…5de6discovery———bridge
Ethereumother (L1LidoTokensBridge proxy — Soneium L1 bridge)0x2f54…e55adiscovery———bridge
Ethereumother (L1LidoTokensBridge proxy — Unichain L1 bridge)0x7556…1877discovery———bridge
Ethereumother (LidoLocator implementation)0x2f87…c72ddiscovery————
Ethereumother (LidoLocator proxy — protocol-wide address registry)0xc1d0…d2ebdiscovery———factory
Ethereumother (MEV Boost Relay Allowed List)0xf95f…610ediscovery————
Ethereumother (NTT Manager proxy — BSC wstETH bridge L1)0xb948…2bd9discovery———bridge
Ethereumother (OperatorGrid proxy — stVaults operator registry)0xc696…544ddiscovery———factory
Ethereumother (PredepositGuarantee proxy — predeposit protection for stVaults)0xf4bf…aac3discovery————
Ethereumother (Reseal Manager — extends GateSeal pauses)0x7914…2d24discovery————
Ethereumother (Simple DVT Node Operators Registry proxy)0xae7b…b433discovery———factory
Ethereumother (Staking Vault Beacon — upgradeable beacon for stVaults)0x5fbe…a789discovery———vault
Ethereumother (StakingRouter proxy — manages staking modules)0xfddf…2999discovery————
Ethereumother (TokenRateNotifier — post-rebase rate pusher)0x25e3…5ba9discovery————
Ethereumother (Triggerable Withdrawals Gateway)0xdc00…037bdiscovery———bridge
Ethereumother (TRP VestingEscrowFactory — token reward program)0xda1d…add0discovery———token
Ethereumother (VaultHub proxy — stVaults coordination)0x1d20…6709discovery————
Ethereumother (Veto Signaling Escrow proxy — stETH/wstETH/unstETH lock for DG veto)0x1658…8e1cdiscovery————
Ethereumother (WithdrawalQueueERC721 proxy — withdrawal NFT queue)0x889e…f9b1discovery————
Ethereumtimelock (EmergencyProtectedTimelock — Dual Governance enforced timelock)0xce04…2316discovery———timelock
Ethereumtoken (LDO governance token — MiniMeToken)0x5a98…1b32discovery———governance
Ethereumtoken (Lido stETH implementation)0x6ca8…a600discovery———token
Ethereumtoken (wstETH — wrapped stETH ERC-20)0x7f39…2ca0discovery———token
Ethereumtreasury (Aragon Finance proxy)0xb9e5…3d86discovery———governance
Ethereumvault (Execution Layer Rewards Vault — collects MEV/priority fees)0x388c…9297discovery———vault
Ethereumvault (WithdrawalVault proxy — collects beacon chain withdrawals)0xb9d7…293fdiscovery———vault
moonbeamTransparentUpgradeableProxy0xfa36…a108TVL✓proxy——
moonriverTransparentUpgradeableProxy0xffc7…fa8cTVL✓proxy——
Optimismgovernance (Optimism Governance Bridge Executor)0xefa0…6fc3discovery———governance
Optimismmultisig (Emergency Brakes Optimism — 3/5)0x4cf8…3088discovery———multisig
Optimismother (L2ERC20ExtendedTokensBridge proxy — Optimism)0x8e01…6957discovery————
Optimismtoken (StETH ERC20RebasableBridgedPermit proxy — Optimism)0x76a5…4138discovery———token
Optimismtoken (WstETH ERC20BridgedPermit proxy — Optimism)0x1f32…4ebbdiscovery———token
Polygontoken (WstETH UChildERC20 proxy — Polygon PoS)0x03b5…bccddiscovery———token
Scrollgovernance (Scroll Governance Bridge Executor)0x0c67…ee09discovery———governance
Scrollmultisig (Emergency Brakes Scroll — 3/5)0xf580…4ee6discovery———multisig
Scrollother (L2LidoGateway proxy — Scroll)0x8ae8…56c9discovery————
Scrolltoken (L2WstETHToken proxy — Scroll)0xf610…da32discovery———token
ZKSyncgovernance (ZkSync Governance Bridge Executor proxy)0x139e…3f3cdiscovery———governance
ZKSyncmultisig (Emergency Brakes ZKSync — 3/5)0x0d7f…fe94discovery———multisig
ZKSyncother (L2ERC20Bridge proxy — ZKSync)0xe1d6…782bdiscovery————
ZKSynctoken (ERC20BridgedUpgradeable proxy — ZKSync wstETH)0x703b…e867discovery———token

Protocol Info

Links

[defillama] Source: DeFiLlama [:] Source: DEFI@home quorum
Website
https://lido.fi
Twitter
@LidoFinance
GitHub
11 repositories
Docs
https://docs.lido.fi/
Governance forum
https://research.lido.fi/
DefiScan
DefiScan · Stage 0

Security

[curated] Source: curated human overlay [:] Source: DEFI@home quorum
Audits
127 audits
Bug bounty
https://immunefi.com/bounty/lido/
Security contact
https://github.com/lidofinance/core/blob/master/SECURITY.md

Technical

[:] Source: DEFI@home quorum
Voting token
LDO Ethereum: 0x5A98FcBEA516Cf06857215779Fd812CA3beF1B32
Deployed contracts
https://docs.lido.fi/deployed-contracts/
Upgradeability
Upgradeable

Provenance

[defillama] Source: DeFiLlama [:] Source: DEFI@home quorum
Review status
listed
Updated
2026-06-02 13:51 UTC

Hallmarks

  1. Jan '21Start of incentives for curve pool
  2. May '22UST depeg
  3. Jun '22stETH depeg
  4. Nov '22FTX collapse
  5. May '23ETH Withdrawal Activation