Proposal: Limit the trading liquidity of the Link Pool and start a strategy to optimize our liquidity

Community Chatroom (DISCUSSION) Snapshot Discussion Board
1

Proposal: Limit the trading liquidity of the Link Pool and start a strategy to optimize our liquidity

This proposal is expected to appear on Snapshot for voting on July 26, 2022 (Lisbon). Stake your vBNT for voting before this date and time to participate in the DAO decision.

This proposal is in continuation of the parent proposal, it’s function is as a pilot/trial which we can scale to other tokens if proven successful.

TLDR :

  • We pay IL on 100% of TKN available for trading
  • We get diminishing returns on new fees per unit of trading liquidity
  • If IL > fees then the protocol dies (and is already in crisis due to existing deficits)
  • B3 has the unique ability to set a cap on trading liquidity
  • Taking capital off-curve has a dual benefit of limiting IL exposure AND making it available to other revenue opportunities (native staking, etc.)
  • Currently the protocol deficit increases when LINK price increases by ~1.25x annually relative to BNT, making some assumptions, we could lift this to the protocol being profitable up to a ~4x LINK annual moon relative to BNT by limiting the on-curve trading liquidity to 3650x 30-day average trading fees + implementing some modest staking model (or similar)
  • We should set a simple cap based on the data we have and commission a more sophisticated model in the near future

Proposal:

When we look at the IL curve:

Afbeelding1

image1024×575 63.6 KB

We see that the losses because of IL are a% of all the capital deployed on the trading curve.

If TKN moons 2x relative to BNT then the IL is ~10%, a 4x moon has ~20% IL, etc.

Meanwhile, there are only so many fees due to trade volume across all of defi and almost all trades through Bancor currently are based on arbitrage and aggregators only. There is negligible trading being done directly on Bancor due to retail etc. as that market is largely monopolized by aggregators and a few platforms that take the lion’s share of human traders such as Uniswap.

In considering this proposal, please consider mainly how arb bots and aggregators will respond, not human traders, as the former is 10x+ the latter in terms of protocol fee generation.

Current situation

The below data is from both B3 and V2.1

Let’s look at how that translates to the current state of play for LINK.

There is roughly 2038752 ~ LINK on the trading curve right now, with a value of $13823850 ~

image

7-day LINK fees are 551 ~ Link with a dollar value of $3771 ~
*30-day average of LINK fees is around $1953 ( Around 277 LINK a day)

image

If we annualize this, we get 52 x 551 = 28652 LINK

28652 LINK is 1.40% of 2038752 LINK.

Setting aside mechanics like leveraged vortexing for the moment, the baseline is that the protocol will break even on LINK if IL on 2038752 LINK is 1.4% or less, relative to BNT.

That means that if LINK increases by just 25% relative to BNT over a year, all else equal, the protocol loses LINK, and the deficit increases.

Proposed

As Link staking isn’t live yet, we just want a TQ limiter to limit the potential IL Risk.

Let’s limit the LINK pool size to 3650x the 30D average fees, i.e. an APR of 10% all else equal.

This gives us trading liquidity of 3650 x 277 LINK = 1.011.050 LINK.

Around a 49.6% decrease in TQ with the above calculation.

If we assume the fees generated on 1011050 LINK aren’t significantly less than the fees on 2038752 LINK then this gives us an APR of 10% on LINK.

We spent all of Bancor v2.1 with caps on trading pools showing that 10% APR is sustainable for many TKN, but the reality of how many fees we would miss on a 1011050 LINK pool vs. a 2038752 LINK pool is something that we would have to measure and monitor.

Continuing with the assumption of comparable fees with the limited pool…

This now means that a 2x in LINK vs. BNT costs the protocol 101105 LINK instead of 203875 LINK. That is to say, over 1 year we can expect the protocol to break even on the 10% APR even if LINK moons 2x relative to BNT.

