Chainflip swaps native assets between blockchains without issuing wrapped substitutes. You can deposit BTC on Bitcoin and receive SOL on Solana, for example. Validators observe the deposit, execute the trade in a liquidity pool on the State Chain, and pay the output from assets held on the destination chain.
What Does a Native Swap Actually Mean?
A native swap changes which asset you hold without giving you a claim on a bridged representation of it. In a BTC-to-SOL trade, you send actual BTC on Bitcoin and receive actual SOL on Solana. Nothing needs to mint “BTC on Solana” for you to complete the exchange.
The assets do not travel from one blockchain to another. They enter and leave separate Chainflip Vaults, while the State Chain records deposits, balances, trades and payouts. The vaults are controlled through threshold signatures from the validator set; the State Chain’s accounting determines what each vault should release. That design avoids a wrapped output, but it still depends on the validator network, vaults and trading liquidity functioning correctly.
How Does Chainflip Settle a BTC-to-SOL Swap?
The swap starts with an instruction that identifies the input asset, output asset and destination address. A broker can register that instruction and obtain a deposit channel, or a supported vault swap can carry the required information in its transaction. The distinction matters: an ordinary transfer to a vault address carries no usable swap instruction.
After you deposit BTC, validators wait for sufficient Bitcoin confirmations and witness the transaction onto the State Chain. Three Bitcoin blocks, roughly 30 minutes, is a typical confirmation threshold; Ethereum deposits typically take about six blocks, roughly 90 seconds. These are confirmation estimates, not promises for the entire swap.
The State Chain then executes the trade in its just-in-time AMM. A BTC-to-SOL order normally takes two pool legs, BTC to USDC and USDC to SOL; USDC serves as an accounting and pricing intermediate, rather than a wrapped token you must receive or transfer. Liquidity providers can update their orders before execution, and swaps in the same pool and direction are bundled at the block level.
Finally, the network constructs an outgoing Solana transaction, signs it with its threshold scheme and broadcasts SOL from its Solana holdings to your destination address. Source confirmation, AMM execution and destination broadcast are separate stages. If a payout is delayed, identifying the stage is more useful than assuming the source deposit failed.
Which Assets and Networks Match the Task?
Asset names alone are insufficient: specify both the asset and its chain. Supported examples include BTC on Bitcoin; ETH and USDC on Ethereum or Arbitrum; and SOL and USDC on Solana. The supported set also includes assets on Asset Hub, Tron and BNB Smart Chain, but route availability and trade size still need checking when you act.
A common mistake is selecting WBTC on Ethereum because the intended output is “Bitcoin.” WBTC is an Ethereum token, while BTC on Bitcoin is the native asset; the same distinction applies to USDC on Ethereum versus USDC on Solana. If your application needs Bitcoin deposits, the destination must be BTC on Bitcoin, regardless of which token looks economically similar.
For a BTC-to-SOL transfer, settle the chain and asset pair before choosing where the SOL should arrive. The Chainflip protocol is the route to make that cross-chain exchange once those details are clear. In the Chainflip exchange, the deciding question is the asset your destination application can actually accept, not merely the ticker displayed beside it.
What Do Chainflip Fees, Timing and Limits Depend On?
Chainflip fees combine trading and network costs. Liquidity fees are typically about 0.10%–0.15% per pool leg , and the protocol network fee is typically around 0.10% of the trade, with a small dollar minimum. You also pay the source-chain transfer cost; the destination broadcast cost is deducted from the output. An optional boosted Bitcoin deposit adds a fee that is typically about 0.05%–0.30%.
For an illustrative $1,000 BTC-to-SOL swap with two pool legs, those liquidity fees amount to roughly $2–$3 and a 0.10% network fee to roughly $1. That is before Bitcoin transaction costs, Solana payout costs, any broker fee, and the spread or price impact in the pools. Compare the estimated amount arriving with the amount your task requires; adding advertised percentages alone will not give the final output.
BTC confirmation often dominates the wait for a regular swap. Boost can shorten that part of the process by advancing liquidity against an unconfirmed deposit, at the cost of its extra fee. Larger trades may instead benefit from execution split into chunks over multiple State Chain blocks, which can reduce price impact but increases elapsed time and exposes later chunks to a changed market.
Minimum and maximum deposit amounts, as well as minimum payouts, depend on the particular asset and current protocol parameters. Treat a quote’s accepted input range and estimated output as part of the trade specification. An amount that is economical for a $1,000 swap may be poor value for a small transfer once fixed chain costs are included.
How Do You Keep the Result Within Your Requirements?
Set a minimum accepted price and a source-chain refund address when initiating the swap. If available liquidity cannot meet that price during the chosen retry window, the unfilled input is returned rather than exchanged at any price. Live price protection can additionally bound deviation from an oracle price where that asset pair supports it; it is distinct from a minimum based on the original quote.
Those protections apply to AMM execution, not to every cost in the final payout. A successful trade can therefore deliver less than a simple minimum-price calculation suggests after network, broker and broadcast fees. With a trade split into chunks, completed chunks can reach the destination while later unfilled chunks return to the source-chain refund address.
Before sending funds, check the exact source asset and network, destination address, accepted amount and refund address together. Deposit channels generally close after about 24 hours, so use a fresh instruction for each transfer; sending directly to a vault without valid swap data, or outside the accepted amount range, can leave funds unrecoverable. The question to ask before acting is: will the asset arriving on that exact chain, after costs and within my price limit, satisfy the application I am funding?