You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Copy file name to clipboardExpand all lines: docs/launch-arbitrum-chain/02-configure-your-chain/advanced-configurations/02-bold.mdx
+4-3Lines changed: 4 additions & 3 deletions
Display the source diff
Display the rich diff
Original file line number
Diff line number
Diff line change
@@ -12,13 +12,14 @@ content_type: how-to
12
12
protocol used by Arbitrum chains today, like Arbitrum One. This page is intended for Arbitrum chain owners/operators
13
13
and assumes knowledge of Arbitrum BoLD is and experience upgrading an Arbitrum chain's Rollup contracts.
14
14
This page assumes you have read and followed the guide on [How to upgrade to BoLD](../../04-maintain-your-chain/05-upgrade-to-bold.mdx)
15
-
and our guide on [BoLD adoption for Arbitrum chains](../../bold-adoption-for-arbitrum-chains.mdx). Please
16
-
read these two guides first before proceeding with changing any of the parameters relating to BoLD below.
15
+
and our guide on [BoLD adoption for Arbitrum chains](/launch-arbitrum-chain/02-configure-your-chain/common-configurations/bold-adoption-for-arbitrum-chains.mdx).
16
+
Please read these two guides first before proceeding with changing any of the parameters relating to
17
+
BoLD below.
17
18
18
19
To read more about Arbitrum BoLD, please refer to the [Gentle Introduction for BoLD](../../../how-arbitrum-works/bold/gentle-introduction.mdx).
19
20
20
21
:::caution
21
-
As mentioned in our guide on [BoLD adoption for Arbitrum chains](../../bold-adoption-for-arbitrum-chains.mdx), the recommendation is that Arbitrum 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](../../../how-arbitrum-works/03-sequencer.mdx#censorship-timeout) feature be kept disabled.
22
+
As mentioned in our guide on [BoLD adoption for Arbitrum chains](/launch-arbitrum-chain/02-configure-your-chain/common-configurations/bold-adoption-for-arbitrum-chains.mdx), the recommendation is that Arbitrum 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](../../../how-arbitrum-works/03-sequencer.mdx#censorship-timeout) feature be kept disabled.
Copy file name to clipboardExpand all lines: docs/launch-arbitrum-chain/02-configure-your-chain/common-configurations/02-use-a-custom-gas-token-rollup.mdx
+1-1Lines changed: 1 addition & 1 deletion
Display the source diff
Display the rich diff
Original file line number
Diff line number
Diff line change
@@ -606,7 +606,7 @@ Here are the steps you should take to deploy your Arbitrum chain with a custom g
606
606
-`FEE_TOKEN_ADDRESS` = your `ERC-20` gas token
607
607
-`FEE_TOKEN_PRICER_ADDRESS` = your deployed pricer
608
608
-`ROLLUP_CREATOR_ADDRESS` = the rollup creator contract on L1
609
-
-`STAKE_TOKEN_ADDRESS` = token used for staking (see [BoLD docs](/launch-arbitrum-chain/bold-adoption-for-arbitrum-chains.mdx#use-of-your-projects-native-token-as-the-bonding-asset-to-secure-the-chain) for more details)
609
+
-`STAKE_TOKEN_ADDRESS` = token used for staking (see [BoLD docs](/launch-arbitrum-chain/02-configure-your-chain/common-configurations/bold-adoption-for-arbitrum-chains.mdx#use-of-your-projects-native-token-as-the-bonding-asset-to-secure-the-chain) for more details)
610
610
611
611
The script will deploy and initialize the Rollup accordingly.
Copy file name to clipboardExpand all lines: docs/launch-arbitrum-chain/02-configure-your-chain/common-configurations/timeboost-for-arbitrum-chains.mdx
+4-4Lines changed: 4 additions & 4 deletions
Display the source diff
Display the rich diff
Original file line number
Diff line number
Diff line change
@@ -37,8 +37,8 @@ some of the available Maximum Extractable Value (MEV) on their blockchain and re
37
37
spamming, in exchange for a small impact on user response times (despite block times not changing). It
38
38
is therefore recommended that chains only consider deploying and enabling Timeboost if there is substantial
39
39
DeFi and related MEV activity (e.g. liquidations, arbitrage, backrunning) on the chain. Please read the
40
-
[gentle introduction to Timeboost](../how-arbitrum-works/timeboost/gentle-introduction.mdx) to learn
41
-
more about how Timeboost works.
40
+
[gentle introduction to Timeboost](/how-arbitrum-works/timeboost/gentle-introduction.mdx) to learn more
41
+
about how Timeboost works.
42
42
43
43
As with all features on the Arbitrum stack, Arbitrum chains can adopt Timeboost at their own discretion and on their own timeline. To deploy and enable Arbitrum Timeboost on your chain, please refer to this guide on how to [deploy and configure Timeboost](/launch-arbitrum-chain/02-configure-your-chain/advanced-configurations/04-deploy-timeboost.mdx).
44
44
@@ -50,7 +50,7 @@ Again, Arbitrum chains can adopt Timeboost at their discretion and on their time
50
50
51
51
## Benefits of adopting Timeboost
52
52
53
-
Timeboost enables a chain owner to capture a portion of the available MEV on their blockchain, reducing latency-related spam while preserving the built-in protections and UX benefits that Arbitrum users have come to know and enjoy. A more in-depth overview of the benefits of Timeboost is explored in the [gentle introduction to Timeboost](../how-arbitrum-works/timeboost/gentle-introduction.mdx), and also a paper on how Timeboost is more profitable for arbitrageurs compared to other forms of MEV capture, like Priority Gas Auctions (PGA) [here](https://arxiv.org/abs/2410.10797).
53
+
Timeboost enables a chain owner to capture a portion of the available MEV on their blockchain, reducing latency-related spam while preserving the built-in protections and UX benefits that Arbitrum users have come to know and enjoy. A more in-depth overview of the benefits of Timeboost is explored in the [gentle introduction to Timeboost](/how-arbitrum-works/timeboost/gentle-introduction.mdx), and also a paper on how Timeboost is more profitable for arbitrageurs compared to other forms of MEV capture, like Priority Gas Auctions (PGA) [here](https://arxiv.org/abs/2410.10797).
54
54
55
55
#### Fair(er) MEV capture
56
56
@@ -82,7 +82,7 @@ Often times, the cost required to set up, configure, and maintain the infrastruc
82
82
83
83
#### User experience
84
84
85
-
As explained in the [gentle introduction to Timeboost](../how-arbitrum-works/timeboost/gentle-introduction.mdx), the Timeboost express lane time advantage is implemented by imposing an artificial delay (default: `200ms`) on all non-express lane transactions whenever there is an express lane controller for a round (default: `1 minute`). While Timeboost does not change the default Arbitrum blocktimes (default: `250ms`), this artificial delay _does_ mean that the average response time for a user in the non-express lane is the sum of the artificial delay and the block time of the chain. Note that this artificial delay is only applied when there is an express lane controller for a round, meaning there is no change in user experience if nobody is using Timeboost, even though it is enabled (for the duration of that round).
85
+
As explained in the [gentle introduction to Timeboost](/how-arbitrum-works/timeboost/gentle-introduction.mdx), the Timeboost express lane time advantage is implemented by imposing an artificial delay (default: `200ms`) on all non-express lane transactions whenever there is an express lane controller for a round (default: `1 minute`). While Timeboost does not change the default Arbitrum blocktimes (default: `250ms`), this artificial delay _does_ mean that the average response time for a user in the non-express lane is the sum of the artificial delay and the block time of the chain. Note that this artificial delay is only applied when there is an express lane controller for a round, meaning there is no change in user experience if nobody is using Timeboost, even though it is enabled (for the duration of that round).
Copy file name to clipboardExpand all lines: docs/partials/_bold-config-params.mdx
+1-1Lines changed: 1 addition & 1 deletion
Display the source diff
Display the rich diff
Original file line number
Diff line number
Diff line change
@@ -12,7 +12,7 @@
12
12
|`chainId`| Your chain's ID | Your chain's ID |
13
13
|`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 |
14
14
|`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 |
15
-
|`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](../launch-arbitrum-chain/bold-adoption-for-arbitrum-chains.mdx).|`false`|
15
+
|`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](/launch-arbitrum-chain/02-configure-your-chain/common-configurations/bold-adoption-for-arbitrum-chains.mdx). |`false`|
16
16
|`blockLeafSize`| Maximum number of blocks between assertions. It is not recommended to change this value. | 2^26 |
17
17
|`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 |
18
18
|`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 |
0 commit comments