Configure a test Arbitrum chain
On a production Arbitrum chain, an assertion takes about a week to confirm (6.4 days). That delay is the security model working as intended, but it makes integration testing impractical. This page covers how to shorten it on a chain you do not need to secure. It also covers which parameters differ on a testnet.
Every value on this page trades security for speed. A chain configured this way offers no meaningful dispute window, so an incorrect assertion can be confirmed before anyone has time to dispute it — and if the validator allowlist is disabled, any address can trigger that confirmation. Use these settings only on chains that hold no value.
Fast withdrawals are a production feature that shortens confirmation on an AnyTrust chain by delegating confirmation to a committee, using the --node.bold.enable-fast-confirmation and --node.staker.enable-fast-confirmation flags. That is a deliberate trust assumption, configured separately, and it is not what this page describes. To learn how it works, see Fast withdrawals.
What actually gates confirmation speed
Two independent layers govern how quickly an assertion confirms, and lowering only one has no effect:
- Onchain parameters set the floor.
confirmPeriodBlocksdetermines how long an assertion must exist before the protocol confirms it, andminimumAssertionPerioddetermines how frequently assertions may be posted at all. No node setting can go below these. - Node intervals determine how promptly your validator acts within that floor. These are polling and cadence settings; they cannot shorten an onchain period.
The common mistake is lowering the node intervals alone, then concluding that the configuration did not work. If confirmPeriodBlocks still represents a week, confirmation still takes a week.
Onchain parameters
Most of these are set at deployment. As chain owner you can update confirmPeriodBlocks and minimumAssertionPeriod afterward through the Rollup admin interface, and on a legacy chain extraChallengeTimeBlocks as well. On a BoLD chain, challengePeriodBlocks is fixed when the challenge manager is deployed and challengeGracePeriodBlocks when the Rollup is initialized — neither has an owner setter, so plan them before you deploy. To learn what the production values are, see Challenge period and the BoLD parameter table.
Parameters that exist on both BoLD and legacy chains:
| Parameter | Production reference | For a test chain |
|---|---|---|
confirmPeriodBlocks | 45,818 blocks, about one week | Low enough that a test can wait it out |
minimumAssertionPeriod | 75 blocks, about 15 minutes | Must be below the posting interval you configure next |
BoLD chains only:
| Parameter | Production reference | For a test chain |
|---|---|---|
challengePeriodBlocks | Usually equal to confirmPeriodBlocks | Keep equal to confirmPeriodBlocks; set at challenge manager deployment |
challengeGracePeriodBlocks | 48 hours of Ethereum blocks | Can be reduced; it exists to give a security council time to intervene. Fixed at deployment |
Legacy (pre-BoLD) chains only:
| Parameter | For a test chain |
|---|---|
extraChallengeTimeBlocks | Can be reduced or set to 0 |
All block counts above are denominated in the parent chain's block.number. On an Arbitrum parent, block.number tracks a bounded estimate of the underlying Ethereum L1 block number — not the Arbitrum chain's own block height — so one unit is still roughly 12 seconds for a chain settling to Arbitrum One or Nova. Only when the parent's block.number is its native height (Ethereum itself, or a local devnet) does the parent's own block time apply. To learn more, see Block numbers and time.
The interaction between minimumAssertionPeriod and the posting interval is the one that catches people. The two use different units — the posting interval is a duration, while minimumAssertionPeriod counts parent chain block.number units (on an Arbitrum parent, that is the underlying L1 block number, roughly 12 seconds per unit — see the note above). The validator enforces the onchain minimum itself: before posting, it checks how many of those block units have elapsed since the parent assertion and waits (logging Need to wait N blocks before posting next assertion) instead of submitting a transaction that would revert. If you lower the posting interval without lowering minimumAssertionPeriod to match, assertions do not stop or revert — they simply keep posting at the onchain floor's cadence. Lowering both is what makes posting faster.
Node intervals
These are Nitro flags, set per validator. Lower them so your validator acts promptly inside the onchain floor you configured above.
| Flag | Default | Applies to | For a test chain |
|---|---|---|---|
--node.bold.assertion-posting-interval | 15m0s | BoLD staker | Lower it, keeping it above minimumAssertionPeriod |
--node.bold.assertion-scanning-interval | 1m0s | BoLD staker | Lower it to notice new assertions sooner |
--node.bold.assertion-confirming-interval | 1m0s | BoLD staker | Lower it to poll for confirmability more often |
--node.bold.minimum-gap-to-parent-assertion | 1m0s | BoLD staker | Lower it so consecutive assertions are not spaced out |
--node.staker.make-assertion-interval | 1h0m0s | Legacy staker | Lower it; no effect on BoLD chains |
--node.staker.staker-interval | 1m0s | Legacy staker | Lower it to check the Rollup status and act sooner |
--node.staker.confirmation-blocks | 12 | Legacy staker | Lower it, or 0 on a chain where you accept reorg risk |
Lowering the confirming interval makes the validator check more often. It does not make confirmation permissible sooner — that is governed by confirmPeriodBlocks, plus challengeGracePeriodBlocks after a challenge. To learn more about that distinction, see Assertion timing flags.
A worked example
Nitro's own test suite configures the legacy staker for maximum speed. These values come from TestL1ValidatorConfig in staker/legacy/staker.go:
| Setting | Test value | Default |
|---|---|---|
staker-interval | 10ms | 1m0s |
make-assertion-interval | -1000h | 1h0m0s |
confirmation-blocks | 0 | 12 |
The negative make-assertion-interval is intentional rather than a typo. The staker checks whether more than the configured interval has elapsed since the last assertion. A negative duration makes that check always pass, so the staker posts on every cycle without waiting.
Nitro defines no TestBoldConfig. On a BoLD chain, set the four --node.bold.* intervals individually rather than looking for a single test preset.
Why a test validator looks stuck when nothing is misconfigured
--node.bold.rpc-block-number defaults to finalized, and the symptom depends on what your parent chain does with finality:
- The parent chain never finalizes (common on local devnets). Requests for the
finalizedblock fail with an RPC error such asfinalized block not found, so the staker cannot initialize and the node fails startup witherror initializing staker: could not create assertion chain: .... The intervals never come into play. - Finality lags the tip. The validator reads a finalized view that trails recent activity. If the finalized head predates the Rollup contract's deployment, initialization fails with
no contract code at given address; once the deployment is finalized, the validator acts on a stale view and appears idle until finality catches up.
Both read like an interval problem and are not one. Check this before tuning anything. To learn more, see Parent chain read consistency.
On a test chain, latest is usually the right value; safe helps only if your parent chain actually advances it. Both accept reorg exposure that would be unacceptable in production.
Testnet chains
A chain settling to a public testnet such as Sepolia is not a local test chain. Its parent chain has real block times and real finality, so parent chain block counts convert the same way they do on mainnet, and a production confirmPeriodBlocks still means about a week.
If you want faster confirmation on a testnet-settled chain, you must lower the onchain parameters deliberately — settling to a testnet does not shorten them for you. Read the parameters from your Rollup contract rather than assuming they were reduced at deployment.