ACTIVITY_TYPE_EXECUTE_SWAP_V3 runs a swap end-to-end against a quote from ACTIVITY_TYPE_CREATE_SWAP_QUOTE_V2. You sign an execute intent carrying the quote’s economics — the quoteId, amounts, minimum output, and destinationAddress when the route is EVM ↔ SVM. Turnkey matches that intent to the bound quote, then constructs the transaction from the quote’s attested execution (including any required ERC-20 approvals), signs it with the wallet derived from the bound quote inside a secure enclave, and broadcasts it. You never construct, see, or sign raw calldata; the intent is the only thing you sign.
Prerequisites
- A swap configuration is not required; without one, the quote already carries a client fee of 0. See Enable Swaps.
- You are using an unexpired quote from
ACTIVITY_TYPE_CREATE_SWAP_QUOTE_V2. - The address the quote was created for holds enough of the input asset to cover
inputAmount. For non-sponsored swaps it also needs the origin chain’s native asset for gas; ifsponsor: true, your organization can sponsor the gas for the user’s trade. To use the sponsored path gas sponsorship must be enabled for your organization. - For cross-chain or EVM ↔ SVM routes, the destination chain is supported by the provider. See Supported providers, chains, and routes.
- For EVM ↔ SVM, the quote and execute intents both set
destinationAddressto the same raw output-protocol address.
Submit the swap
string
required
The quote to execute, from
ACTIVITY_TYPE_CREATE_SWAP_QUOTE_V2. Execution is pinned to this quote’s pricing and provider. Must be unexpired.string
required
CAIP-19 identifiers for the assets being sold and bought, matching the quoted pair. The origin chain derives from
inputToken; a differing CAIP-2 prefix on outputToken makes the route cross-chain.string
required
In raw onchain units, matching the quoted amount.
string
required
The quote’s expected output, in raw onchain units. Informational in settlement but part of the signed intent: the user signs the economics they were shown.
string
required
The quote’s floor, in raw onchain units. Enforced at execution time — if the swap would return less, it fails rather than filling worse.
boolean
required
Required. When
true, your organization sponsors gas for the transaction; requires gas sponsorship to be enabled for your organization. Set to false to have the swapping wallet pay its own gas.string
Required for EVM ↔ SVM. Must match the quote: a raw public address on the output token protocol. Omit it for same-protocol routes. Wallet account IDs, private key IDs, and CAIP identifiers are not accepted.
cURL
JavaScript
ExecuteSwapResult returns swapRequestId (used to poll status), plus optional provider and quoteId.
Gas: sponsored vs. self-funded
Withsponsor: true, Gas Station pays the gas and the swapping wallet account needs no native asset at all — approvals and the swap execute in one sponsored batch. Gas sponsorship must be enabled for your organization; sponsored gas accrues to your monthly gas bill and counts toward your spend limits.
With sponsor: false, the wallet account performing the swap pays its own gas. The wallet account must be funded with a sufficient amount of the origin chain’s gas asset before executing.
Gas Sponsorship is available on Enterprise plans. Enterprise: Unlimited spend, with configurable time windows. Pay-as-you-go and Pro customers can still access transaction construction, signing, and broadcast. If you’d like to leverage gas sponsorship, please reach out!
What is abstracted away
The signed intent carries only the swap parameters listed above. Everything else is handled by Turnkey:- Provider quote payloads
- Transaction calldata and serialized transactions
- Token approval signatures and payloads
- Fee configuration — rates and the fee receiver are snapshotted into the quote at quote time; execute does not re-read your live configuration, and you cannot override fees per swap
evmNonce, recentBlockhash, gasStationNonce) can be set on the intent; omit them to auto-fetch. See Trust boundary for the full model.
Approvals
For ERC-20 inputs, Turnkey batches any required token approval into the swap transaction — there is no separate approval activity to run, no standing allowance to manage, and no second signature from your user. Approvals are handled automatically as part of execution. Native token swaps (e.g., ETH asinputToken) do not require an approval step.
Some non-standard ERC-20 tokens may not be compatible with the batched approval flow. If a swap fails with an approval-related error, verify the token supports standard ERC-20 approval mechanics before retrying.
Same-chain vs. cross-chain execution
The execute activity is the same for same-chain, cross-chain, and EVM ↔ SVM routes — the route is fixed by the quote you reference. For EVM ↔ SVM, restatingdestinationAddress is required. The difference after broadcast:
- Same-chain swaps reach a terminal status from the origin transaction:
COMPLETEDwith the settledoutputAmount, orFAILEDwithORIGIN_TRANSACTION_FAILED. Same-chain status does not returnrefundorPROVIDER_FILL_FAILED. - Cross-chain swaps stay
PENDINGpast origin inclusion until the destination leg settles (COMPLETED, withdestinationTxHashes) or the provider reports a fill failure (FAILED). Therefundobject can be absent whenFAILEDfirst appears.
get_swap_status with the swapRequestId returned by the execute activity. See Track swap status for terminal states and error handling.
Poll swap status
A successful execute activity returns an ID which you will use to track the status of the swap:swapRequestId— the handle for polling. Pass it toget_swap_status.quoteId/provider— echoed for correlation with the quote you executed.
get_swap_status with the swapRequestId until it reports a terminal state: COMPLETED with the settled amounts, or FAILED with a structured error. Same-chain FAILED has no refund. Cross-chain FAILED can omit refund on the first responses. Cross-chain swaps remain PENDING longer, until the destination leg settles. Full lifecycle semantics on Track swap status.
Next steps
- Track swap status: same-chain vs. cross-chain polling.
- End-to-end example: full flow from enable to confirmation.