ckUSDT’s Index Gets a Memory Safety Buffer—At a Recurring Cost

Proposal 144039 asks the NNS to set the ckUSDT index canister’s memory_allocation to 4,294,967,296 bytes—4 GiB—from its current value of 0, which means dynamic or best-effort allocation. The target is canister cefgz-dyaaa-aaaar-qag5a-cai.

The operational reason is the index’s growth pattern. The proposal says the canister mirrors every block produced by the ckUSDT ledger and does not archive those records. Its memory therefore grows with the ledger rather than reaching a stable footprint. The proposal reports current usage of about 404 MiB, leaving roughly 3.61 GiB below the requested allocation.

That distinction matters on ICP when a subnet is above its storage-reservation threshold. ICP’s documentation says a fixed memory allocation pre-allocates capacity, while memory beyond the allocation remains on-demand and may fail if the subnet is at capacity. The platform also moves cycles into a reserved balance for future storage payments when memory grows on a sufficiently full subnet. A canister’s reserved_cycles_limit can prevent such growth when the required reservation exceeds the limit.

The proposal’s argument is therefore about failure behavior, not merely capacity planning. With the current best-effort setting, future growth could require an advance reservation and be rejected after the canister exhausts its reserved-cycle limit. With a 4 GiB allocation, growth that remains within the reserved range would not face that particular rejection path.

There is a cost trade-off. The proposal says the fiduciary subnet is below its 750 GiB reservation threshold, so applying the setting would reserve no cycles immediately. It estimates the full 4 GiB allocation at about 104.8 trillion cycles per year on a 34-node subnet, while noting that the canister already pays for memory it uses. The incremental charge is described as the currently unused headroom.

For Chain Fusion developers, the broader lesson is that an index canister’s storage policy is part of its reliability design. A reserved allocation buys predictable room for an ever-growing history, but it also creates a recurring obligation that must be monitored alongside cycle balances, subnet saturation, and the canister’s actual growth rate.

This is a proposal, not a claim that the setting has already been applied. The usage, headroom, subnet state, and cost figures above are reported by the proposal and can change as the system evolves. ICP’s canister-settings documentation and CLI reference confirm the behavior of fixed memory allocation and reserved-cycle limits.