Architecture

Nitro's architecture answers one question elegantly: how can the same code that executes the chain also be the code that adjudicates disputes? The answer is a Geth-derived execution core compiled to two targets — native Go (for the node) and WASM (for the L1 fraud-proof VM).

The nitro-node binary

One Go program contains all the off-chain roles; configuration decides which ones run in a given process:

• Sequencer — receives user transactions, orders them, produces blocks, and publishes batches to L1. Maintains the fast confirmation feed.
• Validator — independently verifies the chain by replaying blocks from L1 data, and can stake on assertions.
• Staker — the on-chain actor that posts assertions to the RollupCore contracts and participates in the challenge game (a staker is a validator with skin in the game).
• Relayer — forwards L2-to-L1 messages to L1 and L1-to-L2 messages into the inbox, and serves block data to other nodes.
• Full node — the read/serve role; exposes Ethereum JSON-RPC and the feed to wallets and dapps.

The execution core: Geth + ArbOS

Under the hood the chain state is managed by a fork of go-ethereum. Nitro's insight is to treat the OS the way a real computer treats its OS: ArbOS runs as a program inside the state, with a reserved address range (the precompile range), and mediates everything the EVM cannot do natively — receiving L1 messages, accounting L1 data fees, and bridging out.

• Geth core — transactions, blocks, the EVM, state, receipts, and the JSON-RPC server are all stock go-ethereum, so Nitro inherits Ethereum's correctness and tooling.
• ArbOS — a layer compiled into the state that (1) converts L1 inbox messages into L2 transactions, (2) charges L1 data fees based on how many bytes a transaction occupies in a batch, (3) tracks retryable tickets, and (4) emits the L2-to-L1 outbox messages.
• Precompiles — Nitro exposes ArbSys, ArbGasInfo, ArbToken, ArbOwner, and ArbRetryableTx at deterministic addresses (see the API Reference module).

The L1 contracts

• Bridge.sol — the central repository of message trees (inbox and outbox accumulators) and the delay before delayed messages are force-included.
• Inbox.sol — the entry point for L1 → L2 messages (deposits and retryables).
• Outbox.sol — the redemption point for L2 → L1 messages once they're finalized.
• SequencerInbox.sol — where the sequencer's ordered batches land, with the delayed-inbox safety valve.
• RollupCore.sol — the rollup state machine: assertions (state commitments) and the staking game.
• ChallengeManager.sol — orchestrates the bisection of an assertion dispute into a one-step WASM proof.

How the pieces talk

1. Users send transactions to the sequencer, which orders and executes them, publishing blocks to the feed.
2. The sequencer batches the blocks and posts them to SequencerInbox on L1 (via a relayer process), guaranteeing data availability.
3. Validators reconstruct the chain from L1 and verify the sequencer's work; stakers commit to state assertions on L1.
4. Deposits enter via Inbox; withdrawals exit via Outbox after the challenge window.
5. Disagreements are resolved by ChallengeManager running the Geth-core-as-WASM one step at a time.

Design principles

• One codebase, two targets. Execution and dispute resolution use the same logic — nothing "special" is written for the fraud proof.
• Compatibility first. EVM and Ethereum tooling work unchanged; the chain reads like Ethereum to wallets.
• Trust minimized where it matters. Sequencing is centralized for UX; validity and settlement are open and verifiable.