TL;DR of the proposal: Adjust the budget for Protocol Owned Liquidity to allow a more aggressive capturing of liquidity. For ease of maths, performance will be measured using today’s pool volumes to show the importance of increasing the budget ASAP.
With our pilot with Olympus Pro now officially approved, it’s time we start considering how to approach the transition towards this more sustainable model of liquidity. This is a very big matter to address, but it’s important we start deciding quickly how to approach it, as the foundation’s extension will be ending in a little under three weeks: https://twitter.com/paraswap/status/1505311718058205190
To fully understand this proposal, you will need to read the following ones before continuing:
Before we can assess how much $PSP we need, it’s important that we examine the current existing liquidity. Here are some of the major pools of $PSP (excluding bancor, as it’s already been addressed in prior proposals):
Paraswap Safety Module (ETH):
Total value: 435k
Of which 350k PSP and 85k in eth
Paraswap SushiSwap Pool (ETH):
Total value: 1.4M
Quickswap Pool (MATIC):
Total value: 835k (down from ~1M pre-rewards)
ComethSwap Pool (MATIC)
This is not a major pool, but worth noting that ComethSwap only currently has 28k in liquidity following a drop in rewards, highlighting the importance of protocol owned liquidity over mercenary farmers, as well as highlighting why I wish to suggest the current allocation:
Total Value: ~25k (down from 100k)
With these stats in mind, we can see that with a monthly budget of ~1M PSP at a price of ~0.15, it would take around 8 months to capture just the $MATIC liqduitiy, and around a year and a half to capture the sushi liquidity! Considering how fast things move in DeFi, I feel this is not fast enough.
Because of this, I think it’s important for us to re-balance the budget a little, to allow us to reduce emissions a bit faster.
Let’s look back at the budget chart:
Due to the points mentioned before, I propose the following budget adjustments:
Re-allocate all sidechains’ 80/20 pool budgets to acquire them directly with bonds: Initially, the Matic balancer and beets.fi pools were added to incentivise potential future safety modules. However, it will be better for the protocol’s health if we use this to permanently own this liquidity in the safety module, as it will serve as a safer insurance.
Re-allocate secondary farm pools for PoL programmes in their respective chains: As we’ve seen with cometh vs quickswap, it seems like allocating multiple farms on one chain is counter productive, as people will just chase the highest yield. Instead, we could use these extra farms’ PSP to kickstart the PoL programmes there as well.
[?] Move the ‘future liquidity pools’ budget and undeployed chains to POL? I’m not sure about this one, but maybe it’s best we don’t introduce even more LM schemes, and instead start with bonds to kickstart liquidity. What do you think?
- Move LM budget to PoL
- Keep the budget in Liquidity Mining
Finally, in preparation to the foundation’s LM rewards running out soon:
Extend Sushi and Quickswap LM programmes. Protocol owned liquidity’s introduction functions best when running side-by side with LM.
[?] If we’re moving the budget of undeployed farms to PoL, talk with the OlympusDAO to introduce new bonding schemes for other liquidity pairs.
PS: Following feedback from the budget proposal, I think it’s best that each of these bullet points counts as a separate vote on snapshot. So don’t worry if you disagree with some of these points, I’ve made them to be mostly independent from each other!
This thread is already getting a bit long, so I’ll keep this one short. I feel that, going forward from now on, we should reduce LM emissions with every month, relative to the success of OHM Pro bonds. Because of this, we must be ready to adjust emissions depending on how well the bonding pilot goes. I’d say we could start with a 15% reduction per month, and see how it goes from here.
Final point, due to the urgency of mining rewards soon running out again, I think it’s best we plan to have this ready on snapshot by the first week of April, that way, everything is ready to deploy by the 19th and the transition is smooth.