Proposal: m-m-m-multi curve

TLDR:

B3’s first “new revenue producing opportunity for superfluid liquidity” will be “more than 1 AMM curve per TKN”.

Proposal:

Currently in B3 we have the ability to take liquidity off and put it back on-curve under a single bnTKN.

Ostensibly this serves two potential purposes:

At a high level this works something like:

  • User deposits X TKN and receives Y bnTKN representing their deposit
  • Staking ledger is updated so that surplus/deficit can be tracked against deposits/withdrawals
  • some % of TKN is actively used by the protocol to trade “on the curve”
  • the rest of the TKN is set aside and is not “on the curve”

This proposal proposes that there could be N curves for any given TKN each with their own parameters.

There are several expected benefits to this:

  • We could do real A/B testing on fees/liq/etc., rather than trying to cobble together v2.1/v3 and compare data across incomparable market conditions (e.g. Snapshot)
  • We have observed that the v2.1 and v3 pools trade against each other and actually generate quite a bit of intraprotocol fee revenue due to arb opportunities, so having N curves with L/N liq each would likely generate more fees than 1 curve with L liq in it
  • We can start flexing our “superfluid liquidity” muscles and stress testing the model on something that is familiar (AMM curves) before trying to do something entirely different and unfamiliar like staking or lending, there’s no clear (public) timeline or plan afaik for rolling anything else out, “new revenue opportunities” is just something that “could” happen atm
  • If we run some experiment that goes badly, the fallout is limited to the liq bound to that curve rather than all the liq for that TKN in the protocol
  • One of the main value propositions of bancor v3 is single sided staking for project treasuries. In many cases these projects have negligible liq outside bancor, so there’s nothing to trade against, if the staked liq was split across several bancor curves this would be the same conceptually as there being a pool in bancor and uni/sushi/etc. - it’s much easier for arb bots to do their thing if there are many onchain sources of liquidity vs. a single pool that can’t trade against itself
  • Opens up potential for new ideas in the future as there may be things we want to paramaterize that would make sense in a multi-curve world but not for a single curve

Technically the way this would look is that external interfaces that are NOT bancor-multi-curve-aware (all of them) would see something that looks just like the current interface but would behave as a micro-aggregator under the hood, combining the liq/price/fees of the internal curves.

In addition each curve would be exposed to trade directly against so that arb can generate fees and keep the prices aligned. This way there is an incentive for external actors to upgrade themselves to become multi-curve aware in order to have first dibbs on cross-curve arb opportunities.

Note that this proposal is NOT saying that there should be many bnTKN pools/staking ledgers. Deposits and withdrawals and total protocol surplus/deficit all would continue to work as it always has. This proposal is saying “if we could allocate X% of the TKN to staking/lending, can we instead/also allocate it to a new BNT/bnTKN curve with different parameters?”

