Proposal to introduce a small pool standardized fee (0.3%) based on market cap ranking

I would like to discuss the interest in making a proposal to raise the minimum swap fee on all pools to 0.2%. This is the swap fee used by the majority of Bancor pools. The only large pool that is below this is (I believe) ETH/BNT, which was recently raised from 0.1% to 0.15%, with no obvious ill effects (although perhaps this has not been monitored for long enough to see if this is in fact the case).

A rise to 0.2% swap fee would contribute to the long term sustainability for the protocol, especially as we seek to grow the volume traded through the long tail. Additionally, small pools suffer considerable slippage, and a small increase will be unlikely to make much of a difference to volume, especially since we are in some cases the only liquidity pool available. A 0.2% minimum could be brought in as a pre-set minimum for all new pools.

1 Like

I disagree with the assertion of “no obvious ill effects” and agree with your comment about the pool not being monitored long enough. I am hoping that after 30 days (changes have been live for ~15 days) we will have some data that the Bancor folks can potentially present to the community about the effects of this change. Until then, I won’t be supporting any proposals to increase fees on the ETH pool and I will caution the community against doing so.

FYI, the fees are currently set by the owner of the pool at creation time. They can later on be modified by the owner of the pool through the pool contract. My guess is that the vast majority of non-whitelisted small pools are not owned by the Bancor DAO and hence we won’t be able to modify the fees on those pools unless the ownership gets transferred over. I think we could potentially enforce a minimum pool fee via the UI during pool creation if we wanted to go in that route.

There is also the question of V3 and what effects that will have on pool fees. If greater capital efficiency drives more volume, then I am wondering how pools fees will play into that equation.

3 Likes

I think it would be a reasonable requirement for all whitelisted pools to be 0.2% minimum. They benefit from IL insurance and increasing the kickback into the protocol (through the vBNT burner) is a reasonable thing. Even more so if there is a BNT coinvestment as these swap fees will accrue to protocol owned BNT. This may only be possible on new pools - I don’t know if there is any way to adjust preexisitng pools. Clearly there are big things afoot with V3, but that doesn’t mean we should stop offering up ideas for discussion and even implementing them.

1 Like

Fees have been a polarizing topic in the Bancor community since the launch of v2.1:

From some of the experiments we have run over the last 8 months, we have learned a few interesting things:

  • Specific trade paths cannot be ignored. The overwhelming majority of 2-leg trades occur from the ETH pool, and so all changes to the ETH pool fee impact swaps across the protocol at a disproportionate rate.
  • The pool fee has a small impact on trade volumes in general. When we dropped the pool fees across all pools to 0.1%, the volume remained relatively unchanged. Then, when we increased the fees again to 0.2%, the trade volume was similarly unchanged.
  • High pool fees are easily tolerated if the slippage is low compared to the ecosystem overall. wNXM is the best case-in-point; we have the deepest source of liquidity by far, and a 1% pool fee does little to perturb traders due to the slippage more than compensating for the increased commission.
  • During periods of high volatility, fees can and should be higher. A dynamic fee has been a topic of debate within our own community for a long time, but Kyber will likely be the first to implement it (see below).

To my mind, this kind of dynamic fee structure is the best course of action, not just for Kyber or Bancor, but probably for all AMMs.

4 Likes

long tail assets should have much higher fees:

1 Like

I agree about long-tail pools being able to readily accept higher fees. I think 1% would be a reasonable standard. This is likely to be a trivial expense versus slippage. The tricky question is how to define a long-tail pool and what is the threshold effect - how to we manage the swap fees in a pool going back and forth over a threshold? For larger pools the critical issue is not the size of the swap fees alone, it is the swap fee + slippage. Aggregators will route traffic based on the total cost. If we have the deepest pools with the smallest slippage, we should be able to charge higher swap fees, up to some point. I agree that the BNT/ETH pool is probably a special case that should be treated separately, and excised from any proposal that goes forward. I think it is a simple argument to make that we are not supporting the long-term health of the protocol by having small pools at 0.1% swap fees - the minimum fee should be higher; is 0.2% high enough? Ultimately, LM rewards will run out and already have on some pools. IL protection may keep some LPs in these pools for a while, but unless we can make the APYs attractive, they will eventually leave and liquidity will be lost, leading to higher slippage on trades and reduced liquidity. Ultimately traders will leave if they can get better trades elsewhere. It is important to get the APYs higher to retain LPs, and this can, in principle, be done by careful increases in swap fees.

