Why a Destination Chain Rejects a Crypto Transfer

A destination chain rejects a crypto transfer when the outgoing transaction does not meet that chain’s rules for an address, transaction format or fee. In a cross-chain swap, the source asset first reaches a protocol’s vault, the swap is processed, and a network then tries to send the destination asset to the address supplied. Each chain checks that final transaction against its own rules, so a successful deposit does not guarantee a successful delivery.

For a THORChain swap, nodes observe the incoming transaction and the protocol processes the trade through its liquidity pools before arranging an outbound transaction from a vault on the destination chain. The transfer is like a parcel moving through two separate postal systems: acceptance by the first does not mean the second can deliver it to any address in any format. A fuller walkthrough of the wallet steps appears in thor swap. The key point is that the destination chain gets a transaction to validate, not a guarantee that every wallet address will work.

What does the destination chain check?

The destination chain checks whether the transaction can be included and executed under its rules. The most basic check is the address: it must belong to the intended chain and use a supported format. A Bitcoin address cannot receive ETH, even if it is pasted into a field labelled “destination.” Some networks also require extra information, such as a destination tag for certain exchange accounts.

Format is only one part of validation. On smart-contract chains, a token transfer may need to call a contract, and some contract addresses or wallet types may not be supported by the sending protocol. The network also has to pay the destination chain’s transaction fee. If the output is too small to cover the fee, or the transaction violates a chain-specific minimum, the transfer may not be deliverable as planned.

These checks can happen at different points. A quote or interface may catch an obvious mismatch before the user sends funds. Later checks happen when the protocol constructs, signs or broadcasts the outbound transaction. A destination chain can reject a broadcast transaction, while a transaction that has been broadcast but not confirmed may simply be delayed or stuck. Those are different states, even if a wallet shows neither as a completed deposit.

What happens after a rejection?

The result depends on when and why the transaction failed. If the swap request fails validation before the deposit is made, no cross-chain transfer has begun. If the inbound transaction is accepted but the swap itself cannot proceed, THORChain’s documented failure path is a refund to the source chain, with a source-chain outbound fee. A failure in the destination-chain broadcast can require recovery steps, such as retrying or rescheduling; it does not mean every rejection produces an immediate refund.

That distinction matters when checking a transfer. Follow the transaction across each stage rather than relying on a single “failed” status. Look for the source-chain deposit, the protocol’s processing record, and any destination-chain transaction ID. If there is no destination transaction ID, the protocol may not have broadcast the outbound yet. If there is one, check whether the destination chain accepted, confirmed or dropped it.

How can you reduce the chance of rejection?

Use a destination address made for the selected asset and network, and check the receiving wallet’s instructions for any required tag or memo. Before sending, review the quoted output after fees and confirm that the address shown in the transaction is the one you intended. A short checklist covers the main failure points:

• Match the destination address to the exact chain and asset.
• Check whether the receiving account needs a tag or memo.
• Allow for the destination network fee and any minimum output.
• Keep the transaction ID so you can trace each stage.

When a transfer is rejected, the failure usually identifies a mismatch between the transaction and the destination chain’s rules, or a problem delivering it under current network conditions. What changed is that the source deposit and destination delivery are separate steps, each with its own checks. The next useful signal is the outbound transaction status: whether it was never broadcast, is pending, was rejected, or has confirmed.