Skip to content
Tenzro
Documentation menu
Execution and interoperability

Multi-VM runtime

How Tenzro Network runs EVM, SVM and DAML on one ledger: one native TNZO balance, parallel execution and a deterministic block time.

Tenzro Network 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.

RuntimeUse it for
EVMSolidity contracts, account abstraction, the Ethereum tool chain (wallets, Foundry, Hardhat, viem, ethers). See EVM.
SVMSolana programs and SPL token mechanics. See SVM.
DAMLMulti-party agreements where each party sees only its own part of the workflow. See Canton and DAML.
NativeTyped transactions for transfers, staking, escrow, settlement and governance, which do not need a VM at all.

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:

bash
curl -s https://rpc.tenzro.com \
  -H 'content-type: application/json' \
  -d '{"jsonrpc":"2.0","id":1,"method":"tenzro_getTokenBalance","params":[{"address":"0xYOUR_ADDRESS","token":"TNZO"}]}'
json
{
  "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, there is no bridge between VMs and nothing to convert. A transfer debits one account and credits another in the same block, and the recipient sees the credit in every VM's view at once. An EVM agent paying a Solana program's account sends an ordinary transfer to that account's address:

bash
tenzro wallet send 0xRECIPIENT 10 --rpc https://rpc.tenzro.com

Other tokens registered in the token ledger move the same way, by token id:

bash
tenzro token transfer --token-id <TOKEN_ID> --to 0xRECIPIENT --amount 10000000 \
  --rpc https://rpc.tenzro.com

Both commands sign with the paying account's hardware key. tenzro token list --vm evm (or svm, daml, native) shows the tokens available and their address in each view.

Parallel execution

Tenzro Network 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.