Relayer strategy

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.