Step Execution Overview
Step Execution using the API
When executing orders using the API directly, there are often multiple steps, like submitting a deposit transaction to the solver or signing a message. These steps differ based on the desired action and best route to execute the action. To make this simple, you can use the execute endpoints, which return the exact steps that you need to follow, including descriptions that you can display to users.
The flow looks like this:
Fetching Steps
Call the Get Quote API to start your execution.
Iterate Through Steps
Iterate through the steps and the items within a step, taking the necessary actions. Steps with no items, or an empty array of items, should be skipped. If step item data is missing then polling the api is necessary.
Executing Steps
As mentioned above each step contains an array of one or more items. These items need to be iterated and completed depending on the kind of step (signature or transaction).
Checking the fill status
After a step is signed or submitted you should check on the progress of the fill
Success!
Once all the steps are complete you can consider the action complete and notify the user.
Signature Step
A message that needs to be signed. Every signature comes with sign data and post data. The first action we need to take is to sign the message, keep in mind the signatureKind and use the appropriate signing method. Refer to your crypto library of choice on how to sign (viem, web3, etc).
Posting the data
After the message is signed the second action is to submit the post
body to the endpoint
provided in the post
data. You’ll also need to provide the signature that was generated from the sign data as a query parameter. If the request is successful we can mark the step item as complete locally.
The design pattern of this API is completely generic, allowing for automatic support of new types of liquidity without needing to update the app. This data can be fed directly into an Ethereum library such as viem, making it easy to sign and submit the exact data that is needed.
Transaction Step
A transaction that needs to be submitted onchain. After the transaction is submitted onchain you can poll the step items check
endpoint. The endpoint will return a status which when successful will return ‘success’. The step item can then be successfully marked as complete. Note that the transaction step item contains a chainId
for which the transaction should be submitted on.
Steps Example
Below is an example of steps you’ll encounter in the wild when working with the API.
Along with the steps you’ll see that the following objects are returned: fees, breakdown and balances. Information about fees is detailed here. Breakdown pertains to time estimation for the execution, broken down by value. The balances object is in regards to the user and how much they require to solve for the execution.
Checking the fill status
Along with the step data there’s an optional check object. You can use this object to check if the status of the transaction is complete. The object details the method and the endpoint to request. You should poll this until the endpoint returns success
.
The check api will always return a status, the expected statuses are as follows:
Status | Description |
---|---|
refund | Execution was refunded on the origin chain unless refundOrigin parameter is set to false, in which case the refund is made on the destination chain |
delayed | If the time pending is 2x the p50 fill time, we mark the request as delayed |
waiting | Waiting for a deposit |
failure | The fill has failed and was not refundable, check the details property for more information on the failure |
pending | Fill is currently pending |
success | Fill was successfully processed |
SDK Reference
To review the official way the SDK handles execution, please refer to the executeSteps file which implements executing steps detailed above.