Published

owned this note owned this note

Linked with GitHub Any changes Be notified of any changes

Mention me Be notified of mention me

Restricted custody MVP1 spec == ## Overview Funds are deposited to the venue using private deposits. Venue collects orders from traders and executes them, in batches or continously. All users funds are protected by "Restricted Custody" design where either venue of operator is honest, those funds are safe. This is a restriction originating in our temporary inability to have compact proofs of state transitions for trade settlements. 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 is the settlement proof mechanism. This spec aims to be a subset of spec using [zkSNARKs](https://github.com/omisego/research/issues/87), [SGX](https://github.com/omisego/research/issues/95) or multisig approach, to ease the transition to fully non-custodial exchange mechanism. ## Transaction structure ``` { transaction_type: integer, inputs: [{utxo_pos | output_id}], outputs: [{output_type, owner, on_behalf_of, token, amount | {token_type, token_specific_data}}], metadata: bytes32, witness: bytes, } ``` ##### transaction_type Defines the rules of chain state transition spending inputs and creating outputs. ##### output_id Computed as a function of transaction body minus witness. Useful for chaining. For simplicity used in most transactions involving a venue. ##### output_type Defines a set of transaction types that are allowed to spend the output. ##### on_behalf_of Trader's address. ##### token_type ERC-721, ERC-1155, etc. If not defined and only amount is present, it's ERC-20. #### token_specific_data Opaque, interpreted by vaults implementing particular token standard. For ERC-721 this field may contain a list of token ids. ##### witness Contents are dependant on transaction_type. For payment transaction, this field will contain signatures of owners of inputs. ## Concepts ### Funding Funding is done using [private deposits](https://github.com/omisego/research/issues/84). Private deposit solves a problem of locking the funds with purpose of trading without revealing information about intent to anyone. The funding transaction looks like a normal money transfer to previously unseen receiver. Its output address, however, does not correspond to private key. Instead, it's a fragment of hash of information about exchange, owner, nonce and output type. To spend this output, exchange would have to show the preimage and a valid signature from exchange address. ### Order Submission An user can submit order after the funding is done. The order should specify a UTXO that would fund the order. The UTXO must be an output of funding transaction, or the output of settlement transaction. If UTXO is an output of funding transaction, the preimage of owner field of the UTXO should also be revealed. Order is identified with hash of it's body (minus signature/witness). This value is called order id later. We support two types of orders at this moment: market order and limit order. #### Market Order Below is an example data needed for a market order: ``` { token_to_buy: [:token], amount_to_buy: [:amount], utxo: [:output_id], owner_preimage: [:bytes], signature: [:sig], } ``` #### Limit Order Below is an example data needed for a limit order: ``` { token_to_buy: [:token], amount_to_buy: [:amount], price: [:price] utxo: [:output_id], owner_preimage: [:bytes], signature: [:sig], } ``` ### Order Cancelation An order can be canceled by the user to send a order cancelation message with order id to venue. This is done off-chain. ### Settlement 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 already consumed, 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 no proof along with settlement data. Later, we can expand settlement tx with proof data. For more information, see settlement proofs section. This new version of settlement will be implemented as a separate predicate. #### Off-chain settlement validation Transaction type expects that witness data contains signature from both venue and regulator. Venue should provide regulator all data relevant to security of traders' funds and regulator should check if everything is intact. Than regulator should add his own signature to the witness of the transaction settlement. To make sure that operator, watchers and root chain contract are aware what address is the address of the regulator, both the venue and the regulator should add their addresses to an external contract. Once added, pair can't be reused - i.e. one can't swap regulator for someone else. Address of this external contract will be hardcoded in the predicate responsible for this transaction type. ### Continious trading settlement With [MoreVP/MVP](https://github.com/omisego/research/issues/83) [switching](https://github.com/omisego/plasma-contracts/issues/113) and MVP [chaining](https://github.com/omisego/research/issues/86), we can have as many trade settlements in a single Ethereum block period as needed. This makes continius trading viable. The settlement can be performed as soon as the match is made. Inputs of the tx would contain sold funds, outputs would contain bought funds. ### Batch Settlement Exchange would define how frequent are batches. Each batch would have its own "round number". Also, it would have all the UTXOs for the matched orders and the outputs for the result. #### List of fields * transaction_type: integer * list of inputs: [output_id] * list of outputs: * owner * token * amount * output_type * on_behalf_of (if owner is the venue) * witness: * round number * traded pair | nil for multi-pair trading * ... see settlement proofs section ### Withdrawals There are two ways to do a withdrawal. #### Cooperative withdrawal For happy case, trader sign and submit the withdrawal request to venue, and then venue would sign the request and send it to operator. Operator knows if reciever is the owner by checking on_behalf_of field or peeking into owner preimage data. ##### list of fields * transaction_type: integer * inputs: [utxo_pos | output_id] * outputs: [{owner, token, amount}] * witness: * venue signature * preimage of owner fields of inputs, if needed #### Forced withdrawal If venue is not cooperating, forced withdrawal is possible directly on plasma chain. It consists of two actions. The trader first notifies the venue and the operator via on-plasma-chain trasaction. After a "clearance" period (defined by the venue is in the contract on Ethereum chain in seconds in Ethereum time) the trader can post a transaction finalizing the withdrawal. Success of this two-step process depends on venue not spending UTXO in question in trade settlement. 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. #### Withdrawal notification tx * transaction_type: integer * inputs: [] * outputs: [] * witness: * utxos: [utxo_pos | output_id] * trader's signature * preimage of owner fields of utxos, if needed #### Withdrawal execution tx * transaction_type: integer * inputs: [utxo_pos | output_id] * outputs: [{owner, token, amount}] * witness: * trader's signature * preimage of owner fields of utxos, if needed * tx_pos of notification tx ### Fees Since in PoA plasma chain there is no mechanism preventing operator from censoring, we assume that there is a business relationship between operator and venue, which covers fees for settlements and withdrawals (including withdrawal notifications). RC deposits and transactions not related to RC are paid via implicit fees (sum of outputs is less than sum of inputs). Accounting of fees collected by operator does not change. ### Trade settlements proofs This document assumes that one of three methods of ensuring that trade settlement is performed correctly, while allowing order details to remain private. Details of this methods are out of the scope of this document. #### Off-chain validation by regulator Signatures of venue are not valid without a countersignature by regulator - party that has access to privileged information and is capable of checking if exchange is following its own rules. It's a form of a multisig. #### SGX Venue's matching algorithm and private keys are inside an [SGX enclave](https://github.com/omisego/research/issues/95), running known code. Traders verify that the enclave is certified by Intel before depositing the funds. SGX hardware guarantees that algorithm execution can't be affected even by a person with direct access to the hardware. #### zkSNARKs Venue creates a succinct proof that matching was done correctly and according to exchange rules. This proof can be checked by plasma participants and also by Ethereum.