List of protocol improvements for dfusion

The current contract of the dfusion 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

  3. Basket orders

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.