ckBTC’s Archive Gets a Larger Safety Margin for Subnet Storage Pressure

The Internet Computer’s NNS is considering a narrowly targeted resilience change for ckBTC: proposal 143835 would raise the reserved cycles limit of the ckBTC archive canister, nbsys-saaaa-aaaar-qaaga-cai, from 5 trillion cycles to 1 quintillion cycles. The proposal was published on September 8, 2026.

The important detail is what this setting does—and does not do. On a subnet using more than 750 GiB of storage, the protocol moves cycles from a canister’s main balance into a reserved balance when the canister allocates additional storage. The reserved-cycles limit caps that balance. If required reservations would exceed the cap, a memory-growth operation can fail. ICP’s documentation identifies increasing the limit as one remedy for that specific failure mode.

That makes the proposal an operational safeguard for ckBTC’s historical record. The ckBTC ledger automatically creates archive nodes as transaction volume grows, while the archive canister holds past ledger transactions. If the archive needs to expand during periods of subnet storage pressure, a low reservation ceiling could become an avoidable write-growth boundary.

The proposed value is 1,000,000,000,000,000,000 cycles—200,000 times the stated 5 trillion-cycle default. The proposal says this exceeds the largest reservation the protocol could demand on the subnet and therefore should not need to be revisited. It also states that changing the limit does not itself reserve or spend cycles: actual reservations remain bounded by the canister’s cycles balance.

For builders, the lesson is broader than the number. A canister’s ability to grow depends on both available funding and configuration ceilings. Raising a ceiling does not finance storage, waive storage charges, or guarantee unlimited memory growth; it removes one configuration-based reason for growth to fail. The canister must still have enough cycles to pay for its resource use.

The same desk is also tracking companion proposals for the ckBTC ledger and index canisters. Together, they suggest a maintenance pattern around the full chain-fusion token stack: keep the ledger, archive, and indexing surfaces from inheriting an unnecessarily tight reservation limit as usage expands.

The live dashboard lookup did not expose the proposal’s current voting status or outcome, so this article does not claim that proposal 143835 has been adopted or executed. The primary proposal page remains the authoritative source for that status.