EVM, WASM & IVM: Blockchain Execution Compared

Smart contracts continue to automate agreements across nearly every blockchain, but 2025 forces developers to choose between three distinct execution paradigms: Ethereum’s liquidity-driven EVM, Polkadot’s flexible WASM runtimes, or SORA Nexus’s deterministic IVM designed for governed economies and CBDC integration.

This choice matters because each approach optimizes for different priorities—composability, flexibility, or institutional-grade determinism. SORA’s evolution from Substrate/WASM (v2) to Iroha 3/IVM (v3) demonstrates how networks can transition between paradigms while maintaining their DeFi ecosystems.

TL;DR

Three execution paradigms define modern blockchain development:

• EVM / Solidity dominates DeFi with unmatched composability and liquidity across Ethereum, Base, Polygon, and L2s.
• WASM / Rust powers Polkadot’s parachain ecosystem with flexible, upgradeable runtimes via Substrate.
• IVM / Kotodama is SORA Nexus’s purpose-built deterministic VM — designed for governed execution, CBDC interoperability, and institutional use cases.

Choose EVM for immediate market reach, WASM for parachain flexibility, and IVM for deterministic governance and regulatory compatibility.

Key Takeaways

• EVM/Solidity remains the global standard for DeFi composability and developer tooling.
• WASM/Rust powers Polkadot’s Substrate framework, enabling flexible parachain runtimes and upgradeable logic.
• SORA Nexus (Iroha 3) uses the IVM (Iroha Virtual Machine) with Kotodama bytecode — NOT WASM — for deterministic, governed execution.
• Products like Polkaswap and Kensetsu run on SORA’s infrastructure, benefiting from IVM’s predictability and governance integration.
• SORA v2 (Substrate-based) supported WASM; SORA v3 (Nexus) moved to IVM for stricter determinism and CBDC compatibility.
• Definitions for governance, bonding curves, and liquidity live in the Soranauts Glossary, with related datasets viewable in SORA Explorer.

Understanding the Execution Environments

Smart contracts execute on virtual machines that define how bytecode runs on-chain. Three dominant approaches have emerged, each optimizing for different priorities:

EVM / Solidity (Ethereum)

The Ethereum Virtual Machine standardizes bytecode execution across Ethereum and compatible chains (Base, Polygon, Arbitrum, Optimism). Solidity’s familiar syntax and massive ecosystem make it the default for DeFi applications. The EVM documentation covers execution mechanics, opcodes, and gas metering in detail.

Strengths:

• Global composability — deploy once, integrate everywhere
• Extensive tooling (Hardhat, Foundry, Remix)
• Massive liquidity and user base
• Battle-tested security patterns

Tradeoffs:

• Gas constraints and opcode limitations
• Upgrade complexity (proxy patterns, migrations)
• Shared congestion during high usage

For a deeper comparison of Ethereum’s architecture, see our Polkadot vs Ethereum analysis.

WASM / Rust (Polkadot/Substrate)

WebAssembly enables near-native performance with language flexibility. Polkadot’s Substrate framework uses WASM for parachain runtimes, allowing forkless upgrades and custom logic. The WebAssembly standard ensures portable, sandboxed execution across different platforms.

Strengths:

• Flexible runtimes — custom state models and execution logic
• Forkless upgrades — governance-approved updates without hard forks
• Multi-language support — Rust, C, C++, and others compile to WASM
• Parachain specialization within Polkadot’s shared security

Tradeoffs:

• Newer ecosystem compared to EVM
• Parachain coordination overhead (slot auctions, relay chain dependencies)
• Requires deeper technical expertise

For developers exploring Rust in this context, see our guide on Rust programming for cryptocurrencies.

Historical Context: Earlier SORA versions (v1–v2) used Substrate pallets and ink! contracts, leveraging WASM runtimes. SORA v2 remains online on Substrate, while SORA v3 (Nexus) transitions to a fundamentally different architecture.

IVM / Kotodama (SORA Nexus / Iroha 3)

The Iroha Virtual Machine (IVM) is SORA Nexus’s purpose-built execution environment. Unlike EVM or WASM, IVM was designed from scratch for deterministic, auditable execution suitable for CBDCs, institutional systems, and governed DeFi.

Key IVM characteristics:

