Chainflip swaps: choosing a path for your integration

A Chainflip integration should use deposit channels for wallet-agnostic funding and vault swaps when users can sign a source-chain transaction. Both paths carry a swap from a source asset to a destination address, but they start differently: one reserves a deposit address before the user sends funds; the other asks the user’s wallet to submit a transaction to the Chainflip vault. That first step shapes the product experience and the work required from the integration.

How does a Chainflip swap start?

A deposit-channel swap begins when the app requests a quote, then asks a broker to open a channel with the swap details, including the destination chain and address. The broker returns a unique deposit address. The user sends the source asset there, and that deposit starts the swap. The channel expires after 24 hours, so it should be created for an imminent deposit rather than kept as a reusable address. The chainflip protocol then witnesses the deposit, processes the swap and sends the output to the destination address.

This path suits products where the user should not have to connect or transact from a source-chain wallet at the moment the swap begins. A user could fund the address from a separate wallet, for example. The integration still needs to show the address and channel status clearly, and give users a way to verify the channel-opening transaction. A broker submits that request on the user’s behalf and can charge a commission; an integration that needs broker fees or affiliate commissions needs its own Broker API.

When should an integration use a vault swap?

Use a vault swap when the product already has a connected wallet and should make the swap a signed transaction in that wallet’s normal flow. The app requests a quote, encodes the swap details for the source-chain vault, and asks the wallet to submit the transaction. For an ERC-20 token, the user may also need to approve the vault to spend the token. The swap details travel with the vault transaction, so there is no separate deposit address to create first.

This is often the more natural fit for an on-chain app whose users already expect to approve and sign transactions. It can also mean less waiting at the start: the user submits the transaction directly instead of first waiting for a deposit channel request. The trade-off is that the app must handle wallet connection, signing, chain-specific transaction formats and, where required, token approvals. Across Bitcoin, Solana, EVM networks and other supported chains, transaction construction differs, so the source chain matters as much as the product design.

How should you choose between the two paths?

Start with the action you want the user to take. Deposit channels make the source-chain step a transfer to an address; vault swaps make it a wallet-signed vault transaction. Then check that the route and source asset support the chosen swap type. Chainflip’s SDK can return available chains and assets filtered by capability, along with quotes that distinguish regular, vault and other supported options. Treat those responses as live integration data rather than maintaining a fixed list in the interface.

For most wallet-agnostic products, deposit channels are the simpler user-facing choice: the user funds an address, and the app does not need to build a source-chain vault transaction for each wallet. For a wallet-native product, vault swaps usually fit better because the user signs the swap in the same flow as other on-chain actions. A quote alone does not settle the choice; compare its output, fees and estimated timings for the actual route, and display the selected route’s terms before the user commits.

• Use a deposit channel when users may fund from a separate wallet or the product avoids wallet signing.
• Use a vault swap when users are already connected and a signed source-chain transaction fits the flow.
• Check route availability and quote details for the exact source and destination assets.
• For either path, pass a valid destination address and define refund and slippage handling.

The choice changes where the swap begins: at a reserved address or in a signed vault transaction. Next, verify support and quote terms per route, then build the status and recovery steps around that starting point.