Redstone x Arbitrum Stylus: Oracles Beyond the EVM Limitations

In a previous article, we introduced Stylus and examined its significance to the Arbitrum ecosystem, highlighting early practical implementations.

Now that some time has passed, it is appropriate to revisit the topic.

This article analyses how Stylus can be used to circumvent the structural constraints of the Ethereum Virtual Machine (EVM), using RedStone’s oracle implementation as a representative case study.

Small Primer on Stylus

Before examining the case study, it is helpful to restate Stylus’s role for Arbitrum’s broader architectural roadmap.

Stylus expands Arbitrum into one of the most developer-accessible L2s by introducing a second execution layer: a WebAssembly (WASM) virtual machine that operates alongside the traditional EVM. This dual-VM design broadens the available programming models and opens a new design space that is not achievable within Solidity-only constraints.

In practical terms, Stylus enables developers to deploy smart contracts written in widely adopted, performance-optimised languages such as Rust, C, and C++. The WASM VM interprets and compiles these languages while maintaining interoperability with existing EVM environments. This can be understood as introducing a translation layer that retains the EVM’s composability while lifting its computational and architectural restrictions.

The resulting expansion of the design space is substantial. WASM introduces:

• Mature tooling and ecosystems from established programming languages.

• Efficient handling of memory and compute-intensive logic.

• Viability for categories of applications that are prohibitively expensive or impractical on the EVM alone (e.g., advanced cryptographic primitives, simulation-heavy DeFi applications, onchain agents, and data-intensive analytics).

The next section demonstrates these advantages within the context of Oracle infrastructure, using RedStone as a case study.

RedStone x Stylus: Overcoming EVM Constraints

Operating an oracle within an EVM-only environment is costly, especially for high-throughput or data-heavy feed updates. While some protocols mitigate these inefficiencies through design trade-offs, oracles that depend on large payloads face structural bottlenecks that make frequent or complex updates economically prohibitive.

The primary limitations include:

• Stack-Based Architecture: Direct memory access is not possible, requiring multiple stack operations even for simple tasks.

• Rigid 256-bit Word Size: All operations, regardless of actual bit-width, incur the cost of 256-bit processing.

• Limited OP code set: Limited native support for common computational patterns; absence of SIMD instructions and native floating-point operations.

• Quadratically Scaling Memory Costs: Complex data structures are expensive to store and manipulate.

• Interpreted Bytecode vs Compiled: EVM bytecode is interpreted at runtime, without opportunities for just-in-time optimisation.

• No direct hardware access: Examples include the impossibility of CPU-specific optimisation and making cryptographic operations very expensive.

Stylus directly addresses these issues. Its WASM VM allows RedStone to compile and execute Rust-based logic onchain, significantly improving performance and reducing gas costs.

Because RedStone’s SDK is written in Rust, Stylus provides a near-native execution environment without requiring re-implementation of core logic in Solidity.

Another key differentiator of Stylus, fundamental to RedStone’s oracle implementation, is direct memory access, which enables efficient data structures and allows multiple feeds to be processed within a single transaction. WASM’s native 32- and 64-bit operations avoid the forced 256-bit overhead, making high-throughput data handling feasible. RedStone expects this to eventually support “1MB-class data windows per block” for specialised use cases.

The advantages of operating in a WASM context include:

• Computational Performance: 10-100x faster execution for complex operations

• Memory Efficiency: Direct memory access and optimised data structures

• Gas Reduction: Lower execution costs for compute-heavy logic.

• Language Ecosystem: Use of established tooling and libraries.

• Compile-Time Guarantees: Strong type- and memory-safety properties.

• Near-Native Performance: Execution closer to hardware-level efficiency.

Using Stylus, RedStone can:

• Implement WASM-optimised cryptographic primitives

• Leverage direct memory access for high-speed data ingestion and processing

• Use native Arbitrum precompiles

• Maintain interoperability between WASM and EVM contracts

These advantages translate into tangible savings and improvements, both in the base computational overload (34.3% reduction) and in the computation per-feed (50% reduction), as highlighted in the table below. Compared to its EVM implementation, Stylus still achieves 26% total savings by cutting computational costs nearly in half.

Furthermore, building on Stylus incurs identical costs for:

• L1 Calldata Posting

• Cryptographic Operations

• Storage Operations

Although L1 calldata posting remains the dominant cost for small transactions, Stylus’s relative advantages scale with feed complexity.

More complex data windows see larger savings due to improved:

• Data processing

• Memory management

• Contract execution performance

This makes it particularly adaptable for scalable solutions.

RedStone now maintains Stylus-based oracle feeds alongside existing EVM adapters, with ongoing optimisation planned across both its Rust SDK and Stylus-specific implementations.

Beyond the EVM: Strategic Implications

The RedStone integration illustrates the broader architectural implications of Stylus: protocols can transcend EVM limitations while preserving full composability within the EVM ecosystem.

By combining Rust’s mature toolchains with Arbitrum’s compute-efficient WASM VM, RedStone significantly reduces gas costs across a wide range of data-intensive applications. This unlocks oracle capabilities that were previously uneconomical or technically infeasible, such as more frequent price updates due to lower costs and the ability to implement complex logic in Rust.

Examples include:

• Price updates that can keep up with high-frequency trading

• Complex derivatives requiring heavy computational verification

• Cross-chain applications

• Data-rich DeFi products, which were otherwise constrained by gas costs

Previously, we’ve dived into the differences in the tools available to developers, highlighting several limitations of building in Web3. Bypassing the limitations of the EVM offers several strategic advantages: developers can operate within the same unified SDK that Redston uses across Solana, Radix, and Stylus, access Rust’s tooling and libraries, and avoid vendor lock-in by keeping data verification onchain.

In this sense, Stylus represents a foundational shift. By supporting multiple programming languages and enabling efficient execution of non-Solidity workloads, it lowers the barrier to building advanced systems on Arbitrum and expands the scope of what is technically possible within L2s.