ProvableHQ/snarkOS v4.10.0 on GitHub

Network: mainnet. This is the mainnet release of Aleo Stack v4.10.0; the same code shipped to testnet as testnet-v4.10.0.

Mainnet consensus version (V20) activation height: 22,175,000 — estimated Tue 2026-09-22 ~07:40 UTC at current block times.
Testnet V20 activated at height 19,374,000 on 2026-09-06.

The Aleo maintainers are excited to announce the release of Aleo Stack v4.10.0. This release focuses on strengthening the foundations of the network: it introduces an encrypted handshake for validator connections, lays the groundwork for the upcoming V20 consensus upgrade, and delivers a broad set of hardening, performance, and observability improvements across snarkVM and snarkOS.

Highlights include:

Encrypted validator handshake: validators now establish connections using an asymmetrical Noise-XX handshake, replacing the legacy plaintext handshake with an encrypted, mutually authenticated channel. snarkOS#4354
Stronger deployment verification: the V20 consensus version adds more accurate type checking of the root call and bounds the size of every plaintext type declared in a deployed program. snarkVM#3319, snarkVM#3355
Deeper DoS resistance: verification-time type checking is now memoized, message frames are capped per connection and message type, and each IP is subject to a connection limit.
Faster, more observable nodes: reduced serialization and lock contention on hot paths, plus new metrics covering RocksDB internals, event-encoding overhead, and validator participation scores.

Read on for the details.

Consensus upgrade: introducing V20

Aleo Stack v4.10.0 introduces the V20 consensus version. As with previous upgrades, the new rules ship in this release and activate at a scheduled block height on each network.

V20 brings two refinements to deployment and execution verification:

Root-call type checks: the type of every register in the root call is now checked precisely, closing a gap where translated types were tracked too loosely. snarkVM#3319
Plaintext type size bounds: every PlaintextType declared in a deployed program is now bounded in size during deployment verification, so that declared types always align with what the network can process. snarkVM#3355

V20 is also the activation point for the new validator handshake, described below.

For reference, the V19 upgrade shipped in v4.9.x is now live on both networks. V19 replaced the dynamic, density-based deployment limits with static per-transaction limits (MAX_DEPLOYMENT_{VARIABLES, CONSTRAINTS}_V2 = 1 << 22), allowing for more predictable and expressive smart contract deployments.

ATTENTION: Validators and clients that do not upgrade in time will be at risk of forking. V20 activates at height 22,175,000 on mainnet (estimated Tue 2026-09-22 ~07:40 UTC) and is already live on testnet since height 19,374,000.

Encrypted validator handshake

Validator-to-validator connections are now established with an asymmetrical Noise-XX handshake, providing an encrypted and mutually authenticated channel from the very first byte. The new handshake also hardens the underlying socket and enforces tighter limits on handshake message sizes. snarkOS#4354

The migration happens in two phases and requires no operator action beyond the standard upgrade:

At V20, upgraded validators automatically begin using the Noise-XX handshake with each other, while still accepting the legacy handshake from peers that have not yet upgraded.
At V21, the legacy handshake is no longer accepted.

There are no new keys to provision and no configuration, port, or firewall changes — the handshake authenticates with the validator's existing account key over the same TCP connection. Simply upgrade to v4.10.0 before the V20 activation height, as with any consensus upgrade. One note for advanced setups: infrastructure that inspects validator-to-validator traffic in transit (DPI firewalls or protocol-aware proxies) should expect the handshake to become encrypted at V20.

Hardening the network layer

This release includes a concerted effort to make nodes more resilient against malformed and malicious traffic:

Each connection's frame length is now capped at the maximum size of its allowed message types, and excluded message types are rejected outright. snarkOS#4419
The transaction size cap now accounts for the frame envelope, and Ping messages are size-capped. snarkOS#4416, snarkOS#4417
BFT transmission payloads with trailing bytes are rejected. snarkOS#4344
A per-IP connection limit protects nodes from connection exhaustion. snarkOS#4385
Peers that stop accepting writes are disconnected, and handshakes without a listener address are aborted. snarkOS#4381, snarkOS#4352
Inbound rate-limit cache entries are pruned to bound memory growth. snarkOS#4331

On the snarkVM side, verification is hardened against pathological inputs:

Recursive type checking is now memoized, eliminating an exponential-time path when verifying deeply nested types. snarkVM#3357, snarkVM#3372
Oversized strings fail parsing early. snarkVM#3352
Eager Vec<T> deserialization pre-allocation is capped. snarkVM#3391
Non-canonical encodings of the point at infinity are rejected during curve point deserialization, eliminating byte-level malleability in compressed point encodings, in line with the BLS12-381 serialization spec. snarkVM#3397

A note for developers

There are no new language or API features in this release, but a few changes are worth knowing about:

Signature::sign now rejects request-like messages. snarkVM#3387 Messages whose second field element equals the Poseidon hash of the first — the shape of a transaction request signature — are refused, so a signed "message" can never double as a valid transaction request. This is a client-side signing guard only; signature verification is unchanged. If your application signs raw messages, ensure it handles this rejection gracefully.
Functions with Scalar outputs now synthesize correctly. snarkVM#3258 A circuit-synthesis bug affecting functions with Scalar outputs has been fixed, unifying type matching between the circuit and console environments.
V20 tightens deployment verification. Programs that rely on imprecise root-call typing or declare unboundedly large plaintext types will be rejected once V20 activates.

More improvements for node operators

Consolidated metrics feature: the telemetry build feature has been folded into metrics. If you build snarkOS with --features telemetry, switch to --features metrics; the GET /{network}/validators/participation endpoint now lives behind metrics as well. snarkOS#4406
RocksDB internal metrics are now exported and polled from a dedicated background task. snarkVM#3296, snarkOS#4377
Telemetry reliability: participation-score telemetry has been reworked into a single-owner worker, removing shared locks and over-reporting, and now exports the vintage of published scores. snarkOS#4391
Equivocation visibility: nodes now always log when a peer has equivocated. snarkOS#4371
Dependency patches for mainnet: rustls is upgraded past RUSTSEC-2026-0285, and the yanked der 0.8.0 and wnaf 0.14.0 releases are replaced by their point releases.

BFT robustness

A series of fixes closes subtle edge cases in the consensus machinery:

Certificate references can no longer be lost in the persistent BFT storage, and the cache stays consistent on database write errors. snarkOS#4367
Certificate responses are validated before pending requests are cleared. snarkOS#4368
The signed-proposal cache can never move backwards, and the proposed batch is cleared under a single lock. snarkOS#4369, snarkOS#4370
Worker capacity limits are enforced at transmission insertion, closing a check/insert race. snarkOS#4399

Performance

Recovered signer addresses are cached on batch certificates, avoiding repeated signature recovery. snarkVM#3364
Broadcast events are serialized once instead of once per peer, event frames are written in place, and outbound payloads are serialized off the writer task. snarkOS#4382, snarkOS#4375
Block tree (de)serialization is faster, and the Merkle tree read lock is released as quickly as possible when dumping the tree cache. snarkVM#3349, snarkVM#3369

Closing notes

Aleo Stack v4.10.0 will be available on the snarkOS and snarkVM release pages, or you can build from source today. Validators and clients should upgrade ahead of the V20 activation heights.

Please report any issues you might come across!

Contributors

Thank you to everyone who contributed to this release: Antonio95, awatts73, cbeck88, eranrund, ljedrz, sethryanrollins, thep2p, and vicsn.