Jumper

Jumper is a Route Interface for a First Cross-Chain Swap With Source-Chain Gas Reserved

Jumper is a cross-chain swap interface for moving one asset into another network while leaving enough native currency on the source chain for transaction gas. Connect the wallet that holds the input, select the source and destination chain-token pair, enter an amount below the spendable native balance, compare the available routes, and sign only after the wallet shows the reserved remainder. If the input is an ERC-20 token such as USDC, keep ETH, POL, BNB, or AVAX separately for the source transaction. Then track the source confirmation and destination settlement, verify the exact token contract and balance, and stop once the requested asset is usable in the receiving wallet. The sections below turn that sequence into a first-swap decision brief.

Key takeaway: It is a cross-chain swap interface where users connect a wallet, compare routes, retain gas on the source chain, swap, and confirm the destination balance.

From Wallet Connection to Destination Balance

The Jumper exchange flow is a guided route-selection process that starts with the wallet holding the source asset.

Begin by connecting MetaMask or Rabby for an EVM source, or Phantom when the source asset sits on Solana. Select the source network before the token, because identical tickers can represent different contracts on different ledgers. Choose the destination network and token, enter the amount, and let the routing engine return executable paths. Open the route detail, compare the expected output, minimum received, provider sequence, and estimated duration, then select the path. Finally, use the primary action button, approve an ERC-20 allowance if requested, submit the swap transaction, and leave the progress panel open until destination settlement appears.

For orientation, Ethereum is chain ID 1, while Arbitrum One is 42161. Those IDs identify networks; the token contract identifies the asset. This separation prevents a familiar USDC ticker from overriding the route’s actual source and destination contracts. With the source network fixed, the next decision is how much native balance to keep outside the amount.

Reserving Native Gas Before the Quote

Source-chain gas reserve is the native-token balance deliberately left outside Jumper’s input amount before a route is signed.

Native-Asset Inputs

A native-asset input draws the swap amount and source gas from the same balance. One ETH equals 10 ¹⁸ wei; WETH also uses 18 decimal places, yet WETH is an ERC-20 token and doesn’t pay Ethereum-family gas. Entering an entire ETH balance leaves no room for the EIP-1559 transaction charge.

EVM Source Chains

On Ethereum-style networks, keep the input plus the wallet’s maximum transaction charge within the native balance. Ethereum uses chain ID 1, Base uses 8453, Optimism uses 10, Arbitrum One uses 42161, Polygon PoS uses 137, BNB Smart Chain uses 56, and Avalanche C-Chain uses 43114. The chain ID in the wallet must match the source field before signing. That check also identifies which native balance funds execution, even when the asset ticker looks familiar across several networks. A route refresh doesn’t repair a wallet left on the wrong network.

Solana Source

Solana’s native unit is the lamport, and 1 SOL equals 1,000,000,000 lamports. A SOL input and transaction fee share one balance, so reserve SOL before entering the route amount. Phantom’s final approval shows the transaction before submission.

ERC-20 Inputs

An ERC-20 input uses a separate native-token balance for gas. Circle’s USDC uses 6 decimal places, which means 1 USDC equals 1,000,000 base units; Jumper handles that conversion behind the amount field. If the allowance is below the input, the wallet requests approval before execution. An EIP-5792-compatible smart wallet can batch supported calls, while an ordinary account can show 2 submissions: approval first, then route execution. The source reserve must cover every submitted transaction. That leaves network and token identity as the next check.

Matching the Network, Token, and Wallet

Network matching is the prerequisite check that ties Jumper’s visible ticker to a chain, token contract, and compatible signer.

An EVM account address is 20 bytes, shown as 40 hexadecimal digits after the 0x prefix, or 42 displayed characters in total. A Solana public key is 32 bytes and uses base58 text. MetaMask and Rabby sign EVM routes, while WalletConnect establishes sessions with compatible wallets. Phantom handles Solana accounts and also supports selected EVM connections. Cross-ecosystem delivery therefore requires the recipient format expected by the destination chain. Circle-issued USDC and bridge-issued representations occupy separate contracts, so the route’s destination contract decides which balance arrives. Chain, contract, and recipient form one selection; check all 3 before requesting the route.

