A Chain Fusion Upgrade Should Not Rewrite Its Config: v0.5.1’s Governance Lesson

Chain Fusion Signer v0.5.1 adds btc_sign_prehash, allowing callers to ask the signer for a Bitcoin signature over an arbitrary digest. That expands the signer beyond its higher-level transaction flow and gives applications more control over transaction construction.

The more consequential change is operational. The release changes upgrade proposals to submit the Upgrade variant, preserving the canister’s existing configuration instead of reapplying the original Init arguments. For a shared signing canister, that is a meaningful safety boundary: an upgrade should change the Wasm implementation without silently resetting configuration that operators or governance have already established.

This matters because the Chain Fusion Signer is a governance-controlled public canister. The ICP developer documentation describes it as a shared service exposing threshold ECDSA and Schnorr APIs, with callers paying cycles through ICRC-2 approval. Its configuration is therefore part of a live service contract—not merely a deployment convenience.

For builders, the practical lesson is to separate three reviews. First, review the new interface: btc_sign_prehash signs a digest, so the caller remains responsible for constructing and validating the Bitcoin preimage and transaction semantics. Second, review the upgrade payload: confirm that a maintenance or feature upgrade uses the upgrade path and does not overwrite configuration with stale initialization data. Third, verify the deployed Wasm and proposal hashes independently before trusting a release.

The release also documents a working release-automation path and adds a dependency update for a Rust security advisory. Those details point to a broader shift: Chain Fusion maintenance is becoming an auditable governance workflow, where the artifact, the proposal, and the retained state must line up.

Caveat: the v0.5.1 release notes document these code and process changes, but they do not independently confirm the production upgrade date or deployment status. This article therefore treats production rollout as unconfirmed.

The new angle is not simply that Bitcoin can now receive another signature method. It is that signing infrastructure must preserve its operational identity while its code evolves. In Chain Fusion, upgrade semantics are part of the security model.