Make a Swap
This guide provides a step-by-step walkthrough for executing a cross-chain swap using the Sodax SDK. It covers everything from initializing the SDK to handling errors during the swap process.
For detailed API reference, see SWAPS.md.
Example Source Code: A complete working example can be found in apps/node/src/swap.ts. This example demonstrates a full swap implementation from Arbitrum ETH to Polygon POL, including all error handling and status polling.
Prerequisites
Before you begin, ensure you have:
A wallet provider implementation (e.g.,
IEvmWalletProviderfor EVM chains). You can use existing wallet provider implementations from the@sodax/wallet-sdk-corenpm package, or use the local package @wallet-sdk-core if working within the Sodax monorepo.The
@sodax/sdkpackage installedSufficient token balance to cover the swap amount and fees
RPC URLs for the chains you're interacting with (we recommend having dedicate node provider like Alchemy, Quicknode, etc..)
Private key or wallet (browser) connection for signing transactions. For React applications, you can use the
@sodax/wallet-sdk-reactnpm package, or use the local package @wallet-sdk-react if working within the Sodax monorepo.
Step 1: Initialize Sodax Instance
First, create and initialize a Sodax instance. The Sodax constructor defaults to mainnet configuration, so no configuration is required for basic usage.
import { Sodax } from "@sodax/sdk";
// Create Sodax instance (defaults to mainnet configs)
const sodax = new Sodax();
// Initialize to fetch latest configuration from the backend API (optional, use version based approach without initialize for more stability)
// Initialization fetches the latest configuration from the backend API, including supported tokens and chains.
// This ensures you have the most up-to-date token and chain information
await sodax.initialize();Note:
The
new Sodax()constructor defaults to mainnet configuration automatically. No configuration is required for basic usage.If you skip
initialize(), the SDK will use the configuration from the specific SDK version you're using. Initialization is recommended for production applications to ensure you have the latest supported tokens and chains.
Optional: Custom Configuration
If you need to use custom solver configuration or hub provider settings, you can pass them when creating the Sodax instance:
Step 2: Create Spoke Provider
A spoke provider is required to interact with the source chain where your tokens are located. You need to create a spoke provider for the chain you're swapping from.
Note: For node.js environments, we suggest you provide RPC URLs when creating wallet providers (default public ones might not work). For browser environments, wallet providers are typically injected by wallet extensions.
For EVM chains (Arbitrum, Polygon, BSC, etc.):
Important: For Sonic chain, use SonicSpokeProvider instead of EvmSpokeProvider, even though it's an EVM chain. This is because Sonic is the hub chain and requires special handling.
For more details on creating spoke providers for different chain types, refer to the README.md section or see the HOW_TO_CREATE_A_SPOKE_PROVIDER.md guide.
Example: See how the Arbitrum spoke provider is created in the example file: apps/node/src/swap.ts.
Getting Supported Tokens
Before creating a swap, you may want to check which tokens are supported for swaps on each chain:
Step 3: Get a Quote (Optional but Recommended)
Before executing a swap, it's good practice to get a quote to show users the expected output amount. This helps set proper expectations and allows you to calculate slippage tolerance.
Example: See how quotes are obtained in the example file: apps/node/src/swap.ts.
Step 4: Check Token Allowance
Before creating a swap intent, you need to check if the Asset Manager contract has permission to spend your tokens. If not, you'll need to approve it first.
Example: See how allowance checking is implemented in the example file: apps/node/src/swap.ts.
Step 5: Approve Tokens (If Needed)
If the allowance check returned false, you need to approve the Asset Manager contract to spend your tokens. The approval amount should match the inputAmount in your intent parameters (fees are automatically deducted from this amount).
Example: See how token approval is handled in the example file: apps/node/src/swap.ts.
Important: Always wait for the approval transaction to be confirmed before proceeding with the swap. The exact method to wait for confirmation depends on your wallet provider implementation.
Step 6: Prepare Intent Parameters
Now that you have approval (if needed), prepare the complete intent parameters. Make sure to:
Use the quoted amount from Step 3 to set a reasonable
minOutputAmountSet appropriate
deadline(or use0nfor no deadline)Ensure
srcAddressmatches your wallet addressSet
dstAddressto where you want to receive the output tokens
Step 7: Execute the Swap
Now you're ready to execute the swap. The swap method handles all steps automatically:
Example: See how the swap is executed in the example file: apps/node/src/swap.ts.
Creates intent deposit transaction on the source chain
Submits transaction hash to the relayer API
Waits for the relayer to relay the transaction to the hub chain
Posts the hub chain transaction hash to the Solver API
Step 8: Check Intent Status
After a successful swap submission, you should continuously monitor the intent status until it reaches a terminal state. The status checking should poll every 5 seconds until the swap is completed, failed, or not found.
Example: See the complete status polling implementation in the example file: apps/node/src/swap.ts.
Status Codes:
NOT_FOUND (-1): Intent not found in the solver system (may appear immediately after creation). After 3 consecutive attempts, polling stops.NOT_STARTED_YET (1): Intent is queued and waiting to be processed (continues polling)STARTED_NOT_FINISHED (2): Intent is currently being processed (continues polling)SOLVED (3): Swap completed successfully (includesfill_tx_hashwhen available) - Terminal state, polling stopsFAILED (4): Swap failed to complete - Terminal state, polling stops
Polling Behavior:
Polls every 5 seconds (configurable via
intervalMsparameter)Continues until a terminal state is reached (SOLVED, FAILED, or NOT_FOUND after 3 attempts)
Maximum polling duration: 5 minutes (60 attempts Γ 5 seconds, configurable via
maxAttempts)Shows progress messages with attempt numbers
Logs status changes to avoid console spam
Handles temporary API errors gracefully by continuing to poll
Note: The fill_tx_hash field is only present when the status is SOLVED (3). This is the transaction hash of the fill transaction on the destination chain.
Step 9: Handle Errors
The swap operation can fail at different stages. Use the provided error helper functions to handle each error type appropriately.
Example: See how different error types are handled in the example file: apps/node/src/swap.ts.
Complete Example
Here's a complete end-to-end example combining all the steps. For a production-ready implementation, see the example source code in apps/node/src/swap.ts:
Next Steps
See the complete example: Check out the working implementation in
apps/node/src/swap.tsfor a production-ready swap exampleLearn more about swap configuration and advanced features in SWAPS.md
Learn how to create spoke providers in HOW_TO_CREATE_A_SPOKE_PROVIDER.md
Explore other SDK features like Money Market, Bridge, and Staking
Check the README.md for general SDK usage and configuration
Last updated