Cross-chain deposit channels can preserve access after vault changes

Chainflip’s vault design keeps access to funds sent to older deposit-channel addresses through key rotations, while each channel still has a 24-hour window. A channel is a temporary route tied to a particular transaction, not a permanent deposit address. That distinction determines whether a delayed transfer can still be processed.

How do cross-chain deposit channels work?

A deposit channel gives a swap a source-chain address and records the destination asset, chain and address. When funds arrive while the channel is open, the network witnesses the transaction and registers it for processing. This lets a user send an asset from one chain and receive another asset on a different chain.

The address alone does not specify what to do with any future transfer. For a fuller explanation of Chainflip’s native-crypto swap process, see the linked guide. Chainflip’s documentation says channels close after 24 hours; after that, the network may not recognise a late deposit.

What happens to old deposits when a vault changes?

A vault rotation changes which validator set controls protocol funds, so the system must preserve access to funds arriving at addresses created under the previous set. Chainflip’s documentation describes different ways its vaults handle this. On Bitcoin, where funds sit at addresses controlled by keys, the design hands access to older ingress addresses to the new validator set. On EVM chains, deposit channels are smart contracts, and the documentation says the vault can retain access to old channels through key rotation.

This is continuity at the protocol level; it does not extend a user’s channel expiry. Chainflip’s documentation also says many vault types reuse closed channel addresses for later channels. A reused address can therefore belong to a new transaction, so sending to an old address after its channel closes does not guarantee the original swap will be credited.

How can users keep a cross-chain deposit reachable?

Use the channel details for the specific transaction and send while it is open. Before sending, check the asset, source network, destination address and displayed expiry. If a transfer is delayed past expiry or sent to an old address, check the transaction hash and contact the service that opened the channel; do not assume the funds will be automatically assigned to the original swap.

• Open a fresh channel for each swap or deposit.
• Confirm the network and asset match the channel instructions.
• Send before the expiry time shown by the interface.
• Keep the transaction hash and channel request details until the destination transfer completes.

The practical distinction is between an address that vault operators can still control and a channel the protocol will still recognise. Old-address access protects funds during infrastructure changes; the expiry window governs whether a particular deposit has a live instruction attached to it. Check that window before sending, and verify the transaction status if the expected output does not arrive.