Liquidations -> Batch vs Dutch auctions

Hi Maker community. We (Gnosis) want to use this thread to share our thoughts on why we have chosen batch auctions for Gnosis Protocol (our DEX), and why we believe these types of auctions are good for liquidations.

We are not attempting to self-promote, and we want to note that the existing version of Gnosis Protocol (GP) would probably not be suitable at its current state to handle Maker liquidation requirements. Nonetheless, we strongly believe that batch auctions have huge potential in DeFi and we want to spark debate around their advantages and disadvantages.

I’ll attempt to convey the following in this thread:

  1. What are Batch Auctions?
  2. Our implementation
  3. Advantages and Disadvantages of Batch Auctions
  4. Our learnings from the DutchX -> Dutch auction model exchange we built a year and a half ago
  5. Ideas and open questions on how Maker liquidations on GP could look like

What are Batch Auctions?

Batch auctions (also known as Batch Trading) broadly refer to an accumulation of orders that are executed simultaneously.

Different types of Batch auctions have different criteria that determines which orders are executed and at what price.

Our implementation

In our implementation, traders post limit orders for ANY token pair, which are then collected in batches every 5 minutes (orders are valid once the next batch starts).

During these batches, external participants called solvers compete to propose a solution that a) matches the orders with single clearing prices, and b) optimizes Trader Welfare, an optimization criteria encoded in the smart contract that aims to maximize volume and profit for all traders.

Trades are then settled according to the winning solver’s solution, and the winner is rewarded with a fee collected from traders. Please note that I am omitting several details in order to maintain a high level discussion accessible to everyone.

Advantages

  • Instead of siloing liquidity with one orderbook per pair, batch auctions enable sharing liquidity across all listed tokens.
    • Batch auctions enable what we call Ring Trades, where traders get their orders matched indirectly -> e.g. Trader A longs A/B, Trader B longs B/C, Trader C longs C/A. If a solution is proposed that includes the orders with single clearing prices, all 3 trades will get executed. This means you can bid any token with any other token.
  • Not reliant on price oracles
  • Front-running resistant for traders, given that orders are matched in 5 minute intervals. Solvers do need to optimize their gas when posting their solution to the smart contract.
  • Unlike most Automatic Market Makers (AMM), users can provide liquidity by just posting a sell order of ONE token, instead of having to balance a pool with two tokens.
  • Bidders don’t have to be online to participate in auctions. Standing limit orders at a certain price level can be placed ahead of time.

Disadvantages

  • No single block composability: users have to deposit a balance of the token for the order to be considered for matching, and they also have to wait five minutes for the batch to clear, and then withdraw the bought tokens if they want to transfer.
  • Price updates every 5 minutes. Nonetheless, we currently have a fairly effective price estimation tool for the next batch, and are working on enabling quoting prices with no gas costs for market makers.
  • Current version only clears 30 orders per batch.
  • Providing liquidity requires more work than most AMMs, but less than traditional order book models (we are building tools to improve this)

Note: We are aware that not being single-block-composable makes integrations harder and doesn’t enable some other transactions, e.g. Flash Loans. This was a conscious decision given that we think frontrunning will only get worse in the medium to long term, and it will impede easy participation in liquidations and trading on the Ethereum network in general.

Our learnings on Dutch Auctions from the DutchX

We deployed a dutch auction protocol (dutchX) about a year and a half ago, which allowed all bidders to pay the same price.

Different from the Set Protocol-style auction suggested, the bidder who bought the last available unit sets the price for all prior bidders.

Bidders can withdraw the bought token in the same block as the bid was made, even if the auction was still running. Once the auction cleared, the early bidder could come back and redeem the additional tokens they were entitled to, given that the auction closed at a lower price than their bid.

The theoretical benefit of this approach over settling right at the price of the bid-time (as in the Set Protocol auction) is that it incentivises people to enter the market at their true valuation (rather than waiting for the price to fall further and then enter just before somebody else clears the auction).

In the proposed model we worry a bit about games where keepers wait and try to front-run each other when the auction is about to clear.

An additional issue we saw with dutch auctions in general, is that they require active participants that watch the chain and place orders at the right time. In times of network congestion, this assumption can fail.

Ideas and Open questions on Maker liquidations with Batch Auctions

I leave a few open questions that might be interesting for us to discuss. Please feel free to answer or discuss on the thread.

  • Is front-running resistance more valuable than single block composability?
  • If hypothetically every liquidated Vault would post an order to Gnosis Protocol, what should be the limit sell price of the collateral?
    • This is one of the things that works well in the current Keeper system and in Dutch Auctions.
    • On the Dutchx, we would start auctions at double the closing price of the previous auction.

Links

11 Likes