Trust & Security Model

This is the most important page in the Learn section. Read it carefully if you intend to deposit funds or build production applications on Mandala.

The three trust assumptions

Three groups of operators, three different failure modes, three different mitigations.

1. The sequencer

Mandala runs a single sequencer at address 0x445d701bd15c7207723e203a7f0cb850a5a39e60, operated by the Mandala team in coordination with AltLayer. This is consistent with how new Orbit chains launch.

A centralized sequencer cannot steal your funds. It cannot forge transactions on your behalf, and it cannot include transactions you did not sign. The worst it can do is censor: refuse to include your transaction, or order transactions in a way that disadvantages you.

If the sequencer goes down or starts censoring, you can submit your transaction directly to the L1 Inbox at 0x62DfD05c460C7E55DA85B39EaD3eBc6e0CcdD0d5. After a delay, anyone can finalize the inclusion via the L1 SequencerInbox at 0x325acf46079d3f750D5D7E6182E094B1fD0AC2F4, and the transaction lands on L2 whether or not the sequencer cooperates. Force-inclusion is the escape hatch and it works even if the sequencer is offline.

2. The Data Availability Committee (DAC)

Mandala uses AnyTrust DA. Transaction data is stored by the DAC, not by Ethereum. The DAC is currently operated by the Mandala team and AltLayer.

The AnyTrust assumption is that at least two members of the DAC remain honest and online. As long as that holds, anyone can retrieve transaction data from the DAC, the chain can be re-executed by independent observers, and validators can detect bad state assertions.

If the DAC fails (fewer than two members will serve data), the protocol falls back: the chain stops accepting new state assertions until the data becomes retrievable. The chain does not advance into a state nobody can verify. This is the AnyTrust safety property, enforced on L1.

What the DAC cannot do, even if every member colludes:

• Forge transactions or sign for users.
• Move funds.
• Finalize a state root that is not derived from posted batch data.

What the DAC can do if it misbehaves:

• Refuse to serve data, halting the chain's progress until governance can rotate the committee.

Members beyond the operating umbrella are TBC and will be listed here when published.

3. The validator set

Validators watch L2 execution and post state assertions to the L1 Rollup contract. If a validator posts a wrong assertion, any other validator can challenge it through the BoLD dispute game, and the wrong assertion is rejected on L1.

The validator set on Mandala is currently allowlisted to operators run by the Mandala team. The transition to a permissionless validator set follows the upstream Arbitrum BoLD timeline. This page will be updated when that state changes.

Withdrawal challenge window

Funds bridged from Mandala back to Ethereum take ~7 days to finalize. This is not a Mandala-specific choice; it is the standard Arbitrum optimistic-rollup challenge window. It is the time the system gives validators to dispute a bad state root before withdrawals release on L1.

For deposits (Ethereum → Mandala), there is no challenge window. Deposits finalize as soon as the L1 transaction confirms.

If you need faster withdrawals than 7 days, third-party bridges (fast bridges, intent-based bridges) can give you instant withdrawals at the cost of paying a fee to a liquidity provider. They are not part of Mandala's canonical bridge.

Failure modes, in one table