Fall of the Frontrunner

On Multi-Token Batch Auctions

Oedipus and the Sphinx (Ingres, 1808–1827)

Frontrunning in Human Time

An Oracle predicts that one day, Oedipus will break the fundamental laws of Nature. To keep that evil day from catching up with him, Oedipus takes to racing against time.

That’s why he outsmarts the Sphinx guarding the gates of Thebes. She asks a riddle of him.

“What is the creature that walks on four legs in the morning, two legs at noon, and three in the evening?” The prize for the right answer is Oedipus’ own life.

“Man,” answers Oedipus, whose race against time hangs on the temporal blockchain that solves the riddle: infancy, maturity, decrepitude. His infancy has long gone by. Decrepitude will put him beyond the reach of the crimes foretold by the Oracle. All he needs to go scot-free is to make it blamelessly to the end of maturity.

But his race maps a tangle of strange paths. Oedipus takes upon himself to unravel this tangle, only to discover that the crimes he abhors, he unwittingly committed long ago.

No one can front-run a race that’s already over. No one can switch a race’s starting line with the finish line.

That’s Oedipus’ downfall.

Frontrunning in Blockchain Time

On the order book of an exchange for ERC-20 tokens, it’s the privilege of frontrunners to reshuffle the order of events. Indeed, they can run backwards.

The Blockchain enables such an extraordinary feat by virtue of its very data structure, which consists of a back-linked list of blocks of transactions. Short of time travel, the duration of each single block provides the best available track for a frontrunner determined to run an old race anew. Too late for Oedipus, though…

The term frontrunning originated in the stock market. Having received a substantial order from a client to buy a certain stock, a broker would place a buy order for themselves in front of their client’s order. This way, the broker would benefit from the price increase subsequent to the execution of the client’s order.

Both miners and non-miners (the latter ones by paying higher gas prices) may front-run order executions on the Blockchain because of two reasons, namely:

Timing: orders’ executions are verified intermittently (rather than continuously), at the time when a new block is added to the Blockchain; Information: the limited capacity of the block segregates some orders to pending pools that are perfectly transparent.

Frontrunning is a form of information theft. It weakens the market’s competitive edge by decreasing the incentive to collect original information and base one’s trades on it—it depresses mass adoption by promoting unfair pricing mechanisms.

Frontrunning in Double-Auction Continuous Time

The familiar look of the limit order book is that of a red-tinged list of increasing limit ask prices (each price meaning: “I’ll sell for at least this price”) and a green-tinged list of decreasing limit bid prices (each price meaning: “I’ll buy at no more than this price”), with a gap, called spread, separating the lowest ask and the highest bid.

Side by side with each bid and ask, you find the maximum quantity on offer or on demand. It’s a sorting mechanism, usually managed by a market maker — which is, in our conversation, a hypothetical, centralized exchange in the crypto space. A one-on-one transaction occurs whenever bids and asks match — whenever the red and green vector of prices touch in the middle.

Consistently through long decades, we have turned security and currency exchanges into this triangular game: the would-be buyer here with their bid, the would-be seller there with their ask, and some supposedly trusted operator (more often than not, an extractor of rent arbitrage) in the middle, sorting and matching bids and asks by price priority.

If the trading place is provided by a market maker who is willing to risk their own money on my one-on-one trades, then, as soon as I reach the (centralized) marketplace for ERC-20 token A, I may instantly sell A to (or buy ETH from) the market maker at the ongoing price. And if I want to sell token A at a higher-than-ongoing price, or buy ETH at a lower-than-ongoing price, the market maker will add my order to their order book. My trade will happen only if and as soon as a complementary matching order is available.

This one-on-one order book segregates markets. When I am interested to trade token B with ETH, for instance, I must place my order on another, pertinent order book — maybe even on another exchange supporting that trading pair.

