Pillar operators: upgrade to znnd v0.0.9 now
Short version. go-zenon v0.0.9 is out. Every pillar needs to be on it before the community spork address renewal window opens at momentum 14,567,887, projected around 3 November 2026. Within the next 60 to 90 days a new spork will be issued through that window. Nodes still on v0.0.8 will reject it and split off onto a dead chain. Upgrading takes a few minutes with znn-controller and keeps your chain data and producer key.
Release: Release v0.0.9 · zenon-network/go-zenon · GitHub
Why this is not optional
v0.0.9 adds a second authorization window for the community spork address, momentums [14567887, 19791986). The original window closed long ago, so today no spork can be activated at all. The new window is how the network regains the ability to upgrade itself.
The first spork sent inside that window is accepted by v0.0.9 nodes and rejected by v0.0.8 nodes. From the momentum that contains that spork’s contract receive, the two groups are on different chains. A pillar still on v0.0.8 at that point stops following the real network, stops producing valid momentums, stops earning, and will need a resync after upgrading. There is no way to make an old node accept the spork after the fact.
Plan to be upgraded well before 3 November. The spork itself will follow in the 60 to 90 days after this post.
What else v0.0.9 fixes: the momentum 14,103,620 stall
In September the network stalled at momentum 14,103,620. The cause is a bug that makes a chain split cheap to trigger.
An account block’s hash does not cover its signature. Ed25519 lets a key holder produce many different valid signatures for the same block, so two copies of one block can carry different bytes but the same hash. When those two copies reach the network, some nodes hold copy A in their pool and some hold copy B. The pillar that produces the momentum includes whichever copy it has, and the stored bytes feed the momentum’s changes-hash. Every node holding the other copy fails the changes-hash check and cannot import the momentum. That is a stall for those nodes, and a split if a producer keeps building on either side.
Nothing exotic is needed to cause this. One account broadcasting the same block twice with two signatures is enough. v0.0.9 fixes it: when a momentum arrives, the node compares its pool copy against the momentum’s content byte for byte and replaces a mismatched copy with the momentum’s version, with order and duplicate checks before the pool is touched and a snapshot restore if the insert fails. The review of this fix also hardened the pool against several related edge cases in batched contract receives.
How to upgrade with znn-controller
Run this as root on the pillar. The controller stops znnd, pulls the current go-zenon master (v0.0.9), rebuilds, keeps your config and producer key, and restarts the service. The ledger is kept, no resync is needed.
./znn-controller
- Select
1) Deploy. - If asked “Are you sure you want to proceed with the deployment process?”, answer
Y. - When you see “Producer configuration detected. Continue using the existing configuration?”, answer
Y. This keeps your existing producer address and key file. - Wait for the build to finish. The controller starts the
znndservice when it is done.
If you do not have znn-controller on the machine, download it from Releases · zenon-network/znn_controller_dart · GitHub, unzip, chmod +x znn-controller, then run the steps above.
Verify the upgrade
Check the version the running node reports:
curl -s -X POST http://127.0.0.1:35997 -H 'Content-Type: application/json' \
-d '{"jsonrpc":"2.0","id":1,"method":"stats.processInfo","params":[]}'
You should see "version":"v0.0.9". Then confirm the node is producing: select 2) Status in znn-controller, or run systemctl status znnd and watch the momentum height climb. The commit field in that RPC response may be empty on a locally built binary; that is cosmetic and is being addressed separately.
Manual alternative
Prebuilt binaries for Linux, macOS and Windows are attached to the release, with a SHA256CHECKSUMS.txt. Stop the service, replace /usr/local/bin/znnd with the downloaded znnd-linux-amd64 (or arm64), make it executable, and start the service again.
One more thing while you are in there: RPC exposure
v0.0.9 keeps the RPC defaults from v0.0.8: HTTP and WebSocket RPC are enabled, both bind to 0.0.0.0, and CORS and origins are *. If your pillar’s config has never been changed, its RPC is reachable from the internet. Bind it to 127.0.0.1 in config.json, or firewall ports 35997 and 35998, unless you deliberately run a public node. This is unchanged behaviour, not a new issue, but it is worth fixing during the upgrade.
Timeline
| When | What |
|---|---|
| 10 October 2026 | v0.0.9-alphanet released |
| Momentum 14,567,887, about 3 November 2026 | Renewal window opens |
| 60 to 90 days from now | New spork issued. Un-upgraded nodes split off |
| Momentum 19,791,986 | Renewal window closes for good |
Questions or problems upgrading: reply here.