Skip to main content
Execute trades by building transaction data and sending it with your wallet signer. The SDK handles transaction building, gas estimation, and execution automatically.
The trade method combines transaction building and execution into a single operation. This approach simplifies the trading process while maintaining full control over transaction parameters.
Before executing trades, tokens typically require approval to allow the DZap contracts to spend them on your behalf. Learn more about gas-optimized approval mechanisms in the Approval Mechanisms section.
Rate Limits: Our API and SDK have rate limits in place to ensure fair usage. If you need increased rate limits for your application, please reach out to our team on Telegram.

Trade Execution

Execute a trade using the trade method:

Parameters

The trade function expects an object with these parameters:

Required Parameters

TradeBuildTxnRequest Structure

TradeBuildTxnRequestData Structure

TradeBuildTxnResponse (build response)

buildTradeTxn(request) returns an object with (non-gasless, i.e. gasless: false):
  • status - "success" when the build succeeds
  • txId - Unique build/transaction ID (hex string)
  • chainId - Chain where the transaction is to be executed
  • transaction - Chain-specific payload, one of EvmTxData ({ from, data, to, value, gasLimit }), SvmTxData, BtcTxData, BtclnTxData, or HyperLiquidTxData
  • gasless - false for this response shape
  • private - boolean, echoes whether private/MEV-protected execution was used
  • quotes - Per-pair summary keyed by pair ID: { additionalInfo?, provider, destAmount, minDestAmount, priceImpact?, duration? }
  • data, from, to?, value?, gasLimit? - @deprecated top-level mirror of the EVM transaction fields
  • svmTxData? - { blockhash, lastValidBlockHeight } for Solana transactions
  • btcTxData? - { inputs, outputs, feeRate } for Bitcoin transactions
  • btclnTxData? - { paymentRequestType: "bolt11", paymentRequest, paymentExpiry } for Bitcoin Lightning
  • additionalInfo - Record<string, Record<string, unknown>>
  • updatedQuotes - Record<string, string>, refreshed destination amounts keyed by pair ID
When gasless: true is requested, the shape is GaslessTradeBuildTxnResponse instead: { status: "success", txId, transaction: BridgeGaslessTxData | SwapGaslessTxData, quotes, gasless: true, onlySwapData: false }. Pass this object as txnData to trade({ request, signer, txnData }) to skip the build step. See Types reference for the full shape.

Complete Example with Quotes and Approvals

Here’s a full example that gets quotes, handles approvals, and executes a trade. The getAllowance response has data keyed by token address; each entry has allowance (bigint) and type ('dzap' | 'permit2' | 'eip2612') — derive whether approval/signature is needed from those. See Approvals for details.
Viem/wagmi: If using wagmi v2 or viem v2, you may need to cast the wallet client: signer: walletClient as any when passing to approve() or trade().

Error handling and retry (TRY_ANOTHER_ROUTE)

When a trade fails, the response may include action: "TRY_ANOTHER_ROUTE". In that case, retry the trade using the fallback route (bestReturnSource from the quote) instead of recommendedSource:

Best Practices

  1. Always validate balances before execution
  2. Check allowances and execute approvals if needed
  3. Implement proper error handling with retry logic (including TRY_ANOTHER_ROUTE)
  4. Use appropriate slippage settings based on market conditions
  5. Monitor transaction status for cross-chain trades

Next Steps

After executing trades:
  1. Track the trade status to monitor progress
Always ensure users have sufficient balance for both the trade amount and gas fees before execution.
Last modified on July 14, 2026