BoLD configuration parameters

Arbitrum BoLD is the latest iteration of the Optimistic Rollup dispute protocol used by Arbitrum chains today, like Arbitrum One. This page is intended for Orbit chain owners/operators and assumes knowledge of Arbitrum BoLD is and experience upgrading an Arbitrum chain's Rollup contracts. This page assumes you have read and followed the guide on How to upgrade to BoLD and our guide on BoLD adoption for Orbit chains. Please read these two guides first before proceeding with changing any of the parameters relating to BoLD below.

To read more about Arbitrum BoLD, please refer to the Gentle Introduction for BoLD.

caution

As mentioned in our guide on BoLD adoption for Orbit chains, the recommendation is that Orbit chains keep validation permissioned by having disableValidatorWhitelist be false (which is the default) and by having a list of validators on the whitelist via the validators[] array. Furthermore, it is recommended that the Censorship Timeout feature be kept disabled.

Table of Arbitrum BoLD parameters

The following configuration parameters can be applied when deploying or managing your Orbit chain. For an example of a configuration, feel free to reference this sample configuration in our guide on how to upgrade your chain to use BoLD.

Parameter	Description	Recommended default
excessStakeReceiver	The address that confiscated bonds will be sent to. Bonds are confiscated from malicious actors who dispute and lose the interactive fraud proof game	The chain owner's address
challengeGracePeriodBlocks	Amount of time to wait before a challenge period formally expire to allow for the chain owner or security council to intervene to ensure correctness of an assertion	48 hours worth of Ethereum blocks for an L2 Arbitrum chain (settling to Ethereum) or an L3 Arbitrum chain settling to Arbitrum One or Arbitrum Nova. If the chain settles to a different type of parent chain, you must use its parent chain's block.number timing
confirmPeriodBlocks	The amount of time that an assertion must exist on the parent chain before it can be confirmed by the protocol, measured using the parent chain's block.number timing	7 days worth of Ethereum blocks for an L2 Arbitrum chain (settling to Ethereum) or an L3 Arbitrum chain settling to Arbitrum One or Arbitrum Nova. If the chain settles to a different type of parent chain, you must use its parent chain's block.number timing
challengePeriodBlocks	The amount of time that a layer zero edge (otherwise known as a root/refinement node) needs to have accumulated to be confirmed. Usually the same as the confirmPeriodBlocks, measured in the number of parent chain block.number timing	7 days worth of Ethereum blocks for an L2 Arbitrum chain (settling to Ethereum) or an L3 Arbitrum chain settling to Arbitrum One or Arbitrum Nova. If the chain settles to a different type of parent chain, you must use its parent chain's block.number timing
stakeToken	Address for the token, on the parent chain, to be used by a validator to become an assertion proposer	WETH
stakeAmt	The minimum amount of the stakeToken required for a validator to become an assertion proposer. Please consult the Economics of Disputes page to learn more about how to think about setting this value for your chain in a permissionless setting (not recommended)	1 WETH
miniStakeAmounts	An array of the required amounts of the stakeToken for each level of the interactive dispute game. There are three levels to BoLD where participants must dispute assertions down until there is only a single step of execution to prove on Ethereum (to determine a winner)	[0, 1, 1] WETH
chainId	Your chain's ID	Your chain's ID
minimumAssertionPeriod	The minimum amount of time that a validator must wait before posting a new assertion, measured using the parent chain's block.number timing	15 minutes worth of Ethereum blocks for an L2 Arbitrum chain (settling to Ethereum) or an L3 Arbitrum chain settling to Arbitrum One or Arbitrum Nova. If the chain settles to a different type of parent chain, you must use its parent chain's blocks in the calculation
validatorAfkBlocks	The validator whitelist is removed if this amount of time elapses and no assertions are confirmed by the protocol on the parent chain. This parameter is ignored if the disableValidatorWhitelist is true, indicating that there is no whitelist	28 days (4 weeks) worth of Ethereum blocks for an L2 Arbitrum chain (settling to Ethereum) or an L3 Arbitrum chain settling to Arbitrum One or Arbitrum Nova. If the chain settles to a different type of parent chain, you must use its parent chain's blocks in the calculation
disableValidatorWhitelist	Enables or disables the validator whitelist - effectively toggling between permissioned and permissionless BoLD. It is highly recommended that this value be set to false. More information can be found here.	false
blockLeafSize	Maximum number of blocks between assertions. It is not recommended to change this value.	2^26
bigStepLeafSize	Maximum number of steps in the "big step" level history committment. The product of bigStepLeafSize, smallStepLeafSize, and numBigStepLevel should equal to the maximum number of WAVM opcodes theoretically possible in the execution of an Arbitrum block, with a small buffer. It is not recommended to change this value.	2^19
smallStepLeafSize	Maximum number of steps in the "small step" level history committment. The product of bigStepLeafSize, smallStepLeafSize, and numBigStepLevel should equal to the maximum number of WAVM opcodes theoretically possible in the execution of an Arbitrum block, with a small buffer. It is not recommended to change this value.	2^23
numBigStepLevel	Number of "big step" levels. It is not recommended to change this value.	1
maxDataSize	Maximum size of data that can be posted onto the parent chain, in KB	117964 for L2s, and 104857 for L3s
isDelayBufferable	A parameter to enable or disable the delay buffer, otherwise known as the Censorship Timeout feature.	false
bufferConfig.max	The maximum amount of time that the delay buffer can be. More information on how the delay buffer value changes over time and how it is used to calculate the force inclusion window can be found here.	2^32 - note that this configuration value is measured using Ethereum blocks for an L2 Arbitrum chain (settling to Ethereum) or an L3 Arbitrum chain settling to Arbitrum One or Arbitrum Nova. If the chain settles to a different type of parent chain, you must use its parent chain's block.number timing. It is recommended that you set this value to be higher than the batch posting frequency of your chain and ideally higher than the bufferConfig.threshold of your chain.
bufferConfig.threshold	The minimum amount of time that the force inclusion window can be reduced to, in the case of prolonged sequencer censorship and/or unexpected sequencer outages. The delayBuffer, starting from bufferConfig.max, is decremented by the difference between a delayed message's delay beyond bufferConfig.threshold so it is important to set the threshold to some value greater than the regular batch posting frequency of your chain and also greater than delayBlocks on your chain	2^32 - note that this configuration value is measured using Ethereum blocks for an L2 Arbitrum chain (settling to Ethereum) or an L3 Arbitrum chain settling to Arbitrum One or Arbitrum Nova. If the chain settles to a different type of parent chain, you must use its parent chain's block.number timing. It is recommended that you set this value to be higher than batch posting frequency of your chain, but lower than the delayBlocks of your chain.
bufferConfig.replenishRateInBasis	The rate at which the delay buffer will replenish linearly	500 (or 5% replenishment rate), meaning that one minute will be replenished for every 20 minutes where there are no messages delayed beyond bufferConfig.threshold
validators	An array of addresses that are allowed to post assertions to the parent chain, when BoLD is in permissioned mode (i.e., when disableValidatorWhitelist is false)	The list of whitelisted validators allowed to progress the chain (by regularly posting assertions to the parent chain)