/build, you can add your own instructions alongside the swap. This page covers common instructions and how to compose them.
Instruction ordering
When building your transaction, follow this order:- Compute budget instructions (from
/buildresponse) - Setup instructions (from
/buildresponse) - Your pre-swap instructions (e.g. create token accounts)
- Swap instruction (from
/buildresponse) - Your post-swap instructions (e.g. transfer, memo, close accounts)
- Cleanup instruction (from
/buildresponse, if present)
Create associated token account
If the recipient does not have a token account for the output mint, create one before the swap. UsecreateAssociatedTokenAccountIdempotent to safely handle the case where the account already exists.
Close token account
After a swap, you may want to close a token account to reclaim its rent. This is common when swapping to native SOL (the wrapped SOL account can be closed after unwrapping).SOL transfer
Add a SOL transfer to tip a validator, pay a fee, or send funds alongside the swap.Memo instruction
Attach a memo to the transaction for tracking, tagging, or compliance purposes.CPI (Cross-Program Invocation)
For protocols that need to invoke the Jupiter swap from within their own onchain program, use the swap instruction from/build as the inner instruction in a CPI call.
- How CPI works
- CPI considerations
- CPI cannot use Address Lookup Tables (ALTs), which limits the number of accounts in the transaction. Jupiter’s complex routing often requires many accounts.
- Use
maxAccountson/buildto control route complexity and keep the transaction within size limits. - Set your own compute budget, as CPI adds overhead.
- Flash Fill (alternative to CPI): allows the use of Versioned Transactions and ALTs, avoiding the account limit constraints of CPI. The flow:
- References
Related
- Build Custom Transactions for the full
/buildworkflow - Advanced Techniques for compute unit simulation and priority fee strategies
