Proposal: Limit on-curve liquidity to max(520 x 7 day fees, 100k BNT)

Deprecated Proposals (NOT SUBMITTED)
1

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 ETH price increases by ~1.5x annually relative to BNT, making some assumptions, we could lift this to the protocol being profitable up to a ~4x ETH annual moon relative to BNT by limiting the on-curve trading liquidity to 520x 7 day 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:

image
image1024Ă—575 63.6 KB

We see that the losses due to 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. That is to say, 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

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

There is 8807 ETH on the trading curve right now:

image

7 day ETH fees is 4.6:

image

If we annualise this we get 52 x 4.6 = 239.2 ETH

240 ETH is 2.7% of 8800 ETH.

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

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

Proposed

Let’s limit the ETH pool size to 520x the 7 day fees, i.e. an APR of 10% all else equal.

This gives us a trading liquidity of 520 x 4.6 ETH = 2392 ETH ~= 2400 ETH

If we assume that the fees generated on 2400 ETH aren’t significantly less than the fees on 8800 ETH then this gives us an APR of 10% on ETH.

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 2400 ETH pool vs. an 8800 ETH 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 ETH vs. BNT costs the protocol 240 ETH instead of 880 ETH. That is to say, over 1 year we can expect the protocol to break even on the 10% APR even if ETH moons 2x relative to BNT.

We also have 6400 ETH freed up to generate fees. Native staking on ETH yields about 3%.

6400 ETH x 0.03 = 192 ETH ~= 200 ETH

Assuming we do the most conservative thing other than doing nothing at all, use the native ETH staking mechanism, we now have a budget of 200 ETH from staking 6400 ETH and 240 ETH from a 10% APR on 2400 ETH to cover the IL on 2400 ETH.

With 440 ETH we can cover up to ~18% IL on 2400 ETH which allows ETH to annually moon ~4x relative to BNT

Clearly a 4x annual moon is a significantly larger safety margin than a 1.5x annual moon.

All we need to do is:

  • Limit pool to 520x the 7 day fees to give a minimum 10% APR
  • Move the off-curve liquidity into a conservative yield generating mechanism offering 3% e.g. native staking

Generally we could and should apply this 520x 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 7 day fees are too small to support trading of any size, so we can set a minimum, which right now can be somewhat arbitrary like 100k BNT.

Voting

YES: Cap all on-curve TKN trading liquidity to 520x their rolling 7 day fees

  • 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 is presented above

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

8 Likes
2

Is this for all tokens or just for ETH?

3

So this would be v3 pools only? Would the migration of v2.1 pools to v3 pools be a net positive for this proposal?

All in all I really like the proposal, especially since it brings a significantly larger safety margin

4

yes all tokens @foxsteven

i used ETH as it’s a notable example but the same IL vs. fees logic applies to every TKN

anything with more than 520 x 7 day fees in trading liquidity is by definition bringing in less than 10% APR

if anything, TKN that don’t even have theoretical alternative revenue streams while simultaneously having the potential to moon even more than ETH due to illiquidity should have tighter limits (e.g. 260x fees), but let’s just start by establishing a baseline and we can do more fine grained analysis once the elephants in the room are addressed (8800 ETH @ 2.7% APR with existing deficit :sweat_smile: )

1 Like
5

@omegagrey777 this proposal is for B3 yes

i’m not sure what to do about unmigrated liquidity, i suppose it will keep taking unlimited IL that will eventually be dumped into B3 as fresh deficit

6

image
image961Ă—1280 104 KB

here’s an idealised and rough diagram of what i’m proposing and how i imagine this working in my head

if you have y-axis representing TKN inflow/outflow and the x-axis representing trading liquidity

the IL is just a straight line that goes up, absolute expenses go up as TKN on-curve goes up, the slope of that curve is just whatever the price difference with BNT is, but it’s a flat line

the fees however have some kind of curve, in this diagram it assumes that fees look like:

  • when TKN on curve is very low fees are near zero as trades have super high slippage so even arbs/aggregators won’t touch it
  • at some point the trading liquidity starts to become competitive so fees ramp up quickly
  • at some point the majority of all possible fees are being realised so the benefit of more TKN on the curve starts to plateau

in a setup like this, there’s some “goldilocks zone” which is profitable for the protocol (fees > IL), and all trading liquidity above or below the profit zone leads to a deeper deficit for the protocol over time (IL > fees)

1 Like
7

Finally a proposal based on real assumptions with real data. You have my support.

So if I understand well, we wouldn’t generate more IL with this, so the existing protocol’ deficit will only decrease with time, and at the same time we would keep good APR by staking TKN?

8

yes if all the assumptions in the proposal play out, for ETH at least we’d have a profitable protocol (deficit improves) right up to ETH mooning 400% vs. BNT annually

some IL would still exist, but it would be less than trading+staking fees overall so the deficit would heal and eventually become a surplus, all else equal

right now the protocol can only be profitable if ETH doesn’t outperform BNT by more than maybe 30-50% annually, which to be honest sounds to me like playing with fire as ETH is a very aggressive asset

