Bitcoin’s Digest Boundary Moves Into the Chain Fusion Signer

The latest verified Chain Fusion Signer release changes a small but important boundary for Bitcoin developers: v0.5.1 adds btc_sign_prehash, an API for signing an arbitrary digest with the signer’s Bitcoin key. That matters for applications that already construct or hash Bitcoin-specific payloads and need ICP to authorize the final digest rather than accept a higher-level transaction format.

The release also scales the Bitcoin send-fee helper with the number of transaction outputs. That is a practical correction for UTXO transactions: a transaction with more outputs can require a different fee estimate than a simple one-recipient payment. Developers should still treat the helper as an estimate and retain their own policy for fee rates, change outputs, confirmation targets, and replacement behavior.

The deeper change is operational. Upgrade proposals now use an explicit Upgrade variant so an upgrade preserves the canister configuration instead of reapplying initialization arguments. The project also documents its release automation and adds controls for which files the release bot may modify. For a public signing canister, these details are security features: they reduce ambiguity around upgrades and make the path from a reviewed change to a deployed artifact easier to inspect.

ICP’s documentation describes the signer as a governance-controlled public canister that exposes threshold ECDSA and Schnorr APIs to web applications and command-line users. Calls are paid in cycles, normally through an ICRC-2 allowance, while private key material remains distributed across the Internet Computer’s threshold-signing system.

What developers should take from v0.5.1 is not a new signing algorithm or a performance breakthrough. It is a more precise Bitcoin integration surface. Prehash signing can help wallet, custody, and protocol tooling keep serialization logic in the layer that understands it, while the upgrade and release changes make the shared signer easier to operate cautiously.

Editorial caveat: the latest verified release is dated July 16, 2026, even though it was checked on August 15, 2026. The release notes do not claim higher signing throughput or a changed threshold-security model; the significance here is API coverage and operational discipline, not a protocol upgrade.