The remaining LINK should be reserved once Link staking goes live to generate another set of fees. As it isn’t live yet and the details aren’t all public, we should reserve this for a different proposal.

All we need to do is:

Limit the pool to 3650x the average daily fees calculated from the past 30 days to give a 10% APR

We could and should apply this 3650x cap to all TKN on the platform as a rule of thumb and then backfill more sophisticated analytics over time.

For many TKN we might run into a situation where the 30-day average fees are too small to support trading of any size, so we can set a minimum, which right now can be something arbitrary, like 100k BNT.

Even without a fancy simulation, it’s clear as day that the fees in no way cover the risk of IL in the pool at the moment. With just a 25% increase relative to BNT, LINK LPs would already be subject to almost double the IL. Of course, these numbers are an average over a 30-day and 7-day time span and situations can always change. Still, this would be reason enough to experiment with our TQ limiting function and analyze if we can find a perfect balance between fees earned and IL risk. As Link is a fairly isolated pool, it shouldn’t be a significant risk to the protocol. So besides just limiting the link TQ, this is also an experiment to determine if we can make a standard method to optimize our pools and thus limit IL and maximize fee revenue.

My next proposal thus is if the Link pool experiment proves to be successful, we’ll immediately perform limits on TQ following our formula (or maybe an adjusted variant) on the top 10 liquidity pools on Bancor. Below is a screenshot of our 10 biggest pools.

image
image870×397 86.7 KB

It might seem drastic to limit a lot of the current liquidity, but the fees generated at the moment cannot cover the costs of future IL. At the very least, we can optimize the current liquidity and limit our risks. All of this would give the protocol a lot of breathing room to enact its recovery plans and boost the fee-generating measures.

Voting

YES: Cap all on-curve TKN trading liquidity on the LINK pool to 3650x their 30-day average fees and cap the top 10 Liquidity pools (excluding Link) afterward if our actions in this proposal prove successful.

  • Frequency and level of automation of the cap management TBD and improved over time
  • Commit to alternative revenue generation for the off-curve capital
  • Commit to monitoring and ongoing analysis that is more sophisticated than what we present above

NO: Continue to cover double-digit annual% IL with single digit% annual TKN fees

*I took the 30-day average number from 21th of June till the 20th of July
** TQ = Trading Liquidity

5 Likes
2

@mbr

I would appreciate it if you had a look at the proposal.
I know we’re missing some data atm, but I think this is a good opportunity to gather some valuable data.
It could help if we have a solid strategy in defining what an optimal TQ is for a pool, in which we lose as little to IL as possible and make the most fees possible (relatively).

2 Likes
3

it says this is a pilot that we can scale to other pools if successful

what would a definition of success look like?

if we see that fees are reduced by some % that is lower than the % of liq we remove, is that enough to call success?

4

IMO, it is.
It proves that we have too much liquidity in a pool with our current B3 Design, with an emphasis on current.
The devs are building other solutions to generate more fees, but at the moment they simply aren’t here.
And each passing day the deficit is gonna become worse.

If we gotta attach a number to it I’d say if we are gaining 10% relatively on the liquidity set on curve, I’d call it a success.

5

I think we should stick to the custom of posting to Snapshot on Sunday’s.

If we post around the week, we are making things more difficult for voters and proposal might be less likely to hit quorum.

Having said that, it’s just a suggestion.

6

Can you please clarify exactly what should be implemented if this passes?

7

Any chance this will get on the next snapshot? Time is sadly ticking and not everyone can afford to sit it out while losing some percentage every day :confused:

8

Hey @foxsteven,

I suggest we put this proposal on hold.
I understand @mbr was already busy making some calculations.
I think it’s best if we wait for those.

For now the proposal can move to the discussion chatroom ( which I BTW did)

3 Likes
9

well did @mbr say anything about how long this will take? we are approaching 1,5 month soon. We need sth…

10

Sure - thanks @AnimaDunk

11

Its been two weeks what calculations has he come up with?