• Register-based architecture: 256 64-bit general-purpose registers (r0 always equals zero, following RISC conventions)
• Kotodama bytecode: Smart contracts compile to .to files (not WASM) with explicit headers and ABI versions
• Pointer-ABI types: Norito TLV envelopes ensure type-safe inter-contract calls
• No floating-point operations: Strict determinism — identical execution across all validators, every time
• ISI integration: All state changes via Iroha Special Instructions (ISI) applied to World State View (WSV)
• Governed upgrades: Parliament-approved module updates, versioned configs, no surprise forks

Strengths:

• Guaranteed determinism for institutional use cases
• CBDC compatibility by design
• Governed evolution through SORA Parliament
• Auditable state transitions (every change via explicit ISI)
• No nondeterministic syscalls or floating-point edge cases

Tradeoffs:

• Newer ecosystem (Iroha 3 launched in 2025)
• Requires Iroha-specific tooling and Kotodama compiler
• Smaller developer community compared to EVM or Substrate

For a complete overview, see the SORA Nexus Complete Guide.

Comparing Execution Environments

Similarities

All three are Turing-complete, meter execution (gas/weight/resources), provide testing frameworks, and enable cross-chain bridging through wrapped assets or message passing.

Tradeoffs

• EVM/Solidity: Mature, composable, constrained by gas model and opcode limits
• WASM/Rust: Flexible, performant, requires parachain coordination and deeper expertise
• IVM/Kotodama: Deterministic, governed, newer with smaller ecosystem but designed for institutional requirements

Case Study: The SORA Stack

SORA’s evolution illustrates how a network can transition between execution environments while maintaining its DeFi ecosystem.

SORA v2 (Substrate / WASM)

SORA v2 runs on Substrate, using WASM-compatible runtimes. This phase established:

• Polkaswap — liquidity aggregation and AMM
• Kensetsu — KUSD stablecoin issuance
• XOR, VAL, PSWAP — core token ecosystem
• Polkadot parachain integration and XCM messaging

SORA v2 demonstrated governance-driven DeFi within Polkadot’s ecosystem but faced limitations in determinism and CBDC compatibility due to WASM’s flexibility.

SORA v3 / Nexus (Iroha 3 / IVM)

SORA v3 (Nexus) migrates to Hyperledger Iroha 3, replacing WASM with the IVM (Iroha Virtual Machine). This architectural shift prioritizes:

• Strict determinism — No floating-point operations, explicit syscalls, guaranteed identical execution across all validators
• CBDC compatibility — Designed for institutional and regulatory requirements from day one
• Governed evolution — Parliament-approved upgrades without hard forks or surprise changes
• Hubchain model — Politically neutral interoperability layer connecting CBDCs, DeFi, and enterprise systems

The Fujiwara testnet validates IVM modules, governance mechanisms, and cross-chain verifiers before mainnet activation. Internal research continues refining Nexus’s architecture ahead of production release.

Polkaswap & Kensetsu

Polkaswap continues as the liquidity core for XOR, VAL, PSWAP, and cross-chain assets. Kensetsu complements it by issuing KUSD and TBCD, funding builders through the bonding-curve treasury.

Together they form SORA’s economic engine — with governance transitioning from Substrate’s WASM runtime (v2) to Iroha 3’s IVM (v3) as Nexus matures. Economic logic written in Rust adapts to the new execution environment while maintaining compatibility.

SORA Card & TONSWAP

SORA Card demonstrates how IVM governance can coexist with compliance frameworks, bridging DeFi’s permissionless ethos with institutional requirements. TONSWAP connects Telegram-based liquidity to SORA’s ecosystem, showcasing cross-chain integration under the new architecture.

Both products benefit from IVM’s deterministic execution and governed upgrade path, ensuring predictable behavior for institutional partners and retail users alike.

Conclusion

EVM, WASM, and IVM represent three philosophies for blockchain execution:

• EVM optimizes for global composability — deploy once, integrate everywhere across Ethereum’s vast liquidity network.
• WASM optimizes for flexibility — custom runtimes, forkless upgrades, and specialized parachain logic within Polkadot’s ecosystem.
• IVM optimizes for deterministic governance — institutional-grade predictability, CBDC readiness, and Parliament-approved evolution.

The most resilient builders will understand all three:

• Use Solidity for Ethereum’s liquidity and composability
• Use Rust/WASM for Polkadot’s modularity and parachain innovation
• Use Kotodama/IVM for SORA Nexus’s governed economy and institutional integration

For deeper context on how these systems connect, see the SORA Ecosystem Guide.

FAQs