platform=aggregator is the only supported platform; omitting it uses that platform.
Wallet execution
Request a quote with explicitslippage and the wallet’s sender. A single-transaction result contains transaction.envelopeXdr.
The envelope invokes execute_strategy(sender, total_in, swap_xdr). Inspect its source, network, router, amounts, and minimum output before signing. When transaction.simulated is true, the server has populated the source account’s current sequence + 1 along with Soroban resources, fees, and authorizations. The envelope is ready to sign. Request a new quote if another transaction uses the source account before submission; the sequence is not reserved.
When simulation was disabled, populate the account sequence and prepare the envelope through Stellar RPC first. Submit the signed transaction through your wallet or RPC and wait for confirmation; an accepted submission is not a successful swap.
Contract composition
Request a quote with explicit slippage and consumerouteXdr, the base64-encoded opaque ScVal XDR payload. It is not a transaction envelope. Decode its transport encoding and pass the payload through the calling contract’s supported integration, such as the lending SDK’s strategy flow.
Keep the payload intact. Reconstructing it from hops loses information, especially liquidity mint and burn legs. Bind the quote to the intended tokens, input, minimum output, referral, and deployment. Requote when any of these change.
An LP conversion may expose an independently size-checked atomic routeXdr alongside a two-step wallet plan. Simulation of those two envelopes does not validate the atomic payload. Its absence means atomic composition is unavailable for that quote.
Simulate the complete outer lending or application transaction. Simulating an aggregator wallet envelope alone does not prepare resources or authorization for a different outer transaction.
Ordered transaction plans
Some LP conversions returntransactions[] instead of transaction. Execute steps in order and confirm each before preparing the next. The plan is not atomic across transactions: an earlier step can succeed while a later step fails, leaving the user holding an intermediate asset.
Do not sign every step upfront. Refresh account state and simulate the next step after the preceding step confirms. If amounts or pool state no longer satisfy the plan, requote from the asset actually held.
Integration checklist · Quote semantics