The Internet Computer is drawing the curtains on one of its longest-running backend flows. Developers who rely on the ledger_notify method for minting cycles are now being asked to shift to a more efficient and robust alternative. The legacy path, once the standard for creating or topping up canisters using ICP tokens, is now marked for deprecation. This marks a technical turning point for many within the ecosystem, particularly those operating at the infrastructure level.
The existing process works in two steps: an initial ICP transfer to a subaccount tied to the Cycles Minting Canister (CMC), followed by a separate notify() call to the Ledger. The memo in the transaction determines whether it’s a request to create a canister or top up an existing one. Once this second step is triggered, the Ledger performs a chain of checks and forwards the transaction details to the CMC, which then mints cycles based on the ICP/XDR rate and completes the operation.
While this model has served the community well, it carries a few serious drawbacks. The coupling between the Ledger and downstream canister calls means the Ledger has to wait for responses from the CMC—or even other subnetworks. If those downstream systems hang or become unresponsive, the Ledger is left holding open contexts, which interferes with upgrades and puts the entire flow at risk. This issue isn’t theoretical; it has already created challenges for the ecosystem’s upgrade agility.
There’s also the matter of deduplication. To prevent replay attacks or accidental double usage, the Ledger only keeps track of past notify() calls for a 24-hour window. If a notification doesn’t come through successfully within that short timeframe, the underlying ICP tokens can’t be re-used or recovered unless a manual fix is applied. It’s not hard to imagine how this could affect developers working across time zones or with limited automation.
Even worse, if the response from a notify call is lost—for example, due to frontend failure or poor network conditions—there’s no recovery path. The Ledger doesn’t store the result, so users can’t later find out what happened to their canister creation or top-up. In short, the system has too many single points of failure and too little room for error.
That’s where the new cmc_notify flow comes in. The process kicks off in the same way—transferring ICP tokens to a designated CMC subaccount—but now skips the Ledger as an intermediary in the notification step. Instead, users directly interact with the CMC via one of two new endpoints: notify_create_canister() for new canisters, and notify_top_up_canister() for replenishing existing ones.
This change alters the architecture in meaningful ways. Since the Ledger is no longer involved in downstream calls, its role becomes cleaner, reducing upgrade risks and improving overall reliability. The CMC, now in charge of its own deduplication, retains records for up to a million transactions, well beyond the previous 24-hour limit. If something goes wrong—like a lost network response—the user can simply try again with the same transaction index and get the original result.
The shift also brings more power to developers. When creating a new canister, they can now specify the subnet type or even pick a specific subnet. They can also define initial settings right from the start. This gives teams much-needed control during deployment, especially in production environments.
Switching to the new system is simple, technically speaking. Developers currently using ledger_notify just need to swap out the notify call to point to one of the two new CMC methods. No other part of the ICP transfer process needs to change. That said, developers should act quickly—there’s a firm removal date on the horizon. The notify() endpoint is scheduled to be permanently disabled at the end of June. After that, any integration still relying on the legacy path will stop working.
To ease this transition, the ICP team is taking a proactive approach. The Ledger’s notify() endpoint now logs the principal of each caller. This way, the team can try to identify and reach out directly to anyone still relying on the old flow. It’s an unusual but necessary move, driven by the goal of reducing friction and avoiding disruption for developers who might otherwise miss the announcement.
Those still using ledger_notify are being asked to confirm their status and provide an estimated migration timeline. If there are any blockers—be it a lack of engineering time, dependency on third-party libraries, or just confusion about how to proceed—the ICP team is open to support. Several developers have already begun the migration, and early feedback indicates that the process is straightforward and the benefits are real.
While this might seem like a low-level infrastructure change, it has broader implications for the stability and scalability of the Internet Computer. By removing dependencies between key canisters and allowing more graceful handling of delays or outages, the network is making itself more robust. It’s the kind of detail that won’t make headlines outside developer circles, but within the community, it’s a major quality-of-life improvement.
As decentralised systems continue to mature, these types of incremental updates—replacing tightly-coupled flows with more modular ones—play a big part in long-term resilience. The success of the cmc_notify transition will likely shape how future improvements to ICP infrastructure are rolled out. For now, the focus is on getting everyone off the old flow before it vanishes for good.
Anyone using ledger_notify and yet to begin the migration is encouraged to flag it publicly or contact the team. With only a few weeks left before the legacy route is removed entirely, preparation is key. The change is already live and ready for use, and those who’ve switched say it’s a clear upgrade in terms of control and reliability.
Developers who take the time now to transition will likely face fewer headaches in the months to come. And for a platform as complex and interconnected as the Internet Computer, fewer headaches means more time building—and less time untangling backend flows that no longer fit the way the network runs.
