ICP’s Bitcoin Signer Adds a Prehash Lane for Wallet Interoperability

The latest listed Chain Fusion Signer release, v0.5.1, adds a small API with a meaningful integration consequence: btc_sign_prehash signs an arbitrary, precomputed 32-byte digest under the caller’s Bitcoin key.

That is different from a conventional send helper. The signer’s existing Bitcoin transaction methods build a transaction from supplied UTXOs and outputs, then sign the transaction inputs. The new method accepts a hexadecimal 32-byte hash and returns a raw 64-byte ECDSA signature, represented as r || s. The caller must recover the recovery identifier from the known public key and apply whatever encoding the target workflow requires.

The repository’s interface documentation describes this as the Bitcoin counterpart to the signer’s Ethereum prehash method. It also explains why a generic ECDSA call is not interchangeable: the generic API derives a Generic key, while the new method uses the Bitcoin (Btc) key schema so that the signature can verify against the caller’s P2WPKH address.

For Chain Fusion builders, the practical shift is composability. A canister or wallet integration can prepare a Bitcoin-specific digest outside the signer’s transaction-construction path and request only the cryptographic signature from ICP. That opens a cleaner route for workflows such as wallet interoperability, message signing, and partially signed transaction tooling. The signer remains responsible for threshold ECDSA execution; the application remains responsible for deciding exactly what bytes are hashed and how the resulting signature is packaged.

That division is the important safety boundary. A prehash endpoint does not understand the meaning of the digest. It cannot tell whether a hash represents a valid Bitcoin message, a correctly serialized transaction, or an unintended payload. The interface rejects values that are not valid hexadecimal 32-byte digests, and it reports signing and payment failures, but semantic validation still belongs to the caller.

The current ICP documentation places the Chain Fusion Signer among the reusable building blocks for applications that hold and operate external-chain assets. It describes Chain Fusion as direct interaction with networks such as Bitcoin, Ethereum, and Solana under ICP’s protocol trust assumptions, while the signer exposes threshold-signature APIs to web applications and CLI users.

The release therefore matters less as a new Bitcoin transport than as an expansion of the signing surface. Builders can now separate transaction or message construction from key custody, but that flexibility should be paired with domain-separated hashing, strict serialization tests, public-key/address checks, and explicit user approval of the payload before a signature request is sent.

One limitation should remain explicit: the release notes and interface definition do not establish that every PSBT or message format is supported. Integrators must construct and validate the digest and signature encoding themselves. The repository also does not establish adoption or deployment across all Chain Fusion applications; it only identifies v0.5.1 as the latest listed release and shows a 16 July release date.