Architecture
Estimated read time: 8 minutes
TL;DR
Valdium is a single-chain, account-model L1 in the Ethereum account-model family. The reference node is written in JavaScript (Node.js). Every component — consensus, contract execution, RPC — runs inside the same process. The chain exposes a native val_* JSON-RPC surface in the standard JSON-RPC 2.0 envelope, so adapting existing client libraries is a thin shim.
Overview
Valdium is a purpose-built Layer-1. It is not a fork of Ethereum, Cosmos, or any other chain. The reference node implementation is written entirely in JavaScript and runs under Node.js. This is a deliberate choice: smart contracts are also JavaScript, which means the execution environment for contracts is the same runtime that runs the node itself — a single coherent trust boundary.
The chain is a single canonical chain with no shards, no rollups, and no sidechains in v1. One chain, one state, one canonical history. Simplicity is a security property.
Node architecture
A Valdium node runs as a single Node.js process composed of several modules that communicate over internal event buses rather than network sockets:
- Consensus engine — Tendermint-style BFT. Drives the pre-vote / pre-commit round protocol and maintains the validator committee set.
- Mempool — A simple ordered queue of pending transactions. Transactions fan out over HTTP to configured peers.
- Block builder — The proposer pulls transactions from the mempool, validates each (signature, nonce, balance, gas), and assembles a candidate block.
- Contract runtime — A Hardened JavaScript (SES) Compartment that executes contract code in a frozen, capability-constrained sandbox. Deterministic across all supported platforms.
- State database — A key-value store (LevelDB) holding accounts, contract storage, and block headers. BLAKE3 state roots are computed after every block.
- RPC server — An HTTP server exposing the native
val_*JSON-RPC API plus Valdium-specific extensions. - P2P layer — HTTP-based peer gossip. Blocks and transactions propagate via push to configured peers; pull sync for catching up.
The four layers
It helps to think of the stack in four layers, each with a clearly bounded responsibility:
| Layer | What it does | Key tech |
|---|---|---|
| Cryptography | Signing, hashing, address derivation | ML-DSA-65, BLAKE3 |
| Consensus | Block production and finality | Tendermint BFT, ~100-validator committee |
| Execution | Transaction and contract execution | Hardened JS (SES), async message-passing |
| Interface | Client-facing APIs and tooling | val_* JSON-RPC, Valdium CLI, SDK |
Each layer has exactly one job and is not allowed to reach "up" into the layer above it. The cryptography layer knows nothing about consensus. The execution layer knows nothing about block production. This separation makes each component testable and auditable in isolation.
JSON-RPC compatibility
Valdium exposes a native JSON-RPC endpoint at /rpc. The core val_* methods mirror the standard read/write surface every chain exposes:
eth_getBalance,eth_getTransactionCounteth_sendRawTransaction,eth_getTransactionReceipteth_call,eth_estimateGaseth_getBlockByNumber,eth_getBlockByHasheth_getLogs,eth_subscribe(websocket)
The Valdium SDK (@valdium/sdk) wraps these methods with ergonomic helpers, and the JSON-RPC 2.0 envelope means a thin adapter exposes them to any generic RPC client. What is Valdium-specific: contracts are plain JavaScript (not Solidity or Rust), transaction signing uses Dilithium3 (not ECDSA or secp256k1), and hashing is BLAKE3 throughout.
Valdium-specific methods are namespaced under valdium_ and documented in the JSON-RPC reference.
Where to go next
- Post-Quantum Cryptography — the full Dilithium3 spec
- Consensus & Validators — how blocks are produced and finalised
- Smart Contracts — the JavaScript contract execution model