Low LUSD liquidity

[bingen]

Problem

• Ensure sustainable liquidity on stable Bold pairs of $20m per side (e.g. USDC/BOLD). If users expect 7% on a stable LP this makes $2.8m/year, and we expect $1.4m/year to come from trading fees (curve/uniswap).
  • Assumption on venue and pairs
  • Curve:
  • Maverick:
  • Uniswap v3:
• What means do we have to achieve it in a decentralised way?

[bingen]

See also #26 and #27

[edmulraney]

Liquidity

Need/Problem

Ensure sustainable liquidity on stable Bold pairs of $20m per side (e.g. USDC/BOLD). If users expect 7% on a stable LP this makes $2.8m/year, and we expect $1.4m/year to come from trading fees (curve/uniswap).

Criteria

• Target TVL: $40M TVL ($20m BOLD/ $20m stable)
• Target yield: 7% (at target TVL)
• Assume 50% of 7% yield comes from trade fees, meaning 3.5% is required from somewhere else
• Code should be audit-ready by 30th March 2024

Assumptions

AMM venue

• Internal AMM
• External AMM (Curve, Maverick, Uniswap, etc.)

LP pairs

BOLD/stable (e.g. USDC, 3CRV)

Solution components

When considering a spectrum of centralized <-> governed <-> decentralized solutions, the following must be considered.

Liquidity pairing

• Handling an evolving landscape of stablecoins (e.g. popular stablecoin winds down or becomes less popular (less liquid), a new stablecoin emerges and becomes more popular)
• Handling the case where the paired stablecoin fails or depegs
• Do we want to incentivise a single LP pair, or multiple?

AMM venue

• Handling the case where the venue suffers loss of funds due to a hack or bug (LPs lose funds)
• Handling the case where the venue is no longer popular and liquidity moves elsewhere (Uniswap v2->v3->v4-vx, Sushiswap dead, Curve v2->vx) (LPs no longer use the venue we've chosen)
• Does the venue give us fine grained control of liquidity concentration? e.g. Maverick and Uniswap v3, vs Curve

Incentivisation mechanism

• How do we incentivise liquidity?
• What system states should trigger the incentivisation of liquidity, and the inverse, reduce incentivisaiton?
• What incentive (e.g. reward asset(s)) does the LP receive?
• Does the mechanism work autonomously or require governance or require admin changeability?
• Where does the reward/yield come from?

Yield source

• Repurpose protocol revenue (mint/redeem fees, borrow fees/interest, liquidation fees, reserve yield)
• Secondary token rewards (e.g. repurpose LQTY rewards/tokenomics)
• Introduce new fees (e.g. borrower interest rate) when liquidity below target threshold)

Ensuring we obtain the desired liquidity

• Open questions:
• Is it possible to have a controller target an APR of LP positions i.e. is there the necessary data on-chain to perform the calculation?
• We need to know the current APR of the LP positions, and then we also need a price feed for ETH and LQTY in order to calculate the delta between current APR of LP positions, and extra yield required to obtain the desired TVL for liquidity
• If we can't solve this on chain, then we need a simpler approach to incentivisation: TBD (fixed split of protocol revenue, yield increases dynamically based on TVL (risky), etc.)

Potential solutions

Solution 0

• Repurpose all system yield into a controller which can distribute it towards different actors (e.g. LPs) (i.e. remove LQTY staking)
• Hardcode the Curve ecosystem into the protocol
• Yield controller distributes yield towards the most liquid stablecoin pools on Curve, i.e. lookup which Curve pools have the most stablecoin liquidity and distribute yield towards that BOLD/that-pair
• Yield controller rebalances periodically (e.g. bi-weekly) to figure out which Curve pool to distribute yield to

Solution 1

• Repurpose all system yield into a controller (i.e. remove LQTY staking)
• Define conditions which make the controller push the yield to required actors at the required time (borrowing, stability pool, liquidity)
• Define target yields such that all the controller held yield isn't paid out but pays enough to achieve the target
• Create a ve tokenomics voting system for LQTY holders which allow stakeholders to choose which BOLD/stable pairs receive incentivisation (yield), and gain boosted yield (same as ve == new utility for LQTY)

Solution 2

• Solution 1 but replace governance with:
• Liquity admin multisig which can control which liquidity pairs which are incentivised

Solution 3

• Take solution 1 or 2 and then:
• Repurpose Stability pool, instead of taking BOLD, it takes BOLD/stable LP tokens

Solution 4

