Skip to content

MVP on chain multi token batch auctions

Jump to bottom
Stefan George edited this page Aug 15, 2019 · 3 revisions

Batches

  1. Batches run for 5 minutes. The timestamp of a block defines implicitly the current batch number
  2. During the current batch (n), the previous batch (n-1) can be solved. The n-1 is finalized once n+1 started.

Deposit and Withdrawl

  1. Any user can deposit tokens any time. A deposit needs to only increase the balance for the current batch and not for the previous one that is currently in "solution submission period". This is implemented with a "pending amount" that is only valid from batch "current". If there is a write access to balance in a batch n+1 "pending amount" is summed into the regular balance.
  2. A withdrawal can be requested anytime. An amount and a "withdrawal batch" needs to be specified. Withdrawal batch number needs to be >= current. If the amount is accessed any time at or after "withdrawal batch" the withdrawal amount is deducted from the amount.
  3. A withdrawal request can be directly canceled/reduced as long it is in the future or current batch. Otherwise, it needs to create a new deposit (amount still pending).
  4. A withdrawal settlement can be made if n is > "withdrawal batch" (this can be done by any account).

Orders

  1. Users can submit orders any time and specify from when till when they are valid. (can not be from previous batches)
  2. Orders can be canceled by setting valid till to "n-1"

Solution Submission

  1. A solution can be submitted any time for batch n-1.
  2. A solution can first change prices of tokens and after that settle trades at those prices.
  3. If a solution is already submitted the previous solution will be rolled back if the new solution generates higher trade volume == overall fees.

Executing a solution:

  1. Potentially rollback of the previous solution
  2. set all prices of tokens touched denominated in the reference/fee token

For each order

  1. check that prices (after fees) are honored. Execute order at clearing prices - fee

  2. check that never a token is used that was not in the list of tokens that got a new price

  3. check that every token that was used also got a new price

  4. update balances, reduce "volume left" of orders, store those deltas to enable rollback

  5. track for each token the total "delta" (sum of sold and bought) After order execution

  6. Check that after all trades are executed deltas for all tokens = 0 and for fee token = claimed total fee

  7. credit half the fee to solution submitter, burn half

Some implicit consequences of this specification. a) No "islands". All settled trades need to have a trading path to the fee token. This is because fees are taken in each token and the only way to create a valid solution is to trade all those surplusses into the fee token. If "island" would be allowed this auction could not serve as a price oracle because prices could be set arbitrarily by the solver.

b) Solution submissions are attackable by frontrunners and most so by miners. To reduce the "miner extractable value" and to create adoption incentives for the GNO community half of the fees are burned.

c) The number of trades that can be touched is implicitly limited by the block gas limit. We expect this number to be around 20-35.

d) Given a 0.1% total fee, a solver would get 0.05% of the fee. Given marginal gas costs of ~150k per trade and assuming a gas price of 10 GWEI this would mean a 0.0015ETH gas costs. To cover this for the solver the trade size needs to be at least 3 ETH.

e) A consequence of d) is that larger trades will be given preference. There might be pooling contracts where different users aggregate common trades (e.g market order to convert DAI to ETH) to create larger orders and increase overall efficiency.

Clone this wiki locally