Skip to main content

State Transition Function

An Arbitrum node is a deterministic machine: feed it the same ordered inputs, and it will always produce the same outputs. The job of everything before the STF is to agree on exactly which inputs those are and in what order they should be.

How it works​

1. Two doors, one source of truth​

Inputs reach a node through two doors. The fast door is the Sequencer feed—a real-time broadcast of newly ordered messages, so nodes feel the chain advance within milliseconds. The slow, trustworthy door is Ethereum itself: the Sequencer periodically posts compressed batches to the parent-chain inbox, emitting a SequencerBatchDelivered event. When the two disagree, the feed yields—the parent chain is the canonical record (Ethereum for Arbitrum), and a node will reorg its optimistic feed-derived state to match what was actually settled on Ethereum.

2. The envelope (L1IncomingMessage)​

Whatever the door, every input lands as one L1IncomingMessage: a header plus an opaque L2msg payload. The header is the input surface the STF reads—what kind of message, who put it there, BlockNumber and Timestamp, the ordering/identity handle, and L1BaseFee (parent-chain gas price used). Determinism comes from this: the STF never asks the outside world for the time or the gas price—it only reads what is in the header.

3. One byte decides the path​

The header’s Kind routes the message. A handful of kinds are system messages minted by the protocol: Initialize (the genesis message that sets the chain ID and base fee), EthDeposit (native-token bridging), SubmitRetryable (the retryable-ticket mechanism behind robust L1→L2 messaging), and BatchPostingReport (which lets the STF charge the batch poster for the L1 data it consumes). The workhorse, though, is L2Message (kind 3)—the envelope for ordinary user activity.

4. The envelope inside the envelope​

Open an L2Message, and you’ll find a second type byte—the L2MessageKind. A single signed transaction (SignedTx), an unsigned EOA or contract call (UnsignedUserTx, ContractTx), or—most importantly—a Batch, which is simply a list of more L2 messages. This nesting is why the type space looks deceptively flat in summaries but is really two layers: an outer parent-chain framing and an inner transaction framing.

5. From batch to messages​

A batch posted to L1 isn’t a list of transactions; it’s a Brotli-compressed blob, or calldata. The inbox multiplexer inspects the leading header byte, decompresses, and pops out individual L1IncomingMessages one at a time—the same shape the feed delivers. By the time anything reaches the STF, both doors have converged on the identical stream of envelopes.

6. The unwrap​

Finally, ParseL2Transactions turns each envelope into the EVM transactions Geth will run: deposits become ArbitrumDepositTx, retryables become their submission transaction, batches recurse, and bookkeeping kinds like RollupEvent are acknowledged and skipped. What flows out is an ordered list of transactions—and that ordered list, derived deterministically from headers no node can fabricate, is the true input to Arbitrum’s State Transition Function.

Stylus-specific transaction processing​

A modified version of Geth that recognizes and processes Stylus transactions, ensuring proper inclusion in state transitions.

Execution in a WASM runtime​

Stylus transactions execute in ArbOS's WASM runtime instead of the EVM, enabling faster execution and more efficient computation.

Stylus gas accounting and pricing​

Unlike standard EVM transactions, Stylus transactions introduce new gas pricing models that account for factors such as opcode pricing, host I/O operations, and Ink usage costs.

Interoperability with the EVM​

Stylus contracts can interact with Solidity contracts, enabling hybrid applications that leverage EVM and WASM execution environments.

These Stylus-related changes aim to maintain compatibility with Ethereum’s execution model while introducing a more efficient, flexible, and scalable alternative for smart contract development.

The following sections cover STF inputs, node processing, and implementation rules, highlighting differences between Ethereum and Arbitrum, and Stylus execution environments. Stylus-specific execution tasks handled within ArbOS will be covered separately, focusing on host I/O operations, caching, and WASM memory management.