Integrate Liquity V1 Stability Pool for LUSD Collateral Yield

[0x4007]

Problem

Plain LUSD collateral earns 0% yield. Integrate Stability Pool for ~6.28% APR (Dune data) to fund governance token buybacks, without disrupting liquidity.

Solution

Add StabilityPoolFacet via diamond proxy. Auto-deposit LUSD to pool on mint; withdraw principal on redeem. Harvest ETH/LQTY yields during redeems for buybacks/compounding (protocol-owned only). Piggyback ops on user txs for gas efficiency.

Alternatives Considered

• AAVE (~3.24% yield, more complex).
• Leverage/LPs (higher risk).
• V2 migration (future option for multi-collateral).

Implementation Spec

Prerequisites

• Audit facet (~$10-20K budget).
• Integrate IStabilityPool.sol (address: 0x66017D22b0f8556afDd19e1e5b5f1cbD89a6C337).
• Add 1inch/Uniswap for swaps.
• New storage: totalPrincipalInPool (uint256), protocolTreasury (address).

Facet Functions

• depositToPool(uint256 amount): Call provideToSP(amount, address(0)).
• withdrawFromPool(uint256 amount): Call withdrawFromSP(amount).
• harvestRewards(): Claim rewards, swap (e.g., 50% to LUSD for compounding, 50% to governance token for buybacks).

Flows

• Mint: Transfer LUSD → Deposit to pool → Mint uUSD → Update totalPrincipalInPool += amount.
• Redeem: Burn uUSD → Calc principal → Withdraw/transfer principal → Harvest if rewards > threshold (route to treasury) → Update totalPrincipalInPool -= amount.

Over-Collateralization

Value pool as LUSD equivalent (Chainlink oracles for ETH/LQTY). Redemptions: principal only.

Monitoring/Automation

• Chainlink/Gelato for optional harvests. It would be nice to sell the ETH/LQTY for LUSD and boost holdings as soon as it is rewarded by the stability pool.
• Dune alerts for APR/supply.

Testing

• Unit: Deposit/withdraw/harvest (Foundry).
• Integration: Mainnet fork; simulate liquidations.
• Edges: Low liquidity, volatility, mass redeems. Gas: <200K extra per tx.

Deployment

1. Deploy facet.
2. diamondCut via multisig.
3. Verify on Etherscan.
4. Phased: Opt-in for new deposits.

Risks/Mitigations

• Yield variability: Fallback to plain LUSD if APR <3%.
• Supply crunch: Auto-withdraw if < $10M.
• Security: Audit for reentrancy.

[ryzhak]

We already introduced aave amo minter (i.e. getting LUSD collateral yield via aave). There's this issue which should refactor aave amo minter a bit and we could give aave a try.

We could:

1. Implement Aave AMO v2 #968
2. Cover amo minter feature with fuzzing and formal verification tests/specs
3. Run a security audit of the amo minter feature (ask 2 independent researches to make it faster)
4. Deploy

With the "amo minter" feature fully functional we can easily add new protocols for collateral yield, not just aave or Liquidity V1.

[0x4007]

I think AAVE is less attractive because 1. Half the yield compared to stability pool (at least for the last year, according to AAVE dashboard data and DUNE Liquity data) 2. As I recall thinking through this yesterday it seems more complex dealing with swaps for LUSD -> aLUSD compared to just depositing LUSD in the stability pool.

However for farming the LQTY/ETH rewards we would need to automate that as a separate task, which involves swaps.

[ryzhak]

Auto-deposit LUSD to pool on mint

So the flows for an end user are:

Mint

1. User sends LUSD collateral to Ubiquity Pool
2. LUSD collateral is sent to Liquidity V1 Stability Pool immediately
3. UUSD minted to the end user

Redeem

1. User redeems UUSD and sends UUSD to Ubiquity Pool
2. LUSD is sent from Liquidity V1 Stability Pool to Ubiquity Pool immediately
3. LUSD is sent to the redeeming user

I'm asking because the flows above are fully automated while Frax's AmoMinter requires an admin to manually transfer collateral to the desired AMO (i.e. AAVE, Liquidity, etc..).

[0x4007]

Yes I think fully automated is best because then it's impossible for a bank run scenario. Also it seems like the simplest "base layer" yield of the protocol.

[ryzhak]

To sum up, as a part of the current issue we should:

1. Add a new library (ex: LibYield) that will move collateral in/out of yield generating protocols (ex: aave, liquidity) with the support of the following admin user stories:
   a) Admin should be able to switch yield protocols (ex: we should be able to switch from liquidity to aave)
   b) Admin should be able to move existing collateral (the one that we have right now in the deployed Ubiquity Pool) to the selected yield generating protocol
2. Add a new diamond facet (ex: YieldFacet) which should expose admin methods for moving collateral that already resides in the ubiquity pool
3. Modify UbiquityPool to call LibYield on minting/redeeming UUSD

P.S. #968 can be closed as "not planned" since AmoMinter requires manual moving of the collateral by the admin and we're implementing a fully automated solution in the current issue

[0x4007]

Isn't making a generic interface to support farming yield from anywhere more complicated compared to a specialized module for only the Stability Pool rewards? The architecture is not very clear to me.

For the foreseeable future though, I think supporting 1. Stability Pool rewards as a top priority and optionally 2. Aave yield later makes sense to support.

Basically I'm suggesting that focusing only on the Stability Pool rewards support is of interest in the near future.

I also think that piggy backing the farming on mints and redeems would be great, and optionally keepers like Gelato later.

[ryzhak]

Isn't making a generic interface to support farming yield from anywhere more complicated compared to a specialized module for only the Stability Pool rewards? The architecture is not very clear to me.

Yes, the idea is to make the architecture generalized which is definitely more complicated compared to "hardcoding" only Liquidity Stability Pool.

If we need results ASAP then "hardcoding" could be an option although the generalized solution would save us some time should we consider moving from Liquidity Stability Pool to some other yield protocol.

[0x4007]

I think doing both is preferred for the sake of time. We can take our time to do the generic interface correctly. And we can push the stability pool version confidently with less time. I imagine that the attack surface area would be minimized as well.

[0x4007]

Not sure if only author can use /time but @ryzhak perhaps you can set a time

[ryzhak]

/time 1 day

[ubiquity-os]

Warning

Only admins, collaborators, or the issue author can set time estimates.

[ryzhak]

Not sure if only author can use /time but @ryzhak perhaps you can set a time

I suppose Time: 1 day is enough for a raw (i.e. not generalized) Liquidity V1 integration and preparing a deployment migration.