Vera Protocol is a blockchain node written in Rust. Validators agree on blocks with Tendermint BFT consensus, so a committed block is final. The state is committed in a BLAKE3 sparse Merkle tree, so balances can be checked with proofs. Smart contracts run on an Ethereum-compatible virtual machine. This document describes what runs on the public testnet today, what was measured, and what is planned.
1. Overview
VERA is a Layer-1 blockchain in its public testnet phase. The node software is open source under the Apache-2.0 license and is published as GPG-signed releases. The testnet runs node version v0.2.9.1 with two active validators in different data centers; validator admission is permissioned (an allowlist) during this phase.
The design goal is a chain that is easy to check: blocks are final on commit, every validator re-executes every block before voting, and any account can be proven against the state root of a block. The node aims to run on modest hardware; one of the two testnet validators runs on a single virtual CPU.
Version 3.0 replaces version 2.0 of this document, which described targets (throughput, finality, validator economics, in-memory execution) that the software does not implement. In this version, every figure is either measured on the public testnet or read from the node source code. Planned mainnet parameters are marked as plans and can change.
2. Architecture
An implementation of the Tendermint algorithm (Buchman, Kwon, Milosevic, arXiv:1807.04938), active since block #152 (node v0.2.6). A block is committed when validators holding more than 2/3 of the stake precommit it, so it is final and is never reorganized.
The proposer of each round is chosen deterministically from a hash of the height and round, weighted by stake. Timeouts: propose 3 s + 1 s per round, prevote and precommit 1 s + 0.5 s per round. Blocks are produced only when the mempool holds transactions.
Each validator writes its consensus messages to a write-ahead log and syncs it to disk before signing, so a restart cannot make it sign two different blocks at the same height and round.
Every account is a leaf of a sparse Merkle tree hashed with BLAKE3 (the CSMT). Each block header commits to the state root. The RPC method vera_getProof returns a Merkle proof for an account, which can be checked against that root.
Contracts run on revm 43 with the Cancun rules, so Solidity contracts and tools such as MetaMask, Hardhat and ethers work. The block gas limit is 30,000,000 and the minimum gas price is 1 gwei.
Native accounts use Ed25519 keys and 32-byte addresses. EVM accounts use secp256k1 keys and 20-byte addresses, as in Ethereum. Both kinds live in the same state tree.
Proposals of 256 transactions or more are sent in compact form: transaction hashes instead of full transactions. Validators rebuild the block from their own mempool. A 3,000-transfer proposal shrank from about 3.2 MB to about 0.2 MB.
Before voting, every validator re-executes the proposed block and compares the state, transaction and receipt roots in its header. A block whose roots do not match gets no vote.
3. Measured Performance
Measured on the public testnet: two active validators in different data centers, one of them on 1 vCPU. Sustained load was measured on 25 October 2026 with node v0.2.9.1: signed transfers sent for 30 s at a fixed rate, half of them through the public RPC, counted from the first submission to the last block that carried them; median of three runs. Finality and batch throughput were measured on 21 October 2026 with node v0.2.8.1.
These results come from a small network. With more validators, spread over more regions, finality will take longer, because each round needs messages from validators holding 2/3 of the stake. The method and raw data are published with the release notes and on the benchmarks section of the home page.
4. Economics
The rules below are in the node source code and apply on the testnet now. Test VERA has no monetary value.
Plans, not implemented. The figures below come from TOKENOMICS.md in the repository and may change before a mainnet launch. There is no mainnet and no VERA token on sale.
The planned mainnet minimum stake is 10,000 VERA. The 70 / 15 / 15 fee split is expected to stay as implemented.
5. Security & Verification
The full node is on GitHub under Apache-2.0. Anyone can build it and compare the result with the published binaries.
Each release ships SHA256SUMS signed with the Vera Core release key (ed25519, fingerprint 37F3 9BD8 9ADE E9EE E554 9C38 8974 19EF F806 BE51). Anyone can verify the binaries before installing them.
A node reports the SHA-256 of the binary it runs. This is self-reported: it helps spot a wrong version, but it is not proof, since a modified node could report any value.
The official systemd unit runs the node as an unprivileged user with a read-only system, no capabilities, no writable-and-executable memory and a system-call filter.
The node sends no usage data. The command-line tool contacts the GitHub releases API to check for updates and the RPC endpoint it is pointed at (the public RPC by default).
Account state can be checked with vera_getProof against a block's state root, in your own code; a light-client verifier is on the roadmap.
6. Known Limitations
7. Roadmap
Progress is reported in the release notes.
8. Use Cases
Tokens, NFTs and DeFi contracts written in Solidity and deployed with standard tools. See the documentation for Hardhat and MetaMask setup.
The VERA Player asks the viewer's wallet for a 0.1 test VERA transaction before playing a video for 15 minutes. The check happens in the browser; the video file itself is not protected.
The faucet sends test VERA to any address, with a daily limit, so anyone can try transfers and contracts.
9. References