A reliable swap integration treats every Deposit Channel as temporary state. Your application must connect the channel request, the source-chain transaction, and the eventual swap or refund without assuming they happen at the same time.
- Open a fresh channel for each deposit and track its expiry.
- Verify the channel request before showing a deposit address.
- Keep deposit confirmation, swap execution, and refund as separate states.
A Deposit Channel Is a Time-Limited Swap Request
A Deposit Channel ties a source-chain deposit to the swap instructions registered with the protocol. Those instructions include the destination asset and address, plus any applicable price protection, retry duration, or cross-chain message parameters.
For an integration, model channel creation as the start of a lifecycle, not as a reusable account. Chainflip’s Broker documentation says channels expire after 24 hours; a late deposit may no longer be recognized. Create a new channel for each swap, and make its expiry visible to the user or to the service that submits the transaction.
For example, a wallet app preparing a Bitcoin-to-ETH swap should save the channel request identifier, the deposit address, the expiry, and the intended destination details together. If the user returns after the channel has expired, the app should request a fresh channel instead of reusing the old address.
Verify the Request Before You Show the Address
Verify that the channel request was successfully submitted before presenting its derived address as ready for a deposit. The Broker returns a transaction hash for the request; retain it so the user or your service can check that the protocol recorded the intended destination and swap parameters.
Chainflip’s Deposit Channels documentation describes locally deriving the address from the request data. It advises interface designers to let users access the request transaction hash and to avoid deriving addresses server-side. That gives an integrator an auditable path: inspect the submitted request, derive or retrieve the corresponding address, then compare the result before displaying it.
If you want the full user-facing explanation of the swap itself, see how Chainflip handles native swaps. This article focuses on the integration state you need to preserve around the deposit request.
Keep source-chain identity and asset identity alongside the address. An address can be reused by some vault types after a channel closes, so address equality alone does not prove that a later transfer belongs to the earlier request.
Track Source Confirmation Separately From Swap Completion
A source transaction being broadcast does not mean the deposit has been witnessed or the swap has completed. Track at least three distinct events: transaction observed on the source chain, deposit witnessed by the protocol, and destination transfer or refund completed.
For Bitcoin deposits, the Chainflip protocol documentation currently describes a three-block witnessing threshold, roughly 30 minutes at typical block intervals. Treat that as an operational estimate, not a deadline: block intervals vary, and the required confirmations can be fetched through the SDK. Bitcoin’s Developer Guide explains why each additional block adds another confirmation and makes reversing a transaction harder.
In a typical case, a user broadcasts a Bitcoin deposit and immediately asks why their ETH has not arrived. Your status response should say whether the transaction is still awaiting source-chain confirmations, has been witnessed, or is waiting for execution and destination transfer. That distinction makes delayed Bitcoin blocks easier to diagnose than a single generic “pending” state.
chainflip.org is a service that can carry out a native cross-chain swap. For an integration, use the same lifecycle discipline: preserve the request reference and source transaction hash so a user can reconcile progress across chains.
Make Expiry, Retry, and Refund Explicit States
Expiry and refund are different outcomes, so represent them separately in your application. Expiry means the channel’s deposit window has ended; a refund means a recognized deposit could not satisfy the swap’s execution conditions within the configured retry period.
Price protection determines one important failure path. Chainflip’s Swapping Basics documentation describes minimum accepted price and, where supported, maximum oracle slippage: if the condition is not met during the retry window, the protocol refunds the deposit to the specified refund address. The refund can take time to appear on the source chain, so keep the request and refund address attached to the original swap record.
A practical edge case is a deposit sent near expiry that confirms after the channel closes. Don’t automatically create a second channel and imply the first deposit will move to it; a new request has new swap instructions and does not retroactively bind the old transfer. Surface the original transaction status and direct the user to verify its outcome before attempting another deposit.
For each swap record, persist the request hash, source chain and asset, deposit address, expiry, destination details, protection parameters, source transaction hash, and final execution or refund status. That gives support and reconciliation jobs enough context to distinguish an expired request from a delayed confirmation or an unsuccessful swap.
For integrators, the key is to treat the request, deposit, and outcome as separate linked records with explicit expiry and refund handling.