An inbound transaction hash proves that the source-chain transfer was broadcast; an outbound hash proves the destination transfer was broadcast. For an integration, call the swap complete only after the destination chain confirms delivery to the intended address, while treating a refund as a separate terminal result.
Which Transaction Should Your App Track?
Track both the source and destination transactions, and use destination-chain confirmation to decide when the user has received the swap. The source hash is available first, so save it as soon as the wallet broadcasts it; later, attach the protocol’s outbound hash and destination-chain status to the same swap record.
When a thor swap aggregator returns a route, keep its expected output and destination address with the source hash. Your status worker can then compare the eventual transfer with the user’s intended result instead of treating any outbound transaction as success.
Use explicit states so a pending transfer cannot look finished in the interface:
- Submitted: source transaction broadcast; confirmation pending.
- Observed: protocol has detected the inbound transaction.
- Processing: inbound is confirmed; the swap or outbound delay is in progress.
- Outbound: destination transaction broadcast; destination confirmation pending.
- Complete: destination transfer is confirmed to the intended address.
- Refunded: funds returned to the refund address; show the refund transaction separately.
Persist chain ID, transaction hash, address, amount, and block height for each leg. A hash alone is not a globally unique identifier: include its chain, and make status updates idempotent so a repeated event does not create duplicate transfers.
Why Can a Confirmed Deposit Still Be Pending?
A confirmed source deposit is only one stage in a cross-chain swap. The protocol must observe it, wait for its required confirmations, execute the swap, and broadcast the destination transfer; the destination chain then needs to confirm that transfer. Maya Protocol’s delay reference describes these stages and exposes confirmation progress through transaction status and block-height fields.
The source chain changes the wait. For example, Maya Protocol lists an inbound confirmation of around 10 minutes for Bitcoin and around 15 seconds for Ethereum or Arbitrum; those are typical block times, not end-to-end swap guarantees. Its reference also describes finalise_height, the external block height required before confirmation, and an outbound delay that can extend up to an hour.
That distinction matters when a user refreshes or reconnects. A Bitcoin deposit may be visible on-chain while still awaiting protocol confirmation; an Ethereum deposit may confirm sooner, while its destination transfer remains pending. For a thor swap integration, keep the pending state durable across sessions and refresh it from transaction status rather than restarting the swap or asking the user to submit again.
What Should Your Completion Rule Include?
How often should I poll status?
Poll at a measured interval and back off when the transaction has not advanced; one request per minute is a reasonable starting point when the status source supports it. Keep the source hash as your lookup key until an outbound hash appears, then watch that transaction on the destination chain. Also offer a refresh or notification path for users who leave the screen.
What if the output amount is lower than expected?
Compare the confirmed destination amount with the route’s quoted expectation and any minimum-output limit the user accepted. Fees, pool movement, and route execution can affect the result. Mark delivery complete when the transfer meets the transaction’s rules; surface a refund or failed minimum-output condition as its own outcome. I would change the completion rule only if the integration defines success as protocol execution rather than user receipt.