wanchain decentralized exchange
att 844c810324 formatting 7 months ago
README.md formatting 7 months ago
image_0.png Upload files to '' 7 months ago
image_1.png Upload files to '' 7 months ago

README.md

(for richer formatting, please see this document at https://docs.google.com/document/d/1wcABjQtyQihrRtE9BY5G8Bmu4MBKha_72gd31E-HdPI)

Decentralized Exchange on Wanchain

Solomon Wu - Blockchain developer/evangelist since 2013

Amir Youssefi - Chief Data Engineer at Paypal

Peter Ma - Intel Software Innovator, AI/IoT/Mobile

Executive Summary

Centralized exchanges have issues with custodial risk. User does not control the private key and centralized exchanges can run away with the fund. We proposed two decentralized exchange (DEX) designs that would address these shortcomings. One design that is more suitable at earlier stage of Wanchain network when the network has lower traffic. Another design that is more suitable for later stage when traffic is higher. Both designs offer no custodial risks and off-chain matching. The first design places more info on-chain, which offers higher transparency at the cost of more storage. Thus it is more suitable at lower traffic environment. The second design moved more info off-chain, which is more suitable when the network has higher traffic.

Wanchain features add cross-chain and privacy/anonymity features to both of our DEX designs.

Problem

Centralized exchanges have issues:

  • User does not control private key

  • They could run away with their money

  • Hacks (eg. Mt. Gox, Bitfinex)

  • Opaque operation

  • Potential favoritism

  • User have to submit identity information, resulting in privacy concern and leak of private info

  • Market instability when hacked

Proposed Solution

The most important issue is the control of funds. Centralized exchange have the control of funds instead of their users. Users have to trust the exchange to handle their funds. Crypto space people have dreamed and desired decentralized exchange. Decentralized exchange will addressed this issue. The users retain control of funds at all time.

Designs

Design 1: Discrete Unit Contract (DUC) exchange

Overview & Uniqueness

This design is based on "discrete unit contract" (DUC). In "discrete unit contract" exchange, a user who creates a maker order creates a new contract. The contract is deployed to the network. Each make order exists as its own contract. Another users who wishes to take the contract can simply sends money to this contract address to receive the other side of token.

Characteristics

no custodial or counterparty risk. The user controls their own fund. Orion Dex never controls the user's fund. By using decentralized smart contract, Orion Dex cannot maliciously inappropriate user's fund.

Advantages

One of the biggest issue with smart contract is bug and unintended use. A DUC contract will be very compact. The less code on smart contract, the less likely there is a bug. In addition to reduce the attack surface, DUC contract will be easier to maintain and upgrade. DUC also provide transparency to order book.

Prose Description

The market maker (seller) creates the contract. The contract will lock the selling token. When buyer sends the required buying amount to the contract, the swap will take place.

Structure

Pseudocode of an DUC contract

var tokenSell = {
  amount:
  type:
}

var tokenBuy = {
  amount:
  type:
}

function constructor() {
  lock the tokenSell
}

function exchange() {
  check if coin to buy are received
  send the tokenSell to buyer
  send tokenBuy to seller
}

function cancel() {
  return tokenSell to seller
  delete contract
}

User Experience

Creating the maker order

Although our contract source code will be open source and provided to public for their examination, it is unlikely that the user will create the contract by copy and paste our contract code. Instead, an open source website will be provided for the user to create an order at the push of a button. On the website's frontend, it will create and deploy the contract. Since the contract is created on the frontend, it retain the complete decentralization and does not rely on trusting a middleman. It is decentralized and non-proprietary, third-party can also create the website to provide the same service. The end user does not need to know how to create and deploy the contract. The end user can still view the contract created and verify the contract on other websites. These other websites are called verifier websites. A separate service will constantly running to check the integrity of the exchange website.

View the existing order

Service and website will browse the blockchain and display the orders to the user. Providing an experience that is similar to either OTC site (eg. Huobi OTC) or exchanges (eg. GDAX)

An index service built by us or third parties can browse the blockchain and aggregate the orderbook. Making it easier for the service or website to display the orders to the user. More info about this on ## Index service section. Website do not need to use the index service, but the index service makes things easier.

Component: Index service and API

An index service can look at the blockchain and aggregate the orderbook. This is an optional component. This service may be built by us or provided by a third party. We define the contract spec. A third party could index it from the public blockchain data. The index service will provide an API that shows the orderbook and volume. The index service API spec will be drafted.

Summary

  • no custodial risk

  • on-chain order book

  • off-chain matching

  • no aggregated contract. just individual contract.

Design 2: Fund holding in contract, settlement on chain, order book off-chain, matching off-chain

In this design, we will move both matching and orderbook off-chain.

Flow Abstract

For the sake of explaining, we will give an over-simplified procedures of this exchange.

  1. User deposit their tokens into the exchange contract.

  2. User sign the signature for the buy or sell order and send to relayers.

  3. Relayers will do the matching and send matched orders to the exchange contract.

  4. The exchange contract will swap the token according to the buy/sell orders.

Full Flow

image alt text

Figure 1: Flow for Broadcast option

image alt text

Figure 2: Flow for relayer option

  1. user deposit their tokens into the exchange contract

  2. when user wishes to create a buy or sell maker order, it creates and sign the order.

    a. the order by itself is not a valid blockchain transaction.

    b. the order has a structure like:

    {   type: "limit buy/ limit sell / etc",   tradingPair: “<trading pair>”, // eg. “ETH/WAN”  price: <price>,   partial: true/false,   seqNum: <number>}
    

    c. the order will be sent to exchange contract. The exchange contract understands the signature and can verify the signature of the order.

  3. user now has a few options: broadcast the order or send the order to a relayer

  4. if user chooses to broadcast the order, anyone who wishes to be the taker of this order can sign their taker order and submit both the maker and taker order to the exchange contract

  5. if user chooses to submit the maker order to a relayer. The relayer maintain the order book and will do the matching.

  6. relayer does the matching (the match may come from the current order book on the relayer or from another liquidity source using this same exchange protocol. It is possible to share the liquidity among different players of the same exchange protocol.)

  7. When relayer has a good match , it submits the matched pair of orders (eg. a buy and a sell order) to the exchange contract

  8. The exchange contract will swap the token according to the buy/sell orders.

Relayers only get the signature of order. At no time would relayers get control of users fund.

Partial orders, Market orders, and Stop orders

Partial order is possible in this system and it is planned on this exchange. Partial matching will increase the complexity of the exchange contract, but it is manageable.

There is no real market orders in this system (this is the same for most of the decentralized exchange). However, market orders can be mimicked by the user taking the available market orders.

Stop-loss, stop-buy, or stop-sell orders can be offered by the relayers. However, since someone else can submit the orders to the exchange contract at the same time as the relayers and there is no preferential treatment to any parties, there is no guarantee that the these orders will be executed when the stop price is first reached. This is due to the system is trying to make things as fair as possible. No one has preferential treatment.

Summary

We proposed to DEX designs with following features:

  • No custodial risk

  • Off-chain order book

  • Off-chain matching: broadcast or relayer

with Wanchain we achieve cross-chain and privacy through anonymity.