(There are exchanges where token A and B may be directly traded at their ongoing exchange rate. But even in this case, we are dealing with dual-token order books; i.e., to trade token C with either A or B, I must switch order books. Moreover, such token exchanges are in a tiny minority, as ETH [or some other dominant coin] tends to be generally adopted as pricing numeraire.)

The procedure I just described, managed by the market maker, is called: continuous double auction. Since orders are processed in continuous time, and the underlying Blockchain unfolds in discontinuous time, this is, as I said above, a frontrunner’s dream track.

Next, I am going to show why batch auctions are a convenient remedy to frontrunning.

Frontrunning in Batch-Auction Discrete Time

An alternative token-trading place is provided by the (decentralized) auctioneer who does not risk any of their money on my trades. In this case, I can engage in continuous double auctions or batch auctions. The continuous double auction has all the attributes of the homonymous kind managed by the market maker, except that it does not enable instantaneous trades.

There are two sorts of batch auctions, namely, the dual-token batch auction and the multi-token batch auction.

They both occur when the auctioneer puts my tokens in a batch with other traders’ tokens, and at a pre-established moment, known to all potential traders, trades them at the price that satisfies some agreed-upon constraint: say, the price meant to clear the largest number of trades, or to maximize the difference between sales and buys, or some other constraint.

Both sorts of auctions may be envisioned as token-to-token. In other words, they permit the transition from a numeraire-based price to an exchange rate. Phrasing it differently, they entail the transition from bids and asks to swaps. (The logic behind this transition is elementary: whenever I ask for some amount of token A in return for some amount of token B, I’m indeed bidding some amount of token B in return for some amount of token A; as token swapper, I am buyer and seller at one and the same time. Think bartering.)

After the auction has taken place, I find out the results. Did I swap all of my tokens, part of them, or none? And if I did some swapping, did I get the limit exchange rates I wished for or better ones?

In the midst of this uncertainty, I have one certainty: batch auctions impede frontrunning.

And this is because batch auctions process orders in discrete, discontinuous time intervals within the duration of a single block, applying the same clearing exchange rate to the whole batch (more precisely, to all the orders in the batch whose exchange rate limits agree with the clearing exchange rate).

Hence, my participation in the batch auction enhances the market’s competitive edge, promotes fair pricing (which comes to my immediate personal advantage — unless I am a would-be frontrunner), and increases mass adoption.

An example of the dual-token batch auction in the Ethereum ecosystem is the DutchX.

To date, no multi-token batch auction is available in the same ecosystem.

A dual-token batch auction may have a positive impact on the trading pair’s liquidity. However, the multi-token batch auction, where the order book comprises several trading pairs, is the all-purpose booster shot that propels liquidity to new heights.

Let’s see why.

Liquidity in Multi-Token Batch Auctions

It is well known that liquidity is an existential problem for decentralized token exchanges.

A token’s market liquidity is inversely proportional to its bid-ask spread and directly proportional to its market depth: the greater is the spread and the smaller is the average order size, the thinner is the liquidity. Moreover, an obvious feedback loop links large spread and shallow market depth to thin liquidity — and also thereby to price slippage being caused by relatively small trades.

Large spreads and thin market depths are a typical problem of illiquid tokens traded on decentralized exchanges. The multi-token batch auction solves the liquidity problem by means of ring trades.

The image beneath depicts the ring trade afforded by a simple triple-token batch auction.

There are three traders on the market: Tizio, Caio, and Sempronio. Tizio owns token A, Caio owns token B, Sempronio owns token C. Tizio would like to swap A with B. Caio would like to swap B with C. Sempronio would like to swap C with A.

In a conventional one-on-one exchange, Tizio, Caio, and Sempronio’s respective orders belong in three distinct order books. Hence, since there are no further traders on our simple model market, neither Tizio, nor Caio, nor Sempronio manages to do any trading.

