From 095552f8003332d0cc7b7ad9eee25a7fbdc61f9f Mon Sep 17 00:00:00 2001 From: mart1n <20109376+mart1n-xyz@users.noreply.github.com> Date: Fri, 27 Mar 2026 12:06:06 +0100 Subject: [PATCH 01/12] Add RFP-013 reflexive stablecoin and RFP-014 liquidation engine Port draft RFPs from the stablecoin spec split (RAI-style CDP core plus reusable liquidation/auctions). Assign sequential IDs 013/014, cross-link the pair and existing RFP-001/002/008, use relative paths in Resources, and register both in the README Open RFPs table. Made-with: Cursor --- README.md | 2 + RFPs/RFP-013-reflexive-stablecoin-protocol.md | 207 ++++++++++++++++++ RFPs/RFP-014-liquidation-auction-engine.md | 203 +++++++++++++++++ 3 files changed, 412 insertions(+) create mode 100644 RFPs/RFP-013-reflexive-stablecoin-protocol.md create mode 100644 RFPs/RFP-014-liquidation-auction-engine.md diff --git a/README.md b/README.md index b7c560e..eef0f1b 100644 --- a/README.md +++ b/README.md @@ -64,6 +64,8 @@ Click an RFP to view details. Use the Submit Proposal button to apply. | RFP-004 | [Privacy-Preserving DEX](RFPs/RFP-004-privacy-preserving-dex.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 | draft | 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 | draft | Applications & Integrations | [Submit Proposal](https://github.com/logos-co/rfp/issues/new?template=proposal.yml) | +| RFP-013 | [Reflexive Stablecoin Protocol](RFPs/RFP-013-reflexive-stablecoin-protocol.md) | XL | $XXXXX | draft | Applications & Integrations | [Submit Proposal](https://github.com/logos-co/rfp/issues/new?template=proposal.yml) | +| RFP-014 | [Liquidation & Auction Engine](RFPs/RFP-014-liquidation-auction-engine.md) | L | $XXXXX | draft | Applications & Integrations | [Submit Proposal](https://github.com/logos-co/rfp/issues/new?template=proposal.yml) | ## Terms & Conditions diff --git a/RFPs/RFP-013-reflexive-stablecoin-protocol.md b/RFPs/RFP-013-reflexive-stablecoin-protocol.md new file mode 100644 index 0000000..87824bb --- /dev/null +++ b/RFPs/RFP-013-reflexive-stablecoin-protocol.md @@ -0,0 +1,207 @@ +--- +id: RFP-013 +title: Reflexive Stablecoin Protocol +tier: XL +funding: $XXXXX +status: draft +dependencies: RFP-001 (Admin Authority), RFP-002 (Freeze Authority) +category: Applications & Integrations +--- + +# RFP-013 — Reflexive Stablecoin Protocol + +## Overview + +Build a non-pegged, reflexive stablecoin protocol for the Logos Execution Zone (LEZ). The stablecoin is backed by a reference token collateral and uses an autonomous feedback controller to adjust a floating redemption price, incentivizing market participants to stabilize the token without requiring active governance intervention. + +This design — pioneered by [RAI / Reflexer Finance](https://reflexer.finance/) — produces a stablecoin that trades governance for mathematics: the system self-corrects via economic incentives rather than policy decisions. Users lock collateral and mint stablecoins against it. The protocol continuously adjusts a redemption rate based on the deviation between market price and redemption price. When market price exceeds redemption price, the rate goes negative, causing redemption price to drift down and reducing demand. When market price is below redemption price, the rate goes positive, causing redemption price to drift up and increasing demand. This creates a self-stabilizing feedback loop. + +The protocol follows the RAI design with these key components: collateralized debt positions (SAFEs) that track collateral, normalized debt, and accumulated rates; a redemption price that drifts based on a computed redemption rate; stability fees that accrue continuously via rate accumulation; and a feedback loop that stabilizes the token mathematically rather than through governance intervention. + +## Why This Matters + +The Logos ecosystem needs a credibly neutral settlement asset that reduces trust assumptions. Traditional stablecoins are either centralized (USDC), governance-heavy (DAI), or under-collateralized and fragile (failed algorithmic coins). This protocol provides a fourth option: reflexive, non-pegged, and over-collateralized. + +Stablecoins enable lending, trading, and payments without the volatility of native assets. For the private economy, this offers a stable unit of account without requiring users to trust an issuer or governance body. Other protocols can build on this stable asset as a risk-off collateral asset, establishing a foundation for DeFi activity on LEZ. + +## Scope of Work + +### Hard Requirements + +#### Functionality + +1. Users can lock reference token collateral and generate stablecoin debt against it. All positions must maintain a minimum collateralization ratio. Users can add or remove collateral and repay debt subject to safety constraints. + +2. The protocol computes a redemption rate from the deviation between market price and redemption price using a feedback controller. The redemption price drifts continuously based on this rate. Rate updates occur at bounded intervals with permissionless triggers. + +3. Debt accrues interest continuously via a stability fee mechanism. The fee rate is governance-adjustable but applies uniformly to all positions. + +4. Positions cannot be modified in ways that would push their collateralization ratio below the liquidation threshold. Read-only queries are always permitted. + +5. The stablecoin must be a standard fungible token on LEZ, transferable and composable with other protocols. The protocol handles minting and burning via integration with the LEZ Token Program. + +6. The protocol reads market prices from a configurable price feed. The interface requires price data with staleness detection; the specific implementation is flexible. + +#### Usability + +1. Build the program using the SPEL framework, which generates the IDL and client code from the program definition. + +2. Provide a Logos mini-app GUI with local build instructions, downloadable assets, and loadable in Logos app (Basecamp) via git repo. + +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. Users can view current collateralization ratio, minimum safe ratio, and projected outcomes of operations before executing them. + +5. Users can view current redemption rate, redemption price, and projected debt growth from stability fees. + +6. The SDK supports both public account operations and private account operations via the standard deshield-interact-reshield pattern. + +7. Failed operations return clear, actionable error messages indicating why the operation was rejected. + +#### Reliability + +1. All financial calculations use sufficient precision to prevent overflow. Critical invariants include: total stablecoin minted equals sum of all position debts; collateralization ratios are enforced after every modifying operation. + +2. The feedback controller must include safeguards against integral windup and rate explosion. + +3. If the price feed is stale or unavailable, rate updates are paused. Existing positions remain operational but new debt generation may be restricted. + +4. Parameter updates (stability fee, controller gains, safety ratios) are gated through admin authority. Emergency circuit breaker functionality is available via freeze authority. + +#### Performance + +1. Position operations and rate updates must fit within LEZ transaction compute limits with headroom for network conditions. + +2. The protocol supports thousands of concurrent positions without exceeding compute limits on any operation. + +3. Rate updates complete within a small number of blocks. Position operations complete within one block. + +#### Supportability + +1. The 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. + +3. CI must be green on the default branch. + +4. Every hard requirement in Functionality, Usability, Reliability, and Performance has at least one corresponding test. + +5. A README documents end-to-end usage: deployment steps, program addresses, and step-by-step instructions for interacting with the program via CLI and 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. When a user chooses the private account path, the SDK must enforce the complete pattern — the reshield step must not be skippable. + +2. When using the private account path, the SDK must validate that the target account for reshielding is a private (shielded) account before submitting the transaction, and reject the operation with an explicit error if it is not. + +3. The ephemeral public account 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. + +### Soft Requirements + +If possible. + +#### Reliability + +1. Multi-oracle redundancy for price feeds, with fallback when primary is stale. + +2. Formal verification of critical invariants: a position with collateralization ratio above the minimum cannot be liquidated; total stablecoin supply equals total debt across all positions. + +#### Usability + +1. Health factor preview showing before/after state for operations. + +2. Historical data display: redemption price, market price, and redemption rate over time. + +### Out of Scope + +The following are explicitly excluded from this RFP. + +- Liquidation mechanism — addressed by [RFP-014](./RFP-014-liquidation-auction-engine.md) +- Surplus/debt management auctions — addressed by [RFP-014](./RFP-014-liquidation-auction-engine.md) +- Multi-collateral positions +- Private state positions (privacy via UX layer only) +- Governance token design + +### Privacy Architecture + +All position state lives in public (on-chain) state. This is a deliberate architectural choice: public state enables permissionless liquidation, price feed 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 (lock collateral, mint, repay, withdraw): + +1. The user initiates the action from their private account. The SDK deshields to a fresh, single-use public account 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. The ephemeral account executes the protocol operation. +3. The ephemeral account shields any outputs back to the user's private account. The account is never reused. + +#### What is public (observable on-chain) + +- All position state: collateral amounts, debt amounts, collateralization ratios. +- All protocol operations and their amounts. +- Price feeds and rate update events. + +#### What is private + +- Which private account funded any operation. +- Where withdrawn assets go after reshielding. +- Any link between multiple protocol interactions by the same user (no on-chain linkability across ephemeral accounts). + +## Platform Dependencies + +### Hard blockers + +These must be available on LEZ before this RFP can open. + +#### Price feed + +The protocol requires external price feeds for market price and redemption rate computation. Every hard requirement related to rate adjustment (F2) and reliability (R3) depends on this. + +#### On-chain clock / timestamp + +Rate computation and stability fee accrual require knowing how much time has elapsed between interactions. Without a reliable on-chain timestamp, these cannot be computed. + +### Soft blockers + +Desirable but the RFP can open without them. + +#### Event emission + +Off-chain services need to monitor positions and rate updates. Without structured events, services must poll all accounts, which is expensive. + +## Recommended Team Profile + +Team experienced with: + +- DeFi protocol design (CDP systems, RAI/Reflexer patterns) +- Solana or SVM program development +- Fixed-point arithmetic and numerical methods +- Interest rate modelling and control theory +- Oracle integration and price feed security +- Writing and running on-chain tests +- Front-end development for DeFi applications + +## Timeline Expectations + +Estimated duration: **14–18 weeks** + +## Open Source Requirement + +All code must be released under the **MIT+Apache2.0 dual License**. + +## Resources + +- [RAI Whitepaper](https://github.com/reflexer-labs/whitepapers/blob/master/English/rai-english.pdf) +- [RFP-001 — Admin Authority](./RFP-001-admin-authority-poc.md) +- [RFP-002 — Freeze Authority](./RFP-002-freeze-authority-poc.md) +- [RFP-008 — Lending & Borrowing](./RFP-008-lending-borrowing-protocol.md) +- [RFP-014 — Liquidation & Auction Engine](./RFP-014-liquidation-auction-engine.md) + +## How to Apply + +👉 Submit a proposal using the Issue form: + +**[Submit Proposal](https://github.com/logos-co/rfp/issues/new?template=proposal.yml)** + +We typically respond within **14 days**. For clarification questions, please use **Discussions**. diff --git a/RFPs/RFP-014-liquidation-auction-engine.md b/RFPs/RFP-014-liquidation-auction-engine.md new file mode 100644 index 0000000..380e1dc --- /dev/null +++ b/RFPs/RFP-014-liquidation-auction-engine.md @@ -0,0 +1,203 @@ +--- +id: RFP-014 +title: Liquidation & Auction Engine +tier: L +funding: $XXXXX +status: draft +dependencies: RFP-001 (Admin Authority), RFP-002 (Freeze Authority), RFP-013 (Reflexive Stablecoin Protocol or equivalent CDP host) +category: Applications & Integrations +--- + +# RFP-014 — Liquidation & Auction Engine + +## Overview + +Build a permissionless liquidation and auction system for collateralized debt position (CDP) protocols on the Logos Execution Zone (LEZ). This system is designed as a reusable program that each CDP product can deploy as its own instance. It detects undercollateralized positions, seizes collateral, and sells it via auctions to cover debt. It also manages protocol surplus and debt through separate auction mechanisms. + +The design follows proven patterns from [RAI / Reflexer Finance](https://reflexer.finance/): a fixed-discount auction for seized collateral that incentivizes quick liquidation while minimizing protocol losses, plus surplus and debt auction houses for system-level balance management. When a position becomes undercollateralized, the system seizes its collateral and begins an auction where the discount to market price increases over time until the target amount is raised. Surplus from liquidation penalties and stability fees is auctioned for the reference token and burned. Shortfalls from insufficient collateral auctions are covered by minting the reference token and auctioning for stablecoins. + +## Why This Matters + +CDP protocols require liquidation to remain solvent. Without it, bad debt accumulates, threatening protocol solvency and user confidence. For the Logos ecosystem, a well-designed liquidation system protects solvency by closing positions before they become underwater, minimizes losses via efficient price discovery, and handles system imbalances via surplus and debt auctions. + +Building this as a reusable program has ecosystem-wide benefits. Each CDP product can deploy its own instance of the same battle-tested liquidation code rather than rebuilding from scratch. This includes the reflexive stablecoin ([RFP-013](./RFP-013-reflexive-stablecoin-protocol.md)), future lending protocols, or Maker-style multi-collateral systems. Reusing the same codebase means shared security audits, shared liquidator bot logic, and faster time-to-market for new CDP products. Each instance is configured for its specific product while inheriting the proven auction mechanisms and safety guarantees. + +## Scope of Work + +### Hard Requirements + +#### Functionality + +1. Anyone can trigger liquidation on any undercollateralized position. No whitelist or special permissions required. The liquidator receives an incentive (e.g., a percentage of seized collateral). + +2. Seized collateral is sold via auctions where the discount to market price increases over time. The discount schedule must be configurable. Auctions terminate early when the target amount is reached. + +3. Auctions support buying partial collateral lots, preventing large positions from becoming stuck. + +4. When collateral auctions don't raise enough to cover debt plus penalty, the shortfall is handled via a separate debt auction mechanism that restores system balance. + +5. When the protocol accumulates excess stablecoin above a threshold, surplus auctions sell it for the reference token (which is burned). + +6. Auctions follow strict state transitions with no reversals. All state changes are atomic and verifiable. + +7. The system integrates with its host CDP protocol via a well-defined interface. Each product deploys its own configured instance of the program. + +#### Usability + +1. Build the program using the SPEL framework, which generates the IDL and client code from the program definition. + +2. Provide a Logos mini-app GUI with local build instructions, downloadable assets, and loadable in Logos app (Basecamp) via git repo. + +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. Tools display undercollateralized positions with estimated liquidator incentives, enabling efficient bot operation. + +5. Active auctions display collateral type, amount, current discount, raised amount vs target, and time remaining. Users can bid with clear previews of received collateral and costs. + +6. SDK supports private account operations via the deshield-interact-reshield pattern. + +#### Reliability + +1. Auction operations are non-reentrant. State transitions are ordered to prevent manipulation. + +2. Liquidation uses time-weighted or confidence-adjusted prices, not raw spot. If price feeds are stale, liquidations pause for that collateral type. + +3. Multiple liquidations and auctions can occur simultaneously without interference. Each auction maintains isolated state. + +4. If a price feed fails for one collateral type, only that type's liquidations pause. Other operations continue unaffected. + +5. Critical invariants: seized collateral equals collateral in auction; debt shortfalls are properly accounted; surplus and debt auctions maintain system balance. + +#### Performance + +1. Liquidation transactions complete within one block. + +2. The system supports many concurrent auctions without exceeding compute limits. + +3. Bid transactions complete within one block. + +#### Supportability + +1. The 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. + +3. CI must be green on the default branch. + +4. Every hard requirement in Functionality, Usability, Reliability, and Performance has at least one corresponding test. + +5. A README documents end-to-end usage: deployment steps, program addresses, and step-by-step instructions for interacting with the program via CLI and 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. When a user chooses the private account path, the SDK must enforce the complete pattern — the reshield step must not be skippable. + +2. When using the private account path, the SDK must validate that the target account for reshielding is a private (shielded) account before submitting the transaction, and reject the operation with an explicit error if it is not. + +3. The ephemeral public account 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. + +### Soft Requirements + +If possible. + +#### Reliability + +1. Multi-oracle redundancy for price feeds, with fallback when primary is stale. + +2. Formal verification of auction invariants: collateral seized equals collateral in auction; debt shortfalls are correctly propagated to debt auction house. + +#### Usability + +1. Liquidator bot SDK with position monitoring and automated liquidation triggers. + +### Out of Scope + +The following are explicitly excluded from this RFP. + +- Flash loan liquidations +- Liquidation aggregators (batching across multiple positions) +- Insurance funds or socialized loss mechanisms +- Multi-collateral atomic liquidations + +### Privacy Architecture + +All auction and liquidation state lives in public (on-chain) state. This is a deliberate architectural choice: public state enables permissionless liquidation, price feed integration, and composability. + +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 (liquidate, bid, settle): + +1. The user initiates the action from their private account. The SDK deshields to a fresh, single-use public account 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. The ephemeral account executes the protocol operation. +3. The ephemeral account shields any outputs back to the user's private account. The account is never reused. + +#### What is public (observable on-chain) + +- All auction state: collateral amounts, bids, settlement status. +- All liquidation events and their amounts. +- Price feeds and position health data. + +#### What is private + +- Which private account initiated any liquidation or bid. +- Where auction proceeds go after reshielding. +- Any link between multiple protocol interactions by the same user (no on-chain linkability across ephemeral accounts). + +## Platform Dependencies + +### Hard blockers + +These must be available on LEZ before this RFP can open. + +#### Price feed + +The system requires external price feeds for collateral valuation and liquidation triggers. Every hard requirement related to liquidation (F1) and reliability (R2) depends on this. + +#### CDP Protocol + +This liquidation system is designed to integrate with a host CDP protocol that provides positions to liquidate. It is typically deployed alongside [RFP-013](./RFP-013-reflexive-stablecoin-protocol.md) or equivalent. + +### Soft blockers + +Desirable but the RFP can open without them. + +#### Event emission + +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. + +## Recommended Team Profile + +Team experienced with: + +- DeFi protocol design (liquidation systems, auction mechanisms) +- Solana or SVM program development +- Auction theory and mechanism design +- Oracle integration and price feed security +- Writing and running on-chain tests +- Front-end development for DeFi applications + +## Timeline Expectations + +Estimated duration: **10–12 weeks** + +## Open Source Requirement + +All code must be released under the **MIT+Apache2.0 dual License**. + +## Resources + +- [RAI / GEB Code](https://github.com/reflexer-labs/geb) +- [RFP-001 — Admin Authority](./RFP-001-admin-authority-poc.md) +- [RFP-002 — Freeze Authority](./RFP-002-freeze-authority-poc.md) +- [RFP-008 — Lending & Borrowing](./RFP-008-lending-borrowing-protocol.md) +- [RFP-013 — Reflexive Stablecoin Protocol](./RFP-013-reflexive-stablecoin-protocol.md) + +## How to Apply + +👉 Submit a proposal using the Issue form: + +**[Submit Proposal](https://github.com/logos-co/rfp/issues/new?template=proposal.yml)** + +We typically respond within **14 days**. For clarification questions, please use **Discussions**. From 4d1f2479463296671e3a15088cb9059708512e00 Mon Sep 17 00:00:00 2001 From: "mart1:n" <20109376+mart1n-xyz@users.noreply.github.com> Date: Wed, 1 Apr 2026 12:20:05 +0200 Subject: [PATCH 02/12] Update RFPs/RFP-013-reflexive-stablecoin-protocol.md SDK Co-authored-by: fryorcraken <110212804+fryorcraken@users.noreply.github.com> --- RFPs/RFP-013-reflexive-stablecoin-protocol.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/RFPs/RFP-013-reflexive-stablecoin-protocol.md b/RFPs/RFP-013-reflexive-stablecoin-protocol.md index 87824bb..af0a47e 100644 --- a/RFPs/RFP-013-reflexive-stablecoin-protocol.md +++ b/RFPs/RFP-013-reflexive-stablecoin-protocol.md @@ -54,7 +54,7 @@ Stablecoins enable lending, trading, and payments without the volatility of nati 5. Users can view current redemption rate, redemption price, and projected debt growth from stability fees. -6. The SDK supports both public account operations and private account operations via the standard deshield-interact-reshield pattern. +6. Provide an SDK that can be used to build Logos modules for interacting with the program. The SDK must support both public account operations and private account operations via the standard deshield-interact-reshield pattern. 7. Failed operations return clear, actionable error messages indicating why the operation was rejected. From 36baa6edfe7f9d80725236c3d1f6c05f427920dc Mon Sep 17 00:00:00 2001 From: "mart1:n" <20109376+mart1n-xyz@users.noreply.github.com> Date: Wed, 1 Apr 2026 12:20:28 +0200 Subject: [PATCH 03/12] Update RFPs/RFP-014-liquidation-auction-engine.md SDK Co-authored-by: fryorcraken <110212804+fryorcraken@users.noreply.github.com> --- RFPs/RFP-014-liquidation-auction-engine.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/RFPs/RFP-014-liquidation-auction-engine.md b/RFPs/RFP-014-liquidation-auction-engine.md index 380e1dc..2c355d7 100644 --- a/RFPs/RFP-014-liquidation-auction-engine.md +++ b/RFPs/RFP-014-liquidation-auction-engine.md @@ -54,7 +54,7 @@ Building this as a reusable program has ecosystem-wide benefits. Each CDP produc 5. Active auctions display collateral type, amount, current discount, raised amount vs target, and time remaining. Users can bid with clear previews of received collateral and costs. -6. SDK supports private account operations via the deshield-interact-reshield pattern. +6. Provide an SDK that can be used to build Logos modules for interacting with the program. The SDK must support private account operations via the deshield-interact-reshield pattern. #### Reliability From 003e320edbee90faeeabdc9e5098b0a8e94b6ba7 Mon Sep 17 00:00:00 2001 From: "mart1:n" <20109376+mart1n-xyz@users.noreply.github.com> Date: Wed, 1 Apr 2026 12:23:31 +0200 Subject: [PATCH 04/12] Update RFPs/RFP-014-liquidation-auction-engine.md Co-authored-by: fryorcraken <110212804+fryorcraken@users.noreply.github.com> --- RFPs/RFP-014-liquidation-auction-engine.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/RFPs/RFP-014-liquidation-auction-engine.md b/RFPs/RFP-014-liquidation-auction-engine.md index 2c355d7..102dffd 100644 --- a/RFPs/RFP-014-liquidation-auction-engine.md +++ b/RFPs/RFP-014-liquidation-auction-engine.md @@ -80,7 +80,7 @@ Building this as a reusable program has ecosystem-wide benefits. Each CDP produc 1. The 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. +2. End-to-end integration tests run against a LEZ sequencer (standalone mode) with `RISC0_DEV_MODE=0` and are included in CI. 3. CI must be green on the default branch. From 5d5c0e372e84f55250d5f04f9c5bf2410717b257 Mon Sep 17 00:00:00 2001 From: "mart1:n" <20109376+mart1n-xyz@users.noreply.github.com> Date: Wed, 1 Apr 2026 12:23:47 +0200 Subject: [PATCH 05/12] Update RFPs/RFP-013-reflexive-stablecoin-protocol.md Co-authored-by: fryorcraken <110212804+fryorcraken@users.noreply.github.com> --- RFPs/RFP-013-reflexive-stablecoin-protocol.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/RFPs/RFP-013-reflexive-stablecoin-protocol.md b/RFPs/RFP-013-reflexive-stablecoin-protocol.md index af0a47e..7f9ffdb 100644 --- a/RFPs/RFP-013-reflexive-stablecoin-protocol.md +++ b/RFPs/RFP-013-reflexive-stablecoin-protocol.md @@ -80,7 +80,7 @@ Stablecoins enable lending, trading, and payments without the volatility of nati 1. The 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. +2. End-to-end integration tests run against a LEZ sequencer (standalone mode) with `RISC0_DEV_MODE=0` and are included in CI. 3. CI must be green on the default branch. From 341a0aafa2db67ab192725cbebb81a1167d1aaed Mon Sep 17 00:00:00 2001 From: "mart1:n" <20109376+mart1n-xyz@users.noreply.github.com> Date: Wed, 1 Apr 2026 12:24:02 +0200 Subject: [PATCH 06/12] Update RFPs/RFP-014-liquidation-auction-engine.md Co-authored-by: fryorcraken <110212804+fryorcraken@users.noreply.github.com> --- RFPs/RFP-014-liquidation-auction-engine.md | 6 ++++-- 1 file changed, 4 insertions(+), 2 deletions(-) diff --git a/RFPs/RFP-014-liquidation-auction-engine.md b/RFPs/RFP-014-liquidation-auction-engine.md index 102dffd..a2cbe11 100644 --- a/RFPs/RFP-014-liquidation-auction-engine.md +++ b/RFPs/RFP-014-liquidation-auction-engine.md @@ -64,9 +64,11 @@ Building this as a reusable program has ecosystem-wide benefits. Each CDP produc 3. Multiple liquidations and auctions can occur simultaneously without interference. Each auction maintains isolated state. -4. If a price feed fails for one collateral type, only that type's liquidations pause. Other operations continue unaffected. +4. If a price feed fails for one collateral type, only that type's liquidations pause. -5. Critical invariants: seized collateral equals collateral in auction; debt shortfalls are properly accounted; surplus and debt auctions maintain system balance. +5. Other collateral types and non-liquidation operations continue unaffected. + +6. Critical invariants: seized collateral equals collateral in auction; debt shortfalls are properly accounted; surplus and debt auctions maintain system balance. #### Performance From 834e141057a43590e37b79e3bba79397164c61c0 Mon Sep 17 00:00:00 2001 From: "mart1:n" <20109376+mart1n-xyz@users.noreply.github.com> Date: Wed, 1 Apr 2026 12:24:12 +0200 Subject: [PATCH 07/12] Update RFPs/RFP-013-reflexive-stablecoin-protocol.md Co-authored-by: fryorcraken <110212804+fryorcraken@users.noreply.github.com> --- RFPs/RFP-013-reflexive-stablecoin-protocol.md | 4 +++- 1 file changed, 3 insertions(+), 1 deletion(-) diff --git a/RFPs/RFP-013-reflexive-stablecoin-protocol.md b/RFPs/RFP-013-reflexive-stablecoin-protocol.md index 7f9ffdb..e4b5fca 100644 --- a/RFPs/RFP-013-reflexive-stablecoin-protocol.md +++ b/RFPs/RFP-013-reflexive-stablecoin-protocol.md @@ -66,7 +66,9 @@ Stablecoins enable lending, trading, and payments without the volatility of nati 3. If the price feed is stale or unavailable, rate updates are paused. Existing positions remain operational but new debt generation may be restricted. -4. Parameter updates (stability fee, controller gains, safety ratios) are gated through admin authority. Emergency circuit breaker functionality is available via freeze authority. +4. Parameter updates (stability fee, controller gains, safety ratios) are gated through admin authority. + +5. Emergency circuit breaker functionality is available via freeze authority. #### Performance From db7dc89ba5afa6eb3152193b46bd595fb89eecc3 Mon Sep 17 00:00:00 2001 From: mart1n <20109376+mart1n-xyz@users.noreply.github.com> Date: Wed, 8 Apr 2026 12:09:33 +0200 Subject: [PATCH 08/12] Add ecosystem appendices for RFP-013 and RFP-014 Add appendix/appendix-reflexive-stablecoin-ecosystem.md and appendix/appendix-liquidation-auction-ecosystem.md with ecosystem surveys and design rationale. Reference them from the corresponding RFPs in overview and Resources sections. Made-with: Cursor --- RFPs/RFP-013-reflexive-stablecoin-protocol.md | 3 +- RFPs/RFP-014-liquidation-auction-engine.md | 3 +- .../appendix-liquidation-auction-ecosystem.md | 345 ++++++++++++++++++ ...appendix-reflexive-stablecoin-ecosystem.md | 178 +++++++++ 4 files changed, 527 insertions(+), 2 deletions(-) create mode 100644 appendix/appendix-liquidation-auction-ecosystem.md create mode 100644 appendix/appendix-reflexive-stablecoin-ecosystem.md diff --git a/RFPs/RFP-013-reflexive-stablecoin-protocol.md b/RFPs/RFP-013-reflexive-stablecoin-protocol.md index e4b5fca..7a647db 100644 --- a/RFPs/RFP-013-reflexive-stablecoin-protocol.md +++ b/RFPs/RFP-013-reflexive-stablecoin-protocol.md @@ -14,7 +14,7 @@ category: Applications & Integrations Build a non-pegged, reflexive stablecoin protocol for the Logos Execution Zone (LEZ). The stablecoin is backed by a reference token collateral and uses an autonomous feedback controller to adjust a floating redemption price, incentivizing market participants to stabilize the token without requiring active governance intervention. -This design — pioneered by [RAI / Reflexer Finance](https://reflexer.finance/) — produces a stablecoin that trades governance for mathematics: the system self-corrects via economic incentives rather than policy decisions. Users lock collateral and mint stablecoins against it. The protocol continuously adjusts a redemption rate based on the deviation between market price and redemption price. When market price exceeds redemption price, the rate goes negative, causing redemption price to drift down and reducing demand. When market price is below redemption price, the rate goes positive, causing redemption price to drift up and increasing demand. This creates a self-stabilizing feedback loop. +This design — pioneered by [RAI / Reflexer Finance](https://reflexer.finance/) — produces a stablecoin that trades governance for mathematics: the system self-corrects via economic incentives rather than policy decisions. For a survey of the stablecoin ecosystem and the design rationale behind this approach, see the [companion appendix](../appendix/appendix-reflexive-stablecoin-ecosystem.md). Users lock collateral and mint stablecoins against it. The protocol continuously adjusts a redemption rate based on the deviation between market price and redemption price. When market price exceeds redemption price, the rate goes negative, causing redemption price to drift down and reducing demand. When market price is below redemption price, the rate goes positive, causing redemption price to drift up and increasing demand. This creates a self-stabilizing feedback loop. The protocol follows the RAI design with these key components: collateralized debt positions (SAFEs) that track collateral, normalized debt, and accumulated rates; a redemption price that drifts based on a computed redemption rate; stability fees that accrue continuously via rate accumulation; and a feedback loop that stabilizes the token mathematically rather than through governance intervention. @@ -199,6 +199,7 @@ All code must be released under the **MIT+Apache2.0 dual License**. - [RFP-002 — Freeze Authority](./RFP-002-freeze-authority-poc.md) - [RFP-008 — Lending & Borrowing](./RFP-008-lending-borrowing-protocol.md) - [RFP-014 — Liquidation & Auction Engine](./RFP-014-liquidation-auction-engine.md) +- [Appendix: Reflexive Stablecoin Ecosystem](../appendix/appendix-reflexive-stablecoin-ecosystem.md) ## How to Apply diff --git a/RFPs/RFP-014-liquidation-auction-engine.md b/RFPs/RFP-014-liquidation-auction-engine.md index a2cbe11..67a7abf 100644 --- a/RFPs/RFP-014-liquidation-auction-engine.md +++ b/RFPs/RFP-014-liquidation-auction-engine.md @@ -14,7 +14,7 @@ category: Applications & Integrations Build a permissionless liquidation and auction system for collateralized debt position (CDP) protocols on the Logos Execution Zone (LEZ). This system is designed as a reusable program that each CDP product can deploy as its own instance. It detects undercollateralized positions, seizes collateral, and sells it via auctions to cover debt. It also manages protocol surplus and debt through separate auction mechanisms. -The design follows proven patterns from [RAI / Reflexer Finance](https://reflexer.finance/): a fixed-discount auction for seized collateral that incentivizes quick liquidation while minimizing protocol losses, plus surplus and debt auction houses for system-level balance management. When a position becomes undercollateralized, the system seizes its collateral and begins an auction where the discount to market price increases over time until the target amount is raised. Surplus from liquidation penalties and stability fees is auctioned for the reference token and burned. Shortfalls from insufficient collateral auctions are covered by minting the reference token and auctioning for stablecoins. +The design follows proven patterns from [RAI / Reflexer Finance](https://reflexer.finance/): a fixed-discount auction for seized collateral that incentivizes quick liquidation while minimizing protocol losses, plus surplus and debt auction houses for system-level balance management. For a survey of liquidation mechanisms and the design rationale behind this approach, see the [companion appendix](../appendix/appendix-liquidation-auction-ecosystem.md). When a position becomes undercollateralized, the system seizes its collateral and begins an auction where the discount to market price increases over time until the target amount is raised. Surplus from liquidation penalties and stability fees is auctioned for the reference token and burned. Shortfalls from insufficient collateral auctions are covered by minting the reference token and auctioning for stablecoins. ## Why This Matters @@ -195,6 +195,7 @@ All code must be released under the **MIT+Apache2.0 dual License**. - [RFP-002 — Freeze Authority](./RFP-002-freeze-authority-poc.md) - [RFP-008 — Lending & Borrowing](./RFP-008-lending-borrowing-protocol.md) - [RFP-013 — Reflexive Stablecoin Protocol](./RFP-013-reflexive-stablecoin-protocol.md) +- [Appendix: Liquidation & Auction Ecosystem](../appendix/appendix-liquidation-auction-ecosystem.md) ## How to Apply diff --git a/appendix/appendix-liquidation-auction-ecosystem.md b/appendix/appendix-liquidation-auction-ecosystem.md new file mode 100644 index 0000000..c323354 --- /dev/null +++ b/appendix/appendix-liquidation-auction-ecosystem.md @@ -0,0 +1,345 @@ +# Appendix: Liquidation & Auction Ecosystem + +This appendix surveys existing liquidation mechanisms and auction systems across the DeFi ecosystem. It serves as a reference for [RFP-014: Liquidation & Auction Engine](../RFPs/RFP-014-liquidation-auction-engine.md), providing context on design evolution, trade-offs between mechanisms, and why an increasing-discount auction model was selected as a reusable engine pattern. + +While liquidation systems are typically tightly coupled to their host CDP protocols, RFP-014 proposes a **reusable liquidation program** that any CDP product can deploy as its own instance. This appendix examines the evolution of liquidation mechanisms (particularly MakerDAO's progression and Reflexer's discount-based approach), alternative mechanisms excluded from scope, and the architectural rationale for decoupling liquidation from CDP logic. + +## Liquidation Mechanisms Surveyed + +| Protocol | Auction Type | Speed | Incentive Model | Reusability | +|----------|--------------|-------|-----------------|-------------| +| Reflexer (RAI) | Increasing discount | Fast (seconds-minutes) | Escalating keeper discount | Coupled to RAI | +| Sky/MakerDAO V1 | English auction | Slow (hours) | Bid competition | Coupled to Maker | +| Sky/MakerDAO V2+ (Liq 2.0) | Dutch auction | Medium (minutes) | Descending price, flash-loan composable | Coupled to Maker | +| Aave/Compound | Direct liquidation | Instant (atomic) | Bonus % of collateral | Coupled per protocol | +| Liquity V1 | Stability Pool absorption | Instant | SP depositors receive discounted collateral | Unique to Liquity | +| Liquity V2 | Stability Pool absorption | Instant | SP earns 75% of interest + liquidation gains | Unique to Liquity | +| crvUSD (LLAMMA) | Soft liquidation via AMM | Continuous | Gradual conversion, reversible | Coupled to Curve | + +## Liquidation Mechanism Evolution + +### Sky/MakerDAO: The Evolution from English to Dutch + +MakerDAO's (now Sky) liquidation mechanism has evolved across versions, demonstrating the trade-offs in auction design: + +**Liquidation 1.2: English Auctions (Ascending Price)** +- Collateral seized when position undercollateralized via `bite` transaction +- Two-phase English auction: first phase (`tend`) raises DAI bids for fixed collateral lots; second phase (`dent`) returns excess collateral while maintaining the DAI bid +- **Problem:** Slow. Auctions could take hours, with bidder capital locked until outbid or auction settlement +- Exposed to network congestion risk: during MakerDAO's ["Black Thursday" event (March 2020)](https://blog.makerdao.com/the-market-collapse-of-march-12-2020-how-it-impacted-makerdao/), gas prices spiked and liquidations cleared at near-zero bids, creating ~$6M in bad debt + +**Liquidation 2.0: Dutch Auctions (Descending Price) - [MIP 45](https://forum.makerdao.com/t/mip45-liquidations-2-0-liq-2-0-liquidation-system-redesign/6352)** +- Collateral offered via `Clipper` contracts at a high starting price that decreases deterministically over time according to a configurable price-vs-time curve (linear, stepwise exponential, or continuous exponential) +- First bidder to accept price wins via `take` function; partial bids permitted +- **Key improvement:** Single-block composability - bidders can use flash loans to purchase collateral atomically with zero capital requirement, leveraging all on-chain DAI liquidity +- Keeper incentive: flat DAI tip plus percentage-based chip proportional to vault debt size +- Per-collateral circuit breakers limit total DAI being raised simultaneously + +**Why Liq 2.0 matters for RFP-014:** The move from English to Dutch eliminated capital lockup and enabled flash-loan participation. However, Dutch auctions still require time for price discovery (the price must descend to a level bidders accept). RFP-014's discount-based approach trades price discovery for speed: the discount is known immediately, removing the waiting period. + +### Reflexer (RAI): Discount-Based Auctions + +Reflexer's GEB framework implements [three collateral auction types](https://docs.reflexer.finance/system-contracts/auction-module), each representing a different point in the speed vs. price-discovery tradeoff: + +**1. English Collateral Auction House** - Two-phase ascending auction similar to MakerDAO Liq 1.2. Included for compatibility but not used in RAI production due to speed limitations. + +**2. Fixed Discount Collateral Auction House** - Collateral sold at a constant discount to the current oracle price throughout the auction's lifetime. Bidders call `buyCollateral`, submitting RAI and receiving collateral at the fixed discount. No price discovery - the discount is set at auction creation and never changes. + +**3. [Increasing Discount Collateral Auction House](https://docs.reflexer.finance/system-contracts/auction-module/increasing-discount-collateral-auction-house)** - Starts with a small discount (`minDiscount`) that grows over time at `perSecondDiscountUpdateRate` up to `maxDiscount`. This is the variant RAI used in production. It combines speed (early bidders get collateral quickly at a small discount) with resilience (if no one bids early, the growing discount eventually attracts bidders). + +**In all discount variants:** +- Bidders submit RAI, and the contract calculates collateral to return based on the current discount, the collateral's oracle price, and the system coin's redemption price +- Multiple bidders can purchase from the same auction (partial fills) +- Flash-loan compatible: bidders can atomically buy collateral and sell on DEX +- No capital lockup period +- Liquidation penalty of 12% provides keeper incentive margin + +**Why increasing discount for RFP-014:** The increasing discount model gives the best balance for a new ecosystem: it creates immediate opportunity for early keepers (small discount) while guaranteeing auction completion even in thin markets (discount escalates). This is more forgiving than a fixed discount (which may be set too low for thin markets or too high, giving away value) and faster than Dutch auctions (no descending price curve to wait through). + +## Alternative Mechanisms (Out of Scope) + +### Direct Liquidation with Bonus (Aave, Compound) + +**Mechanism:** +- Liquidator repays a portion of the borrower's debt (up to a close factor, e.g. 50%) +- Receives borrower's collateral at a bonus (e.g. 5-10% above debt value) +- Can be composed with flash loans: borrow → repay debt → seize collateral → sell collateral → repay flash loan, all atomically + +**Advantages:** +- Instant, single-transaction settlement +- No auction state to manage +- With flash loans, zero capital requirement for liquidators + +**Why not selected for RFP-014:** +- Requires deep on-chain liquidity for flash loans to be profitable +- Fixed bonus doesn't adapt to market conditions (thin markets may need higher incentive) +- No price discovery: bonus is governance-set, not market-determined +- Tightly coupled to lending protocol account structure +- LEZ liquidity landscape uncertain at this stage + +### Stability Pool Liquidation (Liquity) + +Liquity's liquidation has three distinct layers: + +**1. Trigger (keepers):** External keepers monitor Trove collateralization ratios and call `liquidateTroves()` when positions fall below 110% CR. Keepers receive gas compensation (200 LUSD + 0.5% of the liquidated Trove's collateral) for triggering. This is a conventional keeper role identical in function to MakerDAO or Reflexer keepers - someone must detect undercollateralization and initiate the process. + +**2. Resolution - primary (Stability Pool):** LUSD/BOLD depositors in the Stability Pool act as pre-committed liquidation counterparties. When a liquidation is triggered, the SP's LUSD is burned to cover the Trove's debt, and SP depositors receive the Trove's ETH collateral pro-rata. The spread between the Trove's debt value and its collateral value (at 110% CR, this is roughly a 10% gain) is the SP depositor's reward. Settlement is instant - no auction, no bidding, no waiting. + +**3. Resolution - fallback (redistribution):** If the Stability Pool has insufficient LUSD to absorb the debt, the remaining debt and collateral are redistributed across all active Troves proportionally. This is a socialized backstop that doesn't require any additional infrastructure. + +**Note:** This is distinct from Liquity's *redemption* mechanism (which lets anyone exchange LUSD for ETH at face value from the lowest-collateralized Troves). Redemptions are a peg stability mechanism, not a liquidation mechanism. See the [Reflexive Stablecoin appendix](./appendix-reflexive-stablecoin-ecosystem.md#design-consideration-reflexive--redemption-hybrid) for discussion of how redemptions interact with reflexive stablecoin design. + +**Advantages:** +- SP depositors are pre-committed capital, eliminating auction timing risk +- Instant resolution - no price discovery delay +- Keeper role is lightweight (trigger only, no bidding strategy needed) +- MEV extraction reduced: SP depositors all receive the same pro-rata share, no competitive bidding + +**Why not selected as the primary mechanism for RFP-014:** +- Requires a dedicated Stability Pool with its own incentive structure (interest share in V2, LQTY rewards in V1), creating a bootstrapping dependency separate from the CDP protocol +- SP must have sufficient deposits before liquidations can be processed reliably - on a new chain, this is a chicken-and-egg problem +- Deeply coupled to Liquity's token mechanics; not easily abstracted behind a generic interface +- Less flexible for different CDP designs that may have different collateral types or risk parameters + +**However**, the trigger layer (keeper detects undercollateralization, calls liquidation function) is shared across all approaches. The difference is in resolution: Liquity routes to a Stability Pool, RFP-014 routes to an increasing-discount auction, and Aave-style direct liquidation resolves at the CDP level without an engine. See [Compatibility with RFP-013 Hybrid Evolution](#compatibility-with-rfp-013-hybrid-evolution) for how these paths relate to the hybrid design discussed in the stablecoin appendix. + +### Soft Liquidation via AMM (crvUSD / LLAMMA) + +**Mechanism:** +- Curve's [LLAMMA (Lending-Liquidating AMM Algorithm)](https://docs.curve.fi/crvUSD/amm/) places borrower collateral into a specialized AMM that automatically converts between collateral and crvUSD as the price moves +- As collateral price drops, the AMM gradually sells collateral for crvUSD (soft liquidation) +- As price recovers, the AMM gradually buys collateral back (de-liquidation) +- Full liquidation only occurs if the position is left in soft liquidation too long and losses accumulate + +**Advantages:** +- Gradual, reversible liquidation reduces the impact of temporary price wicks +- No keeper infrastructure for the soft liquidation phase +- Borrowers can recover without being fully liquidated + +**Why not selected for RFP-014:** +- Requires a custom AMM (LLAMMA) integrated with the CDP system - cannot be decoupled as a reusable engine +- Complex pricing math involving band-based liquidity distribution +- Borrowers suffer "soft liquidation losses" from the AMM's spread even if they recover +- Novel mechanism with limited production history outside Curve's ecosystem +- Not compatible with the reusable engine pattern (deeply coupled to AMM state) + +### Insurance Fund / Socialized Loss (Various) + +**Mechanism:** +- Protocol maintains insurance fund from fees +- Covers bad debt when collateral insufficient +- If fund exhausted, losses socialized across depositors or stakers + +**Why explicitly excluded from RFP-014:** +- Creates governance capture vectors (who decides payouts?) +- Moral hazard (riskier position-taking if socialized backstop) +- Complicates keeper incentives +- RFP-014 uses debt auction house for shortfalls instead (market-based, not governance-based) + +## The Reusable Engine Pattern + +### The Coupling Problem + +Traditionally, liquidation logic is tightly coupled to the CDP protocol: +- Maker's liquidation (`Dog` + `Clipper` contracts) is part of the Maker codebase +- Aave's liquidation is Aave-specific +- Liquity's Stability Pool is deeply integrated with Trove state +- Each new CDP product rebuilds similar logic + +**Problems with coupling:** +- Security: Each new implementation needs fresh audit +- Time-to-market: Months rebuilding proven mechanics +- Fragmentation: Keeper ecosystem split across implementations +- Upgrade complexity: Improvements don't propagate + +### The Reusable Engine Solution (RFP-014) + +RFP-014 proposes a **reusable liquidation program** that any CDP product can deploy: + +``` +CDP Protocol A -----> Liquidation Engine Instance A + (configured for A's parameters) + +CDP Protocol B -----> Liquidation Engine Instance B + (configured for B's parameters) + +RFP-013 Stablecoin -> Liquidation Engine Instance S + (configured for RAI-style reflexive params) + +Future Lending -----> Liquidation Engine Instance L + (configured for lending parameters) +``` + +**Each instance:** +- Inherits battle-tested auction logic +- Configured for host protocol's collateral types, ratios, discounts +- Isolated state per deployment (no cross-protocol contamination) +- Shared audit, shared keeper bot logic + +### Integration Interface + +The liquidation engine requires a minimal interface from host CDP protocols: + +``` +Host -> Engine: + - notify_undercollateralized_position(position_id, collateral, debt) + - get_collateral_price(collateral_type) -> price, confidence + +Engine -> Host: + - seize_collateral(position_id, amount) -> bool + - cancel_debt(position_id, amount) -> bool + - mint_surplus(amount) -> bool // for debt auctions +``` + +This interface abstraction allows the same engine code to service different CDP designs: +- Reflexive stablecoins (RFP-013) +- Multi-collateral lending (future RFPs) +- Single-asset synthetic assets +- Custom CDP products + +### Benefits of Reusable Design + +| Benefit | Explanation | +|---------|-------------| +| **Security** | Single codebase receives focused audit attention; improvements benefit all instances | +| **Time-to-market** | New CDP products don't rebuild liquidation from scratch; configure and deploy | +| **Liquidator ecosystem** | Keepers can operate across all LEZ CDP products with same tooling; concentrated liquidity | +| **Upgrade path** | Engine improvements can be adopted by all deployed instances (or remain isolated per-instance) | +| **Composability** | Standard interface enables CDP protocol aggregation, analytics, cross-protocol features | + +### Compatibility with RFP-013: Reflexive Stablecoin Specifics + +The integration interface above is generic, but RFP-013's reflexive stablecoin introduces two specific requirements that implementations must account for: + +**Redemption price in discount calculations.** In a fixed-peg stablecoin ($1 target), the auction discount math is straightforward: sell collateral at X% below oracle price, accept system coins at face value. In a reflexive stablecoin, the system coin's value *is* the floating redemption price. The GEB implementation handles this explicitly - the `FixedDiscountCollateralAuctionHouse` reads `lastReadRedemptionPrice` and uses it (alongside the collateral oracle price) to calculate collateral amounts returned to bidders. If the engine assumes a $1 unit of account instead of the current redemption price, the discount calculation is wrong and keepers either overpay or the protocol undersells collateral. The `get_collateral_price` interface should therefore also expose a `get_system_coin_redemption_price` call, or the host protocol must normalize prices before passing them to the engine. + +**Debt auction backstop.** The debt auction mechanism ("mint protocol tokens, auction for stablecoin") assumes a mintable protocol token (FLX in Reflexer, MKR in MakerDAO). RFP-013 explicitly lists governance token design as out of scope. This creates a dependency gap: either RFP-014's debt auction requires a protocol token that doesn't yet exist, or the debt auction component needs an alternative backstop. Options include relying solely on the surplus buffer (no backstop beyond accumulated fees), accepting that unresolvable bad debt must be socialized or written off, or deferring debt auctions until a protocol token is defined. Implementations should treat the debt auction house as a configurable component that can be activated later once a protocol token exists. + +### Compatibility with RFP-013 Hybrid Evolution + +The [Reflexive Stablecoin appendix](./appendix-reflexive-stablecoin-ecosystem.md#design-consideration-reflexive--redemption-hybrid) discusses a potential hybrid model combining RAI's PID controller with Liquity-style direct redemptions. If this hybrid is pursued, the liquidation engine's scope expands in two ways: + +**Redemption-triggered position closures.** In a hybrid, redemptions force-close the riskiest CDPs (Liquity-style). This is not a liquidation in the traditional sense (the position isn't undercollateralized), but it uses similar mechanics: collateral is seized from a position and transferred to the redeemer. The engine's integration interface would need to support a `redeem_against_position(position_id, amount)` call distinct from `seize_collateral`, since redemption has different authorization rules (anyone can redeem, not just keepers responding to undercollateralization). + +**Direct liquidation as a CDP-level function.** The Liquity Stability Pool model requires pre-committed capital from depositors, creating a bootstrapping dependency unsuitable for a new ecosystem. A simpler complementary path is direct liquidation (Aave-style), where a keeper repays a position's debt and receives collateral at a configurable bonus in a single atomic transaction. + +Critically, direct liquidation does not require the auction engine at all. It is a function on the CDP program itself (RFP-013), callable by any keeper: + +``` +Undercollateralized position detected + | + +---> Path C: Keeper calls RFP-013 directly + | keeper repays debt, receives collateral at bonus + | No auction engine involved. Flash-loan composable. + | + +---> Path A: Collateral routed to RFP-014 auction engine + increasing-discount auction handles thin markets + No keeper capital needed (discount attracts bidders) +``` + +Path C is fast and simple but requires keepers with capital (or flash-loan access). Path A is the fallback: if no keeper takes the direct liquidation within N blocks, or if the CDP protocol is configured for auction-only resolution, collateral flows to the RFP-014 auction engine where escalating discounts guarantee eventual clearing even in thin markets. + +This means: +- **RFP-014** (this RFP) delivers the auction engine (Path A). This is the scope of the current deliverable. +- **RFP-013** currently scopes all liquidation to RFP-014. If the hybrid evolution is pursued, RFP-013 would add a direct `liquidate(position_id, debt_amount)` function (Path C) as a CDP-level feature, independent of the auction engine. +- The two paths are complementary, not competing. Path C handles the common case (liquid markets, capital-rich keepers). Path A handles the stress case (thin markets, volatile conditions, no immediate taker). + +In this model, the liquidation engine's integration interface remains as specified: the CDP protocol notifies the engine when collateral needs to be auctioned. Direct liquidation bypasses this interface entirely since it's resolved at the CDP layer. A Stability Pool (Liquity-style Resolution B) remains a viable but more complex addition for later stages when the ecosystem has sufficient depositor liquidity. + +## Auction Types Comparison + +### English Auctions (Ascending) + +- Two phases: raise DAI bids, then return excess collateral +- Highest bidder wins after timeout +- **Time:** Hours typical +- **Capital lockup:** Yes (bid locked until outbid) +- **Best for:** Maximizing seller revenue in liquid markets +- **Worst for:** Liquidations (time = risk; capital lockup excludes flash-loan participants) +- **Used by:** MakerDAO Liq 1.2 (deprecated), Reflexer (available but not used in production) + +### Dutch Auctions (Descending) + +- Start above market price, price decreases deterministically +- First acceptor wins; partial fills allowed +- **Time:** Minutes to hours depending on price curve +- **Capital lockup:** No (instant settlement) +- **Best for:** Price discovery with time pressure; flash-loan composable +- **Worst for:** Volatile collateral (clearing price may lag rapid price movements) +- **Used by:** Sky/MakerDAO Liq 2.0 (current production) + +### Fixed / Increasing Discount Auctions + +- Collateral offered at discount to oracle price; fixed or escalating +- Bidders purchase immediately at current discount; partial fills allowed +- **Time:** Seconds to minutes +- **Capital lockup:** No (instant settlement) +- **Best for:** Fast liquidation, predictable keeper incentives, thin markets (escalation ensures clearing) +- **Worst for:** May undervalue collateral if discount is too aggressive; relies on oracle accuracy +- **Used by:** Reflexer/RAI (increasing discount variant in production) + +### Batch Auctions (Not in RFP-014) + +- Aggregate multiple liquidations into periodic clearing events +- Clear at uniform price across all participants +- **Time:** Periodic batches (minutes to hours) +- **Best for:** Gas efficiency, MEV mitigation, fair price for all participants +- **Worst for:** Immediate resolution (positions wait for batch) +- **Used by:** CoW Protocol (for DEX), not widely used for liquidations + +**RFP-014 selection:** Increasing discount with configurable escalation schedule. Fast, predictable, resilient in thin markets. + +## Surplus and Debt Auctions + +Beyond collateral liquidation, RFP-014 includes system balance mechanisms: + +### Surplus Auctions + +**Trigger:** Protocol accumulates excess stablecoin above threshold (from stability fees, liquidation penalties) + +**Mechanism:** Auction surplus stablecoin for reference token (e.g., ETH). In Reflexer's implementation, this uses a dedicated Surplus Auction House where bidders offer increasing amounts of protocol token (FLX) for a fixed lot of surplus RAI. + +**Outcome:** Protocol token burned, creating buyback pressure. Reference token or surplus distributed per protocol policy. + +### Debt Auctions + +**Trigger:** Collateral auction doesn't raise enough to cover debt + penalty (shortfall) + +**Mechanism:** Mint protocol tokens (IOUs), auction for stablecoin to recapitalize. In Reflexer, the Debt Auction House mints FLX and auctions it for RAI to cover bad debt. In MakerDAO, MKR is minted and auctioned for DAI. + +**Outcome:** Dilution of protocol token to cover system debt. Acts as lender-of-last-resort mechanism. + +**RFP-014 scope:** Both surplus and debt auction houses included as configurable components. + +## Why Public State for Auctions + +Similar to RFP-013's public position state, RFP-014's auction state is public: + +| Requirement | Public State Necessity | +|-------------|------------------------| +| **Bidder participation** | Bidders need to see current discount, remaining collateral, and bid status to make purchase decisions | +| **Keeper monitoring** | Keepers scan undercollateralized positions across protocols to trigger liquidations and participate in auctions | +| **Price verification** | Auction clearing prices serve as market signals; aggregators and oracles can reference liquidation data | +| **Composability** | Other protocols may build on auction outcomes (insurance products, liquidation analytics, automated strategies) | + +**Private auctions add complexity without clear benefit:** Unlike CDP positions (where users have a legitimate privacy interest in their financial exposure), auction state has no natural privacy stakeholder. Bidders want transparency to assess opportunity. The protocol needs transparency for correct settlement. Sealed-bid auctions exist in traditional finance but introduce additional challenges (bid commitment schemes, reveal phases, griefing via non-reveal) that add protocol complexity without improving liquidation outcomes. + +**Privacy approach:** Same as RFP-013 - public protocol state, private user interaction via deshield-interact-reshield. Bidders can participate from private accounts using ephemeral public accounts; auction state remains public. + +## References + +1. [RAI / GEB Auction Module](https://docs.reflexer.finance/system-contracts/auction-module) - Reflexer auction type documentation +2. [Fixed Discount Collateral Auction House](https://docs.reflexer.finance/system-contracts/auction-module/fixed-discount-collateral-auction-house) - GEB Docs +3. [Increasing Discount Collateral Auction House](https://docs.reflexer.finance/system-contracts/auction-module/increasing-discount-collateral-auction-house) - GEB Docs +4. [MIP 45: Liquidations 2.0](https://forum.makerdao.com/t/mip45-liquidations-2-0-liq-2-0-liquidation-system-redesign/6352) - MakerDAO Liquidation System Redesign +5. [Sky Liquidation 2.0 Developer Guide](https://github.com/sky-ecosystem/developerguides/blob/master/mcd/collateral-auction-integration-guide/collateral-auction-integration-guide.md) - Clipper contract integration +6. [Aave Liquidation Docs](https://docs.aave.com/faq/liquidations) - Direct liquidation mechanics +7. [Liquity V1 Whitepaper](https://www.liquity.org/blog/whitepaper) - Stability Pool liquidation design +8. [Liquity V2](https://www.liquity.org/) - Immutable borrowing with updated stability mechanics +9. [crvUSD LLAMMA Documentation](https://docs.curve.fi/crvUSD/amm/) - Soft liquidation via AMM +10. [DeFi Llama: Liquidations](https://defillama.com/liquidations) - Cross-protocol liquidation data +11. [ChainSecurity: MakerDAO Liquidations 2.0 Audit](https://www.chainsecurity.com/security-audit/makerdao-liquidations-2-0) - Security assessment of Dutch auction implementation + +--- + +*This appendix was prepared to support RFP-014. For the companion stablecoin design appendix, see [Appendix: Reflexive Stablecoin Ecosystem](./appendix-reflexive-stablecoin-ecosystem.md). For clarification or additions, please use the RFP repository Discussions.* diff --git a/appendix/appendix-reflexive-stablecoin-ecosystem.md b/appendix/appendix-reflexive-stablecoin-ecosystem.md new file mode 100644 index 0000000..5af089c --- /dev/null +++ b/appendix/appendix-reflexive-stablecoin-ecosystem.md @@ -0,0 +1,178 @@ +# Appendix: Reflexive Stablecoin Ecosystem + +This appendix surveys existing stablecoin protocols across the DeFi ecosystem. It serves as a reference for [RFP-013: Reflexive Stablecoin Protocol](../RFPs/RFP-013-reflexive-stablecoin-protocol.md), providing context on design approaches, their trade-offs, and why a governance-minimized reflexive model was selected. + +The stablecoin design space spans centralized custodial models (USDC), governance-heavy over-collateralized systems (Sky/MakerDAO), governance-minimized reflexive systems (RAI), and non-governance alternatives (LUSD). This appendix focuses on the subset relevant to RFP-013's design choice: why RAI-style reflexive control was selected over governance-heavy or centralized alternatives. + +## Stablecoin Protocols Considered + +Protocols are ordered by relevance to RFP-013's design philosophy (closest match first). + +| Protocol | Type | Governance | Collateral | Primary Mechanism | Launch | TVL/Status | +|----------|------|------------|------------|-------------------|--------|------------| +| Reflexer (RAI) | Reflexive | Governance-minimized | ETH only | PID controller, floating redemption price | 2021 | ~$5M TVL, ~$1.8M mcap; low activity but operational | +| HAI | Reflexive | Governance-minimized | Multi | RAI fork with multi-collateral | 2024 | Active on Optimism | +| Liquity V1 (LUSD) | Non-governance | No governance | ETH only | Redemption-based, pure ETH backing | 2021 | ~$153M TVL; LUSD supply ~$37M (declining due to V2 migration) | +| Liquity V2 (BOLD) | Non-governance | No governance | ETH, wstETH, rETH | User-set interest rates, immutable | 2025 | ~$95M TVL; actively growing | +| Sky/MakerDAO (DAI/USDS) | Governance-heavy | Extensive | Multi | DSChief governance, MKR/SKY voting | 2017 | ~$5.3B TVL (Sky Lending); rebranded to Sky in 2024 | +| USDC | Centralized | Corporate | Fiat reserves | Off-chain custody, mint/burn | 2018 | ~$60B+ supply | + +## Stablecoin Design Spectrum + +### Centralized: USDC + +USDC is issued by Circle with fiat reserves held at regulated banks. It offers the tightest peg stability and deepest liquidity but requires trust in Circle's solvency, reserve management, and regulatory compliance. Circle maintains blacklist capabilities and can freeze accounts. + +**Why not this approach for LEZ:** Centralization contradicts Logos' ethos of credibly neutral infrastructure. Blacklist capability and issuer dependencies create systemic risks. RFP-013 explicitly targets decentralized alternatives. + +### Governance-Heavy: Sky/MakerDAO (DAI/USDS) + +MakerDAO (rebranded to Sky in 2024) operates via MKR/SKY token governance. Protocol parameters (stability fees, collateral types, debt ceilings) require voting. The system uses multi-collateral backing (ETH, WBTC, real-world assets) and has evolved toward broad collateral inclusion and governance-active management. The rebrand introduced USDS alongside DAI, with DAI remaining operational. + +**Key mechanism:** Users lock collateral in Vaults, mint DAI/USDS against it. If collateral ratio falls below liquidation ratio, position is liquidated via auction. + +**Why not this approach for LEZ:** Extensive governance creates capture risks and reduces predictability. The reflexive stablecoin approach trades governance intervention for mathematical self-correction. + +### Governance-Minimized: RAI / Reflexer + +RAI pioneered the "governance minimized, reflexive" stablecoin model. It uses only ETH collateral and removes most governance parameters in favor of a feedback controller. + +**Core mechanism:** +- Redemption price: A floating target price that drifts over time +- Redemption rate: The rate at which redemption price changes, computed by a PID controller based on market price deviation +- Market price vs redemption price: If market price trades at premium to redemption price, redemption rate goes negative, causing redemption price to fall and eventually reducing demand +- Self-stabilization: No governance votes to adjust rates; mathematics enforces equilibrium + +**Position structure (SAFEs):** +- Locked ETH collateral +- Normalized debt (debt units, not nominal RAI) +- Accumulated rates (stability fees applied continuously) +- Nominal debt = normalized debt × accumulated rate + +**Current status:** RAI remains operational but with very low activity (~397 active Safes, ~$5M TVL, daily trading volume under $15K). The protocol achieved its governance-minimization goals but struggled with adoption, partly due to the difficulty of bootstrapping liquidity for a non-pegged asset and negative redemption rates discouraging LP participation. + +**Why this approach for LEZ:** Governance minimization aligns with LEZ's goal of credibly neutral infrastructure. The system is more predictable (no surprise parameter changes) and harder to capture. RFP-013 follows this design with LEZ-specific adaptations. RAI's adoption challenges are noted; LEZ's integrated ecosystem may provide a more favorable bootstrapping environment. + +### Non-Governance: Liquity (LUSD / BOLD) + +Liquity V1 eliminates governance entirely. It uses pure ETH backing, a fixed 110% collateralization ratio, and a redemption mechanism (users can redeem LUSD for ETH at face value, effectively creating a price floor). The protocol is fully immutable with zero exploits to date. + +Liquity V2 launched in January 2025 with its new stablecoin BOLD, expanding collateral to include ETH, wstETH, and rETH, and introducing user-set interest rates. V2 maintains full immutability while addressing V1 limitations around forced deleveraging from aggressive redemptions. V2 directs 75% of interest revenue to Stability Pool depositors and 25% to DEX liquidity providers. + +**Key difference from RAI:** No floating redemption price. LUSD/BOLD target $1.00 via redemption arbitrage (if LUSD < $1, buy and redeem for $1 of ETH). The protocol has no parameter governance - everything is immutable. + +**Why not this approach for LEZ:** While attractive for its immutability, Liquity's redemption mechanism creates different dynamics. RAI uses a **floating redemption price** as its target - the "peg" exists but drifts based on market conditions and PID controller feedback. This is distinct from both rigid $1.00 pegs (LUSD, DAI, USDC) and completely unpegged free-float tokens. The floating target allows the system to self-correct without governance intervention while still providing a measurable redemption value. + +### Multi-Collateral Reflexive: HAI + +HAI is a direct fork of RAI on Optimism that adds multi-collateral support (stETH, rETH, etc.) while maintaining the reflexive redemption rate mechanism. It demonstrates that the RAI model can evolve beyond pure ETH backing. + +**Relevance to RFP-013:** Shows evolutionary path if multi-collateral is desired later. RFP-013 starts with single-collateral for simplicity but could theoretically extend following HAI's pattern. + +## Design Consideration: Reflexive + Redemption Hybrid + +A natural question is whether combining RAI's PID controller with Liquity's direct redemption mechanism would address RAI's known adoption challenges while preserving the non-pegged, governance-minimized design. No production system has attempted this combination, but the design space is worth examining to explain why RFP-013 starts with pure reflexive control. + +### What the hybrid would look like + +In a hybrid model, anyone could redeem LEZ for `redemption_price` worth of ETH (from the riskiest CDPs, Liquity-style), creating an immediate arbitrage floor: if `LEZ_market < redemption_price`, buy on market, redeem for ETH, pocket the difference. The PID controller would continue managing the ceiling (market above redemption price triggers negative redemption rate, gradually reducing the target). The result is belt-and-suspenders stabilization: redemptions enforce the floor instantly, the PID manages the ceiling gradually, and the target still floats rather than pegging to $1. + +### Why this is attractive + +RAI's bootstrapping problem stems from having no fast correction mechanism in either direction. The PID slowly grinds price deviations down over hours or days, requiring sophisticated arbitrageurs and deep secondary market liquidity that RAI never achieved. Direct redemptions would create day-one utility and arbitrage opportunity without requiring deep liquidity. The average absolute deviation from target would be smaller, which means negative redemption rate episodes (the main LP deterrent in RAI) would be shorter and shallower, though not eliminated - the PID still needs negative rates when market trades above target. + +### Why RFP-013 does not specify this + +The hybrid introduces a dual-feedback-loop control problem that has not been modeled or tested. The PID controller and the redemption mechanism both respond to the same price signal but operate at different speeds (instantaneous step correction from redemption arbs vs. continuous proportional correction from PID). When redemption arbs snap the price back to floor, the PID observes a rapid recovery it didn't cause and may misinterpret the signal, leading to under-correction or over-correction on subsequent cycles. The PID gains would need to be detuned to account for the redemption loop, but detuning weakens ceiling enforcement, which is the only direction the PID handles alone. + +Additionally, Liquity-style redemptions force-close the riskiest CDPs involuntarily, which was V1's biggest UX pain point. Liquity V2 addressed this by letting borrowers set their own interest rates (lowest rate gets redeemed first), essentially letting users pay for redemption priority. A hybrid would need an analogous mechanism, adding significant protocol complexity. + +These are modelable problems, not intractable ones. RFP-013 starts with pure reflexive control to keep the initial implementation tractable and well-understood. The hybrid remains a viable evolution path if the controller tuning and redemption UX challenges can be formally analyzed - this would be a strong candidate for follow-on research with the TKE team. + +## Why Public State for CDPs + +### The Privacy Architecture Challenge + +A natural question: why not private position state? If users value privacy, shouldn't CDP positions be shielded? + +**The technical reality:** Private CDP state is an open research problem with no production implementation. + +### Why CDP Positions Must Be Public + +| Requirement | Why Public State Necessary | Private State Challenge | +|-------------|---------------------------|------------------------| +| **Liquidation monitoring** | Keepers must identify undercollateralized positions to trigger liquidation | With private positions, the question becomes *who* checks health and *when*. Oracle prices are public, and the ZK circuit itself is straightforward (prove `private_collateral * public_price < private_debt * liquidation_ratio`). The hard problem is authority and timing: if the CDP owner generates the proof, they control when liquidation-eligibility becomes visible (see research challenge 1 below). If a third party checks, they need access to the private position data, reintroducing trust. | +| **Permissionless position scanning** | Keepers, aggregators, and yield optimizers scan all positions to find liquidation opportunities, compute system-wide collateralization, and build on top of the protocol | Private state breaks *discoverability*: external protocols cannot enumerate or scan positions without owner cooperation. Owner-authorized interactions (e.g., passing a private record to a composing program) still work, but permissionless scanning by keepers, dashboards, and risk monitors does not. | +| **Systemic risk observability** | Total system collateralization, bad debt accumulation, and concentration risk are visible in real-time, allowing markets to price systemic risk | With private CDPs, liquidation failures become silent. Nobody knows how much bad debt is accumulating until it surfaces as a protocol insolvency event. For a reflexive stablecoin where the PID controller depends on market confidence, this observability is load-bearing: if the market cannot assess system health, the redemption price signal loses credibility, undermining the core stabilization mechanism. | + +**The RFP-013 approach:** +- Position state: Public (collateral amounts, debt, ratios) +- User privacy: Enforced at UX layer via deshield-interact-reshield pattern + +This matches the architecture in RFP-008 (Lending & Borrowing): public protocol state with optional private user interaction. + +### Research Frontier: ZK CDPs + +Private CDP systems are an active research area, but no production-ready system exists. Key projects exploring relevant primitives: + +- **Aztec Network:** The original Aztec Connect (private DeFi bridge using UTXO model) was [sunsetted in March 2023](https://medium.com/aztec-protocol/sunsetting-aztec-connect-a786edce5cae) due to centralization and resource constraints. The team rebuilt from scratch and launched Aztec Ignition Chain in November 2025 as a general-purpose privacy L2 on Ethereum, entering Alpha in early 2026. Aztec now supports programmable private smart contracts via Noir, meaning CDPs *could theoretically* be built on it, but none exist yet. A critical proving-system vulnerability disclosed in March 2026 (fix planned for July 2026) underscores the immaturity of the execution environment. +- **Aleo:** ZK-native L1 with mainnet live and the most advanced privacy-native DeFi infrastructure among the protocols listed. Paxos launched USAD (private stablecoin) in February 2026 and Circle launched USDCx (confidential USDC) in January 2026. Confidential DeFi tools (dark pools, private lending) are being explored in the ecosystem, but no CDP/stablecoin-minting system exists in production. Aleo's Leo language and ZK execution model could support private CDPs, but the coordination problems described below remain unsolved. +- **Manta Network:** Privacy-focused Ethereum L2 (Manta Pacific), not a ZK-native L1. Focused primarily on private token swaps via its MantaSwap product, processing 12M+ ZK transactions in Q1 2026. The Polkadot-based Manta Atlantic parachain is sunsetting August 2026. No CDP or lending primitives exist on Manta. + +**Note on "zk" terminology:** Some protocols use "zk" (e.g., StarkNet, zkSync) for validity proofs that provide scalability and data compression, not transaction privacy. Lending protocols on these chains (e.g., the now-defunct zkLend on StarkNet, which was hacked for $9.5M in February 2025 and [shut down in June 2025](https://www.bitget.com/news/detail/12560604834674)) had fully public position state despite operating on "zk-rollups". This distinction matters: zk-for-scalability ≠ zk-for-privacy. + +**The research challenges:** Private state CDPs face fundamental coordination problems centered on *who checks position health* and *when*: + +1. **Owner-generated health proofs (the timing problem):** The most natural ZK approach: the CDP owner periodically proves their position is healthy against a public oracle price, without revealing collateral or debt amounts. The ZK circuit is tractable (prove `collateral * price >= debt * ratio` over private inputs). The problem is that the owner controls proof cadence. If a price crash makes their position undercollateralized, they can delay submitting the proof while racing to add collateral or repay debt. This turns liquidation from a permissionless real-time check into a game of timing, undermining system solvency during exactly the conditions (rapid price drops) when liquidation matters most. A protocol-mandated proof interval (every N blocks) mitigates this but doesn't eliminate it: the owner still has N blocks of grace period, and gas costs per proof create ongoing UX burden. + +2. **Mandatory periodic proofs with default liquidation:** A strengthened version of (1): require health proofs every N blocks, and treat failure to prove as liquidation-eligible. This creates conditional privacy: positions stay private as long as owners keep proving health. This is a legitimate design option with real tradeoffs - it adds per-epoch gas costs for every CDP holder, creates a UX burden (miss a proof window and your healthy position gets liquidated), requires careful N calibration (too short = expensive, too long = undercollateralized positions persist), and still allows N-block gaming windows. Importantly, when a position *is* liquidated via proof timeout, the liquidator still needs to learn the position details to execute, requiring either a reveal step or trusted execution. + +3. **Trusted keepers / decryption committees:** A set of permissioned parties (a keeper committee, threshold decryption group, or TEE enclave) with access to encrypted position data, checking health and triggering liquidations. Practically simpler than ZK approaches but reintroduces centralization and trust: the committee must be trusted not to front-run, not to selectively liquidate, and to remain available. For Logos' credibly neutral infrastructure goals, this is a poor fit, though it may be acceptable for other protocol contexts. + +4. **FHE (Fully Homomorphic Encryption):** Emerging FHE-based DeFi infrastructure (Fhenix, Zama/fhEVM, Inco) allows on-chain computation over encrypted data without decryption. In principle, a protocol could compute `encrypted_collateral * public_price < encrypted_debt * threshold` homomorphically and produce a boolean liquidation-eligibility result. This would solve the timing problem since the protocol itself checks health at every block. However, FHE operations are orders of magnitude more expensive than plaintext computation, current implementations cannot support real-time liquidation checks at the throughput required for a production CDP system, and the tooling is immature. This is the most promising long-term direction but not production-viable as of April 2026. + +5. **Forced full decryption on timeout:** Protocol decrypts the entire position after X blocks of inactivity. Unlike approach (2), this reveals actual amounts rather than just health status, completely breaking privacy for inactive or distressed positions. Creates perverse incentives where owners must "ping" regularly to maintain privacy, and the threat of full reveal may deter privacy-conscious users from using the protocol at all. + +None of these approaches are production-ready as of April 2026. Approach (2) is the closest to viable but carries significant UX and economic overhead. Approach (4) is the most architecturally promising but furthest from production. RFP-013 acknowledges this landscape and scopes privacy to the UX layer - public protocol state enables permissionless liquidation, systemic risk observability, and composability, while the deshield-interact-reshield pattern provides user-level privacy for their interactions with the protocol. + +## Fee Structure Comparison + +| Protocol | Stability Fee | Liquidation Penalty | Revenue Destination | +|----------|--------------|---------------------|---------------------| +| Sky/MakerDAO | Variable (governance vote) | 13% flat | MKR buy-and-burn, surplus buffer | +| RAI | Variable (PID controller) | 12% | Surplus auction (burn ETH) | +| Liquity V1 | 0.5% one-time (borrowing fee) | No explicit penalty; SP depositors capture excess collateral (~10% at 110% CR) | LQTY stakers, Stability Pool | +| Liquity V2 | User-set interest rate | No explicit penalty; SP depositors capture excess collateral | 75% Stability Pool, 25% DEX LPs | +| RFP-013 | Configurable (governance for rate, controller for mechanism) | Configurable | Protocol-defined | + +RFP-013 leaves fee structure flexible but recommends RAI-style accumulation: stability fees accumulate in a surplus buffer, with surplus auctions when above threshold. + +## Design Decisions Summary + +| Decision | Selected Approach | Rejected Alternatives | Rationale | +|----------|-----------------|----------------------|-----------| +| **Price targeting** | Floating redemption price (reflexive) | Fixed $1.00 peg | Self-correcting without governance | +| **Rate control** | PID controller | Governance voting | Minimize capture risk | +| **Governance scope** | Limited (safety ratios, fees) | Extensive (rates, collateral types) | Predictable, harder to game | +| **Stabilization** | Pure reflexive (PID controller) | Reflexive + redemption hybrid | Avoids dual-feedback-loop tuning; hybrid viable as evolution path | +| **Collateral** | Single-asset initially (simple) | Multi-collateral at launch | Reduce complexity risk | +| **State privacy** | Public protocol state | Private state | Technical feasibility, permissionless liquidation, protocol integration | +| **User privacy** | UX-layer (deshield-interact-reshield) | None, or ZK state | Best available tradeoff | + +## References + +1. [RAI Whitepaper](https://github.com/reflexer-labs/whitepapers/blob/master/English/rai-english.pdf) - Reflexer Labs, 2021 +2. [GEB Code Repository](https://github.com/reflexer-labs/geb) - Reflexer implementation +3. [Sky (formerly MakerDAO) Documentation](https://docs.sky.money/) - Sky protocol mechanics +4. [Liquity V1 Whitepaper](https://www.liquity.org/blog/whitepaper) - Non-governance stablecoin design +5. [Liquity V2](https://www.liquity.org/) - Immutable borrowing with user-set interest rates +6. [HAI Documentation](https://docs.letsgethai.com/) - Multi-collateral RAI fork +7. [Reflexer Blog: Why RAI](https://reflexer-labs.medium.com/why-rai-2f8502ba1fbd) - Governance minimization rationale +8. [DeFi Llama: Stablecoins](https://defillama.com/stablecoins) - Market data and TVL comparisons +9. [Aztec Network](https://aztec.network/) - Privacy L2 on Ethereum +10. [Aleo](https://aleo.org/) - ZK-native L1 blockchain +11. [Sunsetting Aztec Connect](https://medium.com/aztec-protocol/sunsetting-aztec-connect-a786edce5cae) - Aztec Labs, March 2023 + +--- + +*This appendix was prepared to support RFP-013. For the companion liquidation mechanisms appendix, see [Appendix: Liquidation & Auction Ecosystem](./appendix-liquidation-auction-ecosystem.md). For clarification or additions, please use the RFP repository Discussions.* From c24640184859499bc7c2c673b7552d89a9bc865e Mon Sep 17 00:00:00 2001 From: mart1n <20109376+mart1n-xyz@users.noreply.github.com> Date: Fri, 10 Apr 2026 11:48:08 +0200 Subject: [PATCH 09/12] reject hybrid --- .../appendix-liquidation-auction-ecosystem.md | 14 ++++++------- ...appendix-reflexive-stablecoin-ecosystem.md | 20 ++++++++++++++----- 2 files changed, 21 insertions(+), 13 deletions(-) diff --git a/appendix/appendix-liquidation-auction-ecosystem.md b/appendix/appendix-liquidation-auction-ecosystem.md index c323354..b4b42e7 100644 --- a/appendix/appendix-liquidation-auction-ecosystem.md +++ b/appendix/appendix-liquidation-auction-ecosystem.md @@ -101,7 +101,7 @@ Liquity's liquidation has three distinct layers: - Deeply coupled to Liquity's token mechanics; not easily abstracted behind a generic interface - Less flexible for different CDP designs that may have different collateral types or risk parameters -**However**, the trigger layer (keeper detects undercollateralization, calls liquidation function) is shared across all approaches. The difference is in resolution: Liquity routes to a Stability Pool, RFP-014 routes to an increasing-discount auction, and Aave-style direct liquidation resolves at the CDP level without an engine. See [Compatibility with RFP-013 Hybrid Evolution](#compatibility-with-rfp-013-hybrid-evolution) for how these paths relate to the hybrid design discussed in the stablecoin appendix. +**However**, the trigger layer (keeper detects undercollateralization, calls liquidation function) is shared across all approaches. The difference is in resolution: Liquity routes to a Stability Pool, RFP-014 routes to an increasing-discount auction, and Aave-style direct liquidation resolves at the CDP level without an engine. See [Compatibility with RFP-013 Hybrid Evolution](#compatibility-with-rfp-013-hybrid-evolution) for how direct liquidation could complement the auction engine independently of the hybrid approach (which was [rejected](./appendix-reflexive-stablecoin-ecosystem.md#design-consideration-reflexive--redemption-hybrid) based on simulation analysis). ### Soft Liquidation via AMM (crvUSD / LLAMMA) @@ -217,13 +217,11 @@ The integration interface above is generic, but RFP-013's reflexive stablecoin i ### Compatibility with RFP-013 Hybrid Evolution -The [Reflexive Stablecoin appendix](./appendix-reflexive-stablecoin-ecosystem.md#design-consideration-reflexive--redemption-hybrid) discusses a potential hybrid model combining RAI's PID controller with Liquity-style direct redemptions. If this hybrid is pursued, the liquidation engine's scope expands in two ways: +The [Reflexive Stablecoin appendix](./appendix-reflexive-stablecoin-ecosystem.md#design-consideration-reflexive--redemption-hybrid) discusses a potential hybrid model combining RAI's PID controller with Liquity-style direct redemptions, and explains why this approach was rejected. Simulation analysis found that the hybrid's redemption floor is asymmetric — it only fires when the market trades below the redemption price, but the dominant RAI failure mode is an upside death spiral where the market stays above target and the PID drives extended negative-rate regimes that bleed LP participation. The hybrid provides zero protection against this risk. For the full analysis, see the stablecoin appendix. -**Redemption-triggered position closures.** In a hybrid, redemptions force-close the riskiest CDPs (Liquity-style). This is not a liquidation in the traditional sense (the position isn't undercollateralized), but it uses similar mechanics: collateral is seized from a position and transferred to the redeemer. The engine's integration interface would need to support a `redeem_against_position(position_id, amount)` call distinct from `seize_collateral`, since redemption has different authorization rules (anyone can redeem, not just keepers responding to undercollateralization). +**Redemption-triggered position closures.** Although the full hybrid is not recommended as a default operating mode, Liquity-style redemptions — where anyone redeems stablecoins for collateral from the riskiest CDPs — remain a viable component, either as a circuit-breaker-activated emergency backstop for downside crunches or as a standalone feature independent of the PID hybrid framing. This is not a liquidation in the traditional sense (the position isn't undercollateralized), but it uses similar mechanics: collateral is seized from a position and transferred to the redeemer. To support this, the engine's integration interface should accommodate a `redeem_against_position(position_id, amount)` call distinct from `seize_collateral`, since redemption has different authorization rules (anyone can redeem, not just keepers responding to undercollateralization). Keeping this interface available costs nothing and ensures the engine remains versatile if RFP-013 adds a redemption path later. -**Direct liquidation as a CDP-level function.** The Liquity Stability Pool model requires pre-committed capital from depositors, creating a bootstrapping dependency unsuitable for a new ecosystem. A simpler complementary path is direct liquidation (Aave-style), where a keeper repays a position's debt and receives collateral at a configurable bonus in a single atomic transaction. - -Critically, direct liquidation does not require the auction engine at all. It is a function on the CDP program itself (RFP-013), callable by any keeper: +**Direct liquidation as a complementary CDP-level function.** Independent of the hybrid question, there is value in a direct liquidation path (Aave-style) as a complement to the auction engine. A keeper repays a position's debt and receives collateral at a configurable bonus in a single atomic transaction. This does not require the auction engine at all — it is a function on the CDP program itself (RFP-013), callable by any keeper: ``` Undercollateralized position detected @@ -241,10 +239,10 @@ Path C is fast and simple but requires keepers with capital (or flash-loan acces This means: - **RFP-014** (this RFP) delivers the auction engine (Path A). This is the scope of the current deliverable. -- **RFP-013** currently scopes all liquidation to RFP-014. If the hybrid evolution is pursued, RFP-013 would add a direct `liquidate(position_id, debt_amount)` function (Path C) as a CDP-level feature, independent of the auction engine. +- **RFP-013** could independently add a direct `liquidate(position_id, debt_amount)` function (Path C) as a CDP-level feature. This is a straightforward Aave-style mechanism that does not depend on the hybrid design. - The two paths are complementary, not competing. Path C handles the common case (liquid markets, capital-rich keepers). Path A handles the stress case (thin markets, volatile conditions, no immediate taker). -In this model, the liquidation engine's integration interface remains as specified: the CDP protocol notifies the engine when collateral needs to be auctioned. Direct liquidation bypasses this interface entirely since it's resolved at the CDP layer. A Stability Pool (Liquity-style Resolution B) remains a viable but more complex addition for later stages when the ecosystem has sufficient depositor liquidity. +In this model, the liquidation engine's integration interface remains as specified: the CDP protocol notifies the engine when collateral needs to be auctioned. Direct liquidation bypasses this interface entirely since it's resolved at the CDP layer. ## Auction Types Comparison diff --git a/appendix/appendix-reflexive-stablecoin-ecosystem.md b/appendix/appendix-reflexive-stablecoin-ecosystem.md index 5af089c..1a64133 100644 --- a/appendix/appendix-reflexive-stablecoin-ecosystem.md +++ b/appendix/appendix-reflexive-stablecoin-ecosystem.md @@ -81,13 +81,23 @@ In a hybrid model, anyone could redeem LEZ for `redemption_price` worth of ETH ( RAI's bootstrapping problem stems from having no fast correction mechanism in either direction. The PID slowly grinds price deviations down over hours or days, requiring sophisticated arbitrageurs and deep secondary market liquidity that RAI never achieved. Direct redemptions would create day-one utility and arbitrage opportunity without requiring deep liquidity. The average absolute deviation from target would be smaller, which means negative redemption rate episodes (the main LP deterrent in RAI) would be shorter and shallower, though not eliminated - the PID still needs negative rates when market trades above target. -### Why RFP-013 does not specify this +### Why this approach was rejected -The hybrid introduces a dual-feedback-loop control problem that has not been modeled or tested. The PID controller and the redemption mechanism both respond to the same price signal but operate at different speeds (instantaneous step correction from redemption arbs vs. continuous proportional correction from PID). When redemption arbs snap the price back to floor, the PID observes a rapid recovery it didn't cause and may misinterpret the signal, leading to under-correction or over-correction on subsequent cycles. The PID gains would need to be detuned to account for the redemption loop, but detuning weakens ceiling enforcement, which is the only direction the PID handles alone. +The hybrid introduces a dual-feedback-loop control problem that, upon formal analysis, turns out to be asymmetric in a way that undermines the design rationale. -Additionally, Liquity-style redemptions force-close the riskiest CDPs involuntarily, which was V1's biggest UX pain point. Liquity V2 addressed this by letting borrowers set their own interest rates (lowest rate gets redeemed first), essentially letting users pay for redemption priority. A hybrid would need an analogous mechanism, adding significant protocol complexity. +The redemption floor only binds when the market trades *below* the redemption price — it creates arbitrage that pushes the price back up to floor. However, the dominant failure mode that drove RAI's adoption collapse is an *upside* demand event: persistent buying pressure keeps the market *above* target, the PID drives the redemption rate negative for extended periods, LP yield turns into carry bleed, LPs exit, the order book thins, deviations widen, the rate goes more negative, and the loop closes. The hybrid's redemption floor never fires in this regime. -These are modelable problems, not intractable ones. RFP-013 starts with pure reflexive control to keep the initial implementation tractable and well-understood. The hybrid remains a viable evolution path if the controller tuning and redemption UX challenges can be formally analyzed - this would be a strong candidate for follow-on research with the TKE team. +Simulation analysis confirms this asymmetry. In prolonged-negative-rate scenarios (the RAI death spiral), hybrid and pure PID collapse to identical outcomes — the same LP floor, the same ~6.3% mean peg error, the same supply blow-out. The hybrid provides **zero protection** against the single failure mode that matters most. The negative-rate regime persisted ~96% of the scenario duration in simulation; the redemption floor was inert throughout. + +Where the hybrid *does* help is symmetric bank-run and liquidity-crunch events, cutting max peg error from ~13% to ~1.2% and keeping LP P&L positive. This is a real but narrow benefit — and it is available through a much smaller surface area: an emergency redemption module that is off by default and activated only when a circuit breaker fires (e.g., >3% sustained downside deviation for >6h). + +Beyond the asymmetry problem, the hybrid increases attack surface — a CDP vault, instant redemption, and a PID controller form three coupled control loops to harden — and adds parameter overhead (redemption fee, capacity, floor activation threshold). The additional complexity creates a false sense of security that may tempt weaker PID gains. Liquity-style redemptions also force-close the riskiest CDPs involuntarily (V1's biggest UX pain point), requiring an interest-rate priority mechanism (à la Liquity V2) that adds further protocol complexity. + +A mechanism comparison across 11 families (29 candidates) found that LP-Lockup — structurally locking a fraction of pool liquidity against withdrawal shocks — is the only mechanism strictly dominant over pure RAI on every scenario × metric cell tested. The hybrid floor loses on LP P&L or depth in at least one stress scenario. The dominant risk to the system is LP retention under sustained negative carry, not a gap that can be closed at the redemption layer. + +A separate sweep of insurance reserve + fee kicker combinations (49 candidates × 8 scenarios × 24 seeds = 9,600 simulations) reinforces this conclusion and adds an important nuance. An insurance reserve of 8–12% of TVL with adaptive deployment (scaling intervention with error severity) achieves 16–21% less peg error than pure RAI with LP returns slightly improved (ratio 1.007–1.010), scoring 34 wins / 21 ties / 1 loss. However, the fee kicker — routing negative-rate holding tax to LPs as a subsidy — is counterproductive at every setting tested. Kicker payments attract LP entry, the pool overcrowds, per-unit returns dilute by more than the kicker compensates, and net LP P&L drops to 97% of RAI at full kicker. The optimal kicker setting is zero. Direct peg intervention (insurance reserve buying/selling against deviations) beats indirect incentives (fee routing to LPs) because second-order effects (overcrowding, dilution) dominate the intended first-order benefit. + +RFP-013 specifies pure reflexive control. If downside liquidity crunches prove problematic in production, the recommended path is an emergency redemption module (off by default, activated by circuit breaker), not a permanently active hybrid floor. The effective supplementary mechanisms are an insurance reserve with adaptive deployment, aggressive integrator anti-windup with hard clamping, and TWAP oracle hardening with staleness circuit breakers — these address the actual variance in the system. ## Why Public State for CDPs @@ -154,7 +164,7 @@ RFP-013 leaves fee structure flexible but recommends RAI-style accumulation: sta | **Price targeting** | Floating redemption price (reflexive) | Fixed $1.00 peg | Self-correcting without governance | | **Rate control** | PID controller | Governance voting | Minimize capture risk | | **Governance scope** | Limited (safety ratios, fees) | Extensive (rates, collateral types) | Predictable, harder to game | -| **Stabilization** | Pure reflexive (PID controller) | Reflexive + redemption hybrid | Avoids dual-feedback-loop tuning; hybrid viable as evolution path | +| **Stabilization** | Pure reflexive (PID controller) | Reflexive + redemption hybrid | Simulation analysis shows the hybrid's redemption floor is asymmetric — addresses downside only, provides zero protection against the dominant upside death spiral (the RAI failure mode). Emergency redemption as a circuit-breaker-activated backstop remains an option for downside crunches. | | **Collateral** | Single-asset initially (simple) | Multi-collateral at launch | Reduce complexity risk | | **State privacy** | Public protocol state | Private state | Technical feasibility, permissionless liquidation, protocol integration | | **User privacy** | UX-layer (deshield-interact-reshield) | None, or ZK state | Best available tradeoff | From 3b6e56a65e46b629821fc33fb51f82439abfe379 Mon Sep 17 00:00:00 2001 From: mart1n <20109376+mart1n-xyz@users.noreply.github.com> Date: Fri, 10 Apr 2026 12:17:13 +0200 Subject: [PATCH 10/12] Missing hard blocker: LP-0015 --- RFPs/RFP-013-reflexive-stablecoin-protocol.md | 8 ++++++++ RFPs/RFP-014-liquidation-auction-engine.md | 8 ++++++++ 2 files changed, 16 insertions(+) diff --git a/RFPs/RFP-013-reflexive-stablecoin-protocol.md b/RFPs/RFP-013-reflexive-stablecoin-protocol.md index 7a647db..2692bd2 100644 --- a/RFPs/RFP-013-reflexive-stablecoin-protocol.md +++ b/RFPs/RFP-013-reflexive-stablecoin-protocol.md @@ -164,6 +164,14 @@ The protocol requires external price feeds for market price and redemption rate Rate computation and stability fee accrual require knowing how much time has elapsed between interactions. Without a reliable on-chain timestamp, these 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 stablecoin operation like "lock collateral and mint" needs to: (1) call the token program to transfer collateral into the position, then (2) continue executing to update position state and mint stablecoins. 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 collateral 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 stablecoin 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. diff --git a/RFPs/RFP-014-liquidation-auction-engine.md b/RFPs/RFP-014-liquidation-auction-engine.md index 67a7abf..47db0f9 100644 --- a/RFPs/RFP-014-liquidation-auction-engine.md +++ b/RFPs/RFP-014-liquidation-auction-engine.md @@ -161,6 +161,14 @@ The system requires external price feeds for collateral valuation and liquidatio This liquidation system is designed to integrate with a host CDP protocol that provides positions to liquidate. It is typically deployed alongside [RFP-013](./RFP-013-reflexive-stablecoin-protocol.md) or equivalent. +#### 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 liquidation operation needs to: (1) call the host CDP protocol to seize collateral from an undercollateralized position, then (2) continue executing to initialize auction state and account for the seized collateral. 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 collateral seizure). + +[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 liquidation program can tail-call the CDP program and have control return to a protected continuation. This prize is currently **open**. + ### Soft blockers Desirable but the RFP can open without them. From 9aa4394a984d64fb0d1daa8ca0dbd8a1b1b21d42 Mon Sep 17 00:00:00 2001 From: mart1n <20109376+mart1n-xyz@users.noreply.github.com> Date: Fri, 10 Apr 2026 12:18:43 +0200 Subject: [PATCH 11/12] RFP-014 Usability 4: triggering liquidation should be explicit --- RFPs/RFP-014-liquidation-auction-engine.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/RFPs/RFP-014-liquidation-auction-engine.md b/RFPs/RFP-014-liquidation-auction-engine.md index 47db0f9..b5bcd9a 100644 --- a/RFPs/RFP-014-liquidation-auction-engine.md +++ b/RFPs/RFP-014-liquidation-auction-engine.md @@ -50,7 +50,7 @@ Building this as a reusable program has ecosystem-wide benefits. Each CDP produc 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. Tools display undercollateralized positions with estimated liquidator incentives, enabling efficient bot operation. +4. Tools display undercollateralized positions with estimated liquidator incentives and allow users to trigger liquidation, enabling efficient bot and manual operation. 5. Active auctions display collateral type, amount, current discount, raised amount vs target, and time remaining. Users can bid with clear previews of received collateral and costs. From 2f87433f393664e0b796b79040a817d7385ef76b Mon Sep 17 00:00:00 2001 From: mart1n <20109376+mart1n-xyz@users.noreply.github.com> Date: Fri, 10 Apr 2026 12:27:32 +0200 Subject: [PATCH 12/12] RFP-014 F4: debt auction requires a token that doesn't exist --- RFPs/RFP-014-liquidation-auction-engine.md | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/RFPs/RFP-014-liquidation-auction-engine.md b/RFPs/RFP-014-liquidation-auction-engine.md index b5bcd9a..0ea6fe4 100644 --- a/RFPs/RFP-014-liquidation-auction-engine.md +++ b/RFPs/RFP-014-liquidation-auction-engine.md @@ -34,9 +34,9 @@ Building this as a reusable program has ecosystem-wide benefits. Each CDP produc 3. Auctions support buying partial collateral lots, preventing large positions from becoming stuck. -4. When collateral auctions don't raise enough to cover debt plus penalty, the shortfall is handled via a separate debt auction mechanism that restores system balance. +4. When collateral auctions don't raise enough to cover debt plus penalty, the shortfall is handled via a debt auction mechanism. The mechanism must be fully implemented and tested (using a mock token), but parameterized by a configurable token address so the deployer can point it at whatever protocol token they choose. The protocol token itself is out of scope (see [RFP-013 Out of Scope](./RFP-013-reflexive-stablecoin-protocol.md#out-of-scope)). Until a protocol token is configured, the surplus buffer absorbs shortfalls up to its capacity; if bad debt exceeds the buffer, the system pauses new debt generation via freeze authority ([RFP-002](./RFP-002-freeze-authority-poc.md)). -5. When the protocol accumulates excess stablecoin above a threshold, surplus auctions sell it for the reference token (which is burned). +5. When the protocol accumulates excess stablecoin above a threshold, surplus auctions sell it for a protocol token (which is burned). As with F4, the surplus auction mechanism must be fully implemented and tested with a mock token, parameterized by a configurable token address. Until a protocol token is configured, surplus accumulates in the buffer without being auctioned. 6. Auctions follow strict state transitions with no reversals. All state changes are atomic and verifiable.