Chain Fusion’s Hidden Scaling Lever: Why Pre-Signature Inventory Matters

A cross-chain application can be perfectly designed and still stall at the moment it needs to sign. In ICP’s Chain Fusion architecture, canisters can control Bitcoin, Ethereum, Solana, and other external-chain accounts through threshold signatures, but the signing subnet remains a shared production resource.

That resource received a significant engineering upgrade in February 2026. DFINITY engineers reported that cryptographic work was parallelized, expensive operations were moved out of critical execution paths, and pre-signature artifacts were moved into replicated subnet state. Pre-signatures are materials prepared before a user request arrives; producing them is the main performance bottleneck in the threshold-signing protocol.

The practical change is an inventory model. Instead of generating every component under the pressure of an incoming transaction, the subnet can prepare thousands of artifacts during quieter periods. When demand spikes, requests can consume that inventory immediately. The forum announcement says optimized signing subnets can sustain more than ten times their previous throughput and can exceed 100 signatures per second while pre-signatures remain available.

That headline needs careful interpretation. The 100-plus figure is a burst ceiling for specially configured high-signing-load subnets, not a universal rate for every Chain Fusion application. The same announcement says the production fiduciary subnet’s conservative parameters, following NNS proposal 140289, corresponded to approximately 3.5 tECDSA signatures per second, 6.5 tSchnorr signatures per second, and 18 vetKeys signatures per second under the cited configuration.

For builders, this creates a more useful design question than simply asking whether ICP can sign faster: how does an application shape demand? A wallet batching many withdrawals, a Bitcoin service managing UTXOs, or an automated settlement canister should separate user-facing ingestion from signing execution, tolerate queueing, and avoid assuming that a temporary burst limit is permanent capacity. Timers and retries also need to distinguish a signing queue from an external-chain confirmation delay.

The upgrade therefore strengthens Chain Fusion’s control plane rather than magically accelerating Bitcoin, Ethereum, or Solana. External fees, block production, RPC availability, and confirmation times still apply after ICP produces a signature. The improvement targets ICP’s threshold-signing service; it does not by itself remove latency, fees, or congestion on external chains.

The broader lesson is that threshold cryptography is becoming an operations problem. Precomputation, replicated state, queue sizing, and subnet parameters now matter alongside key security and signature correctness. As more canisters use Chain Fusion for automated payments and cross-chain execution, the applications that plan around signing inventory—not just peak cryptographic benchmarks—will be better positioned to deliver predictable behavior.