The Internet Computer has introduced a change that many developers have been asking for, and it’s now live across all mainnet subnets. Canisters are no longer strictly confined to their memory allocation. Instead of hitting a hard stop once they reach their preset limit, they can now continue using additional memory on a best-effort basis, depending on subnet conditions.
Previously, anything beyond the allocated amount would fail outright. That rigidity often forced developers to over-allocate memory just to avoid unexpected errors, which wasn’t cost-efficient. With the updated system, memory usage within allocation still works as expected and remains guaranteed. Once a canister grows beyond that allocation, it moves into a flexible mode where success depends on available subnet memory, freezing rules, and the storage-cycle mechanism that kicks in when a subnet crosses certain usage thresholds.
The change also affects billing. If a canister stays within its allocation, charges reflect the allocated figure. If the canister exceeds it, charges are based on actual usage instead. This approach makes costs more aligned to real behaviour rather than cautious over-reserving.
A simple example shows how it works. A canister with 100GiB allocated and 96GiB used continues to pay for 100GiB. If it grows to 98GiB, nothing changes. But if it needs another 6GiB, taking it to 104GiB, that expansion now succeeds when the subnet has enough free memory, the canister avoids freezing, and the system can reserve the storage cycles. If those conditions line up, the action goes through and the canister is billed for 104GiB instead of the allocated 100GiB.
Developers will likely welcome this shift because it removes the hard ceiling that used to cause sudden failures, while keeping clear guardrails in place so the network stays stable. It’s a practical change rather than an extravagant one, giving canister controllers better control over how they manage resources without forcing them into overly cautious allocations.
For those who want the finer technical detail or wish to review the constraints, the full explanation is available through the Internet Computer forum, alongside references to the updated documentation.
This update doesn’t rewrite how canisters behave, but it does reduce friction. More importantly, it offers something many teams value: room to adjust as their applications grow, without the fear of an abrupt stop the moment their allocation is exceeded.
Dear Reader,
Ledger Life is an independent platform dedicated to covering the Internet Computer (ICP) ecosystem and beyond. We focus on real stories, builder updates, project launches, and the quiet innovations that often get missed.
We’re not backed by sponsors. We rely on readers like you.
If you find value in what we publish—whether it’s deep dives into dApps, explainers on decentralised tech, or just keeping track of what’s moving in Web3—please consider making a donation. It helps us cover costs, stay consistent, and remain truly independent.
Your support goes a long way.
🧠 ICP Principal: ins6i-d53ug-zxmgh-qvum3-r3pvl-ufcvu-bdyon-ovzdy-d26k3-lgq2v-3qe
🧾 ICP Address: f8deb966878f8b83204b251d5d799e0345ea72b8e62e8cf9da8d8830e1b3b05f
🪙 BTC Wallet: bc1pp5kuez9r2atdmrp4jmu6fxersny4uhnaxyrxau4dg7365je8sy2q9zff6p
Every contribution helps keep the lights on, the stories flowing, and the crypto clutter out.
Thank you for reading, sharing, and being part of this experiment in decentralised media.
—Team Ledger Life
Community Discussion