Why an Unsupported Swap Deposit May Need Manual Recovery

An unsupported swap deposit may not enter the protocol’s normal swap or refund flow, so recovery depends on where the asset was sent and whether the network can identify it. A cross-chain swap starts with a registered instruction: the source asset, destination, and refund details are tied to a deposit channel or a direct call to a vault contract. The network watches for the expected deposit, records it, then processes the swap.

If the asset or network does not match that instruction, the deposit may not be recognized as a valid swap input. A late transfer can also fall outside the deposit channel’s 24-hour window. The fuller chainflip explainer covers how those channels fit into a swap. Here, the key distinction is whether the protocol recorded a swap at all.

What counts as an unsupported swap deposit?

An unsupported deposit is a transfer the swap flow cannot process under the details it was given. That can mean the wrong token, the wrong network, a transfer to an expired deposit channel, or funds sent straight to a vault without first registering a swap. A transaction can be confirmed on its source blockchain and still be absent from the swap record.

A normal failed swap is different. When the protocol has registered the swap but its conditions are not met, it can return the remaining funds to the refund address supplied at setup, less applicable fees. That automated refund path does not establish that an unrecognized transfer can also be returned. The first task is to find out which case applies.

How do you trace the deposit?

Start with the source transaction, then match it against the swap details. Open the swap’s status page if one exists and check whether the deposit appears in its events. Confirm the source network, token contract or asset, amount, destination address, and time of transfer. Deposit channels close after 24 hours, so note whether the transaction was sent within that period.

• Save the source transaction hash and its block explorer record.
• Copy the exact deposit address and identify the network and token contract.
• Find the swap or order identifier, plus the intended refund address.
• Record the amount and approximate time, including the time zone.

These details let support compare the on-chain transfer with the registered channel and determine whether it was witnessed. Do not send another deposit to the same address to “activate” the first one; a second transfer creates a separate problem and does not repair the missing instruction.

How do you request recovery?

Open a private support ticket through Chainflip’s official Discord or Telegram support route and provide the transaction hash, network, token, deposit address, and swap identifier. State plainly whether the transfer used a different asset, network, or an expired channel. Ask whether the deposit was witnessed and whether a recovery route exists for that specific transfer.

Recovery is not automatic or guaranteed. The protocol may lack the asset handling or transaction data needed to return an unrecognized deposit, and an on-chain confirmation alone does not prove that it can control the funds. Use only official support channels. Never share a seed phrase or private key, and ignore unsolicited messages claiming they can recover the deposit for a fee.

For future swaps, check the asset and network before sending, use the current deposit address, and send within the channel’s stated window. The useful signal now is the support team’s confirmation of whether the transfer entered the protocol’s records; that determines whether a normal refund is pending or manual recovery must be assessed.