This doc is very out of date.
Funds are deposited to the venue. Venue collects orders from traders and executes them in batches. Each batch is a single price auction for all orders. All users funds are protected by "Restricted Custody" design where either venue of operator is honest, those funds are safe.
It would be running on a plasma chain that support M(ore)VP protocol, as where normal payment transactions would be running with MoreVP and DEX settlement transactions with MVP protocol.
Out of scope in this spec:
An user can use a special funding transaction to provide funds to the exchange. The funding transaction would transfer a normal transaction output to a DEX specific output. In the DEX specific output, it would explicit the exchange and the real owner address. Thus, owner address would be the target address when doing exit. However, exchange address would be verified when doing trade settlement transaction.
There are some other possible ways to do the funding with less info leakage. However, as a DEX MVP, let's start with the simpliest solution. (For other funding designs, see: https://github.com/omisego/research/issues/71)
An user can submit order after the funding is done. The order should specify a UTXO that the order is going to use. The UTXO must be an output of funding transaction, or the output of settlement transaction.
After user submit the order to exchange, exchange should provide a unique order id signed by the exchange. User would need such order id to cancel the order.
We support two types of orders at this moment: market order and limit order.
Below is an example data needed for a market order:
Below is an example data needed for a limit order:
An order can be canceled by the user to send a order cancelation message with order id to venue. Venue should sign the message and now the order should be considered canceled.
Since we want the cancelation to be "immediate", we are not introducing any protection from plasma chain. In other words, a possible attack here is that a dishonest exchange can still put your order into a settlement transaction even though such order is "canceled".
As a compensation, if an canceled order ever exists in a settlement tx, user can slash an exchange bond on root chain by disclosing the order cancelation message singed by venue and the proof of inclusion of the order in a settlement tx. As our exchanges are not anonymous, this means it become obvious the exchange if rogoue and people should stop using such exchange.
However, here still exists an attack where exchange does not accpept the cancelation on purpose. In this case, user should withdraw fund to force cancel an order. Since all orders are linked with UTXO, once withdrawn, it is promised that the order would not be executed. Keep in mind that withdrawal is not a immediate process, for the detail of time needed for withdrawal, please see the withdrawals section.
In this design, settlement is done in batch. Each batch would have its own "round number" that specifies which batch/round it is in. Also, it would have all the UTXOs for the matched orders and the outputs for the result.
The settlement output can keep the money "on exchange", which is, the output here can be like the output of funding transaction explicit both exchange and real owner address. So the output of a settlement transaction can be immediately re-used for next trade on next order without extra funding process.
We support partial-fill settlement by auto-generating an order for the remainings amounts of the order. Since the old UTXO of the order is used, the new partial-fill order would point to an output of the settlement transaciton output specially generated for the partial-fill.
The exchange would be submitting different data of batch settlement transaction to operator (in normal case) and Ethereum (when in-flight exit). This is because of the existence of Ethereum gas limit. To reduce gas, we submit compact proof of orders instead of full order data. Correctness of the order would be delegated to challenge games to pro
There are two path to do the withdrawals.
For happy case, trader should sign and submit the withdrawal request to venue, and then venue would sign the request and send it to operator.
However, in case of venue being rogue, we need another mechanism for the traders to do withdrawals directly on plasma chain without venue's involvement. This type of withdrawal is non-instant action: trader must first notify the venue and the operator and only after a "clearance" period the trader can actually post a transaction that reverses the deposit; provided that the deposit was not spent in any trade during the "clearance". This mechanism protects the exchange in case the withdrawn deposit takes part in a settlement which proof is being computed at the time of withdrawal.
We must introduce a special transaction type on plasma chain, which would serve as notification of withdrawal intention. In order to post a withdrawal transaction trader should include proof of having first notified the exchange.
Since this is a batch transaction, we have the flexibility fo venue can add their own input to pay the OmiseGo network fee. Also, venue can add their own address into output of the transaction to collect fee. It is also possible to ask user use different UTXO to provide fee for venue.
However, a pratical fee pricing model would be highly dependent on each venue to design.
Whole design is under "Restricted Custody" security design. Funds are safe if operator or venue are honest.
Double-spend via simultaneus withdrawal and trade.
Assuming later usage of zkSNARKs by venues, usual "first to be mined invalidates later ones" is troublesome for the venue, since venue would have to throw away generated proofs. Such design would create a griefing attack.
So instead, we introduce a pair of messages sent by trader. First one is - "notifyAboutWithdrawal" and the second one is "withdrawal". Both should point to the same utxo and validity of "withdrawal" is conditioned on "notifyAboutWithdrawal" being included into chain at least N blocks ago.
Double-spend via exit from deposit transaction and trade on plasma chain.
Venue can challege the exit or piggyback by disclosing the next settlement transaction using the output.
MoreVP forbids to spend utxo that was not yet confirmed (submitBlock on Ethereum and verification by watcher are required).
There is a dependency problem with settlements (https://github.com/omisego/docs/issues/22).
Lets assume that every submitBlock mines in next Ethereum block (propagation speed is infinite, gas price is infinite).
Probability that market will move in opposite direction than last time and change output will not be consumed (no dependency) is 0.5.
This gives us average trades per block at 2 (estimated value of length of sequence of coin tosses that are terminated with first tails).
Single trade settlement may become in-flight transaction. Thus, we need to make it processable as tx on Ethereum. We can hide order signatures and some other data and have a challenge-reveal game around that worsening time constraints of MoreVP. We still need to merkle proof every input. Estimation of gas cost of such proof puts upper bound on number of orders taking part in single trade settlement at 340.
2 * 340 = 780 orders per trading pair per Ethereum block is our very raw upper bound.
The followings provide the sample of how can a possible transaction looks like, and what is the essential feilds or informations in the transactions. The implementation does not need to be exactly the same as this.
The following sample/example assumes we adapt the abstraction layer design where we have the ability and flexibility to define our own transaction and output type for DEX.
ODEX_OUTPUT
to represent this in the following data sample.PARTIAL_FILL_OUTPUT
to represent this in the following data sample.Below is an example transaction for user to put fund to exchange.
utxo_pos
from all orders are used as input. No mismatch.utxo_pos
owner.This is the tx to show the will of a user wants to withdraw. Withdraw can be valid after certain blocks of this notification tx.
Same as basic MoreVp, we have two types of exit: standard exit and in-flight exit. However, for IFE to be exitable, it has to be "format-wise" correct. It was easy to verify before as it only needs to check signature + sum of input >= sum of output. But for batch settlement, it needs to check all the correctness of orders and it would be impratical. To reduce gas, we delegate the proof of "tx format-wise correctness" to challenge games instead of running verification whenever IFE starts.
For the withdrawal clearance period, is it secure enough to wait N childchain block and not N ethereum block?
Do we support partial fill limit order? Yes.
Do we support partial fill market order?
What is our front-running protection for single price auction?