Inside the Multi-VM Execution Layer (MEL): Architecture, Runtimes, and Atomic Execution

1. The Multi-VM Architecture Thesis

Modern blockchain ecosystems are partitioned by execution environments. Ethereum developers build in Solidity using the EVM; Solana developers write high-throughput Rust programs on the SVM; and emerging ecosystems leverage Move for linear resource conservation or WebAssembly for lightweight execution.

Rather than forcing developers to rewrite their applications or relying on asynchronous cross-chain bridges, InterLayer introduces the Multi-VM Execution Layer (MEL): an orchestration framework integrated directly into the Substrate runtime kernel that runs smart contracts from five virtual machines natively in a shared global state trie.

Figure: Substrate Runtime & MEL Execution Stack

2. The 5 Native Virtual Machine Interpreters

MEL does not translate smart contracts into an intermediate bytecode. Instead, it embeds dedicated, highly optimized virtual machine interpreters inside the Substrate FRAME runtime:

To make onboarding frictionless, the chain exposes individual, fully compatible RPC subdomains. EVM developers connect Foundry or MetaMask directly to evm.interlayer.one, while Solana developers configure Anchor to interact with svm.interlayer.one.

3. The Universal MEL Transaction Envelope (MelTx)

To execute transactions across heterogeneous virtual machines without requiring separate wallets, all payloads are packaged into a unified MEL Transaction Envelope (MelTx):

#[derive(Clone, Encode, Decode, PartialEq, RuntimeDebug, TypeInfo)]
pub struct MelTx {
    /// Sender's canonical 32-byte account ID on InterLayer
    pub from: AccountId32,
    /// Destination contract address (format-agnostic)
    pub to: TargetAddress,
    /// Target execution environment (EVM, SVM, Move, CosmWasm, PolkaVM)
    pub vm: VmType,
    /// Raw call data payload for the target interpreter
    pub payload: Vec<u8>,
    /// Universal gas allowance in Substrate Weight Units
    pub gas_budget: u64,
    /// Signature authentication scheme (Ed25519, Sr25519, ECDSA, or Native)
    pub auth_scheme: AuthScheme,
    /// Nonce for replay protection
    pub nonce: u64,
}

Submitting a Cross-VM Transaction in JavaScript

Developers can package signed native payloads into the MEL envelope and dispatch it directly via the Substrate API:

import { ethers } from "ethers";
import { ApiPromise, WsProvider } from "@polkadot/api";

// 1. Package the signed EVM RLP transaction into the MEL envelope
const melTx = {
  from: Array.from(ethers.getBytes(evmAddress)),
  to: Array.from(ethers.getBytes(contractAddress)),
  vm: { EVM: null },                 // Target VM
  payload: Array.from(evmRlpBytes),  // Signed EVM transaction bytes
  gas_budget: 21000,
  nonce: Date.now(),
  chain_id: 2021,
  auth_scheme: { Native: null }      // Let EVM adapter verify internal sig
};

// 2. Submit the envelope natively to the Substrate kernel
const wsProvider = new WsProvider("wss://node.interlayer.one");
const api = await ApiPromise.create({ provider: wsProvider });

const txHash = await api.tx.melCore
  .executeMelTransaction(melTx)
  .signAndSend(senderKeypair);

4. Synchronous Atomic Cross-VM Calls via MelBus

When contracts across different VMs interact within the same transaction (e.g., an EVM contract calling a Solana program via the MelBus precompile at 0x...801), execution is completely synchronous:

// SPDX-License-Identifier: MIT
pragma solidity ^0.8.24;

interface IMelBus {
    function dispatchSvmCall(bytes32 programId, bytes calldata data) external returns (bytes memory);
}

contract CrossVmArbitrage {
    IMelBus public constant MEL_BUS = IMelBus(0x0000000000000000000000000000000000000801);

    function executeSwap(bytes32 svmRaydiumProgram, bytes calldata swapInstruction) external {
        // Synchronous atomic cross-VM call with state snapshot rollback on revert
        bytes memory result = MEL_BUS.dispatchSvmCall(svmRaydiumProgram, swapInstruction);
        require(result.length > 0, "SVM Execution Failed");
    }
}

The Execution Lifecycle:

1. Pre-Execution Snapshot: A Merkle trie state snapshot is recorded.
2. Unified Balance Lock: pallet-unified-balance locks the user's native balance before MEL acquires an execution lock.
3. Deterministic Rollback: If any sub-call reverts or runs out of gas, the entire state reverts atomically to the pre-execution snapshot.

5. Universal Gas Calibration

To prevent cross-VM resource starvation, MEL standardizes gas computation into Substrate Weight Units ($1 \text{ Weight} = 1 \text{ picosecond of execution time}$):

Where $K_{\text{EVM}}$, $K_{\text{SVM}}$, and $K_{\text{Move}}$ are calibrated benchmarks ensuring fair compute pricing across all five virtual machines.