Updates

7 October 2026 — node v0.24.0

This release closes two routes through which a stranger could interfere with a node's local application, makes peer identity checks take effect, and lets a consumer recover when a channel body cannot be found. Node operators and application operators both need to update. Unlike v0.23.0, this is a coordinated network upgrade: nodes using the old default chain name cannot connect to nodes using the new one.

Peer certificates now identify the actual chain

The production node was bypassing its network configuration reader. The certificate checks for chain name and protocol version therefore could not enforce the intended separation. Production now uses one reader, and the default chain name is derived from the genesis identifier instead of being the same evolver-demo string on every chain. Unknown evolver.network keys now stop the node at boot, so a misspelled setting no longer looks as though it worked.

Coordinate the upgrade with your peers. With default settings, v0.24.0 and v0.23.0 reject one another's certificates in both directions. Upgrading just one node leaves it disconnected; a normal rolling upgrade cannot keep that mixed fleet connected. Devnet's managed nodes have already moved, so a node still using the old default must update to rejoin them. An explicit evolver.network.chain-name overrides the derived name, but it is a deliberate network-wide choice, not something to set independently on one node.

A stranger can no longer advance your application's cursor through the peer API

/api/channel/next is a single-consumer, forward-only cursor. Exposing it on a listener peers can reach allowed another caller to advance it past the real consumer, losing deliveries without leaving that consumer a way to rewind. The route is now served only on the plain local API listener. The mobile remote-signer API also leaves the peer TLS listener; it included device-enrolment deletion without a credential. These are reasons to upgrade even if your node appears healthy.

The plain API now binds to loopback by default

Moving a local capability off the peer listener would achieve little if its replacement still listened on every interface. The new http.bind-host defaults to 127.0.0.1. An application in a separate container cannot reach that loopback address: without a configuration change, its requests will get connection refused after the upgrade.

For an application on the node's private Docker network, set http.bind-host = "0.0.0.0" in the node configuration before restarting, and keep that plain API port off the public host. Binding to every container interface is safe only when the network boundary limits who can reach it. Applications on the same host can keep the loopback default.

A missing body no longer holds up every later read

A channel transaction can be ordered even when this node cannot find its body. Previously the consumer could wait forever at that position, also preventing a processing node from applying later state. The node now reports body-unavailable when its search deadline expires, allowing the consumer to continue. A negative answer from one peer does not end the search, and a peer cannot keep restarting the deadline.

Rebuild applications with @mcsherrylabs/evolver-client 0.18.0. Its drainChannel understands the new result and reports skipped positions through onMissed. Supply that callback and record misses in your durable application state; without it, the client still skips and emits a warning. A timeout is not proof that the body is gone forever: retrying the same position can find it later, but once the consumer advances, its forward-only cursor cannot go back.

A holder with an unreachable address can still send content

A peer advertising a LAN address used to be less useful than one advertising no address at all: the node tried to pull from the advertised URL and abandoned the holder when it could not connect. It now asks that holder to push the content instead. Reachability is judged from the requesting node, so a URL working on the holder's own network is no longer enough to send the transfer down a dead end.

The local capabilities are listed in one place

The release inventories the unauthenticated capabilities whose protection depends on who can reach their listener. That review also found a separate gRPC exposure, tracked as issue #152; the inventory does not itself close it. The cursor and mobile peer-listener fixes above are the runtime changes in this release.

Devnet and the running managed fleet are on v0.24.0

All eleven running managed nodes have upgraded, including the GCP forge and six local agent nodes. The chain, identities and application stores were preserved; the fleet reached round 2722 after the restarts. Meerkat v0.7.12, scheduler v0.11.28 and Forge v0.2.13 embed client 0.18.0. Published agent tool packages can still bring an older client transitively, so verify the version inside the image you actually run. Changing a Compose default alone also cannot replace a node image pinned by a deployment artifact: use an updated artifact and check the running image.

The full container regression passed all 33 stages, and the unit suites passed 3,257 tests. The coordinated deployment then confirmed peer connections, advancing chain state and application reads on the running fleet.

Before you restart

1. Arrange the v0.24.0 upgrade with your network's peers. Keep your existing genesis, identity keys and data volumes.
2. Check the node's API bind address for your application's topology. Containerized apps need access over their private network; the plain API must remain private.
3. Rebuild and redeploy applications with client 0.18.0, including their transitive tool dependencies, and handle missing bodies through onMissed.
4. Use the updated deployment artifact or image, then verify the running node version, peer connections, chain progress and a real application read. A green container health check alone does not prove the application can reach its node.