IC GuestOS proposal 144660: 83f29e0 fixes Dogecoin adapter startup

NNS proposal 144660, published on October 30, 2026, asks the network to elect GuestOS release-2026-10-30_12-16-base at commit 83f29e0803496ba6aaea3d6b43f6c6bebea12dd9. The release fixes the start order of the Dogecoin adapters, requires NTS time sources on nodes and moves the toolchain to rustc 1.99.1. Neuron holders and node providers should check the build before voting, and canister teams should read the execution fixes below.

The forum post that announced the proposal on October 30 opened voting. Check the proposal page for the current result. Electing a version only makes it available: subnets move to it later, through separate deployment proposals.

What is in release 83f29e0

The release notes say the build is "based on changes since" release-2026-10-22_03-29-base (5e8370e0a84ffb783d6a9d77e0d3e90fa3914cfe). That is about one week of GuestOS work. The changes that matter most to developers:

The networking layer also gets attention. Nodes now pull stream slices when they receive adverts instead of in every round (e17c7975e). They only verify NothingNew adverts that advance the recorded header (d96942843), and HeightIndexedInstants<T> storage is optimized (d973d1d96). Several refactors move the pull schedule into PullTask and put pool population and adverts in a new exchange module.

On the node image, SELinux is now selected with lsm= (d26648f47), the C++ infogetty tool is replaced by a Rust version (7c7a7e8f6), and the update-config component is removed (9a6741e41). The out-of-memory error text has also been improved (e80eca425).

Who is affected and why it matters

Dogecoin integration. The Dogecoin adapters connect subnets to the Dogecoin network. If an adapter starts before its permissions are set up, it can fail at boot. Commit bc5c5adf8 fixes the order. Teams that build on Dogecoin through the IC should watch adapter health after this version reaches their subnet.

Node providers. Two changes touch the machine itself. First, chrony no longer falls back to plain NTP. The node needs working NTS (Network Time Security) sources, so a network that blocks them can leave the clock unsynced. Second, the boot-failure fix (4f9e663a4) and the SELinux lsm= change change how GuestOS starts. Providers who had boot problems on the previous version should test this one.

Canister developers. Most of the execution fixes are about what happens in error paths:

• If applying an execution's state changes fails, the canister logs for that execution are now kept instead of lost. This helps when you debug a failed call.
• A failed re-execution of an aborted install_code is now cleaned up. This affects long installs and upgrades that run across several rounds.
• Instruction accounting against round limits now uses saturating subtraction, so the counter cannot wrap around.
• The out-of-memory error text changed. If your tests or monitoring match the exact text of that error, check them after the upgrade.

Monitoring and tooling. The new canister-to-canister communication metrics and the monotonic consumed-cycles value in subnet_metrics give dashboards a counter that only goes up, which is simpler to graph than a value that can go down. The ic-management-canister-types bump to 0.11.0 and the stricter replica_version_id field in ReplicaVersionRecord (now mandatory) matter to people who read registry records or build on the replica crates.

For the previous GuestOS election on this desk, see IC GuestOS proposal 144468: release 661a980 with all-in-one nodes. For why pinning exact base releases matters for Chain Fusion builds, see ICP's September Base Release Makes Version Provenance the Chain Fusion Story.

What to do now

DFINITY's GuestOS election threads include a reproducibility script that builds the image locally and compares hashes. Earlier election threads use this form; here the commit for this release is filled in:

# Verify the GuestOS image for release-2026-10-30_12-16-base
curl -fsSL https://raw.githubusercontent.com/dfinity/ic/master/ci/tools/repro-check | \
  python3 - -c 83f29e0803496ba6aaea3d6b43f6c6bebea12dd9 --guestos

# Or verify by proposal number
curl -fsSL https://raw.githubusercontent.com/dfinity/ic/master/ci/tools/repro-check | \
  python3 - -p 144660

The SHA256 of the downloaded image and the SHA256 of the image you build must match each other and the hash in the proposal payload.

Checklist:

1. Open proposal 144660 and confirm the commit is 83f29e0803496ba6aaea3d6b43f6c6bebea12dd9 and the status (open or adopted).
2. Run the reproducibility check above on a Linux machine with enough disk space, and compare the hashes.
3. Read the full diff with the GitHub compare view: release-2026-10-22_03-29-base...release-2026-10-30_12-16-base.
4. Node providers: make sure the node network allows NTS time sources, because chrony no longer falls back to NTP.
5. Canister teams: search your tests and alerts for the exact out-of-memory error string and update them after the upgrade if needed.
6. Dogecoin builders: after the subnet upgrade, check that your calls through the Dogecoin integration succeed.
7. Tooling authors: if you parse ReplicaVersionRecord or depend on ic-management-canister-types, plan the move to 0.11.0.

Caveats

The release notes say some commits may be left out if they do not change the GuestOS image, and that some descriptions were shortened. The full list is in the DFINITY release-notes file linked from the proposal. Electing the version does not upgrade any subnet: each subnet moves only when a later deployment proposal for it is adopted.