Order
The order property of an SDK instance supports querying, creating, pausing, resuming, and canceling orders.
Creating Orders
Creating an order is pretty simple now that you have in/out tokens and an algo.
Once you have the tokens and algo, you can easily prepare an order for submission. You'll notice a new parameter: tags.
Tags
Orders can be tagged with name/value pairs to give you a way of associating the orders with your own internal accounting or processing. Any order queries will return the tags attached to every order.
The result of the prepare function is an object that either contains an "error" property, or an "order" property. The order property references an order object ready to submit. The order object also has a "quote" property that you can evaluate if you didn't previously request a quote.
Once you've decided all looks good, and there are no errors, the order object has a "submit" function that will send the order to Dexible for execution.
Querying Orders
You can also use the order sub-property to query for all your active and historical orders or for a specific order once you know its id. Here is an example:
This will return the first 100 orders owned by the wallet connected to the SDK orders with the following JSON structure:
There is quite a bit of detail attached to an order. Most of the fields match what was used to create the order (tokens, amounts, etc). But many things get attached to the order as it executes in Dexible. We'll briefly cover those here.
Fill Summary
The fill summary gives you a quick summary of what has been filled with the order so far. In this example, it shows basis points fee (fees) of 0.0031158 WETH and .00123 WETH paid for gas (gas_fees). The fees are expressed in the fee token address, which is WETH in this example. It shows that it's 60% complete (progress) with 2 rounds finished. It shows how much of the input tokens have been spent and how many output tokens have been received. Finally, it shows the txn hash for all transactions that were submitted so far.
Execution Status
As the order executes, Dexible records detailed information about the order. Each policy evaluation records changes and the reason why the pass/fail outcome changed. In this example, we can see three policies: StopPrice, GasCost, and FailLimit. The StopPrice says that it passed and provides the price point it was triggered at to make it pass. The GasCost checks gas prices and in this case, since we used relative/fast gas price, it always passes. Finally, the FailLimit policy did not find more than 30% of the total rounds failing, so it passed as well. If a policy status is "fail", it means the policy conditions prevented the order from proceeding to the next round.
Status Changes
Anytime the order status changes, such as being paused, cancelled, or resumed, a status change log is created to let you know why the order state changed. In this example, the trader canceled the order before it was complete.
Last updated