How Wasm Elevates Performance Without Leaving the EVM

Most conversations about execution models in Ethereum focus on proving speed, zkVM design, or whether RISC-V should become a universal instruction set. These are worthwhile protocol questions, but they are not the first concerns a builder faces when trying to ship fast, reliable onchain applications.

Builders think about execution environments. Builders think about predictable performance across machines. Builders think about how easily code can be profiled, optimized, and reproduced in production. These concerns shape real workloads far more than the debates researchers have.

This is where WebAssembly stands out.

Wasm has already proven itself as a portable, reproducible execution format across billions of devices. Developers know how it behaves. Toolchains understand how to optimize it. Engines know how to compile it to fast, native code. When Stylus brought Wasm into the Arbitrum ecosystem, developers gained access to these same qualities onchain, in a format that coexists with the EVM while sharing the same state tree.

After more than a year of Stylus in production, the verdict is clear. Wasm gives builders predictable speed, structured execution, safer instrumentation, and the flexibility to evolve across future proving systems.

Below is a closer look at why this matters for builders.

The three layers every builder should understand

To understand why Wasm improves performance, it helps to clarify the three roles that instruction sets play in a blockchain environment. What follows is adapted from a post on Ethereum Research by Mario Alvarez, Matteo Campanelli, Tsahi Zidenberg, and Daniel Lumi of Offchain Labs.

The three instruction set architectures (ISA) can be understood as:

• Delivery ISA (dISA): This is the format that smart contracts are deployed in. The EVM bytecode you write today is a dISA. Stylus uses Wasm as its dISA. This is the ISA that your code is actually stored in when it lands onchain.
• Proving ISA (pISA): The low level instruction set used inside proving circuits. Many zkVMs use variants of RISC-V today, but the proving landscape is still evolving.
• Execution ISA (eISA): This is the ISA that node software uses to execute the state transition function. It is mostly a concern for client implementors.

As a builder, you interact almost entirely with the delivery layer. This is where your contracts live, and this is where performance gains matter most. A key insight is that the delivery ISA does not need to match the proving ISA or the execution ISA. The ISA that works best for circuit layouts is rarely the ISA that works best for safe execution and predictable optimization.

Wasm fits the delivery role precisely because it can be cleanly compiled into whatever proving ISA or backend emerges in the future. It is stable, structured, and easy to transform.

Arbitrum’s execution layer (ArbOS) supports both EVM bytecode and Wasm instructions. This is why both contract types share the same state and can run side by side. Wasm does not replace the EVM. It complements it.

What performance means for builders

When protocol engineers say “performance,” they often mean prover throughput. Builders mean something different.

Builders are looking for execution speed on common hardware. Most of the heavy lifting happens in RPC endpoints that serve eth_call and gas estimation. These workloads are a high percentage of the volume of onchain transactions and they run on commodity ARM and x86 hardware. For builder performance, a dISA needs to run fast here, not just inside proof circuits.

At the same time, the VM must allow for clean and safe insertion of gas meters, safety guards and stack checks. This can only work well with structured code that avoids arbitrary jumps. Similarly, the developer experience requires mature compilers, good profiling tools, and predictable binary formats to achieve a high-performance builder environment.

Finally, none of the above matters if the execution environment cannot survive future changes in proving systems. Builders need a format that will not be invalidated by new proving systems. A future proofed dISA shields code from shifts in low-level proving choices.

Wasm delivers across all of these dimensions.

How Wasm improves performance today

Stylus has been live for a bit more than a year, and that year has shown some remarkable takeaways. The strongest takeaway is also the most simple.

Wasm contracts can be compiled to native machine code on the platforms that people actually use.

This gives builders near-native execution speed without requiring any specialized hardware or specialized node setups.

Wasm was designed from the ground up to compile efficiently into the native instruction sets used by ARM and x86. Modern toolchains have highly optimized Wasm paths, and the JITs (just-in-time compilation) in environments like browsers have been hardened over billions of executions. This means that Wasm smart contracts can take advantage of aggressive optimizations that have nothing to do with blockchain but everything to do with observable real-world performance.

