What this looks like on HyperEVM
- Source: the intent transaction is an ordinary EVM transaction on HyperEVM, signed by the user’s wallet and paid for in HYPE.
ChainKeys.HYPEREVM_MAINNET('hyper') identifies the network everywhere in the SDK. - Reach: any solver-compatible asset on any SODAX network is a valid destination, 166 assets today. The on-HyperEVM asset list only bounds what users hold on HyperEVM itself, not what they can swap into.
- Tokens: HYPE uses the zero address; every other token is a HyperEVM ERC-20 contract. Only HyperEVM balances count: assets in HyperCore spot or perps have to be transferred to HyperEVM before they can be swapped.
- Settlement: output lands on the destination network at
dstAddress. Swaps into HyperEVM settle as ordinary HYPE or ERC-20 balances at the recipient’s HyperEVM address, unless you route USDC into HyperCore with the deposit hook below.
Approvals
swap() does not approve the input token for you. HYPE is the native token and needs no approval. Every ERC-20 does: SODAX’s asset manager pulls it through the token’s ERC-20 interface, so check the allowance first and approve when it falls short.
params is the same intent params object you pass to swap().
Quoting
The solver API quotes both directions:getQuote deducts any configured partner fee before quoting, so quoted_amount is the net output the user actually receives.
Fees
Using SODAX is free to integrate. Two fees can apply to a trade:- Base fee: a fixed 0.1% of the input, taken by the protocol. Not configurable; compute it ahead of time with
getSolverFee(inputAmount). - Your fee: optional platform fee on top, set by you and paid to you. It is the only fee you control. Configure it at SDK setup and check it with
getPartnerFee(inputAmount). See Monetize SDK.
Executing
Preferswap(). It creates the intent on HyperEVM, verifies it landed, submits it to the relay, waits for the packet on the hub, and notifies the solver. The Quickstart has the complete call. Track progress with getStatus(request), and cancel unfilled intents with cancelIntent. Limit orders (intents without deadlines) work from HyperEVM too, via createLimitOrder.
Orchestrating manually with createIntent and submitIntent works the same as on any EVM network: HyperEVM intents need no relay extra data.
Delivering into HyperCore
A swap into HyperEVM normally pays the recipient’s HyperEVM wallet. When your user wants to trade on Hyperliquid, the SDK can instead deposit the output into their HyperCore perps account in the same delivery, using the HyperCore deposit hook registered for HyperEVM. SetoutputToken to USDC on HyperEVM, dstChainKey to ChainKeys.HYPEREVM_MAINNET, and add hook. The source can be any SODAX network; this example swaps ETH on Arbitrum:
hook set, dstAddress keeps its plain meaning: the account being credited. The SDK looks up the hook’s deployed address on HyperEVM, makes it the real delivery target, and encodes dstAddress into the payload the hook reads. A few rules:
- USDC only. The hook’s registry entry accepts HyperEVM USDC as the delivered token. Check a token before you offer the option with
isHookSupportedToken(ChainKeys.HYPEREVM_MAINNET, HookKind.HYPERCORE_DEPOSIT, token.address). - Never the zero address. The SDK rejects a zero
dstAddresswhen a hook is set, because the delivery could not be recovered on arrival. - Quote as usual. The quote is the same USDC-to-HyperEVM quote; the hook only changes where the output goes on arrival.
Error handling
Operations returnResult<T> instead of throwing. The core methods (swap, createIntent, postExecution) return a typed SodaxError union you can switch on by error.code.
Full reference, including raw mode, limit orders, cancellation, and the complete error-code table: Swaps.