Updates
14 October 2026 — node v0.24.3, client 0.19.1 unchanged.
Release published and managed-node rollout complete: v0.24.3 is tagged, image CI passed and all ten active managed nodes have been upgraded and verified. The required Meerkat and scheduler deployment artifacts were released too. This scope excludes decommissioned GCP, optional or stopped nodes, and unrelated deployments.
Previous update: 9 October 2026 — node v0.24.2
A DA collection can expire even when the chain is quiet
A channel submission can need data-availability attestations before it is sent for ordering. Previously, collecting those attestations expired only as committed rounds advanced. If the chain made no progress, a request could wait indefinitely instead of returning a useful refusal. Issue 88 adds an elapsed-time deadline independent of new blocks.
The default collection timeout is 20 seconds, configured by
ce.evolver.channel.da-collection-timeout-ms. The existing
30-round limit remains: a collection ends when either bound is reached.
The elapsed budget uses a monotonic clock, and an attestation received after the budget
expires cannot revive the collection.
This is a collection budget, not a hard real-time HTTP response guarantee. Timer messages still run through the overlay EventProcessor; a blocked processor can delay delivery. Collection state and its timer are retired before the completion callback runs, preventing a late event or a stale timer from completing the same collection again.
Retries do not replace the request already in flight
A duplicate submission while DA collection is in progress leaves the original request
intact and returns 409 with the in-flight transaction identifier to the
newcomer. When collection times out, the caller receives
503 da_unavailable. The existing SDK reads these as an in-flight transaction
and an explicit refusal respectively; no new client release is needed.
That distinction matters to application queues: an in-flight transaction is something to resolve, while a refused collection must not be mistaken for successful acceptance or an unexplained transport failure.
One owner for each identity-key HTTP request
Issue 155 fixes request-buffer ownership in the identity-key lookup handler. A matched request is released exactly once at the synchronous dispatch boundary, including when dispatch throws. An unmatched request is forwarded without adding an extra reference, leaving ownership with the next handler.
The regression tests use nonempty buffers and exercise successful, refused, failed and forwarded requests while preserving the route's responses. This is a targeted ownership fix, not a claim that every HTTP handler or every Netty leak has been audited and fixed.
A node-only patch, with deployment artifacts moving too
The node release is v0.24.3. Client 0.19.1, pi-evolver 0.9.1 and pi-meerkat 0.4.3 stay unchanged. There is no genesis, signed encoding or database schema change in these fixes; no chain reset or identity replacement is planned.
App deployment artifacts pin their node image by digest. Moving the committee alone is therefore not a complete upgrade: the Meerkat and scheduler artifacts must be released against the new node image, rendered with the existing deployment variables, and checked before restarting their node services.
All ten active managed nodes now run v0.24.3: Hetzner's committee and two front nodes, plus the local LLM node and six active agent nodes. Explorer and fleet monitor also run v0.24.3. The final readback found every node at round 6620, with all nine processing nodes having applied their stored tip. Existing node identities, public keys and data-volume mappings were preserved, and both front peers reconnected to the committee.
The required remote app pairs now use Meerkat v0.7.14 and scheduler v0.11.31, each still embedding client 0.19.1. Their main and tag pipelines passed. Both app images and all six OCI deployment artifacts were verified in Nexus; the bundled and devnet artifacts pin the exact v0.24.3 node digest. Fresh artifact digests and the existing deployment variables were used for the rolling upgrade.
The committee's round-100, round-500 and round-1000 block IDs were unchanged. Existing app owners, channel terms and balances were unchanged too. The Meerkat index retained its two expired entries, reported no missing or deferred bodies, and had walked through its round-6620 tip; the scheduler retained its identity, request channel and durable state.
Local registries remain on Meerkat v0.7.13; local agent and LLM proxy images were not rebuilt or restarted. They do not embed the remote app artifact's node pin, and their production code and SDK dependencies did not change in this patch. The signer and Nexus retained their original container IDs and start times; neither was restarted.
The newer Forge deployment record says its GCP deployment was removed on 13 October and further GCP use is prohibited. That is a recorded decommission, not a fresh GCP verification by this release. It is excluded from the rollout; no GCP deployment is recreated or upgraded. Optional and previously stopped nodes stay stopped, and existing keys, identities, channels and data volumes must be preserved.
Verification and release artifacts
The exact combined candidate passed the official full-container regression: 33 of 33 stages, exit zero, on 14 October. Its stage 52 empty-queue control took 1,626 ms and its wedged-path check 1,531 ms. An earlier separate DA-fix run was not a pass: its control took 10,112 ms against the 4,000 ms measurement guard. The test budgets were not loosened; the later clean combined run is the release's regression evidence.
Independent source review found no verified blockers. Java 21 validation with PARANOID leak detection passed 3,298 Scala tests, with four existing opt-in cancellations. Local statement coverage was 52.90%. The successful main CI pipeline passed the same test counts, reported 52.85% statement coverage against its 45% floor, and passed the declared npm gate, including 16 conformance checks and 900 differential comparisons. The CI gate explicitly skips two machine-sensitive streaming harnesses; those skips are not additional passing tests.
The tag image pipeline
passed all four jobs. Public Nexus manifests for evolver-node,
evolver-explorer and fleet-monitor were fetched by the exact
v0.24.3 tag, and each response's SHA-256 matched its registry digest. The node image is
sha256:013d25a50ad1f275d21f58b9bfb1de13d75645c72a320273eccd4f9da1a18f73.
The first local npm gate failed on an overlong Unix-socket pathname in nested
tsx processes. Correcting only the process-local temporary-directory pathname
made the exact declared gate pass. No test or product behavior was changed to obtain that
result.
The unchanged PeerContentAuthSpec outbound file-chunk fixture also reported a
pre-existing leak during unit validation. Green assertions do not mean a leak-free suite.
Other HTTP ownership candidates need their own audit, and the separate
mobile deletion authorization issue
is not addressed by this patch. Keep APIs inside their intended reachability boundary.