What makes Stylus different
Arbitrum Stylus introduces a WebAssembly (WASM) execution environment that runs alongside the existing EVM. This architecture allows developers to write smart contracts in high-performance languages like Rust, C, and C++, rather than being limited to Solidity or Vyper.
By compiling to WASM, Stylus programs access a broader ecosystem of existing libraries and tools. This enables substantial performance gains for compute-heavy tasks, such as zero-knowledge proof verification or complex cryptographic operations, which can be inefficient or costly on the pure EVM.

The core distinction lies in how the chain processes code. While the EVM relies on a stack-based instruction set designed for security and uniformity, Stylus leverages the efficiency of WASM. This allows Arbitrum to support multiple virtual machines simultaneously, giving projects the flexibility to choose the right stack for their specific engineering needs.
| Feature | EVM (Solidity) | Stylus (Rust/C++) |
|---|---|---|
| Language | Solidity, Vyper | Rust, C, C++, AssemblyScript |
| Execution Model | EVM Bytecode | WebAssembly (WASM) |
| Performance | Standard | High (up to 20x faster for compute) |
| Interoperability | Native on Ethereum L2s | Arbitrum-specific (can call EVM contracts) |
EVM vs. Stylus: Core differences
Arbitrum supports two distinct environments for smart contracts: the native Ethereum Virtual Machine (EVM) and Stylus. While the EVM remains the standard for Solidity and Vyper development, Stylus introduces WebAssembly (WASM) execution. This allows developers to write contracts in languages like Rust, C, and C++, broadening the ecosystem beyond Solidity’s syntax.
The primary engineering tradeoff lies in language flexibility versus ecosystem maturity. The EVM offers a vast library of existing tooling and established security patterns, making it the safer choice for standard DeFi protocols. Stylus, however, provides access to a wider range of programming languages and potentially higher execution efficiency for compute-heavy tasks, appealing to developers who prefer systems-level languages.
Comparison of Execution Environments
The table below outlines the technical distinctions between the two stacks.
| Feature | EVM | Stylus |
|---|---|---|
| Primary Languages | Solidity, Vyper | Rust, C, C++ |
| Compilation Target | EVM Bytecode | WebAssembly (WASM) |
| Execution Speed | Standard | Potentially Faster |
| Tooling Maturity | Mature, Extensive | Growing, Rust-focused |
| Interoperability | Full Ethereum Compatibility | ABI-equivalent via SDK |
Stylus contracts are compiled to WASM and executed on Arbitrum’s specialized WASM VM. To ensure compatibility with existing Ethereum tooling, Stylus provides an SDK that generates Solidity ABI-equivalent interfaces. This allows Stylus contracts to interact seamlessly with standard EVM contracts, bridging the gap between the two environments without requiring developers to rewrite their entire stack.
Performance and gas efficiency
Arbitrum Stylus introduces WebAssembly (WASM) execution to the EVM environment, fundamentally changing how compute-heavy tasks are priced and processed. While the EVM was designed for simplicity and security, it often struggles with the overhead of interpreting complex logic. Stylus allows developers to write smart contracts in Rust, C, and C++, compiling them into WASM modules that execute natively on the chain. This shift from interpretation to native execution provides a significant advantage for applications requiring heavy computation, such as zero-knowledge proof verification, machine learning inference, or complex cryptographic operations.
The primary benefit for users is reduced gas costs for these specific workloads. Because WASM executes more efficiently than the EVM’s bytecode, it requires fewer computational steps to achieve the same result. Arbitrum estimates that WASM execution can reduce gas costs for complex computations by up to 100x compared to equivalent EVM implementations. This efficiency is not universal; for simple token transfers or basic storage operations, the EVM remains cost-effective. However, for any application where CPU cycles are the primary bottleneck, Stylus offers a substantial economic advantage.
Throughput also improves as a result of this efficiency. By reducing the gas consumed per transaction for compute-heavy tasks, Stylus allows more such transactions to be included in a single block. This increases the overall capacity of the network for advanced applications without requiring a change in the underlying rollup architecture. Developers can now build applications that were previously too expensive to deploy on-chain, expanding the scope of what is possible on Arbitrum.

