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!

1 Like
2

One thing this design makes visible at this level of abstraction:

Execution here is validated and its effects are committed via state, but the execution itself is not independently referenceable.

The state root commits to outcomes, not the process that produced them.

Any system that produces deterministic state transitions already defines a deterministic execution representation sufficient to derive those transitions.

If that representation is treated as first-class:

H = hash(E)

and anchored on-chain, then verification reduces to:

recompute → compare → confirm inclusion

without requiring access to the originating runtime.

This makes execution independently referenceable and portable across systems, and separates:

  • agreement on outcomes (state)
  • from
  • verification of what occurred (execution)

which are distinct properties.

This is the layer formalized by OCP — a minimal primitive for making execution independently referenceable.

3

Hi and thanks for opening this thread !

The rsETH exploit is a good case study for what’s missing at the infrastructure level. Building on the bridge attack vector analysis with a standards perspective:

The rsETH exploit on April 18 demonstrated a structural gap in DeFi’s risk architecture: risk signals don’t propagate across chains in any standardized format. (Related thread on bridge attack vectors:

“Bridge Attacks Like the Recent Aave rsETH Exploit”) An attacker compromised LayerZero’s DVN infrastructure to mint 116.5K unbacked rsETH on Aave. The result: $124M-$230M in bad debt, $10B+ in outflows across protocols, and a 77-minute reaction time. The community is now coordinating $100M+ in rescue contributions. Two observations from a standards perspective:

-1. Risk signal format is unstandardized. Each protocol computes risk independently. Aave’s Guardian, Morpho’s risk engine, SparkLend’s governance / all detected different facets of the same contagion event at different times. No standard interface exists for one protocol to publish a risk signal that another protocol can consume programmatically. A minimal interface for this: solidity

interface IRiskSignal {
    function getRiskSignal() external view returns (
        uint256 compositeIndex,     // 0-100
        uint8   regime,             // STABLE, ELEVATED, CRISIS_FORMING, CRISIS, RECOVERY
        uint256 criticalClusters,
        uint256 timestamp,
        uint256 sourceChainId
    );
    function propagateSignal(RiskSignal calldata signal, bytes calldata proof) external;
}

The proof parameter is intentionally opaque — the standard doesn’t mandate any specific bridge protocol. Signal verification is implementation-defined. 2. Regime detection has formal properties worth studying. The transition function STABLE → ELEVATED → CRISIS_FORMING → CRISIS → RECOVERY can be modeled as a finite state machine with hysteresis (requiring sustained signals before transitions). RECOVERY was suggested by a commenter on our EthMagicians thread as a fifth state — it prevents the dangerous CRISIS → STABLE jump that re-opens positions prematurely. The CRI (Composite Risk Index) decomposition into structural (topology concentration) and active (cascade propagation) components creates a two-dimensional risk surface. Regime transitions triggered by either dimension independently vs. their combination is an open design question with implications for automated vault behavior. Formal question for the research community: Given N protocols on K chains, each producing independent risk assessments at frequency f, what is the minimum propagation latency required to ensure that no protocol acts on stale risk data with probability > 1-ε? In the rsETH case, contagion velocity (exploit → asset devaluation) was ~2 blocks. Signal velocity (detection → Guardian reaction) was 77 minutes.

The gap is 3 orders of magnitude. A reference implementation with 31 contracts across 3 chains (Base, Gnosis, BNB) and EIP-712 signed attestations achieving sub-minute relay latency is operational. The standard is proposed as ERC-1705 (PR: Git hub), with active discussion on EthMagicians……. - Interested in formal analysis of:

  • Optimal regime transition hysteresis parameters under adversarial conditions

  • Cross-chain signal propagation bounds when bridges are compromised

  • Game-theoretic properties of multi-source risk aggregation (preventing single-attester manipulation)

Patrick