You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
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.
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.
The text was updated successfully, but these errors were encountered:
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
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.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.
The text was updated successfully, but these errors were encountered: