Arbitrum Stylus — Building Web3 Applications with Rust, C++, WASM and EVM

Arbitrum Stylus is an extension of the Arbitrum Nitro technology stack that enables developers to build EVM-compatible smart contracts using Rust, C, C++, and other languages that can compile to WebAssembly. Rather than replacing Solidity, Stylus adds a second WASM execution environment alongside the EVM, allowing both types of contracts to operate on the same network and interact directly with each other. Stylus launched on Arbitrum mainnet on September 3, 2024, and has gradually evolved into a broader developer framework with a Rust SDK, CLI tools, ABI support, debugging, and WASM deployment capabilities. By 2026, the technology is positioned as an option for building computationally intensive DeFi, cryptographic, gaming, and infrastructure applications while retaining compatibility with the Ethereum ecosystem.

Contents

• What Is Arbitrum Stylus and How Does MultiVM Work?
• Smart Contract Development with Rust, C, and C++
• WASM, EVM, and Stylus Contract Performance
• Stylus SDK, Security, and Developer Tools
• Arbitrum Stylus Development and the Future of Web3 Programming

1. What Is Arbitrum Stylus and How Does MultiVM Work?

Stylus is an upgrade to Arbitrum Nitro rather than a separate blockchain or Layer 2 network. The technology adds a second virtual machine for WebAssembly to ArbOS alongside the existing Ethereum Virtual Machine. Arbitrum describes this architecture as MultiVM: Solidity contracts continue to execute through the EVM, while Stylus programs use the WASM environment.

The main advantage of this model is interoperability between the two execution environments. A Solidity contract can call a function in a program written in Rust, while a Stylus contract can interact with an existing ERC-20 token, oracle, or another Solidity application. Communication uses the standard Ethereum ABI, so developers do not need a separate bridge between EVM and WASM contracts.

This distinguishes Stylus from blockchains that use WASM as their only virtual machine and require developers to move applications into a different ecosystem. Existing parts of a protocol can remain written in Solidity, while computationally intensive components can be implemented in Rust or C++. This architecture makes it possible to introduce Stylus gradually into an existing dApp.

The technology launched on mainnet on September 3, 2024. Stylus was integrated into Arbitrum One and other compatible networks built on the Arbitrum stack, allowing developers to deploy WASM contracts alongside conventional EVM applications. In current documentation, Stylus is presented as an alternative development environment within the broader Arbitrum ecosystem rather than a replacement for Solidity.

2. Smart Contract Development with Rust, C, and C++

Rust is the primary programming language used with Stylus. Offchain Labs maintains the Stylus Rust SDK and the cargo-stylus development tool. As of July 2026, the documentation describes Rust SDK version 0.10.7, which enables developers to create Solidity ABI-compatible contracts, compile them into WebAssembly, and deploy them to Arbitrum networks. The SDK uses Alloy for Ethereum data types and interaction with the broader Rust Web3 ecosystem.

Rust is not the only available option. Stylus supports C and C++ through a dedicated SDK and can technically execute programs written in other languages if they compile into compatible WASM modules. The documentation also covers the deployment of WebAssembly Text and other precompiled WASM files. For less common languages, however, tooling and official support may be more limited than for Rust.

For Rust developers, the structure of a Stylus project resembles a conventional Cargo application. Projects use Cargo.toml, the Rust toolchain, and familiar crates, while Stylus-specific macros define storage, entrypoints, and public functions. However, not every library from crates.io can automatically operate in a blockchain environment. Features such as multithreading, system-generated randomness, and floating-point operations are not supported in the standard Stylus environment.

This approach broadens the potential audience for smart contract development. Developers experienced in systems programming, game engines, cryptography, and financial computation can work with familiar languages instead of being required to switch entirely to Solidity. Blockchain-specific constraints remain, however, including gas costs, storage management, reentrancy, access control, and other risks associated with immutable smart contract execution.

3. WASM, EVM, and Stylus Contract Performance

The main technical advantage of Stylus becomes apparent in compute-intensive operations. Rust code is first compiled into WASM, after which the deployed program goes through an activation process. During activation, ArbOS validates the WebAssembly code and prepares it for efficient execution. Once activated, a contract can execute computational logic more efficiently than an equivalent implementation based entirely on EVM bytecode.

The largest performance improvements can occur in arithmetic, loops, byte processing, cryptographic operations, and other workloads involving substantial computation or memory usage. Standard blockchain storage operations do not automatically become cheaper: SLOAD, SSTORE, external calls, transfers, and events continue to use the underlying mechanisms of Arbitrum. The actual cost advantage therefore depends on the architecture and workload of a particular application.

Activation is another distinctive feature of the framework. Deploying a Stylus contract involves uploading the WASM code and subsequently activating it. cargo-stylus normally handles both operations automatically. The network can reuse an already activated code hash, while frequently called programs may be placed in a dedicated cache to reduce the cost of subsequent execution.

This model expands the range of workloads that can reasonably be executed inside smart contracts. Examples discussed within the Arbitrum ecosystem include advanced cryptography, zero-knowledge verification, financial computation, storage proofs, and mathematical algorithms. Stylus does not make these operations free, but it can reduce the computational overhead associated with implementing them directly in the EVM.

4. Stylus SDK, Security, and Developer Tools

The Stylus ecosystem extends beyond the virtual machine itself. cargo-stylus enables developers to create projects, validate WASM compatibility, estimate costs, deploy programs, activate contracts, and export ABIs. The ecosystem also includes tools for source verification and debugging, including workflows for analyzing transactions involving multiple Stylus contracts and interactions with Solidity.

Key Features of Arbitrum Stylus:

• an additional WASM execution environment operating alongside the EVM;
• support for Rust, C, C++, and other WASM-compatible languages;
• ABI compatibility with Solidity contracts;
• bidirectional calls between EVM and Stylus programs;
• more efficient execution of compute-intensive operations;
• Stylus Rust SDK and cargo-stylus for development and deployment;
• Solidity ABI export for compatibility with existing Web3 tools;
• activation and caching mechanisms for WASM execution optimization;
• access to compatible parts of the existing Rust ecosystem;
• support for hybrid applications combining Solidity and WASM contracts.

Security remains a separate consideration. The core Stylus implementation underwent an audit by Trail of Bits before the mainnet launch, while the Rust SDK was reviewed by OpenZeppelin. Arbitrum documentation also references additional SDK audits, including assessments of version 0.10 conducted in December 2025. Auditing the framework can reduce certain infrastructure risks, but it does not replace security reviews of individual applications.

Rust can prevent several classes of memory-management errors, but smart contract vulnerabilities often originate in business logic rather than the programming language itself. Access-control mistakes, reentrancy, incorrect oracle assumptions, and unsafe interactions with external contracts remain possible. Moving from Solidity to Rust should therefore be viewed as a change in the development environment rather than an automatic solution to smart contract security.

5. Arbitrum Stylus Development and the Future of Web3 Programming

Following its mainnet launch, Stylus began appearing in DeFi and infrastructure experiments. One practical use case involves Uniswap v4 hooks, where complex custom logic can be implemented in Rust while interacting with EVM-based Uniswap contracts. Other projects have explored Stylus for cryptography, zero-knowledge computation, and applications that require more efficient data processing.

During 2025–2026, development increasingly shifted from proving the viability of the technology toward improving its tooling. The Rust SDK received new releases, while deployment workflows, constructors, contract verification, debugging, and caching mechanisms continued to evolve. This is important for broader adoption because the usefulness of a new smart contract language depends not only on execution performance but also on libraries, testing infrastructure, documentation, and overall developer experience.

Stylus can also be used in specialized networks built on the Arbitrum technology stack. This expands its potential applications beyond Arbitrum One. Custom Arbitrum chains can combine EVM and WASM execution for gaming, financial applications, AI infrastructure, cryptographic systems, and other products with demanding computational requirements.

Arbitrum Stylus represents an approach to expanding the Ethereum-compatible development environment without abandoning the existing EVM ecosystem. Solidity remains a fully supported development option, while Rust, C, and C++ provide additional flexibility for workloads where performance, memory handling, and access to existing software libraries are important. The long-term role of Stylus will depend on the maturity of its SDKs, the number of production applications, the quality of security tooling, and whether WASM contracts can deliver practical advantages in areas where conventional EVM execution becomes inefficient.