Jupiter DEX

Jupiter DEX is a Solana Swap Aggregator Where Balance Checks Precede Reverse Swaps

Jupiter DEX is a Solana swap aggregator where the received SPL-token balance, not the earlier quote, should set a reverse swap's input. Wait until the first transaction is confirmed, read the destination token account, subtract any pre-existing balance and request a fresh quote for that confirmed amount. Sign only after the mint, decimals and spendable units match the transaction record.

That sequence prevents an estimated output from becoming an invalid reverse input. It also separates route accounting from the amount that actually reached the wallet after token mechanics and transaction fees. A sibling page explains it in detail.

Record, Settle and Reverse the Received Balance

The Jupiter DEX reverse-swap sequence has three stages: capture the starting balance, confirm the first swap and quote the amount that actually settled.

Before signing the first trade, record four items: the input mint, output mint, wallet address and destination account's raw balance. Each Solana mint address is a 32-byte public key, while a ticker such as USDC is display metadata. Read the associated token account tied to the output mint and wallet owner. If that account does not yet exist, treat its starting token amount as zero. Save the slot and commitment with the reading, because a later subtraction must compare states from the same account and mint. Do not combine balances from unrelated token accounts.

Confirm the First Settlement

After the signature lands, check that the transaction succeeded and reached confirmed commitment. Swap V2 integrations also receive a status, signature and four accounting amounts. A status code of 0 means success. For the amount that reached the wallet, read totalOutputAmount. Interface users can match the signature in Solana Explorer, then inspect the post-swap token balance.

Build the Return Order

Subtract the recorded starting amount from the confirmed ending amount when the intent is to reverse only the new proceeds. Select the received mint as the new input mint and the original mint as the new output mint. Request a fresh Jupiter quote for that raw integer amount. A partial unwind uses a smaller deliberate amount. The reverse is a second trade with its own route, blockhash, price impact and signature.

What Should the Reverse Amount Include?

The reverse amount for Jupiter DEX should include only confirmed, spendable output units that the wallet owner intends to exchange back.

Jupiter amount inputs are raw integers rather than formatted wallet decimals. SOL uses nine decimal places, so 1 SOL equals 1,000,000,000 lamports. USDC on Solana uses six decimals, making 1 USDC equal to 1,000,000 base units. Preserve the integer string throughout balance subtraction and quote construction. One basis point equals 0.01%, 100 basis points equal 1% and 10,000 basis points equal 100%. These percentages describe tolerances or fees; they do not change the mint's decimal conversion. Floating-point arithmetic can silently round the last spendable units. Retain raw units in logs and quote payloads.

Separate Output From Network Cost

Solana charges a base fee of 5000 lamports for each signature in a transaction. A standard pair of one-signature wallet-paid swaps therefore creates two base-fee events totaling 10,000 lamports, before optional priority fees and account creation. Priority fees use the requested compute-unit limit, not the units ultimately consumed. Their formula divides compute-unit price times the limit by 1,000,000 micro-lamports per lamport and rounds upward. Keep enough native SOL for the return transaction unless the assembled order assigns another fee payer.

Honor Token Transfer Mechanics

Token transfer mechanics belong in the received-balance check. A Token-2022 mint with a transfer-fee extension credits the destination after applying its configured basis points and maximum fee. Quote the spendable account amount, not the route's pre-transfer expectation.

Jupiter graphic reads Trade Any Token On Solana

Three Readouts for the Same Settled Amount

In the same way, Jupiter DEX users can verify settled output through the execution response, Solana transaction metadata or the destination token account.

Readout Field or View Use in the Reversal Hard Boundary
Jupiter Swap V2 totalOutputAmount Use the wallet-reflected output from the executed order One executed request
Solana Explorer Post-balance minus pre-balance Isolate the output created by the first transaction One transaction signature
Solana JSON-RPC getTokenAccountBalance Read the account's latest spendable holdings One token account per call

The JSON-RPC balance method returns four relevant values: amount, decimals, uiAmount and uiAmountString. Store amount as the unsigned 64-bit integer string and use the mint's decimal field for formatting. The numeric uiAmount is allowed to be null, while uiAmountString preserves a display-ready decimal string. Transaction metadata adds preTokenBalances and postTokenBalances, indexed against transaction accounts. Matching owner, mint and program ID isolates the correct balance delta.

Phantom, Solflare and Backpack present formatted balances for convenience. Their display remains useful for a manual check, but automation should retain the raw integer and context slot.

When Is the First Balance Final Enough to Reverse?

A confirmed Jupiter DEX output balance is the practical threshold before requesting a routine reverse quote from the same wallet.

Solana exposes three commitment levels: processed, confirmed and finalized. Processed reflects the node's latest block, while confirmed reflects a block voted on by a cluster supermajority. Finality is reached when nodes representing two-thirds of stake share the same root. Use one commitment consistently for transaction status and the following balance read. Confirmed suits dependent transactions that must proceed in sequence. Finalized adds the strongest ledger assurance when no immediate return order is required. A wallet display without a matching status leaves the operating sequence incomplete.

The return transaction still has a separate lifetime. Solana stores up to 300 recent blockhashes, but validators accept a transaction only when its blockhash sits among the newest 151 entries. The maximum processing age is 150 slots. If the signed return transaction passes that boundary, request a new order and sign its fresh blockhash; the already settled token balance remains available.

Mint Precision, Token Accounts and Spendable Units

