Below is the full text of the Lido Lend proposal. It brings together the announcement, the feature highlights on Fallback Exits, the Guardian Security Council and Turbulence Controls, and the technical specification and committees shared in this thread.
The following proposal is intended for discussion in this thread. Edits are expected following community feedback, and the text will be updated before the Lido DAO on-chain vote.
Lido Lend: Final Proposal
1. Proposal Summary
This proposal seeks Lido DAO acceptance of Lido Lend, a new decentralized lending market, built on a modified fork of Morpho Blue and designed around the principle of security-first and lender-first isolated markets.
Lido Lend is built for lenders who are long-term, passive holders of on-chain assets looking for rewards, without exposure to hidden risks. Every market is scoped so that lenders have clarity around the rules of the market, access to reliable exits during full utilization or liquidity crunches, and screening mechanisms for new collateral supplies which seek to guard lenders from bad collateral. Three features shared in this thread serve this purpose:
- Fallback Exits, a lending mechanism built to provide lenders with a secure and predictable liquidity exit path in times of turbulence;
- the Guardian Security Council, a screening mechanism built to help protect Lido Lend markets, and especially lenders, from tainted or stolen assets, as well as other novel attack vectors;
- Turbulence Controls, a set of mechanisms designed to mitigate the impact of severe collateral events, including hacked or stolen collateral, dirty-flow/dusting attacks, and liquidity crunches.
The Lido Lend core contracts are deployed on mainnet. The core, the IRM router, and each controller, vault, Guardian registry and standard oracle run behind upgradeable proxies. The Lido DAO Agent is the proxy admin of these contracts, the owner of the IRM router, and the role admin of LidoLendOwner, the RiskStewardDashboard, each controller and each Guardian registry.
Four committees are able to act within the confines of Lido Lend with specific scopes and responsibilities: three Lend committees and a Guardian Security Council for each market. Contract upgrades and role administration are not delegated to the committees and require Lido DAO votes.
The Lido DAO on-chain vote would register the Lido Lend Easy Track factories, each bounded to a fixed set of contract calls. The vote does not approve specific markets. At the contract level, the Easy Track roles are held by the Lido EVMScriptExecutor, so the limits on the Lend Operational Committee, the only Lend committee that acts through Easy Track, come from the set of registered Easy Track factories. New markets are added to Lido Lend through Lend Operational Committee Easy Track motions, using the Easy Track factory registered by this vote, and LDO holders can object during the motion period. Lido DAO on-chain votes can also add markets directly, though this is not the main path. Market parameters and Guardian Security Council members are defined per market and will be shared in this thread before the corresponding motion or vote.
Assuming general support and no blocking issues are raised, the tentative plan is to proceed with the Lido DAO on-chain vote.
2. Motivation
Over the past year, incidents across lending markets have created what Lido contributors see as an opportunity for an opinionated and hyper-resilient spin on lending, purpose-built for looping on one side and conservative lenders on the other.
The core principles shaping the Lido Lend approach are:
- the system should offer protections that close major attack vectors, e.g. through screening and filtering of hacked funds, and through a more deliberate approach to asset selection and separation;
- lending should be safe and dependable, following a “set it and forget it” approach, with high liquidity and reliable exit paths across market conditions;
- markets should be focused on blue-chip assets, pairs should be price-correlated (e.g. stETH / ETH) to temper potential volatility;
- borrowing should follow clear and predictable rules, so even under stressful market conditions extended looping positions can be unwound.
Lido Lend is not designed as a general-purpose pooled lending solution, but rather as a hyper-secure solution for the specialized needs of professional borrowers and risk-averse lenders, intended to complement current market solutions.
3. Why Lido
Lido Staking is one of the most battle-tested protocols on Ethereum, with more than $25B staked in the form of stETH, novel DeFi primitives across Lido Earn and stVaults, and zero major security incidents since inception. This is the outcome of a security, transparency, and trust model that extends to all products under the Lido banner. With six+ years building critical onchain Ethereum infrastructure, Lido contributors have a proven operational track record.
Low-risk DeFi is what Lido builds best, and Lido Lend complements both the stETH flywheel as well as Lido Earn. Curated DeFi vaults like EarnETH and EarnUSD will most likely be early users of Lido Lend.
4. Protocol Design
Architecture
The LidoLend core contract stores all markets. A market is defined by five parameters: loan token, collateral token, oracle, interest-rate model (IRM) and Liquidation LTV (LLTV). Positions and totals are isolated per market.
The Lido Lend fork makes four changes to Morpho Blue:
- only the owner can create markets;
- each market can be bound to a controller, which the core calls before most market actions;
- a
settlefunction is added for lender settlement; - the core can run behind a proxy.
Each market has its own market controller, a smart contract that the core calls before most market actions. It checks the action against the market’s rules (supply cap, collateral maturation, Guardian-based borrow restrictions, freeze and pause, settlement queue) and reverts it if a rule is broken. It cannot change the amounts computed by the core, spend user tokens, or act for user accounts.
When a market is created, its five parameters, its controller address and the settlement setting are fixed, and no contract function can change them later. The following can change after creation:
- the IRM and its configuration, because the market stores the address of
IrmRouter, which selects the model for that market; - controller settings, such as the supply cap and the maturation and settlement configuration, through the committee and DAO roles;
- contract code, through a proxy upgrade, until the proxy is ossified.
Fallback Exits
Fallback Exits are built to provide lenders with a secure and predictable liquidity exit path in times of turbulence. When loan asset liquidity is insufficient, lenders can use borrower collateral to supplement the withdrawal request.
The mechanism behind it is settlement. Settlement lets a lender exit without loan-token liquidity. Part of a borrower’s debt is cancelled against the lender’s supply, and the lender gets collateral of the same oracle value, with no liquidation incentive. By default, settlement targets the borrower at the top of a queue ordered by borrow shares per unit of collateral, which in practice means the highest LTV in the market. A lender can settle this way only the part of its supply that the market’s available liquidity cannot cover. Each such cut is also capped by a governance-set policy, so a large exit may take several transactions. The Fallback Exit uses this path for vault lenders: it pays out available liquidity first and settles the rest against the borrowers at the top of the queue, one by one. While the borrower at the top of the queue has bad debt, all settlement in the market is blocked until the position becomes solvent or the debt is cleared.
Guardian Security Council
Lido Lend introduces a screening mechanism for new collateral supplies, dubbed the Guardian Security Council, with one instance for each different lending market. Guardian Security Councils check collateral provenance, including whether or not funds, or the originating address, are:
- compromised or contain funds from compromised sources;
- related to illicit funds or funding of illicit activities;
- attempting to exploit or abuse Lido Lend.
New collateral counts toward position health immediately, but can be used for new borrowing only after it matures. After the maturation time, collateral matures only when Guardians in quorum have reported scans covering that time, the account is not banned, and the market is not frozen. If Guardian reports do not arrive in time, a fallback deadline lets collateral mature without them, so that Guardian downtime cannot block maturation indefinitely.
Guardians report on accounts in a market with flags and suspect reports, and both can extend the maturation time. When flags from distinct Guardians reach quorum, the account is banned in that market. A ban blocks new borrowing and stops maturing collateral from becoming active. It does not block repayment, liquidation, settlement or collateral withdrawal. Guardians cannot lift a ban. It stays in force until an unban through a Lend Operational Committee Easy Track motion.
Turbulence Controls
The market controller can restrict a market in two ways:
- a freeze is the milder one: it stops new borrowing, collateral maturation and collateral withdrawal from positions with debt, while repayment, liquidation, settlement and lender withdrawals continue. A freeze is applied by the Lend Risk Steward Committee and lifted through a Lend Operational Committee Easy Track motion;
- a pause stops every market action that goes through the controller, including repayment, liquidation and settlement. The Lend Emergency Brakes Committee can apply one pause of fixed duration to a market controller, but cannot choose the pause duration, extend or end a pause. Interest keeps accruing during a pause.
Turbulence Controls are enacted per-market, not across Lido Lend as a whole. The self-custodial nature of Lido Lend remains intact, as none of these turbulence controls nor the Guardian Security Council afford the ability to take custody of or move any user assets.
5. Governance and Committees
Contract upgrades and role administration are not delegated to the committees and require Lido DAO votes. Three Lend committees, which are multisigs, and a Guardian Security Council for each market act within narrower limits:
- the Lend Operational Committee acts through predefined Easy Track motions, open to objections from LDO holders during the motion period. It can create markets, set supply caps, maturation and settlement configuration, fees and IRM configuration, manage Guardians and their quorum, unban accounts, appoint Risk Stewards, configure Emergency Brakes and unfreeze markets;
- the Lend Risk Steward Committee acts instantly. It can freeze a market, increase the maturation time, the non-matured capital lock and the supply collateral minimum, and revoke an address’s instant maturation privilege, but cannot loosen any setting;
- the Lend Emergency Brakes Committee acts instantly through
CircuitBreaker, while it sends periodic heartbeats, and can apply one pause of fixed duration to a market controller; - the Guardian Security Council screens incoming collateral offchain and can ban an account in a market when flags reach quorum.
An account can be banned only through a Guardian quorum. The role for a direct ban (ACCESS_LIMITER_ROLE) has no holder at launch, and granting it requires a separate DAO decision. The full table of powers is in the technical specification, and roles.md maps every privileged action to its holder.
| Committee | Signing threshold | Members |
|---|---|---|
| Lend Operational Committee | 5 of 7 | @psirex, @alexander_tarelkin, @Izzy, @Willem, @TheDZhon, @mikgur, @Mol_Eliza |
| Lend Risk Steward Committee | 3 of 7 | @psirex, @alexander_tarelkin, @Izzy, @Willem, @TheDZhon, @mikgur, @Mol_Eliza |
| Lend Emergency Brakes Committee | 3 of 6 | @psirex, @alexander_tarelkin, @Izzy, @skhomuti, @George, @folkyatina |
Guardian Security Council members are defined at a per-market basis and will be shared later in this thread.
A pause normally ends when its duration expires. If Dual Governance is not in its normal state, the protocol-wide Reseal Manager can make the pause permanent.
DISCLAIMER
To use Lido Lend, a user must acknowledge and agree that the Guardians and any other members of the Guardian Security Councils, the members of any of the Committees (Lend Risk Steward Committee, Lend Emergency Brakes Committee, Lend Operational Commitee) or other body involved in any Lido Lend protocol (“Protocol”) decision, including any committee acting under authority delegated by the Lido DAO (“Protocol Role Holders”), have no liability to the user for any act, omission, error or delay in the performance of their functions. This includes any decision to ban or not to ban an account, to adjust or not to adjust a parameter, or to pause or not to pause a Protocol function. To the maximum extent permitted by law, the user releases each Protocol Role Holder from, and agrees not to bring, any such claim. Protocol Role Holders owe the user no fiduciary or other duty by reason of their functions.
6. Market Onboarding
After the vote, each market is added through its own Easy Track motion:
- Lido contributors publish market details in this thread: the five market parameters, supply cap, maturation and settlement configuration, IRM configuration, and the Guardian Security Council members and quorum;
- the Lend Operational Committee starts an Easy Track motion to create the market in the Lido Lend core;
- LDO holders can object during the motion period;
- if the motion is not blocked by objections, it is enacted and the market is created.
The first market is expected to be WETH / wstETH, with a single Guardian run by Lido contributors (1-of-1 quorum) at launch and independent Guardians added later. Markets with USD-stablecoin loan assets against tokenized RWAs are expected to follow.
7. Risks and Mitigations
| Risk | Description | Mitigation |
|---|---|---|
| Modified fork | The changes to Morpho Blue introduce new security assumptions. The original audits, formal verification and track record don’t automatically carry over. Integrations built for Morpho Blue may be affected by the additional controller checks. | FORK_NOTES.md details the delta from the upstream commit. The changes go through external audits and AI-assisted continuous audit and monitoring. The Lido bug bounty program on Immunefi will be updated to include Lido Lend in scope. |
| Upgradeability | The core, the IRM router, and each controller, vault, Guardian registry and standard oracle run behind upgradeable proxies. For the core, the immutability guarantees of upstream Morpho Blue apply only after ossification. | The Lido DAO Agent is the proxy admin. Contract upgrades are not delegated to the committees and require Lido DAO votes. |
| Shared components | Accounting is isolated per market, but one core holds the tokens of all markets. A flash loan can use the core’s full balance of a token, and a failure of a token affects every market that uses it. Core authorization is global. An oracle, IRM or Guardian registry may also serve several markets. | Different markets can have different Guardians, and this is decided for each market. Turbulence Controls are enacted per-market. |
| Oracle | The oracle adapters for initial markets take the collateral price from the rate published by the collateral issuer, not from secondary-market prices. If the market price of the collateral falls while the published rate does not, the protocol overvalues the collateral. Liquidation may then become uneconomic, and settlement may pay out collateral worth less than the debt it cancels. The contracts do not detect such events. | Detection and response are operational, for example through a pause. Future markets may use other price sources, such as secondary-market prices. |
| Screening limits | The design keeps stolen or sanctioned collateral from becoming borrowing capacity; it does not keep funds out of the market. The registry checks the referenced block hash and cannot verify the scan itself. If Guardian reports do not arrive in time, collateral matures without them. | New collateral can be used for new borrowing only after it matures, and the minimum maturation time grows with recent collateral inflow across the market. If a threat is missed, the Lend Risk Steward Committee can freeze the market, which stops new borrowing and collateral maturation, and the Lend Emergency Brakes Committee can pause it. |
| Settlement for borrowers | During a liquidity crunch, the borrower at the top of the settlement queue can have debt cancelled against collateral of the same oracle value, with no liquidation penalty. | A lender can settle only the part of its supply that available liquidity cannot cover, and each settlement is capped by a governance-set policy. Settlement is blocked while the borrower at the top of the queue has bad debt. |
| Pause | A pause stops every market action that goes through the controller, including repayment, liquidation and settlement. Interest keeps accruing during a pause. | A pause applies to one market controller. The Lend Emergency Brakes Committee cannot choose its duration, extend it, or pause the same controller again before it is re-registered through a Lend Operational Committee motion. |
| Committee actions | Committee members can make wrong or delayed decisions, or lose access to their keys. | The three Lend committees are multisigs and act when their signing threshold is reached. The Lend Risk Steward Committee cannot loosen any setting. The Lend Operational Committee acts only through predefined Easy Track motions, open to objections from LDO holders. No committee can upgrade contracts or withdraw user positions. |
| Market-specific risks | Each collateral carries its own risks. For example, collateral with transfer restrictions may need liquidators approved by its issuer. | Market parameters are defined per market and will be shared in this thread before the market’s motion. |
8. What’s Next?
If the proposal is approved, Lido Lend proceeds as follows:
- the Lido DAO on-chain vote registers the Lido Lend Easy Track factories;
- the Lend Operational Committee starts a motion to create the WETH / wstETH market, with its parameters published in this thread beforehand;
- the Lido Lend web interface goes live;
- further markets follow, each through its own motion.
Feedback and questions are welcome in this thread.
9. References
- Technical specification and committees: post;
- lending core: lidofinance/lend;
- policy layer: lidofinance/lend-markets, with the architecture overview and roles.md;
- interest-rate models: lidofinance/lend-irm;
- Guardian reference implementation: lidofinance/lend-guardian-daemon;
- Easy Track factories: lidofinance/easy-track, branch feat/lido-lend-factories.