Proposal: Improved Value Capture and Fast Lane POC

what i am pointing out is this:

  1. adding the “fee-less” feature will require poking a hole in the contracts. this risk should be evaluated carefully and only be done once we know for a fact that it is worth the hassle and possible risk.
  2. frontrunning is done only if you are successful and high profile. when this happens, it is a good sign.

again, i believe in MVP and that this should start small and grow. show that we have merit in the flow and then add more features to it.

bottom line is, you can already arb the protocol today without this extra code, so why should you not do so?

1 Like
  1. That’s fair - from my perspective, the main risk would be that someone would be able to make trades without fees temporarily (until it was fixed). @yudi do you see any other risks here?
  2. That’s not true - frontrunning happens on any profitable transaction.

To address your question:

bottom line is, you can already arb the protocol today without this extra code, so why should you not do so?

It can’t be done today without this extra code, because generalized frontrunners will frontrun any profitable transaction & take any profits for themselves. The only way for this to be viable is with the changes.

Hi @lesigh, thought I might help with answering the points you raised.You generally mention that anybody using this new contract comes only at the benefit of the protocol, whereas we wanted highlight the potential risks coming with it.

  1. As highlighted in the link, little to no highly profitable (up to $1.5) arbitrage is happening on Bancor. If you would hand out a high reward to execute those, you open the gates to any arbitrageur/market-maker keen to get a higher profit on their execution. The lower the profitability of this trade, the less these arbitrageurs will be incentivized to hang on.

  2. This is not about smart-contract risk but the potential risk that the execution behaviour of the contract can be identified and value can be extracted from the protocol rather than the other way around.

  3. The current layout mentioned by @foxsteven is as followed:

  • Contract does a BNT flashloan
  • Contract does the trades exempt from pool fees
  • Contract gives the wallet who called the function a finders fee

As we understood it, it is not the user executing the trade (and receiving the flashloan) but the contract itself. The latter would also pay the gas fees and calculate the finders fee. This results in the protocol initially covering for gas fees, not the user, and putting it at the risk of a loss. This can be abused by repetitive calling.

  1. Arbitrage trades does not have to necessarily triangular, the idea is to rebalance multiple pools at the same time rather than a single one. When you enable fee-less swapping, you could automatically adjust the spot rate by moving BNT from one pool to another.

Happy to further clarify, if needed!

1 Like

Hey, there’s always a risk when publishing new code and unexpected consequences.
Code changes should be kept to a minimum and of course tested throughly, but as always, there’s no guarantee that it’s perfect (not to say that it shouldn’t be done).

Thanks for replying Philipp. To address some of your points:
2. The link provided shows tons of arbitrage being earned on Bancor - just not into the BNT token. Regarding rewards - I think you misunderstand what is meant by reward - the reward is the tokens earned by the arbitrage trade, not an externally-provided reward. So receiving a reward of 100 BNT would require the arbitrageur to generate a profit of 1000 BNT in their transaction, of which 900 would be burned.
3. That’s a reasonable point. The contract would need to be closely monitored to ensure it is not being used to extract unexpected value.
4. The contract caller would pay the gas fee. Any other option would be abusable as you pointed out.
5. You’re right - it would not necessarily have to be triangular. I personally think Bancor V3 naturally lends itself well to triangular arbitrage anyway.


Jumping back in guys :slight_smile:

Appreciate your clarifications @lesigh and you giving us the reply and opportunity to express our views more clearly.

In general, we all agree Fast Lane is an interesting concept and innovative one even. So it’s exciting.

Our remarks are humbly shared as risk management is our bread and butter and we know it’s always easier to imagine (bad) scenarios and find mitigation avenues, before deployment than after.

I think we are landing on common ground for most points here but there are still a few things I’d like to convey.

Regarding Point 2 in particular:
The reward concept is well understood. What we’re saying is that this incentive mechanisms might not be a good one because of externalities it generates on Bancor users (due to positive network externalities on arbitrageurs). It is a crucial point since we agree on Point 1 that the normie Bancor user will likely not use Fast Lane by lack of competitive tech and exp in the arbitrage market.

So postulating the following:

The way I see it is that if arbitrageurs (or anyone for that matter) use the contract, it is a significant win for Bancor.

is true, but in my opinion the real question is not whether it is a win or not, we agree that’s a win. The question is how do we ensure the arbitrageurs actually use it. What’s in it for them? Why go through the extra step of using it? Where and how do we place the incentives?

