Why We Built a Multi-VM Runtime

Most blockchains pick a side. Ethereum chose the EVM. Solana built the SVM. Enterprise networks standardized on DAML. But the agent economy doesn't respect these boundaries. Autonomous AI agents need to interact with DeFi protocols on Ethereum, execute high-throughput programs on Solana, and settle with enterprise Canton ledgers—all within a single transaction flow.

The Multi-Ecosystem Reality

We started building Tenzro with a simple observation: the fragmentation of blockchain ecosystems is an architectural constraint, not a feature. When an AI agent orchestrates a cross-chain payment, it shouldn't need to manage three separate wallets, three transaction formats, and three consensus mechanisms. The complexity should collapse at the infrastructure layer.

Tenzro runs three virtual machines in a single execution runtime:

• EVM (Ethereum Virtual Machine) — Full compatibility with Ethereum smart contracts, using revm for bytecode execution. Deploy Solidity contracts, call existing DeFi protocols, and leverage the mature Ethereum developer ecosystem.
• SVM (Solana Virtual Machine) — High-throughput BPF program execution via solana_rbpf with syscall stubs for sol_log, sol_sha256, and compute unit metering. Execute Solana programs with native account serialization.
• DAML Executor — Canton Ledger API v2 integration for enterprise DAML smart contracts. Connect to existing Canton domains, execute templates, and settle with traditional finance infrastructure.

The MultiVmRuntime routes transactions by type, but the state layer is unified. A single Merkle Patricia Trie tracks account balances. A single Block-STM executor parallelizes transactions. A single EIP-1559 fee market adjusts gas prices dynamically across all three VMs.

Block-STM: Parallel Execution Without Conflicts

Sequential transaction processing is a bottleneck. Ethereum processes approximately 15 transactions per second because each transaction executes serially. Solana achieves higher throughput with parallel execution, but only for transactions that touch disjoint state.

We implemented Block-STM, a parallel execution engine with multi-version concurrency control (MVCC). Transactions execute optimistically in parallel. When conflicts are detected, the engine automatically falls back to sequential execution for conflicting transactions only.

pub struct BlockStmExecutor {
    thread_pool: ThreadPool,
    max_reexecutions: usize,  // Default: 16
    conflict_threshold: f64,  // Default: 0.5 (50%)
}

impl BlockStmExecutor {
    pub async fn execute_block(&self, txs: Vec<Transaction>) -> Result<Vec<ExecutionResult>> {
        // Phase 1: Optimistic parallel execution
        let results = self.execute_parallel(txs.clone()).await?;

        // Phase 2: Conflict detection via MVCC
        let conflicts = self.detect_conflicts(&results);

        // Phase 3: Sequential fallback if conflict rate > threshold
        if conflicts.len() as f64 / txs.len() as f64 > self.conflict_threshold {
            return self.execute_sequential(txs).await;
        }

        // Phase 4: Reexecute only conflicting transactions
        self.reexecute_conflicts(results, conflicts).await
    }
}

The MVCC data structure maintains multiple versions of each state variable. When transaction T2 reads a value written by T1, the executor records a read dependency. If T1 aborts or reexecutes, T2 must also reexecute. This dependency tracking ensures serializability without global locks.

Performance characteristics: maximum 30 million gas per block, maximum 16 reexecutions per transaction, automatic sequential fallback when conflict rate exceeds 50%. In practice, most agent workloads have low contention—different agents interact with disjoint state.

EIP-1559: Dynamic Fee Markets

Gas price auctions create terrible user experiences. Users overpay during congestion or get stuck in the mempool during low traffic. Ethereum solved this with EIP-1559: a dynamic base fee that adjusts algorithmically, plus a priority fee for transaction ordering.

We implemented EIP-1559 across all three VMs. The base fee adjusts by ±12.5% per block based on gas utilization relative to a 15 million gas target. When blocks are full, the base fee increases, pricing out lower-value transactions. When blocks are empty, the base fee decreases, making transactions cheaper.

pub struct FeeMarket {
    base_fee: u64,  // Current base fee in Gwei
    target_gas: u64,  // 15,000,000
    min_base_fee: u64,  // 0.1 Gwei
    max_base_fee: u64,  // 1000 Gwei
}

