Chainflip First Swap

Updated on

Chainflip is a protocol for swapping supported assets across blockchains. A deposit address accepts a standard transfer, while a Vault Swap carries swap instructions in a source-chain transaction. For a first swap, the choice depends on whether the sending wallet supports the required transaction format for the selected asset and network.

Navigate this article

Entry Method Comparison

Entry Method Wallet Fit and Preparation
Deposit Address Fits a sender that can transfer the selected asset to a standard blockchain address, including compatible hardware wallets and custodial withdrawals. The deposit-address flow requires no wallet connection or contract approval. A broker must register the deposit channel before funding.
Vault Swap Requires a wallet or application that can build, sign and submit the source chain’s encoded swap transaction. Applications usually request a wallet connection for this method. Bitcoin also requires a private channel that the broker opens beforehand.

Asset, Network and Amount Requirements

Chain and Asset Support
The source and destination assets and their chains must form a supported combination. A token ticker alone does not identify its network. The SDK’s getChains and getAssets methods can filter support by depositChannel or vaultSwap . The SDK removed Polkadot support in version 1.11 and directs DOT swaps to Assethub.
Swap Amount Limits
The minimum and any maximum apply to the particular source asset on its source chain. getSwapLimits returns these changing bounds in the asset’s base units, such as satoshis for BTC. Funds below the minimum or in excess of a configured maximum are absorbed by the protocol and cannot be recovered. Check the applicable limits before funding either method.
Quote and Refund Settings
A quote gives expected output, fees and duration. These are estimates for the selected swap. Where slippage protection is configured, funds that cannot be swapped at or above the minimum accepted price within the retry duration are returned to the specified source-chain refund address. An applicable refund can still incur refund and broadcast fees.

Deposit Channel Funding and Expiry

A broker records the destination asset, chain and address when opening a deposit channel. The generated source-chain address then associates an incoming transfer with those instructions. This is how a normal transfer can initiate a cross-chain swap without carrying the swap instructions in the sending transaction.

Deposit channels can accept more than one deposit while open. However, How Swapping Works? , updated September 21, 2026, describes a 24-hour open period and instructs users to create a fresh channel for each swap and fund it promptly. Late deposits may no longer be recognized after the channel expires.

Graphic: Deposit Channel Funding and Expiry (Chainflip)

Open full-size image

A saved vault address is not a substitute for a registered deposit channel. Sending funds directly to a vault without the required Vault Swap instructions can result in lost funds.


Vault Swap Formats

A Vault Swap uses freshly encoded instructions to construct a single-use transaction on the source chain. The SDK’s encodeVaultSwapData returns unsigned transaction data; the user still needs to sign and submit the transaction. Encoding the payload alone does not move funds.

Topic diagram: Chainflip First Swap: Deposit Address or Vault Swap?

Chainflip First Swap: Deposit Address or Vault Swap?

  • Entry Method Comparison
  • Asset, Network and Amount Requirements
  • Deposit Channel Funding and Expiry
  • Vault Swap Formats

Open full-size image

Vault Swaps avoid waiting for a new swap deposit channel to be registered. The Broker Vault Swaps guide describes deposit-channel creation as requiring State Chain finality, which can take up to 18 seconds. That preparation difference does not remove source-chain confirmation or destination settlement time.

Ethereum, Arbitrum and BSC
EVM Vault Swaps call the Chainflip Vault contract on the source network. BSC support for this method was introduced in version 2.3. ERC-20 inputs may also need token approval before the swap call, so a wallet that can only send tokens to an address may not support the complete Vault Swap transaction.
Solana
Solana Vault Swaps use a program instruction with encoded data and the required accounts. A standard SOL transfer does not supply that instruction. The sending wallet or integration must support the program transaction that the encoding describes.
Tron
Tron Vault Swaps transfer assets to the vault with encoded swap parameters attached as a transaction note. The note identifies the swap. Supported TRC-20 inputs, such as USDT, do not need a separate token approval for this method. The Tron Vault Swaps guide recommends Vault Swaps because they avoid the protocol fetch transaction and its ingress fee; other swap and source-chain transaction costs still apply.
Bitcoin

Bitcoin Vault Swaps use a private Bitcoin channel opened by the broker. The transaction must begin with these outputs in this order:

  1. A payment to the returned deposit_address .
  2. An OP_RETURN output carrying the returned nulldata_payload .
  3. A change output whose address becomes the refund address.

The change output is mandatory and must exceed the dust threshold for its address type. Some input value must therefore remain for change. Bitcoin Vault Swaps cannot attach a cross-chain message for a follow-on destination contract call.

Bitcoin Vault Swap payloads expire after two epoch rotations. The broker’s persistent private channel does not extend a payload’s validity. Use newly encoded transaction data instead of relying on an old unused payload.


Swap Progress and Destination Receipt

Swap status is separate from the sending wallet’s transaction record. A deposit address identifies the funding destination, while a source-chain transaction hash identifies the funding transaction. Neither establishes that the destination asset has arrived.

Chainflip: Swap Progress and Destination Receipt - diagram

Open full-size image

The SDK’s getStatusV2 can look up a swap using its deposit-channel ID, Vault Swap transaction hash or swap ID. Its response distinguishes progress states from COMPLETED and FAILED . Destination receipt concerns the outgoing transfer of the selected asset to the intended address on the selected network. Source-chain inclusion alone is an intermediate result.

Both entry methods still depend on deposit recognition, trade execution and the outgoing transfer. Choose the method that the sending wallet can correctly submit, then assess completion from the swap status and destination transfer rather than from how quickly the initial address or payload was prepared.