• Solution 3 but with:
• Enable zapping into an LP position when borrowing
• Users can automatically zap into an LP position which is staked in the Stability pool, from their stETH
• Creates a default case for earning yield on their ETH

Solution 5

• Any previous solution e.g. Solution 1 or 2 but with:
• Remove LQTY staking, instead LQTY is used for receiving (boosted) yield: (borrowing, stability pool and LP pairs)
• Creates new utility for LQTY

Promising solutions

Solution 0

• Description: yield controller with baked in Curve dependence
• Pros/cons: no governance, no admin control (more decentralized), more effort to develop
• What can be done (complexity and time): TBD
• What does it break? How is it correlated to other points?: TBD
• How effective is it?: we gain some nice properties, buy into the existing Curve ve ecosystem and don't need to implement ve ourselves, but it's still complicated to developer because we need our own controller to lookup liquid Curve pools and rebalance the rewards based on the the most liquid pools

Solution 1

• Description: yield controller with ve tokenomics for LP pairs
• Pros/cons: minimal decentralized governance, no admin control (more decentralized), more effort to develop
• What can be done (complexity and time): reuse/rewrite ve contracts
• What does it break? How is it correlated to other points?: TBD
• How effective is it?: if we go off Liquity v1, there has always been enough yield to incentivise liquidity, however, we can't guarantee this will be the case when LQTY emissions tail off. Potentially LQTY could become a variable supply to enable inflation/deflation such that LQTY rewards can always be minted where needed

Solution 2

• Description: yield controller with Liquity multisig controlling it and multisig controlling pairs
• Pros/cons: no governance, but a limited admin multisig for controlling yield and LP pairs (more centralized), less effort to develop
• What can be done (complexity and time): TBD
• What does it break? How is it correlated to other points?: TBD
• How effective is it?: if we go off Liquity v1, there has always been enough yield to incentivise liquidity, however, we can't guarantee this will be the case when LQTY emissions tail off. Potentially LQTY could become a variable supply to enable inflation/deflation such that LQTY rewards can always be minted where needed. Users that like the decentralized nature of Liquity might not like Liquity AG multisig controlling system yield, though it's contained

TBD:

• Remove Stability Pool, remove LQTY staking
• Instead users can only stake the currently incentivise LP pair(s)
• The staked LP can be used for liquidations (e.g. like a Stability pool), it also receives the yield as required to achieve target TVL
• • OR, cap the SP to limit the amount of BOLD that can be staked in it, such that its safe for liquidations (e.g. 30% BOLD supply max), and the remaining system yield can be used to incentivise LP pairs or borrowing via a controller

[edmulraney]

Exploring voting mechanisms for the management of yield to be used for incentivising external stablecoin liquidity

Vote locking LQTY options

1. LQTY holders can vote lock their LQTY toward any LP token

   • Benefits: any AMM venue is usable = future proof
   • Downsides: LPs lose access to their LP token as it would need to be staked
   • Mitigations: we could at least issue a new LP token to represent their staked LP token

2. LQTY holders can vote lock their LQTY towards any pairable asset on hardcoded AMMs

   • Benefits: instead of voting on specific LP tokens, LQTY holders would vote on a single token which would then be permitted for liquidity pairing with bold on any of the whitelisted AMM venues. This enables LPs to permissionlessly add eligible pools from any whitelisted AMM venue for yield to be directed towards it, the yield would have to be weighted by pool TVL. This also means LPs don’t need to stake an LP token and thus their LP token remains in their wallet. This means their wouldn’t need to be a governance vote per pool, just per asset, whereby there may be the same pool in different venues
   • Downsides: hardcoded AMM venues
   • Mitigations: perhaps voting could be extended to include whitelisting new venues

3. Yield could be directed towards The DeFi Collective who repurpose the yield for their own chosen liquidity strategy, and LQTY holders can vote to turn off the yield if they underperform

   • Benefits: liquidity strategy isn’t handled by the protocol but offloaded to liquidity experts who can adapt to market changes, AMM venue changes, etc. and run advanced liquidity strategies
   • Downsides: depends on a single organisation which can fail or underperform
   • Mitigations: needs a fallback strategy if LQTY voters revoke the yield from DeFi collective (could be any on chain “marketmaker” entity if they exist)

4. Clone Maverick contracts and embed in our protocol a specific pool which executes our desired liquidity strategy, pay out all yield to this single pool. LQTY holders can only vote on the asset that can be paired with bold. Position is tokenised.

   • Benefits: not dependent on third party AMM, we have more granular control over the pool and can incentivise deep liquidity in a single pol, while being future proof on the asset which is paired. Removes the need for complex yield distribution among various pools.
   • Downsides: locked into the Maverick design forever, when better designs will come along in the future
   • Mitigations: could enable governance voting over the internal AMM contract, with conditions to prevent misuse

