Engine controller proposal 144560 adds canister creation on engines

NNS proposal 144560, submitted on October 23, 2026, upgrades the engine-controller canister from commit e9963e1c5852e407327d04fcccfc1fd8ad50d948 to 3e645182ac06c7b761040615db4e3d44a8349351. The upgrade adds canister creation, state-limit controls and a cool-down switch for cloud engine subnets. If your code calls create_engine or update_subnet, change it to send the complete subnet_admins list, because the super admin is no longer added for you.

What changes in the engine controller

Pietro Di Marco of DFINITY submitted the proposal. It lists seven commits under ./rs/engine_controller. The upgrade argument is the empty Candid value (). Three are feature commits for the engine controller and registry: PRs #11924, #11863 and #11519. The other four touch shared code that the canister depends on: a cooling_down field on SubnetRecord, configurable query limits in SubnetRecord, a secp256r1 variant for EcdsaCurve, and the removal of ReplicaVersion::default().

New methods and arguments:

• create_canister creates "an empty canister on a cloud engine subnet, controlled by the given controllers only."
• change_subnet_membership passes calls through to the registry's endpoint of the same name. When the engine controller is the caller, the registry only allows this on CloudEngine subnets.
• create_engine takes an optional resource_limits record with maximum_state_size and maximum_state_delta. The values go into the new subnet's CreateSubnetPayload. If you leave it out, the subnet gets the protocol defaults, as before.

Changes to update_subnet:

PR #11863 explains why the state limits are needed. Until now, every cloud engine subnet started with the protocol defaults, whatever hardware its nodes had. A subnet is only as big as its smallest node, so an engine on small nodes needs tighter limits. An engine whose nodes are upgraded should be able to raise them again. The PR also describes a registry rule: when the engine controller is the caller, any limit the payload leaves unset keeps its current value. A state-size-only update therefore keeps the delta limit and any query limits set by governance. Governance updates still replace resource_limits as a whole.

PR #11519 describes the cool-down switch. A cooling-down subnet drains its subnet queues and streams. During that time it runs no canister messages and serves no queries. The engine controller can do this before it halts the subnet. Both the engine-controller proxy and the registry check which fields are allowed, and the registry still requires the target to be a CloudEngine subnet.

Who is affected

This matters to teams that run cloud engines and to anyone who builds tools that call the engine controller. Canisters running on mainnet subnets are not affected.

The change that can break existing code is in subnet_admins. With the current version, the engine controller's authorized caller (the super admin) was added to subnet_admins on every create_engine and update_subnet call. With 3e64518, the proposal says "the supplied list is now forwarded to the registry as-is." A script that sent only the customer's principals, and counted on the super admin being added, will now remove the super admin from that subnet. The proposal lists this as a fix for create_engine and a change for update_subnet.

The other changes are additions. resource_limits is optional, so callers who do not send it keep the current behaviour. With create_canister, an engine owner's provisioning flow can create empty canisters on the engine with a chosen set of controllers. The new update_subnet fields let operators resize a subnet after its nodes change, and make it cool down before a halt.

Check the proposal's status on the dashboard before you depend on the new methods. Until the proposal is adopted and executed, mainnet runs the canister at git hash e9963e1 (wasm hash 120dce8e153bd9118a3a1eabc9378f8041b81ce563bc97f95d96514e43861aee).

What to do now

If you vote on NNS proposals or review them, you can rebuild the wasm yourself. These steps are taken from the proposal and apply to commit 3e64518:

git clone git@github.com:dfinity/ic.git
cd ic
git checkout 3e645182ac06c7b761040615db4e3d44a8349351
./ci/container/build-ic.sh -c
sha256sum ./artifacts/canisters/engine-controller-canister.wasm.gz

The result should match the proposal's wasm_module_hash field. To check the upgrade argument, install didc and run:

didc encode '()' | xxd -r -p | sha256sum

The result should match the proposal's arg_hash field.

If you maintain code that calls the engine controller:

1. Find every call to create_engine and update_subnet that sets subnet_admins.
2. Add each principal that should keep admin rights, including the super admin if you still want it there. The canister no longer adds it.
3. Decide whether new engines on smaller nodes need resource_limits in create_engine. Leave it out to keep the protocol defaults.
4. If you resize existing engines, send only maximum_state_size and/or maximum_state_delta in update_subnet. Setting query limits fails for this caller.
5. If your shutdown flow halts a subnet, consider setting cooling_down first so the subnet can drain, and then set is_halted.
6. Regenerate client bindings from the new engine_controller.did after execution so that you get create_canister, change_subnet_membership and the new optional fields.

Other releases this week: dfinity/ic tagged release-2026-10-22_03-29-base on October 22, and Motoko 2.1.0 shipped on October 21.