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

Thanks for your proposal, very well explained and very interesting. I hope Bancor team willl accelerate things now.

1 Like

Agree, this proposal almost sounds like a nobrainer.

  • If we combine it with the migration of v2.1 positions, all of the v2.1 positions would be net positive capital, because it won’t be part of the on-curve liquidity in this case. This would give us a lot more off-curve capital to put in native staking and thus making the protocol much more resistent against these moon scenarios.
  • We need to make a fast decision on the 2.1 pools though, because they don’t have the technical ability to limit on-curve liquidity and thus are a threat to collecting unlimited IL if stalled I think.
1 Like

small update on this is that @tfns and i are looking into producing a simple scatterplot that plots every 24hr fees against liquidity on that day for every day across all time

right now i have no idea what that will look like so i don’t want to speculate too much until i see it

this is separate to simulations, what i’m looking for here is a way to visualise the real onchain trading data

at this stage i don’t really care why fees might be higher or lower at different liq levels, i just want to show at a super high level how things have played out so far


so small update:

  • i got slammed with work so had not much time to do anything this week
  • something to be mindful of is that if we take a lot of liquidity off curve it changes the dynamic between BNT price and the deficit, i.e. less BNT liq => BNT price movements change the surplus/deficit less
  • i really need to get a mac so i can install tableau, seems like it’s the standard for bancor moving forward, but in the meantime i can maybe do some clojure scripting
  • there is actually going to be an ongoing liquidity optimisation strategy “soon” which is great, it’s not going to require random ppl to put proposals up ad hoc

what would happen in the event of a # of large wallets or another mass exodus occurs in a particular pool.

If the funds have been deployed in another revenue generation protocol, then the pool itself may not be able to handle the withdraws … then might that not lead to a similar situation as to what we are facing today?

@Jindo yes for sure, liquidity of the revenue mechanism itself is important to consider

obvious example being stETH vs. native ETH 2.0 staking

if we used stETH directly then the surplus/deficit would reflect the stETH peg, so if people exited then the protocol would do a swap from stETH back to ETH and pay those that exited according to revenue vs. peg situation

if we natively staked ETH 2.0 ourselves then the deficit would look like 100% for all funds locked in ETH 2.0 until withdrawals are enabled natively for ETH staking, after which point those funds would become available again + staking revenue - anyone who was withdrawing while the ETH was locked would effectively be donating that locked stake to everyone who remained (i think it’s clear why stETH is so popular…)

do you know how long it will take or a better definition of soon? linkchart is killing me and im close to withdraw but i really dont want to.
Thanks for your contribution in your free time!

as i understand it the analysis is happening already, the bit that is “soon” would be figuring out how that fits into a DAO decision making/feedback loop

1 Like

@thedavidmeister I went ahead and did some analysis for your proposal using actual data. The last section still needs to be completed, but should be able to finish up later today - research/limit_tradingliquidity_proposal_study.ipynb at quickstudies · bancorprotocol/research · GitHub

1 Like


ok so this is only b3 data, which we have a lot of reasons to be a bit skeptical of

still, it’s better than nothing

the crazy spikes in fees in the middle are probably NOT indicative of some magic liquidity zone and more likely to be due to broader market conditions on those days

sadly i don’t think we have enough liquidity in the protocol to test that that :sweat_smile:

what i’m NOT seeing here is a clear trend like “when we double liquidity our fees more than double”

there is a tiny bit of data near 0 during which b3 was bootstrapping i guess

then we blow way past any kind of curve that we could measure into the millions of $ for all three curves

at this point LINK gives maybe a 1.5x for a 2-3x in liquidity, DAI doesn’t seem to care how much liquidity it has and ETH has a link-esque modest improvement for a 3.5x in liquidity

Is someone alive here? This conversation has been going on for almost a month now… When level 2?

1 Like

i think there’s some bar that needs to be met re: use of the simulator, and i only recently got setup with tableau, let alone the python scripting

i do wish that other proposals like “max all the curves” first started as a discussion on this existing thread

1 Like

This would be VERY nice to see before ETH and LINK raised significantly against BNT. As far as my perception goes this should be top priority.

there’s an argument against doing this that should be presented here @glenn

i don’t want to mangle it, as i’m not sure i agree with it, so it should come from the source

1 Like

Wanted to let everybody know that tomorrow (Thursday 8/18) I’ll be doing a demo/presentation of the simulator using this proposal on Discord. Mark will be joining to facilitate the discussion as well. Along with all of the instructions and code to replicate the simulation, we will make the summarized results available here in governance for anybody interested.

The demo will be recorded for anybody to watch on their own time, but if you’d like to join for the live session we’re planning to start at noon Eastern US (New York) time.


This proposal has had no activity since the 17th of August. Can I archive it @thedavidmeister ?

Did this just die out? What happened to this proposal to limit IL. Please correct me if I am wrong but as this proposal states, deficit is just increasing?

I would say that the Almanak proposal is trying to achieve a similar outcome (bring in more fees and lower the deficit) and is very much within the spirit of this post. You can track the Almanak proposal on the following post:

note that for now, this is only targeting the wBTC, DAI, ETH, and LINK pools. Regarding the deficit, you can track those for any v3 pool or protocol wide via

1 Like