Skip to main content

ArbOS

ArbOS is the child EVM hypervisor for the Arbitrum chain, providing the execution environment for the chain. Acting as a trusted "system glue" component within the STF, ArbOS is responsible for:

1. Managing network resources​

It allocates and tracks the resources needed to execute transactions on the child chain.

2. Block production​

ArbOS processes incoming sequencer data batches to produce child chain blocks, ensuring the state is updated correctly.

3. Cross-chain messaging​

It facilitates communication between the parent and child chains, supporting functionalities like Ether and token deposits and withdrawals.

4. Enhanced EVM execution​

ArbOS runs its instrumented Geth instance to execute smart contracts, incorporating additional logic specific to the child chain environment.

5. Stylus-specific tasks in ArbOS​

ArbOS manages host I/O calls, memory operations, and execution context for Stylus transactions, ensuring efficient and deterministic processing with the WASM runtime.

By offloading high-cost tasks from the parent chain, ArbOS enables them to be executed quickly and cost-effectively on the child chain. This design reduces computational and storage costs and offers significant flexibility, allowing the child chain code to evolve or be customized more easily than in a parent-chain-enforced architecture.

While Ethereum's STF provides a secure, deterministic basis for state updates, Arbitrum's Nitro stack builds on this foundation with key modifications — ranging from dual gas accounting to cross-chain messaging — to optimize performance and flexibility. These innovations are realized through minimal yet strategic modifications to Geth, integrated seamlessly with ArbOS, forming the "geth sandwich."

With the introduction of Stylus, Arbitrum extends its execution model beyond the EVM, enabling high-performance WASM-based smart contracts. This integration introduces additional modifications to Geth, ensuring compatibility with Stylus transactions while preserving Ethereum-like execution guarantees. These changes include handling Stylus-specific transaction types and ensuring smooth interaction between the EVM and WASM environments.

In the following section, we'll dive deep into these modifications, exploring how Nitro leverages 'Geth at the core' and the custom enhancements provided by ArbOS to deliver an advanced, high-performance STF. Stylus-specific tasks within ArbOS are covered separately to highlight its role in managing execution, host I/O, and memory operations.

How precompiles work​

ArbOS implements precompiles using a Solidity interface paired with a Golang backend, connected through runtime reflection for type safety and ABI conformance. For the full technical details of the precompile architecture, see ArbOS technical reference. For a complete list of precompiles, refer to the precompile references.

Messages​

An L1IncomingMessage represents an incoming sequencer message. A message includes one or more user transactions depending on load and is made into a unique child chain block. The child chain block may include additional system transactions while processing the message's user transactions. However, ultimately, the relationship is still bijective: for every L1IncomingMessage, there is a child chain block with a unique child chain block hash, and for every child chain block after chain initialization, there was an L1IncomingMessage that made it. A sequencer batch may contain more than one L1IncomingMessage.

Retryables​

A retryable is a special message type for creating an atomic parent-to-child chain; for details, see parent-to-child chain messaging.

ArbOS state​

ArbOS's state is managed through ArbosState objects that abstract over the underlying key-value storage. Most of this state supports precompiles. Key components include blockhashes (recent parent chain block hashes), l1PricingState (parent chain fee tracking and batch poster reimbursement), and l2PricingState (child chain gas pricing via dual gas pools).

For the full technical details of ArbOS state, pricing internals, and the per-block gas limit mechanism, see the ArbOS technical reference. For parent chain pricing specifics, see Parent chain pricing.

Gas and fees​

ArbOS manages child chain gas pricing and fee collection for both child chain execution costs and parent chain data posting costs. The child chain uses a dynamic basefee mechanism with multiple gas targets over different time windows to handle demand spikes while maintaining long-term chain capacity. Transactions pay fees to both the batch poster (for parent chain data costs) and the network (for child chain execution).

For a comprehensive explanation of how gas pricing works, including:

  • Child chain basefee calculation and gas targets
  • Parent chain calldata pricing and batch poster reimbursement
  • Fee estimation and collection mechanisms
  • The gas target's role in validator security

See Gas and Fees. For detailed mathematical formulas and parent chain pricing internals, see Parent chain pricing.

Stylus-specific differences​

Stylus extends ArbOS to support WASM-based smart contracts alongside the EVM. When a transaction targets a Stylus contract, ArbOS routes execution to the WASM runtime, which uses host I/O calls for blockchain state access instead of EVM opcodes. Stylus contracts use a multi-dimensional gas model based on Ink units, with LRU caching to minimize execution overhead.

For the full technical details of Stylus execution flow, caching, gas pricing, and Go-WASI integration, see the ArbOS technical reference.