v0.2.9.1-testnet

[0.2.9.1-testnet] - 2026-10-25

Execution upgrade. Consensus-breaking from block #760 (consensus_breaking: true, mandatory_by_height: 760). The public testnet passed block #760 on 25 Oct 2026 under the new rules; nodes on v0.2.8.2 or older stopped following the chain at block #760 and must upgrade.

The automatic upgrade timer never installs consensus-breaking releases, so this one has to be run by hand once:

sudo vera-join --upgrade --yes-consensus-upgrade

This release includes v0.2.9 (execution rules v2) and a faster mempool admission. Both testnet validators run this exact binary.

Execution rules v2 (from block #760)

• Fee credits per block. The stability-pool and burn shares of each transaction fee (15% + 15%) are summed during the block and credited once, after its last transaction. Both system addresses share a long key prefix in the state tree, so crediting them after every transaction rehashed about 240 tree levels each time. The proposer share (70%) is still credited after every transaction. Balances, the fee split and total supply are unchanged: a block produces the same state root under both rules. Inside a block, the stability-pool and burn balances read as they were before the block.
• Receipts without a per-transaction state root. The state root is committed once per block, in the block header. The state_root field of a receipt is zero from block #760.
• Receipt hash v2. It is domain-separated and now commits to the event logs (the previous hash left them out). receipts_root uses it from block #760.
• JSON-RPC responses do not change: eth_getTransactionReceipt keeps returning status, gasUsed, cumulativeGasUsed and logs. Wallets and libraries need no change.

Faster mempool admission

• Before admitting a transaction, a node simulates it. The simulation now skips the stability-pool and burn fee credits, which only matter in a block. Admission cost per transaction roughly halves. Local policy only: block execution and consensus are unchanged.

Measured

• Block execution on one CPU core, block of 2,550 transfers: about 420 ms before, about 60 ms after.

• Mempool admission on one CPU core: about 260 µs before, 110–160 µs after, per transaction.

• Public testnet, sustained load (30 s at a fixed rate, half of it through the public RPC, plain transfers, 2 validators, one of them on a 1-vCPU VPS):

  Offered rate	Sustained	Included	Median latency
  2,000 tx/s	2,028 TPS	60,000 of 60,000	~0.67 s
  2,500 tx/s	2,486 TPS	75,000 of 75,000	~0.76 s
  3,000 tx/s	2,941 TPS	90,000 of 90,000	~0.81 s

  At 3,500 tx/s the latency kept growing: the network was saturated.

Verified

• Node test suite green (101 tests), including new tests: a block executed under both rules reaches the same state root and balances; a node with a different activation height rejects the block; the rules switch exactly at the activation height; the new receipt hash covers the logs.
• Replay of the public testnet history (blocks #1–#734, 260,323 transactions): every block hash and state root matches.
• Devnet of 3 validators with 150–250 ms simulated latency and repeated kill -9, crossing the activation height: 0 forks, 100% of transactions included, receipts served over JSON-RPC.
• Activation rehearsal with one validator still on v0.2.8.2: it rejects the first block under the new rules and stops following the chain, with no fork; the upgraded validators continue.
• Public testnet activation at block #760: both validators produced identical block hashes across the switch.

Other

• Wording: the eth_sendTransaction error now reads "This node is non-custodial and holds no user keys."

Release Artifacts

Signed offline with the official VERA Core release key:

• Fingerprint: 37F3 9BD8 9ADE E9EE E554 9C38 8974 19EF F806 BE51
• Key Identity: Vera Core <dev@verachain.cloud>

v0.2.8.2-testnet

[0.2.8.2-testnet] - 2026-10-25

Patch release on top of v0.2.8.1. Not consensus-breaking (consensus_breaking: false); the automatic upgrade timer installs it, or run:

sudo vera-join --upgrade

Fixed

• Reported version. web3_clientVersion, the vera_node start-up banner and vera_node --help reported a placeholder version (v1.0.0). They now report the release version (VERA-SmartChain/v0.2.8.2-testnet), taken from one constant shared with vera_cli.

No other change: block production, consensus, state and RPC behaviour are the same as in v0.2.8.1.

Release Artifacts

Signed with the official VERA Core release key:

• Fingerprint: 37F3 9BD8 9ADE E9EE E554 9C38 8974 19EF F806 BE51
• Key Identity: Vera Core <dev@verachain.cloud>

v0.2.8.1-testnet

[0.2.8.1-testnet] - 2026-10-21

Patch release on top of v0.2.8. Not consensus-breaking (consensus_breaking: false); the automatic upgrade timer installs it, or run:

sudo vera-join --upgrade

Fixed

• Idle-network latency. In v0.2.8 every proposal went out in compact form, but a small block's transactions usually reach the proposer just before it builds the block. Those transactions are gossiped on the normal queue, behind the priority proposal, so the other validator often did not have them yet and had to ask for the full proposal, costing an extra round trip. Measured on the public testnet: median time to finality 671 ms with v0.2.8, against 584 ms with v0.2.7.
• The fix: proposals with fewer than 256 transactions are now sent whole, as in v0.2.7. Larger proposals stay compact, which is where the bandwidth saving is (1–3 MB blocks).

Measured on the public testnet (same setup as v0.2.8)

	v0.2.7	v0.2.8	v0.2.8.1
Median time to finality, idle (20 transfers)	584 ms	671 ms	554 ms (min 172 ms)
12,800 transfers	rejected at 5,000 pending	869–1,092 TPS	895–1,030 TPS (median 984), all included
6,400 transfers	~700 TPS	721–892 TPS	916 TPS

All other v0.2.8 changes are unchanged: see the v0.2.8 notes.

Verified

• Test suite green; the compact-proposal test now also covers the 256-transaction threshold.
• Devnet with random pauses and repeated kill -9, mixing v0.2.8.1 with the published v0.2.7: 0 forks, 100% of transactions included.
• Running on both testnet validators since 21 Oct 2026 ~19:36 UTC.

Release Artifacts

Signed offline with the official VERA Core release key:

• Fingerprint: 37F3 9BD8 9ADE E9EE E554 9C38 8974 19EF F806 BE51
• Key Identity: Vera Core <dev@verachain.cloud>

v0.2.8-testnet

[0.2.8-testnet] - 2026-10-21

Throughput release. Not consensus-breaking (consensus_breaking: false): blocks, hashes and state roots are identical to v0.2.7, and v0.2.7 and v0.2.8 validators run side by side. The automatic upgrade timer installs it, or run:

sudo vera-join --upgrade

Every change below was found by measuring the public testnet under load, fixed, and measured again there.

Compact block propagation

• Compact proposals. Between v0.2.8 nodes, a Tendermint proposal carries the block header, the commit certificates and the transaction hashes instead of the full transactions and receipts. The receiver rebuilds the block from its own mempool, checks it against the header's tx_root, and computes the receipts when it executes the block. A 3 MB proposal becomes about 200 KB.
• Missing transactions. If the receiver lacks some of the transactions, it asks the proposer for those only, or for the full proposal when most of the block is missing.
• No redundant block broadcast. v0.2.8 nodes no longer send each other the whole block again after every commit. Validators decide the block through consensus, and a node that falls behind catches up through sync.
• Compatibility. These messages are only exchanged with peers that advertise the new FEATURE_COMPACT_BLOCKS capability. Older peers keep receiving full proposals and block commits.

Consensus never waits behind transactions

• Priority queue. Proposals and votes have their own queue on every connection and are sent before transaction gossip.
• Separate transaction queue. Transactions gossiped by peers have their own queue and are admitted in batches, with signatures verified in parallel.
• Before: under load, a validator could wait 1 to 1.5 s for a vote stuck behind thousands of transactions.

Block building and validation without holding the node lock

• Off-lock execution. A proposal is built, or a received one re-executed, on an O(1) copy of the state on a separate thread. The node lock is only taken to store the result.
• Effect: RPC transaction submissions no longer stall while a block executes. A batch of 100 transactions under load went from 720–877 ms to typically 100–350 ms (up to about 850 ms on the busier server).
• Batch submissions: signatures in JSON-RPC batches are verified in parallel before admission.

Mempool

• Cheap prune after each block. After each block the mempool drops used nonces without re-executing anything (160–525 ms → under 1 ms per block).
• Full prune off the lock. The full prune, which re-executes pending transactions, runs in the background on a copy of the state. It drops a transaction only if its sender's account is unchanged since the copy.
• Capacity: 5,000 → 20,000 pending transactions.

Fast start-up

• Persisted index. The transaction index is persisted in blocks/tx_index.log, and the latest-transactions list is built without re-reading the whole chain.
• Measured: a copy of a testnet validator's data (497 blocks) started in 30.8 s before, in 1.4 s on the first start (one-time index migration), and in 0.25 s after.

Timing logs

• Each height logs where its time went (⏱️ [TM]): build, proposal received, validation, precommit, decision and apply.
• Large blocks also log their apply stages (⏱️ [apply]), and block-sized network frames their encode and decode times.

Measured on the public testnet

Two validators in different data centers (one with 1 vCPU, about 118 ms round trip between them), signed transfers sent in JSON-RPC batches to both RPC endpoints, counted when final:

Batch	v0.2.7	v0.2.8
6,400 transfers	~700 TPS	721–892 TPS
12,800 transfers	rejected at 5,000 pending	869–1,092 TPS (median 1,055), all included

Median time to finality of a single transfer on an idle network: about 0.3–0.6 s.

Verified

• Test suite green, including new tests for compact proposals, the persisted transaction index (intact, missing and torn file), and both mempool prunes.
• Devnets with random pauses and repeated kill -9, mixing v0.2.8 with the published v0.2.7 and with each intermediate build: 0 forks, 100% of transactions included.
• Each change was deployed to both testnet validators one node at a time and measured before the next.

Upgrade and rollback

• On the first start, the transaction index is built once from the stored blocks; this takes seconds.
• Rolling back to v0.2.7 needs no conversion. The index file is simply ignored.

Release Artifacts

Signed offline with the official VERA Core release key:

• Fingerprint: 37F3 9BD8 9ADE E9EE E554 9C38 8974 19EF F806 BE51
• Key Identity: Vera Core <dev@verachain.cloud>

v0.2.7-testnet

[0.2.7-testnet] - 2026-10-21

Performance release. Not consensus-breaking (consensus_breaking: false): blocks, hashes and state roots are identical to v0.2.6, and v0.2.6 and v0.2.7 validators run side by side. The automatic upgrade timer installs it, or run:

sudo vera-join --upgrade

A validator that is still on v0.2.5 (stopped at block #151) also upgrades directly to this version. If it was jailed for downtime, unjail it first:

sudo VERA_RPC_URL=https://testnet-rpc.verachain.cloud vera_cli unjail --key-file /etc/vera/validator_key.hex
sudo vera-join --upgrade --yes-consensus-upgrade

Faster block pipeline

• Each block is executed once. The result computed while building or validating a proposal is reused when the block is applied, instead of executing the block again.
• Signature cache and parallel verification. A transaction signature is checked once, when it enters the mempool, and remembered. Signatures not yet seen are verified in parallel across the available cores.
• O(1) mempool admission. Admission no longer scans the whole mempool, and the mempool is persisted in the background instead of on every transaction.
• Persistent state tree. The state tree (CSMT) is copy-on-write, so building and validating a block no longer clones the whole state.
• Incremental state on disk. Instead of rewriting the full state on every block, the node appends a checksummed per-block delta (state/state_deltas.log, written before the block) and writes a full snapshot every 100 blocks. A torn record at the end of the log, from a crash in the middle of a write, is ignored on restart.
• Concurrent RPC reads. Read-only RPC calls share a read lock and no longer wait for each other, and EVM address lookups use an index instead of scanning the state.
• Mempool re-gossip. Pending transactions are re-sent to peers when they connect and periodically, so a transaction is not lost when its first broadcast misses a peer.

Elastic hardware profile

The node detects at start-up what the machine (or its container / systemd slice) gives it: CPU threads (honouring affinity and cgroup quotas), memory and SIMD level. It sizes its parallel work and caches from that, so the same binary fits a 1-vCPU VPS and a 32-core server. The profile is printed in the start-up log. Set VERA_THREADS to override the thread count.

Measured

• Mempool admission with 100,000 accounts in the state: from about 10 to about 3,600 transactions per second.
• Applying a block of 1,500 transfers with 100,000 accounts in the state: from 0.47 s to 0.046 s.
• 3-validator devnet with simulated WAN latency (4-core VPS, all three validators on the same machine): up to about 530 transactions per second sustained, from about 10–20 with v0.2.6.
• Public testnet after the upgrade: median time from submission to a finalized block about 0.5 s.

Verified

• Full test suite green (93 tests), including a golden test that pins the state root of a fixed state, so the new tree computes exactly the same roots as v0.2.6.
• Devnets with random pauses and repeated kill -9, and with v0.2.6 and v0.2.7 validators mixed: 0 forks, 100% of transactions included.
• A copy of a production validator's data opened by v0.2.7 at the same height and with the same state root.

Upgrade and rollback

• Existing data is converted automatically on first start.
• vera-join --upgrade rolls back to the previous binary when the post-upgrade health check fails. Because releases before v0.2.7 only read the full state snapshot, the rollback now first folds the delta log back into the snapshot (it needs python3, and keeps a copy of the state folder as state.pre-rollback.<time>).
• A jailed validator no longer triggers a rollback. Jailing is not caused by the new binary, so the upgrade reports it with the unjail command instead.

Release Artifacts

Signed offline with the official VERA Core release key:

• Fingerprint: 37F3 9BD8 9ADE E9EE E554 9C38 8974 19EF F806 BE51
• Key Identity: Vera Core <dev@verachain.cloud>

v0.2.6-testnet

[0.2.6-testnet] - 2026-10-21

Consensus upgrade. Consensus-breaking at block #152 (consensus_breaking: true, mandatory_by_height: 152). Up to block #151 this version follows the current rules, side by side with v0.2.5. From block #152 on, blocks are decided by the new Tendermint engine, and v0.2.5 nodes stop following the chain at the first block decided after round 0.

Every validator must upgrade before block #152. The automatic upgrade timer never installs consensus-breaking releases, so this one has to be run by hand once:

sudo vera-join --upgrade --yes-consensus-upgrade

Tendermint consensus (from block #152)

• A full implementation of Tendermint (Algorithm 1 of Buchman, Kwon & Milosevic, "The latest gossip on BFT consensus", arXiv:1807.04938). It has two voting phases (prevote, precommit), locks and proof-of-lock re-proposals, rounds with growing timeouts, and round skipping. Each rule in the code cites the line of the paper it implements.
• Safety: two different blocks can never be committed at the same height while the validators that equivocate hold less voting power than the overlap of two quorums. A validator that is late, paused or restarted can no longer cause a fork.
• Liveness: if a round fails (an offline proposer, lost votes, split votes), the network moves to the next round with a new proposer and recovers by itself. The v0.2.4.3 guard could stall in that case.
• Crash safety: every consensus input is written to a write-ahead log (<data-dir>/tm_wal/), and every signature is fsynced before it is sent. A restarted validator resumes the height with its locks and never signs two different messages for the same height, round and step.
• Idle chain: a height starts only when there are transactions or consensus messages for it, so an idle network sends no consensus traffic.
• Quorum: unchanged on-chain rule (supermajority_threshold: at least 2/3 of the active stake, 2 of 3 validators today).
• Blocks now record the round of their commit certificate (commit_round, last_commit_round). These fields are outside the block hash, and blocks before #152 keep round 0.
• New P2P messages (TmProposal, TmVote) are only sent to peers that advertise them in the handshake, and only messages signed by active validators are relayed.

Verified

• Full test suite green (90 tests).
• Randomized network simulation of the engine: 20,000+ runs with 3 to 7 validators, up to 2 Byzantine validators (equivocating proposals and votes, old-round re-proposals, future-round votes), 60% message loss, unequal stake, and a validator asleep for 44 s. 0 safety violations, and every run terminated after the network stabilized. Deliberately injected bugs (no lock, ignored locks, simple-majority quorum) are caught.
• Devnets of 3 and 4 validators with 150–250 ms simulated WAN latency, random pauses and repeated kill -9: 0 forks, 100% of transactions included, write-ahead log recovery exercised.
• Activation rehearsal at block #152 with one validator still on v0.2.5, then upgraded.

Upgrade

sudo vera-join --upgrade --yes-consensus-upgrade

Release Artifacts

Signed offline with the official VERA Core release key:

• Fingerprint: 37F3 9BD8 9ADE E9EE E554 9C38 8974 19EF F806 BE51
• Key Identity: Vera Core <dev@verachain.cloud>

v0.2.5-testnet

[0.2.5-testnet] - 2026-10-21

Networking release. Not consensus-breaking (consensus_breaking: false): blocks, votes and state transitions are unchanged, and v0.2.4.x and v0.2.5 nodes run side by side. Includes the v0.2.4.3 equivocation guard.

Automatic validator mesh (peer discovery)

• A new validator needs one seed. Within seconds it connects directly to every other active validator, and the network keeps finalizing blocks when any single node (including the seed) goes down.
• Each validator announces its P2P address, signed with its validator key (PeerAnnounce). Nodes accept an announcement only if it comes from an active validator of the on-chain set, so the governance allowlist is the only authorization list. Tampered, foreign-chain, stale (> 1 h) or non-validator announcements are dropped.
• Nodes learn their own public IP from their peers (AddrHint), so no configuration is needed. Optional override: --external-addr <ip:port>.
• Backward compatible: the handshake advertises a capability bit, and the new messages are only sent to peers that understand them.
• A node that has its own address in its seed list now detects itself once and stops dialing it.
• Operators: the P2P port (default 26656/tcp) must accept inbound connections from any IP. This includes the firewall of your hosting provider, not only ufw.

Automatic upgrades (opt-in, asked once)

• vera-join.sh now asks once, after joining or upgrading: Enable automatic upgrades? [Y/n] (default yes). When enabled, the node checks for a new release once a day, verifies the GPG signature, installs it, and rolls back automatically if the health check fails. Consensus-breaking releases are never installed automatically.
• Nothing is enabled without an answer at an interactive terminal. A "no" is remembered. Change it any time with sudo vera-join --enable-auto-upgrade or --disable-auto-upgrade.

Verified

• Full test suite green (83 tests), including new peer-discovery tests: tamper detection, freshness window, old-handshake compatibility, and no discovery messages to old peers.
• 5-validator devnet with a single seed: full mesh in 40 s, the chain kept finalizing after the seed was stopped, 0 forks, 20/20 transactions included. Mixed v0.2.4.3 + v0.2.5: no disconnections.
• Running on both core validators since 2026-10-21.

Upgrade

sudo bash vera-join.sh --upgrade

Release Artifacts

Signed offline with the official VERA Core release key:

• Fingerprint: 37F3 9BD8 9ADE E9EE E554 9C38 8974 19EF F806 BE51
• Key Identity: Vera Core <dev@verachain.cloud>

v0.2.4.3-testnet

[0.2.4.3-testnet] - 2026-10-20

Safety patch. Not consensus-breaking (consensus_breaking: false): block, vote and wire formats are unchanged, and v0.2.4.2 and v0.2.4.3 nodes run side by side. Every validator operator should upgrade.

Safety

• Equivocation guard: a validator now signs at most one block per height. Before signing (as proposer or as voter), the node writes the block to <data-dir>/signed_heights/<height>.json and fsyncs it, so a crash or restart cannot lead to a second, different signature for the same height. With every honest validator signing once per height, two different blocks can never both reach 2/3 of the stake, so the chain cannot fork.
• If a height stalls because the votes split, each validator re-broadcasts the block it already signed every 2 s, until a validator that has not signed yet completes the 2/3.

Verified

• 3-validator devnet (mesh and star topologies, simulated 150–250 ms WAN latency, random node pauses, kill -9 restart): 0 forks, all nodes at the same height, 120/120 transactions included.
• Running on both core validators since 2026-10-20 (blocks #98 and #99 committed with identical hashes).
• vera_cli now reports 0.2.4.3-testnet; no functional change.

Upgrade

sudo bash vera-join.sh --upgrade

Release Artifacts

Signed offline with the official VERA Core release key:

• Fingerprint: 37F3 9BD8 9ADE E9EE E554 9C38 8974 19EF F806 BE51
• Key Identity: Vera Core <dev@verachain.cloud>

v0.2.4.2-testnet: Security Patch

[0.2.4.2-testnet] - 2026-10-19

Security patch. Not consensus-breaking (consensus_breaking: false): honest blocks are produced and validated identically by v0.2.4.1 and v0.2.4.2 nodes. Every node operator should upgrade.

Security

• Hardened validation of EVM (eth_sendRawTransaction) transactions: every field used during execution is now checked against the ECDSA-signed payload. Details will be published after the network has upgraded.

Verified

• Full test suite green, plus a new regression test (tests/test_evm_wrapper_binding.rs).
• The entire existing testnet history (3,702 transactions, 3,663 EVM) re-validates under the new rule.

Upgrade

sudo bash vera-join.sh --upgrade

Release Artifacts

Signed offline with the official VERA Core release key:

• Fingerprint: 37F3 9BD8 9ADE E9EE E554 9C38 8974 19EF F806 BE51
• Key Identity: Vera Core <dev@verachain.cloud>

v0.2.4.1-testnet: Security & Liveness Patch

[0.2.4.1-testnet] - 2026-10-18

Security / liveness patch. Not consensus-breaking (consensus_breaking: false): v0.2.4.1 nodes and v0.2.4 nodes produce and validate the same blocks. Upgrading is strongly recommended for every node, and required for new nodes to sync past block #50.

Fixed

• Sync stalled at block #50 for new nodes. A SyncResponse could bundle up to 50 blocks without a size limit; the batch #51–#100 exceeded the 4 MiB P2P frame limit and the connection dropped ("early eof"). Sync responses are now limited to 3 MiB measured on the real wire frame (always at least 1 block).
• Block proposals could exceed the 4 MiB P2P frame. Proposals are now limited by the complete BlockProposal frame (3.25 MiB, including receipts and signatures); the proposer trims transactions from the end until it fits.
• Unbounded EVM logs. The proposer no longer includes a transaction whose logs exceed 256 KiB (local proposer policy, not a validation rule).
• Oversized frames are never sent. The sender logs the message type and size instead of writing a frame the peer would reject.
• vera-join.sh --upgrade now reads four-part versions (0.2.4.1) correctly.

Added (local admission limits)

• raw_evm ≤ 128 KiB, program ≤ 128 KiB, serialized transaction ≤ 512 KiB, mempool ≤ 64 MiB.

Upgrade

sudo bash vera-join.sh --upgrade

Nodes stuck at #50: upgrade, then restart sync normally (validators: sudo bash vera-join.sh --activate if not active yet).

Release Artifacts

Signed offline with the official VERA Core release key:

• Fingerprint: 37F3 9BD8 9ADE E9EE E554 9C38 8974 19EF F806 BE51
• Key Identity: Vera Core <dev@verachain.cloud>

SHA-256 Checksums

3fd9f7e9fdefa78cc195b965cda8c50e47e5ec8fb3bd2fba986b8ada79fb2771  RELEASE.json
a75e73ed753f0a9a33e176786d2e1b3348a372f6d0f2a44b452af2ba1802da43  install.sh
988a0dc3a91e01b34670f0b74bdbc603b39497d68a07192f7eaecbdc53c26b7c  testnet-genesis.json
a436e0b7b3c206a067a75c32f6b2b07e9fbcfc0db0d1836a7dce887211d71819  vera-join.sh
cbb752efa588ed15385313af96d38df49d0524b4b7893bce3744388fdaa72807  vera-node.service
7f205fbf8f11cc5d45687b6e3c106de74ee478fba715b85becf962ff9348e127  vera-release.pub
8ecff672ec526a8d96b3ca9890a7dd67e357ee462a508029d7b87c49e3d42d0d  vera-validator.service
72d49356a693cc69d3a5fad9e1bb2ada34fe263a9bcfcbbef6e053fffe59cb0b  vera_cli
f7c5e6b2a2fc823bda7ff7cafa73aea0178319026cf7ce6d12ecc39c30d1bab2  vera_node