Multi-VM runtime

Tenzro Network 1 has one settlement ledger and three execution environments on top of it: the EVM for Ethereum-compatible contracts, the SVM for Solana programs, and DAML for multi-party workflows. They share one account model, one native TNZO balance and one block. There is no bridge between them, because there is nothing to bridge: each VM reads and writes the same state.

Why three runtimes

Different parts of the Machine Economy already speak different languages.

Every transaction names its target runtime. The runtime dispatches it to the matching executor, and native typed transactions skip the VMs entirely.

One native TNZO balance

TNZO has exactly one balance per account, held by the native ledger. Each VM gets a view of that balance in its own format:

• EVM: an ERC-20 pointer contract (wTNZO) with 18 decimals.
• SVM: an SPL token mint (wTNZO), shown with 9 decimals.
• DAML: a CIP-56 holding template, with DAML Decimal amounts.

A view is a handle, not a copy. When a contract on the EVM transfers wTNZO, the native balance moves; the SVM and DAML views of the same account change in the same block. Nothing is locked, minted or wrapped, so a balance cannot be spent twice through two VMs, and total supply stays fixed at 1,000,000,000 TNZO whichever VM you look from.

Read all views of one account at once:

curl -s https://rpc.tenzro.xyz \
  -H 'content-type: application/json' \
  -d '{"jsonrpc":"2.0","id":1,"method":"tenzro_getTokenBalance","params":[{"address":"0xYOUR_ADDRESS","token":"TNZO"}]}'

{
  "address": "0xYOUR_ADDRESS",
  "native":       { "balance_wei": "25000000000000000000", "decimals": 18 },
  "evm_wtnzo":    { "balance_wei": "25000000000000000000", "decimals": 18 },
  "svm_wtnzo":    { "balance_base_units": "25000000000", "decimals": 9 },
  "daml_holding": { "amount_wei": "25000000000000000000", "decimals": 18 }
}

The SVM view truncates from 18 to 9 decimals; it never rounds up. tenzro_listTokens and tenzro_getToken return the pointer address of TNZO in each VM, so you never hard-code them.

Moving value between VMs

Because the balance is shared, a cross-VM transfer is an ordinary transaction that debits one account and credits another in the same block. Use it when the recipient lives in a different VM, for example an EVM agent paying a Solana program's account:

tenzro token transfer \
  --from-vm evm --to-vm svm \
  --from 0xSENDER --to 0xRECIPIENT \
  --amount 10 \
  --rpc https://rpc.tenzro.xyz

From TypeScript:

import { TenzroClient } from "tenzro-sdk";

const client = new TenzroClient({ endpoint: "https://rpc.tenzro.xyz" });

const result = await client.token.crossVmTransfer({
  from_address: "0xSENDER",
  to_address: "0xRECIPIENT",
  amount: "10",
  from_vm: "evm",
  to_vm: "svm",
});

tenzro_crossVmTransfer moves money, so it is an owner method: the transaction must be signed by the paying account. Both sides of the transfer commit atomically in one block or not at all. Other tokens registered in the unified token registry use the same path; tenzro token list --vm evm|svm|daml|native shows what is available.

Parallel execution

Network 1 executes blocks with Block-STM. Transactions in a block run optimistically in parallel against multi-version state. Each transaction records what it read and wrote; if a later transaction read a value that an earlier one changed, it is re-executed with the correct value. The committed result is always identical to executing the block one transaction after another in block order, so contracts need no changes to benefit.

Parallelism matters most for the Machine Economy's traffic pattern: many small, independent payments and settlements from different agents and machines, which rarely touch the same state.

Deterministic block time

Every validator executes a block against the same block height and the same timestamp, both fixed when the block is finalised by Tenzro DAG Consensus. The EVM NUMBER and TIMESTAMP opcodes and SVM clock reads resolve to those values, never to a validator's local clock. The same block therefore always produces the same state root on every node, and time-based logic (deadlines, rental epochs, permit expiry) behaves the same everywhere.

Fees

All three runtimes charge gas in TNZO under one EIP-1559-style fee market. The base fee adjusts with demand; part of it is burned and part goes to the treasury, and a priority fee goes to block producers. Gas can also be paid in stablecoins; see Stablecoin payments. Use eth_gasPrice and eth_feeHistory to price transactions.

Tenzro precompiles

EVM contracts can call Tenzro precompiles inside ordinary transactions to verify TEE attestations, check STARK proofs and verify VRF output, with the result committed as part of the block. See EVM for the list.

Related

• EVM, SVM, DAML
• Token economics
• Finality certificates
• Bridges for value moving to and from other networks