Preventing Front-Running attacks in a CO


#1

A friend sent me this great post from Relevant which explores also the use of Bonded Curves (using the same paradigm as Bancor). Like for Bancor, I find it kind of hard to understand the model they propose (it seems very abstract to me… but maybe that’s just me).

The article also refers how Bancor prevented Front-Running attacks in their contract.

Bonding curves are susceptible to front-running attacks. This is when an adversary watches for a big buy order coming in and sends her own buy order with more gas to cut ahead of the original order. Once the original order is executed, the attacker sells her tokens at a guaranteed profit. […] Bancor’s proposed solution is to set a limit on gas price buyers and sellers can submit and encourage everyone to use the maximum allowed gas price when sending their orders. This prevents the adversary from having their order executed ahead of the already-submitted orders.

This is a nice and simple solution that we should implement in our MVP.
However I think another, maybe more elegant (but also more complicated to develop), solution would be to implement a regular “price fixing”. It means that instead of the buy/sell order being executed immediately, they are instead batched into a pool of orders and, say every 6 hours, the contract executes the trades taking into account the orders registered in the order book. It means that the trades are not executed immediately but it has the immense advantage of preventing front-running attacks. This is how the Gnosis DutchX Decentralized exchange works:

Hence, with batched orders entering the block at the time the auction clears with the same price for all bidders and sellers , neither miners nor the exchange itself, or other participants will be able to game the system.

In conclusion, I think that such a system does not penalize liquidity much if the price fixing is regular enough (every 6 hours in the case of DutchX) but has the huge advantage of preventing front-running.