5. Similar to 4 but create our own specialised AMM, potentially using some ideas from dispenser

6. Create a Chicken bond for bold LP tokens but instead of having an increasing backing price for bBond, allow people to stake it and collect yield. LQTY holders can vote on which LP tokens can be bonded.

[edmulraney]

Liquidity incentivisation approach

High level We’ll enable LQTY holders to vote on stablecoins which can be paired with bold inside UniV3 (no wrappers like Bunni) to receive system yield rewards. Although voting can happen on a weekly basis, which is good for responding to market exceptions like the paired asset failing/depegging, we don’t want LQTY holders and LPs to have to manage their position on a weekly basis. Instead we expect a pool to last for a very long time, until a better stablecoin pairing comes along. And thus by voting once, you indicate your voting for eternity unless you unstake your LQTY which voted on a pairing. (“Set and forget”). We’re not trying to recreate Curve, but just incentivise long term liquidity.

Process

1. LQTY holders will vote at most once per week on a stablecoin they want to pair with BOLD to receive yield rewards for (they vote by staking and locking their LQTY for 1 week)

Questions How will the system know the asset users are voting on is a stablecoin? It won’t know possible future stablecoins ahead of time

2. At the end of the voting period, their LQTY is unlocked and they can unstake if they want to stop voting, but if they don’t unstake, it means they’re automatically voting for the same pool to continue receiving rewards next period

Questions I’m assuming the LQTY will be unstakable until just before the end of the next voting period (1 week), meaning they have 1 week to unstake until it gets auto-locked for the next week as a vote

3. At the same time, a permissionless function becomes callable which will: If there’s no existing Univ3 BOLD pool with the voted on asset: Deploy a new UniV3 pool with a fixed parameters like tick range determined by the system, and with the paired asset being the only dynamic parameter which was voted on

Questions How will the system know the tick range for the asset? If we somehow limit it only to stablecoins then maybe this is easier? If there’s an existing Univ3 BOLD pool: don’t deploy a new pool Deploy a Univ3Staker contract, with pool/incentivisation parameters all pre-configured by the system (not chosen by users)

The parameters will be: baseFee: (1bp, 5bps, 30bps) univ3pool: the pool from above tickRange: TODO startTime: now endTime: end of period (1 week) refundee: bold smart contract which holds the yield (any remaining rewards are given back to the system) maxTargetTVL: TBD amountOfRewards: this should be a function of the maxTargetTVL and the amount of available system yield that can be paid out, the system shouldn’t pay more yield out than should attract maxTargetTVL, but of course if the system doesn’t have enough yield for maxTargetTVL then it can only pay out its max yield and the realized TVL may be lower

The UniV3 pool needs to have admin control given to a bold smart contract which can kick start the rewards again at the start of the next period if the same pool is voted upon to receive yield

Questions Does the Univ3Staker contract actually support this functionality or would we need to redeploy a new staking contract every period and have the system move the staked NFT over to the new one?

4. Once the UniV3Staker contract is deployed, LPs can now stake their UniV3 NFT within the staking contract to receive the allocated system yield rewards
5. If the same pool is voted upon again next period, then LPs do not need to remove/restake their liquidity (TBD is this possible? see question in last part of step 3)

Other questions: How do we handle the first week? Their LQTY will be locked and no pool will be receiving rewards as we won’t have the result of the first vote. Perhaps we can just initialize a pool we think is worth incentivising first e.g. BOLD/USDC or whatever

[edmulraney]

Colin's feedback:

