How Mandala is Built
Mandala's stack on top of Arbitrum Orbit: sequencer, batch poster, validators, DAC, and the L1 contracts.
This page is the mechanical view: what is actually running and where it lives. Trade-offs and trust assumptions live on the Trust & Security Model page; the fee and finality details have their own pages. This one just lays out the parts.
The components
Mandala is an Arbitrum Orbit chain in AnyTrust mode. Five components, in the order a transaction touches them.
| Component | What it does | Run by |
|---|---|---|
| Sequencer | Receives user transactions, orders them, produces L2 blocks. | Mandala team and AltLayer (centralized today). |
| Execution engine (Nitro) | Runs the EVM, with ArbOS40 on top. | Same as the sequencer. |
| Batch poster | Bundles sequenced transactions and posts them to L1: header to SequencerInbox, full data to the DAC. | Mandala team and AltLayer. |
| Data Availability Committee (DAC) | Stores batch data and signs availability certificates that the batch poster includes in the L1 header. | Mandala team and AltLayer. |
| Validators | Watch L2 state, post assertions to the L1 Rollup contract, dispute bad assertions. | Mandala team. |
ArbOS40 and Nitro v3.9.5-66e42c4 run the show. These are the same execution layers that power Arbitrum One; Mandala does not fork or modify them.
The transaction lifecycle
A transaction's path from user to finalized state, end to end.
A few things to flag from the diagram. The sequencer's "soft confirmation" is not a finality guarantee; it is the sequencer saying "I have ordered your transaction and will include it in the next block." The hard guarantee comes when the batch header lands on L1. The trust-minimized guarantee comes after the challenge window. All three are covered on the Block Production & Finality page.
Where things live on L1
These addresses pin the chain. Anything claiming to be "Mandala on Ethereum" should match these.
| Contract | Address |
|---|---|
| Rollup | 0x218D35154D1efEBFC46D64451C9495288219b275 |
| SequencerInbox | 0x325acf46079d3f750D5D7E6182E094B1fD0AC2F4 |
| Inbox (delayed) | 0x62DfD05c460C7E55DA85B39EaD3eBc6e0CcdD0d5 |
| Outbox | 0x004eF39261cee56409Dbd26040a33Eca8326490C |
| Bridge | 0x65DB181838b53f32428ce106fA5355b7e4806b79 |
The full surface, including the ERC-20 gateway/router contracts, lives in Network Details.
Withdrawals out of Mandala go through the L1 Bridge after the challenge window. Force-inclusion of L2 transactions, when the sequencer is unresponsive, starts at the L1 Inbox; after a delay anyone can finalize the inclusion via the SequencerInbox.
On the L2 side, the standard Arbitrum precompile ArbSys lives at 0x0000000000000000000000000000000000000064. That is what your contracts call to initiate L2-to-L1 messages.
What is standard Orbit, and what isn't
The chain is standard Orbit + AnyTrust. Mandala's customization is in the parameters, not the protocol.
- Native gas token: KPG instead of ETH.
- DA mode: AnyTrust (instead of full rollup mode).
- Block production: on demand (no empty blocks).
- Sequencer + DAC operators: Mandala + AltLayer.
Everything else (Nitro, ArbOS40, fraud proofs, retryable tickets, the L1 inbox model) is upstream Arbitrum protocol. The Arbitrum docs are the authoritative reference for those.
Read more on Arbitrum
Arbitrum's How Arbitrum works: a gentle introduction walks through the Nitro architecture and the L1 inbox model in depth.