Skip to main content

Swap

Spot swap and cross-chain swap

Cross-chain swap (bridge aggregation)

Quote a cross-chain swap across all supported bridge aggregators (Across, LI.FI, Squid, Stargate, Symbiosis, DZap, Circle CCTP, …) and build the winning transactions. Omit `account` for quote-only. Include `account` to build full transaction calldata. Each build quote carries `approvalTarget`/`approvalRequired`, and `actions.permissions` holds one ERC-20 approve per unique spender (composed routes share the 1delta composer; plain bridges use their own deposit contract) with a `spender` field — execute only the permission whose `spender` equals your chosen quote's `approvalTarget`. When `fromChainId` equals `toChainId` the request falls back to the spot meta-aggregator (same response shape with `aggregator` instead of `bridge` per quote, marked `fallback: 'spot'`). **Uncurated tokens:** a leg missing from its chain's curated token list is resolved on-chain (per chain — the two legs live on different chains), so uncurated EVM tokens still quote; such a leg has no USD price. Non-EVM legs (Solana) are not resolved this way. An address that is not an ERC-20 answers `Unknown Token: <address> on <chainId>`. **CCTP** (`CCTP` = Standard finality, free; `CCTP Fast` = soft finality, 0–13 bps) is Circle's burn-and-mint for its native USDC with the Forwarding Service submitting the destination mint — one transaction, output is exact (`amount − maxFee`, Circle keeps the whole ceiling). The output token must be the destination's Circle USDC; any input is swapped into USDC on the source. Poll `/v1/data/bridge/status` for the mint (`toHash`). **Solana**: CCTP serves Solana both ways. Out of Solana the burn is our own instruction, co-signed by a throwaway event-account key, and locks ~0.003 SOL of rent (`eventRentLamports`) that [`/v1/actions/bridge/cctp/reclaim`](/1delta-api/bridge-cctp-reclaim) returns after 5 days. Into Solana the mint goes to the receiver's USDC token account; when that account does not exist Circle creates it first, at a higher forwarding fee (`recipientSetup: true`).

Cross-chain swap (submit signed permits)

Same parameters as GET. The JSON body carries `permits` (signed offers from a previous response). The endpoint re-quotes with the permit legs riding INSIDE the composed calldata — safe on value because this endpoint is EXACT_INPUT only — and answers with `permitApplied: true` on every route whose assembled bytes actually carry the leg (verified, never assumed); those routes need no approve. Router-spender routes are untouched. On the same-chain spot fallback, `builds` from the previous response are honoured too (spliced without re-quoting).