The order book of the multi-token batch auction is multi-dimensional; it comprises all possible trading pairs, as well as the orders of all traders interested in one or more of those pairs. Hence, at the time of the auction, the auctioneer’s algorithm will create a ring trade, where Tizio, interested in swapping A with B, will trade with Sempronio, interested in swapping C with A, after Sempronio will have obtained B from Caio, interested in swapping B with C.

So, each of our three traders may bring home the sought-after token — which, in and by itself, bespeaks increased liquidity.

Pushing the multi-token batch auction to its logical consequences, we may envision each trader specifying their own exchange rate limits, the portion of their order beneath which they’ll refuse to trade, and even the weighted portfolio of tokens they would like to trade; and so on—the more of a trader’s expressiveness we can handle the better, provided computational costs don’t become prohibitive and market depth does not suffer from excessive order fragmentation.

Clearing Exchange Rates in Multi-Token Batch Auctions

Let’s suppose there is a fourth trader involved in our triple-token batch auction, called Cecco, who is endowed with token A and is interested, like Tizio, in swapping A with B. Well, at the time of the auction, Cecco and Tizio will trade A and B at uniform clearing exchange rates.

The extent to which a multi-dimensional order book increases market liquidity depends on the process whereby clearing exchange rates are computed.

The attainment of uniform clearing exchange rates comes from the solution of a complex optimization problem. And this solution varies depending on the target which the problem is designed to maximize. In most financial markets, the target is maximum profit, or the broadest gap between sales and buys. In the case of a decentralized exchange aiming at an increase in overall liquidity, the optimization problem must find uniform clearing exchange rates for all trading pairs, such that traded volume is maximized.

The figure beneath provides an impressionistic visual of the optimal solution to our triangular ring trade. The maximum trading volume is achieved by the yellowest set of exchange rates, i.e., the optimal uniform clearing exchange rates (called “price” for short in the figure), where the optimal number of traders’ limit orders converge. All the orders of these traders, as well as the orders of traders whose limit exchange rates are more than satisfied by the selected set of clearing rates, are executed at the moment of the batch auction.

Optimal Uniform Clearing Price (i.e., Exchange Rate) Computation

I need to point out that the optimal set of exchange rates, as well as the matching optimal set of traded volumes, varies according to the choice of the individual reference token whose traded volume is the primary target of maximization. The choice of this particular token is a problematic one: what criterion ought it to be based on?

In the above ring trade, any random choice of reference token has a decent probability of being the best one: it’s either A or B or C. But when you face a ring trade made up, say, of several dozen tokens, your choice needs to be based on robust cryptoeconomic considerations. And once you have selected your reference token, do you optimize in terms of its traded volume? Or is there some stratagem whereby you may factor in all the other trades as well?

So, fellow mathematicians, where does this leave you?

Why do you give me that perplexed look?

When in doubt, go to the Owl.

Gnosis

They say that the Owl of Knowledge, aka gnosis, spreads its wings at dusk. It means that understanding comes in hindsight, after you turn the future of expectations into the past of outcomes — like we do in prediction markets, like Oedipus did with his own destiny.

I was standing by the birdbath at dusk, watching a black raven do its ablutions. The Owl looking down on us asked me a riddle: “Do you keep the raven before throwing out the bathwater?”

Like the votary of gnosis that I am, I took right away to reshuffling the riddle backwards in time.

In the 16th Century, they derived the word volatility from the Latin word volare, to fly.

Quite a bit earlier, in the 14th Century, they derived the word liquidity from the Latin liquere, to flow like water.

So, riddle solved! Volatile is the jumbled flight of the raven, liquid is the steady stream from the puddle.

It is only to be expected that the deeper liquidity promoted by multi-token batch auctions will have a stabilization effect over the volatility of exchange rates.

In sum, my fellow mathematicians, whichever optimization algorithm you adopt, just remember: If there is something you need to throw out for the sake of computation, go for the raven of volatility. Put it in a cage. Get rid of it. Smash it under the birdbath, I don’t care. But make sure you keep the bathwater. It’s the steady stream of liquidity we are after.