From 387559da9167b6f3f5afaf9c01eb3ffac449cffb Mon Sep 17 00:00:00 2001 From: fryorcraken Date: Fri, 10 Apr 2026 22:16:34 +1000 Subject: [PATCH 1/2] rfp: adopt Morpho Blue design for lending RFPs Rewrite RFP-008 from Aave-style shared pools to Morpho Blue isolated markets. Extract shared privacy architecture and platform dependencies into appendix/lending-platform.md. Update RFP-012 from Aave v3 features to MetaMorpho curated vaults. Co-Authored-By: Claude Opus 4.6 --- RFPs/RFP-008-lending-borrowing-protocol.md | 389 ++++++++------------- RFPs/RFP-012-advanced-lending-features.md | 294 +++++++++------- appendix/lending-platform.md | 137 ++++++++ 3 files changed, 459 insertions(+), 361 deletions(-) create mode 100644 appendix/lending-platform.md diff --git a/RFPs/RFP-008-lending-borrowing-protocol.md b/RFPs/RFP-008-lending-borrowing-protocol.md index 05d2682..df60b10 100644 --- a/RFPs/RFP-008-lending-borrowing-protocol.md +++ b/RFPs/RFP-008-lending-borrowing-protocol.md @@ -4,7 +4,7 @@ title: Lending & Borrowing Protocol tier: XL funding: $XXXXX status: open -dependencies: See Platform Dependencies section +dependencies: See Appendix — Platform Dependencies category: Applications & Integrations --- @@ -13,24 +13,30 @@ category: Applications & Integrations ## 🧭 Overview -Build a lending and borrowing protocol on LEZ that allows users to supply -assets to liquidity pools, earn interest, and borrow against -over-collateralised positions. The protocol must include algorithmic -interest rates, a permissionless liquidation engine, oracle-fed price -data, and composable receipt tokens — the core primitives that every -major lending protocol (Aave, Compound, Morpho, Kamino, etc.) depends on. - -Lending is the capital-efficiency engine of any DeFi ecosystem. It unlocks -idle assets by letting holders earn yield and borrowers access liquidity -without selling. For the Logos ecosystem, a lending protocol creates -demand for assets deployed on LEZ, drives TVL, and provides a -composability surface that other programs can build on. - -This RFP targets Aave v2 core equivalence — the foundational lending -primitives (supply, borrow, repay, withdraw, liquidation, interest -accrual, oracle integration). Advanced features such as eMode, flash -loans, isolated markets, and multiple collateral per position (Aave v3 -territory) are out of scope here and addressed in +Build a permissionless, isolated-market lending protocol on LEZ, +following the Morpho Blue design: each market is an independent lending +pair defined by five immutable parameters (loan token, collateral +token, oracle, interest rate model, liquidation LTV). Anyone can create +a market from enabled parameters; the core protocol is minimal and +governance-free. The protocol includes algorithmic interest rates, +permissionless liquidation, oracle-fed price data, and flash loans via +callbacks. + +Lending is the capital-efficiency engine of any DeFi ecosystem. It +unlocks idle assets by letting holders earn yield and borrowers access +liquidity without selling. Morpho Blue demonstrated the power of this +minimal, isolated-market approach: its core contract is approximately +650 lines of Solidity, yet the protocol attracted [DATA NEEDED] in +deposits within its first year on Ethereum. For the Logos ecosystem, a +lending protocol creates demand for assets deployed on LEZ, drives TVL, +and provides a composability surface that other programs can build on. + +This RFP targets Morpho Blue core equivalence: the foundational +isolated-market lending primitives (market creation, supply, borrow, +repay, withdraw, liquidation, interest accrual, oracle integration, +flash loans). The curation layer (single-asset deposit vaults that +allocate across multiple markets, vault share tokens, supply and borrow +caps) is addressed in [RFP-012](./RFP-012-advanced-lending-features.md). The applying team should have experience building or contributing to on-chain lending protocols and be comfortable with interest rate modelling, liquidation @@ -49,11 +55,21 @@ ecosystem lacks the capital-efficiency layer needed to attract serious DeFi activity. A lending protocol is the single highest-leverage application for growing the Logos ecosystem. +The Morpho Blue model offers specific advantages for a nascent +ecosystem like LEZ. Permissionless market creation removes governance +bottlenecks for listing new assets, letting the market decide which +pairs are worth lending against. Isolated markets eliminate systemic +contagion: bad debt in one market cannot cascade to others. And the +minimal core (no upgradeable parameters, no complex shared-pool +accounting) is easier to audit, formally verify, and reason about, +which is critical when the protocol is the first lending primitive on a +new chain. + Beyond TVL, lending creates downstream demand: it establishes a -borrowing market for stablecoins, generates liquidation volume for DEXs, -and provides the collateral infrastructure needed for synthetic assets -and structured products. Every major DeFi ecosystem was built on this -foundation. +borrowing market for stablecoins, generates liquidation volume for +DEXs, and provides the collateral infrastructure needed for synthetic +assets and structured products. Every major DeFi ecosystem was built on +this foundation. ## ✅ Scope of Work @@ -61,47 +77,62 @@ foundation. #### Functionality -1. Users can supply supported assets to liquidity pools and receive - interest-bearing receipt tokens representing their pool share. - Receipt tokens must be standard SPL tokens, freely transferable - and composable with other LEZ programs. -2. Users can borrow supported assets against deposited collateral. - All borrow positions must be over-collateralised, governed by - per-asset LTV ratios. -3. Users can repay borrowed assets in full or partially. -4. Users can withdraw supplied assets at any time, subject to - available pool liquidity. -5. Interest rates are determined by a utilisation-based model that - increases rates as pool utilisation rises, incentivising repayment - and maintaining withdrawal liquidity. The specific model design - is left to the implementer. Parameters must be configurable per - asset. -6. Interest accrues continuously. Supply APY and borrow APR are - deterministic functions of pool utilisation, queryable on-chain. -7. When a borrower's health factor (the ratio of weighted collateral - value to outstanding debt; HF ≥ 1 means solvent, HF < 1 means - eligible for liquidation) drops below 1, any account can - permissionlessly liquidate the position by repaying a portion of - the debt and receiving equivalent collateral at a discount. - Liquidation is partial (configurable close factor per transaction). -8. An admin authority can independently configure risk parameters per - asset: LTV, liquidation threshold, liquidation bonus, reserve - factor, and supply/borrow caps. -9. A reserve factor diverts a percentage of borrow interest into - protocol reserves as a buffer against bad debt. -10. Price feeds from at least one oracle provider are integrated for - collateral valuation and liquidation triggers. -11. Per-asset supply and borrow caps are enforced and adjustable by - an admin authority without program upgrade. -12. A liquidator bot that continuously monitors all borrower - positions and executes liquidations when health factors drop - below 1. The bot is the protocol's solvency mechanism — without - it, bad debt accumulates and the protocol becomes insolvent. - Must be runnable by any third party. -13. A risk monitoring service that tracks protocol health metrics: - per-asset utilisation, aggregate collateral ratios, positions - approaching liquidation thresholds, and oracle feed status. - Must expose metrics via an API or dashboard. +1. Anyone can create a lending market by specifying five parameters: + loan token mint, collateral token mint, oracle program, interest + rate model (IRM) program, and liquidation loan-to-value ratio + (LLTV). The market ID is the deterministic hash of these five + parameters. Market creation is permissionless; no admin approval is + required. +2. Users can supply the loan token to a specific market. The protocol + tracks supply shares internally per market per account (no receipt + token at the core level). Supply shares represent a proportional + claim on the market's loan token balance plus accrued interest. +3. Users can withdraw supplied loan tokens from a market at any time, + subject to available liquidity in that market. +4. Users can deposit the market's collateral token and borrow the loan + token, up to the market's LLTV ratio. +5. Users can repay borrowed loan tokens in full or partially. +6. Each market uses the IRM program specified at creation. The IRM + computes the borrow rate as a deterministic function of market + utilisation. Interest accrues continuously; supply APY and borrow + APR are queryable on-chain per market. +7. Interest accrual is lazy (computed on interaction), not via a + separate crank transaction per block. +8. When a borrower's position LTV exceeds the market's LLTV, any + account can permissionlessly liquidate the position by repaying a + portion of the debt and receiving equivalent collateral plus a + liquidation incentive. The liquidation incentive factor is derived + from the market's LLTV (higher LLTV markets have smaller incentives; + lower LLTV markets have larger incentives). +9. An admin authority manages two protocol-level functions: + (a) enabling LLTV values that market creators can select from + (e.g. 86%, 91.5%, 94.5%), and (b) enabling IRM implementations + that market creators can select from. Market creators choose from + enabled parameters; the admin does not control individual markets + after creation. +10. An optional protocol fee diverts a configurable fraction of + interest accrued in each market to a fee recipient account. The + fee percentage and recipient are set by the admin authority. +11. Each market references the oracle program specified at creation for + collateral valuation and liquidation triggers. The oracle is a + separate LEZ program. +12. Flash loans: users can borrow assets from any market within a + single transaction via a callback mechanism. The lending program + releases funds, tail-calls the borrower's callback (via LP-0015's + capability-protected continuation model), and the callback must + invoke repayment before the transaction completes. If the callback + fails or does not repay the full amount plus fee, the transaction + reverts atomically and no funds leave the market. The flash loan + fee is configurable by the admin authority. +13. A liquidator bot that continuously monitors all markets and + executes liquidations when positions exceed their market's LLTV. + The bot is the protocol's solvency mechanism; without it, bad debt + accumulates and the protocol becomes insolvent. Must be runnable + by any third party. +14. A risk monitoring service that tracks protocol health metrics: + per-market utilisation, position LTVs approaching liquidation + thresholds, and oracle feed status. Must expose metrics via an API + or dashboard. #### Usability @@ -113,27 +144,28 @@ foundation. 3. Provide a CLI that covers core functionality of the program. The CLI may have fewer features than the GUI mini-app but must support all essential operations. -4. Liquidator bot and risk monitoring services are implemented as Logos modules, accompanied with Logos core headless CLIs/daemons. -5. The mini-app supports depositing, borrowing, repaying, - withdrawing, and viewing position health. -6. A single health factor metric is displayed per borrower position, - queryable on-chain and surfaced in both CLI and mini-app. -7. Current supply APY, borrow APR, and pool utilisation are displayed - per asset in the mini-app and CLI. +4. Liquidator bot and risk monitoring services are implemented as + Logos modules, accompanied with Logos core headless CLIs/daemons. +5. The mini-app supports creating markets, supplying, borrowing, + repaying, withdrawing, and viewing position health per market. +6. Position LTV is displayed per market per borrower, queryable + on-chain and surfaced in both CLI and mini-app. +7. Current supply APY, borrow APR, and utilisation are displayed per + market in the mini-app and CLI. 8. When interacting via a private account, the SDK must handle the - atomic deshield (deposit token + native gas) as a single indivisible - user action, preventing accidental privacy leaks from externally - funding the intermediate account. + atomic deshield (deposit token + native gas) as a single + indivisible user action, preventing accidental privacy leaks from + externally funding the intermediate account. 9. When interacting via a private account, before each operation the - mini-app must show the estimated transaction fee and confirm that the - user's shielded balance covers both the operation amount and fees - within the single deshield action. If the balance is insufficient, a - clear, actionable error must be shown before any transaction is - submitted — preventing partial deshields that could leave funds - stranded in an ephemeral account. -10. The mini-app must preview the health factor impact of a borrow or + mini-app must show the estimated transaction fee and confirm that + the user's shielded balance covers both the operation amount and + fees within the single deshield action. If the balance is + insufficient, a clear, actionable error must be shown before any + transaction is submitted, preventing partial deshields that could + leave funds stranded in an ephemeral account. +10. The mini-app must preview the position LTV impact of a borrow or withdrawal before the user confirms: displaying both the current - health factor and the projected health factor after the operation. + LTV and the projected LTV after the operation. #### Reliability @@ -142,23 +174,23 @@ foundation. 2. Liquidation triggers use a time-weighted or confidence-adjusted price, not raw spot price, to resist single-transaction price manipulation. -3. If an asset's oracle feed becomes permanently unavailable, the +3. If a market's oracle feed becomes permanently unavailable, the program rejects only operations that depend on that feed (borrows, - liquidations) for the affected asset. All other assets and + liquidations) for the affected market. All other markets and operations continue unaffected. 4. Bad debt remaining after a liquidation exhausts available - collateral is tracked and socialised across the reserve fund. + collateral is socialised among the market's suppliers (supply + shares decrease in value). Bad debt in one market does not affect + any other market. #### Performance -1. Document the transaction size of each operation (supply, borrow, - repay, withdraw, liquidate) on LEZ. LEZ's block size is limited - and this budget may change during testnet. -2. Interest accrual is lazy (computed on interaction), not via a - separate crank transaction per block. -3. The program supports at least 5 distinct asset markets - simultaneously without exceeding LEZ compute limits on any - single user operation. +1. Document the transaction size of each operation (market creation, + supply, borrow, repay, withdraw, liquidate, flash loan) on LEZ. + LEZ's block size is limited and this budget may change during + testnet. +2. The program supports at least 20 independent markets without + exceeding LEZ compute limits on any single user operation. #### Supportability @@ -184,19 +216,19 @@ foundation. interaction and the deshield→interact→reshield pattern for private account interaction. When a user chooses the private account path, the SDK must enforce the complete deshield→interact→reshield - pattern — the reshield step must not be skippable. + pattern; the reshield step must not be skippable. 2. When using the private account path, the mini-app must display a pre-confirmation summary for each operation that clearly identifies - what will be visible on-chain (amounts, asset type, pool address, + what will be visible on-chain (amounts, asset type, market address, ephemeral intermediary account) and what will remain private (the originating private account, the destination of re-shielded tokens, and any link between separate interactions by the same user). 3. When using the private account path, the SDK must validate that the - target receipt token account for re-shielding is a private - (shielded) account before submitting the transaction, and reject the - operation with an explicit error if it is not. -4. The ephemeral public account (account A) created during the deshield - step must never be reused across operations. Each protocol + target account for re-shielding is a private (shielded) account + before submitting the transaction, and reject the operation with an + explicit error if it is not. +4. The ephemeral public account (account A) created during the + deshield step must never be reused across operations. Each protocol interaction from a private account must use a freshly generated account with no prior on-chain history. @@ -205,25 +237,25 @@ foundation. If possible. #### Reliability -1. Multi-oracle redundancy: at least two independent oracle providers, - with fallback when the primary is stale or unavailable. -2. Formal verification of critical invariants: (a) a healthy position - cannot be liquidated, (b) receipt token supply equals total - supplied assets plus accrued interest, (c) interest rate output is - monotonically increasing with utilisation. +1. Multi-oracle redundancy: at least two independent oracle providers + per market, with fallback when the primary is stale or unavailable. +2. Formal verification of critical invariants: (a) a position below + the market's LLTV cannot be liquidated, (b) supply share value is + monotonically non-decreasing absent bad debt, (c) the IRM's borrow + rate output is monotonically increasing with utilisation. ### Out of Scope The following are explicitly excluded from this RFP. -Advanced lending features — deferred to [RFP-012](./RFP-012-advanced-lending-features.md): +Curation layer features, deferred to [RFP-012](./RFP-012-advanced-lending-features.md): -- eMode (efficiency mode): correlated asset groups with elevated LTV ratios -- Isolated markets: higher-risk assets in isolated pools with independent debt ceilings -- Flash loans: uncollateralised single-transaction loans -- Multiple collateral per position: aggregate borrowing power from a weighted collateral sum -- Curated vault abstraction: single-asset deposit vaults allocating across multiple markets -- All risk parameters adjustable without program upgrade +- Curated vault abstraction: single-asset deposit vaults allocating + across multiple markets with a curator-managed strategy +- Vault share tokens (receipt tokens): transferable SPL tokens + representing a vault deposit position +- Supply and borrow caps (enforced at the vault layer, not the core) +- Allocator and guardian roles for vault governance Other exclusions: @@ -231,138 +263,24 @@ Other exclusions: - Governance token design and distribution - Cross-chain liquidity or bridging - Leveraged looping / one-click multiply products +- Multiple collateral per position (each market has exactly one + collateral token; multi-collateral strategies are composed at the + vault layer) ### Privacy Architecture -The protocol state — lending pools, positions, interest indices, and -receipt token accounts — lives in **public (on-chain) state**. This -is a deliberate architectural choice: public state enables -permissionless liquidation, oracle integration, and composability -without open cryptographic research challenges. - -User privacy is optionally enforced at the UX layer. The mini-app and -SDK support both direct public account interaction and private account -interaction via the deshield→interact→reshield pattern. When users opt -to interact from a private account, the SDK must enforce the complete -pattern as described below. - -#### Interaction flow - -For every protocol operation (supply, borrow, repay, withdraw): - -1. The user initiates the action from their private account. The SDK - deshields to a **fresh, single-use** public account (account A) - with no prior on-chain history. The deshield atomically transfers - both the operation token **and** enough native token for gas in a - single indivisible action. -2. Account A executes the protocol operation (e.g. supplies assets, - receives receipt tokens). -3. Account A shields any outputs (receipt tokens, withdrawn assets) - back to the user's private account. Account A is never reused. - -> **Gas:** Both the operation token and gas must come exclusively from -> the deshield in step 1. Funding account A from any external source -> — such as a CEX withdrawal or a known wallet — creates an on-chain -> link to an existing identity and breaks the privacy guarantee. The -> SDK must make this impossible; the atomic deshield is a single, -> indivisible user action. - -#### What is public (observable on-chain) - -- All pool state: asset type, interest rate parameters, total - supplied, total borrowed, utilisation, supply APY, borrow APR. -- All positions: collateral amounts, debt amounts, health factor - — attributed to the ephemeral intermediary account, not the - private user. -- All protocol operations and their amounts. -- Oracle price feeds and liquidation events. - -#### What is private - -- Which private account funded any supply or borrow. -- Where receipt tokens or withdrawn assets go after re-shielding. -- Any link between multiple protocol interactions by the same user - (no on-chain linkability across ephemeral accounts). +See [Appendix: Lending Platform Context](../appendix/lending-platform.md#privacy-architecture). ## ⚠ Platform Dependencies -This RFP is open for proposal submission. However, development is blocked until the dependencies below are resolved. -LEZ has similar programming capabilities to Solana but several -primitives required by a lending protocol are not yet available. - -### Hard blockers - -These must be available on LEZ before this RFP can open. - -#### Oracle provider - -No oracle provider is available on LEZ. The lending protocol requires -external price feeds for collateral valuation and liquidation triggers. -Every hard requirement related to liquidation (F7), oracle integration -(F10), and reliability (R1–R3) depends on this. - -#### On-chain clock / timestamp - -LEZ does not yet have on-chain block time. Interest accrual — the -core economic mechanic of a lending protocol — requires knowing how -much time has elapsed between interactions. Without a reliable on-chain -timestamp, interest rates, supply APY, and borrow APR cannot be -computed. - -#### General cross-program calls (LP-0015) - -LEZ uses a tail-call execution model rather than Solana's CPI -(Cross-Program Invocation). In Solana's model, a program can call -another program mid-execution and resume when the call returns. In -LEZ's model, a tail call hands off control entirely — there is no -return. - -A lending operation like "supply" needs to: (1) call the token -program to transfer assets into the pool, then (2) continue executing -to update interest indices, mint receipt tokens, and write position -state. Without general cross-program calls, step 2 cannot happen after -step 1. Each continuation would need to be a separate externally -callable entrypoint, which is fragile and insecure (anyone could call -the continuation directly, bypassing the token transfer). - -[LP-0015](https://github.com/logos-co/lambda-prize/blob/main/prizes/LP-0015.md) -(General cross-program calls via tail calls) solves this by introducing -internal-only entrypoints protected by an unforgeable capability, so -the lending program can tail-call the token program and have control -return to a protected continuation. This prize is currently **open**. - -### Soft blockers - -Desirable but the RFP can open without them. - -#### Event emission (LP-0012) - -Liquidator bots and indexers need to monitor positions and react to -on-chain state changes. Without structured events, off-chain services -must poll all accounts, which is expensive and unreliable. - -[LP-0012](https://github.com/logos-co/lambda-prize/blob/main/prizes/LP-0012.md) -(Structured events for LEZ program execution) is currently **open**. - -### Risks - -#### Compute budget - -LEZ currently processes one private transaction per block. Liquidation -is the most compute-intensive lending operation: it reads the -borrower's position, multiple collateral balances, multiple oracle -prices, interest indices, and risk parameters, then writes updated -state. On Solana, a liquidation can consume 200–400K compute units. -If LEZ's per-transaction compute budget is insufficient, liquidations -will fail and the protocol risks insolvency. This needs benchmarking -once the protocol is under development. +See [Appendix: Lending Platform Context](../appendix/lending-platform.md#platform-dependencies). ## 👤 Recommended Team Profile Team experienced with: -- DeFi lending protocol design (Aave, Compound, Kamino, Morpho, or - similar) +- DeFi lending protocol design (Morpho Blue, Aave, Compound, Kamino, + or similar) - Solana or SVM program development (Anchor or native) - Interest rate modelling and utilisation curve design - Liquidation mechanism design and MEV considerations @@ -382,8 +300,9 @@ All code must be released under the **MIT+Apache2.0 dual License**. ## Resources -- [RFP-001 — Admin Authority Library](/RFPs/RFP-001-admin-authority-lib.md) +- [RFP-001 — Admin Authority Library](/RFPs/RFP-001-admin-authority-lib.md) — reference pattern for admin-gated operations (F9, F10, F12) - [RFP-002 — Freeze Authority Library](/RFPs/RFP-002-freeze-authority-lib.md) +- [Appendix: Lending Platform Context](../appendix/lending-platform.md) — shared privacy architecture and platform dependencies - TODO: LEE official doc - TODO: Oracle integration guide for LEZ - TODO: SPEL framework documentation diff --git a/RFPs/RFP-012-advanced-lending-features.md b/RFPs/RFP-012-advanced-lending-features.md index 71c8d03..301efc8 100644 --- a/RFPs/RFP-012-advanced-lending-features.md +++ b/RFPs/RFP-012-advanced-lending-features.md @@ -1,6 +1,6 @@ --- id: RFP-012 -title: Advanced Lending Features +title: Curated Lending Vaults tier: L funding: $XXXXX status: open @@ -9,37 +9,51 @@ category: Applications & Integrations --- -# RFP-012 — Advanced Lending Features +# RFP-012 — Curated Lending Vaults ## 🧭 Overview -Extend the lending protocol delivered by [RFP-008](./RFP-008-lending-borrowing-protocol.md) -with Aave v3-equivalent features: efficiency mode (eMode), isolated -markets, flash loans, multiple collateral per position, and curated -vault abstractions. These features either depend on platform primitives -not yet available on LEZ or add complexity best tackled after a -baseline protocol is live and battle-tested. - -This RFP is explicitly a follow-up to RFP-008. Teams should not apply -until the RFP-008 protocol is deployed and the platform dependencies -listed below are resolved. The applying team should ideally be the same -team that delivered RFP-008, or have deep familiarity with the deployed -protocol's internals. +Build a curated vault layer on top of the isolated-market lending +protocol delivered by [RFP-008](./RFP-008-lending-borrowing-protocol.md). +Each vault accepts deposits of a single loan token, issues transferable +vault share tokens (SPL tokens), and allocates deposits across multiple +Morpho-style lending markets according to a curator-defined strategy. +This is the MetaMorpho equivalent for LEZ: it transforms raw isolated +markets into a managed lending product with passive yield, risk +curation, and composable receipt tokens. + +Morpho Blue's isolated-market core is powerful but requires lenders to +choose individual markets manually (evaluating collateral quality, +oracle reliability, LLTV risk). Curated vaults abstract this complexity: +depositors supply a single token, the curator allocates across vetted +markets, and depositors earn blended yield. On Ethereum, MetaMorpho +vaults reached [DATA NEEDED] in deposits, demonstrating that the +vault layer is where most passive capital concentrates. The applying +team should ideally be the same team that delivered RFP-008, or have +deep familiarity with the deployed protocol's internals. ## 🔥 Why This Matters -Aave v3's efficiency mode enabled LST/underlying pairs to operate at -up to 97% LTV, dramatically improving capital efficiency for correlated -assets. Isolated markets allowed the ecosystem to list long-tail assets -without exposing the core protocol to unbounded risk. Flash loans -unlocked a class of atomic arbitrage and self-liquidation tooling that -deepened market efficiency. Together, these features transformed a -functional lending protocol into a composable capital market primitive. - -For the Logos ecosystem, delivering these features on top of the -RFP-008 baseline will complete the capital-efficiency stack, attract -more sophisticated DeFi builders, and position LEZ as a credible -alternative to established chains for advanced lending use cases. +The isolated-market model in RFP-008 optimises for safety and +permissionlessness, but it fragments liquidity: each market is +independent, and lenders must actively manage exposure across markets. +Most passive lenders (the largest source of TVL in any lending +ecosystem) will not do this. Without curated vaults, the protocol's +TVL ceiling is limited to active, sophisticated lenders. + +Curated vaults solve this by aggregating passive capital and directing +it where it earns the best risk-adjusted yield. On Ethereum, the +majority of Morpho deposits flow through MetaMorpho vaults rather than +directly into isolated markets. For the Logos ecosystem, vaults +transform the lending protocol from a tool for power users into a +passive yield product accessible to all participants, dramatically +expanding the protocol's addressable market and TVL. + +Vaults also create a natural role for risk specialists (curators) who +compete on yield and safety. This decentralises risk management: +instead of a single governance body deciding which assets are safe, +multiple curators offer different risk/yield profiles, and depositors +choose the vault that matches their preference. ## ✅ Scope of Work @@ -47,112 +61,148 @@ alternative to established chains for advanced lending use cases. #### Functionality -1. **Flash loans** — uncollateralised loans borrowed and repaid within - a single transaction. The lending program releases funds, tail-calls - the borrower's callback (via LP-0015's capability-protected - continuation model), and the callback must invoke `repay` before - returning control. If the callback fails or does not repay, the - transaction reverts atomically and no funds leave the pool. Borrowers - pay a configurable flash loan fee. - -2. **Efficiency mode (eMode)** — define correlated asset groups - (e.g. stablecoin pairs, LST/underlying) with elevated LTV and - liquidation threshold ratios. Borrowers automatically receive eMode - parameters when all collateral and debt assets belong to the same - eMode category. eMode categories are configurable by an admin - authority. - -3. **Isolated markets** — an admin authority can list higher-risk - assets in isolated pools with independent debt ceilings. Bad debt - from an isolated market does not propagate to cross-market pools. - Each isolated asset has its own debt ceiling set and enforced - on-chain by an admin authority. - -4. **Multiple collateral per position** — a single borrower can - deposit multiple distinct assets as collateral. Aggregate borrowing - power is the weighted sum of each collateral asset's contribution - (LTV × USD value). When interacting via a private account, the ZKP - must verify the aggregate collateral constraint. - -5. **All risk parameters adjustable without program upgrade** — every - configurable parameter (interest rate model slope, eMode LTV, - isolated market debt ceiling, flash loan fee, reserve factor, etc.) - must be updatable by an admin authority without redeploying the - program. +1. **Vault creation**: anyone can create a vault by specifying the + loan token, a vault name, and a vault symbol. The creator becomes + the vault's initial curator. Vault creation is permissionless. +2. **Vault share tokens**: depositors receive SPL tokens representing + their proportional share of the vault's total assets. Vault shares + are freely transferable and composable with other LEZ programs. + The share-to-asset exchange rate increases monotonically as interest + accrues (absent bad debt). +3. **Deposit and withdraw**: users can deposit the vault's loan token + and receive vault shares. Users can redeem vault shares for the + underlying loan token, subject to available liquidity across the + vault's allocated markets. +4. **Market allocation**: the curator (or an authorised allocator) + allocates vault deposits across RFP-008 lending markets. The + curator sets a supply cap per market, limiting the maximum amount + the vault can supply to each market. +5. **Supply queue and withdraw queue**: the curator defines an ordered + list of markets for deposits (supply queue) and withdrawals + (withdraw queue). Deposits flow into markets in supply queue order + until each market's cap is reached. Withdrawals draw from markets + in withdraw queue order. +6. **Curator role**: the curator can update supply caps, reorder + queues, add or remove markets from the vault's allocation set, and + set a performance fee. The curator can transfer the curator role to + another account. +7. **Allocator role**: the curator can authorise allocator accounts + that may reallocate funds between the vault's approved markets + within the curator's supply caps. Allocators cannot change caps, + queues, or fees. +8. **Performance fee**: a configurable percentage of yield accrued by + the vault is directed to the curator as a performance fee. The fee + is denominated in vault shares and minted to the curator's account + on each interaction that triggers interest accrual. +9. **Timelock for parameter changes**: changes to supply caps, market + additions, curator transfer, and fee adjustments are subject to a + configurable timelock. The timelock duration is set at vault + creation and is immutable. +10. **Guardian role**: the curator can appoint a guardian that can + revoke pending (timelocked) parameter changes before they take + effect. The guardian cannot initiate changes, only cancel them. + This is a safety mechanism against compromised curator keys. #### Usability -1. All new features are exposed in the SDK, CLI, and mini-app built +1. All vault features are exposed in the SDK, CLI, and mini-app built in RFP-008; no separate front-end is required, only extension of the existing one. -2. The mini-app clearly surfaces eMode status per position (active - category, effective LTV) and isolated market constraints (debt - ceiling remaining). -3. Flash loan callbacks must be documented with worked examples - showing how to implement an atomic arbitrage or self-liquidation - flow. +2. The mini-app displays per-vault: current APY, total deposits, + allocated markets with individual utilisation, supply caps and + remaining capacity, and the curator's performance fee. +3. The mini-app displays per-user: vault share balance, current value + in underlying token, and accrued yield since deposit. +4. When interacting via a private account, the SDK must handle the + atomic deshield (deposit token + native gas) as a single + indivisible user action, consistent with the RFP-008 privacy + pattern. +5. When interacting via a private account, before each vault + operation, the mini-app must show the estimated transaction fee and + confirm that the user's shielded balance covers both the deposit + amount and fees within the single deshield action. +6. Vault share tokens must be usable as collateral in RFP-008 lending + markets (subject to an oracle being available for the vault share + price). #### Reliability -1. Flash loans revert atomically if the borrower's callback fails to - invoke `repay` or the repaid amount (principal + fee) does not - match the borrowed amount. -2. eMode LTV parameters cannot be set above a hard-coded maximum - (configurable at deploy time, not upgradeable) to prevent - governance from enabling 100% LTV positions. -3. Isolated market debt ceilings are enforced atomically; concurrent - borrows cannot jointly exceed the ceiling. +1. Vault share value (assets per share) is monotonically + non-decreasing absent bad debt in underlying markets. +2. Supply caps are enforced atomically; concurrent deposits cannot + jointly exceed a market's cap. +3. Withdrawal always succeeds if the total available liquidity across + the vault's allocated markets covers the requested amount, even if + individual markets have insufficient liquidity (the vault draws + from multiple markets in queue order). +4. If a market in the vault's allocation incurs bad debt, the loss is + socialised across all vault depositors proportionally. The vault + must track and report realised bad debt per market. #### Performance -1. Document the transaction size of each new operation (flash loan - initiation, eMode position open, isolated market borrow) on LEZ. - LEZ's block size is limited and this budget may change during - testnet. -2. Multiple collateral positions must not exceed LEZ compute limits - for a position with up to 5 collateral assets. +1. Document the transaction size of each vault operation (deposit, + withdraw, reallocate) on LEZ. LEZ's block size is limited and this + budget may change during testnet. +2. A vault with up to 10 allocated markets must not exceed LEZ compute + limits on any single deposit or withdrawal operation. #### Supportability 1. The updated program is deployed and tested on LEZ devnet/testnet. 2. End-to-end integration tests run against a LEZ sequencer - (standalone mode) and are included in CI — CI must be green on + (standalone mode) and are included in CI; CI must be green on the default branch. 3. Every hard requirement in Functionality, Usability, Reliability, and Performance has at least one corresponding test. -4. A README addendum documents the new features: configuration steps, - eMode category setup, isolated market listing process, and a - flash loan integration guide. +4. A README addendum documents the vault features: vault creation, + curator setup, market allocation, deposit/withdrawal flow, and + guardian configuration. 5. Submit a [doc packet](https://github.com/logos-co/logos-docs/issues/new?template=doc-packet.yml) - for each new SDK feature (flash loans, eMode, isolated markets, multiple - collateral), covering the developer integration journey. + for each new SDK feature (vault creation, deposit/withdraw, market + allocation, curator/allocator/guardian roles), covering the developer + integration journey. 6. Submit a [doc packet](https://github.com/logos-co/logos-docs/issues/new?template=doc-packet.yml) - for the CLI additions covering the new features. + for the CLI additions covering the vault features. 7. Provide Figma designs or equivalent for all GUI additions to the mini-app. +#### + Privacy + +1. The mini-app and SDK must support both direct public account + interaction and the deshield→interact→reshield pattern for private + account interaction with vaults. When a user chooses the private + account path, the SDK must enforce the complete + deshield→interact→reshield pattern; the reshield step must not be + skippable. +2. When using the private account path, the mini-app must display a + pre-confirmation summary for each vault operation that clearly + identifies what will be visible on-chain (deposit/withdrawal + amount, vault address, vault share mint/burn, ephemeral + intermediary account) and what will remain private (the originating + private account, the destination of re-shielded vault shares or + withdrawn tokens, and any link between separate interactions by the + same user). +3. The ephemeral public account (account A) created during the + deshield step must never be reused across vault operations. Each + interaction from a private account must use a freshly generated + account with no prior on-chain history. + ### Soft Requirements If possible. #### Functionality -1. **Curated vault abstraction** — single-asset deposit vaults that - allocate across multiple lending markets via a curator-defined - strategy. Depositors receive vault shares; the curator rebalances - allocations to maximise yield within risk limits they define. +1. **Vault performance history**: an on-chain or indexed record of + historical vault APY, enabling depositors to evaluate curator + track records before depositing. #### Reliability -1. **Multi-oracle redundancy for eMode assets** — eMode correlated - asset groups should support a secondary oracle per asset, with - automatic fallback when the primary is stale, to prevent eMode - positions from becoming un-liquidatable due to oracle downtime. - -#### Supportability - -1. **Formal verification of eMode invariants** — (a) an eMode - position with health factor ≥ 1 cannot be liquidated, (b) eMode - LTV is never higher than the hard-coded maximum. +1. **Formal verification of vault invariants**: (a) vault share value + cannot decrease except through realised bad debt, (b) supply caps + are never exceeded, (c) timelock duration cannot be shortened after + vault creation. ### Out of Scope @@ -162,43 +212,34 @@ If possible. - Leveraged looping / one-click multiply products - Any feature already delivered by RFP-008 +### Privacy Architecture + +See [Appendix: Lending Platform Context](../appendix/lending-platform.md#privacy-architecture). + ## ⚠ Platform Dependencies This RFP is open for proposal submission. However, development is blocked until the following is satisfied: -1. **RFP-008 is live on LEZ mainnet/testnet** — this RFP extends the +1. **RFP-008 is live on LEZ devnet/testnet**: this RFP extends the deployed protocol; it cannot proceed without the base layer. -All other platform primitives required by this RFP (including -LP-0015 general cross-program calls, oracle provider, and on-chain -clock) are hard blockers for RFP-008 and will therefore be resolved -before this RFP opens. - -### Private Account Complexity - -eMode (F2) and multiple collateral per position (F4) increase ZKP -complexity for private account users: - -- **eMode** — the ZKP must verify that all collateral and debt assets - belong to the same eMode category and apply the correct elevated LTV. - This adds circuit constraints but is tractable in principle. -- **Multiple collateral** — the ZKP must aggregate the USD value of - multiple collateral assets, each with its own oracle price and LTV. - Circuit size grows with the number of collateral assets. Benchmarking - proof generation time for 5-asset positions is required before - marking this feature production-ready. +All other platform primitives required by this RFP (including LP-0015 +general cross-program calls, oracle provider, and on-chain clock) are +hard blockers for RFP-008 and will therefore be resolved before this +RFP opens. See +[Appendix: Lending Platform Context](../appendix/lending-platform.md#platform-dependencies) +for details. ## 👤 Recommended Team Profile Team experienced with: -- Aave v3 or equivalent protocol internals (eMode, isolated markets, - flash loan architecture) +- Morpho Blue and MetaMorpho vault architecture (or equivalent + vault/aggregator protocols such as Yearn, ERC-4626 vaults) - Solana or SVM program development (Anchor or native) -- ZKP circuit design (for private account compatibility of multi-asset - positions) -- Capability-based cross-program call patterns (flash loan callback model) -- DeFi governance and parameter management +- DeFi risk curation and yield optimisation strategies +- Token standard design (vault share token mechanics) +- Front-end development for DeFi applications Ideally the same team that delivered RFP-008. @@ -216,8 +257,9 @@ All code must be released under the **MIT+Apache2.0 dual License**. ## Resources - [RFP-008 — Lending & Borrowing Protocol](./RFP-008-lending-borrowing-protocol.md) -- [RFP-001 — Admin Authority Library](./RFP-001-admin-authority-lib.md) +- [RFP-001 — Admin Authority Library](./RFP-001-admin-authority-lib.md) — reference pattern for admin-gated operations (F6, F10) - [RFP-002 — Freeze Authority Library](./RFP-002-freeze-authority-lib.md) +- [Appendix: Lending Platform Context](../appendix/lending-platform.md) — shared privacy architecture and platform dependencies - TODO: Oracle integration guide for LEZ - TODO: SPEL framework documentation diff --git a/appendix/lending-platform.md b/appendix/lending-platform.md new file mode 100644 index 0000000..dbe924e --- /dev/null +++ b/appendix/lending-platform.md @@ -0,0 +1,137 @@ +--- +title: Lending Protocol Platform Context +status: draft +--- + + +# Lending Protocol Platform Context + +This appendix covers shared architectural context for the lending +protocol RFPs ([RFP-008](./RFP-008-lending-borrowing-protocol.md) and +[RFP-012](./RFP-012-advanced-lending-features.md)). + + +## Privacy Architecture + +The protocol state (lending markets, positions, interest indices, and +token accounts) lives in **public (on-chain) state**. This is a +deliberate architectural choice: public state enables permissionless +liquidation, oracle integration, and composability without open +cryptographic research challenges. + +User privacy is optionally enforced at the UX layer. The mini-app and +SDK support both direct public account interaction and private account +interaction via the deshield→interact→reshield pattern. When users opt +to interact from a private account, the SDK must enforce the complete +pattern as described below. + +### Interaction flow + +For every protocol operation (supply, borrow, repay, withdraw): + +1. The user initiates the action from their private account. The SDK + deshields to a **fresh, single-use** public account (account A) + with no prior on-chain history. The deshield atomically transfers + both the operation token **and** enough native token for gas in a + single indivisible action. +2. Account A executes the protocol operation (e.g. supplies assets to + a market). +3. Account A shields any outputs (withdrawn assets, repaid collateral) + back to the user's private account. Account A is never reused. + +> **Gas:** Both the operation token and gas must come exclusively from +> the deshield in step 1. Funding account A from any external source +> (such as a CEX withdrawal or a known wallet) creates an on-chain +> link to an existing identity and breaks the privacy guarantee. The +> SDK must make this impossible; the atomic deshield is a single, +> indivisible user action. + +### What is public (observable on-chain) + +- All market state: asset pairs, interest rate parameters, total + supplied, total borrowed, utilisation, supply APY, borrow APR. +- All positions: collateral amounts, debt amounts, position LTV, + attributed to the ephemeral intermediary account, not the + private user. +- All protocol operations and their amounts. +- Oracle price feeds and liquidation events. + +### What is private + +- Which private account funded any supply or borrow. +- Where withdrawn assets or other outputs go after re-shielding. +- Any link between multiple protocol interactions by the same user + (no on-chain linkability across ephemeral accounts). + + +## Platform Dependencies + +These RFPs are open for proposal submission. However, development is +blocked until the dependencies below are resolved. LEZ has similar programming capabilities to Solana but +several primitives required by a lending protocol are not yet +available. + +### Hard blockers + +These must be available on LEZ before any lending RFP can open. + +#### Oracle provider + +No oracle provider is available on LEZ. The lending protocol requires +external price feeds for collateral valuation and liquidation triggers. + +#### On-chain clock / timestamp + +LEZ does not yet have on-chain block time. Interest accrual (the +core economic mechanic of a lending protocol) requires knowing how +much time has elapsed between interactions. Without a reliable on-chain +timestamp, interest rates, supply APY, and borrow APR cannot be +computed. + +#### General cross-program calls (LP-0015) + +LEZ uses a tail-call execution model rather than Solana's CPI +(Cross-Program Invocation). In Solana's model, a program can call +another program mid-execution and resume when the call returns. In +LEZ's model, a tail call hands off control entirely; there is no +return. + +A lending operation like "supply" needs to: (1) call the token +program to transfer assets into the market, then (2) continue +executing to update interest indices and write position state. Without +general cross-program calls, step 2 cannot happen after step 1. Each +continuation would need to be a separate externally callable +entrypoint, which is fragile and insecure (anyone could call the +continuation directly, bypassing the token transfer). + +[LP-0015](https://github.com/logos-co/lambda-prize/blob/main/prizes/LP-0015.md) +(General cross-program calls via tail calls) solves this by introducing +internal-only entrypoints protected by an unforgeable capability, so +the lending program can tail-call the token program and have control +return to a protected continuation. This prize is currently **open**. + +### Soft blockers + +Desirable but the RFPs can open without them. + +#### Event emission (LP-0012) + +Liquidator bots and indexers need to monitor positions and react to +on-chain state changes. Without structured events, off-chain services +must poll all accounts, which is expensive and unreliable. + +[LP-0012](https://github.com/logos-co/lambda-prize/blob/main/prizes/LP-0012.md) +(Structured events for LEZ program execution) is currently **open**. + +### Risks + +#### Compute budget + +LEZ currently processes one private transaction per block. Liquidation +is the most compute-intensive lending operation: it reads the +borrower's position, collateral balance, oracle price, interest +indices, and market parameters, then writes updated state. On Solana, +a liquidation can consume 200,000 to 400,000 compute units. If LEZ's +per-transaction compute budget is insufficient, liquidations will fail +and the protocol risks insolvency. This needs benchmarking once the +protocol is under development. From 5ffa9ff3e55bb0cf5364ebff4c2d433e67876572 Mon Sep 17 00:00:00 2001 From: fryorcraken Date: Tue, 28 Apr 2026 20:32:40 +1000 Subject: [PATCH 2/2] rfp: address fact-check findings, align with template, humanize prose - fix broken relative links in appendix (./RFPs -> ../RFPs) - rename RFP-012 file to match its title (curated-lending-vaults) - update LP-0015/LP-0012 URLs from main to master branch - remove on-chain clock blocker (resolved in logos-execution-zone) - source the Solana compute-budget figures and mark liquidation CU cost as [BENCHMARK NEEDED] - add Supportability item for the privacy and anonymisation properties document, aligning both RFPs with the template - rewrite promotional and rule-of-three passages in the Overview and Why This Matters sections Co-Authored-By: Claude Opus 4.7 (1M context) --- README.md | 2 +- RFPs/RFP-008-lending-borrowing-protocol.md | 32 +++++++++++-------- ...s.md => RFP-012-curated-lending-vaults.md} | 30 ++++++++++------- appendix/lending-platform.md | 29 ++++++++--------- 4 files changed, 52 insertions(+), 41 deletions(-) rename RFPs/{RFP-012-advanced-lending-features.md => RFP-012-curated-lending-vaults.md} (90%) diff --git a/README.md b/README.md index 36dd807..0a84fec 100644 --- a/README.md +++ b/README.md @@ -65,7 +65,7 @@ Click an RFP to view details. Use the Submit Proposal button to apply. | RFP-015 | [Token Launchpad: Bonding Curve](RFPs/RFP-015-bonding-curve-launchpad.md) | L | $XXXXX | open | Applications & Integrations | [Submit Proposal](https://github.com/logos-co/rfp/issues/new?template=proposal.yml) | | RFP-016 | [Token Launchpad: LBP](RFPs/RFP-016-lbp-launchpad.md) | XL | $XXXXX | open | Applications & Integrations | [Submit Proposal](https://github.com/logos-co/rfp/issues/new?template=proposal.yml) | | RFP-008 | [Lending & Borrowing Protocol](RFPs/RFP-008-lending-borrowing-protocol.md) | XL | $XXXXX | open | Applications & Integrations | [Submit Proposal](https://github.com/logos-co/rfp/issues/new?template=proposal.yml) | -| RFP-012 | [Advanced Lending Features](RFPs/RFP-012-advanced-lending-features.md) | L | $XXXXX | open | Applications & Integrations | [Submit Proposal](https://github.com/logos-co/rfp/issues/new?template=proposal.yml) | +| RFP-012 | [Curated Lending Vaults](RFPs/RFP-012-curated-lending-vaults.md) | L | $XXXXX | open | Applications & Integrations | [Submit Proposal](https://github.com/logos-co/rfp/issues/new?template=proposal.yml) | ## Terms & Conditions diff --git a/RFPs/RFP-008-lending-borrowing-protocol.md b/RFPs/RFP-008-lending-borrowing-protocol.md index df60b10..26c9ec5 100644 --- a/RFPs/RFP-008-lending-borrowing-protocol.md +++ b/RFPs/RFP-008-lending-borrowing-protocol.md @@ -37,23 +37,23 @@ repay, withdraw, liquidation, interest accrual, oracle integration, flash loans). The curation layer (single-asset deposit vaults that allocate across multiple markets, vault share tokens, supply and borrow caps) is addressed in -[RFP-012](./RFP-012-advanced-lending-features.md). The applying team +[RFP-012](./RFP-012-curated-lending-vaults.md). The applying team should have experience building or contributing to on-chain lending protocols and be comfortable with interest rate modelling, liquidation mechanics, and oracle integration. ## 🔥 Why This Matters -Lending protocols are proven ecosystem catalysts. Aave's deployment on -Polygon catalysed over $1B in TVL and bootstrapped the entire Polygon -DeFi ecosystem. On Solana, Kamino grew to $2.8B TVL and became the -backbone for leveraged yield strategies across the chain. +Lending protocols anchor DeFi ecosystems. Aave on Polygon reached over +$1B TVL within months of deployment and was the largest application on +the chain at that time. On Solana, Kamino grew to $2.8B TVL and is the +largest source of borrowed liquidity on the chain. Without lending, assets on LEZ sit idle. Holders have no way to earn yield, builders have no liquidity primitive to compose with, and the ecosystem lacks the capital-efficiency layer needed to attract serious -DeFi activity. A lending protocol is the single highest-leverage -application for growing the Logos ecosystem. +DeFi activity. A lending protocol is one of the highest-impact +applications for growing the Logos ecosystem. The Morpho Blue model offers specific advantages for a nascent ecosystem like LEZ. Permissionless market creation removes governance @@ -65,11 +65,9 @@ accounting) is easier to audit, formally verify, and reason about, which is critical when the protocol is the first lending primitive on a new chain. -Beyond TVL, lending creates downstream demand: it establishes a -borrowing market for stablecoins, generates liquidation volume for -DEXs, and provides the collateral infrastructure needed for synthetic -assets and structured products. Every major DeFi ecosystem was built on -this foundation. +Beyond TVL, lending creates downstream demand: a borrowing market for +stablecoins and the collateral layer that synthetic assets and +structured products are built on. ## ✅ Scope of Work @@ -209,6 +207,14 @@ this foundation. 7. Submit a [doc packet](https://github.com/logos-co/logos-docs/issues/new?template=doc-packet.yml) for the CLI, covering the core operator/user journey. 8. Provide Figma designs or equivalent for the mini-app GUI. +9. Provide a privacy and anonymisation properties document covering: + what on-chain state and transaction data is visible to observers; + what data is protected when the private account path is used; trust + assumptions, specifying which guarantees are enforced by the on-chain + program and which depend on correct client behaviour; and what + happens if a user bypasses the expected interaction path. See + [Appendix: Lending Platform Context — Privacy Architecture](../appendix/lending-platform.md#privacy-architecture) + for the baseline this document must align with. #### + Privacy @@ -248,7 +254,7 @@ If possible. The following are explicitly excluded from this RFP. -Curation layer features, deferred to [RFP-012](./RFP-012-advanced-lending-features.md): +Curation layer features, deferred to [RFP-012](./RFP-012-curated-lending-vaults.md): - Curated vault abstraction: single-asset deposit vaults allocating across multiple markets with a curator-managed strategy diff --git a/RFPs/RFP-012-advanced-lending-features.md b/RFPs/RFP-012-curated-lending-vaults.md similarity index 90% rename from RFPs/RFP-012-advanced-lending-features.md rename to RFPs/RFP-012-curated-lending-vaults.md index 301efc8..83ac411 100644 --- a/RFPs/RFP-012-advanced-lending-features.md +++ b/RFPs/RFP-012-curated-lending-vaults.md @@ -27,10 +27,10 @@ choose individual markets manually (evaluating collateral quality, oracle reliability, LLTV risk). Curated vaults abstract this complexity: depositors supply a single token, the curator allocates across vetted markets, and depositors earn blended yield. On Ethereum, MetaMorpho -vaults reached [DATA NEEDED] in deposits, demonstrating that the -vault layer is where most passive capital concentrates. The applying -team should ideally be the same team that delivered RFP-008, or have -deep familiarity with the deployed protocol's internals. +vaults reached [DATA NEEDED] in deposits. Most passive capital in +Morpho concentrates in the vault layer rather than in raw markets. The +applying team should ideally be the same team that delivered RFP-008, +or have deep familiarity with the deployed protocol's internals. ## 🔥 Why This Matters @@ -44,10 +44,10 @@ TVL ceiling is limited to active, sophisticated lenders. Curated vaults solve this by aggregating passive capital and directing it where it earns the best risk-adjusted yield. On Ethereum, the majority of Morpho deposits flow through MetaMorpho vaults rather than -directly into isolated markets. For the Logos ecosystem, vaults -transform the lending protocol from a tool for power users into a -passive yield product accessible to all participants, dramatically -expanding the protocol's addressable market and TVL. +directly into isolated markets. For the Logos ecosystem, vaults make +the lending protocol usable for passive depositors who would not +otherwise interact with raw isolated markets. This widens the +protocol's addressable market. Vaults also create a natural role for risk specialists (curators) who compete on yield and safety. This decentralises risk management: @@ -165,6 +165,15 @@ choose the vault that matches their preference. 6. Submit a [doc packet](https://github.com/logos-co/logos-docs/issues/new?template=doc-packet.yml) for the CLI additions covering the vault features. 7. Provide Figma designs or equivalent for all GUI additions to the mini-app. +8. Update the privacy and anonymisation properties document delivered + by RFP-008 to cover the vault layer: what vault state and operations + are visible to observers; what data is protected when the private + account path is used for vault interactions; trust assumptions, + specifying which guarantees are enforced by the on-chain program and + which depend on correct client behaviour; and what happens if a user + bypasses the expected interaction path. See + [Appendix: Lending Platform Context — Privacy Architecture](../appendix/lending-platform.md#privacy-architecture) + for the baseline this document must align with. #### + Privacy @@ -224,9 +233,8 @@ This RFP is open for proposal submission. However, development is blocked until deployed protocol; it cannot proceed without the base layer. All other platform primitives required by this RFP (including LP-0015 -general cross-program calls, oracle provider, and on-chain clock) are -hard blockers for RFP-008 and will therefore be resolved before this -RFP opens. See +general cross-program calls and an oracle provider) are hard blockers +for RFP-008 and will therefore be resolved before this RFP opens. See [Appendix: Lending Platform Context](../appendix/lending-platform.md#platform-dependencies) for details. diff --git a/appendix/lending-platform.md b/appendix/lending-platform.md index dbe924e..1d05e26 100644 --- a/appendix/lending-platform.md +++ b/appendix/lending-platform.md @@ -7,8 +7,8 @@ status: draft # Lending Protocol Platform Context This appendix covers shared architectural context for the lending -protocol RFPs ([RFP-008](./RFP-008-lending-borrowing-protocol.md) and -[RFP-012](./RFP-012-advanced-lending-features.md)). +protocol RFPs ([RFP-008](../RFPs/RFP-008-lending-borrowing-protocol.md) and +[RFP-012](../RFPs/RFP-012-curated-lending-vaults.md)). ## Privacy Architecture @@ -80,14 +80,6 @@ These must be available on LEZ before any lending RFP can open. No oracle provider is available on LEZ. The lending protocol requires external price feeds for collateral valuation and liquidation triggers. -#### On-chain clock / timestamp - -LEZ does not yet have on-chain block time. Interest accrual (the -core economic mechanic of a lending protocol) requires knowing how -much time has elapsed between interactions. Without a reliable on-chain -timestamp, interest rates, supply APY, and borrow APR cannot be -computed. - #### General cross-program calls (LP-0015) LEZ uses a tail-call execution model rather than Solana's CPI @@ -104,7 +96,7 @@ continuation would need to be a separate externally callable entrypoint, which is fragile and insecure (anyone could call the continuation directly, bypassing the token transfer). -[LP-0015](https://github.com/logos-co/lambda-prize/blob/main/prizes/LP-0015.md) +[LP-0015](https://github.com/logos-co/lambda-prize/blob/master/prizes/LP-0015.md) (General cross-program calls via tail calls) solves this by introducing internal-only entrypoints protected by an unforgeable capability, so the lending program can tail-call the token program and have control @@ -120,7 +112,7 @@ Liquidator bots and indexers need to monitor positions and react to on-chain state changes. Without structured events, off-chain services must poll all accounts, which is expensive and unreliable. -[LP-0012](https://github.com/logos-co/lambda-prize/blob/main/prizes/LP-0012.md) +[LP-0012](https://github.com/logos-co/lambda-prize/blob/master/prizes/LP-0012.md) (Structured events for LEZ program execution) is currently **open**. ### Risks @@ -131,7 +123,12 @@ LEZ currently processes one private transaction per block. Liquidation is the most compute-intensive lending operation: it reads the borrower's position, collateral balance, oracle price, interest indices, and market parameters, then writes updated state. On Solana, -a liquidation can consume 200,000 to 400,000 compute units. If LEZ's -per-transaction compute budget is insufficient, liquidations will fail -and the protocol risks insolvency. This needs benchmarking once the -protocol is under development. +where the per-instruction default is 200,000 compute units and the +per-transaction maximum is 1.4M compute units (see +[Solana compute budget](https://solana.com/docs/core/fees/compute-budget)), +a liquidation typically consumes hundreds of thousands of compute +units; the exact figure for LEZ depends on the implementation and +needs benchmarking [BENCHMARK NEEDED]. If LEZ's per-transaction +compute budget is insufficient, liquidations will fail and the +protocol risks insolvency. This needs benchmarking once the protocol +is under development.