Jumper exchange State Tracking from Commitment to Exit

From selected input to receiving-state proof

The state sequence separates choices that remain editable from transactions that have already reached a blockchain. Route details describe the proposed action. A wallet request presents the transaction that can commit it, and later records show what actually happened.

Before commitment

The before-commitment state contains the selected input, requested output, source and destination networks, recipient and route estimate. The minimum output matters because it defines the lowest result that the transaction may accept under its stated slippage condition. A changed amount, token, network or recipient creates a different request and needs a fresh review.

A token approval, when the route requires one, is separate from the exchange execution. It authorizes a specified spender to use the token under the approval terms. When approval uses an onchain transaction, that transaction may confirm while the actual swap or cross-chain transfer remains unsigned.

Committed execution

The committed state begins when the wallet submits the execution transaction to the source network. The relevant evidence is the source transaction hash, its network and its confirmed or failed receipt. A wallet prompt can also expose a sequence rather than one atomic action. A multi-step route may require a separate wallet transaction for each step.

That distinction prevents an early approval or source-side swap from being mistaken for the requested destination result. If another signature remains, the route has not completed every required action even though an earlier transaction succeeded.

Receiving-state proof

The receiving state answers a narrower question: did the intended recipient obtain the requested token on the intended network? A same-chain exchange may resolve through one transaction receipt and the resulting balance change. A cross-chain path can add a destination transaction, so the source receipt alone does not prove delivery.

Where does commitment become hard to reverse?

Commitment becomes hard to reverse after the execution transaction leaves the wallet and enters the source network. Editing the original form or closing the page does not alter that submitted transaction. A pending transaction may support replacement or cancellation on some networks and wallets, but that possibility is not universal and cannot be assumed.

Before submission, the reader can reject the wallet request, refresh an outdated quote or change the requested output. After submission, the useful choices depend on the transaction state. A failed source transaction permits a fresh request once the wallet balance and any approval state are checked. A confirmed source transaction that feeds a cross-chain route should be tracked through its destination or refund state before another attempt begins.

Pending execution across separate systems

A pending label covers several materially different points in the handoff. A tracked transfer can move from Not Found to Pending and then to Done or Failed. Not Found can mean that the transaction has not been indexed yet, but it can also indicate an invalid hash. Pending may reflect source confirmations, bridge processing, an unavailable chain connection or a refund already in progress.

Source confirmation establishes that the first transaction entered the chain history. It does not establish that a cross-chain route delivered its output. Waiting for a destination transaction means the source side has progressed while the receiving-side record remains absent. Submitting an identical request during this interval can create a second independent transfer rather than accelerate the first.

A stalled interface is also different from stalled settlement. The source hash, destination hash when available and current substatus provide stronger evidence than a spinner or an unchanged page. If status tracking identifies a temporary infrastructure condition, the action remains pending until that condition clears or the route reaches a final failure or refund state.

What does a final Done state prove?

A final Done state proves that tracking reached an end state, but the substatus determines the actual outcome. A Done status can carry Completed, Partial or Refunded as its final substatus.

Completed output

A Completed substatus supports the expected outcome when the receiving record also shows the intended token, network, recipient and amount. Reconciliation compares those observed fields with the acceptance condition chosen before commitment. The original estimate remains useful context, but the destination record and resulting balance establish what arrived.

Partial result or refund

A Partial substatus means the receiving side contains a different token from the one requested. The actual receiving token must therefore be read from the final record before the action is accepted or rejected. A Refunded substatus means the desired transfer did not complete and a return was recorded instead.

Refund handling varies by the bridge used in the route. A refund often returns to the source chain, while another route may return funds elsewhere. Some failed transfers require a manual claim instead of an automatic return. The refund details and any claim instruction in the final status govern the next action. A permanent Failed state without refund proof should not be treated as available balance.

A bounded retry after a refunded transfer

When should the user exit instead of retrying?

The user should exit before commitment when no route meets the stated minimum output, recipient or network condition. Repeated quote refreshes do not improve a route that remains outside those limits. They only update the available proposal.

View full-size image

During a pending transfer, the safer exit is procedural: stop submitting new transactions and preserve the current hash until the state becomes final. A Refunded result moves the action into reconciliation of the returned token and its location. A Partial result requires inspection of the token that arrived. A permanent failure requires the error and transaction record to be reviewed, and its cause addressed, before the same request is attempted again.

An interface timeout alone does not supply that final evidence. Likewise, a source-side success cannot justify a retry while the destination or refund path remains unresolved. The practical limit is clear: absence of the requested output is not permission to duplicate an active transfer.

Reconciliation records beyond the interface

Reconciliation records connect the wallet action to both sides of the route after the original screen changes or closes. Keep enough detail to distinguish a delayed transfer from a different transaction made with similar inputs.

• The source transaction hash and source network
• The destination transaction hash when one exists
• The sending and receiving wallet addresses
• The requested and actually received token identifiers
• The final status, substatus and recorded amounts
• Any refund location or manual claim instruction

A screenshot can preserve the displayed estimate, but it cannot replace a transaction hash or chain record. The strongest reconciliation ties the confirmed source action to the final destination, partial receipt or refund. Once those records agree with the wallet balance, the action can be closed as completed, reconciled with a different result or exited without another submission.