How will the system know the asset users are voting on is a stablecoin? It won’t know possible future stablecoins ahead of time One potential option is to have a fixed number of slots, say 5, which would represent the stables that could be paired next to BOLD. Initially we should probably set them to USDC, USDT, DAI, LUSD and FRAX (whatever, but not important for this demonstration). Few things we should consider, what is the time horizon of this version. While the code would remain immutable --or at least until state rent (maybe) gently coasts it off Ethereum. It's not crazy to imagine that it has a 5-10 year practical lifespan, after which we're on v3 (or more), and this version is less relevant. Given our expressed desire to use a single version of staked ETH, this time horizon is probably towards the top end of what the effective lifespan could be. That in mind, I see essentially we need to design against 2 scenarios: A token is no longer a relevant pair (e.g. say we drop BOLD-FRAX to replace it with BOLD-CRVUSD --again just to demonstrate, don't worry about the choice). We could hold a time locked vote (say 4 successive 1 week epochs need more votes for CRVUSD more than for FRAX), after which CRVUSD replaces FRAX as the fifth position on the 'allowable paired assets' list. This would suggest that effectively anyone (maybe with token gating) could propose assets, most of the time this will fail the 4 epoch test in which case it's discarded), but it would need to be something that is guarded against (a reasonable rationale fundamental for holding a token). Couple of things: This does potentially allow other assets, which are not stablecoins to become the incentivised pair. As I mentioned, I don't think that I'm smarter than the market, so if that's the choice of governance, so be it. It may, however, raise the effective cost of liquidity, but it doesn't put us in a worse situation than with v1. We could imagine putting guardrails in for minimum liquidity or snapshot volatility (using TWAP metrics in Univ3) but again, maybe we don't factor that we're smarter than the market. We probably need to consider including a veto or blank spot, where less than the max number of pairable assets in the list (e.g., 4 of 5) slots could be incentivised and it's not easy to abuse spamming in a 5th. A token has been replaced and/or redeployed. We've seen this with DAI (now SAI), but it's also not impossible to imagine that USDC or USDT could be redeployed without a long lead time. That would create a ton of headaches, not only for us, but large swathes of DeFi, so I'm not too concerned with this being a messy process, but it should be factored into the design. I think that the solution for 1 is probably sufficient, with the worst case being that it takes a few weeks of paying incentives to a defunct token while we sort out replacing it in the list. I’m assuming the LQTY will be unstakable until just before the end of the next voting period (1 week), meaning they have 1 week to unstake until it gets auto-locked for the next week as a vote Most ve designs I've seen have a "reset" mechanism to nullify their vote if they were to remove (unstake it) over the course of a epoch snapshot in the event of it's expiry. If someone locks for 1 week and votes, but waits until after the epoch to withdraw their LQTY (or whatever), that usually counts. I would advocate that we force people to relock their tokens, or give them a roll-over option through an external mechanism, but wouldn't overengineer this point. Questions: how will the system know the tick range for the asset? If we somehow limit it only to stablecoins then maybe this is easier The UniV3 staker doesn't require this, it balances incentives within range, which means we don't 'guide' liquidity, we just pay liquidity that is actually used. If we want to do guided, I would suggest we use a discretionary offchain mechanism (i.e. Brice) to do this. Does the Univ3Staker contract actually support this functionality or would we need to redeploy a new staking contract every period and have the system move the staked NFT over to the new one? I'd suggest we design it that the 'kicking' should be done from the governance module that we deploy, which would create a new set of incentives at the start of each epoch and reward those assets already staked. I will need to pick apart the contract a bit more, but I think that if (for instance) we reward BOLD-USDC 0.05 in epoch 1 and epoch 2 (creating new incentives each time), an LP with that who staked in epoch 0 and didn't unstake, wouldn't need to do any further action, which would be ideal UX imo. Though there is probably a step immediately before epoch 2 incentives are created that epoch 1 incentives need to be ended (which should be trigged by the governance module). The staker contract, does have logic on createIncentive to specify where refunds would be sent (BOLD or whatever incentive token we give), which would be the governance contract or a treasury that handles this.

[edmulraney]

Choosing an AMM venue

We need to assess which AMM makes most sense to use immutably into the protocol.

Contenders: UniV3, Curve, UniV4, Maverick.

Since UniV4 isn't out yet we can't assess it.

Note on Merkl: Merkl is an incentivisation layer for UniV3. However, it depends on a complex stack of dependencies: Merkl off-chain logic + dispute process -> Arrakis -> Gelato bots.

It requires off-chain calculation of rewards by the Angle team, which an immutable protocol should not depend on ideally.

UX / how would users receive rewards for their liquidity

UniV3

• Users would stake their liquidity NFT inside our UniV3Staker contract to receive rewards. They don't receive another NFT that represents their staked position.
• Bold voters could vote on the pool address to receive rewards

Curve

• Bold protocol could distribute rewards directly to a Curve pool, meaning users don't have to leave the Curve ecosystem or relinquish their position to our protocol
• Bold voters could vote on the pool address to receive rewards

Maverick

• Bold protocol could distribute rewards directly to a Maverick pool, meaning users don't have to leave the Maverick ecosystem or relinquish their position to our protocol
• Bold voters could vote on the pool address to receive rewards, this would enable people to easily shape liquidity and choose asset to pair BOLD with in their browser off-chain, rather than trying to build pool provisioning into the protocol.

