Blueshift swap settlement requires checking the received tokens

Blueshift swaps require a destination balance check before you commit the received tokens to another transaction. Match the selected network, output token, and recipient with the completed transfer. For a cross-chain swap, success on the sending network establishes only that part of the operation. A submitted request or an unchanged wallet display cannot settle the question alone. Keep the transaction identifiers until delivery or a completed recovery explains where the funds are.

The transaction behind the notification

A wallet notification identifies an action, so its meaning depends on which action the wallet confirmed. Token authorization, swap submission, and destination delivery answer different questions. Before interpreting a success message, match its transaction identifier to the operation you intended.

For an ERC-20 token, approval grants a spender an allowance. It does not itself exchange tokens or establish the output balance. A separate successful approval can remain valid even when a later swap fails. Inspecting the transaction method prevents that approval receipt from becoming mistaken evidence of settlement.

A transaction hash identifies a transaction. It does not certify success.

Source confirmation and destination delivery

Blueshift’s documented cross-chain design separates initiation on the source blockchain from finalization on the destination blockchain. Validators coordinate these operations through the settlement network. This separation explains why a successful source receipt cannot establish that the recipient already holds the output.

View image file

The protocol describes initiation through OnSend and destination completion through OnReceive. These are contract events, not promises about the wording a wallet will display. When inspecting decoded events, match the participating chains and recipient to the original operation.

A local swap needs successful execution and matching output on its own network. Cross-chain delivery adds a separate destination transaction to reconcile.

Execution success inside the receipt

A receipt reports the outcome of a particular transaction, while the token movements explain whether that transaction produced your intended result. Read both. A successful call to an unrelated contract, or a successful approval, does not resolve a missing swap output.

Under the standard EVM receipt convention, status 1 indicates execution success and status 0 indicates failure. That status applies to the transaction whose receipt you opened. It does not describe every operation a cross-chain request might require.

Block inclusion and finality also differ. Inclusion places the transaction in the chain’s recorded history; finality concerns whether that history can change under the network’s consensus rules. Use the confirmation information for the actual network rather than borrowing a waiting period from another chain.

The recipient account and exact output token

The output belongs to the account named in the completed transfer, on the network where that transfer occurred. Compare the full recipient address with the intended address. A familiar account label or shortened address is insufficient for resolving a mismatch.

For contract tokens, compare the token contract as well as its symbol. A matching ticker does not establish matching assets. The ERC-20 standard makes names and symbols optional metadata; balances and transfers belong to a particular token contract. A token on another network also requires its own identity check.

The top-level transaction recipient may be a router or another contract. Locate the actual token movement to the receiving account rather than expecting every contract interaction to name your wallet as its immediate recipient.

A missing wallet entry after delivery

A missing token entry can reflect a display problem when the destination account already holds the asset. Check the account balance through the network’s explorer, then compare it with the wallet. Confirm the selected network before changing any token settings.

View image file

If the wallet supports manual token display, use the exact contract for the received asset. Adding that display entry does not perform another swap or move funds. Refreshing the account view is a smaller intervention than resetting the wallet, and it preserves the transaction history needed for reconciliation.

Received amounts and quote differences

The amount delivered belongs to the completed swap, whereas a refreshed quote describes a possible new exchange. Compare the receipt with the original accepted terms, including any minimum output the submitted operation enforced. Do not use a later quote to calculate what an earlier transaction should have returned.

Blueshift’s cross-chain fee model includes validator and gas compensation charges alongside swap fees. Their configuration and calculation inputs can change. An old percentage therefore cannot establish the deductions for a particular transaction.

For balance reconciliation, separate the output transfer from other activity in the same account. The difference between earlier and later balances equals the token amount received from the swap only when no other incoming transfers, outgoing transfers, or token balance adjustments intervene. Compare token quantities first; a displayed currency valuation can change independently.

Pending operations and completed rollback

An operation with neither a confirmed destination outcome nor a verified return of funds on the source network remains unresolved, even if the interface has stopped updating. Silence does not distinguish delayed delivery from a failed operation. Preserve the source transaction identifier and any corresponding destination or operation identifier.

The documented rollback path uses a separate transaction on the source blockchain and emits OnRollback. A rollback decision and the completed source transaction are different observations. Confirm the account’s returned funds before treating recovery as complete.

A failed destination transaction also does not prove that an earlier source transaction reversed. Follow the records for each part separately. Neither an elapsed waiting period nor a fresh browser session establishes a refund amount or completion deadline.

Failed execution and the cost of retrying

A failed EVM transaction can consume gas without completing its intended token exchange. Network processing costs and swap proceeds therefore require separate reconciliation. An out-of-gas failure reverts execution changes while consuming the gas supplied for that execution.

Before preparing a replacement, distinguish a rejected wallet request from a broadcast transaction and a recorded failure. These states leave different evidence. A request the wallet rejected before broadcasting has no network execution to inspect; a broadcast transaction may still be pending, and its receipt becomes available after inclusion in a block.

A replacement swap also uses new conditions. Its quote, available liquidity, and required transaction fee may differ from the original request. Correct the identified cause first, and reconsider the new terms rather than repeatedly submitting unchanged instructions.

Settlement before a portfolio deposit or transfer

Received tokens become the input to a separate action when you transfer them or deposit them into a liquidity portfolio. That later action has its own token compatibility, authorization, and fee requirements. Successful settlement establishes ownership of the output; it does not establish that another contract accepts it.

A destination account may hold the swap output while lacking the network’s fee asset for a subsequent transaction. That condition does not invalidate the completed swap. The wallet’s transaction preview should identify the fee requirement for the next action before you authorize it.

Keep the completed swap receipt separate from any later deposit receipt. A failure in the later action needs investigation under that action’s terms.

The boundary between receipt and onward use

A completed swap gives you the selected output on the recorded destination network. If that asset or network does not suit the next application, another transfer or exchange would be a new decision with new costs. Reversing the trading direction does not undo the original transaction.

Close the original investigation only when its recorded outcome and account movements agree. Where the swap succeeded, retain the actual output amount and destination transaction. Where recovery occurred, retain the corresponding return transaction. An EVM receipt reporting status 1 confirms execution of that receipt’s transaction.

View image file

Blueshift: frequently asked questions

Last updated - 10-Sep-2026