From 38cbb10a2c64292b360b130425321d3914750f05 Mon Sep 17 00:00:00 2001 From: Pete Date: Mon, 15 Dec 2025 08:31:16 -0600 Subject: [PATCH 01/25] Fixing link that is displayed incorrectly --- .../features/common/data-availability/choose-anytrust.mdx | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) 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..33e07746e3 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,4 @@ 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-providers). From f98b18882c613b74192b4c7fe969b7167e239765 Mon Sep 17 00:00:00 2001 From: Pete Date: Mon, 15 Dec 2025 08:38:45 -0600 Subject: [PATCH 02/25] adding examples --- .../features/common/data-availability/choose-rollup.mdx | 6 ++++++ 1 file changed, 6 insertions(+) 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..bde764f44c 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/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). From ac7aef9dd5ae49cd542bec517e1ced7d5a7d781d Mon Sep 17 00:00:00 2001 From: Pete Date: Mon, 15 Dec 2025 08:41:19 -0600 Subject: [PATCH 03/25] removing redudancy; typo --- .../features/common/data-availability/choose-alt-da.mdx | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) 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. From cdfc47f77e844bb816d5adc58b5b5fcc6125edd8 Mon Sep 17 00:00:00 2001 From: Pete Date: Mon, 15 Dec 2025 08:43:37 -0600 Subject: [PATCH 04/25] styling --- .../features/common/gas-and-fees/choose-fee-rebates.mdx | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) 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. From 24914187f37b492524b7923e0ee2e3835a5083e0 Mon Sep 17 00:00:00 2001 From: Pete Date: Mon, 15 Dec 2025 08:45:18 -0600 Subject: [PATCH 05/25] removing broken quicklook --- .../features/common/validation-and-security/choose-bold.mdx | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) 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..fd3f1c7c75 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 From 0416c6cc1042fe6d94ce5c48e4d9a1878115a3d8 Mon Sep 17 00:00:00 2001 From: Pete Date: Mon, 15 Dec 2025 08:47:29 -0600 Subject: [PATCH 06/25] styling --- .../common/validation-and-security/choose-challenge-period.mdx | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) 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..b2f074fccf 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 From dc689fe47ce1cadce05d12015b5e833642ea1c18 Mon Sep 17 00:00:00 2001 From: Pete Date: Mon, 15 Dec 2025 08:49:46 -0600 Subject: [PATCH 07/25] styling; link displaying incorrectly --- .../features/common/mev/choose-timeboost.mdx | 6 +++--- 1 file changed, 3 insertions(+), 3 deletions(-) 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..262eca92ad 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,11 @@ 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). From 2094358448c2f2fada87fd72037e3fa4f63fbaa1 Mon Sep 17 00:00:00 2001 From: Pete Date: Mon, 15 Dec 2025 08:52:07 -0600 Subject: [PATCH 08/25] styling --- .../features/advanced/choose-arbos-version.mdx | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) 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 From b41c83ecb9c97ec91541f76323f7a86f494dc835 Mon Sep 17 00:00:00 2001 From: Pete Date: Mon, 15 Dec 2025 09:42:27 -0600 Subject: [PATCH 09/25] converting to mdx --- .../02-deploying-an-arbitrum-chain.md | 321 ------------------ .../05-deploying-token-bridge.md | 286 ---------------- 2 files changed, 607 deletions(-) delete mode 100644 docs/launch-arbitrum-chain/03-deploy-an-arbitrum-chain/02-deploying-an-arbitrum-chain.md delete mode 100644 docs/launch-arbitrum-chain/03-deploy-an-arbitrum-chain/05-deploying-token-bridge.md 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.md deleted file mode 100644 index 79e52923fa..0000000000 --- a/docs/launch-arbitrum-chain/03-deploy-an-arbitrum-chain/02-deploying-an-arbitrum-chain.md +++ /dev/null @@ -1,321 +0,0 @@ ---- -title: 'How to deploy an Arbitrum chain using the Chain SDK' -description: 'How to deploy an Arbitrum chain using the Chain SDK ' -author: GreatSoshiant, jose-franco -sme: GreatSoshiant, jose-franco -target_audience: 'Developers deploying and maintaining Arbitrum chains.' -user_story: As a current or prospective Arbitrum chain deployer, I need to configure and deploy an Arbitrum chain. -content_type: how-to ---- - -import RaaSNotice from '../partials/_raas-providers-notice.mdx'; - - - -Creating a new Arbitrum chain involves deploying a set of contracts on your chain's parent chain. These contracts are: - -- **Bridge contracts**: Used to send cross-chain messages between the Arbitrum chain and its parent chain, including batches posted by the sequencer -- **Rollup contracts**: Used by validators to create and confirm assertions of the current state of the Arbitrum chain -- **Challenge protocol contracts**: Used by validators to dispute current assertions of the state of the chain, and ultimately resolve those disputes - -You can explore the code of these contracts in the [nitro-contracts repository](https://github.com/OffchainLabs/nitro-contracts). - -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. - -:::info About custom gas token Arbitrum chains - -Custom gas token Arbitrum chains let participants pay transaction fees in an `ERC-20` token instead of `ETH`. Standard `ERC-20` tokens can be used as gas tokens, while more complex tokens with additional functionality must fulfill [these requirements](/launch-arbitrum-chain/02-configure-your-chain/common-configurations/02-use-a-custom-gas-token-rollup.mdx#requirements-of-the-custom-gas-token) to be used as gas tokens. Remember that the `ERC-20` token to be used must be deployed on your chain's parent chain. - -::: - -## Parameters used when deploying a new chain - -Before we describe the process of creating a chain using the Chain SDK, let's see what configuration options we have available when creating a chain. - -Deploying a new Arbitrum chain is done through a [`RollupCreator`](/launch-arbitrum-chain/03-deploy-an-arbitrum-chain/07-canonical-factory-contracts.mdx) contract that processes the creation of the needed contracts and sends the initialization messages from the parent chain to the newly created Arbitrum chain. - -`RollupCreator` has a `createRollup` function that deploys your chain's core contracts to the parent chain. `createRollup` takes a complex struct called `RollupDeploymentParams` as its only input. This struct defines the parameters of the Arbitrum chain to be created. - -```solidity -struct RollupDeploymentParams { - Config config; - address[] validators; - uint256 maxDataSize; - address nativeToken; - bool deployFactoriesToL2; - uint256 maxFeePerGasForRetryables; - address[] batchPosters; - address batchPosterManager; -} -``` - -The following table describes `RollupDeploymentParams`'s parameters: - -| Parameter | Type | Description | -| :-------------------------- | :-------- | :------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | -| `config` | Config | The chain's configuration, explained below. | -| `validators` | address[] | Initial set of validator addresses. Validators are responsible for validating the chain state and posting assertions (`RBlocks`) back to the parent chain. They also monitor the chain and initiate challenges against potentially faulty assertions submitted by other validators. | -| `maxDataSize` | uint256 | Maximum message size for the Inbox contract (`117964` for L2 chains, and `104857` for L3 chains). | -| `nativeToken` | address | Address of the token contract in the parent chain, used for paying gas fees on the Arbitrum chain. It can be set to `ETH` for regular chains or to any `ERC-20` token for custom gas token Arbitrum chains. | -| `deployFactoriesToL2` | bool | Whether or not to deploy several deterministic factory contracts to the Arbitrum chain. | -| `maxFeePerGasForRetryables` | uint256 | Gas price bid to use when sending the retryable tickets. | -| `batchPosters` | address[] | Initial set of batch poster addresses. Batch posters batch and compress transactions on the Arbitrum chain and transmit them back to the parent chain. | -| `batchPosterManager` | address | Address of the account responsible for managing currently active batch posters. Not mandatory, as these actions can also be taken by the chain owner. | - -The `Config` struct used in the previous configuration looks like this: - -```solidity -struct Config { - uint64 confirmPeriodBlocks; - address stakeToken; - uint256 baseStake; - bytes32 wasmModuleRoot; - address owner; - address loserStakeEscrow; - uint256 chainId; - string chainConfig; - uint256 minimumAssertionPeriod; - uint64 validatorAfkBlocks; - uint256[] miniStakeValues; - ISequencerInbox.MaxTimeVariation sequencerInboxMaxTimeVariation; - uint256 layerZeroBlockEdgeHeight; - uint256 layerZeroBigStepEdgeHeight; - uint256 layerZeroSmallStepEdgeHeight; - AssertionState genesisAssertionState; - uint256 genesisInboxCount; - address anyTrustFastConfirmer; - uint8 numBigStepLevel; - uint64 challengeGracePeriodBlocks; - BufferConfig bufferConfig; -} -``` - -Most of these parameters don't need to be configured, since the Chain SDK will provide the right default values for them. However, the following table describes some of the parameters that you might want to configure: - -| Parameter | Type | Description | -| :-------------------- | :------ | :-------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | -| `confirmPeriodBlocks` | uint64 | Sets the challenge period in terms of blocks, which is the time allowed for validators to dispute or challenge state assertions. Learn more about it in [Customizable challenge period](/launch-arbitrum-chain/02-configure-your-chain/common-configurations/03-customizable-challenge-period.mdx). | -| `stakeToken` | address | Address of the token that validators must stake to participate in the chain's validation process. | -| `baseStake` | uint256 | Arbitrum chain validator nodes must stake a certain amount to incentivize honest participation. This parameter specifies this amount. | -| `wasmModuleRoot` | address | Hash of the WASM module root to be used when validating. | -| `owner` | address | Account address responsible for deploying, owning, and managing your Arbitrum chain's base contracts on its parent chain. | -| `loserStakeEscrow` | address | Address that will receive any extra stakes deposited in the same assertion (when creating disputes). | -| `chainId` | uint256 | Your chain's unique identifier. It differentiates your chain from others in the ecosystem. | -| `chainConfig` | string | Additional chain configuration, explained below. | - -The `chainConfig` parameter within the `Config` struct is a stringified `JSON` object that looks like this: - -```typescript -{ - chainId: number; - homesteadBlock: number; - daoForkBlock: null; - daoForkSupport: boolean; - eip150Block: number; - eip150Hash: string; - eip155Block: number; - eip158Block: number; - byzantiumBlock: number; - constantinopleBlock: number; - petersburgBlock: number; - istanbulBlock: number; - muirGlacierBlock: number; - berlinBlock: number; - londonBlock: number; - clique: { - period: number; - epoch: number; - } - arbitrum: { - EnableArbOS: boolean; - AllowDebugPrecompiles: boolean; - DataAvailabilityCommittee: boolean; - InitialArbOSVersion: number; - InitialChainOwner: Address; - GenesisBlockNum: number; - MaxCodeSize: number; - MaxInitCodeSize: number; - } -} -``` - -Again, most of these parameters don't need to be configured, since the Chain SDK will provide the right default values for them. However, the following table describes some of the parameters that you might want to configure: - -| Parameter | Type | Description | -| :----------------------------------- | :------ | :-------------------------------------------------------------------------------------------------------------------------------------------------------------- | -| `chainId` | number | Your chain's unique identifier. It differentiates your chain from others in the ecosystem. | -| `arbitrum.DataAvailabilityCommittee` | bool | Whether or not to use a Data Avalability Committee (DAC) to store your chain's data (this should be `false` for Rollup chains, and `true` for AnyTrust chains). | -| `arbitrum.InitialArbOSVersion` | number | ArbOS version to use (it should be the latest ArbOS version available). | -| `arbitrum.InitialChainOwner` | address | Account address responsible for deploying, owning, and managing your Arbitrum chain's base contracts on its parent chain. | -| `arbitrum.MaxCodeSize` | number | Sets the maximum size for contract bytecodes on the chain (it's recommended to use the default 24Kb, and not set it higher than 96Kb). | -| `arbitrum.MaxInitCodeSize` | number | Maximum initialization bytecode size allowed (usually double the amount set in `MaxCodeSize`). | - -:::info - -The `chainId` and `InitialChainOwner` parameters must be equal to the `chainId` and `owner` defined in the `Config` struct. - -::: - -## How to create a new Arbitrum chain using the Chain SDK - -Now, let's look at the methods to use when creating a new Arbitrum chain with the Chain SDK. - -:::info Example script - -The Chain SDK includes an example script for creating an Arbitrum chain. We recommend that you first understand the process described in this section and then check the following example scripts: - -- [`create-rollup-eth`](https://github.com/OffchainLabs/arbitrum-chain-sdk/blob/main/examples/create-rollup-eth/index.ts) for creating an Arbitrum AnyTrust chain with `ETH` as the gas token. -- [`create-rollup-custom-fee-token`](https://github.com/OffchainLabs/arbitrum-chain-sdk/tree/main/examples/create-rollup-custom-fee-token) for creating an Arbitrum AnyTrust chain with an `ERC-20` as the gas token. - -::: - -Here are the steps involved in the deployment process: - -1. [Create the chain's configuration object](#1-create-the-chains-configuration-object) -2. [Deploy the Arbitrum chain](#2-deploy-the-arbitrum-chain) -3. [Understand the returned data](#3-understand-the-returned-data) -4. [Set the DAC keyset in the `SequencerInbox` (for AnyTrust chains)](#4-set-the-dac-keyset-in-the-sequencerinbox-for-anytrust-chains) -5. [Next step](#5-next-step) - -### 1. Create the chain's configuration object - -The `prepareChainConfig` function creates a `chainConfig` structure like the one defined in the previous section. It sets the appropriate defaults for most of the parameters, allowing you to override any of these defaults. However, the `chainId` and `InitialChainOwner` parameters must be set to the desired values. - -Below is an example of how to use `prepareChainConfig` to obtain the chain configuration for a Rollup chain with a specific `chainId` and `InitialChainOwner`: - -```typescript -import { prepareChainConfig } from '@arbitrum/chain-sdk'; - -const chainConfig = prepareChainConfig({ - chainId: 123_456, - arbitrum: { - InitialChainOwner: 0x123...890, - // Set the following parameter to `true` to deploy instead an AnyTrust chain - DataAvailabilityCommittee: false, - }, -}); -``` - -Once we have the `chainConfig`, we can use the function `createRollupPrepareDeploymentParamsConfig` to craft a `Config` structure like the one defined in the section above. Again, this function will set the appropriate defaults for most parameters, allowing you to override any of these defaults. However, the `chainId` and `owner` parameters must be set to the desired values. Additionally, a public client of the parent chain must be passed as an argument to the function. - -Below is an example of how to use `createRollupPrepareDeploymentParamsConfig` to obtain the chain configuration for a chain with a specific `chainId` and `owner`: - -```typescript -import { createPublicClient, http } from 'viem'; -import { createRollupPrepareDeploymentParamsConfig } from '@arbitrum/chain-sdk'; - -const parentChainPublicClient = createPublicClient({ - chain: parentChain, - transport: http(), -}); - -const createRollupConfig = createRollupPrepareDeploymentParamsConfig(parentChainPublicClient, { - chainId: 123_456, - owner: 0x123...890, - chainConfig: chainConfig, -}); -``` - -### 2. Deploy the Arbitrum chain - -With the new crafted configuration, we can call the `createRollup` method which will send the transaction to the `RollupCreator` contract and wait until it is executed. - -Besides the `Config` structure created in the previous step, other parameters from the `RollupDeploymentParams` structure can be passed to override the defaults set by the Chain SDK. Batch poster and validator addresses must be set to the desired values. Additionally, a public client of the parent chain and a deployer PrivateKeyAccount must be passed as arguments to the function. - -:::info Additional step for custom gas token chains - -If you want to configure a custom gas token, the deployer needs to give allowance to the `RollupCreator` contract before starting the deployment process, so that it can spend enough tokens to send the correspondant `Parent-to-Child` messages during the deployment process. This process is handled within the `createRollup` function, but the deployer must own enough tokens to create these messages. - -::: - -If you want to configure a custom gas token, you can pass the address in the parent chain of the `ERC-20` token to use in the `nativeToken` parameter of the `createRollup` function. - -Below is an example of how to use `createRollup` using the `createRollupConfig` crafted in the previous step: - -```typescript -import { createPublicClient, http } from 'viem'; -import { privateKeyToAccount } from 'viem/accounts'; -import { createRollup } from '@arbitrum/chain-sdk'; - -const deployer = privateKeyToAccount(deployerPrivateKey); -const parentChainPublicClient = createPublicClient({ - chain: parentChain, - transport: http(), -}); - -const createRollupResults = await createRollup({ - params: { - config: createRollupConfig, - batchPosters: [batchPoster], - validators: [validator], - // Uncomment the following line and add the address of the custom gas token - // nativeToken: '0xAddressInParentChain', - }, - account: deployer, - parentChainPublicClient, -}); -``` - -### 3. Understand the returned data - -After calling `createRollup`, an object of type `CreateRollupResults` is returned with the following fields: - -```typescript -type CreateRollupResults = { - // The transaction sent - transaction: CreateRollupTransaction; - // The transaction receipt - transactionReceipt: CreateRollupTransactionReceipt; - // An object with the addresses of the contracts created - coreContracts: CoreContracts; -}; -``` - -### 4. Set the DAC keyset in the `SequencerInbox` (for AnyTrust chains) - -If you're creating an AnyTrust chain, the next step is to set up the keyset of your Data Availability Committee (DAC) on the `SequencerInbox` contract. This process involves setting up the Data Availability Servers (DAS) and generating the keyset with all DAS' keys. See [How to configure a DAC](/run-arbitrum-node/data-availability-committees/01-get-started.mdx) to learn more about setting up a DAC. - -:::info - -The Arbitrum Chain SDK includes an example script for setting up the keyset in the `SequencerInbox`. We recommend that you first understand the process described in this section and then check the [`set-valid-keyset`](https://github.com/OffchainLabs/arbitrum-chain-sdk/blob/main/examples/set-valid-keyset/index.ts) script. - -::: - -The Chain SDK includes a `setValidKeyset` function to help set the keyset in the SequencerInbox. From the last step, you can gather the `sequencerInbox` and `upgradeExecutor` addresses and pass them to the function along with the `keyset`, a public client of the parent chain, and a wallet client of an account that has executor privileges in the `UpgradeExecutor` contract (to learn more about `UpgradeExecutor`, see [Ownership structure and access control](/launch-arbitrum-chain/04-maintain-your-chain/03-ownership-structure-access-control.mdx)). - -Below is an example of how to use `setValidKeyset` using the parameters described above: - -```typescript -import { createPublicClient, createWalletClient, http } from 'viem'; -import { privateKeyToAccount } from 'viem/accounts'; -import { setValidKeyset } from '@arbitrum/chain-sdk'; - -const deployer = privateKeyToAccount(deployerPrivateKey); -const parentChainPublicClient = createPublicClient({ - chain: parentChain, - transport: http(), -}); -const deployerWalletClient = createWalletClient({ - account: deployer, - chain: parentChain, - transport: http(), -}); - -const transactionReceipt = await setValidKeyset({ - coreContracts: { - upgradeExecutor: '0xUpgradeExecutor', - sequencerInbox: '0xSequencerInbox', - }, - keyset: generatedKeyset, - publicClient: parentChainPublicClient, - walletClient: deployerWalletClient, -}); -``` - -This function will send the transaction and wait for its execution, returning the transaction receipt. - -### 5. Next step - -Once the chain's contracts are created, you can move to the next step: [configure your Arbitrum chain's node](/launch-arbitrum-chain/how-tos/arbitrum-chain-sdk-preparing-node-config.md). 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.md deleted file mode 100644 index 152039a4c5..0000000000 --- a/docs/launch-arbitrum-chain/03-deploy-an-arbitrum-chain/05-deploying-token-bridge.md +++ /dev/null @@ -1,286 +0,0 @@ ---- -title: 'Deploy a token bridge using the Chain SDK' -description: 'How to deploy a token bridge using the Chain SDK ' -author: GreatSoshiant, jose-franco -sme: GreatSoshiant, jose-franco -target_audience: 'Developers deploying and maintaining Arbitrum chains.' -user_story: As a current or prospective Arbitrum chain deployer, I need to understand how to deploy a token bridge using the Chain SDK. -content_type: how-to ---- - -import RaaSNotice from '../partials/_raas-providers-notice.mdx'; - - - -The Arbitrum stack doesn't natively support specific token bridging standards at the protocol level. Instead, Offchain Labs designed a "canonical token bridge" that ensures seamless `ERC-20` token transfers between the parent and child chains. - -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. - -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) -- 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 - -Before we describe the process of deploying a token bridge using the Chain SDK, let's look at the parameters we need to pass to the token bridge creator contract. - -Deploying a new token bridge for an Arbitrum chain is done through a [`TokenBridgeCreator`](/launch-arbitrum-chain/03-deploy-an-arbitrum-chain/07-canonical-factory-contracts.mdx) contract that processes the creation of the needed contracts and sends the appropriate `ParentToChild` messages from the parent chain to the child chain so the counterpart contracts of the token bridge are created in the Arbitrum chain. - -`TokenBridgeCreator` has a `createTokenBridge` function that creates the parent chain contracts of the token bridge and sends the creation message to the Arbitrum chain via retryable tickets. `createTokenBridge` takes four parameters as input: - -```solidity -address inbox, -address rollupOwner, -uint256 maxGasForContracts, -uint256 gasPriceBid -``` - -The following table describes these parameters: - -| Parameter | Type | Description | -| :------------------- | :------ | :------------------------------------------------------------------------------------------------------------------------ | -| `inbox` | address | Address of the Inbox contract of the chain. This is used to uniquely identify the chain. | -| `rollupOwner` | address | Account address responsible for deploying, owning, and managing your Arbitrum chain's base contracts on its parent chain. | -| `maxGasForContracts` | uint256 | Gas limit used for executing the retryable ticket on the child chain. | -| `gasPriceBid` | uint256 | Max gas price used for executing the retryable ticket on the child chain. | - -When creating the token bridge through the Chain SDK, the parameters `maxGasForContracts` and `gasPriceBid` don't need to be configured, since the SDK will calculate the right values. - -## How to deploy a token bridge using the Arbitrum Chain SDK - -Let's look at the methods to create a token bridge using the Chain SDK. - -:::info Example script - -The Arbitrum Chain SDK includes an example script for deploying a token bridge. We recommend that you first understand the process described in this section and then check the [create-token-bridge-eth](https://github.com/OffchainLabs/arbitrum-chain-sdk/blob/main/examples/create-token-bridge-eth/index.ts) and [create-token-bridge-custom-fee-token](https://github.com/OffchainLabs/arbitrum-chain-sdk/blob/main/examples/create-token-bridge-custom-fee-token/index.ts) scripts. - -::: - -Deploying a token bridge for a chain involves the following steps: - -1. [Approve the custom gas token (if configured)](#1-approve-the-custom-gas-token-if-configured) -2. [Deploy the token bridge](#2-deploy-the-token-bridge) -3. [Wait for retryable tickets to execute](#3-wait-for-retryable-tickets-to-execute) -4. [Obtain the token bridge contracts (optional)](#4-obtain-the-token-bridge-contracts-optional) -5. [Set up the WETH gateway](#5-set-up-the-weth-gateway) - -### 1. Approve the custom gas token (if configured) - -:::note - -This step is only a requirement for Arbitrum chains configured to use a custom gas token. - -::: - -Because the token bridge creation involves sending a retryable ticket to the Arbitrum chain, the `TokenBridgeCreator` needs to be able to send the appropriate custom gas token amount for its execution on the child chain. That means that before calling the `TokenBridgeCreator`, we need to grant allowance to the contract to move our custom gas token. To facilitate this process, the Chain SDK provides two functions: - -1. `createTokenBridgeEnoughCustomFeeTokenAllowance`: This method verifies that the `TokenBridgeCreator` contract has enough allowance to pay for the fees associated with the token bridge deployment. -2. `createTokenBridgePrepareCustomFeeTokenApprovalTransactionRequest`: This function assists in generating the raw transaction required to approve the custom gas token for the `TokenBridgeCreator` contract. - -Both functions take the following parameters: - -- `nativeToken`: the address of the custom gas token contract in the parent chain -- `owner`: the address of the chain owner -- `publicClient`: a viem's public client for the parent chain - -The following example shows how to use these functions: - -```typescript -import { createPublicClient, http } from 'viem'; -import { - createTokenBridgeEnoughCustomFeeTokenAllowance, - createTokenBridgePrepareCustomFeeTokenApprovalTransactionRequest, -} from '@arbitrum/chain-sdk'; - -const parentChainPublicClient = createPublicClient({ - chain: parentChain, - transport: http(), -}); - -const allowanceParams = { - nativeToken, - owner: rollupOwner.address, - publicClient: parentChainPublicClient, -}; - -if (!(await createTokenBridgeEnoughCustomFeeTokenAllowance(allowanceParams))) { - const approvalTxRequest = await createTokenBridgePrepareCustomFeeTokenApprovalTransactionRequest( - allowanceParams, - ); - - // sign and send the transaction - const approvalTxHash = await parentChainPublicClient.sendRawTransaction({ - serializedTransaction: await rollupOwner.signTransaction(approvalTxRequest), - }); - - // get the transaction receipt after waiting for the transaction to complete - const approvalTxReceipt = await parentChainPublicClient.waitForTransactionReceipt({ - hash: approvalTxHash, - }); -} -``` - -### 2. Deploy the token bridge - -To initiate the token bridge deployment process, we can call the `createTokenBridgePrepareTransactionRequest` function, which will craft a transaction request to be signed by the chain owner and sent to the `TokenBridgeCreator` contract. - -After that, we wait for the transaction to be executed and retrieve its receipt with `createTokenBridgePrepareTransactionReceipt`. - -You'll notice that in this case we use the `rollup` contract instead of the `inbox` contract as input for the `createTokenBridgePrepareTransactionRequest` function. Both contracts can uniquely identify a chain, so either can be used to find the right Inbox contract, but only the latter can be sent to the `TokenBridgeCreator` contract. - -Below is an example of how to use these functions: - -```typescript -import { createPublicClient, http } from 'viem'; -import { - createTokenBridgePrepareTransactionRequest, - createTokenBridgePrepareTransactionReceipt, -} from '@arbitrum/chain-sdk'; - -const parentChainPublicClient = createPublicClient({ - chain: parentChain, - transport: http(), -}); -const orbitChainPublicClient = createPublicClient({ - chain: orbitChain, - transport: http(), -}); - -const txRequest = await createTokenBridgePrepareTransactionRequest({ - params: { - rollup: coreContracts.rollup, - rollupOwner: rollupOwner.address, - }, - parentChainPublicClient, - orbitChainPublicClient, - account: rollupOwner.address, -}); - -// sign and send the transaction -const txHash = await parentChainPublicClient.sendRawTransaction({ - serializedTransaction: await rollupOwner.signTransaction(txRequest), -}); - -// get the transaction receipt after waiting for the transaction to complete -const txReceipt = createTokenBridgePrepareTransactionReceipt( - await parentChainPublicClient.waitForTransactionReceipt({ hash: txHash }), -); -``` - -### 3. Wait for retryable tickets to execute - -After the transaction executes on the parent chain, we wait for the generated retryable tickets to execute on the child chain. To do this, we use a `waitForRetryable` method available in the `txReceipt` object returned by `createTokenBridgePrepareTransactionReceipt`. - -Remember that these retryable tickets intend to create the counterpart contracts of the token bridge in the child chain so that they can communicate. The first retryable ticket creates a creator contract on the child chain configured with the templates of all the token bridge contracts. The second retryable creates the actual counterpart contracts of the token bridge. - -Example: - -```typescript -// wait for retryables to execute -console.log(`Waiting for retryable tickets to execute on the Orbit chain...`); -const orbitChainRetryableReceipts = await txReceipt.waitForRetryables({ - orbitPublicClient: orbitChainPublicClient, -}); -console.log(`Retryables executed`); -console.log( - `Transaction hash for first retryable is ${orbitChainRetryableReceipts[0].transactionHash}`, -); -console.log( - `Transaction hash for second retryable is ${orbitChainRetryableReceipts[1].transactionHash}`, -); -if (orbitChainRetryableReceipts[0].status !== 'success') { - throw new Error( - `First retryable status is not success: ${orbitChainRetryableReceipts[0].status}. Aborting...`, - ); -} -if (orbitChainRetryableReceipts[1].status !== 'success') { - throw new Error( - `Second retryable status is not success: ${orbitChainRetryableReceipts[1].status}. Aborting...`, - ); -} -``` - -### 4. Obtain the token bridge contracts (optional) - -Once the token bridge deployment is successful, you can use the `getTokenBridgeContracts` method to retrieve all the token bridge contracts' addresses: - -```typescript -const tokenBridgeContracts = await txReceipt.getTokenBridgeContracts({ - parentChainPublicClient, -}); -``` - -### 5. Set up the WETH gateway - -:::note - -That step only applies to ETH-based Arbitrum chains (i.e., not custom gas token chains). The canonical bridge design has a separate custom gateway for `WETH` to bridge it in and out of the Arbitrum chain. - -You can find more info about `WETH` gateways in our ["other gateways flavors" documentation](/build-decentralized-apps/token-bridging/03-token-bridge-erc20.mdx#other-flavors-of-gateways). - -::: - -Once the token bridge deploys, if the chain uses `ETH` as the gas token, you must set a special gateway to bridge `WETH`. This gateway unwraps `WETH` to bridge it as `ETH` and wraps it back to `WETH` on the destination chain. - -You can use the methods `createTokenBridgePrepareSetWethGatewayTransactionRequest` and `createTokenBridgePrepareSetWethGatewayTransactionReceipt` to set this gateway, in a similar way to what we used to send the `createTokenBridge` request earlier. - -This action also sends a retryable ticket to the child chain to create and configure the `WETH` gateway, so you should wait to verify that the ticket executes successfully. - -Below is an example of how to use these functions: - -```typescript -import { createPublicClient, http } from 'viem'; -import { - createTokenBridgePrepareSetWethGatewayTransactionRequest, - createTokenBridgePrepareSetWethGatewayTransactionReceipt, -} from '@arbitrum/chain-sdk'; - -const parentChainPublicClient = createPublicClient({ - chain: parentChain, - transport: http(), -}); -const orbitChainPublicClient = createPublicClient({ - chain: orbitChain, - transport: http(), -}); - -const setWethGatewayTxRequest = await createTokenBridgePrepareSetWethGatewayTransactionRequest({ - rollup: coreContracts.rollup, - parentChainPublicClient, - orbitChainPublicClient, - account: rollupOwner.address, -}); - -// sign and send the transaction -const setWethGatewayTxHash = await parentChainPublicClient.sendRawTransaction({ - serializedTransaction: await rollupOwner.signTransaction(setWethGatewayTxRequest), -}); - -// get the transaction receipt after waiting for the transaction to complete -const setWethGatewayTxReceipt = createTokenBridgePrepareSetWethGatewayTransactionReceipt( - await parentChainPublicClient.waitForTransactionReceipt({ hash: setWethGatewayTxHash }), -); - -// Wait for retryables to execute -const orbitChainSetWethGatewayRetryableReceipt = await setWethGatewayTxReceipt.waitForRetryables({ - orbitPublicClient: orbitChainPublicClient, -}); -console.log(`Retryables executed`); -console.log( - `Transaction hash for retryable is ${orbitChainSetWethGatewayRetryableReceipt[0].transactionHash}`, -); -if (orbitChainSetWethGatewayRetryableReceipt[0].status !== 'success') { - throw new Error( - `Retryable status is not success: ${orbitChainSetWethGatewayRetryableReceipt[0].status}. Aborting...`, - ); -} -``` - -:::warning You must verify Arbitrum chain contracts' source code - -We have provided a script that will perform the source code verification of all the contracts deployed by the `L1AtomicTokenBridgeCreator` to the specific Arbitrum chain. The script is available in the [Token Bridge Contracts repo](https://github.com/OffchainLabs/token-bridge-contracts/blob/main/docs/deployment.md#verify-orbit-contracts-source-code-on-the-blockscout). - -::: From 2bcf37e04deeb6c96a9d0d3b74fd19f83ab23baa Mon Sep 17 00:00:00 2001 From: Pete Date: Mon, 15 Dec 2025 09:42:56 -0600 Subject: [PATCH 10/25] converted mdx files --- .../02-deploying-an-arbitrum-chain.mdx | 321 ++++++++++++++++++ .../05-deploying-token-bridge.mdx | 286 ++++++++++++++++ 2 files changed, 607 insertions(+) create mode 100644 docs/launch-arbitrum-chain/03-deploy-an-arbitrum-chain/02-deploying-an-arbitrum-chain.mdx create mode 100644 docs/launch-arbitrum-chain/03-deploy-an-arbitrum-chain/05-deploying-token-bridge.mdx diff --git a/docs/launch-arbitrum-chain/03-deploy-an-arbitrum-chain/02-deploying-an-arbitrum-chain.mdx b/docs/launch-arbitrum-chain/03-deploy-an-arbitrum-chain/02-deploying-an-arbitrum-chain.mdx new file mode 100644 index 0000000000..79e52923fa --- /dev/null +++ b/docs/launch-arbitrum-chain/03-deploy-an-arbitrum-chain/02-deploying-an-arbitrum-chain.mdx @@ -0,0 +1,321 @@ +--- +title: 'How to deploy an Arbitrum chain using the Chain SDK' +description: 'How to deploy an Arbitrum chain using the Chain SDK ' +author: GreatSoshiant, jose-franco +sme: GreatSoshiant, jose-franco +target_audience: 'Developers deploying and maintaining Arbitrum chains.' +user_story: As a current or prospective Arbitrum chain deployer, I need to configure and deploy an Arbitrum chain. +content_type: how-to +--- + +import RaaSNotice from '../partials/_raas-providers-notice.mdx'; + + + +Creating a new Arbitrum chain involves deploying a set of contracts on your chain's parent chain. These contracts are: + +- **Bridge contracts**: Used to send cross-chain messages between the Arbitrum chain and its parent chain, including batches posted by the sequencer +- **Rollup contracts**: Used by validators to create and confirm assertions of the current state of the Arbitrum chain +- **Challenge protocol contracts**: Used by validators to dispute current assertions of the state of the chain, and ultimately resolve those disputes + +You can explore the code of these contracts in the [nitro-contracts repository](https://github.com/OffchainLabs/nitro-contracts). + +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. + +:::info About custom gas token Arbitrum chains + +Custom gas token Arbitrum chains let participants pay transaction fees in an `ERC-20` token instead of `ETH`. Standard `ERC-20` tokens can be used as gas tokens, while more complex tokens with additional functionality must fulfill [these requirements](/launch-arbitrum-chain/02-configure-your-chain/common-configurations/02-use-a-custom-gas-token-rollup.mdx#requirements-of-the-custom-gas-token) to be used as gas tokens. Remember that the `ERC-20` token to be used must be deployed on your chain's parent chain. + +::: + +## Parameters used when deploying a new chain + +Before we describe the process of creating a chain using the Chain SDK, let's see what configuration options we have available when creating a chain. + +Deploying a new Arbitrum chain is done through a [`RollupCreator`](/launch-arbitrum-chain/03-deploy-an-arbitrum-chain/07-canonical-factory-contracts.mdx) contract that processes the creation of the needed contracts and sends the initialization messages from the parent chain to the newly created Arbitrum chain. + +`RollupCreator` has a `createRollup` function that deploys your chain's core contracts to the parent chain. `createRollup` takes a complex struct called `RollupDeploymentParams` as its only input. This struct defines the parameters of the Arbitrum chain to be created. + +```solidity +struct RollupDeploymentParams { + Config config; + address[] validators; + uint256 maxDataSize; + address nativeToken; + bool deployFactoriesToL2; + uint256 maxFeePerGasForRetryables; + address[] batchPosters; + address batchPosterManager; +} +``` + +The following table describes `RollupDeploymentParams`'s parameters: + +| Parameter | Type | Description | +| :-------------------------- | :-------- | :------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | +| `config` | Config | The chain's configuration, explained below. | +| `validators` | address[] | Initial set of validator addresses. Validators are responsible for validating the chain state and posting assertions (`RBlocks`) back to the parent chain. They also monitor the chain and initiate challenges against potentially faulty assertions submitted by other validators. | +| `maxDataSize` | uint256 | Maximum message size for the Inbox contract (`117964` for L2 chains, and `104857` for L3 chains). | +| `nativeToken` | address | Address of the token contract in the parent chain, used for paying gas fees on the Arbitrum chain. It can be set to `ETH` for regular chains or to any `ERC-20` token for custom gas token Arbitrum chains. | +| `deployFactoriesToL2` | bool | Whether or not to deploy several deterministic factory contracts to the Arbitrum chain. | +| `maxFeePerGasForRetryables` | uint256 | Gas price bid to use when sending the retryable tickets. | +| `batchPosters` | address[] | Initial set of batch poster addresses. Batch posters batch and compress transactions on the Arbitrum chain and transmit them back to the parent chain. | +| `batchPosterManager` | address | Address of the account responsible for managing currently active batch posters. Not mandatory, as these actions can also be taken by the chain owner. | + +The `Config` struct used in the previous configuration looks like this: + +```solidity +struct Config { + uint64 confirmPeriodBlocks; + address stakeToken; + uint256 baseStake; + bytes32 wasmModuleRoot; + address owner; + address loserStakeEscrow; + uint256 chainId; + string chainConfig; + uint256 minimumAssertionPeriod; + uint64 validatorAfkBlocks; + uint256[] miniStakeValues; + ISequencerInbox.MaxTimeVariation sequencerInboxMaxTimeVariation; + uint256 layerZeroBlockEdgeHeight; + uint256 layerZeroBigStepEdgeHeight; + uint256 layerZeroSmallStepEdgeHeight; + AssertionState genesisAssertionState; + uint256 genesisInboxCount; + address anyTrustFastConfirmer; + uint8 numBigStepLevel; + uint64 challengeGracePeriodBlocks; + BufferConfig bufferConfig; +} +``` + +Most of these parameters don't need to be configured, since the Chain SDK will provide the right default values for them. However, the following table describes some of the parameters that you might want to configure: + +| Parameter | Type | Description | +| :-------------------- | :------ | :-------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | +| `confirmPeriodBlocks` | uint64 | Sets the challenge period in terms of blocks, which is the time allowed for validators to dispute or challenge state assertions. Learn more about it in [Customizable challenge period](/launch-arbitrum-chain/02-configure-your-chain/common-configurations/03-customizable-challenge-period.mdx). | +| `stakeToken` | address | Address of the token that validators must stake to participate in the chain's validation process. | +| `baseStake` | uint256 | Arbitrum chain validator nodes must stake a certain amount to incentivize honest participation. This parameter specifies this amount. | +| `wasmModuleRoot` | address | Hash of the WASM module root to be used when validating. | +| `owner` | address | Account address responsible for deploying, owning, and managing your Arbitrum chain's base contracts on its parent chain. | +| `loserStakeEscrow` | address | Address that will receive any extra stakes deposited in the same assertion (when creating disputes). | +| `chainId` | uint256 | Your chain's unique identifier. It differentiates your chain from others in the ecosystem. | +| `chainConfig` | string | Additional chain configuration, explained below. | + +The `chainConfig` parameter within the `Config` struct is a stringified `JSON` object that looks like this: + +```typescript +{ + chainId: number; + homesteadBlock: number; + daoForkBlock: null; + daoForkSupport: boolean; + eip150Block: number; + eip150Hash: string; + eip155Block: number; + eip158Block: number; + byzantiumBlock: number; + constantinopleBlock: number; + petersburgBlock: number; + istanbulBlock: number; + muirGlacierBlock: number; + berlinBlock: number; + londonBlock: number; + clique: { + period: number; + epoch: number; + } + arbitrum: { + EnableArbOS: boolean; + AllowDebugPrecompiles: boolean; + DataAvailabilityCommittee: boolean; + InitialArbOSVersion: number; + InitialChainOwner: Address; + GenesisBlockNum: number; + MaxCodeSize: number; + MaxInitCodeSize: number; + } +} +``` + +Again, most of these parameters don't need to be configured, since the Chain SDK will provide the right default values for them. However, the following table describes some of the parameters that you might want to configure: + +| Parameter | Type | Description | +| :----------------------------------- | :------ | :-------------------------------------------------------------------------------------------------------------------------------------------------------------- | +| `chainId` | number | Your chain's unique identifier. It differentiates your chain from others in the ecosystem. | +| `arbitrum.DataAvailabilityCommittee` | bool | Whether or not to use a Data Avalability Committee (DAC) to store your chain's data (this should be `false` for Rollup chains, and `true` for AnyTrust chains). | +| `arbitrum.InitialArbOSVersion` | number | ArbOS version to use (it should be the latest ArbOS version available). | +| `arbitrum.InitialChainOwner` | address | Account address responsible for deploying, owning, and managing your Arbitrum chain's base contracts on its parent chain. | +| `arbitrum.MaxCodeSize` | number | Sets the maximum size for contract bytecodes on the chain (it's recommended to use the default 24Kb, and not set it higher than 96Kb). | +| `arbitrum.MaxInitCodeSize` | number | Maximum initialization bytecode size allowed (usually double the amount set in `MaxCodeSize`). | + +:::info + +The `chainId` and `InitialChainOwner` parameters must be equal to the `chainId` and `owner` defined in the `Config` struct. + +::: + +## How to create a new Arbitrum chain using the Chain SDK + +Now, let's look at the methods to use when creating a new Arbitrum chain with the Chain SDK. + +:::info Example script + +The Chain SDK includes an example script for creating an Arbitrum chain. We recommend that you first understand the process described in this section and then check the following example scripts: + +- [`create-rollup-eth`](https://github.com/OffchainLabs/arbitrum-chain-sdk/blob/main/examples/create-rollup-eth/index.ts) for creating an Arbitrum AnyTrust chain with `ETH` as the gas token. +- [`create-rollup-custom-fee-token`](https://github.com/OffchainLabs/arbitrum-chain-sdk/tree/main/examples/create-rollup-custom-fee-token) for creating an Arbitrum AnyTrust chain with an `ERC-20` as the gas token. + +::: + +Here are the steps involved in the deployment process: + +1. [Create the chain's configuration object](#1-create-the-chains-configuration-object) +2. [Deploy the Arbitrum chain](#2-deploy-the-arbitrum-chain) +3. [Understand the returned data](#3-understand-the-returned-data) +4. [Set the DAC keyset in the `SequencerInbox` (for AnyTrust chains)](#4-set-the-dac-keyset-in-the-sequencerinbox-for-anytrust-chains) +5. [Next step](#5-next-step) + +### 1. Create the chain's configuration object + +The `prepareChainConfig` function creates a `chainConfig` structure like the one defined in the previous section. It sets the appropriate defaults for most of the parameters, allowing you to override any of these defaults. However, the `chainId` and `InitialChainOwner` parameters must be set to the desired values. + +Below is an example of how to use `prepareChainConfig` to obtain the chain configuration for a Rollup chain with a specific `chainId` and `InitialChainOwner`: + +```typescript +import { prepareChainConfig } from '@arbitrum/chain-sdk'; + +const chainConfig = prepareChainConfig({ + chainId: 123_456, + arbitrum: { + InitialChainOwner: 0x123...890, + // Set the following parameter to `true` to deploy instead an AnyTrust chain + DataAvailabilityCommittee: false, + }, +}); +``` + +Once we have the `chainConfig`, we can use the function `createRollupPrepareDeploymentParamsConfig` to craft a `Config` structure like the one defined in the section above. Again, this function will set the appropriate defaults for most parameters, allowing you to override any of these defaults. However, the `chainId` and `owner` parameters must be set to the desired values. Additionally, a public client of the parent chain must be passed as an argument to the function. + +Below is an example of how to use `createRollupPrepareDeploymentParamsConfig` to obtain the chain configuration for a chain with a specific `chainId` and `owner`: + +```typescript +import { createPublicClient, http } from 'viem'; +import { createRollupPrepareDeploymentParamsConfig } from '@arbitrum/chain-sdk'; + +const parentChainPublicClient = createPublicClient({ + chain: parentChain, + transport: http(), +}); + +const createRollupConfig = createRollupPrepareDeploymentParamsConfig(parentChainPublicClient, { + chainId: 123_456, + owner: 0x123...890, + chainConfig: chainConfig, +}); +``` + +### 2. Deploy the Arbitrum chain + +With the new crafted configuration, we can call the `createRollup` method which will send the transaction to the `RollupCreator` contract and wait until it is executed. + +Besides the `Config` structure created in the previous step, other parameters from the `RollupDeploymentParams` structure can be passed to override the defaults set by the Chain SDK. Batch poster and validator addresses must be set to the desired values. Additionally, a public client of the parent chain and a deployer PrivateKeyAccount must be passed as arguments to the function. + +:::info Additional step for custom gas token chains + +If you want to configure a custom gas token, the deployer needs to give allowance to the `RollupCreator` contract before starting the deployment process, so that it can spend enough tokens to send the correspondant `Parent-to-Child` messages during the deployment process. This process is handled within the `createRollup` function, but the deployer must own enough tokens to create these messages. + +::: + +If you want to configure a custom gas token, you can pass the address in the parent chain of the `ERC-20` token to use in the `nativeToken` parameter of the `createRollup` function. + +Below is an example of how to use `createRollup` using the `createRollupConfig` crafted in the previous step: + +```typescript +import { createPublicClient, http } from 'viem'; +import { privateKeyToAccount } from 'viem/accounts'; +import { createRollup } from '@arbitrum/chain-sdk'; + +const deployer = privateKeyToAccount(deployerPrivateKey); +const parentChainPublicClient = createPublicClient({ + chain: parentChain, + transport: http(), +}); + +const createRollupResults = await createRollup({ + params: { + config: createRollupConfig, + batchPosters: [batchPoster], + validators: [validator], + // Uncomment the following line and add the address of the custom gas token + // nativeToken: '0xAddressInParentChain', + }, + account: deployer, + parentChainPublicClient, +}); +``` + +### 3. Understand the returned data + +After calling `createRollup`, an object of type `CreateRollupResults` is returned with the following fields: + +```typescript +type CreateRollupResults = { + // The transaction sent + transaction: CreateRollupTransaction; + // The transaction receipt + transactionReceipt: CreateRollupTransactionReceipt; + // An object with the addresses of the contracts created + coreContracts: CoreContracts; +}; +``` + +### 4. Set the DAC keyset in the `SequencerInbox` (for AnyTrust chains) + +If you're creating an AnyTrust chain, the next step is to set up the keyset of your Data Availability Committee (DAC) on the `SequencerInbox` contract. This process involves setting up the Data Availability Servers (DAS) and generating the keyset with all DAS' keys. See [How to configure a DAC](/run-arbitrum-node/data-availability-committees/01-get-started.mdx) to learn more about setting up a DAC. + +:::info + +The Arbitrum Chain SDK includes an example script for setting up the keyset in the `SequencerInbox`. We recommend that you first understand the process described in this section and then check the [`set-valid-keyset`](https://github.com/OffchainLabs/arbitrum-chain-sdk/blob/main/examples/set-valid-keyset/index.ts) script. + +::: + +The Chain SDK includes a `setValidKeyset` function to help set the keyset in the SequencerInbox. From the last step, you can gather the `sequencerInbox` and `upgradeExecutor` addresses and pass them to the function along with the `keyset`, a public client of the parent chain, and a wallet client of an account that has executor privileges in the `UpgradeExecutor` contract (to learn more about `UpgradeExecutor`, see [Ownership structure and access control](/launch-arbitrum-chain/04-maintain-your-chain/03-ownership-structure-access-control.mdx)). + +Below is an example of how to use `setValidKeyset` using the parameters described above: + +```typescript +import { createPublicClient, createWalletClient, http } from 'viem'; +import { privateKeyToAccount } from 'viem/accounts'; +import { setValidKeyset } from '@arbitrum/chain-sdk'; + +const deployer = privateKeyToAccount(deployerPrivateKey); +const parentChainPublicClient = createPublicClient({ + chain: parentChain, + transport: http(), +}); +const deployerWalletClient = createWalletClient({ + account: deployer, + chain: parentChain, + transport: http(), +}); + +const transactionReceipt = await setValidKeyset({ + coreContracts: { + upgradeExecutor: '0xUpgradeExecutor', + sequencerInbox: '0xSequencerInbox', + }, + keyset: generatedKeyset, + publicClient: parentChainPublicClient, + walletClient: deployerWalletClient, +}); +``` + +This function will send the transaction and wait for its execution, returning the transaction receipt. + +### 5. Next step + +Once the chain's contracts are created, you can move to the next step: [configure your Arbitrum chain's node](/launch-arbitrum-chain/how-tos/arbitrum-chain-sdk-preparing-node-config.md). diff --git a/docs/launch-arbitrum-chain/03-deploy-an-arbitrum-chain/05-deploying-token-bridge.mdx b/docs/launch-arbitrum-chain/03-deploy-an-arbitrum-chain/05-deploying-token-bridge.mdx new file mode 100644 index 0000000000..152039a4c5 --- /dev/null +++ b/docs/launch-arbitrum-chain/03-deploy-an-arbitrum-chain/05-deploying-token-bridge.mdx @@ -0,0 +1,286 @@ +--- +title: 'Deploy a token bridge using the Chain SDK' +description: 'How to deploy a token bridge using the Chain SDK ' +author: GreatSoshiant, jose-franco +sme: GreatSoshiant, jose-franco +target_audience: 'Developers deploying and maintaining Arbitrum chains.' +user_story: As a current or prospective Arbitrum chain deployer, I need to understand how to deploy a token bridge using the Chain SDK. +content_type: how-to +--- + +import RaaSNotice from '../partials/_raas-providers-notice.mdx'; + + + +The Arbitrum stack doesn't natively support specific token bridging standards at the protocol level. Instead, Offchain Labs designed a "canonical token bridge" that ensures seamless `ERC-20` token transfers between the parent and child chains. + +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. + +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) +- 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 + +Before we describe the process of deploying a token bridge using the Chain SDK, let's look at the parameters we need to pass to the token bridge creator contract. + +Deploying a new token bridge for an Arbitrum chain is done through a [`TokenBridgeCreator`](/launch-arbitrum-chain/03-deploy-an-arbitrum-chain/07-canonical-factory-contracts.mdx) contract that processes the creation of the needed contracts and sends the appropriate `ParentToChild` messages from the parent chain to the child chain so the counterpart contracts of the token bridge are created in the Arbitrum chain. + +`TokenBridgeCreator` has a `createTokenBridge` function that creates the parent chain contracts of the token bridge and sends the creation message to the Arbitrum chain via retryable tickets. `createTokenBridge` takes four parameters as input: + +```solidity +address inbox, +address rollupOwner, +uint256 maxGasForContracts, +uint256 gasPriceBid +``` + +The following table describes these parameters: + +| Parameter | Type | Description | +| :------------------- | :------ | :------------------------------------------------------------------------------------------------------------------------ | +| `inbox` | address | Address of the Inbox contract of the chain. This is used to uniquely identify the chain. | +| `rollupOwner` | address | Account address responsible for deploying, owning, and managing your Arbitrum chain's base contracts on its parent chain. | +| `maxGasForContracts` | uint256 | Gas limit used for executing the retryable ticket on the child chain. | +| `gasPriceBid` | uint256 | Max gas price used for executing the retryable ticket on the child chain. | + +When creating the token bridge through the Chain SDK, the parameters `maxGasForContracts` and `gasPriceBid` don't need to be configured, since the SDK will calculate the right values. + +## How to deploy a token bridge using the Arbitrum Chain SDK + +Let's look at the methods to create a token bridge using the Chain SDK. + +:::info Example script + +The Arbitrum Chain SDK includes an example script for deploying a token bridge. We recommend that you first understand the process described in this section and then check the [create-token-bridge-eth](https://github.com/OffchainLabs/arbitrum-chain-sdk/blob/main/examples/create-token-bridge-eth/index.ts) and [create-token-bridge-custom-fee-token](https://github.com/OffchainLabs/arbitrum-chain-sdk/blob/main/examples/create-token-bridge-custom-fee-token/index.ts) scripts. + +::: + +Deploying a token bridge for a chain involves the following steps: + +1. [Approve the custom gas token (if configured)](#1-approve-the-custom-gas-token-if-configured) +2. [Deploy the token bridge](#2-deploy-the-token-bridge) +3. [Wait for retryable tickets to execute](#3-wait-for-retryable-tickets-to-execute) +4. [Obtain the token bridge contracts (optional)](#4-obtain-the-token-bridge-contracts-optional) +5. [Set up the WETH gateway](#5-set-up-the-weth-gateway) + +### 1. Approve the custom gas token (if configured) + +:::note + +This step is only a requirement for Arbitrum chains configured to use a custom gas token. + +::: + +Because the token bridge creation involves sending a retryable ticket to the Arbitrum chain, the `TokenBridgeCreator` needs to be able to send the appropriate custom gas token amount for its execution on the child chain. That means that before calling the `TokenBridgeCreator`, we need to grant allowance to the contract to move our custom gas token. To facilitate this process, the Chain SDK provides two functions: + +1. `createTokenBridgeEnoughCustomFeeTokenAllowance`: This method verifies that the `TokenBridgeCreator` contract has enough allowance to pay for the fees associated with the token bridge deployment. +2. `createTokenBridgePrepareCustomFeeTokenApprovalTransactionRequest`: This function assists in generating the raw transaction required to approve the custom gas token for the `TokenBridgeCreator` contract. + +Both functions take the following parameters: + +- `nativeToken`: the address of the custom gas token contract in the parent chain +- `owner`: the address of the chain owner +- `publicClient`: a viem's public client for the parent chain + +The following example shows how to use these functions: + +```typescript +import { createPublicClient, http } from 'viem'; +import { + createTokenBridgeEnoughCustomFeeTokenAllowance, + createTokenBridgePrepareCustomFeeTokenApprovalTransactionRequest, +} from '@arbitrum/chain-sdk'; + +const parentChainPublicClient = createPublicClient({ + chain: parentChain, + transport: http(), +}); + +const allowanceParams = { + nativeToken, + owner: rollupOwner.address, + publicClient: parentChainPublicClient, +}; + +if (!(await createTokenBridgeEnoughCustomFeeTokenAllowance(allowanceParams))) { + const approvalTxRequest = await createTokenBridgePrepareCustomFeeTokenApprovalTransactionRequest( + allowanceParams, + ); + + // sign and send the transaction + const approvalTxHash = await parentChainPublicClient.sendRawTransaction({ + serializedTransaction: await rollupOwner.signTransaction(approvalTxRequest), + }); + + // get the transaction receipt after waiting for the transaction to complete + const approvalTxReceipt = await parentChainPublicClient.waitForTransactionReceipt({ + hash: approvalTxHash, + }); +} +``` + +### 2. Deploy the token bridge + +To initiate the token bridge deployment process, we can call the `createTokenBridgePrepareTransactionRequest` function, which will craft a transaction request to be signed by the chain owner and sent to the `TokenBridgeCreator` contract. + +After that, we wait for the transaction to be executed and retrieve its receipt with `createTokenBridgePrepareTransactionReceipt`. + +You'll notice that in this case we use the `rollup` contract instead of the `inbox` contract as input for the `createTokenBridgePrepareTransactionRequest` function. Both contracts can uniquely identify a chain, so either can be used to find the right Inbox contract, but only the latter can be sent to the `TokenBridgeCreator` contract. + +Below is an example of how to use these functions: + +```typescript +import { createPublicClient, http } from 'viem'; +import { + createTokenBridgePrepareTransactionRequest, + createTokenBridgePrepareTransactionReceipt, +} from '@arbitrum/chain-sdk'; + +const parentChainPublicClient = createPublicClient({ + chain: parentChain, + transport: http(), +}); +const orbitChainPublicClient = createPublicClient({ + chain: orbitChain, + transport: http(), +}); + +const txRequest = await createTokenBridgePrepareTransactionRequest({ + params: { + rollup: coreContracts.rollup, + rollupOwner: rollupOwner.address, + }, + parentChainPublicClient, + orbitChainPublicClient, + account: rollupOwner.address, +}); + +// sign and send the transaction +const txHash = await parentChainPublicClient.sendRawTransaction({ + serializedTransaction: await rollupOwner.signTransaction(txRequest), +}); + +// get the transaction receipt after waiting for the transaction to complete +const txReceipt = createTokenBridgePrepareTransactionReceipt( + await parentChainPublicClient.waitForTransactionReceipt({ hash: txHash }), +); +``` + +### 3. Wait for retryable tickets to execute + +After the transaction executes on the parent chain, we wait for the generated retryable tickets to execute on the child chain. To do this, we use a `waitForRetryable` method available in the `txReceipt` object returned by `createTokenBridgePrepareTransactionReceipt`. + +Remember that these retryable tickets intend to create the counterpart contracts of the token bridge in the child chain so that they can communicate. The first retryable ticket creates a creator contract on the child chain configured with the templates of all the token bridge contracts. The second retryable creates the actual counterpart contracts of the token bridge. + +Example: + +```typescript +// wait for retryables to execute +console.log(`Waiting for retryable tickets to execute on the Orbit chain...`); +const orbitChainRetryableReceipts = await txReceipt.waitForRetryables({ + orbitPublicClient: orbitChainPublicClient, +}); +console.log(`Retryables executed`); +console.log( + `Transaction hash for first retryable is ${orbitChainRetryableReceipts[0].transactionHash}`, +); +console.log( + `Transaction hash for second retryable is ${orbitChainRetryableReceipts[1].transactionHash}`, +); +if (orbitChainRetryableReceipts[0].status !== 'success') { + throw new Error( + `First retryable status is not success: ${orbitChainRetryableReceipts[0].status}. Aborting...`, + ); +} +if (orbitChainRetryableReceipts[1].status !== 'success') { + throw new Error( + `Second retryable status is not success: ${orbitChainRetryableReceipts[1].status}. Aborting...`, + ); +} +``` + +### 4. Obtain the token bridge contracts (optional) + +Once the token bridge deployment is successful, you can use the `getTokenBridgeContracts` method to retrieve all the token bridge contracts' addresses: + +```typescript +const tokenBridgeContracts = await txReceipt.getTokenBridgeContracts({ + parentChainPublicClient, +}); +``` + +### 5. Set up the WETH gateway + +:::note + +That step only applies to ETH-based Arbitrum chains (i.e., not custom gas token chains). The canonical bridge design has a separate custom gateway for `WETH` to bridge it in and out of the Arbitrum chain. + +You can find more info about `WETH` gateways in our ["other gateways flavors" documentation](/build-decentralized-apps/token-bridging/03-token-bridge-erc20.mdx#other-flavors-of-gateways). + +::: + +Once the token bridge deploys, if the chain uses `ETH` as the gas token, you must set a special gateway to bridge `WETH`. This gateway unwraps `WETH` to bridge it as `ETH` and wraps it back to `WETH` on the destination chain. + +You can use the methods `createTokenBridgePrepareSetWethGatewayTransactionRequest` and `createTokenBridgePrepareSetWethGatewayTransactionReceipt` to set this gateway, in a similar way to what we used to send the `createTokenBridge` request earlier. + +This action also sends a retryable ticket to the child chain to create and configure the `WETH` gateway, so you should wait to verify that the ticket executes successfully. + +Below is an example of how to use these functions: + +```typescript +import { createPublicClient, http } from 'viem'; +import { + createTokenBridgePrepareSetWethGatewayTransactionRequest, + createTokenBridgePrepareSetWethGatewayTransactionReceipt, +} from '@arbitrum/chain-sdk'; + +const parentChainPublicClient = createPublicClient({ + chain: parentChain, + transport: http(), +}); +const orbitChainPublicClient = createPublicClient({ + chain: orbitChain, + transport: http(), +}); + +const setWethGatewayTxRequest = await createTokenBridgePrepareSetWethGatewayTransactionRequest({ + rollup: coreContracts.rollup, + parentChainPublicClient, + orbitChainPublicClient, + account: rollupOwner.address, +}); + +// sign and send the transaction +const setWethGatewayTxHash = await parentChainPublicClient.sendRawTransaction({ + serializedTransaction: await rollupOwner.signTransaction(setWethGatewayTxRequest), +}); + +// get the transaction receipt after waiting for the transaction to complete +const setWethGatewayTxReceipt = createTokenBridgePrepareSetWethGatewayTransactionReceipt( + await parentChainPublicClient.waitForTransactionReceipt({ hash: setWethGatewayTxHash }), +); + +// Wait for retryables to execute +const orbitChainSetWethGatewayRetryableReceipt = await setWethGatewayTxReceipt.waitForRetryables({ + orbitPublicClient: orbitChainPublicClient, +}); +console.log(`Retryables executed`); +console.log( + `Transaction hash for retryable is ${orbitChainSetWethGatewayRetryableReceipt[0].transactionHash}`, +); +if (orbitChainSetWethGatewayRetryableReceipt[0].status !== 'success') { + throw new Error( + `Retryable status is not success: ${orbitChainSetWethGatewayRetryableReceipt[0].status}. Aborting...`, + ); +} +``` + +:::warning You must verify Arbitrum chain contracts' source code + +We have provided a script that will perform the source code verification of all the contracts deployed by the `L1AtomicTokenBridgeCreator` to the specific Arbitrum chain. The script is available in the [Token Bridge Contracts repo](https://github.com/OffchainLabs/token-bridge-contracts/blob/main/docs/deployment.md#verify-orbit-contracts-source-code-on-the-blockscout). + +::: From cfa160669eaeff4aa2b540b2b3c15e57ced05cc6 Mon Sep 17 00:00:00 2001 From: Pete Date: Mon, 15 Dec 2025 09:43:39 -0600 Subject: [PATCH 11/25] removing broken quicklook --- .../features/advanced/choose-chain-precompiles.mdx | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) 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. From 9899f469fab19131d2d0e3bb4776861b64ae2162 Mon Sep 17 00:00:00 2001 From: Pete Date: Mon, 15 Dec 2025 09:44:14 -0600 Subject: [PATCH 12/25] Adding how to configure AnyTrust tw-606 --- .../data-availability/choose-anytrust.mdx | 24 +++++++++++++++++++ 1 file changed, 24 insertions(+) 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 33e07746e3..d2662a72f1 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 @@ -27,3 +27,27 @@ 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-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. From b0a78a646320136fbefa131f29bc78ce62984c3d Mon Sep 17 00:00:00 2001 From: Pete Date: Mon, 15 Dec 2025 09:47:25 -0600 Subject: [PATCH 13/25] linking to how to configure page --- .../validation-and-security/choose-challenge-period.mdx | 4 ++++ 1 file changed, 4 insertions(+) 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 b2f074fccf..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 @@ -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). From dab768841c47f554de763c1e659c6e4b3ac882a6 Mon Sep 17 00:00:00 2001 From: Pete Date: Mon, 15 Dec 2025 09:57:47 -0600 Subject: [PATCH 14/25] renamed heading to be more specific --- .../bold-adoption-for-arbitrum-chains.mdx | 6 +++--- 1 file changed, 3 insertions(+), 3 deletions(-) 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; From bbcfa89c29b99ab5061a99962c4e61f106cad387 Mon Sep 17 00:00:00 2001 From: Pete Date: Mon, 15 Dec 2025 09:58:20 -0600 Subject: [PATCH 15/25] Adding references to other BoLD documentation; and how to configure --- .../validation-and-security/choose-bold.mdx | 16 ++++++++++++++++ 1 file changed, 16 insertions(+) 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 fd3f1c7c75..8d54bcee84 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 @@ -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/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/bold-adoption-for-arbitrum-chains#how-to-adopt-arbitrum-bold.mdx) 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). From 367bdd3ed3800bf845f0171ca3cdc86969e50b79 Mon Sep 17 00:00:00 2001 From: Pete Date: Mon, 15 Dec 2025 10:02:49 -0600 Subject: [PATCH 16/25] fixing section heading wording --- .../04-stake-and-validator-configurations.mdx | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) 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. From c2d6f136f845520ac14f6d876664db89bfa9102a Mon Sep 17 00:00:00 2001 From: Pete Date: Mon, 15 Dec 2025 10:03:33 -0600 Subject: [PATCH 17/25] adding xref to how to configure --- .../choose-permissioned-validators.mdx | 4 ++++ 1 file changed, 4 insertions(+) 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..8a0987f00e 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#validator-configurations-and-how-to-set-them-up.mdx) section on the [Stake and Validator configurations](/launch-arbitrum-chain/02-configure-your-chain/common-configurations/04-stake-and-validator-configurations.mdx) page. From a74687192323e1a3ae750a4ea5c3825b8d3bfe71 Mon Sep 17 00:00:00 2001 From: Pete Date: Mon, 15 Dec 2025 10:07:17 -0600 Subject: [PATCH 18/25] adding xref to how to configure page --- .../features/common/ux/choose-fast-withdrawals.mdx | 10 +++++++--- 1 file changed, 7 insertions(+), 3 deletions(-) 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..eea146f648 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 +:::note + +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`. From 4332904bc36032b76fc3870f635afd950931c6ca Mon Sep 17 00:00:00 2001 From: Pete Date: Mon, 15 Dec 2025 10:08:06 -0600 Subject: [PATCH 19/25] renaming heading to be more specific --- .../common-configurations/timeboost-for-arbitrum-chains.mdx | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) 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 From 4f2ab05398708ba31ee91f7f1864c7b4e6ff42f6 Mon Sep 17 00:00:00 2001 From: Pete Date: Mon, 15 Dec 2025 10:08:53 -0600 Subject: [PATCH 20/25] changing admonition --- .../features/common/ux/choose-fast-withdrawals.mdx | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) 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 eea146f648..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,7 +42,7 @@ From a UX perspective, enabling fast withdrawals transforms slow, multi-day proc ## How to configure -:::note +:::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. From 93100328442c04bca16722a495e9347b0ee94b06 Mon Sep 17 00:00:00 2001 From: Pete Date: Mon, 15 Dec 2025 10:17:45 -0600 Subject: [PATCH 21/25] adding xref --- .../features/common/mev/choose-timeboost.mdx | 6 ++++++ 1 file changed, 6 insertions(+) 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 262eca92ad..4e0eecbf11 100644 --- a/docs/launch-arbitrum-chain/features/common/mev/choose-timeboost.mdx +++ b/docs/launch-arbitrum-chain/features/common/mev/choose-timeboost.mdx @@ -36,6 +36,12 @@ Works with any Arbitrum chain (L2/L3 ## How to configure +:::warning Caution + +This is an abbreviated set of instructions on how to configure Timeboost. It is recommended to refer to the [Timeboost for Arbitrum chains](/launch-arbitrum-chain/02-configure-your-chain/common-configurations/timeboost-for-arbitrum-chains.mdx) page for complete details about potential impacts and a full set of instructions. The configuration instructions begin in the [Prerequisites](/launch-arbitrum-chain/02-configure-your-chain/common-configurations/timeboost-for-arbitrum-chains.mdx#prerequisites) section on that page. + +::: + 1. **Deploy Auction contract**: Use Arbitrum chain scripts (e.g., from [`orbit-actions`](https://github.com/OffchainLabs/orbit-actions) repo) with a `.env` file specifying addresses (e.g., proxy admin, bid token like `WETH`, beneficiary). Run `forge script` to deploy and verify. 2. **Run Auctioneer Services**: Set up Redis for coordination; run bid 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. From 58de0ae71f98550ba14dd6457a35ceb8a17c7e0e Mon Sep 17 00:00:00 2001 From: Pete Date: Mon, 15 Dec 2025 10:18:04 -0600 Subject: [PATCH 22/25] adding xref to how to --- .../common/gas-and-fees/choose-custom-gas-token.mdx | 7 +++++++ 1 file changed, 7 insertions(+) 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..8c11796280 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/01-use-a-custom-gas-token-rollup.mdx) From cec2cce4dc68eb53ea1bf0b75feb48111798de08 Mon Sep 17 00:00:00 2001 From: Pete Date: Mon, 15 Dec 2025 10:18:19 -0600 Subject: [PATCH 23/25] adding xref to how to configure --- .../common/configure-aep/configure-aep-fees.mdx | 12 ++++++++++++ 1 file changed, 12 insertions(+) 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..79a4e7c7ff 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-introductions.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. From 5bf2e779e6adba625674d0ea94862904e0d54cae Mon Sep 17 00:00:00 2001 From: Pete Date: Mon, 15 Dec 2025 10:24:09 -0600 Subject: [PATCH 24/25] adding xrefs to how to configure pages --- .../features/advanced/choose-custom-delay-inbox-finality.mdx | 4 ++++ .../features/common/validation-and-security/choose-bold.mdx | 2 +- .../choose-permissioned-validators.mdx | 2 +- 3 files changed, 6 insertions(+), 2 deletions(-) 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/validation-and-security/choose-bold.mdx b/docs/launch-arbitrum-chain/features/common/validation-and-security/choose-bold.mdx index 8d54bcee84..f2a02d1500 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 @@ -50,6 +50,6 @@ Additional resources are: ## How to configure -For specfics on configuration refer to the [How to adopt Arbitrum BoLD](/launch-arbitrum-chain/02-configure-your-chain/bold-adoption-for-arbitrum-chains#how-to-adopt-arbitrum-bold.mdx) section on that page. +For specfics on configuration refer to the [How to adopt Arbitrum BoLD](/launch-arbitrum-chain/02-configure-your-chain/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-permissioned-validators.mdx b/docs/launch-arbitrum-chain/features/common/validation-and-security/choose-permissioned-validators.mdx index 8a0987f00e..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 @@ -48,4 +48,4 @@ This option balances security with practicality in Arbitrum's ecosystem, but for ## 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#validator-configurations-and-how-to-set-them-up.mdx) section on the [Stake and Validator configurations](/launch-arbitrum-chain/02-configure-your-chain/common-configurations/04-stake-and-validator-configurations.mdx) page. +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. From d93158796d8e11fe3e6a79252058aacc5446197a Mon Sep 17 00:00:00 2001 From: Pete Date: Mon, 15 Dec 2025 11:56:38 -0600 Subject: [PATCH 25/25] converting file to mdx; fixing broken links --- .../02-deploying-an-arbitrum-chain.mdx | 2 +- .../03-deploy-an-arbitrum-chain/05-deploying-token-bridge.mdx | 4 ++-- .../07-canonical-factory-contracts.mdx | 2 +- .../05-customize-your-chain/customize-arbos.mdx | 2 +- .../06-third-party-integrations/01-bridged-usdc-standard.md | 2 +- ...dk-introduction.md => arbitrum-chain-sdk-introduction.mdx} | 4 ++-- .../features/common/configure-aep/configure-aep-fees.mdx | 2 +- .../features/common/data-availability/choose-anytrust.mdx | 2 +- .../features/common/data-availability/choose-rollup.mdx | 2 +- .../features/common/gas-and-fees/choose-custom-gas-token.mdx | 2 +- .../features/common/validation-and-security/choose-bold.mdx | 4 ++-- .../how-tos/arbitrum-chain-sdk-preparing-node-config.md | 4 ++-- 12 files changed, 16 insertions(+), 16 deletions(-) rename docs/launch-arbitrum-chain/{arbitrum-chain-sdk-introduction.md => arbitrum-chain-sdk-introduction.mdx} (97%) diff --git a/docs/launch-arbitrum-chain/03-deploy-an-arbitrum-chain/02-deploying-an-arbitrum-chain.mdx b/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.mdx +++ 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.mdx b/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.mdx +++ 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/common/configure-aep/configure-aep-fees.mdx b/docs/launch-arbitrum-chain/features/common/configure-aep/configure-aep-fees.mdx index 79a4e7c7ff..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 @@ -45,7 +45,7 @@ The configuration ensures compliance with the AEP terms, streamlines reporting, :::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-introductions.mdx). +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: 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 d2662a72f1..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,7 +26,7 @@ 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-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 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 bde764f44c..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 @@ -32,4 +32,4 @@ For implementation, refer to the docs or your RaaS 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/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). +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 8c11796280..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 @@ -41,4 +41,4 @@ For implementation, refer to the docs or your RaaS 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/01-use-a-custom-gas-token-rollup.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/validation-and-security/choose-bold.mdx b/docs/launch-arbitrum-chain/features/common/validation-and-security/choose-bold.mdx index f2a02d1500..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 @@ -38,7 +38,7 @@ BoLD is required for Rollup mode with custom gas tokens posting to Ethereum (to :::info Still unsure? -The [BoLD adoption for Arbitrum chains](/launch-arbitrum-chain/02-configure-your-chain/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. +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: @@ -50,6 +50,6 @@ Additional resources are: ## How to configure -For specfics on configuration refer to the [How to adopt Arbitrum BoLD](/launch-arbitrum-chain/02-configure-your-chain/bold-adoption-for-arbitrum-chains.mdx#how-to-adopt-arbitrum-bold) section on that page. +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/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