How to Track Cross-Chain Transfers Reliably
If your app sends tokens across chains, treat the source transaction and destination delivery as separate events; a successful source receipt does not mean the transfer is finished. Build a status view around the route’s steps so users can see what happened, what is waiting, and whether they need to act.
- A mined source transaction confirms only that the first on-chain action succeeded.
- Use the route’s step statuses and next check time to drive your app’s updates.
- Show “complete” only when every required transaction and wait step is done.
Model the transfer as a sequence of states
A cross-chain transfer can include transactions to sign, automatic relayer actions, and waits for confirmations or protocol finalization. The sequence depends on the chosen route, so don’t assume every bridge has the same steps or timing. When deciding how your interface should explain the journey, keep what Super Bridge does across chains in mind: the route determines what happens after the source action.
For example, a route from Ethereum to Base might start with a wallet transaction, then wait for source confirmation, then rely on a relayer to deliver funds. A native route can involve a much longer wait; Optimism’s native bridge, for example, has a seven-day challenge period for withdrawals. Present the route’s expected steps and timing before submission, then update them from observed status.
Use the activity record to advance the transfer
For an integration with Super Bridge, the Activity endpoint returns the transfer’s steps and a nextCheckTimestamp. Save the initiating transaction hash as soon as the wallet submits it; use that hash to find the matching activity record, or query by the user’s address. If the record has not appeared yet, treat it as “awaiting indexing,” not as a failed transfer.
- Wait for the source transaction receipt and store its hash with the source and destination chain identifiers.
- Query /v1/activity using the initiating hash or address, then match the activity’s transaction confirmation hash to your saved hash.
- Read every step: ready means a transaction can be submitted, auto means a relayer handles it, and done means a transaction was confirmed. Wait steps use in-progress and done.
- When a transaction step is ready, request its transaction data with the step action and submitter address, then ask the wallet to sign and send it.
- Schedule the next activity check from nextCheckTimestamp; if it is null or already passed, check now.
Keep both chain IDs alongside the hash: a hash is only meaningful on its own chain, and the same user may have several transfers in flight. Store each step’s status and transaction hash so a page refresh or backend restart can restore progress without asking the user to submit the original transaction again.
Report delays and completion accurately
Suppose a user sends 0.01 ETH from Ethereum to Base. The source receipt arrives, but the route is still in a wait step. Your app should show “source confirmed; destination pending,” not “complete,” and use the route’s expected duration to set a reasonable expectation. A delayed indexer can briefly leave the activity record missing; retry the lookup rather than encouraging the user to repeat the transfer.
Stop polling only when all transaction steps are confirmed or automatic and all wait steps are done. If a step becomes actionable, surface the required wallet action; if the route remains in a wait, show its last confirmed step and check again at the supplied time. The reliable pattern is simple: persist the source hash, follow the route’s actual steps, and reserve “complete” for confirmed destination delivery.
Comments
Post a Comment