Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Relayer strategy #7

Open
posgnu opened this issue Dec 6, 2018 · 2 comments
Open

Relayer strategy #7

posgnu opened this issue Dec 6, 2018 · 2 comments
Assignees

Comments

@posgnu
Copy link
Contributor

posgnu commented Dec 6, 2018

Strategy:

As a client submit its order, the relayer checks if there is a matching order stored in the order book. Before this, the relayer also checks if the order conforms with fee policy regulated by the DEX. Only the relayer can fill the orders so that there is no primary race condition from the matching process. The relayer also knows when orders are matched before anyone else and can update the order book as soon as the transaction is submitted.

Rest API

submit(inputs: assetTransferInput[], order: Order, marketId: number, makerAddress: string)

Check if the transaction is valid

Before relaying transactions, they have to be checked validity. First, the DEX have to verify that the transaction 's unlock script is valid. It means that the transaction has to provide a correct signature over order. After the validity checking is finished, the transaction will be relayed on the DEX so that other clients can fill the transaction.

Matching

When the transaction arrives at the DEX, there may or may not be combinable orders. If there are not, the transaction will directly go into the order book as order. The case becomes more complicated if there are orders which are combinable with the incoming transaction. It can be divided into three situations.

  • There is an order which has exactly the same rate and amount with the incoming transaction - In this case, the order is filled and transmitted to a Codechain node
  • There is an order which has the same rate but less amount than an incoming transaction - Fill the order and relay the remainder.
  • There is an order which has the same rate but more amount than an incoming transaction - Do the partial fill

Matching priority

First In, Frist Match rule

Sync

All of the operations with DB have to be atomic. In addition, the matching processes have to be synchronized since matching only occurs in the DEX.

@posgnu posgnu mentioned this issue Dec 6, 2018
8 tasks
@posgnu
Copy link
Contributor Author

posgnu commented Dec 7, 2018

Similar to https://0xproject.com/wiki#Matching

@posgnu posgnu self-assigned this Dec 7, 2018
@posgnu
Copy link
Contributor Author

posgnu commented Dec 12, 2018

  • transaction verifying
  • check a pubkey hash is a standard script
  • register UTXO and expiration date to order watcher
  • check if a fee is properly paid
  • matching
  • In case that matched order is fully filled
  • In case that matched order is partially filled
  • In case that matched order is fully filled and there is a remaining amount in an incoming order

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

1 participant