impl FeeMarket {
    pub fn adjust_base_fee(&mut self, gas_used: u64) -> u64 {
        let delta = if gas_used > self.target_gas {
            // Block is full: increase base fee by 12.5%
            ((gas_used - self.target_gas) as u128 * self.base_fee as u128
                / self.target_gas as u128 / 8) as u64
        } else {
            // Block is empty: decrease base fee by 12.5%
            ((self.target_gas - gas_used) as u128 * self.base_fee as u128
                / self.target_gas as u128 / 8) as u64
        };

        // Clamp to [min, max] bounds
        self.base_fee = (self.base_fee + delta)
            .max(self.min_base_fee)
            .min(self.max_base_fee);

        self.base_fee
    }
}

The base fee is burned, removing TNZO tokens from circulation with every transaction. This creates deflationary pressure and aligns user incentives with network economics. Priority fees go to validators as a tip for transaction inclusion.

For AI agents, predictable gas pricing is critical. Agents can query the current base fee, estimate the priority fee based on urgency (low/medium/high), and construct transactions with bounded costs. No more gas price auctions, no more stuck transactions.

ERC-4337: Account Abstraction for Agents

Traditional blockchain accounts are EOAs (externally owned accounts) controlled by private keys. This is terrible for AI agents. Agents can't securely store seed phrases, can't program custom authorization logic, and can't pay their own gas fees without pre-funding.

ERC-4337 account abstraction solves this with smart contract wallets. Instead of a private key, the account is a smart contract with programmable validation logic. Instead of signing transactions, agents submit UserOperations to an EntryPoint contract that validates and executes them.

pub struct SmartAccount {
    pub address: Address,
    pub owner: Address,
    pub modules: Vec<AccountModule>,
    pub nonce: u64,
}

pub enum AccountModule {
    SocialRecovery { guardians: Vec<Address>, threshold: u32 },
    SessionKey { key: PublicKey, expires_at: Timestamp, permissions: Vec<Operation> },
    SpendingLimit { max_daily: u64, current: u64, reset_at: Timestamp },
    Batching { max_batch_size: usize },
}

impl SmartAccount {
    pub fn validate_user_op(&self, op: &UserOperation) -> Result<ValidationData> {
        // Check signature via owner or session key
        self.verify_signature(&op.signature)?;

        // Check nonce to prevent replay
        if op.nonce != self.nonce {
            return Err(VmError::InvalidNonce);
        }

        // Check spending limits
        for module in &self.modules {
            module.validate(op)?;
        }

        Ok(ValidationData::valid())
    }
}

Smart account modules enable powerful agent capabilities:

• Social Recovery — Multiple guardian addresses can recover the account if the owner key is lost. No seed phrase required.
• Session Keys — Temporary keys with limited permissions and expiration times. Agents can grant fine-grained access to third-party services.
• Spending Limits — Daily spending caps prevent runaway agent behavior. If an agent is compromised, maximum damage is bounded.
• Batching — Multiple operations in a single UserOperation. Atomic multi-step workflows without multiple transactions.

The Paymaster system completes the picture. A Paymaster is a smart contract that agrees to pay gas fees on behalf of a UserOperation. This enables:

• Gas sponsorship — Applications pay gas fees for their users or agents
• Token payments — Pay gas fees in USDC instead of TNZO
• Subscription models — Monthly gas allowances for registered agents

Cross-VM State Consistency

The hardest problem in multi-VM design is state consistency. When an EVM contract calls a Solana program, which state root is canonical? How do you prevent double-spending across VMs?

Our solution: a unified state adapter backed by a single Merkle Patricia Trie. All three VMs read and write through the same state layer. EVM accounts, SVM accounts, and DAML contracts all live in the same state tree. The Block-STM executor ensures serializability across VMs—if an EVM transaction conflicts with an SVM transaction, both are detected and reexecuted in order.

Gas accounting is normalized across VMs. EVM uses "gas", SVM uses "compute units", and DAML uses fixed estimates. We convert all three to a common gas unit at the state layer, so the EIP-1559 fee market works uniformly across all execution environments.

Why This Matters

Blockchain fragmentation is a temporary phase. The next generation of decentralized infrastructure will be multi-ecosystem by default. AI agents don't care about Ethereum vs Solana tribal debates—they care about accessing liquidity, executing logic, and settling payments wherever those capabilities exist.

Tenzro's multi-VM runtime is a bet on convergence. Instead of forcing agents to bridge between chains, we bring the chains to the agents. Execute EVM contracts for DeFi, run Solana programs for high throughput, and settle with Canton for enterprise compliance—all in a single transaction, all with account abstraction and gas sponsorship built in.

The agent economy needs infrastructure that works like the internet: open protocols, interoperable standards, and zero friction between ecosystems. That's what we're building.