config-l1-challenge-period
Configuring the challenge period on L1 means deploying your Arbitrum chain as a Layer 2 Rollup that settles directly to Ethereum, where assertions are posted, challenged, and confirmed using L1 contracts and block numbers. A Layer 2 configuration contrasts with a Layer 3 configuration, where the chain settles to Arbitrum and the challenge period runs on the L2. The default challenge period is 6.4 days, but it can be customized via the confirmPeriodBlocks parameter during deployment or post-deployment by the chain owner. The chain owner can reset the confirmPeriodBlocks, using rollupAdmin.setConfirmPeriodBlocks.
| Feature | Pros | Cons |
|---|---|---|
| Security | - Directly inherits Ethereum's full L1 security model, with no dependency on an intermediary L2's assumptions or potential vulnerabilities. - Challenges are resolved on the most decentralized and tested layer, reducing risks from L2-specific issues | - No significant cons here; L1 offers the highest baseline security, though custom shorter periods could theoretically reduce time for fraud detection. |
| Costs | - Avoids compounded fees from an L2 intermediary, potentially simplifying long-term economics for high-security needs | - Higher operational costs: Posting transaction blobs and resolving challenges uses expensive L1 gas (e.g., calldata fees on Ethereum are higher) - Less suitable for cost-sensitive applications, as L2 settlement can reduce data availability and posting expenses. |
| Finality & Withdrawal times | Faster overall finality for withdrawals directly to L1: ~7 days default challenge period - Simpler path to Ethereum mainnet settlement, beneficial for users needing quick access to L1 liquidity | - Still requires a ~7 day wait for standard withdrawals, which can feel slow compared to zero-knowledge Rollups or optimized AnyTrust setups - No benefit from L2's faster block times for intra-layer operations |
| Customization & Flexibility | - The challenge period is easily customizable (e.g., via Rollup.setConfirmPeriodBlocks) to balance security and speed, using reliable L1 block timing - Suitable for applications requiring high-value transfers or strict L1 alignment | - Less flexibility in leveraging L2-specific features (e.g., cheaper data availability committees in AnyTrust mode) - Customization options are similar to L2 settlement, but adjustments may incur higher gas costs on L1 |
| Overall usability | - Ideal for projects prioritizing maximum decentralization and direct Ethereum integration, avoiding "security stacking" risks | - May limit scalability for high-throughput apps due to L1 congestion or costs; L3 setups on L2 can offer better performance for specialized use cases |