List of protocol improvements for Gnosis Protocol

The current contract of the batch auction exchange provides a MVP for the concept of “multi-asset-batch-auction”. Here we will collect a list of possible improvements and further development.

Scaling
Currently, the system is limited mainly by only allowing 25 executed trades per batch (5min). This is a consequence of the fact that the solver directly executes all trades. While more than 25 executed trades would fit into one transaction (one block) 25 already creates gas costs in the range of 5 million. Transactions above that get more unlikely to get mined and thus a miner could get advantages by running a solver (that can simply add more orders) to create higher utility and potentially abuse that to submit suboptimal solutions. The other bottleneck is the cost to create orders. Currently, the full order information is stored on-chain and thus the costs to submit one order are in the range of 100k.

  1. Small gas optimizations
    There are smaller tweaks that can marginally improve gas costs. See this or this.
  2. Bundling of order
    Orders of the same type (e.g. a market order to sell ETH for DAI) can be bundled into one larger order that is owned by multiple traders (similar to a uniswap pool). This basically increases the 25 order limit to a “25 distinct order types” limit. Note that this might be doable without any contract changes. Since smart contracts can be users of the exchange they can handle the logic of allocating the shared balance to different traders.
  3. Order stored only as a hash
    We could store orders only as a hash (or even just a Merkle root). Solvers would need to get the orders from the historic call data and as part of their solution, they would need to provide a Merkle proof that the orders would be part of the system. This could decrease order submission significantly but would potentially even increase solver gas costs.
  4. SNARKs/STARKs
    Instead of storing balances directly on-chain we could just have a Merkle root onchain that represents all the balances. A solver would provide a zero-knowledge proof with the update of that hash to proof it was updated according to all rules. One key feature we want to consider here is to keep composability. Smart contracts should nevertheless be able to be participants in the system. This would, for example, mean that they can not be required to access of chain state just to do e.g. a withdrawal.

Order expressibility

  1. Simple additions (buy order)
    Currently, the dfusion only supports sell limit orders. Those are orders that specify a token amount that should be sold and minimum price. A simple addition would be buy-limit orders that specify the amount of token that should be bought exactly.

  2. Automated Market Maker
    Currently, you can think of orders as one-dimensional objects. To express a demand and supply CURVE this can only be approximated with many individual orders. Instead, we could allow “two-dimensional” orders where the buy/sell amount if a function of the clearing price. The simplest function would be a linear one where sell quantity increases linearly with a better price. Another popular function is the constant factor formula introduced by @alanlu (x*y =k) and used by e.g. Uniswap.
    The advantages are 2 fold:
    a) gas costs, expressing a curve can become MUCH cheaper than a costly approximation
    b) counter “pennying

  3. Basket orders
    Orders of the type: with 10A10B buy at least (5C7D10E)

Price Oracle

  1. Access to historic state
    To get a more reliable price feed one would want to calculate an average/median price over the last n auctions. Also information about trading volume could help to create a more robust price feed.

  2. Restricting range of valid solutions
    If there is one market order to sell token A in the system it would be today a valid solution to set the price of A to near 0. This will certainly not be an optimal solution but if dfusion should be used as a price oracle a determined attacker might be successful in preventing other solution submitters to submit their solutions in the 4 min time window. Ideally, solutions that are far off would not be accepted in the first place. A strategy to consider is a proof that no orders above the price are unmatched (no disregarded utility). This might be doable with SNARKs. Alternatively, there could be specific orders (AMM?) that always HAVE to be looked at in the solution submission.

Privacy/frontrunning

  1. Sealed order submission and DKG

Mechanism design
We think the core concept of a multi-asset batch auction with single price clearing will not change. However - we might change or tighten the rules of a valid solution. See the discussion here.

  1. Objective Function
    Currently, we calculate the “trader utility” measured in OWL, subtract disregarded utility (of only touched orders) and give some bonus for fee generation (== trading volume). Ideally, we would want solutions with no disregarded utility at all. We are however not certain if a solver can always find those. Thus we penalize disregarded utility. The factor is definitely up for debate. Also for computation reasons, we can only calculate the disregarded utility of touched orders, ideally, we would calculate it of all.
1 Like

One interesting new functionality it can be consider for v2 would be to add a:
Lightweight method to send tokens/balance from one user to another one.

I see this useful, for multiple use case, including:

  1. Rebalance between accounts you control: for implementing complex liquidity provision logics.

  2. Pool contracts: where you don’t need to withdraw, wait and send tokens to each participants. They can send tokens directly from the pool balance to their own account.

  3. Withdraw all: Implement withdraw all functionality when you control multiple accounts. I.e You could say “Withdraw all into account XXX” or “withdraw all into XXX as DAI”

  4. Making dead simple, some complex user workflows: A user could delegate to a smart contract some logic involving trading. The smart contract could have built in, some incentives to trigger all the trading logics without his intervention. At the end of this workflow, the user could automatically get back the balances from the one or multiple accounts used for implementing the complex logic. i.e. “Perform a bracket strategy with XXXX ETH for 4 weeks with this parameters”

For reference, this is a list of issues with tag version 2: Issues · gnosis/dex-contracts · GitHub

1 Like