i did cheat a little bit in the proposal by including native staking numbers - a lot of TKN don’t have native staking options

but let’s say we ignore staking completely and just take everything except 2400 ETH off-curve and do nothing with it, that’s still a 73% reduction in annual IL expenses

if you don’t believe all my assumptions but still believe we can get at least 1.25 ETH per week in fees from a 2400 ETH curve, then you should still vote YES as it’s less bad than the status quo :sweat_smile:

5 Likes
9

also FYI, on this day July 21 2018 BNT was about 0.005 ETH and is now about 0.00033 ETH

in 4 years ETH has done about a 15x over BNT

if we could offset the annual IL from a 4x in price then this would be 4^4 for 4 years = 256x

as 15 < 256 the past 4 years would have been profitable under this model

also these numbers are suuuuuper rough, just trying to show some scale here with historical perspective

10

The pools with the biggest USD deficit have it (or will have it soon though). Might be also worth to run some numbers for the LINK pool if you include being part of the 5% native staking that will go live this year?

3 Likes
11

This is basically one of the reasons B3 was developed.
We need other reliable ways to deploy our staked capital, instead of simply throwing it all in the trading liquidity and hoping fees will outpace IL (Spoiler alert, a lot of times it doesn’t).

I completely agree that we should find other ways to deploy the capital, like as in your example natively staking it.
This proposal should also be our entrance to actively managing the TQ of our other pools.

For those who don’t understand the point that David is trying to make it basically boils down to the below formula:

IF IL > Fee Profit - Launch or increase IL minimization strategy ( Limiting TQ, increasing swap fee, deployment to alternative revenue)
IF IL < Fee Profit - Decrease IL minimization strategy (Increase TQ, stabilize swap fee, decrease deployment to alt. revenue)

Of course, there’s always some situation-specific leeway, so decreasing alt. revenue for example could be a bad choice if the alternative revenue is bringing in more than even the fees in a low IL scenario.

1 Like
12

Super interesting.

It would be cool to simulate this, generate some results and add them back into the proposal.

If you are interested, you know how to reach me.

5 Likes
13

image

now

liquidity = 2 million link
7 day fees = 550 link = 0.0275% APR

so we can afford to cover the IL from a moonocity of… let’s just call it an even 1x :rofl:

with proposal

520x 7 day fees = 286 000 LINK
annual revenue = 28 600 LINK (10%)

native link staking = 1 714 000 @ 5%
annual revenue = 85700 LINK

total revenue from trading+staking = 114 300 LINK

114 300 / 286 000 = revenue can cover IL of 40% annual for on-curve liquidity

40% IL = ~8x annual moon LINK vs. BNT

2 Likes
14

I would love to see the results of the simulation before voting on this.

I’d like to know the impact lowering liquidity would have on fees. If fees drop, do we have to lower liquidity again?

Might be interesting to try out on 1 pool first and see how it goes.

15

I’d like to know the impact lowering liquidity would have on fees. If fees drop, do we have to lower liquidity again?

yes and if fees improve we can increase liquidity also

point is just to convince ourselves that we’ve found the best possible balance of fees vs. IL exposure, with the data we currently have

that’s why in the proposal i left a space for implementation details like automation, frequency of recalibrating, etc.and an explicit commitment to ongoing modelling

Might be interesting to try out on 1 pool first and see how it goes.

yup seems reasonable

2 Likes
16

This and:

This.
Are 2 of the reasons that B3 is such a big improvement over v2.1. We should be using the new features to our advantage.

@mbr we are currently just pulling data from the API manually and taking rough guestimates on APR and TVL. If there is a Working Group that exists or can be setup to work on a subset of pools that would be a good start.

Personally I see ETH being a tricky pool as it is involved in more “hops” than most other pools so using something like LINK might be a better start.

1 Like
17

I’m concerned that 7d fees might be too volatile of a metric to base liquidity decisions on. We’ve seen that crypto can have a really quiet 7 days or an extremely volume heavy one.

I suggest analyzing over a longer time period for a more reliable metric to react off of. Something like last 30 days of fees might be a better metric for this.

1 Like
18

If there is a simulation available then sure. But at some point we have to pick a value and start from there. I’ve been in favor or dropping ALL pools to 100k BNT cap until we have better analytics setup.
This seems like a compromise and is at least semi-data based and gets us a starting point that we can test on subsets and adjust all other pools once we have a process in place.

@foxsteven Using 7-day fees allows a weekly DAO proposal and adjustment flow as well.

19

i think that’s totally reasonable too, a 120x of 30 days fees might be better

20

for sure, the risk to NOT doing this is that we remain fully exposed to IL on… 2 MILLION LINK that the protocol currently owes 3.7 MILLION LINK on the staking ledger for

whatever analysis we do as a first pass can only be that which can be done on short turnaround imo

LINK and ETH alone both have strong narratives (staking and merge respectively) coming soon and big deficits on the books for the protocol, if either one moons and we’ve taken zero steps towards limiting our exposure, it’s going to be quite bad

3 Likes