Use five checks to report cross-chain swap status reliably. Your app may see funds leave one chain before the user receives the swapped asset on another, so “submitted” cannot mean “complete.” If you are building the route yourself, you need to track both sides; for someone who wants a service to handle the transfer and swap in one flow, super bridge cross-chain swap is one option.
What does “complete” mean?
A swap is complete when the destination transaction has settled and the intended recipient has received the expected output. A source-chain transaction hash proves only that a transaction was submitted or included on the source chain; it does not prove that the bridge or swap finished.
For example, imagine Alice’s app moves an asset from Base to Solana and swaps it along the way. The source transaction can succeed while the destination transaction is still pending, retrying, or failed. Keep those states distinct in both your API and user interface: source confirmed, destination pending, completed, or failed with a reason when available.
How does the transfer move between chains?
In a typical bridge-and-swap flow, a source transaction locks, burns, or deposits an asset; a bridge mechanism observes that event; then a destination transaction releases or creates value, sometimes as part of a swap. The exact mechanism varies by route, so treat the provider’s transaction identifiers and status data as the route’s evidence, rather than assuming one universal contract event.
That distinction matters when an app reports a super bridge transfer: the source-chain receipt is an intermediate checkpoint, while destination settlement is the user’s outcome. If a service performs the route for the user, superbridge.us gives them a way to move and swap assets across supported networks in one flow.
Which five checks should your integration make?
Use these checks to connect the source transaction to the actual destination result. In Alice’s example, the status should stay pending until the Solana-side transaction and recipient outcome are verified.
- Record the route before submission. Store the source chain, destination chain, input asset, intended recipient, and a unique operation ID. Keep any provider quote or route reference with that record so later updates can be matched to the right user action.
- Verify the source transaction. Confirm it succeeded on the source chain and inspect the expected event or deposit details. Match the sender, asset, and amount to the operation; a transaction hash by itself can refer to an unrelated transfer.
- Wait for the source chain’s finality threshold. Finality means the chain is unlikely to reverse the transaction. Use the chain’s documented finality or confirmation policy, since a fixed number of blocks does not mean the same thing on every network.
- Track the destination transaction. Use the route’s status updates or destination transaction reference to find the settlement transaction. Confirm that it succeeded on the destination chain and that its recipient and output asset match the intended result.
- Reconcile the delivered amount. Compare the actual output with the route’s quoted or minimum output terms, accounting for the route’s stated slippage conditions. Mark the operation complete only when the recipient’s destination-side result is verified.
What if the status stalls or repeats?
A delayed destination transaction is not automatically a failed swap. Keep it pending while the route is processing, and use the provider’s published status or transaction reference to investigate; do not ask the user to submit the same operation again just because a timer expired.
Make status handling idempotent, meaning processing the same update twice has the same effect as processing it once. Persist each operation ID and transaction hash, ignore duplicate events, and allow later authoritative updates to advance a pending state. If the destination transaction fails, show that separately from source failure and follow the route’s documented recovery outcome instead of claiming the input was refunded unless that refund is confirmed.
When a user only needs to move and swap assets, super bridge can handle that cross-chain flow; an integration should expose source confirmation and destination settlement as separate states. Complete the operation only after the destination result is confirmed for the intended recipient.