Tenzro documentation

Run Solana programs on Tenzro Network against the same accounts and the same native TNZO balance as EVM contracts.

The SVM runtime executes Solana programs (BPF bytecode) on Tenzro Network, alongside EVM contracts and DAML workflows on the same ledger. SVM programs see the same accounts and the same native TNZO balance as the other runtimes. See Multi-VM runtime for how the three fit together.

What runs

Programs. Deploy BPF programs built with the standard Solana tool chain (cargo build-sbf, Anchor). The program's account model maps onto the unified account store, so an SVM program and an EVM contract can serve the same user without a bridge.
SPL Token. Calls to the SPL Token program are served by a native adapter that reads and writes the unified balance layer directly. Transfer and balance reads work as in SPL Token; the administrative instructions (InitializeMint, InitializeAccount, Approve, Revoke, CloseAccount) are accepted for compatibility. Issuance and redemption of TNZO never happen through SPL MintTo or Burn: TNZO supply is fixed, and the SPL mint is only a view of it.
Fees. Compute is charged as gas in TNZO under the same fee market as the EVM.
Time. Clock reads return the finalised block's height and timestamp, so every validator computes the same result.

TNZO on the SVM

TNZO appears on the SVM as the wTNZO SPL mint. It is a view of the account's native balance, not a separate token: the EVM wTNZO ERC-20, the SVM wTNZO mint and the DAML holding all read one balance. The SPL view uses 9 decimals and truncates from the native 18; it never rounds up.

bash

tenzro token balance 0xYOUR_ADDRESS --token TNZO --rpc https://rpc.tenzro.com

tenzro_listTokens and tenzro_getToken return the TNZO addresses for each runtime, including the SVM mint registered at genesis.

Send a transaction

The node speaks the Solana JSON-RPC methods that wallets and SDKs use: getAccountInfo, getBalance, getLatestBlockhash, getFeeForMessage, getSignatureStatuses, simulateTransaction, sendTransaction and the rest of the read set. A transaction is a standard Solana wire transaction signed by the wallet's own Ed25519 key, so @solana/web3.js, @solana/kit and the Solana CLI work against https://rpc.tenzro.com unchanged:

import { Connection } from "@solana/web3.js";

const connection = new Connection("https://rpc.tenzro.com");
const { blockhash } = await connection.getLatestBlockhash();
// build and sign the transaction with the wallet, then:
const signature = await connection.sendRawTransaction(signedTx.serialize());

sendTransaction returns the transaction's first signature in base58. simulateTransaction runs it against a scratch copy of state and reports whether it would succeed and the compute it uses.

For SPL Token calls, account order follows SPL Token: Transfer takes [source, destination, authority]. The node checks that the SPL authority signed the transaction.

Moving TNZO to or from the SVM

Because the balance is shared, there is nothing to move: the SPL view of an account's TNZO is the same balance its EVM view shows. Paying a Solana-style account is an ordinary transfer to its address, from any runtime:

bash

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

Smart-account policies apply here too

An agent acting through the SVM is held to the same Terms as anywhere else: the Terms live in consensus state, whichever runtime the call arrives through. See Agents.

RPC compatibility

Tenzro Network exposes the SVM through the Tenzro namespace, not the Solana JSON-RPC wire protocol. Solana-shaped requests such as getSlot or getLatestBlockhash are not served by https://rpc.tenzro.com. Use:

Need	Method	Access
Balances in every runtime	`tenzro_getTokenBalance`	open
Token registry	`tenzro_listTokens`, `tenzro_getToken`	open

The Rust and TypeScript tenzro-sdk packages wrap these; for example client.token.getTokenBalance(address) in TypeScript.

Multi-VM runtime
EVM
Bridges for moving assets to and from Solana itself

SVM