Safety/risk

UniV3: battle tested, confidence high Curve: battle tested, confidence high Maverick: less battle tested, significant/complex changes over UniV3, confidence medium (related to KyberSwap concentrated liquidity hack recently)

Efficiency / peg

UniV3: no effect, liquidity goes where LPs choose to place it, if the price moves out of LP range Curve: dynamically moves concentrated liquidity where its needed Maverick: allows us, or market participants, to create "boosted pools" - choose a liquidity shape that effects the peg in a way favourable to us

[edmulraney]

Comparing options

There are two main paths we seem to be converging on:

1. Minimal approach: simple incentivisation on-chain, complex incentivisation off-chain
2. Maximal approach: complex incentivisation on-chain, no incentivisation off-chain

Minimal approach

• The core protocol distributes rewards to a UniV3 pool which LQTY holders can vote on each week for receiving rewards.
• The core protocol distributes a smaller portion of rewards to a third-party smart contract, which can be utilized by the third party (e.g. The DeFi Collective) to create their own incentivisation strategy of pools in DeFI
• The third-party reward stream can be revoked by LQTY voters at any time, and switched to a new third party

Pros

• The protocol core remains slim/simple/minimal, and doesn't try to figure out all the possible and future protocols to incentivise
• Enables off-chain liquidity strategy that can adapt to market/protocol changes and therefore is future proof
• Incentivising a primary pool ensures liquidity that is routable to the rest of DeFi and avoids fragmentation
• Set and forget, LPs can deposit into the primary liquidity pool and can leave it there as long as LQTY voters want to keep this pool incentivised (should only change if a better stablecoin pairing comes along (infrequent))

Cons

• No guarantee the third party will perform well
• UniV3 is enshrined in the protocol forever, and may become a dead town when Univ4/UniV5 or a better competitor is released
• No ability for other projects to co-incentivise the liquidity pool

Maximal approach

• Support multiple liquidity venues/protocols e.g. Maverick, Convex, Yearn, etc.
• Don't distribute rewards to a third party contract for third-party management

Pros

• Enables co-incentivisation of liquidity which should reduce the protocols spend (amount of rewards distributed)
• LPs have multiple options supported in the core protocol, doesn't depend on a single venue

Cons

• Still not future proof. Whatever we enshrine as supported venues would be immutable and these might not be future proof
• Assumes projects still are doing DeFi 1.0 LP renting, not sure this is the common approach anymore, seems bribing took over this
• Risk of liquidity fragmentation if many options can receive rewards
• Not set and forget, LPs would have to manage their liquidity actively when the co-incentivisation periods expires
• Lots of unknowns:
  • How could the smart contracts measure how much rewards it needs to distribute based on the rewards that other projects are contributing?
  • Which venue(s) supports co-incentivisation in a smart contract automated way?

[edmulraney]

Conclusion from today's dev call

Let's assume we'll go with the minimal approach.

Next steps

Given some TVL and some average interest rate:

• How much could we pay in rewards towards the primary liquidity pool and the third party contract

Factors:

• How much do we need to pay to Stability pool?
• How much do we need to pay to LQTY holders? Answer: none

Base numbers:

• $7M rewards per year (= 140M in BOLD debt * 5% = $7M)
• $1.5m goes to reward token holders
• $4m to SP
• $1.5m to liquidity incentivisation
• 10% of bold supply: 140m = 14m in liquidity
• AMM = 14m BOLD / 14m USDC* = 28m total liquidity
• APR = 1.5m/28m = 5.35% APR
• Average daily volume = $4m
• Trade fee rewards = 0.05% $4m 365 = $730k
• Trade fee APR = 730k/28m = 2.6%
• Total APR = 5.35% + 2.6% = 7.95% APR

* USDC could be any paired asset

Outstanding:

• What do we need to know to start coding this in February?
• Voting gauges
• Whitelisting assets to pair with
• Number of active incentivised pools
• Set and forget ability, what needs to be maintained/updated by voters/LPs
• Asset locked until ended of period, then voters can claim (LP tokens don't get locked, freely stake/unstake)
• Come up with architecture design diagram that shows all components interacting together

[edmulraney]

Moved to docs: https://docs.google.com/document/d/1AptoX4ZzZCFWujBYAkf-wmaA4tVpMym4w7hf4B8Ge_w/edit#heading=h.kvhz0bsk85i3

[bingen]

Hopefully the governance module fixes this.