Building with an AI assistant? Add the SODAX Builders MCP (
https://builders.sodax.com/mcp) to Claude, Cursor, or any MCP-capable tool and it can pull live token lists, real quotes, and these docs while it writes your integration.1. Install
2. Create a Sonic wallet provider
Sonic uses the sameEvmWalletProvider as every other EVM network, keyed by ChainKeys.SONIC_MAINNET.
@sodax/wallet-sdk-react connects EVM wallets for you and hands back a ready-made provider via useWalletProvider. See Wallets.
3. Look up supported tokens
Token addresses and decimals come from the SDK config, so you never hard-code them. Native S uses the zero address in the config.4. Quote and swap
swap() runs the full lifecycle: it creates the intent on Sonic, confirms it, and notifies the solver to fill on the destination network. Because Sonic is the hub, there is no relay step between the source transaction and the solver.
ok means the intent was created on the hub and the solver notified, not that it was
filled. Poll sodax.swaps.getStatus({ intent_tx_hash: intentDeliveryInfo.dstTxHash }) until the
status is SolverIntentStatusCode.SOLVED, which is the only success signal. The
main quickstart has the full polling loop, including why NOT_FOUND is not terminal.
A few things to know on Sonic:
- S needs no approval. It is the native token, sent as the transaction value. Swapping an ERC-20 on Sonic (USDC, wS, SODA, and the rest) needs an allowance for the SODAX intents contract first; see Approvals.
- The hub tx is your source tx. The client-side path uses the Sonic transaction hash directly as the hub hash, with no relay packet to wait for. Keep using
intentDeliveryInfo.dstTxHashfor status calls, so the same code works for every source network. - Amounts follow
token.decimals. S and most Sonic tokens use 18 decimals, but USDC and USDT on Sonic use 6.
Next steps
- Swaps on Sonic: approvals, fees, status, manual orchestration.
- Money Market on Sonic: supply and borrow against the hub reserves.
- Full API reference: Swaps in the SDK docs.