SVM.

BPF programs execute via solana_rbpf with syscall stubs. Account model maps to the unified account store.

The SPL Token Program address is short-circuited to a native Rust adapter that reads and writes through the unified TNZO balance layer — no BPF round-trip. The four canonical instructions are dispatched directly: Transfer, MintTo, Burn, GetBalance (and the standard administrative no-ops: InitializeMint / InitializeAccount / Approve / Revoke / CloseAccount). MintTo and Burn are handled by the bridge layer in the pointer model (the SPL handler acknowledges; actual issuance/redemption happens via the cross-VM bridge). Decimal conversion is 9 SPL ↔ 18 native with truncation (no rounding).

Use tenzro_svmDispatch with program_id set to the SPL Token Program id (32-byte hex). The instruction calldata uses an account-prefix wire format: [n_accounts: u8] [account_0: 32B] … [account_(n-1): 32B] [spl_data: variable]. Per-instruction account conventions follow SPL Token v0.3+: Transfer uses [source, destination, authority]; MintTo uses [mint, destination, mint_authority]; Burn uses [source, mint, authority]; GetBalance uses [token_account]. The dispatch handler enforces that the SPL authority matches the wallet that signed the outer transaction.

The same TNZO balance is read by three pointer contracts: the EVM wTNZO ERC-20, the SVM wTNZO SPL mint (registered at node startup), and the Canton CIP-56 TnzoHolding. tenzro_listTokens / tenzro_getToken return all three address keys for TNZO; tenzro_getTokenBalance returns the native, EVM, SVM, and Canton views of the same underlying balance.

Tenzro RPC does not speak Solana JSON-RPC. Use the native tenzro_* methods (tenzro_listTokens, tenzro_getTokenBalance, tenzro_svmDispatch) for SVM-side queries and dispatch. getSlot, getVersion, getLatestBlockhash and other Solana-shape requests will 404 against rpc.tenzro.network — the SVM view is exposed through Tenzro’s unified namespace, not the Solana wire protocol. SDKs (Rust tenzro-sdk + TypeScript tenzro-sdk) expose this through client.token.list_tokens() / get_token_balance(svm_wtnzo, account); the OpenClaw skill exposes the same surface as solana_get_token_accounts / solana_get_balance tools that translate to the Tenzro namespace.

The same EVM-side ERC-7579 modular validator chain enforces custody at signing time for SVM operations dispatched through the unified account abstraction layer (smart accounts whose installedModules include SessionKey / SpendingLimit / SocialRecovery validators). Persistence to CF_VALIDATOR_MODULES applies to SVM-routed user operations too; an account that installs a session-key validator can only call SVM programs that the session key has been granted on the EVM side.

The tenzro_cross_vm SVM native program (also short-circuited to a Rust handler) provides bridge_to_evm / bridge_from_evm / register_token_pointer / transfer_cross_vm instructions. Cross-VM transfers settle on the same block; the EVM-side and SVM-side state mutations are atomic per Block-STM. tenzro_crossVmTransfer is the JSON-RPC convenience wrapper.