Mint precision and token-account ownership determine the exact Jupiter DEX input that a wallet can spend in the return trade.

Match the Mint Before the Symbol

A Solana token account holds units for one mint under one token program. The Associated Token Program derives the standard account from three inputs: wallet owner, token program and mint. This relationship matters when two assets share a ticker or the wallet owns extra token accounts. Compare the 32-byte mint public key and program ID, then read the account controlled by the signing wallet.

Distinguish the Two Token Programs

Solana supports the original SPL Token Program and Token-2022. Jupiter routes supported assets across the relevant program, while the mint defines decimals and enabled extensions. A Token-2022 transfer-fee configuration contains a basis-point rate and a maximum fee; 10,000 basis points represent 100% before the maximum-fee cap. An updated transfer-fee configuration becomes active two epochs later. The spendable account amount after settlement already reflects the transfer that occurred, so it remains the operational input for a reverse quote.

Treat Wrapped SOL as a Token Balance

Native SOL lives in the wallet's system account and uses lamports. Wrapped SOL is represented by the native SPL mint and occupies a token account with nine decimals. A route can include wrapping or unwrapping instructions, so inspect whether the completed swap left native SOL or wrapped SOL. Choose the matching mint and balance source before constructing the reverse direction.

Route Construction Behind the Return Trade

One level down, Jupiter DEX builds the reverse as a new Swap V2 order using the confirmed output mint, original input mint and selected raw amount.

Swap V2 offers two integration paths. The Meta-Aggregator compares four routing engines: Metis, JupiterZ, Dflow and OKX. Its flow has three actions: obtain an order, sign the assembled transaction and execute it. The Router path uses Metis and exposes raw instructions for custom transaction construction. Neither path reopens the first trade. Raydium, Orca and Meteora liquidity can appear within onchain routing, while a JupiterZ request for quote is fulfilled by a market maker.

The assembled order uses a version 0 Solana transaction. Its serialized size cannot exceed 1232 bytes, each Ed25519 signature occupies 64 bytes and the documented account-lock limit is 64 accounts. Solana also caps a transaction at 1,400,000 compute units. These boundaries explain why route shape and account selection can change between quotes. They do not replace the amount check: the fresh order must still begin from the wallet's confirmed spendable balance.

Read the new input amount and output mint before signing. After execution, repeat the same balance-delta method if another adjustment is planned. That routine turns a round trip into two independently verified settlements.

Quick answers about Jupiter DEX

Do I need SOL remaining after the first swap to reverse the position?

A wallet-funded reverse swap needs enough native SOL to pay its transaction fee and any token-account creation cost. The output token does not replace that fee balance. Some Jupiter Swap V2 orders assign another payer or qualify for gasless handling, but the assembled transaction reveals that arrangement. Without a separate payer, reserve SOL before using the full received-token amount as the reverse input.

What happens if the output token account was created during the first swap?

A newly created output token account has a starting token balance of zero for the first-swap delta. Account creation and token receipt can occur atomically in the same Solana transaction. Read the resulting associated token account after confirmation and use its token amount as the new proceeds. The lamports held for account rent belong to the account structure, not to the SPL-token amount quoted back through Jupiter.

Should a partial reverse swap use the full token-account balance?

A partial reverse should use only the raw-unit amount selected for the adjustment. The remaining tokens stay in the same account and do not need a second destination. Keep the requested amount at or below the confirmed spendable balance, then format it with the mint's decimals for review. Jupiter treats that amount as a new ExactIn trade rather than as a percentage-based cancellation of the first swap.

Does wrapped SOL need a different balance check from native SOL?

Wrapped SOL requires an SPL-token account check, while native SOL requires the wallet's system-account lamport balance. Both use nine decimal places, but they occupy different account types. A Jupiter route can add wrapping or unwrapping instructions around the swap. Inspect the completed transaction and selected mint before reversing, because a wrapped SOL token balance cannot be inferred solely from the wallet's displayed native SOL total.

Which RPC value should automation store before requesting a reverse quote?

Automation should store the amount integer string from getTokenAccountBalance together with the mint, decimals, context slot and commitment. That record supports exact subtraction without floating-point rounding. Use uiAmountString only for presentation. When a transaction created the proceeds, retain its signature and compare the matching entries in preTokenBalances and postTokenBalances before passing the resulting raw amount to Jupiter.

Is a second wallet signature required for the reverse swap?

The reverse swap requires fresh wallet authorization because it is a separate Solana transaction. The first signature authorizes only the original transaction message and its recent blockhash. Jupiter Swap V2 returns a new assembled version 0 transaction for the return order. Sign after reviewing its input mint, output mint and raw amount. Router-specific additional signatures do not remove the wallet owner's authorization for spending the received tokens.

Where do Token-2022 withheld fees appear in the balance calculation?

The spendable token amount reflects what the destination account received after the configured transfer fee, while the withheld amount is tracked separately by the Token-2022 extension. Do not add withheld units to the reverse input. Read the ordinary account amount after confirmation. The mint's transfer-fee configuration supplies both a basis-point rate and a maximum fee, so route output and spendable receipt need not be identical fields.

When should an empty token account be closed after the reverse swap?

Close an empty token account only after the reverse transaction is confirmed and its token amount reads zero. Closing returns the account's rent lamports to the designated destination, while future receipt of that mint requires an account again. Wrapped SOL accounts also use closing to recover their native SOL backing. Keeping a standard associated token account open is reasonable when more swaps are planned, because closure is a separate maintenance action.