v4.12.0

chore(snarkos): update snarkVM version

testnet-v4.12.0

Testnet consensus version (V22) activation height: 20,415,000 (estimated Tue 2026-10-13 ~08:00 UTC, the evening of Mon 2026-10-12 PT).

Network: testnet. ConsensusVersion::V22 raises the maximum number of mappings in a program to 128 and lowers the testnet maximum number of certificates to 40. This release also carries everything merged to staging through snarkOS #4531 and snarkVM #3485.

Who needs to act

All testnet validators and node operators need to upgrade before the activation height.

Built against snarkVM testnet-v4.12.0 (532d8fdf7).

The Aleo maintainers are excited to announce Aleo Stack testnet-v4.12.0. This release introduces the V22 consensus version, continues the hardening and performance work from v4.10.0, and brings a large set of improvements for node operators: more resilient BFT participation, new REST range endpoints, better observability, and faster CPU proving.

Highlights

• Consensus V22: programs may declare up to 128 mappings, and the testnet certificate limit is lowered to 40.
• BFT resilience: validators no longer let peer-reported sync status silence them, proposals fan out to peers concurrently, and certificates propagate before local commit work.
• Deployment verification hardening: deterministic deployment checks, cyclic struct guards, and tighter wire-format parsing.
• Faster, more observable nodes: an 8% faster private transfer on CPU, committer keys that share the SRS, RocksDB secondary mode, and new metrics and REST routes.

Consensus upgrade: introducing V22