The following table summarizes the core differentiation between the two execution environments regarding performance and cost.
| Feature | EVM | Stylus |
|---|---|---|
| Execution Model | Bytecode interpretation | Native WASM execution |
| Gas Efficiency for Compute | Standard overhead | Up to 100x reduction for complex tasks |
| Supported Languages | Solidity, Vyper | Rust, C, C++ |
| Throughput Impact | Standard block capacity | Higher capacity for compute-heavy transactions |
Developer ecosystem and tooling
The developer experience on Arbitrum depends heavily on which smart contract stack you choose. EVM developers work within a mature ecosystem with extensive tooling support, while Stylus developers engage with a rapidly evolving environment designed for systems-level languages like Rust.
EVM tooling maturity
Developers writing Solidity on Arbitrum benefit from established infrastructure. Standard development tools like Hardhat, Foundry, and Remix work out of the box. The deployment pipeline is well-documented, and debugging tools are widely available across the industry. This familiarity reduces onboarding time and allows teams to leverage existing libraries and community resources.
Stylus development workflow
Stylus introduces a different engineering workflow. The stylus-sdk-rs allows developers to write smart contracts in Rust that compile to WebAssembly. This requires understanding WebAssembly compilation targets and managing Rust-specific dependencies. The learning curve is steeper for developers accustomed to high-level smart contract languages, but it offers access to Rust's performance guarantees and type safety.
Testing and verification
Testing frameworks have adapted to support both stacks. For Stylus, tools like Motsu provide specialized testing environments that mimic Arbitrum's execution context. This ensures that contracts behave correctly before deployment. EVM contracts continue to rely on standard unit and integration tests within Hardhat or Foundry environments. Verification processes also differ, with Stylus requiring additional steps to map WebAssembly bytecode to readable source code.
Comparison of development stacks
The following table summarizes the key differences in developer experience between the two approaches.
| Feature | EVM (Solidity) | Stylus (Rust/WASM) |
|---|---|---|
| Primary Language | Solidity | Rust, C, C++ |
| Compilation Target | EVM Bytecode | WebAssembly (WASM) |
| Primary SDK | Hardhat, Foundry | stylus-sdk-rs |
| Testing Frameworks | Hardhat, Foundry | Motsu, standard Rust tests |
| Learning Curve | Low to Moderate | Moderate to High |
| Library Ecosystem | Extensive | Growing (Rust crates) |
Choosing between these stacks involves balancing familiarity against performance needs. Teams with existing Solidity expertise may prefer the EVM path for speed of deployment. Teams prioritizing computational efficiency and systems-level control might find the Stylus workflow more suitable despite the additional setup complexity.
When to choose Stylus over EVM
Stylus offers a clear advantage when your application demands high throughput or complex computational logic that exceeds the constraints of standard EVM opcodes. By supporting WebAssembly (WASM) and languages like Rust, C, and C++, Stylus enables significantly faster execution speeds and lower gas costs for compute-heavy operations. This makes it the preferred stack for high-frequency trading platforms, complex on-chain games, and data-intensive applications where EVM performance bottlenecks would degrade user experience.
If your project relies on existing Rust or C++ libraries, Stylus allows you to leverage that ecosystem directly. You can integrate mature cryptographic primitives or custom data structures without the overhead of rewriting logic in Solidity or Vyper. This reduces development time and potential security risks associated with porting code to the EVM environment.
The following table summarizes the core technical tradeoffs to help you decide which stack aligns with your engineering requirements.

| Feature | Stylus (WASM) | EVM (Solidity) |
|---|---|---|
| Execution Speed | High (near native) | Standard (opcode-bound) |
| Language Support | Rust, C, C++ | Solidity, Vyper |
| Gas Efficiency | Lower for complex logic | Predictable, higher for compute |
| Ecosystem Maturity | Growing | Established, vast tooling |
| Security Model | Memory safe (Rust) | Well-audited patterns |
Frequently asked: what to check next
What is Stylus?
Stylus allows developers to write smart contracts in high-performance languages like Rust, C, and C++ that compile to WebAssembly (WASM) 1. Unlike the traditional EVM which uses Solidity and Yul, Stylus enables access to broader ecosystems of existing libraries and tooling. This architecture supports substantial performance gains and attracts new developer talent beyond the Solidity niche 2.
Is Arbitrum an Ethereum Layer 2?
Yes, Arbitrum is an Optimistic Rollup Layer 2 scaling network built by Offchain Labs. Launched on mainnet in August 2021, it batches transactions off-chain and settles proofs on Ethereum’s base layer. This structure significantly reduces gas fees compared to Ethereum mainnet while inheriting Ethereum’s security guarantees 3.
Is there an Arbitrum token?
The $ARB token is an ERC-20 governance token that allows holders to participate in the Arbitrum DAO’s on-chain governance protocol. The token is minted by a smart contract on Arbitrum One, the primary Layer 2 rollup chain. Governance decisions regarding protocol upgrades and treasury management are executed through this token 4.

No comments yet. Be the first to share your thoughts!