Consider the following plausible scenario:

  • a professional arbitrageur (most certainly a bot) is finding an arbitrage on a pool having 0.5% fees and consider going through Fast Lane to execute it.
  • doing the math, it turns out the expected arbitrage profit is 10% of the trade volume, so that the reward for arbitrageur is 1%, amounting in our example to 100BNT => just equals the announced fixed cap (we exclude gas fees for the sake of simplicity)
  • it’s clear, the incentive for the arbitrageur to execute on Fast Lane depends on the cost of an external execution. At the very least this cost is superior or equal to the pool fee of 0.5%.
  • the bargain for the arbitrageur is then the following:
    • choice1: get an uncertain profit of max 1% by going thru Fast Lane (but leaving out the control over execution) or
    • choice2: get an uncertain profit of max 9.5%=[10% arb profit - 0.5% trade fee], (altho when accounting for the other execution costs the profit is certainly below 9% but surely higher than 1%), while controlling the execution as he’s used to.
  • In terms of game theory, all things being equal, the second choice is always the Nash equilibrium (which is not Pareto optimal) and is a non-coordination. This is due to the positive externality the arbitrageur benefits from the other users actually using the Fast Lane => the more users use or try to use the Fast Lane, the more the arbitrageur is incentivized not to use it since a professional arb bot will always be better at this game than Fast Lane and win the competition.
  • the expected return of this lottery for the arbitrageur a key dimension. Assuming the duplet [p, 1-p] as probabilities of gain from choice 1 and choice 2 respectively, the expected return (still excluding other costs) is E(R)=p*1% + (1-p)*9.5%, where R is the profit.
  • As a rule of thumb, due to technological advance and experience, 1-p is likely twice as high as p → p=0.33. Then E(R)=0.33 * 1% + 0.66 * 9.5% = 6.7%. The reasoning holds if p=0.5.

Fast Lane creates a positive network externality, i.e. it gives free ride on fees to all Bancor and non-Bancor users. And since the 100BNT fixed Cap profit (choice1) will almost always be lower than the Arbitrageur’s expected profit in that scenario, the arbitrageur is in fact pushed to not use the Fast Lane. In the end, arbitrageur is extracting value from the network, backfiring a negative effect to the users of Fast Lane: arbitrageur exploits the positive externality brought by Fast Lane freely.

It’s kind of counter-intuitive that in this scenario the exploit consists in not using the Fast Lane, but what’s at play is that Fast Lane (with such a fixed cap) increases the Arbitrageur’s chance of gain within the non-coordination leg because the other less advanced and informed users will want to use Fast Lane since their E(R) is much lower (probability of success in choice2 is way lower for them).

The opposite scenario would be a high fixed cap: say the expected arbitrage profit is 5% of the trade volume, and the announced fixed cap is set at 50% of that, then choice1 yields 2.5% and choice2 yields 4.5%. Then using the same probabilities, the E(R) equals 3.8%. What we see here is that the differential between choice1 and choice2 is now far lesser, hence lower incentive for the Arbitrageur to not use Fast Lane.

The most effective way to execute this incentive mechanism is by introducing a flexible subsidy/tax (respectively) mechanism into Fast Lane, which can boil down to increasing/reducing (respectively) the final extracted value to a level that is break-even with a function of the expected return E(R) of the identified arbitrage.
Also, the fixed cap entering in the calculation of E(R) should be expressed in % of trade volume, not in BNT amount, to ensure it’s homogeneous with the expected arbitrage profit. The probabilities in E(R) can be left at 0.33/0.66 and be refined afterwards, or even be distributed across a range and picked randomly to avoid further exploit.

In the above first scenario, the extracted value could be set to 6.7% at execution time of the arbitrage trade. Since the arb generates an expected profit of 10%, the protocol will retrieve 3.4% to be burned. This is less than the initial 9% resulting from the application of the proposal, but it maximizes the usage of the bot by arbitrageurs and therefore the effectiveness of Fast Lane on the long run.

Doing so, the risk of arbitrageur going outside Fast Lane and frontrunning Fast Lane users is minimized and the Fast Lane usage is maximized.

1 Like

@foxsteven Any update on this proposal?

1 Like

I expect to push to snapshot in Jan

1 Like

@foxsteven @lesigh –– happy holidays sers.

Have the ideas expressed above triggered any inspiration on your end?
I reckon this might be deemed a long and indigestible post, but I do believe the implementation of Fast Lane should come with some layer of incentives that guarantees the usage maximization by arbitrageurs.

Main questions that I see still need to be answered are:

  1. Who will build the Fast Lane and who’s paying for it? Subsequently, what are the break-even target and horizon (dev costs vs accrued fees from the bot)?
  2. What is the incentive mechanism currently planned to ensure the bot will actually be used by arb-versed users instead of them executing the arb directly as usual?
1 Like

Moved to level two - expected on snapshot today