Chain Fusion Signer v0.3.0 Gives Bitcoin a First-Class Signing Path

ICP’s Chain Fusion story has gained a more practical Bitcoin building block: the shared Chain Fusion Signer now exposes a dedicated method for signing Bitcoin transactions.

The change arrived in version 0.3.0 of the open-source signer, released on February 4, 2026. Its headline feature is a BTC signing method that lets callers obtain a signed Bitcoin transaction. The corresponding ICP Dashboard proposal records an upgrade of the mainnet signer canister to that version and includes the commit, WebAssembly hash, and argument hashes used for verification.

That matters because the signer is designed as a reusable public canister. Developers do not have to deploy a separate backend canister merely to reach ICP’s threshold-signature APIs. Instead, applications can call the governance-controlled signer, approve it to spend cycles through the Cycles Ledger, and request operations for external chains.

The current developer documentation shows the Bitcoin path in concrete terms. A caller can derive a deterministic Bitcoin address for a principal, inspect its balance, and invoke btc_caller_send. The send request specifies the Bitcoin network, address type, UTXOs to spend, fee policy, and destination outputs. The new release’s signing method is especially useful for applications that need to construct or control transaction serialization themselves, rather than relying only on a higher-level send helper.

This is a meaningful shift in developer ergonomics. Bitcoin’s UTXO model requires explicit handling of inputs, outputs, and fees. A generic signature endpoint can provide cryptographic capability, but it leaves more chain-specific work to the application. A dedicated Bitcoin signing method gives builders a narrower interface aligned with Bitcoin transaction workflows while preserving ICP’s threshold-signing model.

The security boundary also remains important. The signer does not hand a private key to the caller. Chain Fusion uses threshold cryptography so that signing authority is distributed across subnet nodes. The signer is a public, shared service, however, which means developers must understand its governance and payment model. Each call consumes cycles, and the documentation instructs users to approve an allowance before making requests.

The release also includes a reproducibility-oriented Docker change: the Linux CPU type is specified in the build configuration. That is not a user-facing Bitcoin feature, but it strengthens the audit trail around the binary proposed for canister installation. The governance record publishes the release commit and hashes, giving operators a concrete artifact to compare.

The broader implication is not that ICP has created a new Bitcoin bridge. It has made one part of Chain Fusion easier to consume: threshold signing for Bitcoin from a shared canister interface. That can support wallets, automated services, and cross-chain applications that need Bitcoin control without placing a conventional private key in one server.

Editorial caveat: the v0.3.0 release is dated February 4, 2026. The sources verify the method, documentation, and upgrade record, but they do not provide independent measurements of production adoption or signing volume. The strongest claim supported today is therefore an API and infrastructure improvement, not a proven usage breakthrough.