2 Likes

I can think or two options.

  1. Anything not in the top 300 on coinmarketcap
  2. We do it one by one
1 Like

I think a better ‘long tail’ definition would be by reference to its contribution to the protocol. Thus it could be a pool with liquidity < 0.1% of total liquidity. Or perhaps <0.01% of total liquidity.

1 Like

Just to clarify the swap fee paradox:
Low fees can attract more swap volume, but are unattractive to LPs, and this leads to smaller pools with greater slippage and higher costs for traders. The challenge is to find the middle ground where both LPs are happy and traders are attracted.

LPs want to maximize (swap fees x volume), whereas traders want to minimize (swap fee + slippage).

2 Likes

Are you suggesting this be done in real time by a smart contract? Or as a quarterly exercise?

2 Likes

Good question. A real time script that constantly checks whether total liquidity (or total volume?) in a pool is some agreed proportion (<0.01%) of total Bancor liquidity (or volume) would seem a fairly low overhead approach, but we would need agreement on what is the small pool swap fee (maybe 1%), with it changing to another amount (perhaps 0.5%) once it gets a bit bigger (0.01-1%). Anything larger than this could be tailored for each pool on a pool-by-pool basis, since the larger pools will probably have sufficient interest that they will merit individual votes and have enough interested parties to vote.

3 Likes

This might be impossible to achieve without an oracle, and the overheads can get prohibitively high.

For example, consider how this might look from the contract perspective:

  • The contract runs a for loop over the pools (prohibitively gas-intensive)
  • For each pool, a calculation is made to determine the state (volume or depth)
  • An if statement is used to determine the outcome (also prohibitively gas intensive)
  • A contract interaction is used to change the pool fee

Some important questions here are:

  • How frequently is this being done?
  • Who is paying the gas to run this?
  • How are they incentivized?
3 Likes

Mark, Thanks for giving some thoughts on the practicality of these pie-in-the-sky ideas. Can you answer the following questions, which may help to get this discussion to a point where it can be worked up to a proposal:

  1. Can the DAO vote to change swap fee on any existing pool?
  2. Is it feasible to ask Devs to manually change the swap fees of all small pools (say each <0.1% of total Bancor liquidity) to perhaps a minimum of 1%, and all others pools (except ETH/BNT) to a minimum of 0.2%?
  3. Any thoughts on an automated way to achieve these settings so that if pools grow or shrink they can be modified?
  4. Any critical risks that you can think of for having 1% and 0.2% (except ETH) as minimum swap fee settings for small and large pools?

If the long tail is to become an important part of Bancor’s future, I think there is a good argument for growing modest swap fee income from the tail to make it worth our while. This is where we will likely end up with a niche that other DEXs will not be interested in. Small pools will not be interested in diluting what limited liquidity they have in other DEXs across multiple pools. As well, if they are seeking to grow liquidity, there will be an incentive to grow with Bancor past the 0.1% small pool threshold and bring proposals for swap fee reductions to a DAO vote.

1 Like

My pleasure, Spencer. Happy to answer your questions:

  1. Can the DAO vote to change swap fee on any existing pool?

Yes, almost 100%. The DAO has taken ownership of a lot of pools, but even the ones that are still under the ownership of other users, we can still vote to change the pool fee. If the pool fee isn’t changed at the DAO request, we can remake the pool and migrate the liquidity. Basically the DAO power is absolute.

  1. Is it feasible to ask Devs to manually change the swap fees of all small pools (say each <0.1% of total Bancor liquidity) to perhaps a minimum of 1%, and all others pools (except ETH/BNT) to a minimum of 0.2%?

