ICP’s Registry Upgrade Turns Chain Fusion Readiness Into an Upgrade-Ordering Problem

The Internet Computer’s latest Registry Canister proposal is less a single feature release than a coordination upgrade for the network’s control plane.

Proposal 144199 proposes moving the Registry Canister to commit 98c898f. The commit combines changes that matter directly to Chain Fusion—most notably a new secp256r1 option for ECDSA chain-key configuration—with safeguards around subnet splitting, replica-version deployment, and Registry-state migration.

The cryptographic addition is deliberately incomplete on its own. The proposal allows create_subnet and update_subnet to name the NIST P-256 curve, but a subnet using that configuration still needs the key to be generated and enabled through separate proposals. For developers building cross-chain applications, that distinction matters: configuration support is not the same thing as an operationally available signing key.

The upgrade also adds a merge_subnets endpoint, exposed through a MergeSubnets proposal. Its scope is intentionally narrow: it rewrites the routing table so canister ranges move from one subnet to another, while leaving both subnet records unchanged and retaining the source subnet. That makes the operation a routing transition rather than a full subnet teardown.

Several changes are aimed at preventing control-plane races. A subnet split now fails if the relevant standard-engine replica-version record changes while fresh key material is being generated. A split from a cloud-engine subnet is also rejected while a new replica version is deploying when that subnet derives its version from the same record. Together, these checks reduce the risk that a topology change produces two subnets with inconsistent runtime versions.

The commit additionally tightens Registry invariants. Elected GuestOS and HostOS version identifiers must be parseable by the version types that consume them. Catch-up-package records must carry a CUP type, while a one-time migration classifies legacy records as Genesis or Recovery. Genesis CUPs no longer need a height field because their height is understood to be zero.

The most operationally revealing change is the increase of MAX_CHUNKABLE_ATOMIC_MUTATION_LEN from 10 MiB to 13 MiB. The accompanying commit explains that Registry migrations accumulated during a longer-than-usual upgrade cadence, producing an approximately 12 MB mainnet mutation during post_upgrade. This is a capacity adjustment for upgrade machinery, not a user-facing throughput increase—and it also exposes a maintenance lesson: deferred migrations can turn routine upgrades into atomic-state sizing problems.

The proposal was published on October 2, 2026. The related IC base release was published the same day, but the proposal itself remains the authoritative place to check the governance action and its execution state. The proposal page and source material describe the intended upgrade; this article does not independently establish that the upgrade has executed on mainnet. Likewise, adding secp256r1 support does not generate or enable a chain key: separate proposals are required for that step.

For Chain Fusion developers, the practical takeaway is to treat Registry capabilities as staged infrastructure. First verify that the relevant curve and subnet configuration are available; then verify that key generation, enablement, routing, and replica-version state have progressed consistently. The commit makes those transitions more explicit—and gives the Registry a larger buffer for the migrations needed to manage them.