SVM

The SVM runtime executes Solana programs (BPF bytecode) on Tenzro Network 1, 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.
• Cross-VM program. A native tenzro_cross_vm program moves value between SVM accounts and EVM or DAML accounts in the same block.
• 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.

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

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

Dispatch an instruction

Send an SVM instruction with tenzro_svmDispatch. It is an owner method: the caller authenticates as the account's owner, and the instruction runs with that account as its signer. Parameters:

{
  "jsonrpc": "2.0",
  "id": 1,
  "method": "tenzro_svmDispatch",
  "params": {
    "program_id": "0x<32-byte program id>",
    "instruction_data": "0x<instruction bytes>",
    "accounts": ["0x<account>", "0x<account>"]
  }
}

The response includes the transaction hash, the program logs, the compute units consumed and the number of state changes.

For SPL Token calls, instruction_data uses an account-prefix format: [n_accounts: u8] [account_0: 32 bytes] ... [spl_data]. Account order follows SPL Token: Transfer takes [source, destination, authority] and GetBalance takes [token_account]. The node checks that the SPL authority is the account that signed the outer transaction.

Moving TNZO to or from the SVM

Because the balance is shared, moving TNZO to a Solana-style account is a single transaction:

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

The JSON-RPC equivalent is tenzro_crossVmTransfer, also an owner method.

Smart-account policies apply here too

Accounts that install smart account policies (session keys, spending limits, recovery guardians) are held to the same policies when they act through the SVM. A session key allowed to call only certain programs cannot call others, whichever runtime the call arrives through.

RPC compatibility

Network 1 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.xyz. Use:

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

Related

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