Multi-batch auctions with uniform clearing prices is a fun problem, I recently started looking at it again. I was somewhat shocked to see the approach that was taken in the paper, I basically started my design with the “extensions” in place. your 5th constraint regarding arbitrage, i’d assume one would get for free. I also have a bunch of other constraints you folks don’t have that I think makes the problem a lot easier to solve:
- A single order can’t cross the previous clearing price.
- I don’t have a reference token.
- There is no difference between Buy and Sell.
- I picked “fairness” over volume.
- I constrain the amount of volume that can be traded per auction.
I don’t read math notation as well as I read code, so maybe I’m missing this but you can solve the problem incrementally. by that I mean, we don’t need solve for all rings at once.
There are a bunch of other things I did that result in a dramatically more simplified plasma construction as well.
- A single order can’t cross the previous clearing price.
What does that mean? If the previous clearing price is 220 DAI per ETH and your order can not “cross” this - wouldn’t that mean that the next auction can only be settled at 220 again?
- I don’t have a reference token.
We would prefer to not have one put having one is a simplification. You need to measure volume/trader utility in SOMETHING.
- There is no difference between Buy and Sell.
But there IS a difference. See this post.
I quote:
- If a user wants to sell 10 ETH at price 300 USD/ETH. This order can expressed as
Order(10, ETH, 3000, USD, false) .
- If a user wants to sell ETH at price 300 USD/ETH to get 3000 USD. This order can expressed as
Order(10, ETH, 3000, USD, true) .
- If a user wants to buy 10 ETH at price 300 USD/ETH, This order can expressed as
Order(3000, USD, 10, ETH, true) .
- If a user wants to spend 3000 USD to buy as many ETH as possible at price 300 USD/ETH, This order can expressed as
Order(3000, USD, 10, ETH, false) .
You CAN nevertheless decide to only allow one type of order (buy or sell) but this will make it impossible in some cases to allow traders to express their “preferences”.
- I picked “fairness” over volume.
How is “fairness” defined? We picked overall “trader utility” (basically the sum of all the differences of what traders wanted at minimum compared to what they actually got (measured in reference token))
- I constrain the amount of volume that can be traded per auction.
Why should VOLUME be constraint? No harm in matching 2 orders with huge volume. We are thinking however for various reasons in constraining the number of orders that can be “touched” in a solution. Mainly to make verification of a solution feasible.
sorry, that’s super unclear, it just means it’s split into two orders. But i’m not even sure that’s a clear way of explaining it. Hopefully, before I end up in Berlin I’ll have concrete code examples 
I’m doing something very similar to what is suggested in the page you quoted, except every order is backed by an escrow. Yes, we are very explicitly restricting the expression of some preferences, in large part because the problem i’m trying to solve is slightly different from a normal exchange is trying to solve. I’ll get to that below.
By fairness I mean we settle as quickly as possible at the last price posted within the time limit of the auction. I’m not going to fully explain myself here, and I apologize for that, but in the cryptoasset space we need order types that provide projective quasi-static price relations into the future.
“honest issuers” of assets are not traders and often times want to make these projections are far forward as they can. Conversely, traders rather not tip their hands and try to project their intent as little as possible. I’m attempting to design a system that is at least safe and usable for both groups, will being ideal for neither… since tension is what will drive activity.
- Super large orders incentivizes “dishonest” matches.
- We are effectively limiting the number of orders this way as well.
1 Like