Introducing Viri: a production-grade 3-layer modular blockchain built entirely in Go, with no external layer dependencies.
The blockchain industry has a dirty secret.
Most "modular" blockchains aren't really modular at all — they're fragmented. Celestia handles data availability but outsources execution. Arbitrum handles execution but depends on Ethereum for security. Cosmos builds app chains but relies on external bridges for interoperability.
Every seam between these layers is a trust assumption. Every bridge is an attack surface. Every external dependency is a point of failure.
We asked a simple question: what if one blockchain owned all three layers natively?
That question became Viri.
What Is Viri?
Viri is a production-grade, 3-layer modular blockchain built in Go — with zero external layer dependencies.
┌──────────────────────────────────────────────────────────────────┐
│ LAYER 3 — APPLICATION │
│ App Chains · IBC-like Interop · REST API · Governance DAO │
│ Cross-chain Bridge · Intent Solver Network · Go SDK │
├──────────────────────────────────────────────────────────────────┤
│ LAYER 2 — EXECUTION │
│ EVM + WASM VM · Native Account Abstraction · ZK Privacy Pool │
│ MEV Resistance · EIP-1559 Gas Oracle · Rollup Framework │
├──────────────────────────────────────────────────────────────────┤
│ LAYER 1 — CORE │
│ HotStuff BFT Consensus · Delegated PoS · P2P Networking │
│ Merkle-Patricia Trie · State Sync · Encrypted Keystore │
└──────────────────────────────────────────────────────────────────┘
No bridges between layers. No external trust. One stack, full control.
The Problem With Modern Blockchains
Before we get into what Viri does, let's talk about what's broken.
The Fragmentation Problem
When you use an L2 on Ethereum, your transaction touches multiple independent systems — the L2 sequencer, the L1 settlement contract, possibly a bridge, a data availability layer. Each of these is a separate team, a separate codebase, a separate point of failure.
The infamous Ronin Bridge hack ($625M) happened at exactly one of these seams. The Wormhole exploit ($320M) — another seam. Most major hacks in crypto history happened at layer boundaries.
The Developer Experience Problem
Building on a multi-layer stack today means learning multiple SDKs, dealing with different finality assumptions per layer, and debugging issues that span three independent codebases. It's exhausting.
The Trust Problem
"Trustless" is the promise of blockchain. But when your L2 depends on a centralized sequencer, and your data availability depends on a separate committee, and your cross-chain bridge has a 5-of-9 multisig — how trustless is it really?
Viri's answer: own the whole stack.
What Makes Viri Different
1. No EOAs — Account Abstraction from Day One
On Ethereum, your wallet is an "externally owned account" — a simple key pair with no programmable logic. ERC-4337 tried to fix this, but it's bolted on, expensive, and complex.
On Viri, every wallet is a smart contract wallet from genesis. There are no EOAs at all.
This means:
Transaction validation logic is programmable at the protocol level
Session keys, social recovery, multisig — all native
Gas sponsorship built in (a project can pay gas for its users)
No ERC-4337 overhead
2. Pay Gas in Any Token
This is one of our favourite features.
On most blockchains, you must hold the native token to pay gas. New users constantly hit this wall — they have USDC but can't send it because they have no ETH for gas.
On Viri, you can pay transaction fees in any token you hold. USDC, a project's own token, anything. The fee handler converts to the native equivalent at execution time via the on-chain price oracle.
No forced native token purchase. No onboarding friction.
3. Dual VM — EVM and WASM
We didn't want developers to choose between ecosystems.
Viri runs both an EVM interpreter and a WASM runtime natively. Deploy your existing Solidity contracts unchanged and they work immediately. Or write WASM contracts for full memory control and better gas efficiency.
Both runtimes run natively. Developers choose.
4. Built-in ZK Privacy
Optional shielded transactions are built directly into the protocol — not a separate rollup, not a third-party mixer.
Viri uses a Groth16 prover (gnark) with Pedersen-commitment nullifiers. Deposits, transfers, and withdrawals through the shielded pool are verified by a ZK verifier running as an on-chain precompile.
Privacy is a first-class citizen.
5. MEV Resistance
MEV (Miner/Maximal Extractable Value) costs users hundreds of millions of dollars per year through front-running and sandwich attacks.
Viri's sequencer uses fair-ordering rules and TEE-based sequencing — removing the sequencer's ability to front-run or sandwich transactions before they're included in a block.
6. Runs on a Raspberry Pi
Stateless verification means nodes verify blocks without holding full state. A Viri node runs on 1GB RAM — including on a Raspberry Pi.
Verification cost does not scale with chain history. Anyone can run a node.
7. On-chain Governance DAO
No off-chain Snapshot votes. No multisig admin key holding upgrade power.
Proposals, token-weighted voting, quorum thresholds, and veto logic are all protocol-native. The chain governs itself.
The Technical Foundation
HotStuff BFT Consensus
Viri's consensus is built on HotStuff-2, the same BFT protocol family used by Meta's Diem/Libra and Aptos. It's a three-phase protocol (Prepare → PreCommit → Commit) with clean leader rotation and view-change logic.
Performance results from our testnet:
2,015 ops/sec at 100-validator supermajority
4,958 messages/sec · 130 blocks/sec throughput
All 4 validators in sync at height 207 in multi-node tests
Network partition + heal: all validators reconverge cleanly
TLA+ Formally Verified
We didn't just test our consensus — we formally verified it.
The HotStuff-2 protocol is specified in TLA+ and model-checked with TLC. We verified it against Byzantine validators, equivocation attacks, malicious leaders, and network partitions.
Results:
34M+ states explored, zero safety violations
Agreement, NoDoubleCommit, QuorumIntersection — all verified
Zero errors across all-honest and Byzantine configurations
This is the same level of rigour used in aerospace and financial systems.
44 Packages. Zero Test Failures.
ok internal/layer1/consensus 55 tests
ok internal/layer1/crypto 20 tests
ok internal/layer1/ledger 50 tests
ok internal/layer1/p2p 52 tests
ok internal/layer2/vm 11 tests
ok internal/layer2/zk 24 tests
ok internal/layer3/governance 6 tests
ok internal/layer3/bridge 12 tests
ok tests/integration 24 tests
ok tests/contracts 43 tests
ok tests/fuzz 10 fuzz harnesses
We also run Jepsen-style fault injection testing — network partitions, process crashes, clock skew — across a 4-validator testnet. Block consistency, height monotonicity, and chain growth all pass under active fault injection.
Testnet Is Live
You can connect to Viri right now.
RPC Endpointhttps://rpc.viri.me
Explorerhttps://testnet.viri.me
Faucethttps://faucet.viri.me
Chain ID2
Block Time1 second
Connect MetaMask or any EVM-compatible wallet to the RPC endpoint and start building immediately.
Roadmap
We're currently on testnet. Here's where we're going:
v0.2.0 — Browser wallet (Chrome extension, Manifest V3)
v0.3.0 — Public testnet with community validators + faucet
v0.4.0 — Native VIRI token + Genesis NFT collection
v0.5.0 — DEX deployment + gas-in-any-token live demo
v1.0.0 — Mainnet launch
Get Involved
Viri is open source and actively looking for contributors. We especially need help with:
Browser wallet (TypeScript / React)
Block explorer frontend
Documentation and tutorials
Additional EVM opcode coverage
GitHub: github.com/RockyOmvi/Viri
Website: viri.me
X (Twitter): @viri_blockchain
Instagram: @ViriBlockchain
Final Thought
Blockchain promised trustlessness. But somewhere along the way, "modular" became a euphemism for "we outsourced the hard parts."
Viri is a bet that owning the full stack — Layer 1, Layer 2, and Layer 3 — in a single codebase, formally verified, production tested, and designed for real users, is how you actually build a trustless system.
The testnet is live. The code is open. Come build with us.
Viri Blockchain · viri.me · @ViriBlockchain
Hi viriblockchain,
I tried to join the testnet from an Ubuntu 22.04 server and hit several blockers. I'd appreciate a direct answer on each — they look like documentation issues more than protocol issues, but right now they make it impossible to actually use the network.
1) Conflicting Chain IDs across the repo:
- README.md (Public Testnet table): Chain ID = 2
- docs/USER_GUIDE.md (section 1, Manual Configuration): Chain ID = 1987050601 (0x76697269)
- testnet/docker-compose.yml: VIRI_CHAIN_ID = 1337
I tried all three of them in MetaMask against
https://rpc.viri.me — none is accepted, MetaMask cannot validate the network on any of them. Which value is correct for the public testnet, and can you point the other docs to a single source of truth?
2) Public endpoints status.
https://rpc.viri.me,
https://faucet.viri.me and
https://testnet.viri.me are returning HTTP 503 (upstream connection failure) for me right now. I saw your note above about backend upgrades — is there an ETA, or a status channel users can subscribe to so we don't keep testing against a dead endpoint?
3) Block-time disagreement. README says 1 second. USER_GUIDE.md section 7 says ~500ms. Which is current?
4) License inconsistency inside README.md alone:
- Badge: MIT
- 'License' section: 'Non-Commercial Use Only'
- Repo OG metadata: BSL 1.1
Which actually applies?
5) Public testnet vs. local testnet. testnet/docker-compose.yml is plainly a local 4-validator setup (CHAIN_ID=1337) with no bootnode references pointing at the public network. There is no testnet/README.md in the repo. Roadmap item v0.3.0 ('Public testnet with community validators + faucet') is still open. Is there a supported way today to run a node that syncs against your public testnet (not the local docker one)? If yes, please publish bootnodes and a join procedure. If no, the README line 'Testnet Live' is easily misread as a community-validator network and could use a clarification.
6) Audit clarification. audit.md is authored in-repo, which is fine, but it is a self-audit. Given the 'production-grade' framing, are you planning a third-party review before v1.0.0?
7) Token / airdrop position. v0.4.0 ('Native VIRI token + Genesis NFT collection') is still open. Some users are starting to assume faucet activity will translate into a future airdrop. Could you state your position explicitly — yes / no / undecided / no comment? An explicit answer protects users and gives you a clear public stance to point at if anyone starts selling 'presale' slots using your branding.
I am not trying to dunk on the project — the architecture pitch is interesting and I'd like to actually test the L2 (ZK shielded pool, AA) and L3 (governance, bridge, intent) features. But right now I cannot get past step one. A short, blunt answer to each of the seven points above would be very useful.
Thanks.
