Lido Lend: Technical Specification and Committees
The following post outlines the Lido Lend technical specifications, and describes the different committees proposed to operate the protocol, as well as their proposed composition. Market parameters and audit reports will be posted separately in this thread.
1. Specifications
The Lido Lend contracts and associated specifications are detailed below.
| Repository | Contents | Start with |
|---|---|---|
| lidofinance/lend | Shared lending core, a modified fork of Morpho Blue | SPECIFICATION.md, FORK_NOTES.md |
| lidofinance/lend-markets | Lido policy layer: market controller, Guardian registry, ERC-4626 vault, Risk Steward dashboard, oracle adapters, governance facade, deployment scripts | docs/specs/architecture.md |
| lidofinance/lend-irm | Interest-rate models and the per-market IRM router, a fork of Morpho Blue IRMs | SPECIFICATION.md |
| lidofinance/lend-guardian-daemon | Reference implementation of the off-chain Guardian screening cycle | docs/guardian-specification.md |
lidofinance/easy-track, branch feat/lido-lend-factories |
Easy Track factories for the Lend Operational Committee motions. The branch contains code and tests; there is no separate specification. | contracts/EVMScriptFactories/lidoLendFactories |
Suggested reading order is as follows: the architecture overview, then the mechanism specifications it links (market controller, Guardian signals, settlement), then roles.md, which maps every privileged action to its holder. Vulnerability reports go through the Lido bug bounty program on Immunefi, as described in the SECURITY.md file of each contract repository (the program will be updated to include Lido Lend in scope in the coming days).
2. Architecture Summary
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 loan-to-value (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 (see section 3); - the core can run behind a proxy.
FORK_NOTES.md details the delta from the upstream commit and how to reproduce a full diff.
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.
3. Technical Points
- Upgradeability. The core, the IRM router, and each controller, vault, Guardian registry and standard oracle run behind upgradeable proxies with the Lido DAO Agent as proxy admin. Until a proxy is ossified, its admin can replace the contract code. For the core, this means the immutability guarantees of upstream Morpho Blue apply only after ossification. Ossification removes only the ability to upgrade. Role-based powers, such as changing the IRM configuration, remain.
- What markets share. Accounting is isolated per market, but one core holds the tokens of all markets. A flash loan can therefore 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 operator authorized by an account can act for that account in every market. An oracle, IRM or Guardian registry may also serve several markets, so a failure or privileged change in it affects each of those markets.
- Oracles. The oracle adapters for initial markets take the collateral price from the rate published by the collateral issuer, such as an accounting rate or a NAV. They do not read secondary-market prices of the collateral. 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.
- Collateral maturation (activation in the specification). New collateral counts toward position health immediately, but can be used for new borrowing only after it matures. A collateral supply below the supply collateral minimum (
minDepositAmount) reverts. Collateral below the maturation threshold (minActivationAmount) does not start the maturation timer and stays withdrawable. The minimum maturation time grows with recent collateral inflow across the market, and Guardian reports on the account can extend it. 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 (maxGuardiansQuorumDelay) lets collateral mature without them. This is deliberate, so that Guardian downtime cannot block maturation indefinitely. - Guardian reports. 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. A suspect report cannot ban an account. Guardians also send heartbeats that state how far they have scanned. The registry checks the referenced block hash and cannot verify the scan itself. Different markets can have different Guardians, and one Guardian can serve several markets. This is decided for each market. Markets that share a Guardian registry also share its membership, quorum and scan progress.
- 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 free 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 free liquidity first and settles the rest against that borrower. Borrowers can also opt in with a personal target LTV, which lets any lender settle against their position down to that target, even when free liquidity is available. 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. The settlement specification describes the rounding limits of this check.
- Freeze and pause. A market can be restricted 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 pause stops every market action that goes through the controller, including repayment, liquidation and settlement. Interest keeps accruing during a pause, and the first accrual afterwards covers the whole paused period. Flash loans and vault-share transfers do not go through the controller, so a pause does not affect them.
4. Committee Overview
Four committees are able to act within the confines of Lido Lend with specific scopes and responsibilities. The three Lend committees are multisigs and act when their signing threshold is reached. The Guardian Security Council is a set of addresses registered in a GuardianSignals registry, one per member, and each member reports on its own. Contract upgrades and role administration are not delegated to the committees and require Lido DAO votes.
| Committee | How it acts | Can | Cannot |
|---|---|---|---|
| Lend Risk Steward Committee | Instantly, by direct calls to RiskStewardDashboard |
Freeze a market. Increase the maturation time, the non-matured capital lock and the supply collateral minimum. Revoke an address’s instant maturation privilege. | Loosen any setting, unfreeze a market, change fees or interest rates, upgrade contracts |
| Lend Emergency Brakes Committee | Instantly, through CircuitBreaker (forum post). Its registration stays valid only while the committee sends periodic heartbeats. |
Apply one pause of fixed duration to a market controller | Choose the pause duration, extend or end a pause, or pause the same controller again before it is re-registered through a Lend Operational Committee motion |
| Lend Operational Committee | Through predefined Easy Track motions, open to objections from LDO holders during the motion period | Activate markets. Set supply caps, maturation and settlement configuration, fees, IRM configuration and instant maturation privileges. Manage Guardians and their quorum, and unban accounts. Appoint Risk Stewards and configure Emergency Brakes. Unfreeze markets. | Upgrade contracts, withdraw user positions, select borrowers for settlement or start settlement |
| Guardian Security Councils | Continuously, based on reports and heartbeats sent to the each market’s GuardianSignals registry. A ban on the account related to maturing collateral which has been flagged requires indications from a quorum of distinct members. |
Screen incoming collateral offchain. Flag or report accounts as suspect, which extends their maturation time. Ban an account in a market when flags reach quorum. Confirm screening progress with heartbeats, which collateral maturation waits for. | Lift a ban, block repayment, liquidation, settlement or collateral withdrawal, change market settings or the council’s own membership and quorum |
Instant maturation lets collateral supplied through a given address, such as an integration contract, mature immediately. No address has this privilege at launch. At the contract level, the Easy Track roles are held by the Lido EVMScriptExecutor, so the limits on the Lend Operational Committee come from the set of registered Easy Track factories. No committee or single actor can ban an account directly. The role for that (ACCESS_LIMITER_ROLE) has no holder at launch, and granting it requires a separate DAO decision.
Composition.
| Committee | Signing threshold | Members |
|---|---|---|
| Lend Operational Committee | 5 of 7 | Bogdan K, Alexander T, Izzy, Willem, Eugene M, Mikhail G, Max |
| Lend Risk Steward Committee | 3 of 7 | Bogdan K, Alexander T, Izzy, Willem, Eugene M, Mikhail G, Max |
| Lend Emergency Brakes Committee | 3 of 6 | Bogdan K, Alexander T, Sergey K, George A, Izzy, Alexey P |
Guardian Security Council members are define at a per-market basis and will be shared later in this thread.
Members:
- Izzy (@Izzy), Head of Lido Lend;
- Bogdan K (@psirex), Lido Lend tech lead;
- Alexander T (@alexander_tarelkin), Lido Lend developer;
- Alexey P (@folkyatina), Lido Lend developer;
- Willem (@Willem), Protocol Relations Lead at Lido Ecosystem;
- Mikhail G (@mikgur), Lido analyst and parameter reviewer of Lido Lend;
- Max (@Mol_Eliza), Lido analyst and economics contributor to Lido Lend;
- Sergey K (@skhomuti), Lido contributor and protocol security reviewer of Lido Lend;
- George (@George), Lido protocol architect and reviewer of Lido Lend;
- Eugene M (@TheDZhon), Chief Technical Master at Lido.
Each member will confirm their signing address in a reply to this post with a signed message.
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.
5. Next Steps
Market parameters and audit reports will be published in this thread over the coming days. Questions and comments on the specifications outlined above are appreciated and welcome in this thread.