• Up to 128 mappings per program. The mapping limit becomes a versioned consensus value: 31 through V21, 128 from V22. Deployment verification enforces the active limit. (snarkVM#3428)
• Testnet certificate limit lowered to 40 at V22, matching mainnet’s committee bound. (snarkVM#3386, snarkVM#3484)
• Message version 33 accompanies V22; the latest message version now ignores consensus versions that have no scheduled height. (snarkOS#4511)

For node operators

BFT resilience

• Consensus participation no longer depends on peer-reported sync status. is_synced() was derived from peer locator messages, so a single peer claiming to be far ahead could silence a validator. Proposing, signing and certifying now rely on the node’s own view. (snarkOS#4461)
• Batch proposals fan out concurrently, and sends scoped to a round are cancelled when the round advances, so one rate-limited peer no longer delays delivery to the rest. (snarkOS#4487)
• Certificates are broadcast before waiting on local consensus, so local commit work does not hold up propagation. (snarkOS#4527)
• Batches that reference aborted transactions are no longer certified. (snarkOS#4412)
• Concurrent duplicate certificate inserts are ignored rather than treated as errors. (snarkOS#4479)
• Cached signer addresses on batch certificates are used instead of re-deriving them. (snarkOS#4434)
• Clients may fetch a single missing block at the tip, improving transaction and mapping visibility. (snarkOS#4529)
• The expired gateway challenge-response handshake has been removed; validators speak only the Noise handshake. (snarkOS#4506)

Hardening the wire format and network layer

• Trailing bytes inside length-delimited sub-objects, repeated entries in count-prefixed collections, and oversized preallocations from wire-declared counts are rejected. (snarkVM#3409, snarkVM#3410, snarkVM#3419)
• Non-canonical curve point encodings (Short Weierstrass y = 0 sign flag, Edwards x = 0) are rejected, and every serialized curve point is asserted to round-trip. (snarkVM#3422, snarkVM#3425, snarkVM#3405)
• MAX_PING_MESSAGE_SIZE is tightened from 16 MiB to 2 MiB, and Ping block locators are optional for clients and validators. (snarkOS#4426, snarkOS#4425)
• Remote parameter downloads and REST queries are bounded, with retries for lost requests. (snarkVM#3436, snarkVM#3435)
• A cached parameter file that fails its checksum is removed rather than reused. (snarkVM#3469)

Storage, history and observability

• RocksDB secondary mode: a store can be opened read-only alongside a running node. (snarkVM#3452)
• --history-json: snarkos start can write credits.aleo history as JSON while finalizing blocks (clients and validators only; not combinable with --history-compat-mode). (snarkVM#3485, snarkOS#4521)
• Metrics: a snarkos_consensus_version gauge, subdag/DAG-density metrics, p2p event and REST request counts by type, RocksDB compaction byte counters, standardized units and histogram buckets, and a fixed inbound-queue gauge. (snarkOS#4469, snarkOS#4453, snarkOS#4512, snarkVM#3482, snarkOS#4454, snarkOS#4436, snarkOS#4486)
• Local devnets provision the incident-response Grafana dashboard, and devnet.sh handles compose failures. (snarkOS#4473, snarkOS#4530)
• The dev_genesis_state_root feature is available for test networks. (snarkVM#3448, snarkOS#4476)
• Unused slipstream plugin support has been removed. (snarkVM#3442, snarkOS#4468)

For external developers

REST API

• New range routes: /blocks/hashes, /blocks/headers, /blocks/stateRoots and /blocks/transactions over a height range (up to 160 blocks), with allow_partial to clamp ranges to the tip. (snarkOS#4447, snarkOS#4455, snarkOS#4467, snarkOS#4510)
• Missing resources return 404, v1 errors are identifiable, and the rate limiter’s Retry-After header is forwarded on a 429. (snarkOS#4450, snarkOS#4472)
• Transaction verification on broadcast?check_transaction=true runs in a blocking task, and operators can cap REST verification concurrency at startup. (snarkOS#4530, snarkOS#4459)
• The request body limit matches the current maximum transaction size, block lookups no longer fill the block cache, and developer endpoints accept static queries. (snarkOS#4444, snarkOS#4485, snarkOS#4478)

Deployment verification hardening

• Deterministic deployment checks. A non-deterministic signer sampled during check_deployment could make nodes disagree; the remaining ambient RNG sources are now seeded. (snarkVM#3346, snarkVM#3365)
• Cyclic struct equivalence is rejected instead of overflowing the stack, guarding legacy cyclic graphs that reach type checking. (snarkVM#3447)
• The rand.chacha instruction is now costed. (snarkVM#3356)
• Beacon blocks apply a conservative spend limit, matching production environments. (snarkVM#3386)

Performance

• CPU proving is about 8% faster on a private transfer, from a set of algorithmic improvements to polynomial arithmetic. (snarkVM#3399)
• Committer keys share the SRS instead of copying the powers of β·G. (snarkVM#3474)
• Off-thread speculative reads no longer stall atomic_speculate, and the sequential VM worker is released after the final external clone. (snarkVM#3438, snarkVM#3444)
• Tokio pools are sized from measured demand, duplicate deserialization allocations are avoided, and a path hasher’s Merkle e...

v4.11.0

chore(snarkos): update snarkVM version

testnet-v4.11.0

Testnet consensus version (V21) activation height: 20,234,000 (estimated Tue 2026-10-06 ~16:25 UTC).

Network: testnet. This is the testnet counterpart of mainnet v4.11.0. It introduces VarunaVersion::V3, activated by ConsensusVersion::V21.

Who needs to act

All testnet validators and node operators need to upgrade before the activation height.

Built against snarkVM testnet-v4.11.0 (11010ba64).

v4.10.1

Network: mainnet. snarkOS-only point release, the mainnet counterpart of testnet-v4.10.1. No consensus change and no snarkVM change: this build uses snarkVM 4.10.0 from crates.io. Validators do not need to upgrade, and the v4.10.0 ConsensusVersion::V20 activation at height 22,175,000 is unaffected.

Who needs to act

Only operators who built snarkOS with --features history and serve the /history/ or /staking/rewards REST routes, typically RPC providers. That cargo feature is gone in this release, and cargo install --features history no longer builds. To keep serving those routes, start the node with --history-compat-mode.

If you don't serve those routes, nothing changes for you.

Why the history feature was removed

The feature answered historical mapping queries from tables the node maintained itself. Those tables never recorded deletions and mixed incompatible height encodings (snarkVM#3418, snarkVM#3408). The visible symptom: once an unbond is claimed, credits.aleo/unbonding kept reporting it as pending at every later height. Rather than patch the tables, this release removes them and serves the routes from a source that is correct in exactly that case.

--history-compat-mode snarkOS#4458

With the flag set, the node registers the same routes and returns the same response bodies as before, but answers them from the Provable historical staking API. That service stores a full snapshot of five credits.aleo staking mappings at every block since genesis, so a deleted key is simply absent at later heights.

snarkos start --client --history-compat-mode
snarkos start --client --history-compat-mode https://your-mirror.example.com

• With no URL, the node uses the instance for its own network: https://{network}.historical-staking.provable.com. Instances exist for mainnet and testnet; there is none for canary.
• A --dev network has no upstream and requires an explicit URL.
• The flag needs the REST server and cannot be combined with --norest.

What it serves:

Route	Behaviour
GET /program/{id}/mapping/{name}/{key}/history/{height}	Same body as before: the value as a plaintext string, or null if the key is absent at that height. Only credits.aleo and the mappings bonded, delegated, metadata, unbonding, withdraw. Anything else returns 404 naming what is supported.
GET /program/{id}/mapping/{name}/history/{height}?keys=…	Same, for several keys in one upstream request.
GET /staking/rewards/{address}/{height}	[validator, reward, new_stake], as the history-staking-rewards feature returned it. new_stake comes from the bonded snapshot at that height.
POST /program/{id}/view/{function}/{height}	Always 404 with an explanation. Staking snapshots are not enough state to evaluate a view function at a past height. The route is kept so older clients get an answer instead of a routing miss.

A height the upstream has no snapshot for returns 404. Snapshots are cached per height and fetched once per height even when many requests for that height arrive together, so an indexer fanning out across addresses costs one upstream request. Upstream calls are limited to 8 in flight, 20 seconds each, and 64 MiB per response.

The history-staking-rewards cargo feature still exists. Its own handler is registered only when compat mode is off.

Know before you rely on it

This is a stop-gap until a proper archival-node mode exists. A node on this flag depends on Provable's hosted historical API being up, and it serves five staking mappings of credits.aleo, not arbitrary program state. If you need historical values of other mappings, or view functions at past heights, this release does not provide them.

Also in this release

• rustls is upgraded past RUSTSEC-2026-0285, and the yanked wnaf 0.14.0 is replaced by 0.14.1.

testnet-v4.10.1

Network: testnet. snarkOS-only point release. No consensus change, no new activation height, and no snarkVM change: this build still uses snarkVM 4.10.0. Validators do not need to upgrade. A mainnet release with the same change will follow once it has been validated on testnet.

Who needs to act

Only operators who built snarkOS with --features history and serve the /history/ or /staking/rewards REST routes, typically RPC providers. That cargo feature is gone in this release, and cargo install --features history no longer builds. To keep serving those routes, start the node with --history-compat-mode.

If you don't serve those routes, nothing changes for you.

Why the history feature was removed

The feature answered historical mapping queries from tables the node maintained itself. Those tables never recorded deletions and mixed incompatible height encodings (snarkVM#3418, snarkVM#3408). The visible symptom: once an unbond is claimed, credits.aleo/unbonding kept reporting it as pending at every later height. Rather than patch the tables, this release removes them and serves the routes from a source that is correct in exactly that case.

--history-compat-mode snarkOS#4458

With the flag set, the node registers the same routes and returns the same response bodies as before, but answers them from the Provable historical staking API. That service stores a full snapshot of five credits.aleo staking mappings at every block since genesis, so a deleted key is simply absent at later heights.

snarkos start --client --history-compat-mode
snarkos start --client --history-compat-mode https://your-mirror.example.com

• With no URL, the node uses the instance for its own network: https://{network}.historical-staking.provable.com. Instances exist for mainnet and testnet; there is none for canary.
• A --dev network has no upstream and requires an explicit URL.
• The flag needs the REST server and cannot be combined with --norest.

What it serves:

Route	Behaviour
GET /program/{id}/mapping/{name}/{key}/history/{height}	Same body as before: the value as a plaintext string, or null if the key is absent at that height. Only credits.aleo and the mappings bonded, delegated, metadata, unbonding, withdraw. Anything else returns 404 naming what is supported.
GET /program/{id}/mapping/{name}/history/{height}?keys=…	Same, for several keys in one upstream request.
GET /staking/rewards/{address}/{height}	[validator, reward, new_stake], as the history-staking-rewards feature returned it. new_stake comes from the bonded snapshot at that height.
POST /program/{id}/view/{function}/{height}	Always 404 with an explanation. Staking snapshots are not enough state to evaluate a view function at a past height. The route is kept so older clients get an answer instead of a routing miss.

A height the upstream has no snapshot for returns 404. Snapshots are cached per height and fetched once per height even when many requests for that height arrive together, so an indexer fanning out across addresses costs one upstream request. Upstream calls are limited to 8 in flight, 20 seconds each, and 64 MiB per response.

The history-staking-rewards cargo feature still exists. Its own handler is registered only when compat mode is off.

Know before you rely on it

This is a stop-gap until a proper archival-node mode exists. A node on this flag depends on Provable's hosted historical API being up, and it serves five staking mappings of credits.aleo, not arbitrary program state. If you need historical values of other mappings, or view functions at past heights, this release does not provide them.

Also in this release

• rustls is upgraded past RUSTSEC-2026-0285, and the yanked wnaf 0.14.0 is replaced by 0.14.1.

v4.10.0

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:

1. 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.
2. 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](https://github.com/ProvableHQ/snarkOS/...

testnet-v4.10.0

Testnet consensus version (V20) activation height: 19,374,000

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. Please consult the release schedule and upgrade block heights [TBD — link] for the V20 activation heights on testnet and mainnet.

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:

1. 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.
2. 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 [TBD — pending merge into staging; remove this bullet if it misses the cut]

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. [TBD — confirm SDK guidance with the SDK team before publishing.]
• 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. [TBD — confirm with the Leo team that current compiler output is unaffected.]

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

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](https://github.com/Provable...

v4.9.1

Replaces the dynamic density-based smart contract deployment limits, by a static const MAX_DEPLOYMENT_{VARIABLES, CONSTRAINTS}_V2: u64 = 1 << 22 This will allow for more predictable and expressive smart contract deployments

Mainnet consensus version activation height: 21,342,000 predicted at current blocktimes to activate 8/24/2026

testnet-v4.9.1

Replaces the dynamic density-based smart contract deployment limits, by a static const MAX_DEPLOYMENT_{VARIABLES, CONSTRAINTS}_V2: u64 = 1 << 22 This will allow for more predictable and expressive smart contract deployments

Testnet consensus version activation height: 18,813,000, predicted at current blocktimes to activate 8/18/2026