Bridge Attacks Like the Recent Aave rsETH Exploit can be eliminated by a new n-VM architecture

Execution Layer Research
1

TL;DR
n-VM is a brand-new architecture that runs N heterogeneous VMs (EVM, SVM, Bitcoin Script and more can be added) as true first-class, co-equal citizens on a single consensus and shared state tree. It replaces fragmented identities and bridge-dependent token transfers with one 32-byte identity commitment and a unified token ledger. Cross-VM transfers are atomic by design, completely eliminating the entire class of bridge exploits that have cost the ecosystem over $2.8B.

Motivation
The blockchain ecosystem is still painfully fragmented. EVM, SVM, Bitcoin Script, and others each have their own account models, address formats, and token standards. Users juggle multiple wallets, liquidity stays siloed, and every cross-chain move depends on bridges — historically the #1 source of DeFi exploits.

Just yesterday (April 18, 2026), we saw this risk play out again at scale: attackers exploited a vulnerability in Kelp DAO’s LayerZero-powered rsETH bridge, draining ~116,500 unbacked rsETH (~$293 million). They dumped the fake tokens straight into Aave V3/V4 as collateral, borrowed real WETH, and left the protocol with substantial bad debt. Aave had to freeze the rsETH markets and TVL dropped over $6 billion. Once again, a single bridge failure cascaded into systemic pain.

Existing multi-VM projects (Sei v2, Movement, Eclipse, etc.) still treat one VM as primary and the rest as subordinate layers. Identity remains fragmented and token movement still requires bridge-like mechanisms.

n-VM does it differently: one runtime, N equal VMs, zero bridges.

Core Architecture
The stack is simple — just four layers:

  1. Consensus Layer (BFT + Attest–Execute–Prove pipeline)
  2. n-VM Dispatcher (opcode-prefix routing)
  3. Pluggable VM Engines (EVM, SVM, etc.)
  4. Unified State Tree + Identity Layer + Token Ledger

Opcode-Based Routing
The first byte of every transaction deterministically routes it to the right VM. Adding a new VM is as easy as registering an unused opcode range — no changes to existing engines or the shared state. Failed transactions are automatically snapshotted and rolled back, keeping everything isolated.

Unified Identity Layer
A single 32-byte commitment id_com = Poseidon(REV, salt, domain) anchors addresses across all VMs through deterministic, domain-separated derivation:

  • EVM: SHA-256("evm:" || id_com)[12:32] (20 bytes)
  • SVM: SHA-256("svm:" || id_com) (32 bytes)
  • …and so on for the others.

Users get one root identity, but every VM keeps its native address format. Wallets (MetaMask, Phantom, etc.) work out of the box via “raw chain ingress” — the chain recovers the signature and binds it to the unified id_com.

Unified Token Ledger
All tokens live in one single ledger. ERC-20 and SPL are simply different views over the same storage slots (keyed by id_com). A transfer from an EVM contract to an SVM program is just one atomic state transition:

    balance[M][id_comA] -= value;
    balance[M][id_comB] += value;

No lock-mint-burn-release cycle. No bridge contracts. No multi-sig committees. The design eliminates exactly the kind of unbacked-collateral attack that hit Aave yesterday.

Parallel Execution
Write-set conflict detection + optional context-based sharding (64 shards by default) give strong parallelism.

Security & Determinism
VM failures are fully isolated. Block-level determinism is guaranteed for every validator. Legacy signatures bind safely to the unified identity without weakening the model.

Comparison

System VMs Identity Token Transfer
Movement EVM + Move Separate Bridge
Eclipse SVM on Ethereum Separate L1↔L2 bridge
Sei v2 EVM + CosmWasm Pointer Pointer
Polkadot Per-parachain Per-parachain XCM
n-VM n equal VMs Single id_com Unified ledger

The Paper

I’d love to hear the community’s thoughts — especially on EVM compatibility, the trade-offs of opcode routing, and how this could play with existing Ethereum tooling or L2s.

Looking forward to your feedback!