September 10 network and operator update

The configured testnet is producing and finalizing blocks after the September 10 recovery and managed node rollout. This page records a dated observation, not a promise that a future maintenance window will be interruption-free. Recheck live finalized state before acting.

Node software, downloads and runtime

These are three separate facts:

Surface	Verified state on September 10
Managed node deployment and public RPC node	3.0.0-dev-764f8c18114, source 764f8c18114386efa1587731e76c185b3f992280
Public releases/current download selector	nightly-3eb6295b-20260908, source 3eb6295b06aef11e87a01a7b22e36e166af2cb72
Finalized on-chain runtime	mainnet spec 286, transaction version 4; unchanged by this node rollout

The immutable v1.1.0 package remains available as historical release evidence. Neither that package nor the September 8 public nightly contains the September 10 managed correction. A public package promotion for 764f8c1 is not established by this documentation update. Check metadata, artifact checksums, architecture, compatibility and the operator-approved revision before choosing an upgrade. Do not downgrade a newer managed node to match an older example or moving link. The dated values are also in the network manifest.

Corrections and qualification

The managed build includes a bounded transaction-pool wait and cancellation handling so stale-parent work cannot hold the authoring path indefinitely. It also classifies local receipt/storage lookup failures separately from protocol rejection. Qualification exercised real-runtime BABE reorganization, transaction retention after a competing head, and recovery after peer loss. Captured pending transactions finalized once after the competing tip was retracted in the successful rehearsal.

The rollout preserved the existing chain history, genesis, identities, keys, authority membership and runtime. Every managed node passed independent canonical-finality checks, and the active managed validators produced fresh finalized blocks. A slow startup exposed an automation defect: RPC version availability alone was an insufficient baseline. The corrected deployment helper waits for the expected genesis and version, connected peers and completed sync before measuring finality, and retains failed canonical-check evidence alongside a verified rollback.

This evidence does not establish the exact blocked task in the original live incident or resolve the separate receipt-history divergence problem. A successful service restart also does not qualify an abrupt power loss or every host's cold-boot sequence.

Verify progress, not just readiness

system_health, AUTHORED and readyToAuthor can remain reassuring while finality is stalled. Check the height of the authorship proof and require a fresh finalized block after startup. Resolve each chain_getFinalizedHead hash with chain_getHeader, sample again after an observation interval, and compare a common finalized height with an independent trusted node.

A configured validator can be an unelected candidate. Keep registration, queued keys, active session membership and observed authorship separate. A non-authoring full node should not fail a health check merely because it has no validator keys or authored block.

Maintenance and clocks

Upgrade or reboot one active validator at a time, with enough other elected authority weight online to preserve quorum. Use a graceful systemd stop and verify the process exits before shutting down the host. Preserve the keystore, node identity, data volume and old executable; check encrypted-volume unlock, mount ordering, clock startup gates and dependent services before the window. After startup, require completed sync, independent finality agreement and fresh authorship appropriate to the node's active role.

The managed validators retain the explicitly temporary early-testnet participation profile. It is not the strict software default and does not permit bypassing synchronization, active-key or fresh authority evidence. Do not change timing enforcement, quorum or membership as an incidental recovery step. Follow the upgrade and recovery guide.

Explorer, wallets and governance

Explorer routing and loading recovery have also been corrected. Check the named finalized source and freshness of displayed data; an HTTP success or loading indicator does not prove a current index. Agora supports participant review and the separately available wallet flows; governance.roko.network remains a wallet-free read-only evidence surface. A healthy proposal index is not execution authority.

An EVM wallet's ability to send Ethereum transactions does not establish support for Agora's Substrate extrinsic signing. Follow wallet compatibility before generating an enrollment package, then verify finalized candidacy and selection through the validator guide.