As far as data goes, we can see that many pools have many multiples more capital than fees they can meaningfully generate, so this isn’t academic, we could be making use of multi-curves right now for many TKN in the protocol folio. (see Proposal: Limit on-curve liquidity to max(520 x 7 day fees, 100k BNT) - #38 by thedavidmeister for discussion on that)

Voting

YES: The first concrete implementation of “superfluid liquidity” WILL be multiple curves per TKN, unless some hard technical limit renders it impossible

NO: No changes/requirements to Bancor roadmap

3 Likes

i wonder, assuming the trade liquidity is always split to 3 to create 3 curves with 3 different fee points. (i.e 0.1%, 0.5%, 1%).
this means the impact on the trade would result in 3 different outcomes and therefore 3 different route options for every token.

the down side is less liquidity per curve which will result in higher slippage.

not sure if this is technically doable and if so how.

yes the downside is less liquidity so some more slippage assuming the curve itself remains standard constant product, which could also be experimented with as other AMMs have done

also consider the linked data, which is that we observe little impact on fees for different liquidity past some point



one of the main criticisms of this data ^^ that i’ve heard is that the giant peaks in the middle are likely indicative of market conditions rather than due to that being some magical amount of liquidity that results in more fees

having a huge pool split into 2-still-quite-large-pools would allow for A/B testing that gives us data that doesn’t have to be discarded simply because the macro environment was busy/quiet for one data point vs. another

in fact, having multi-curve is something i’d like to have specifically so we can find out how much liquidity is ‘enough’

imagine if we took a large pool and kept 90% of it on curve and split off a tiny 10% - comparing how those two perform over the same time range would give us a lot of information about how tightly correlated slippage is to revenue, the main pool would still function 90% as it always had but we’d be able to ask much more interesting questions of the data we have

in one sense i know it is technically doable because other AMMs and aggregators already do this

in another sense i don’t know what would need to be done to make bancor work this way, so i’m not sure about that

@yudi Would appreciate you sharing some insight about if it is doable for Bancor and if yes how hard/time intensive it would be.

V3 design was created to be optimize for routing to reduce path gas costs.
this means that it only supports 1 pool per token.
also, the entire design is based on the fact that the token address = pool address for simplicity.

given that, i would assume that creating multiple pools might be very difficult.
however, since the trade rate is simply a calculation, maybe there is an option to create multiple calculations on the same pool.

yeah this is the proposal, the “pool” as the bnTKN and associated staking ledgers would remain unchanged, it’s purely about the trading calculations

think of it like a “virtual aggregator” between “virtual pools” so that we can say “half the liquidity has 1% fee and the other half has 2% fee” then measure the difference in performance between the two, but in reality all the liquidity is still in the same vault/pool/bnTKN

1 Like

I think that having the ability to create different types of pools for the same token is beneficial. This would allow us to do:

  1. Pools with the same token at different fee levels
  2. Pools with the same token with different weights 50-50, 80-20, etc…
  3. Pools with the same token and different bonding curves (we will have more than 1 in the future that’s not just x*y=k)

I am sure there are others but I am generally supportive of this proposal.

To my understanding this refers to still having a single pool per token but each pool operates with multiple bonding curves.
New bonding curve implementation (regardless of how it’s used) is probably a multi-month process, as these math functions generally take long to implement/test in solidity and attack vectors are a bit more challenging to assess.
Applying the bonding curves to a pool - very hard to say without a spec that outlines exactly how these are used. It can be a few weeks to a few months.

1 Like

To my understanding, the proposal doesn’t involve multiple pools for the same token.
Multiple pools for the same token is of course also doable but will require a redesign of v3 as 1 pool per token is one of the fundamentals of the v3 design.

hmm, the way I understood it is that we want to have the different pools for each token and each pool will have different amounts of TKN on curve so that we can do a/b testing. I am not sure about implementation details under the hood but this seems to suggest that we would need to support multiple pools for the same token.

Not necessarily - multiple curves can be implemented in a way that each pool manages them internally.
So in practice there are multiple pools but externally it appears as if there’s only one.

this is my understanding that this would be The Bancor Way to do it, yeah

treating each new curve as “superfluid liquidity” so we take liq off one curve and add it to another, same as if we were to take TKN off a curve and do native staking with it for example

IMO a few months of work to unlock such a big thing as realtime A/B testing sounds very reasonable :smiley:

When are you starting to implement this? :smiley:

1 Like

last i heard there were “new revenue streams” coming soon, so i assumed someone was going to work on that :sweat_smile:

2 Likes

also, to be clear this proposal doesn’t include new bonding curves, it’s just saying that could happen in the future (but is out of scope right now)

for now it would be a big win to just have 2 identical standard constant product curves but with different parameters, e.g. one curve using 1% fees and one curve with 2% fees

that already gives us the ability to A/B test the impact of liq/fees on protocol metrics without needing to handwave away external market conditions (which seems near impossible to do in practise)

1 Like