Destiner's Notes
Blog

Trade Execution Coordinator (TEC) Primer

13 July 2019

Here’s is the “how & why” explanation of Trade Execution Coordinator (TEC) by 0x. This primer is structured to be a top-down guide of the TEC, starting with a high-level overview and then going into details.

Frontrunning

In the context of decentralized exchanges, frontrunning is a condition where multiple traders try to execute the same order. Of course, only one of them will succeed, while the other one will fail. Frontrunning introduces several inefficiencies:

Accidental

Frontrunning doesn’t have to be malicious. Two users just need to try to fill the same order. Due to the asynchronous nature of public blockchains, a trader can even try to fill the order after it was already successfully filled by another trader.

One “feature” of accidental frontrunning is that it gets worse as more users join. Essentially, all traders compete for a few top orders in the orderbook. At the moment, usage of decentralized exchanges is relatively low (average number of trades on 0x is 1000-2000 trades per day), so the problem rarely occurs. In the future, accidental frontrunning can affect a large share of trades.

Malicious

This type of frontrunning happens intentionally. At least one of the competing traders is aware of the race condition and acts accordingly.

Frontrunners are driven by profit opportunity. They execute sophisticated arbitraging strategies, trying to buy low and sell high. Arbitrage might involve multiple assets and exchanges (e.g. sell A for B on X then sell B for C on Y then sell C for A on Z).

Arbitrage opportunities usually arise from two vectors: price difference and fat-finger errors. Decentralized exchanges are far from being efficient, so there’s a lag between price updates on different DEXs. “Fat-finger error” refers to the trader’s mistake during order creation, resulting in a highly unfair price. Fat-finger errors spawned a handful of opportunities on EtherDelta (sometimes, worth of several ether), as the UI didn’t validate the price input and the users confused order volume with the price.

When there’s a price difference, arbitragers compete with each other, trying to fill the order while not spending too much on gas. As for the fat-finger errors, arbitragers additionally compete with the trader itself that tries to cancel his order.

Pooled decentralized exchanges (Uniswap, Kyber, Bancor) also has frontrunning issues, but its nature is different, the solution is different, thus it is outside of the scope of this article.

Solution

To mitigate frontrunning, an exchange needs to implement a way to orchestrate the trade requests. Such a mechanism could be centralized or decentralized.

Current approach

IDEX offers coordination by offering a hybrid settlement. When a trader executes an order, the balances of maker and taker are updated in the internal database so they can make subsequent trades. At the same time, the execution transaction is placed into a queue. Transactions sent to blockchain in order of their origination, effectively providing trade ordering. This solution offers virtually an instant settlement, soft cancels, and frontrunning prevention. As a drawback, users have to wait until the queue will process all their trades before withdrawing any assets, although they can request a withdrawal at any time.

0x offers a similar solution with the matching orderbook. A relayer employing that model only accepts orders that specify relayer’s address as a taker. Relayer then looks for overlapping orders and execute them on behalf of the users. As relayer is the only party that can execute the orders, frontrunning can’t happen. However, relayer is trusted to process all offers and serves as a single point of failure.

Trade Execution Coordinator

0x plans to introduce an execution coordinator. In its final form, it should eliminate frontrunning for all orders in the pool of shared liquidity, while being fully decentralized.

Essentially, such a coordinator would be a taker of each order. Traders would need to get approval from the coordinator to fill orders. The coordinator would ensure that the order is valid for execution and that no one previously claimed to fill it. In that case, the coordinator signs the order and passes the signature to the trader. As that trader is the only one who knows the signature, only he can execute that order.

The coordinator would also allow soft cancels, i.e. market makers being able to cancel their orders without submitting the cancellation transaction on chain. It’s worth to note that soft cancelled orders can still be filled in case coordinator will be compromised, so the order expiration time should be set reasonably.

Orders are submitted to 0x via Coordinator contract, which serves as an intermediary between maker and taker. Such contract can fill orders signed by different coordinators, as well as not signed at all, in a single transaction, meaning that even in the event of centralized coordinators, orders from different sources preserve fungibility to some extent.

TEC may be implemented in a centralized manner (e.g. a program running on a single server that processes each execution request), as a complete decentralized mechanism (where everyone can apply to participate, and censorship or collusion is impossible by design), or anything in between. In any way, TEC is an off-chain service that runs outside Ethereum network (though, with the notion of it). TEC is not connected to a particular relayer, although a relayer can implement its own coordinator. It can be another blockchain or a similar network of peers.

Live: Bamboo Relay

Bamboo Relay ↗ implemented a coordinator for their own relay. Traders are able to soft cancel their orders. This is especially useful for market makers during high volatility, as they can lower their risk and therefore lower spreads, which in turn benefits the users. Traders are able to choose whether they want to use a coordinator or not.

Bamboo Relay coordinator also provides selective delays. Once coordinator receives a fill request, it waits for a short period of time before signing the order. During that time, market maker is still able to cancel the requested order. This serves as an additional protection from the frontrunning. The delay was initially set to 1 second.

Conclusion

Frontrunning damages UX and exploits human errors. It is expected to get worse as the utilization of decentralized exchanges will increase. To solve that, a mechanism called trade execution coordinator was introduced. It works by keeping a track of previous fill request to make sure that each order is approved only once. That mechanism can be later decentralized to avoid censorship and having a single point of failure.

Thanks to Will Warren, Alex Wearn, and Joshua Richardson for their feedback.

References