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?”
YES: The first concrete implementation of “superfluid liquidity” WILL be multiple curves per TKN, unless some hard technical limit renders it impossible
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
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
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.
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
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)
