The Tenzro ledger runs two virtual machines on one state, the EVM and the SVM, alongside native transactions. Block-STM executes transactions in parallel, and TNZO is native in every runtime. One ledger, several programming surfaces.
Why more than one runtime
Picking a single virtual machine leaves someone out. The EVM is where most smart-contract tooling and token standards live. The SVM brings Solana programs and their tooling. Both are in active use, so the ledger runs both.
Each transaction names its runtime, and the ledger dispatches it to the matching executor. Every runtime reads and writes the same state and settle under the same consensus, Tenzro DAG Consensus (TDC), our post-quantum consensus protocol.
One balance, several views
The naive approach is to mint a wrapped asset in every runtime and bridge between them. The ledger does not do that.
TNZO has one native balance. The EVM sees it through a token contract that reads and writes the native balance directly. The SVM sees it through an SPL Token adapter that maps SPL instructions onto the same balance. Two surfaces, one balance: no bridge risk between runtimes and no fragmented liquidity.
EVM
The EVM supports the standard precompiles, plus Tenzro precompiles that expose network primitives to contracts, such as TEE attestation checks, STARK proof verification and VRF verification. Tenzro precompiles run inside ordinary EVM transactions, so a contract can call them in the same call as any other logic. ERC-8004 registries hold agent identity, reputation and validation. See EVM.
SVM
Solana programs run on Tenzro with their tooling intact. The SPL Token program is mapped through the adapter, and deployed programs run natively in the executor. See SVM.
Parallel execution
Sequential execution does not scale. Block-STM runs transactions optimistically with multi-version concurrency control, detects conflicts, and re-executes only the transactions that conflict. If a block is dominated by conflicts, it falls back to sequential execution. Block time is deterministic, so every validator reaches the same result from the same inputs.
Fees
Fees follow an EIP-1559-style base fee that adjusts to demand. Part of each fee is burned and part goes to the treasury. TNZO has a fixed supply of 1,000,000,000, and validator rewards come from a finite genesis pool rather than new issuance. See Token economics.