For builders, this translates into faster signature verification, faster hashing, cheaper loops, and large performance wins for compute heavy workloads.

It's not just about near-native speed, Wasm also provides significant wins in structure.

Structured control flow helps both safety and speed

Wasm uses structured blocks instead of arbitrary jumps. For performance and safety, this is a major advantage.

Structured control flow:

• Lets the VM validate the program in linear time
• Allows safe and deterministic injection of gas meters
• Makes the code easier for compilers to optimize

Builders see these benefits in practice. Contracts behave predictably. Profiling tools work more reliably. Hazardous bytecode patterns simply are not expressible in Wasm.

Wasm's linear memory and typed instructions make its behavior easier to reason about. JITs can optimize it aggressively. Common operations like loading, storing, slicing, hashing, and transforming data becomes significantly faster and cheaper than their EVM equivalents. For computationally heavy workloads this difference means everything.

Developer experience is performance

One of the biggest performance multipliers in the real world is good developer experience. The ability for developers to iterate quickly is often the differentiator between applications that lag behind and those that keep up with their user needs.

Wasm inherits a mature ecosystem of compilers, debuggers, profilers, and build tools. Rust, C, C++ and TypeScript developers can use the same instrumentation tools they already know. This leads to better velocity and more predictable code, which is where the largest performance wins usually come from.

A multi-language reality means that different problems can be solved in differnt ways. Wasm makes that possible.

Stylus as the live example

Stylus has been a major part of Arbitrum’s execution model long enough to generate real data, and one of the clearest demonstrations of its impact comes from RedStone, a modular oracle framework widely used across DeFi.

RedStone is a strong example because their workload is both computation heavy and latency sensitive, making it a good benchmark for what Stylus actually changes in practice.

You can read the full deep dive: How RedStone Is Advancing Oracle Capabilities With Stylus

Oracles sit at the center of every DeFi market. They collect data from reputable sources offchain, cryptographically sign it, and then verify that data onchain for consumer contracts. RedStone’s architecture separates these steps into three independent layers: aggregation, signing, and onchain verification. This modular structure keeps the system flexible and makes it easy to integrate new data sources without altering how verification works.

Verification is the bottleneck. Even with compression and batching, the EVM imposes a compute ceiling that becomes expensive as workloads scale. The stack based memory model, the fixed 256 bit word size, and the simplicity baked into the EVM design all introduce friction for applications that need to perform large, data heavy updates.

RedStone adopted Stylus to push past that limit.

Stylus allows Wasm contracts to run beside EVM contracts while sharing the same state. This let RedStone bring their existing Rust SDK onchain with no rewrite tax. Wasm gave them direct memory access, efficient byte level operations, and optimizations that map cleanly to ARM and x86 hardware.

The results were immediate.

Stylus also supported incremental adoption. Existing EVM consumers did not need to rewrite their contracts. They simply read from the new Stylus powered feed in parallel with the older EVM adapter. No additional audit was required.

One year later, RedStone continues to report strong performance improvements:

RedStone now processes many feeds per transaction and supports structured datasets far larger than what EVM only oracles can handle.

The RedStone case is a preview of what high performance onchain systems will look like as Wasm adoption grows. Their plan is to continue encouraging consumers to adopt their Stylus powered oracle, and more protocols are likely to follow this pattern as they outgrow the compute limits of the EVM while still relying on its composability and ecosystem.

Stylus makes that path available today.

Wasm is not replacing the EVM. It sits beside it and opens up space for workloads that were never practical before. As more teams run into the limits of stack based execution and fixed width arithmetic in the EVM, the ability to bring mature toolchains and native speed compute onchain will matter even more. Stylus shows that this path is already real, not hypothetical. Builders who want performance today and flexibility tomorrow now have an environment that gives them both.