diff --git a/docs/launch-arbitrum-chain/02-configure-your-chain/common-configurations/04-stake-and-validator-configurations.mdx b/docs/launch-arbitrum-chain/02-configure-your-chain/common-configurations/04-stake-and-validator-configurations.mdx
index db32663f22..8ec44c8492 100644
--- a/docs/launch-arbitrum-chain/02-configure-your-chain/common-configurations/04-stake-and-validator-configurations.mdx
+++ b/docs/launch-arbitrum-chain/02-configure-your-chain/common-configurations/04-stake-and-validator-configurations.mdx
@@ -367,7 +367,7 @@ await walletClient.writeContract({
- Setting `loserStakeEscrow` to a burn address increases the cost of failed challenges, enhancing security.
- Deploy on testnets first; mainnet deployments are costly and permanent.
-## Validator configurations and how to setup them up
+## Validator configurations and how to set them up
Validators are configured during chain deployment and can be run post-launch. Arbitrum chains support permissioned validators, that can be added to an allowlist.
diff --git a/docs/launch-arbitrum-chain/02-configure-your-chain/common-configurations/bold-adoption-for-arbitrum-chains.mdx b/docs/launch-arbitrum-chain/02-configure-your-chain/common-configurations/bold-adoption-for-arbitrum-chains.mdx
index fdff9d0b5f..d20e06ed28 100644
--- a/docs/launch-arbitrum-chain/02-configure-your-chain/common-configurations/bold-adoption-for-arbitrum-chains.mdx
+++ b/docs/launch-arbitrum-chain/02-configure-your-chain/common-configurations/bold-adoption-for-arbitrum-chains.mdx
@@ -17,12 +17,12 @@ This document is currently in **public preview** and may change significantly as
:::
-## Launch details and key dates
+## Launch status and key dates
- **Status:** Generally available for L2s and launched on Arbitrum One and Arbitrum Nova. _BoLD for L3s are not yet supported at the time of writing._
- **Arbitrum Sepolia** Dec 11, 2024
-- **Arbitrum One** 09:00 ET (GMT-5) on Feb 12, 2025{' '}
-- **Arbitrum Nova** 09:00 ET (GMT-5) on Feb 12, 2025{' '}
+- **Arbitrum One** 09:00 ET (GMT-5) on Feb 12, 2025{' '}
+- **Arbitrum Nova** 09:00 ET (GMT-5) on Feb 12, 2025{' '}
### tldr;
diff --git a/docs/launch-arbitrum-chain/02-configure-your-chain/common-configurations/timeboost-for-arbitrum-chains.mdx b/docs/launch-arbitrum-chain/02-configure-your-chain/common-configurations/timeboost-for-arbitrum-chains.mdx
index 82d4b988f2..c6dd6327fd 100644
--- a/docs/launch-arbitrum-chain/02-configure-your-chain/common-configurations/timeboost-for-arbitrum-chains.mdx
+++ b/docs/launch-arbitrum-chain/02-configure-your-chain/common-configurations/timeboost-for-arbitrum-chains.mdx
@@ -22,7 +22,7 @@ AEP fees will apply here in the future.
-## Launch details and key dates
+## Launch status and key dates
- **Status:** Alpha - not formally supported yet for deployments on Arbitrum chains
- **Arbitrum Sepolia**: Feb 12, 2025
diff --git a/docs/launch-arbitrum-chain/03-deploy-an-arbitrum-chain/02-deploying-an-arbitrum-chain.md b/docs/launch-arbitrum-chain/03-deploy-an-arbitrum-chain/02-deploying-an-arbitrum-chain.mdx
similarity index 99%
rename from docs/launch-arbitrum-chain/03-deploy-an-arbitrum-chain/02-deploying-an-arbitrum-chain.md
rename to docs/launch-arbitrum-chain/03-deploy-an-arbitrum-chain/02-deploying-an-arbitrum-chain.mdx
index 79e52923fa..6b4ad8c9a9 100644
--- a/docs/launch-arbitrum-chain/03-deploy-an-arbitrum-chain/02-deploying-an-arbitrum-chain.md
+++ b/docs/launch-arbitrum-chain/03-deploy-an-arbitrum-chain/02-deploying-an-arbitrum-chain.mdx
@@ -22,7 +22,7 @@ You can explore the code of these contracts in the [nitro-contracts repository](
Upon deployment, an Arbitrum chain can be configured as a Rollup or AnyTrust chain, and use `ETH` or any standard `ERC-20 `token as its gas token.
-This page explains how to deploy an Arbitrum chain using the Arbitrum Chain SDK. See the [Overview](/launch-arbitrum-chain/arbitrum-chain-sdk-introduction.md) for an introduction to the process of creating and configuring an Arbitrum chain.
+This page explains how to deploy an Arbitrum chain using the Arbitrum Chain SDK. See the [Overview](/launch-arbitrum-chain/arbitrum-chain-sdk-introduction.mdx) for an introduction to the process of creating and configuring an Arbitrum chain.
:::info About custom gas token Arbitrum chains
diff --git a/docs/launch-arbitrum-chain/03-deploy-an-arbitrum-chain/05-deploying-token-bridge.md b/docs/launch-arbitrum-chain/03-deploy-an-arbitrum-chain/05-deploying-token-bridge.mdx
similarity index 99%
rename from docs/launch-arbitrum-chain/03-deploy-an-arbitrum-chain/05-deploying-token-bridge.md
rename to docs/launch-arbitrum-chain/03-deploy-an-arbitrum-chain/05-deploying-token-bridge.mdx
index 152039a4c5..152749ced5 100644
--- a/docs/launch-arbitrum-chain/03-deploy-an-arbitrum-chain/05-deploying-token-bridge.md
+++ b/docs/launch-arbitrum-chain/03-deploy-an-arbitrum-chain/05-deploying-token-bridge.mdx
@@ -16,11 +16,11 @@ The Arbitrum stack doesn't natively support specific token bridging standards at
The token bridge architecture includes contracts deployed on the parent and child chains. These entities communicate via the retryable ticket protocol, ensuring efficient and secure interactions.
-Once you have deployed your Arbitrum chain and have a node running, you can deploy a token bridge for your chain. See the [Overview](/launch-arbitrum-chain/arbitrum-chain-sdk-introduction.md) for an introduction to creating and configuring an Arbitrum chain.
+Once you have deployed your Arbitrum chain and have a node running, you can deploy a token bridge for your chain. See the [Overview](/launch-arbitrum-chain/arbitrum-chain-sdk-introduction.mdx) for an introduction to creating and configuring an Arbitrum chain.
Before reading this guide, we recommend:
-- Becoming familiar with the general process of creating new chains explained in [How to deploy an Arbitrum chain](/launch-arbitrum-chain/03-deploy-an-arbitrum-chain/02-deploying-an-arbitrum-chain.md)
+- Becoming familiar with the general process of creating new chains explained in [How to deploy an Arbitrum chain](/launch-arbitrum-chain/03-deploy-an-arbitrum-chain/02-deploying-an-arbitrum-chain.mdx)
- Learning about the canonical token bridge in the [Token bridging](/build-decentralized-apps/token-bridging/01-overview.mdx) section
## Parameters used when deploying a token bridge
diff --git a/docs/launch-arbitrum-chain/03-deploy-an-arbitrum-chain/07-canonical-factory-contracts.mdx b/docs/launch-arbitrum-chain/03-deploy-an-arbitrum-chain/07-canonical-factory-contracts.mdx
index b9c54a2172..bcb710626d 100644
--- a/docs/launch-arbitrum-chain/03-deploy-an-arbitrum-chain/07-canonical-factory-contracts.mdx
+++ b/docs/launch-arbitrum-chain/03-deploy-an-arbitrum-chain/07-canonical-factory-contracts.mdx
@@ -14,7 +14,7 @@ This page describes the benefits of using these canonical factory contracts and
:::info Use the Arbitrum Chain SDK
-You can use these contracts to create Arbitrum chains. However, it is strongly recommended to go through the [Chain SDK](/launch-arbitrum-chain/arbitrum-chain-sdk-introduction.md) to interact with them. Doing so prevents misconfiguring parameters and using appropriate defaults for most of them.
+You can use these contracts to create Arbitrum chains. However, it is strongly recommended to go through the [Chain SDK](/launch-arbitrum-chain/arbitrum-chain-sdk-introduction.mdx) to interact with them. Doing so prevents misconfiguring parameters and using appropriate defaults for most of them.
:::
diff --git a/docs/launch-arbitrum-chain/05-customize-your-chain/customize-arbos.mdx b/docs/launch-arbitrum-chain/05-customize-your-chain/customize-arbos.mdx
index 697205e4c3..bf9f83eb1d 100644
--- a/docs/launch-arbitrum-chain/05-customize-your-chain/customize-arbos.mdx
+++ b/docs/launch-arbitrum-chain/05-customize-your-chain/customize-arbos.mdx
@@ -109,7 +109,7 @@ It should be noted that when you initialize the state (initial code is in [custo
Also, please make sure your program cannot call the `state.SetNewMyNumber` or other functions may change the value of `myNumber` before ArbOS v21.
To prevent this, if you are using an external call to the precompile contract to change the value, you can refer to [point 1](./customize-arbos.mdx#1-add-a-new-method-to-existing-precompile-on-a-specific-arbos-version) or
[point 2](./customize-arbos.mdx#2-create-a-new-precompile-contract-on-a-specific-arbos-version) to set the activation time of the precompile contract method.
-If your nitro code needs to call this method to change the state, you can continue reading [point 4](./customize-arbos.mdx#4-any-changes-in-the-stf-logic-that-will-affect-the-final-execution-result).
+If your nitro code needs to call this method to change the state, you can continue reading [Step 4](./customize-arbos.mdx#4-any-changes-in-the-stf-logic-that-will-affect-the-final-execution-result-arbos-version-control).
### 4. Any changes in the STF logic that will affect the final execution result (ArbOS version control)
diff --git a/docs/launch-arbitrum-chain/06-third-party-integrations/01-bridged-usdc-standard.md b/docs/launch-arbitrum-chain/06-third-party-integrations/01-bridged-usdc-standard.md
index 7abebc25d7..8da7f9ae59 100644
--- a/docs/launch-arbitrum-chain/06-third-party-integrations/01-bridged-usdc-standard.md
+++ b/docs/launch-arbitrum-chain/06-third-party-integrations/01-bridged-usdc-standard.md
@@ -41,7 +41,7 @@ Other requirements:
- It is assumed there is already a `USDC` token deployed and used on the parent chain.
- Also, it is assumed that the standard Arbitrum chain ownership system is used, i.e., `UpgradeExecutor` is the owner of the `ownable` contracts, and there is an EOA or multi-sig that has the executor role on the `UpgradeExecutor`.
-- Refer to the [token bridge overview page](/launch-arbitrum-chain/03-deploy-an-arbitrum-chain/05-deploying-token-bridge.md) for more information about the token bridge design and operational dynamics. You can learn more in our [overview of gateways operating models](/build-decentralized-apps/token-bridging/03-token-bridge-erc20.mdx#other-flavors-of-gateways).
+- Refer to the [token bridge overview page](/launch-arbitrum-chain/03-deploy-an-arbitrum-chain/05-deploying-token-bridge.mdx) for more information about the token bridge design and operational dynamics. You can learn more in our [overview of gateways operating models](/build-decentralized-apps/token-bridging/03-token-bridge-erc20.mdx#other-flavors-of-gateways).
## Deployment steps
diff --git a/docs/launch-arbitrum-chain/arbitrum-chain-sdk-introduction.md b/docs/launch-arbitrum-chain/arbitrum-chain-sdk-introduction.mdx
similarity index 97%
rename from docs/launch-arbitrum-chain/arbitrum-chain-sdk-introduction.md
rename to docs/launch-arbitrum-chain/arbitrum-chain-sdk-introduction.mdx
index 3968221953..bd02815841 100644
--- a/docs/launch-arbitrum-chain/arbitrum-chain-sdk-introduction.md
+++ b/docs/launch-arbitrum-chain/arbitrum-chain-sdk-introduction.mdx
@@ -38,7 +38,7 @@ Additionally, Arbitrum chains can be configured to use `ETH` or any standard `ER
## 2. Deploy your chain
-After selecting a chain type, follow [this guide](/launch-arbitrum-chain/03-deploy-an-arbitrum-chain/02-deploying-an-arbitrum-chain.md) to deploy your chain using the Chain SDK.
+After selecting a chain type, follow [this guide](/launch-arbitrum-chain/03-deploy-an-arbitrum-chain/02-deploying-an-arbitrum-chain.mdx) to deploy your chain using the Chain SDK.
## 3. Configure your Arbitrum chain's node
@@ -46,4 +46,4 @@ Once the chain is deployed, you'll need to generate the configuration to run its
## 4. Deploy your Arbitrum chain's token bridge
-Your Arbitrum chain's token bridge contracts allow `ERC-20` tokens to move between your Arbitrum chain and its underlying parent chain. Read [Deploy your Arbitrum chain's token bridge](/launch-arbitrum-chain/03-deploy-an-arbitrum-chain/05-deploying-token-bridge.md) to learn how to set up your bridge.
+Your Arbitrum chain's token bridge contracts allow `ERC-20` tokens to move between your Arbitrum chain and its underlying parent chain. Read [Deploy your Arbitrum chain's token bridge](/launch-arbitrum-chain/03-deploy-an-arbitrum-chain/05-deploying-token-bridge.mdx) to learn how to set up your bridge.
diff --git a/docs/launch-arbitrum-chain/features/advanced/choose-arbos-version.mdx b/docs/launch-arbitrum-chain/features/advanced/choose-arbos-version.mdx
index 24041677db..a63ac528d5 100644
--- a/docs/launch-arbitrum-chain/features/advanced/choose-arbos-version.mdx
+++ b/docs/launch-arbitrum-chain/features/advanced/choose-arbos-version.mdx
@@ -12,7 +12,7 @@ Customizing the ArbOS version involves modify
- **ArbOS**: The hypervisor-like layer in Nitro that manages the chain's execution environment, including STF, precompiles, state, and upgrades. Versions are numbered (e.g., starting from 20 in increments of 10 for canonical releases like "Atlas"), with names taken from planetary moons (e.g., "Atlas" for 20, "Bianca" for 30). Custom versions can use intermediates (e.g., 21-29) for project-specific forks.
- **State Transition Function (STF)**: The deterministic process for computing new states from transactions. Customizations here (e.g., new logic or states) often necessitate an ArbOS upgrade to integrate changes into the replay binary used for fraud proofs.
-- **WASM Module Root**: A 32-byte hash of the STF's implementation (e.g., 0x8b104a2e80ac6165dc58b9048de12f301d70b02a0ab51396c22b4b4b802a16a4 for ArbOS 20). Customizations require updating this on the parent chain for compatibility validation.
+- **WASM Module Root**: A 32-byte hash of the STF's implementation (e.g., `0x8b104a2e80ac6165dc58b9048de12f301d70b02a0ab51396c22b4b4b802a16a4` for ArbOS 20). Customizations require updating this on the parent chain for compatibility validation.
- **Backward compatibility**: Changes must preserve old block results; new features activate only post-upgrade via version gates (e.g., `if state.ArbOSVersion() >= targetVersion`). For more details, please refer to [ArbOS version control](/launch-arbitrum-chain/05-customize-your-chain/customize-arbos.mdx#4-any-changes-in-the-stf-logic-that-will-affect-the-final-execution-result-arbos-version-control).
### Compatibility
diff --git a/docs/launch-arbitrum-chain/features/advanced/choose-chain-precompiles.mdx b/docs/launch-arbitrum-chain/features/advanced/choose-chain-precompiles.mdx
index 50e80cdfe8..7c227794f3 100644
--- a/docs/launch-arbitrum-chain/features/advanced/choose-chain-precompiles.mdx
+++ b/docs/launch-arbitrum-chain/features/advanced/choose-chain-precompiles.mdx
@@ -6,7 +6,7 @@ sme: jason-w123
content_type: configuration
---
-Customizing your chain's precompiles refers to modifying or extending the built-in, system-level smart contract-like functions (precompiles) that provide efficient access to chain-specific operations, such as interacting with the parent chain (L1 or L2), querying state, or performing computations. Precompiles are hardcoded at specific addresses (e.g., 0x64 for `ArbSys`) and executed outside the EVM bytecode level for performance. They inherit Ethereum's standard precompiles (e.g., for hashing or elliptic curves) while adding Arbitrum-specific ones (e.g., `ArbAddressTable` for address compression).
+Customizing your chain's precompiles refers to modifying or extending the built-in, system-level smart contract-like functions (precompiles) that provide efficient access to chain-specific operations, such as interacting with the parent chain (L1/L2), querying state, or performing computations. Precompiles are hardcoded at specific addresses (e.g., 0x64 for `ArbSys`) and executed outside the EVM bytecode level for performance. They inherit Ethereum's standard precompiles (e.g., for hashing or elliptic curves) while adding Arbitrum-specific ones (e.g., `ArbAddressTable` for address compression).
Customization allows developers to add new methods, events, gas logic, or state interactions tailored to the chain's needs, such as app-specific utilities or optimizations. This flexibility is an advanced feature requiring modifications to the Nitro software stack, enabling deeper chain personalization beyond defaults like custom gas tokens or DA modes.
diff --git a/docs/launch-arbitrum-chain/features/advanced/choose-custom-delay-inbox-finality.mdx b/docs/launch-arbitrum-chain/features/advanced/choose-custom-delay-inbox-finality.mdx
index 10691a9881..cde14900e6 100644
--- a/docs/launch-arbitrum-chain/features/advanced/choose-custom-delay-inbox-finality.mdx
+++ b/docs/launch-arbitrum-chain/features/advanced/choose-custom-delay-inbox-finality.mdx
@@ -71,3 +71,7 @@ This affects only incoming (parent-to-child) Delayed Inbox flows; outgoing (chil
- **DACert-optimized**: On Nova settlement with default flags, finality ties to DACert posting (~tens of minutes); configuring low-distance speeds reduces this to ~1 minute for gaming apps needing quick asset transfers.
This feature underscores Arbitrum's modularity for performance tuning while inheriting parent security. For implementation, refer to the latest Nitro sequencer docs or your RaaS; a [list of RaaSes is on the Third-party providers page](/launch-arbitrum-chain/06-third-party-integrations/02-third-party-providers.md#rollup-as-a-service-raas-providers).
+
+## How to configure
+
+For instructions on how to configure the delayed inbox finality, refer to the [How to configure Delayed Inbox finality](/launch-arbitrum-chain/02-configure-your-chain/common-configurations/arbitrum-chain-finality.mdx) page.
diff --git a/docs/launch-arbitrum-chain/features/common/configure-aep/configure-aep-fees.mdx b/docs/launch-arbitrum-chain/features/common/configure-aep/configure-aep-fees.mdx
index aa3e6d722b..aed2babc94 100644
--- a/docs/launch-arbitrum-chain/features/common/configure-aep/configure-aep-fees.mdx
+++ b/docs/launch-arbitrum-chain/features/common/configure-aep/configure-aep-fees.mdx
@@ -43,6 +43,18 @@ The configuration ensures compliance with the AEP terms, streamlines reporting,
## How to configure
+:::warning Caution
+
+This is an abbreviated set of instructions on how to configure AEP fees. For a complete set of instructions refer to the [AEP fee router introduction](/launch-arbitrum-chain/02-configure-your-chain/advanced-configurations/aep-fee-router/01-aep-fee-router-introduction.mdx).
+
+Additional resources:
+
+- [Setup AEP fee router](/launch-arbitrum-chain/02-configure-your-chain/advanced-configurations/aep-fee-router/02-set-up-aep-fee-router.mdx)
+- [Calculate AEP fees](/launch-arbitrum-chain/02-configure-your-chain/advanced-configurations/aep-fee-router/03-calculate-aep-fees.mdx)
+- [Reporting on AEP fees](/launch-arbitrum-chain/02-configure-your-chain/advanced-configurations/aep-fee-router/04-reporting-on-fees.mdx)
+
+:::
+
1. **Calculate net revenue**: Use tools or scripts to track total fees minus settlement costs (e.g., via on-chain queries or off-chain monitoring). For custom tokens, deploy a pricer contract to value fees in `ETH` equivalents.
2. **Deploy fee router**: Use the Arbitrum Chain SDK script (e.g., [`aep-fee-router`](https://github.com/OffchainLabs/arbitrum-chain-sdk/tree/main/examples/setup-aep-fee-router)) to deploy contracts like RewardDistributor on your chain. Set it as a fee collector (e.g., for surplus fees via `ArbOwner` precompile).
3. **Route and bridge fees**: Configure the router to send the 10% share to Ethereum (e.g., via native bridges), then deposit to the DAO address on Arbitrum One. Use functions like `RewardDistributor.distributeRewards` for periodic transfers.
diff --git a/docs/launch-arbitrum-chain/features/common/data-availability/choose-alt-da.mdx b/docs/launch-arbitrum-chain/features/common/data-availability/choose-alt-da.mdx
index 4898a46548..c412592d91 100644
--- a/docs/launch-arbitrum-chain/features/common/data-availability/choose-alt-da.mdx
+++ b/docs/launch-arbitrum-chain/features/common/data-availability/choose-alt-da.mdx
@@ -20,7 +20,7 @@ Selecting Alt-DA means integrating an external provider into your Arbitrum chain
## How it differs:
- From **Rollup**: Alt-DA moves data off Ethereum entirely, avoiding L1 gas costs but potentially sacrificing some decentralization if the external layer has different security properties (e.g., Celestia uses data availability sampling for efficiency).
-- From **AnyTrust**: While both are off-chain, AnyTrust uses Arbitrum's own DAC (permissioned and integrated), whereas Alt-DA leverages independent networks with their own consensus and incentives, offering more modularity but requiring additional setup and trust in the provider's model.
+- From **AnyTrust**: While both are offchain, AnyTrust uses Arbitrum's own DAC (permissioned and integrated), whereas Alt-DA leverages independent networks with their own consensus and incentives, offering more modularity but requiring additional setup and trust in the provider's model.
@@ -35,4 +35,4 @@ Arbitrum chains supports integrations with several Alt-DA solutions, including:
- **EigenDA (via EigenLayer)**: Leverages restaking for secure, decentralized DA.
- For a list of Alt-DA providers, refer to the [Third-party providers page](launch-arbitrum-chain/06-third-party-integrations/02-third-party-providers.md#data-availability-providers-for-anytrust-chains)
-This option reflects the growing trend toward modular blockchain architectures, where DA handling is separate to scale ecosystems like Arbitrum without compromising core security. For implementation, refer to the docs or your RaaS; a [list of RaaSes is on the Third-party providers page](/launch-arbitrum-chain/06-third-party-integrations/02-third-party-providers.md#rollup-as-a-service-raas-providers).
+This option reflects the growing trend toward modular blockchain architectures, where DA handling is separate to scale ecosystems like Arbitrum without compromising core security.
diff --git a/docs/launch-arbitrum-chain/features/common/data-availability/choose-anytrust.mdx b/docs/launch-arbitrum-chain/features/common/data-availability/choose-anytrust.mdx
index a51bd84421..6b8cda637f 100644
--- a/docs/launch-arbitrum-chain/features/common/data-availability/choose-anytrust.mdx
+++ b/docs/launch-arbitrum-chain/features/common/data-availability/choose-anytrust.mdx
@@ -26,4 +26,28 @@ It's ideal for use cases where ultra-low fees are a priority over Ethereum's ful
-This option reflects the growing trend toward modular blockchain architectures, where DA handling is separate to scale ecosystems like Arbitrum without compromising core security. For implementation, refer to the docs or your RaaS; a [list of RaaSes is on the Third-party providers page](/launch-arbitrum-chain/06-third-party-integrations/02-third-party-providers.md#rollup-as-a-service-RaaS-providers).
+This option reflects the growing trend toward modular blockchain architectures, where DA handling is separate to scale ecosystems like Arbitrum without compromising core security. For implementation, refer to the docs or your RaaS; a [list of RaaSes is on the Third-party providers page](/launch-arbitrum-chain/06-third-party-integrations/02-third-party-providers.md#rollup-as-a-service-raas-providers).
+
+## How to configure
+
+To configure AnyTrust this is a pre-deployment decision. You must choose whether or not you will be leveraging AnyTrust prior to deploying your chain.
+
+When calling the `prepareChainConfig` function, it will create a `chainConfig` structure. It sets the appropriate default values for most of the parameters, which allows you to override any of the defaults.
+
+Below is an example of how to use `prepareChainConfig` to set the chain configuration for an AnyTrust chain (`chainId` and `InitialChainOwner` are not set by default):
+
+```typescript
+import { prepareChainConfig } from '@arbitrum/chain-sdk';
+
+const chainConfig = prepareChainConfig({
+ chainId: 123_456,
+ arbitrum: {
+ InitialChainOwner: 0x123...890,
+ // The following parameter determines whether this is an AnyTrust chain
+ // AnyTrust = true, Rollup = false
+ DataAvailabilityCommittee: true,
+ },
+});
+```
+
+For complete deployment instructions refer to the [Deploy an Arbitrum chain](/launch-arbitrum-chain/03-deploy-an-arbitrum-chain/02-deploying-an-arbitrum-chain.mdx) page.
diff --git a/docs/launch-arbitrum-chain/features/common/data-availability/choose-rollup.mdx b/docs/launch-arbitrum-chain/features/common/data-availability/choose-rollup.mdx
index d9851933f4..045cee9d29 100644
--- a/docs/launch-arbitrum-chain/features/common/data-availability/choose-rollup.mdx
+++ b/docs/launch-arbitrum-chain/features/common/data-availability/choose-rollup.mdx
@@ -27,3 +27,9 @@ This flexibility allows developers to tailor chains to specific needs while buil
For implementation, refer to the docs or your RaaS; a [list of RaaSes is on the Third-party providers page](/launch-arbitrum-chain/06-third-party-integrations/02-third-party-providers.md#rollup-as-a-service-raas-providers).
+
+## Configuration
+
+For an example standard (`ETH` as gas token) configuration of deploying an Arbitrum chain as a Rollup, refer to the [`create-rollup-eth`](https://github.com/OffchainLabs/arbitrum-chain-sdk/tree/main/examples/create-rollup-eth) example in the Arbitrum Chain SDK repo.
+
+To use a custom gas token you can read more on the [Use a custom gas token Rollup](/launch-arbitrum-chain/02-configure-your-chain/common-configurations/02-use-a-custom-gas-token-rollup.mdx) page, or you can view an example deployment configuration in the Arbitrum Chain SDK repo, [`create-rollup-custom-fee-token`](https://github.com/OffchainLabs/arbitrum-chain-sdk/tree/main/examples/create-rollup-custom-fee-token).
diff --git a/docs/launch-arbitrum-chain/features/common/gas-and-fees/choose-custom-gas-token.mdx b/docs/launch-arbitrum-chain/features/common/gas-and-fees/choose-custom-gas-token.mdx
index d264cf2637..e10c375a3b 100644
--- a/docs/launch-arbitrum-chain/features/common/gas-and-fees/choose-custom-gas-token.mdx
+++ b/docs/launch-arbitrum-chain/features/common/gas-and-fees/choose-custom-gas-token.mdx
@@ -35,3 +35,10 @@ Choosing a custom gas token refers to configuring the chain to use a specific `E
- Project-native tokens in gaming or DeFi appchains, where users pay fees in the ecosystem's token for seamless integration.
For implementation, refer to the docs or your RaaS; a [list of RaaSes is on the Third-party providers page](/launch-arbitrum-chain/06-third-party-integrations/02-third-party-providers.md#rollup-as-a-service-raas-providers).
+
+## How to configure
+
+For detailed instructions on how to configure a custom gas token, there are several resources available depending on your data availability type:
+
+- **AnyTrust**: [How to configure a custom gas token for your AnyTrust Arbitrum chain](/launch-arbitrum-chain/02-configure-your-chain/common-configurations/01-use-a-custom-gas-token-anytrust.mdx)
+- **Rollup**: [How to configure a custom gas token for your Rollup Arbitrum chain](/launch-arbitrum-chain/02-configure-your-chain/common-configurations/02-use-a-custom-gas-token-rollup.mdx)
diff --git a/docs/launch-arbitrum-chain/features/common/gas-and-fees/choose-fee-rebates.mdx b/docs/launch-arbitrum-chain/features/common/gas-and-fees/choose-fee-rebates.mdx
index 62ab9f723f..cd38e6c35d 100644
--- a/docs/launch-arbitrum-chain/features/common/gas-and-fees/choose-fee-rebates.mdx
+++ b/docs/launch-arbitrum-chain/features/common/gas-and-fees/choose-fee-rebates.mdx
@@ -48,9 +48,9 @@ Configuration requires chain owner priv
## How to configure
-1. **Set fee collectors**: Use the `ArbOwner` and `ArbAggregator` precompile (0x70) to assign addresses for each fee type (e.g., `setInfraFeeAccount` for Orbit base fees). Collectors can be simple addresses or smart contracts.
+1. **Set fee collectors**: Use the `ArbOwner` and `ArbAggregator` precompile (`0x70`) to assign addresses for each fee type (e.g., `setInfraFeeAccount` for Orbit base fees). Collectors can be simple addresses or smart contracts.
2. **Deploy a distributor contract**: For rebates, deploy a contract like `RewardDistributor.sol` on the chain. Set recipients and proportions (e.g., 80% to treasury, 20% to user rebate pool using basis points).
-3. **Trigger distributions**: Call distributeRewards on the contract to execute rebates, specifying recipients and shares.
+3. **Trigger distributions**: Call `distributeRewards` on the contract to execute rebates, specifying recipients and shares.
- **Tools**: Use command-line (cast) or SDK extensions like `arbOwnerActions` for programmatic setup.
diff --git a/docs/launch-arbitrum-chain/features/common/mev/choose-timeboost.mdx b/docs/launch-arbitrum-chain/features/common/mev/choose-timeboost.mdx
index d10a78ec16..4e0eecbf11 100644
--- a/docs/launch-arbitrum-chain/features/common/mev/choose-timeboost.mdx
+++ b/docs/launch-arbitrum-chain/features/common/mev/choose-timeboost.mdx
@@ -23,7 +23,7 @@ It's ideal for DeFi-heavy chains with substantial MEV (e.g., arbitrage opportuni
## Compatibility
-Works with any Arbitrum chain (L2/L3), all DA modes (Rollup, AnyTrust, Alt-DA), gas tokens (native `ETH` or custom), and validation (BoLD or permissioned). Compatible with centralized or future decentralized sequencers; no prerequisites beyond a bid token and infrastructure. Not formally supported yet.
+Works with any Arbitrum chain (L2/L3), all DA modes (Rollup, AnyTrust, Alt-DA), gas tokens (native `ETH` or custom), and validation (BoLD or permissioned). Compatible with centralized or future decentralized sequencers; no prerequisites beyond a bid token and infrastructure. Not formally supported yet.
@@ -36,11 +36,17 @@ Works with any Arbitrum chain (validator (verifies bids) and auction server (resolves auctions) using the `autonomous-auctioneer` binary from Nitro (Docker or local build).
3. **Configure the sequencer**: Update node config to enable `timeboost` and `auctioneer` APIs, pointing to the contract and Redis.
-- Verify via logs (e.g., "New express lane auction round") and test bids/submissions.
+- Verify via logs (e.g., `New express lane auction round`) and test bids/submissions.
- Post-enable, adjust parameters like round duration (60s default) or delay (200ms) via owner privileges.
This feature enhances Arbitrum's modularity for MEV-aware chains but requires careful evaluation. For details, consult the official docs, or your RaaS; a [list of RaaSes is on the Third-party providers page](/launch-arbitrum-chain/06-third-party-integrations/02-third-party-providers.md#rollup-as-a-service-raas-providers).
diff --git a/docs/launch-arbitrum-chain/features/common/ux/choose-fast-withdrawals.mdx b/docs/launch-arbitrum-chain/features/common/ux/choose-fast-withdrawals.mdx
index 70aecb1dc8..4feafac38e 100644
--- a/docs/launch-arbitrum-chain/features/common/ux/choose-fast-withdrawals.mdx
+++ b/docs/launch-arbitrum-chain/features/common/ux/choose-fast-withdrawals.mdx
@@ -42,12 +42,16 @@ From a UX perspective, enabling fast withdrawals transforms slow, multi-day proc
## How to configure
+:::warning Caution
+
+This is an abbreviated set of instructions on how to configure fast withdrawals. For a more in-depth set of instructions, including potential impacts, it is recommended to refer to the [Configure fast withdrawals](/launch-arbitrum-chain/02-configure-your-chain/advanced-configurations/01-fast-withdrawals.mdx) page.
+
+:::
+
1. **Upgrade contracts and nodes**: Ensure nitro-contracts v2.1.0+ (update `RollupAdminLogic` and `RollupUserLogic`) and node software to nitro v3.1.2+. Use the Arbitrum chain versioner script to check and upgrade.
2. **Run configuration scripts**: Use the Arbitrum Chain SDK (e.g., setup-fast-withdrawal example) or Orbit actions repo (e.g., fast-confirm script with Foundry's cast CLI) to create a Safe multisig for the committee, add validators to the allowlist, set the Safe as the `anytrustFastConfirmer`, and optionally adjust `minimumAssertionPeriod` (defaults to 75 blocks ~15 minutes, measured in the first non-Arbitrum ancestor chain's blocks).
3. **Configure nodes**:
- - batch Poster: Set `--node.batch-poster.max-delay` to match the
- assertion
- period (e.g., 15m).
+ - Batch Poster: Set `--node.batch-poster.max-delay` to match the assertion period (e.g., 15m).
- Validators (BoLD mode): Enable `--node.bold.enable-fast-confirmation=true` and set `--node.bold.assertion-posting-interval` to the period.
- Validators (pre-BoLD): Similar flags like `--node.staker.enable-fast-confirmation=true` and `--node.staker.make-assertion-interval`.
diff --git a/docs/launch-arbitrum-chain/features/common/validation-and-security/choose-bold.mdx b/docs/launch-arbitrum-chain/features/common/validation-and-security/choose-bold.mdx
index 9626a91bf6..2ddd3bf462 100644
--- a/docs/launch-arbitrum-chain/features/common/validation-and-security/choose-bold.mdx
+++ b/docs/launch-arbitrum-chain/features/common/validation-and-security/choose-bold.mdx
@@ -20,7 +20,7 @@ For the chain, it resets the challenge clock for in-flight withdrawals (adding u
## Compatibility with chain types
-BoLD is required for Rollup mode with custom gas tokens posting to Ethereum (to handle conversions securely). It's compatible with AnyTrust and Alt-DA modes but focuses on L2/L3 chains settling on Ethereum for maximum security. Post-upgrade, the chain uses BoLD for all new assertions.
+BoLD is required for Rollup mode with custom gas tokens posting to Ethereum (to handle conversions securely). It's compatible with AnyTrust and Alt-DA modes but focuses on L2/L3 chains settling on Ethereum for maximum security. Post-upgrade, the chain uses BoLD for all new assertions.
## How it differs from legacy protocols
@@ -36,4 +36,20 @@ BoLD is required for Rollup mode with custom gas tokens posting to Ethereum (to
- **Arbitrum One and Nova**: Upgraded to BoLD for permissionless validation, allowing public testnets and community validators to secure the chains.
- **Custom Arbitrum chains**: Projects like gaming or DeFi appchains choose BoLD to enable decentralized validation, especially when using Rollup mode with Ethereum settlement for high-security needs.
+:::info Still unsure?
+
+The [BoLD adoption for Arbitrum chains](/launch-arbitrum-chain/02-configure-your-chain/common-configurations/bold-adoption-for-arbitrum-chains.mdx) page has a lot more detailed specifics about the inner workings of BoLD if you are unsure about whether to adopt it for your chain.
+
+Additional resources are:
+
+- [BoLD gentle introduction](/how-arbitrum-works/bold/gentle-introduction.mdx)
+- [BoLD technical deep dive](/how-arbitrum-works/bold/bold-technical-deep-dive.mdx)
+- [BoLD economics of disputes](/how-arbitrum-works/bold/bold-economics-of-disputes.mdx)
+
+:::
+
+## How to configure
+
+For specfics on configuration refer to the [How to adopt Arbitrum BoLD](/launch-arbitrum-chain/02-configure-your-chain/common-configurations/bold-adoption-for-arbitrum-chains.mdx#how-to-adopt-arbitrum-bold) section on that page.
+
This upgrade aligns with Arbitrum's modular ethos, bolstering trust-minimization while inheriting Ethereum's security. For implementation, refer to the official docs, or your RaaS; a [list of RaaSes is on the Third-party providers page](/launch-arbitrum-chain/06-third-party-integrations/02-third-party-providers.md#rollup-as-a-service-raas-providers).
diff --git a/docs/launch-arbitrum-chain/features/common/validation-and-security/choose-challenge-period.mdx b/docs/launch-arbitrum-chain/features/common/validation-and-security/choose-challenge-period.mdx
index b00e37d227..6b630f2608 100644
--- a/docs/launch-arbitrum-chain/features/common/validation-and-security/choose-challenge-period.mdx
+++ b/docs/launch-arbitrum-chain/features/common/validation-and-security/choose-challenge-period.mdx
@@ -26,7 +26,7 @@ It's set by the chain owner and can be chosen based on the application's risk to
- **With DA modes**: Fully compatible across Rollup (full on-chain DA), AnyTrust (DAC-based), and Alt-DA (e.g., Celestia). In AnyTrust, fast withdrawals can reduce the effective period to 15 minutes by leveraging the DAC for rapid verification, bypassing traditional delays.
- **With gas tokens**: No direct impact; works with native `ETH` or custom `ERC-20`s, as the period governs validation timing rather than fee mechanics.
-- **With validation (e.g., BoLD)**: Integrates with BoLD's permissionless disputes, where the period sets the initial challenge window, but BoLD bounds total delays to at most two periods (~12.8 days max on Ethereum) during active disputes, mitigating delay attacks.
+- **With validation** (e.g., **BoLD)**: Integrates with BoLD's permissionless disputes, where the period sets the initial challenge window, but BoLD bounds total delays to at most two periods (~12.8 days max on Ethereum) during active disputes, mitigating delay attacks.
## Pros
@@ -51,4 +51,8 @@ It's set by the chain owner and can be chosen based on the application's risk to
- **During deployment**: Specified in the `RollupCreator` configuration (e.g., via the Arbitrum Chain SDK deployment portal or scripts like `createRollup.ts`). For example, set `confirmPeriodBlocks` to 30,000 for ~4.5 days.
- **Post-deployment**: Dynamically updated via owner-privileged contract calls, such as `Rollup.setConfirmPeriodBlocks(newValue)` for the primary period or `Rollup.setExtraChallengeTimeBlocks(newExtraTimeBlocks)` for the extra buffer (e.g., using tools like cast for onchain transactions).
+## How to configure
+
+For instructions on how to configure the challenge period, refer to the [Customize the challenge period](/launch-arbitrum-chain/02-configure-your-chain/common-configurations/03-customizable-challenge-period.mdx) page.
+
This parameter underscores Arbitrum's modular design, allowing chains to fine-tune validation without compromising core fraud-proof security. For implementation, refer to the official docs, or your RaaS; a [list of RaaSes is on the Third-party providers page](/launch-arbitrum-chain/06-third-party-integrations/02-third-party-providers.md#rollup-as-a-service-raas-providers).
diff --git a/docs/launch-arbitrum-chain/features/common/validation-and-security/choose-permissioned-validators.mdx b/docs/launch-arbitrum-chain/features/common/validation-and-security/choose-permissioned-validators.mdx
index 79bf234714..65a8275f16 100644
--- a/docs/launch-arbitrum-chain/features/common/validation-and-security/choose-permissioned-validators.mdx
+++ b/docs/launch-arbitrum-chain/features/common/validation-and-security/choose-permissioned-validators.mdx
@@ -45,3 +45,7 @@ Works with L2/L3 Arbitrum chains se
- **Custom Arbitrum chains**: Early-stage gaming or enterprise L3s might choose permissioned to limit access to internal teams, avoiding the economic overhead of BoLD while testing.
This option balances security with practicality in Arbitrum's ecosystem, but for maximum trust-minimization, BoLD's permissionless model is recommended for mature chains. Consult the latest official docs, or your RaaS; a [list of RaaSes is on the Third-party providers page](/launch-arbitrum-chain/06-third-party-integrations/02-third-party-providers.md#rollup-as-a-service-raas-providers).
+
+## How to configure
+
+For detailed instructions on how to configure validators, refer to the [Validator configurations and how to setup them up](/launch-arbitrum-chain/02-configure-your-chain/common-configurations/04-stake-and-validator-configurations.mdx#validator-configurations-and-how-to-set-them-up) section on the [Stake and Validator configurations](/launch-arbitrum-chain/02-configure-your-chain/common-configurations/04-stake-and-validator-configurations.mdx) page.
diff --git a/docs/launch-arbitrum-chain/how-tos/arbitrum-chain-sdk-preparing-node-config.md b/docs/launch-arbitrum-chain/how-tos/arbitrum-chain-sdk-preparing-node-config.md
index 9fd93051aa..b7641eac9a 100644
--- a/docs/launch-arbitrum-chain/how-tos/arbitrum-chain-sdk-preparing-node-config.md
+++ b/docs/launch-arbitrum-chain/how-tos/arbitrum-chain-sdk-preparing-node-config.md
@@ -12,9 +12,9 @@ import RaaSNotice from '../partials/_raas-providers-notice.mdx';
-Once you have successfully deployed and initialized the Arbitrum chain core contracts, the next step is to configure and run an Arbitrum Nitro node for your chain. You configure a Nitro node using a `JSON` file describing all the parameters for the node, including settings for the batch poster, validator, and the chain itself. See the [Overview](/launch-arbitrum-chain/arbitrum-chain-sdk-introduction.md) for an introduction to creating and configuring an Arbitrum chain.
+Once you have successfully deployed and initialized the Arbitrum chain core contracts, the next step is to configure and run an Arbitrum Nitro node for your chain. You configure a Nitro node using a `JSON` file describing all the parameters for the node, including settings for the batch poster, validator, and the chain itself. See the [Overview](/launch-arbitrum-chain/arbitrum-chain-sdk-introduction.mdx) for an introduction to creating and configuring an Arbitrum chain.
-Before reading this guide, we recommend that you're familiar with the general process for creating new chains explained in the introduction and the first section of [How to deploy an Arbitrum chain](/launch-arbitrum-chain/03-deploy-an-arbitrum-chain/02-deploying-an-arbitrum-chain.md).
+Before reading this guide, we recommend that you're familiar with the general process for creating new chains explained in the introduction and the first section of [How to deploy an Arbitrum chain](/launch-arbitrum-chain/03-deploy-an-arbitrum-chain/02-deploying-an-arbitrum-chain.mdx).
## Structure of a Nitro node configuration JSON object