Cloud Engines, Online Subnet Splitting and Pay-As-You-Go Outcalls: What the ICP Code Says Is Coming Next

Cloud Engines, Online Subnet Splitting and Pay-As-You-Go Outcalls: What the ICP Code Says Is Coming Next

Roadmap pages tell you what a team hopes to ship. The commit log tells you what it is actually building. We read the roughly 1,500 commits that landed on the master branch of dfinity/ic between late March and 4 September 2026, cross-referenced them with the NNS proposals and forum threads they cite, and pulled out the changes that will matter most to people building on the Internet Computer over the next few months.

Six streams stand out: Cloud Engines and their NNS upgrade train, online subnet splitting, flexible HTTPS outcalls with pay-as-you-go pricing, a new deposit model for ckETH and ckERC20, a batch of management-canister features, and the Mission 70 squeeze on rewards. Most are not on mainnet yet. All of them are in code you can read today.

1. Cloud Engines get a real control plane

The Mission 70 plan describes Cloud Engines as private subnets that a team assembles from network nodes through an NNS-hosted configurator, with 80 percent of engine revenue going to the nodes and 20 percent burned. The registry now has a subnet type for exactly that. rs/protobuf/def/registry/subnet/v1/subnet.proto defines SUBNET_TYPE_CLOUD_ENGINE = 5, described as "configurable, application-specific private subnets under the auspices of the NNS and its rules for safety".

The user-facing piece is a new engine controller canister (rs/engine_controller, mainnet id si2b5-pyaaa-aaaaa-aaaja-cai), which the registry now authorises alongside NNS governance to create and delete subnets. Its Candid interface is small and telling:

service : (opt EngineControllerInitArgs) -> {
  create_engine : (CreateEngineArgs) -> (CreateEngineResult);
  delete_engine : (DeleteEngineArgs) -> (Result);
  update_subnet : (UpdateSubnetPayload) -> (Result);
  change_subnet_membership : (ChangeSubnetMembershipPayload) -> (Result);
  deploy_guestos_to_all_subnet_nodes : (DeployGuestosToAllSubnetNodesPayload) -> (Result);
}

create_engine takes a list of node ids (four is the enforced minimum), the principals that become subnet admins, and a replica version. update_subnet forwards the full registry payload but the registry rejects anything other than subnet_id and subnet_admins when the caller is the engine controller. Only one hard-coded principal may call the canister today, and new engines are bootstrapped from a non-NNS subnet's DKG on purpose, so the NNS is never the parent of a private engine.

The cleverest part is how engines get upgraded. An engine may leave replica_version_id blank in its SubnetRecord, which means "follow the standard train". The train is a new registry record, StandardEngineReplicaVersionRecord, with three fields: new_replica_version_id, old_replica_version_id and deployment_progress, a float between 0 and 1. Each engine computes an "upgrade priority" by hashing the string upgrade priority, the new version id and its own subnet id with SHA-256, taking the first eight bytes as a little-endian integer and dividing by 2^64 - 1. Engines whose priority is at or below deployment_progress run the new version; the rest stay on the old one. Bumping progress from 0.1 to 0.5 to 1.0 is therefore a deterministic canary rollout across the whole fleet, and rolling back is setting it to 0.

