Jupiter swap - From signed transaction to confirmed output
Jupiter swap completion requires successful execution and the expected token changes in the receiving account. Signing authorizes a transaction; submission sends it toward the network. Neither step establishes that the exchange succeeded. Check the transaction’s execution result, its confirmation status, and the amount actually received before treating the quoted output as a completed trade.
A pending message leaves the outcome unresolved. A confirmed transaction can also contain an execution error. Keeping those states separate helps explain an unchanged balance, a missing receipt, or a completed exchange that the wallet hasn’t yet displayed.
From quoted input to recorded output
A quote describes the proposed exchange, while successful execution records the actual input deduction and output receipt. Jupiter’s managed execution handles submission and confirmation polling after signing. Its response can include a transaction signature on successful attempts and some failures, so the signature alone doesn’t establish the outcome. Compare the execution result with the receiving account’s change, using the same token identity and units throughout.
The transaction prepared for approval
Approval should concern the intended input, receiving token, destination, and acceptable output condition. A token’s mint address identifies the asset behind its displayed name. Sufficient spendable input and any required transaction funding must also exist. In Jupiter’s order API, pricing can remain available when transaction construction fails; an empty transaction field means there’s nothing executable to sign. Resolve that preparation error before moving to submission.
Does signing mean the swap has completed?
Signing a swap transaction authorizes its instructions, but completion requires the network to execute those instructions successfully. Wallet approval and network execution happen separately. An application may submit immediately after approval, so don’t assume that closing the signing prompt leaves an authorized transaction unsent.
A transaction signature identifies the signed transaction and can exist before submission. Even a successful response from Solana’s sendTransaction method establishes only that the receiving node accepted the submission. It doesn’t guarantee processing or confirmation. Retain the signature so later status checks concern the same attempt, rather than another transaction with similar token amounts.
Pending status and confirmation depth
A pending display means the application hasn’t established its completion condition; the transaction record provides the more precise execution and confirmation state. An RPC service is a connection through which applications read that network information.
Solana distinguishes processed, confirmed, and finalized commitment levels. Processed data reflects a node’s recent execution view and can still roll back. Confirmed means a supermajority of stake has voted on the block. Finalized represents the network’s strongest confirmation state.
A transaction’s confirmation status and its execution error are separate fields in a Solana signature-status response. Read both. A transaction that reached the required confirmation level still needs a successful execution result before it represents a completed exchange.
A missing lookup result needs interpretation. The signature-status method normally searches a recent cache unless the request enables transaction-history searching. Absence from that cache alone doesn’t prove that an older transaction never executed.
Differences between displays can also reflect their requested commitment levels. A lookup requiring finalization may lack a transaction that another view already shows as confirmed. Keep the network and confirmation requirement consistent when comparing results.
Reconciling the received token amount
Reconciliation means matching the transaction’s recorded changes to the intended exchange, including the output token and the account that received it. Solana transaction metadata can include token balances before and after execution. Match entries by account and mint, and interpret their amounts using the recorded decimals. A wallet’s aggregate balance at two different times can include unrelated activity; transaction-specific changes provide a narrower comparison.
Jupiter’s managed execution distinguishes route output from wallet output. The outputAmountResult field describes output before any swap fee collected in that token. The totalOutputAmount field describes the final amount reflected in the wallet after that fee. Compare an output requirement against the amount on the same accounting basis. Don’t treat a difference between these fields as unexplained slippage.
A missing wallet display doesn’t establish a missing receipt. If the successful transaction records the intended account’s output increase, check that account’s token balance directly. If the record identifies a different mint or destination, the discrepancy concerns the exchange itself.
What does a failed transaction leave behind?
A failed Solana transaction reverses its instruction-driven state changes, although network fees can still apply when the network processes the failure. Atomic execution means the instructions within that transaction succeed together or revert together. A failure therefore doesn’t normally leave half of that transaction’s swap completed.
That boundary is one transaction. Separate transactions have separate outcomes, so a successful earlier transaction doesn’t automatically reverse when a later one fails. Use the signature attached to the swap when interpreting an error or balance change. Distinguish a recorded execution failure from a submission problem that never produced an onchain result.
Closing an unresolved attempt
A timeout reports that a response didn’t arrive within a waiting period; it doesn’t establish transaction expiry. For transactions using a recent blockhash, the last valid block height supplies an expiry boundary. The blockhash is a recent block identifier that limits how long the transaction remains eligible for processing. Check the transaction’s last valid block height rather than relying on a fixed waiting time.
Expiry prevents a previously unprocessed transaction from executing later. It doesn’t erase execution that occurred before expiry. Resolve the original signature’s history as well as its validity before authorizing a replacement. A newly signed transaction can represent another exchange, even when its displayed input resembles the first request.
Completing an exchange with an output requirement
Suppose the exchange is useful only if the intended receiving account gains at least the output amount you’ve chosen to accept. Use that same net-output requirement for every quote under consideration. Establish the token identities, spendable input, and output condition before authorizing the transaction.
Before signing, check the prepared transaction. After submission, use its signature and recorded account changes to assess the result:
- If the prepared transaction doesn’t match the intended tokens, destination, or minimum net-output requirement, don’t sign it.
- If the signature has no conclusive result, leave the attempt unresolved while checking its history and validity.
- If execution records an error, treat the exchange as failed even when the transaction has confirmation.
- If execution succeeds and reaches the required confirmation level, compare the receiving account’s net output with the previously chosen requirement.
- If the mint or destination is wrong, or the net amount received falls below your minimum, record the discrepancy instead of marking the exchange reconciled.
A completed trade can still fail your intended outcome if you approved the wrong asset or accepted an unsuitable output condition. Successful execution answers whether the transaction ran; reconciliation answers whether it delivered the exchange you intended. For managed Jupiter execution, the wallet-output field is totalOutputAmount.
Still wondering about Jupiter swap?
Can closing the browser stop a Jupiter swap that has already been submitted?
Closing the browser doesn’t recall a transaction that the network has already received. Submission hands the signed transaction to infrastructure outside the browser, which may continue forwarding it. Reopening the application may restore its display, but the transaction signature remains the identifier for checking the outcome.
Does a successful simulation prove that my signed swap will execute?
A successful simulation doesn’t prove that the submitted swap will execute successfully. Simulation checks the transaction against a particular network state before execution. The transaction must still reach the network while valid, and execution conditions can change. Treat a simulation result as a preparation check rather than a receipt.
Why does my swap record contain instructions beyond the token exchange?
A swap transaction can invoke several instructions, including instructions that call other programs during execution. Solana records those nested calls as inner instructions. Their presence doesn’t by itself mean that you submitted several separate swaps; examine their account changes within the transaction’s overall execution result.
Could the wrong network view hide my transaction receipt?
A lookup against a different Solana network won’t retrieve the intended network’s transaction history. Each RPC endpoint reads a specific network, so compare the network used for submission with the one used for inspection. A missing result in the wrong view says nothing about whether the original swap succeeded.
Is a null confirmations count the same as an unconfirmed swap?
A null confirmations count alone doesn’t mean that a swap remains unconfirmed. A Solana signature-status response can show that value alongside a finalized confirmation status. Read the named confirmation state and execution error together, rather than interpreting the count in isolation.