Solv

Solv tokenized Bitcoin transfers through Chainlink CCIP

Solv uses Chainlink's Cross-Chain Interoperability Protocol (CCIP) for SolvBTC and xSolvBTC transfers across supported blockchain networks. Solv announced the migration from LayerZero bridges in May 2026. Each transfer still needs an enabled token connection, a compatible destination, and successful destination execution.

Last updated 8 October, 2026

SolvBTC and xSolvBTC under the CCIP migration

SolvBTC is a tokenized Bitcoin reserve asset, while xSolvBTC has a distinct staking-related role through Babylon. Cross-chain standardization changes how these assets move between chains without merging the products.

Solv announced its move from LayerZero bridges to Chainlink CCIP on May 7, 2026. The announced LayerZero deprecations concerned Corn, Berachain, Rootstock, and TAC. The decision followed a security review of the protocol's cross-chain infrastructure.

Network support has an asset and a direction

A transfer needs support for the selected token in the chosen source-to-destination direction. CCIP's network coverage and the protocol's token coverage describe different things. A blockchain may support CCIP without offering a usable connection for every asset. The SolvBTC integration spans Ethereum, BNB Chain, Solana, Arbitrum, Avalanche, and Base, among other networks. That coverage does not establish every possible connection between their token deployments.

The local token pool must recognize the remote chain, token, and authorized pool, and the source router needs an active destination lane. A lane is a directed connection between networks. These requirements make routing a configuration question, even when both chain names appear in network lists. Support for SolvBTC also does not automatically establish support for xSolvBTC on the same connection.

Transfer settings and who controls them

On Ethereum Virtual Machine (EVM) networks, each enabled token uses a token contract, a token pool, and a registry entry. These components divide token-contract permissions from routing administration. A holder authorizes a transfer, while the configured contracts determine whether its selected connection and conditions allow execution.

The Token Admin Registry records the active token administrator and pool address. Deploying a replacement pool alone does not redirect transfers; the registry must point to it. Pool upgrades and a migration between bridge providers therefore involve distinct configuration changes. Transfer rules come from both the deployed CCIP contracts and the token-pool version. An older pool can remain in use after a CCIP service upgrade; optional version 2 pool features require their own configuration.

Open full-size image

Burn-and-mint accounting on the connected chains

The listed SolvBTC connections use burn and mint to move token representations without requiring a swap into another Bitcoin product. A burn-and-mint transfer destroys the transferred tokens on the source chain and creates their counterparts on the destination chain. The authorized pools coordinate those local token operations through CCIP.

For a successful transfer, the source burn supplies the accounting basis for destination issuance. During transit, source tokens may already be gone before the destination balance appears. A reduction on one chain therefore does not, on its own, show the transfer has finished. Destination minting completes the movement of that token representation.

A token pool handles the local token operation, while CCIP validates the message authorizing the remote operation. The configured remote token and pool specify which destination representation can receive the corresponding issuance. This pairing establishes the connection between contracts; matching ticker text alone cannot establish it.

What confirms delivery on the destination chain?

A successful source transaction establishes the send-side operation, while delivery requires successful execution of the CCIP message on the destination chain. The destination has its own execution state, which determines whether token handling and any applicable message delivery completed.

The source transaction creates a message identifier linking the transfer to its destination processing, allowing tracking across chains. It identifies a submitted message and does not certify destination delivery.

Verification establishes whether the source message meets the applicable cross-chain validation requirements. Standard finality handling waits for the required source-chain finality before proceeding. The destination receives the relevant proof or attestations under the deployed CCIP architecture.

On the destination, the authorized execution contract checks the message and invokes the token pool's mint or release operation. A token-only transfer delivers the asset to its encoded recipient. Programmable transfers can also involve a receiver contract callback.

The destination receipt and delivered token amount describe the corresponding on-chain outcome. Any additional application action depends on the receiving contract's logic and the transfer's message contents. For EVM programmable transfers on CCIP 2.0, a receiver callback failure reverts the associated token delivery within that execution attempt.

Bitcoin custody remains a separate control layer

The CCIP migration governs cross-chain token messaging; Bitcoin reserve custody remains a separate part of Solv's architecture. The Bitcoin-mainnet system governs native BTC custody and reserve issuance, while token pools handle local operations for cross-chain representation. Consequently, bridge security, reserve backing, and a staking strategy expose different controls and risks. A successful token transfer confirms delivery without demonstrating the performance or solvency of every underlying product.

The fee quote and the amount delivered

The applicable fee depends on the route and message settings, including destination execution resources. EVM applications obtain a message-specific quote through the router's getFee function. The source transaction checks fee sufficiency when it sends the message. Changing the destination or execution settings changes the inputs used to calculate the quote. Cross-chain charges can cover message verification, destination execution, and the network service. The source-chain transaction also consumes gas. Token-pool fees may apply when the deployed pool configuration enables them, and these costs remain distinct even when a bridge interface presents them together.

Fees paid separately in the selected fee asset do not automatically reduce the bridged token quantity. Version 2 token pools can also configure a percentage deduction in the transferred token. When such a fee applies, only the amount after that deduction continues through the burn or lock operation. The sender's displayed input, the service-fee payment, and the delivered asset amount therefore represent different quantities.

How long does a CCIP transfer take?

A CCIP transfer takes the time required for its source-chain finality policy, cross-chain verification, and destination execution. The route's networks and execution conditions determine the elapsed time. Faster-than-finality processing is an opt-in capability with additional reorganization risk, where supported and configured. The deployed token-pool and application settings determine whether faster processing is available. Destination congestion or an execution failure can extend delivery beyond the source-chain wait.

Rate limits and temporary transfer capacity

Enabled token-pool rate limits govern the quantity a route can process, with separate settings for outbound and inbound transfers. Capacity caps the amount a full bucket can accept, while the refill rate governs how quickly consumed capacity returns.

Available capacity changes as other transfers consume it. An amount may fit below the configured maximum and still exceed what the bucket currently holds. Insufficient outbound capacity blocks the source send; insufficient inbound capacity can cause destination execution to fail. Waiting can help only when the amount fits within maximum capacity and the bucket is refilling. An amount above that maximum requires a smaller transfer or a configuration change. Transfers using the same rate-limit bucket share its capacity, so splitting an amount does not remove that bucket's sustained flow limit.

Pool owners or authorized rate-limit administrators control these settings. Holders do not acquire administrative rights by owning SolvBTC. A limiter can restrict one token's connection without pausing the entire CCIP network. Enabled status, capacity, refill rate, and remaining capacity determine the actual restriction. Administrators can change these on-chain settings without changing the token ticker.

Manual execution for incomplete destination delivery

CCIP provides manual execution for eligible messages whose destination delivery remains incomplete; on EVM destinations, the execution contract checks the original message and required verification data before attempting delivery. Recovery continues the same transfer; submitting another source send would create a separate message.

For routes using CCIP 2.0, a message awaiting its first destination execution differs from one whose execution already failed. Both states can remain executable when the required inputs and conditions permit. A successful message cannot execute again, and a retry cannot bypass token-pool rules, missing verification, or a receiver's failing logic.

In that version, the failure's cause determines the remedy. A receiver callback with insufficient gas may need a higher callback limit. A token-handling or rate-limit failure needs the relevant pool condition resolved; changing callback gas does not repair that problem. Even a successful outer transaction can record a failed message execution. The applicable recovery method changes with the destination chain family and deployed CCIP version.

Solv: reader questions