That knob is exposed through a brand-new NNS proposal type, UpdateStandardEngineReplicaVersion (governance PR #10884), with a matching ic-admin propose-to-update-standard-engine-replica-version subcommand. Supporting work over the summer included allowing XNet traffic on engines, opening the API boundary nodes' SOCKS proxy to them, firewall rules for running ic-gateway as a side-car to the replica, subnet deletion in the registry, message routing and PocketIC, and a guard that refuses to split an engine while a version deployment is in progress.

2. Subnet splitting without hours of downtime

Splitting a subnet has been possible for years, but only offline, with a long halt while state is copied. The 2026 work makes it an online protocol operation. The registry mutation do_split_subnet validates the payload strictly: only Application and VerifiedApplication subnets can be split, the node set must be divided evenly, signing subnets, rental subnets and halted subnets are excluded, and the feature sits behind an is_subnet_splitting_enabled flag.

Consensus does the interesting work (PR #10980 and PR #10936). When a split is scheduled in the registry, the DKG summary marks the interval as Scheduled. Replicas then halt block-making, and instead of producing one catch-up package for the summary height they each build a "post-split" CUP for a block 500 heights ahead, computed deterministically for the subnet they will belong to after the split. Two sets of CUP shares circulate on the same peer-to-peer network; each side validates the shares that match its own post-split block and state hash and rejects the other's. Destination-subnet replicas keep halting until the orchestrator sees the PostSplit CUP and restarts them under their new subnet id.

Two smaller additions round it out. A cooling_down flag on SubnetRecord and SubnetTopology quiesces a subnet: no ingress is inducted, nothing is routed to or from it, and refunds are parked rather than lost, so streams can drain before a split or a merge. And a subnet_merged marker in SystemMetadata suggests merges are on the same track. For canister authors nothing changes in the API, but a subnet you deploy to today may be two subnets tomorrow, with a short pause instead of a multi-hour outage.

3. Flexible HTTPS outcalls, now with pay-as-you-go pricing

On 2 September the FLEXIBLE_HTTP_REQUESTS_FEATURE flag in rs/config/src/execution_environment.rs flipped to Enabled (PR #11399). The flag does three things: fully replicated and non-replicated outcalls may now select the pay-as-you-go pricing version, flexible outcalls become available on ordinary paying subnets, and free and system subnets switch to pay-as-you-go accounting while staying free. It lands on mainnet with the next elected IC OS version, so watch the version-election proposals.

The request shape is FlexibleCanisterHttpRequestArgs, which adds a replication record to the familiar URL, headers, body, method and transform:

record {
  total_requests : nat32;
  min_responses : nat32;
  max_responses : nat32;
}

A canister chooses how many replicas fetch and how many agreeing responses it needs. Because those numbers only make sense relative to the subnet, there is a new system API, ic0_subnet_self_node_count. Pricing version 2 (PRICING_VERSION_PAY_AS_YOU_GO) replaces the flat legacy charge with a base fee plus refunds of unused cycles, delivered asynchronously; a request that runs out of budget fails with a dedicated OutOfCycles error. PATCH is finally an allowed method, and max_response_bytes applies to flexible requests too. The draft interface spec lives in dfinity/developer-docs pull request 254, and PocketIC v16 already models both flexible outcalls and pay-as-you-go pricing so you can test locally before mainnet flips.

4. ckETH and ckERC20 learn to receive plain transfers

Today a ckERC20 deposit means calling a helper contract with your principal. The minter is growing a second path that works with a plain transfer from any exchange or wallet. A new deposit_erc20 endpoint derives a deterministic Ethereum address per ICP account and asset from the minter's threshold-ECDSA key (PR #10685), returns it together with a minimum_deposit_amount, and then scans the address's balance. The status moves from Scanning to AwaitingSweep once funds are detected.

Sweeping uses EIP-7702. The deposit address signs an authorization delegating its code to a sweeper contract, the minter signs an attestation binding the address to the ICP account, and a dedicated sweeper address, with its own nonce so a stuck sweep can never delay a withdrawal, sends a type-4 transaction that installs the delegation and moves the tokens in one go. The last commit before we went to press (PR #11449, 4 September) extends the same machinery to plain ETH sitting at a deposit address. Fee funding, per-token minimums and a Sponsored mode where someone else pays the registration fee are still being wired up, so treat this as a preview rather than a launch.

5. Management canister: visibility, metrics and bigger subnets

A run of smaller changes will show up in the interface spec soon:

• status_visibility joins log_visibility and snapshot_visibility as a canister setting, with controllers, public and allowed_viewers (up to ten principals). Denied calls return the new error code 542, CanisterStatusAccessDenied.
• minimum_incoming_canister_call_cycles lets a canister refuse inter-canister calls that do not attach enough cycles, without touching canister_inspect_message.
• subnet_metrics becomes a management-canister endpoint returning block_height, num_canisters, canister_state_bytes, consumed_cycles_total and update_transactions_total, the same numbers read_state serves under /subnet/<id>/metrics.
• canister_info is now a query, and composite queries may call the management canister's query methods.
• The maximum number of canisters per subnet rises to 250,000 (forum thread 74862), canisters may hold 32 environment variables instead of 20, the creation timestamp is exposed in the state tree, and fetch_canister_logs works in replicated mode with the new log memory store.
• Per-subnet query limits are now registry configuration rather than compile-time constants, which is what lets an engine buy itself a bigger query budget.

6. SEV everywhere, rewards under pressure

Confidential computing moved from experiment to invariant. A registry check now refuses any mutation that would leave an SEV-enabled subnet on a GuestOS version without guest_launch_measurements (PR #11057), the attestation handshake mixes the debugging policy into derived keys and rejects a server that merely mirrors the client's attestation, and Bazel can build SEV recovery images. Proposal 142743 created the second SEV-enabled subnet, so expect the measurement requirement to become the default for new subnets.

On the economics side the code is blunt. NNS motion 142724, "Follow-up on Node Provider Standards, Incident Response Readiness", is implemented in the node rewards canister as final = base * performance_multiplier * 0.5 for providers that failed both incident-response smoke tests, over a fixed window from 15 July to 15 October 2026, with a second cohort added at the end of July. It rides on the Mission 70 approval that cuts annual issuance from 9.72 percent toward roughly 2.92 percent by year end. Governance gained upgrade options for InstallCode proposals and a reserved_cycles_limit field for UpdateCanisterSettings, and two community motions worth following are open on the forum: one to explore a technical collaboration with Bittensor, and one to revive SNS-1.

What this means for builders

• Design for outcall budgets now. Decide how many replicas each external call really needs; single-replica reads plus a quorum of two or three for anything that mutates state will be far cheaper than today's full replication once pay-as-you-go reaches mainnet.
• Assume your subnet can move. Online splitting keeps canister ids and state, but a cooling_down subnet will pause ingress for a while; make clients retry idempotently.
• Audit your canister settings. status_visibility defaults to controllers, so nothing leaks by accident, but public dashboards and monitoring tools will want public or an allowed_viewers list, and minimum_incoming_canister_call_cycles is an easy defence against cycle-drain spam.
• Test against PocketIC v16. It already understands flexible outcalls, pay-as-you-go pricing and subnet deletion, which is the cheapest way to find out how your code behaves before an IC OS election proposal makes it real.