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.tsarrow-up-right. 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., IEvmWalletProvider for EVM chains). You can use existing wallet provider implementations from the @sodax/wallet-sdk-corearrow-up-right npm package, or use the local package @wallet-sdk-core if working within the Sodax monorepo.

  • The @sodax/sdk package installed

  • Sufficient 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-reactarrow-up-right npm 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.tsarrow-up-right.

Getting Supported Tokens

Before creating a swap, you may want to check which tokens are supported for swaps on each chain:

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.tsarrow-up-right.

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.tsarrow-up-right.

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.tsarrow-up-right.

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 minOutputAmount

  • Set appropriate deadline (or use 0n for no deadline)

  • Ensure srcAddress matches your wallet address

  • Set dstAddress to 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.tsarrow-up-right.

  1. Creates intent deposit transaction on the source chain

  2. Submits transaction hash to the relayer API

  3. Waits for the relayer to relay the transaction to the hub chain

  4. 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.tsarrow-up-right.

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 (includes fill_tx_hash when available) - Terminal state, polling stops

  • FAILED (4): Swap failed to complete - Terminal state, polling stops

Polling Behavior:

  • Polls every 5 seconds (configurable via intervalMs parameter)

  • 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.tsarrow-up-right.

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.tsarrow-up-right:

Next Steps

Last updated