Not unreasonable at all. We have had these kinds of proposals previously (see BIP3), and broad changes were implemented without too much hassle. The problem is more about finding the right fee to set. I think for a lot of pools, something like 0.5% might be a better start than 1% - but there is already a proposal to increase ICHI to 1%, so let’s see how that goes.

Any thoughts on an automated way to achieve these settings so that if pools grow or shrink they can be modified?

In all seriousness, a chainlink oracle might be the perfect solution. The overheads are high, but the value capture might be worth it. The trouble is still defining what the behavior should be, and I am watching Kyber closely to see what the impact actually is. I am convinced a dynamic fee structure is essential in the long-term, but it is also something of an optimization. I don’t think it’s not our biggest priority, but something we should all remain mindful of.

For now, frequent proposals suggesting fee changes are probably a good idea.

  1. Any critical risks that you can think of for having 1% and 0.2% (except ETH) as minimum swap fee settings for small and large pools?

Almost none. We need to be careful with the ETH pool, as it is the gateway token to the majority of trades. Keeping its fee low draws in more aggregator traffic, which is positive. A 1% fee is quite high, and might be bad for optics. However, for smaller pools with little or no other liquidity sources, probably not terrible.

3 Likes

At a time where Bancor should be focusing on Growth over Profit, I think it’s the wrong move to require the minimum fee to .2% for all pools.

The main advantage that Uniswap and Sushiswap have over Bancor is that only 1 swap is required for most trades, and that swap generally has a .3% fee.

Swapping from ETH <-> TKN now generally costs .35% with ETH set to .15%.

Furthermore, it’s still early, but it looks like Bancor has LOST Volume Market Share since the change. This is not a great way to approach growth.

I suggest that we first focus on becoming the #1 DEX in Crypto and then figure out how Bancor can increase revenue/profits for investors.

3 Likes

Credit to Tiago for the graph

1 Like

Furthermore, if we consider ETH a gateway token, then we should also consider WBTC, DIA, USDT, and USDC gateway coins.

I suggest that we strongly consider decreasing the fees for those pools from .2% to .15%.

That would allow us to match competitors at a .3% trading fee from one gateway token to another.

It will also help bring the cost down from non-ETH gateway coins to other tokens on Bancor from .4% to .35%.

If we want trade volumes to increase, then Bancor’s fees should be competitive. Especially at this stage.

3 Likes

Thanks a lot for all these comments (especially TheOneJM) and the lovely graph of DEX percentage. The decline in DEX percentage may also coincide with the rise of L2 solutions, in particular Polygon, and it will be important in the future for Bancor to have a presence there.

Based on all the discussions, I think this proposal is starting to coalesce around setting a base swap fee for the smaller pools on Bancor, and leaving the larger pools alone. Setting an appropriate swap fee for the larger pools is definitely controversial and a tricky issue, and I think would be better addressed either on a pool-by-pool basis or in a separate proposal. As mbr comments, there is potential for using dynamic fee pricing and so this would be a possible solution for a future proposal.

As it stands I am leaning towards proposing a minimum swap fee of 0.5% for pools under $250,000 liquidity, being pools that are <0.02% of total Bancor liquidity (and not touching larger pools, which are typically less). For a $1000 trade, this swap fee will be much less than slippage (approx 0.8%) and so is proportionate for even a relatively small trade. For these small pools, Bancor remains a great place for their tokens as it lets them concentrate all their liquidity in one pool, and two-leg trades will then tend to be a max of 1% or less. This proposal would not affect the top 50 or so pools, and any pool could subsequently put forward a proposal for vote changing their swap fee.

1 Like

how far are we from dynamic pools?

1 Like

Honestly, it’s more of an optimization than anything else. Pretty low on the priorities right now. I’m happy to watch what others are doing and use their data to design our own system. We have time.

Until then, we can still experiment with our own pool fees. We have recently changed the fee on ETH - let’s pay attention to the trends and see if we can convince ourselves there is a definitive result. @eldude has previously suggested changing the fee on just one of the stable coin pools. We have done this previously, but might be time to try again.

2 Likes