Chainflip swaps: what integrators need to know

Chainflip lets an app swap assets across supported blockchains by coordinating deposits, pricing and payouts through its own network. For integrators, the key is to register each swap before funds move: the network needs to know the destination asset, chain and address.

Chainflip’s broker documentation describes two ways to start. An app can request a deposit channel through a broker, or call a supported Vault contract directly. The chainflip flow then lets validators watch for the incoming transfer and record it on the State Chain, Chainflip’s coordination blockchain. The choice depends on where the user’s funds start and how much control the app needs over the transaction.

How does a Chainflip swap move funds?

A swap begins when the app registers its destination details and the user sends funds to the resulting address or contract. Validators confirm the deposit on the source chain, then the State Chain processes the trade through Chainflip’s JIT AMM, an automated market maker that matches available liquidity. The network sends the output asset from a vault on the destination chain.

This differs from a typical bridge route that locks an asset and issues a wrapped version elsewhere. Chainflip’s protocol overview says its trading balances are tracked on the State Chain while assets stay in protocol-controlled vaults on their native chains. That avoids a wrapped token in the swap path, but users still rely on the validator network to manage those vaults and settle the payout.

Which integration path should an app use?

Use a broker and deposit channel when the user sends a transfer to a one-time address and the app needs to supply destination details up front. Use a Vault swap when the user can call a supported contract directly; on EVM chains, the broker API can encode the swap parameters for that transaction. Chainflip’s broker documentation sets out the paths and the data each needs.

• Deposit channel: register the swap, show the user the address, then wait for the deposit to be witnessed.
• Vault call: build and submit a contract transaction with the destination and swap details.
• Either path: keep the deposit transaction and swap status visible so users can follow progress.

The first option is often simpler for an app that does not need to compose the swap with another on-chain action. A direct Vault call can suit an app that needs a contract-level handoff. In both cases, integration means handling two chain transactions: the incoming payment and the outgoing payout.

What should integrators account for?

Deposit channels expire after 24 hours, according to Chainflip’s broker documentation, so create a fresh one for each swap and prompt the user to send funds promptly. Confirmation time also depends on the source chain. Chainflip’s swap documentation gives different confirmation thresholds for Ethereum and Bitcoin, so an app should show a pending state rather than promise an instant result.

For a first integration, model the swap as a sequence of registered intent, deposit, confirmation, trade and payout. That makes the main trade-off clear: Chainflip handles cross-chain execution, while the app remains responsible for presenting the correct destination details and keeping the user informed as each step completes.