Reading the Route Before the Primary Action

Route review is the quote-reading stage that shows how Jumper plans to turn the source asset into the destination asset (more in Jumper intro to tutorial tips ).

The routing API defines 4 ordering modes for route requests: recommended, fastest, cheapest, and safest. Jumper presents executable paths for the selected pair, and a route can combine a source DEX, a bridge, and a destination DEX. The detail might name Across, Stargate, Mayan, Uniswap, or Jupiter when that component wins the quote. Read the expected output beside the minimum received, because the latter is the execution boundary. One percentage point equals 100 basis points, so 0.5% equals 50 basis points.

Use this route decision checklist before the primary action:

• The connected wallet shows the chosen source chain and account.
• The input plus the wallet’s maximum charge fits the native balance.
• The destination chain, token contract, and recipient match the intended result.
• The minimum received and provider sequence are acceptable for this transfer.
• The destination will contain enough native gas for the next planned action.

Choose the route whose displayed constraints fit the transfer, then review the freshly generated wallet request. A new quote deserves a new reading because liquidity, network conditions, and executable paths move independently. The next decision is which wallet prompt to authorize.

Signing Approval and Execution in the Right Order

Wallet prompts are on-chain authorization steps that turn Jumper’s selected route into source-chain transactions.

For an ERC-20 input, an approval authorizes the spender address attached to the quote; it doesn’t perform the cross-chain swap. ERC-2612 permits and Permit2 use signed authorization patterns, while EIP-712 defines typed data that a wallet can display before signing. EIP-5792 lets compatible smart wallets submit supported calls as a batch. If Jumper requests a conventional approval, wait for its source-chain confirmation before approving route execution. Native ETH, POL, BNB, AVAX, and SOL inputs don’t use ERC-20 allowance transactions.

After execution submission, an EVM transaction hash contains 32 bytes, displayed as 64 hexadecimal digits after 0x, or 66 characters including the prefix. Save the complete hash from the wallet or progress panel. The prompt count follows the token’s approval state and the connected wallet’s batching capabilities, so the on-screen sequence governs the next signature. After submission, the next decision is when destination evidence is complete.

Confirming Both Legs of the Cross-Chain Result

Transfer status is a two-ledger confirmation record that separates source acceptance from destination delivery in Jumper.

Source Confirmation

Jumper’s transfer tracker uses 5 primary states: NOT_FOUND, INVALID, PENDING, DONE, and FAILED. PENDING includes the source-confirmation period and the bridge’s wait for a destination transaction. A confirmed source hash proves that the sending network accepted the transaction; it doesn’t by itself prove that the requested destination token arrived.

Destination Completion

DONE branches into 3 defined outcomes: COMPLETED, PARTIAL, and REFUNDED. COMPLETED means the requested output reached the destination. PARTIAL means value arrived in a different token, commonly the bridged asset when a final destination swap didn’t complete. REFUNDED means the route returned assets under its recovery path. For the first-swap workflow, completion requires the destination chain, recipient, token contract, and wallet balance to agree with the route record. Refresh the destination network in the wallet before interpreting a delayed asset display as a transfer state. Once those fields agree, move to session close.

Closing the First Swap With a Usable Balance

The Jumper clean exit is the final account check that leaves both source and destination wallets ready for the next action.

Stop the transfer workflow after the status shows DONE with COMPLETED, the destination wallet displays the expected contract balance, and the source wallet still holds its reserved native gas. Save the route record and both transaction hashes when the provider exposes a destination hash. If the received token isn’t visible, refresh the asset list or add the exact destination contract rather than submitting another cross-chain route. Then switch back to the source network once, confirm the retained gas balance, and disconnect the wallet session if no further action is planned.

Where that applies, Jumper doesn’t maintain a custodial trading balance, so there’s no separate platform withdrawal. The destination asset already sits at the selected recipient address.

The next decision begins on the destination chain, where the received asset and its native gas balance now define the available actions. Additional context appears in Jumper what are alternatives in practice.

Jumper - your questions answered