Block Production & Finality
How blocks are produced on Mandala (on demand), the three flavors of finality, and the 7-day withdrawal window.
Two facts about Mandala that surprise builders coming from other L2s.
- Mandala produces blocks on demand. There is no fixed block time.
- There are three different "finalities" for a Mandala transaction. Which one matters depends on what you are doing.
On-demand block production
The sequencer waits for at least one transaction. When a transaction arrives, the sequencer orders it and emits a block. If the chain is idle, no blocks are produced. Period.
This is unusual. Ethereum has a 12-second slot, Arbitrum One has a ~250ms block, most L2s have something between. Mandala has none of those; the chain's clock is event-driven.
The reasoning is straightforward: empty blocks cost L1 gas (the batch poster has to advance the chain) and provide no value. Skipping them keeps the chain cheap when traffic is low.
For builders, three implications.
Do not assume regular block intervals
Mandala's block.timestamp can move forward by seconds, minutes, or hours between two consecutive blocks, depending on traffic. If your contract uses block.timestamp for accounting, vesting, or rate-limiting, validate the math under irregular intervals. If your contract uses block.number as a clock, it will count more slowly than you expect.
- Time-based logic should use
block.timestamp, notblock.number. Block numbers do not advance at a fixed rate. - Per-block accounting (e.g. "X tokens minted per block") behaves differently than on a fixed-slot chain. Convert to per-second accounting where you can.
- On-chain randomness from
block.timestamporblockhashis even less reliable than usual. Use a verifiable randomness source (Chainlink VRF, on-chain commit-reveal) for any application that depends on randomness.
Three flavors of finality
Mandala has three confirmation states, each with a different guarantee and a different latency.
| Stage | Latency | What it guarantees | Who provides the guarantee |
|---|---|---|---|
| Soft (sequencer) | Sub-second | The sequencer has ordered your tx and will include it in the next block. | The sequencer's word. |
| Hard (L1 batch posted) | Minutes | Your tx is in a batch posted to L1. It cannot be re-ordered. | Ethereum's L1 finality. |
| Final (challenge window passed) | ~7 days | The state root containing your tx has cleared the dispute window. Trust-minimized. | The Arbitrum dispute game on L1. |
For most application use cases (token transfers, dApp interactions), soft confirmation is enough. The sequencer cannot include transactions you did not sign and cannot censor without giving you the L1 force-inclusion escape hatch.
For on-chain composability between Mandala and other L2s or rollups, soft confirmation is also usually enough, because the other chain trusts Mandala's sequencer in the same way Mandala does.
For withdrawals to Ethereum, you need final confirmation: the L1 Bridge contract enforces the challenge window before releasing funds.
Visual timeline
The 7-day final-confirmation window is not a Mandala parameter; it is the standard Arbitrum optimistic-rollup challenge period. The Trust & Security Model page covers why it is what it is.
Withdrawals back to Ethereum
To withdraw KPG or ETH back to Ethereum:
- Submit an L2-to-L1 message via the L2
ArbSysprecompile at0x0000000000000000000000000000000000000064. The Arbitrum Portal does this for you. - The message is included in a batch and posted to L1.
- After the ~7-day challenge window, you (or anyone) can call
executeTransactionon the L1 Bridge contract to release the funds.
Step 3 is permissionless. Anyone can pay the L1 gas to execute your withdrawal once the challenge window has passed.
If you need a faster withdrawal, third-party fast bridges sell the wait time at a discount. They are not part of the Mandala protocol; they take the credit risk on themselves.
Read more on Arbitrum
Arbitrum's L1-to-L2 and L2-to-L1 messaging covers the messaging protocol, including how ArbSys interacts with the L1 outbox.