A retry can send a cross-chain swap twice

A cross-chain swap starts with a deposit on the source chain, then a protocol processes that deposit and sends the output asset from a destination-chain vault. A retry can send tokens twice if it causes your wallet to broadcast a second deposit.

The key distinction is whether the retry repeats your source-chain payment or recovers the protocol’s destination-chain transfer.

THORChain’s documentation describes the inbound as an external transaction observed by nodes and the outbound as a separate transaction signed and broadcast by a vault. Its swap state machine processes a confirmed inbound; a route refresh or a stalled status display does not itself prove that another deposit was made. For practical route checks and completion steps, see how to check Thor Swap routes and finish your swap.

When can a retry create a second deposit?

It can happen when the wallet submits another source-chain transaction. For example, if the first payment is still pending and the user approves a fresh transfer with a new transaction identity, both deposits may eventually confirm. The protocol can observe both as separate inbounds; the second is not automatically a retry of the first merely because the interface shows the same route or amount.

On an account-based chain, replacing a pending transaction with another transaction using the same sender and nonce generally competes with the original for inclusion. A new nonce creates a separate transaction. On a UTXO chain, a replacement may spend the same inputs and compete with the earlier transaction, while a new payment funded by different inputs can be a second deposit. The details depend on the source chain and wallet.

What does an outbound retry do?

An outbound retry addresses delivery of the swap output after the inbound has already been processed. THORChain’s developer documentation says a stuck EVM outbound may need a same-nonce replacement, while UTXO chains can use mechanisms such as child-pays-for-parent. It also describes rescheduling when an outbound is not observed: another vault may be assigned to send it.

That recovery has a different risk. If an original outbound remains pending and later confirms after a rescheduled outbound has also confirmed, funds could be sent twice from protocol vaults. THORChain documents safeguards including immediate outbound observation, cached signed transactions, and tracking late transactions so they can be ignored. Those controls concern protocol outbounds; they do not make it safe for a user to send a second inbound while waiting.

What should you check before trying again?

First establish whether the source-chain payment exists and what state it is in. Use the transaction hash from your wallet and verify it on the source chain, then compare it with the swap’s displayed inbound. THORChain says nodes observe inbound transactions and reach consensus before a transaction enters the processing queue; on chains with delayed finality, confirmation requirements apply before processing.

• If the inbound is pending, wait or use the wallet’s supported replacement action; do not approve a separate payment with a new transaction identity.
• If the inbound is confirmed but the output is missing, check the outbound status and its destination-chain transaction hash.
• If no source transaction was broadcast, verify the route, recipient address, amount, and deposit instructions before creating a fresh transaction.
• If two source transactions appear, keep both hashes and contact the swap interface or protocol support with the transaction details.

The practical rule is to retry only the step that failed. A source-chain deposit and a destination-chain outbound are separate transactions with different identifiers and recovery paths; confirm which one is missing before signing anything again.