From a14ac7df74507447aa51ef180ce315a990770591 Mon Sep 17 00:00:00 2001 From: Pete Date: Thu, 13 Nov 2025 12:39:37 -0600 Subject: [PATCH 01/10] Updating Orbit > Arbitrum chain; Orbit-SDK > Chain-SDK --- README.md | 2 +- .../04-embedded-bridge-widget.mdx | 2 +- docs/audit-reports.mdx | 2 +- .../third-party-docs/Covalent/covalent.mdx | 4 +- .../QuickNode/backfill-templates.mdx | 2 +- docs/get-started/overview.mdx | 32 +++---- .../timeboost/gentle-introduction.mdx | 2 +- .../01-a-gentle-introduction.mdx | 4 +- .../01-fast-withdrawals.mdx | 14 ++-- .../04-deploy-timeboost.mdx | 6 +- .../advanced-configurations/04-layer-leap.mdx | 30 +++---- .../02-set-up-aep-fee-router.mdx | 10 +-- .../aep-fee-router/03-calculate-aep-fees.mdx | 6 +- .../06-gas-optimization-tools.mdx | 6 +- .../07-fee-management.mdx | 54 ++++++------ .../08-batch-posting-assertion-control.mdx | 6 +- .../13-arbos-upgrade.mdx | 2 +- .../timeboost-for-arbitrum-chains.mdx | 2 +- .../02-deploying-an-arbitrum-chain.md | 26 +++--- .../05-deploying-token-bridge.md | 20 ++--- .../07-canonical-factory-contracts.mdx | 4 +- .../03-ownership-structure-access-control.mdx | 2 +- .../04-guidance/03-state-growth.mdx | 2 +- ...06-monitoring-tools-and-considerations.mdx | 10 +-- .../05-customize-your-chain/customize-stf.mdx | 6 +- .../01-bridged-usdc-standard.md | 2 +- .../02-third-party-providers.md | 12 +-- ...troubleshooting-building-arbitrum-chain.md | 2 +- .../arbitrum-chain-sdk-introduction.md | 2 +- ...arbitrum-chain-supported-parent-chains.mdx | 2 +- .../concepts/public-preview-expectations.mdx | 2 +- ...rbitrum-chain-sdk-preparing-node-config.md | 12 +-- .../customize-deployment-configuration.mdx | 2 +- .../migrate-between-raases.mdx | 2 +- .../migrate-from-another-stack.mdx | 28 +++---- .../partials/config-alt-da.mdx | 2 +- .../partials/config-challenge-period-l1.mdx | 4 +- .../partials/config-custom-gas-token.mdx | 4 +- .../partials/config-hardware.mdx | 22 ++--- .../partials/config-timeboost.mdx | 2 +- docs/partials/_additional-config-params.mdx | 32 +++---- docs/partials/_gentle-intro-partial.mdx | 4 +- ...troubleshooting-arbitrum-chain-partial.mdx | 2 +- docs/partials/glossary/_arbitrum-orbit.mdx | 2 +- docs/run-arbitrum-node/02-run-full-node.mdx | 4 +- .../arbos-releases/01-overview.mdx | 2 +- .../arbos-releases/arbos32.mdx | 2 +- .../beacon-nodes-historical-blobs.mdx | 2 +- .../more-types/02-run-validator-node.mdx | 2 +- ...orbit-sequencer-compatible-cli-partial.mdx | 84 +++++++++---------- .../_orbit-chains-parameters.mdx | 4 +- .../sequencer/04-run-sequencer-node.mdx | 10 +-- 52 files changed, 253 insertions(+), 253 deletions(-) diff --git a/README.md b/README.md index 77e8b7da79..ff10554875 100644 --- a/README.md +++ b/README.md @@ -15,7 +15,7 @@ This repository is organized as follows: - `for-users/` - User-focused documentation - `how-arbitrum-works/` - Technical explanations of Arbitrum - `intro/` - Introduction and glossary - - `launch-arbitrum-chain/` - Arbitrum Orbit chain deployment guides + - `launch-arbitrum-chain/` - Arbitrum chain deployment guides - `learn-more/` - Additional learning resources - `node-running/` - Node operation guides - `partials/` - Reusable content components and troubleshooting guides diff --git a/docs/arbitrum-bridge/04-embedded-bridge-widget.mdx b/docs/arbitrum-bridge/04-embedded-bridge-widget.mdx index d3ad693ebf..9cd5af0456 100644 --- a/docs/arbitrum-bridge/04-embedded-bridge-widget.mdx +++ b/docs/arbitrum-bridge/04-embedded-bridge-widget.mdx @@ -61,7 +61,7 @@ You can adopt the bridge functionality permissionlessly if your chain is already If you are interested in on-ramp support, please contact [partnerships@offchainlabs.com](mailto:partnerships@offchainlabs.com). -#### 2. If I'm an Orbit chain and I want support, how do I adopt? +#### 2. If I'm an Arbitrum chain and I want support, how do I adopt? You'll need an integration with Li.fi and a minimum number of bridges to enable a good experience. Contact [partnerships@offchainlabs.com](mailto:partnerships@offchainlabs.com) to discuss adding support for your chain. diff --git a/docs/audit-reports.mdx b/docs/audit-reports.mdx index c2c56d7f87..53d6494a69 100644 --- a/docs/audit-reports.mdx +++ b/docs/audit-reports.mdx @@ -19,7 +19,7 @@ | **Trail of Bits** | 10/07/2024 | Optimizations to BoLD history commitments | [view](hosted-audit-reports/2024_10_07_trail_of_bits_security_audit_bold_optimized_history_commitments.pdf) | | **Trail of Bits** | 09/25/2024 | Timeboost Auction Contracts | [view](hosted-audit-reports/2024_09_25_trail_of_bits_security_audit_timeboost_auction_contracts.pdf) | | **Open Zeppelin** | 09/05/2024 | Initial Stylus Rust SDK audit | [view](hosted-audit-reports/2024_09_05_open_zeppelin_security_audit_stylus_rust_sdk.pdf) | -| **Trail of Bits** | 08/29/2024 | Arbitrum Chain (Orbit) & Governance Upgrade Actions Contracts v2.1 | [view](hosted-audit-reports/2024_08_29_trail_of_bits_security_audit_orbit_and_governance_upgrade_actions_v2.1.pdf) | +| **Trail of Bits** | 08/29/2024 | Arbitrum Chain & Governance Upgrade Actions Contracts v2.1 | [view](hosted-audit-reports/2024_08_29_trail_of_bits_security_audit_orbit_and_governance_upgrade_actions_v2.1.pdf) | | **Trail of Bits** | 08/29/2024 | USDC Custom Gateway & ArbOS Timestamp Upgrade Action contract | [view](hosted-audit-reports/2024_08_29_trail_of_bits_security_audit_usdc_custom_gateway_and_arbos_upgrade_at_timestamp_action.pdf) | | **Trail of Bits** | 08/05/2024 | BoLD contract fixes from the May 2024 audit & DAC reward updates | [view](hosted-audit-reports/2024_08_05_trail_of_bits_security_audit_bold_and_dac_rewards_updates.pdf) | | **Trail of Bits** | 08/01/2024 | Custom fee token | [view](hosted-audit-reports/2024_08_01_trail_of_bits_security_audit_custom_fee_token.pdf) | diff --git a/docs/for-devs/third-party-docs/Covalent/covalent.mdx b/docs/for-devs/third-party-docs/Covalent/covalent.mdx index 19944fc3e2..0954f118fb 100644 --- a/docs/for-devs/third-party-docs/Covalent/covalent.mdx +++ b/docs/for-devs/third-party-docs/Covalent/covalent.mdx @@ -1,12 +1,12 @@ --- title: 'Quickstart - Covalent Indexing and Querying API' -description: 'Learn how to use the Covalent APIs to access Arbitrum One, Nova and Arbitrum (Orbit) chain data including balances, transactions, NFTs, DEX and core blockchain data.' +description: 'Learn how to use the Covalent APIs to access Arbitrum One, Nova and Arbitrum chain data including balances, transactions, NFTs, DEX and core blockchain data.' author: harishraisinghani sme: harishraisinghani sidebar_label: 'Covalent' --- -[Covalent](https://www.covalenthq.com/?utm_source=arbitrum&utm_medium=partner-docs) is a hosted blockchain data solution providing access to historical and current onchain data for [200+ supported blockchains](https://www.covalenthq.com/docs/networks/?utm_source=arbitrum&utm_medium=partner-docs), including Arbitrum One, Nova and Arbitrum (Orbit) chains. +[Covalent](https://www.covalenthq.com/?utm_source=arbitrum&utm_medium=partner-docs) is a hosted blockchain data solution providing access to historical and current onchain data for [200+ supported blockchains](https://www.covalenthq.com/docs/networks/?utm_source=arbitrum&utm_medium=partner-docs), including Arbitrum One, Nova and Arbitrum chains. Covalent maintains a full replica of every supported blockchain, meaning you have access to: diff --git a/docs/for-devs/third-party-docs/QuickNode/backfill-templates.mdx b/docs/for-devs/third-party-docs/QuickNode/backfill-templates.mdx index e7e941a053..a3e9b62b73 100644 --- a/docs/for-devs/third-party-docs/QuickNode/backfill-templates.mdx +++ b/docs/for-devs/third-party-docs/QuickNode/backfill-templates.mdx @@ -37,5 +37,5 @@ For detailed pricing and timing information, visit our [Streams Backfills - Arbi - [QuickNode - Arbitrum Chain Page](https://www.quicknode.com/chains/arb) - [QuickNode - Arbitrum Documentation](https://www.quicknode.com/docs/arbitrum) -- [QuickNode Builders Guide - Arbitrum Chains (Orbit)](https://www.quicknode.com/builders-guide/tools/arbitrum-orbits-by-arbitrum-foundation) +- [QuickNode Builders Guide - Arbitrum Chains](https://www.quicknode.com/builders-guide/tools/arbitrum-orbits-by-arbitrum-foundation) - [QuickNode - Arbitrum Faucet](https://faucet.quicknode.com/arbitrum) diff --git a/docs/get-started/overview.mdx b/docs/get-started/overview.mdx index ff4d36f995..6d4b2ac034 100644 --- a/docs/get-started/overview.mdx +++ b/docs/get-started/overview.mdx @@ -14,27 +14,27 @@ Arbitrum suite along with onboarding guidance tailored to specific audiences. The Arbitrum suite includes the protocols, chains, services, and SDKs that power the Arbitrum ecosystem: -| Component | Description | -| ------------------------------------------------------------------------- | ------------------------------------------------------------------------------------------------------- | -| [Arbitrum Rollup](/how-arbitrum-works/01-inside-arbitrum-nitro.mdx) | A **protocol** for scaling Ethereum smart contracts. | -| [Arbitrum AnyTrust](/how-arbitrum-works/deep-dives/anytrust-protocol.mdx) | A **protocol** for scaling Ethereum smart contracts even further, with a mild trust assumption. | -| [Arbitrum Nitro](/how-arbitrum-works/01-inside-arbitrum-nitro.mdx) | The node **software** that codifies the Rollup and AnyTrust protocols. | -| [Arbitrum nodes](/run-arbitrum-node/02-run-full-node.mdx) | **Machines** that run Nitro in order to service and/or interact with an Arbitrum chain. | -| [Arbitrum One](https://portal.arbitrum.io/?chains=arbitrum-one) | A public Rollup **chain**. | -| [Arbitrum Nova](https://portal.arbitrum.io/?chains=arbitrum-nova) | A public AnyTrust **chain**. | -| [Arbitrum bridge](https://bridge.arbitrum.io/) | Lets you move `ETH` and `ERC-20` tokens between Ethereum, Arbitrum, and select Arbitrum (Orbit) chains. | -| [Arbitrum (Orbit) chains](https://orbit.arbitrum.io/) | Lets you run your own Rollup and AnyTrust chains. | -| [Arbitrum Stylus](/stylus/gentle-introduction.mdx) | Lets you write EVM-compatible smart contracts in Rust and any other language that compiles to Wasm. | +| Component | Description | +| ------------------------------------------------------------------------- | --------------------------------------------------------------------------------------------------- | +| [Arbitrum Rollup](/how-arbitrum-works/01-inside-arbitrum-nitro.mdx) | A **protocol** for scaling Ethereum smart contracts. | +| [Arbitrum AnyTrust](/how-arbitrum-works/deep-dives/anytrust-protocol.mdx) | A **protocol** for scaling Ethereum smart contracts even further, with a mild trust assumption. | +| [Arbitrum Nitro](/how-arbitrum-works/01-inside-arbitrum-nitro.mdx) | The node **software** that codifies the Rollup and AnyTrust protocols. | +| [Arbitrum nodes](/run-arbitrum-node/02-run-full-node.mdx) | **Machines** that run Nitro in order to service and/or interact with an Arbitrum chain. | +| [Arbitrum One](https://portal.arbitrum.io/?chains=arbitrum-one) | A public Rollup **chain**. | +| [Arbitrum Nova](https://portal.arbitrum.io/?chains=arbitrum-nova) | A public AnyTrust **chain**. | +| [Arbitrum bridge](https://bridge.arbitrum.io/) | Lets you move `ETH` and `ERC-20` tokens between Ethereum, Arbitrum, and select Arbitrum chains. | +| [Arbitrum chains](https://orbit.arbitrum.io/) | Lets you run your own Rollup and AnyTrust chains. | +| [Arbitrum Stylus](/stylus/gentle-introduction.mdx) | Lets you write EVM-compatible smart contracts in Rust and any other language that compiles to Wasm. | ## Arbitrum for users **Users** interact with Arbitrum either through the Arbitrum bridge or by using dApps that have been deployed to an Arbitrum chain. -| Resource | Description | -| --------------------------------------------------------- | ------------------------------------------------------------------------------------------------------- | -| [Arbitrum bridge](https://bridge.arbitrum.io/) | Lets you move `ETH` and `ERC-20` tokens between Ethereum, Arbitrum, and select Arbitrum (Orbit) chains. | -| [Arbitrum Portal](https://portal.arbitrum.io/) | A directory of dApps on Arbitrum. | -| [Quickstart (bridge)](/arbitrum-bridge/01-quickstart.mdx) | Provides step-by-step instructions for first-time bridge users. | +| Resource | Description | +| --------------------------------------------------------- | ----------------------------------------------------------------------------------------------- | +| [Arbitrum bridge](https://bridge.arbitrum.io/) | Lets you move `ETH` and `ERC-20` tokens between Ethereum, Arbitrum, and select Arbitrum chains. | +| [Arbitrum Portal](https://portal.arbitrum.io/) | A directory of dApps on Arbitrum. | +| [Quickstart (bridge)](/arbitrum-bridge/01-quickstart.mdx) | Provides step-by-step instructions for first-time bridge users. | ## Arbitrum for developers diff --git a/docs/how-arbitrum-works/timeboost/gentle-introduction.mdx b/docs/how-arbitrum-works/timeboost/gentle-introduction.mdx index 12d89acb81..93191c38ea 100644 --- a/docs/how-arbitrum-works/timeboost/gentle-introduction.mdx +++ b/docs/how-arbitrum-works/timeboost/gentle-introduction.mdx @@ -14,7 +14,7 @@ import ImageZoom from '@site/src/components/ImageZoom'; Arbitrum Timeboost is a novel transaction ordering policy for Arbitrum chains that enables chain owners to capture the Maximal Extractable Value (MEV) on their chain, reduce spam, and preserve fast block times, all while protecting users from harmful types of MEV, such as sandwich attacks and front-running. -Timeboost is the culmination of over a year of [research and development](https://arxiv.org/abs/2306.02179) by the team at Offchain Labs. It is currently live on Arbitrum One and Arbitrum Nova, and is available for Arbitrum Orbit chains, whose owners can adopt and customize it as they choose. +Timeboost is the culmination of over a year of [research and development](https://arxiv.org/abs/2306.02179) by the team at Offchain Labs. It is currently live on Arbitrum One and Arbitrum Nova, and is available for Arbitrum chains, whose owners can adopt and customize it as they choose. ## Why do Arbitrum chains need Timeboost? diff --git a/docs/launch-arbitrum-chain/01-a-gentle-introduction.mdx b/docs/launch-arbitrum-chain/01-a-gentle-introduction.mdx index 7799b326d4..123c91fbec 100644 --- a/docs/launch-arbitrum-chain/01-a-gentle-introduction.mdx +++ b/docs/launch-arbitrum-chain/01-a-gentle-introduction.mdx @@ -12,7 +12,7 @@ import { FloatingHoverModal } from '@site/src/components/FloatingHoverModal'; This document is for developers and decision-makers who want to learn more about **Arbitrum chains**, a product offering that lets you create your own Arbitrum chains. -If you'd prefer to learn by doing, see the [Orbit SDK Rollup creation example](https://github.com/OffchainLabs/arbitrum-orbit-sdk/tree/main/examples/create-rollup-eth) for step-by-step instructions that walk you through the process of how to use `orbit-sdk` to configure and launch your own Arbitrum chain. +If you'd prefer to learn by doing, see the [Chain SDK Rollup creation example](https://github.com/OffchainLabs/arbitrum-orbit-sdk/tree/main/examples/create-rollup-eth) for step-by-step instructions that walk you through the process of how to use `chain-sdk` to configure and launch your own Arbitrum chain. ### In a nutshell: @@ -24,7 +24,7 @@ If you'd prefer to learn by doing, see the [Orbit SDK Rollup creation example](h diff --git a/docs/launch-arbitrum-chain/02-configure-your-chain/advanced-configurations/01-fast-withdrawals.mdx b/docs/launch-arbitrum-chain/02-configure-your-chain/advanced-configurations/01-fast-withdrawals.mdx index f35a3528d6..ce88d11d14 100644 --- a/docs/launch-arbitrum-chain/02-configure-your-chain/advanced-configurations/01-fast-withdrawals.mdx +++ b/docs/launch-arbitrum-chain/02-configure-your-chain/advanced-configurations/01-fast-withdrawals.mdx @@ -67,9 +67,9 @@ To enable the fast withdrawals feature, there are three actions to take: ### Upgrading to `nitro-contracts` v2.1.0 -As mentioned above, the fast withdrawals feature is available for chains that are using `nitro-contracts` v2.1.0 or above, especially the `RollupAdminLogic` and the `RollupUserLogic` contracts. You can check what nitro-contracts version your chain is using by running the [Arbitrum chain (Orbit) versioner script](https://github.com/OffchainLabs/orbit-actions/blob/main/README.md#check-version-and-upgrade-path). +As mentioned above, the fast withdrawals feature is available for chains that are using `nitro-contracts` v2.1.0 or above, especially the `RollupAdminLogic` and the `RollupUserLogic` contracts. You can check what nitro-contracts version your chain is using by running the [Arbitrum chain versioner script](https://github.com/OffchainLabs/orbit-actions/blob/main/README.md#check-version-and-upgrade-path). -If your chain is not running with `nitro-contracts` v2.1.0 or above, you’ll need to perform an upgrade to enable this version. The [Arbitrum chain (Orbit) versioner script](https://github.com/OffchainLabs/orbit-actions/blob/main/README.md#check-version-and-upgrade-path) will provide the upgrade paths needed to reach v2.1.0, but basically: +If your chain is not running with `nitro-contracts` v2.1.0 or above, you’ll need to perform an upgrade to enable this version. The [Arbitrum chain versioner script](https://github.com/OffchainLabs/orbit-actions/blob/main/README.md#check-version-and-upgrade-path) will provide the upgrade paths needed to reach v2.1.0, but basically: - If the chain is running nitro-contracts v1.1.x, you need to [upgrade first to v1.2.1](https://github.com/OffchainLabs/orbit-actions/blob/main/scripts/foundry/contract-upgrades/1.2.1/README.md). - If the chain is running nitro-contracts v1.2.1, you need to [upgrade to v2.1.0](https://github.com/OffchainLabs/orbit-actions/blob/main/scripts/foundry/contract-upgrades/2.1.0/README.md). @@ -82,7 +82,7 @@ Suppose you’re upgrading your `nitro-contracts` from v1.2.1 to v2.1.0 and usin Once the chain runs `nitro-contracts` v2.1.0 or above, the new fast withdrawal parameters will be available in the `RollupAdminLogic` and the `RollupUserLogic` contracts. -Both the Arbitrum (Orbit) chain SDK and the Arbitrum (Orbit) chain actions repository provide configurable scripts to activate and configure fast withdrawals on an AnyTrust chain. You can use either of those to activate the feature. Both scripts perform the same actions. +Both the Arbitrum SDK and the Chain SDK actions repository provide configurable scripts to activate and configure fast withdrawals on an AnyTrust chain. You can use either of those to activate the feature. Both scripts perform the same actions. :::info @@ -90,9 +90,9 @@ Even though two scripts are available to activate Fast Withdrawals, you only nee ::: -#### Arbitrum chain (Orbit) SDK script +#### Arbitrum Chain SDK script -The Arbitrum chain (Orbit) SDK provides an [example script](https://github.com/OffchainLabs/arbitrum-orbit-sdk/tree/main/examples/setup-fast-withdrawal) to set up a fast withdrawal committee by performing the following operations: +The Chain SDK provides an [example script](https://github.com/OffchainLabs/arbitrum-orbit-sdk/tree/main/examples/setup-fast-withdrawal) to set up a fast withdrawal committee by performing the following operations: 1. Create a new `n/n` Safe wallet with the specified validators as signers 2. Add the specified validators to the Rollup validators allowlist @@ -130,9 +130,9 @@ cp .env.example .env yarn run dev ``` -#### Arbitrum chain (Orbit) actions script +#### Arbitrum chain actions script -The Arbitrum chain (Orbit) actions repository also provides an [action script](https://github.com/OffchainLabs/orbit-actions/blob/main/scripts/foundry/fast-confirm/README.md) to activate fast withdrawals by performing the following operations: +The Arbitrum chain actions repository also provides an [action script](https://github.com/OffchainLabs/orbit-actions/blob/main/scripts/foundry/fast-confirm/README.md) to activate fast withdrawals by performing the following operations: 1. Make sure the "Validate fast confirmation" has not been enabled yet 2. Create a Safe contract for the fast confirmation committee diff --git a/docs/launch-arbitrum-chain/02-configure-your-chain/advanced-configurations/04-deploy-timeboost.mdx b/docs/launch-arbitrum-chain/02-configure-your-chain/advanced-configurations/04-deploy-timeboost.mdx index d871814667..381f1a2825 100644 --- a/docs/launch-arbitrum-chain/02-configure-your-chain/advanced-configurations/04-deploy-timeboost.mdx +++ b/docs/launch-arbitrum-chain/02-configure-your-chain/advanced-configurations/04-deploy-timeboost.mdx @@ -2,15 +2,15 @@ title: 'Deploy and configure Timeboost for your chain' sidebar_label: 'Deploy and configure Timeboost' description: 'Learn how to deploy and configure Timeboost' -user_story: As a current or prospective Orbit chain owner, I need to understand how to deploy and configure Timeboost +user_story: As a current or prospective Arbitrum chain owner, I need to understand how to deploy and configure Timeboost author: Jason Wan sme: Jason Wan content_type: how-to --- -# Enabling Timeboost for your Arbitrum (Orbit) chain +# Enabling Timeboost for your Arbitrum chain -This guide walks you through the process of enabling Timeboost for your Arbitrum Orbit chain. For a conceptual introduction to Timeboost, see the [Timeboost Introduction](/how-arbitrum-works/timeboost/gentle-introduction.mdx). +This guide walks you through the process of enabling Timeboost for your Arbitrum chain. For a conceptual introduction to Timeboost, see the [Timeboost Introduction](/how-arbitrum-works/timeboost/gentle-introduction.mdx). ## Prerequisites diff --git a/docs/launch-arbitrum-chain/02-configure-your-chain/advanced-configurations/04-layer-leap.mdx b/docs/launch-arbitrum-chain/02-configure-your-chain/advanced-configurations/04-layer-leap.mdx index 5081738a97..d81f044d68 100644 --- a/docs/launch-arbitrum-chain/02-configure-your-chain/advanced-configurations/04-layer-leap.mdx +++ b/docs/launch-arbitrum-chain/02-configure-your-chain/advanced-configurations/04-layer-leap.mdx @@ -1,20 +1,20 @@ --- title: 'Integrate with Layer Leap' -description: 'Learn how to implement Layer Leap to enable direct token bridging from Ethereum to Arbitrum chain (Orbit)s' +description: 'Learn how to implement Layer Leap to enable direct token bridging from Ethereum to Arbitrum chains' author: leerderek sme: amarrazza -target_audience: 'Developers who want to implement Layer Leap on their Arbitrum chain (Orbit)' +target_audience: 'Developers who want to implement Layer Leap on their Arbitrum chain' sidebar_position: 1 --- ## Overview -Layer Leap is a protocol that enables users to bridge `ETH` and `ERC-20` tokens directly from Ethereum to Arbitrum chains (Orbit) in a single transaction. This significantly improves user experience by eliminating the need for intermediate bridging steps. +Layer Leap is a protocol that enables users to bridge `ETH` and `ERC-20` tokens directly from Ethereum to Arbitrum chains in a single transaction. This significantly improves user experience by eliminating the need for intermediate bridging steps. ### Key benefits -- **For users**: Bridge tokens from Ethereum to any Arbitrum chain (Orbit) with a single transaction -- **For developers**: Seamlessly onboard users to your Arbitrum chain (Orbit) directly from Ethereum +- **For users**: Bridge tokens from Ethereum to any Arbitrum chain with a single transaction +- **For developers**: Seamlessly onboard users to your Arbitrum chain directly from Ethereum ## How it works @@ -22,30 +22,30 @@ Layer Leap uses a [system of contracts](https://github.com/OffchainLabs/l1-l3-te 1. **L1Teleporter** (on Ethereum): Entry point for token transfers 2. **L2ForwarderFactory** (on Arbitrum One/Nova): Creates deterministic `L2Forwarder` contracts -3. **L2Forwarder** (on Arbitrum One/Nova): Handles the final transfer to the Arbitrum chain (Orbit) +3. **L2Forwarder** (on Arbitrum One/Nova): Handles the final transfer to the Arbitrum chain ### Technical architecture Layer Leap leverages two key mechanisms: -1. **For `ERC-20` tokens**: The Teleport Contracts coordinate transfers through the canonical token bridges of both the parent chain and the Arbitrum chain (Orbit) +1. **For `ERC-20` tokens**: The Teleport Contracts coordinate transfers through the canonical token bridges of both the parent chain and the Arbitrum chain 2. **For `ETH`**: A "double retryable" approach, where a retryable ticket creates another retryable ticket to complete the cross-chain transfer ## Requirements -Layer Leap currently supports Arbitrum chain (Orbit)s with the following characteristics: +Layer Leap currently supports Arbitrum chains with the following characteristics: - Built on top of an Arbitrum Layer 2 (Arbitrum One or Nova) - Using `ETH` as the gas token -- The parent chain must be an Arbitrum chain (Orbit) due to reliance on retryable tickets. +- The parent chain must be an Arbitrum chain due to reliance on retryable tickets. -Support for Arbitrum chains (Orbit) with custom gas tokens is planned for future releases. +Support for Arbitrum chains with custom gas tokens is planned for future releases. ## Implementation guide ### Option 1: Integrate with Arbitrum bridge UI -If you want your Arbitrum chain (Orbit) to appear on the Arbitrum bridge UI with Layer Leap support: +If you want your Arbitrum chain to appear on the Arbitrum bridge UI with Layer Leap support: 1. If your chain is not yet on the Arbitrum bridge, submit a request using this [GitHub template](https://github.com/OffchainLabs/arbitrum-token-bridge/issues/new?assignees=&labels=feat%2Ctriage&projects=&template=add-orbit-chain-request.yml&title=%5Bfeat%5D%3A+) 2. Request Layer Leap activation using this [GitHub template](https://github.com/offchainlabs/arbitrum-token-bridge/issues/new?assignees=&labels=feat%2ctriage&projects=&template=add-layerleap-request.yml&title=%5bfeat%5d%3a+enable+layer+leap+for+%3corbit+chain%3e) @@ -56,7 +56,7 @@ To integrate Layer Leap into your custom bridge UI: 1. **Set up infrastructure** - - Ensure your Arbitrum chain (Orbit) is properly configured + - Ensure your Arbitrum chain is properly configured - Deploy and configure the necessary components 2. **Implement the bridging flow** @@ -70,10 +70,10 @@ import { TeleportTokenParameters, teleportToken } from '@arbitrum/sdk/dist/lib/t const params: TeleportTokenParameters = { l1Signer, // Ethereum signer l2Provider, // Arbitrum L2 provider - l3Provider, // Arbitrum chain (Orbit) provider + l3Provider, // Arbitrum chain provider erc20Address, // Token address (or null for ETH) amount, // Amount to bridge - l3WalletAddress, // Recipient address on the Arbitrum chain (Orbit) + l3WalletAddress, // Recipient address on the Arbitrum chain teleportType: TeleportType.STANDARD, // For ETH-fee chains }; @@ -130,4 +130,4 @@ You can see Layer Leap in action on the Arbitrum Bridge by bridging to: - [Layer Leap repository](https://github.com/OffchainLabs/l1-l3-teleport-contracts) - [SDK documentation](https://www.npmjs.com/package/@arbitrum/sdk/v/3.5.1-teleporter.0) -- [Request Layer Leap for your Arbitrum chain (Orbit)](https://github.com/OffchainLabs/arbitrum-token-bridge/issues/new?assignees=&labels=feat,triage&projects=&template=add-layerleap-request.yml&title=[feat]) +- [Request Layer Leap for your Arbitrum chain](https://github.com/OffchainLabs/arbitrum-token-bridge/issues/new?assignees=&labels=feat,triage&projects=&template=add-layerleap-request.yml&title=[feat]) diff --git a/docs/launch-arbitrum-chain/02-configure-your-chain/advanced-configurations/aep-fee-router/02-set-up-aep-fee-router.mdx b/docs/launch-arbitrum-chain/02-configure-your-chain/advanced-configurations/aep-fee-router/02-set-up-aep-fee-router.mdx index be501bd82f..19e40796f5 100644 --- a/docs/launch-arbitrum-chain/02-configure-your-chain/advanced-configurations/aep-fee-router/02-set-up-aep-fee-router.mdx +++ b/docs/launch-arbitrum-chain/02-configure-your-chain/advanced-configurations/aep-fee-router/02-set-up-aep-fee-router.mdx @@ -14,7 +14,7 @@ import ImageZoom from '@site/src/components/ImageZoom'; ## Quick start -You can adopt the AEP Fee Router by using the [AEP Router deployment scripts](https://github.com/OffchainLabs/arbitrum-orbit-sdk/tree/main/examples/setup-aep-fee-router) provided in the [Arbitrum chain (Orbit) SDK](https://github.com/OffchainLabs/arbitrum-orbit-sdk/tree/main) +You can adopt the AEP Fee Router by using the [AEP Router deployment scripts](https://github.com/OffchainLabs/arbitrum-orbit-sdk/tree/main/examples/setup-aep-fee-router) provided in the [Chain SDK](https://github.com/OffchainLabs/arbitrum-orbit-sdk/tree/main) ### Canonical contracts @@ -76,7 +76,7 @@ Here are a few flows to help visualize the deployment: ## Deployment scripts -The Arbitrum chain (Orbit) SDK provides a [configurable script](https://github.com/OffchainLabs/arbitrum-orbit-sdk/tree/main/examples/setup-aep-fee-router) that allows a chain operator to deploy quickly and set up the AEP fee router contracts. +The Arbitrum Chain SDK provides a [configurable script](https://github.com/OffchainLabs/arbitrum-orbit-sdk/tree/main/examples/setup-aep-fee-router) that allows a chain operator to deploy quickly and set up the AEP fee router contracts. The standard script deploys and sets up the AEP fee router contracts to route funds to the parent chain. @@ -88,7 +88,7 @@ L3 chains (or further layers) might need to specify a different target address o The script performs the following operations: 1. Obtain the rollup and inbox contract of the chain. These are needed to execute the next steps. -2. Obtain the current fee collectors of the chain: Arbitrum chain (Orbit) base fee collector, Arbitrum chain (Orbit) surplus fee collector, and Parent chain surplus fee collector. +2. Obtain the current fee collectors of the chain: Arbitrum chain base fee collector, Arbitrum chain surplus fee collector, and Parent chain surplus fee collector. 3. Deploy the `ChildToParentRouter` contract, configured to send the amounts received to the appropriate target address on the parent chain. 4. Deploy a `RewardDistributor` contract for each different fee collector account, configured to distribute 90% of the amounts received to the current fee collector, and 10% to the ChildToParentRouter contract deployed in the previous step. 5. Set each of the fee collectors to the `RewardDistributor` contracts @@ -103,8 +103,8 @@ To configure the script, you need to specify the following [environment variable - `ROLLUP_ADDRESS`: address of the rollup contract - `CHAIN_OWNER_PRIVATE_KEY`: private key of the account with executor privileges in the `UpgradeExecutor` admin contract for the chain -- `ORBIT_CHAIN_ID`: chain id of the Arbitrum chain (Orbit) -- `ORBIT_CHAIN_RPC`: RPC of the Arbitrum chain (Orbit) +- `ORBIT_CHAIN_ID`: chain id of the Arbitrum chain +- `ORBIT_CHAIN_RPC`: RPC of the Arbitrum chain - `PARENT_CHAIN_ID`: chain id of the parent chain, which shouldn't be an Arbitrum chain - `PARENT_CHAIN_TARGET_ADDRESS`: address on the parent chain where 10% of the revenue will be sent to. You can find the potential target addresses in this document's [canonical contracts](#canonical-contracts) section. If the parent chain is not on that list, or if your chain uses a gas token different than the one the router is configured for, contact the Arbitrum Foundation to obtain a specific target address for your chain. diff --git a/docs/launch-arbitrum-chain/02-configure-your-chain/advanced-configurations/aep-fee-router/03-calculate-aep-fees.mdx b/docs/launch-arbitrum-chain/02-configure-your-chain/advanced-configurations/aep-fee-router/03-calculate-aep-fees.mdx index 4a19464216..bd6e6eeb96 100644 --- a/docs/launch-arbitrum-chain/02-configure-your-chain/advanced-configurations/aep-fee-router/03-calculate-aep-fees.mdx +++ b/docs/launch-arbitrum-chain/02-configure-your-chain/advanced-configurations/aep-fee-router/03-calculate-aep-fees.mdx @@ -16,8 +16,8 @@ Before we define “Protocol Net Revenue”, let's explain how fees work in a st In a vanilla Arbitrum chain (a chain without customizations, transaction ordering policies, or other add-ons), users and dApps will pay a single gas fee to submit their transactions. Under the hood, however, a user’s fee is allocated across four components used by the network in different ways. These four fee components are split as follows: -- **`l2BaseFee`**: Fees paid to execute a transaction on the Arbitrum chain (Orbit). -- **`l2SurplusFee`**: Surplus fees are charged in addition to the base fee when an Arbitrum chain (Orbit) is congested. +- **`l2BaseFee`**: Fees paid to execute a transaction on the Arbitrum chain. +- **`l2SurplusFee`**: Surplus fees are charged in addition to the base fee when an Arbitrum chain is congested. - **`l1SurplusFee`**: An additional surplus fee that can be configured to award extra fees to the batch poster. Based on the above, we interpret that an Arbitrum chain’s revenue sources include all fee components: `l2BaseFee`, `l2SurplusFee`, and `l1SurplusFee`. @@ -26,7 +26,7 @@ From here on, we will refer to the three onchain components (security, execution ### Additional revenue sources -As the Arbitrum chain (Orbit) license allows chain owners to customize their Rollup, the AEP license accounts for revenue sources that could arise out of innovations. As such, it’s worth noting that the total calculation of revenue will also include: +As the Arbitrum chain license allows chain owners to customize their Rollup, the AEP license accounts for revenue sources that could arise out of innovations. As such, it’s worth noting that the total calculation of revenue will also include: - Revenue from transaction ordering policies - Revenue earned through fees on top of the bridge's diff --git a/docs/launch-arbitrum-chain/02-configure-your-chain/common-configurations/06-gas-optimization-tools.mdx b/docs/launch-arbitrum-chain/02-configure-your-chain/common-configurations/06-gas-optimization-tools.mdx index 79a42e3dc1..d828e53a9f 100644 --- a/docs/launch-arbitrum-chain/02-configure-your-chain/common-configurations/06-gas-optimization-tools.mdx +++ b/docs/launch-arbitrum-chain/02-configure-your-chain/common-configurations/06-gas-optimization-tools.mdx @@ -6,7 +6,7 @@ sme: content_type: how-to --- -To configure gas behavior on an Arbitrum (Orbit) chain using the [Arbitrum Orbit SDK](https://github.com/OffchainLabs/arbitrum-orbit-sdk), you primarily use the `ArbOwner` precompile (at address `0x0000000000000000000000000000000000000070`), which allows the chain owner to manage key parameters via function calls. These are called with post-deployment using tools like `cast` (from Foundry) or a custom script with a library like `ethers.js` or `viem`. The defaults inherit from the parent chain or standard Nitro settings, but it is possible to customize your Arbitrum chain as they are permissioned by design. +To configure gas behavior on an Arbitrum chain using the [Chain SDK](https://github.com/OffchainLabs/arbitrum-orbit-sdk), you primarily use the `ArbOwner` precompile (at address `0x0000000000000000000000000000000000000070`), which allows the chain owner to manage key parameters via function calls. These are called with post-deployment using tools like `cast` (from Foundry) or a custom script with a library like `ethers.js` or `viem`. The defaults inherit from the parent chain or standard Nitro settings, but it is possible to customize your Arbitrum chain as they are permissioned by design. Below is a breakdown of each specified parameter, including its role, typical defaults (based on Arbitrum One), and how to configure it. Note that changes may require careful consideration to avoid impacting chain performance, user experience, or security. For example, setting limits too high could lead to state bloat or slower block processing. @@ -47,7 +47,7 @@ Refer to the [Chain parameters](/build-decentralized-apps/reference/03-chain-par - **Description**: This is the minimum L2 base fee (in `wei` per gas unit), preventing fees from dropping too low during periods of low activity. The actual base fee fluctuates based on demand, but it will not fall below this set floor. It will affect user transaction costs. - **Default**: 0.1 `gwei` (100,000,000 `wei`). - **Configuration**: - - **During deployment**: Set the `minL2BaseFee` field in the Orbit setup script's config JSON. + - **During deployment**: Set the `minL2BaseFee` field in the Arbitrum chain setup script's config JSON. - **Post-deployment**: Call the `setMinimumL2BaseFee(uint256 newMinBaseFee)` method on the [`ArbOwner` precompile](/build-decentralized-apps/precompiles/02-reference.mdx#arbowner), where `newMinBaseFee` is the value in `wei`. Example using `cast`: @@ -78,6 +78,6 @@ Refer to the [How to manage the fee parameters](/launch-arbitrum-chain/02-config :::warning Caution -Always test changes on a devnet or testnet Arbitrum (Orbit) chain, as misconfiguration can lead to unexpected fee behavior or chain instability. Refer to the [`ArbOwnerPublic` precompile](/build-decentralized-apps/precompiles/02-reference.mdx#arbowner) for reading current settings without modifications. If using a custom gas token, ensure configurations are compatible. +Always test changes on a devnet or testnet Arbitrum chain, as misconfiguration can lead to unexpected fee behavior or chain instability. Refer to the [`ArbOwnerPublic` precompile](/build-decentralized-apps/precompiles/02-reference.mdx#arbowner) for reading current settings without modifications. If using a custom gas token, ensure configurations are compatible. ::: diff --git a/docs/launch-arbitrum-chain/02-configure-your-chain/common-configurations/07-fee-management.mdx b/docs/launch-arbitrum-chain/02-configure-your-chain/common-configurations/07-fee-management.mdx index 03d127104f..cead35a0c7 100644 --- a/docs/launch-arbitrum-chain/02-configure-your-chain/common-configurations/07-fee-management.mdx +++ b/docs/launch-arbitrum-chain/02-configure-your-chain/common-configurations/07-fee-management.mdx @@ -13,11 +13,11 @@ This guide describes the different fees collected on your chain, how to configur ## What fees are collected on an Arbitrum chain? -There are four fee types that are collected on every transaction of an Arbitrum chain (Orbit): +There are four fee types that are collected on every transaction of an Arbitrum chain: -- **Orbit base fee**: fees paid for executing the transaction on the chain based on the minimum base price configured. +- **Arbitrum chain base fee**: fees paid for executing the transaction on the chain based on the minimum base price configured. -- **Orbit surplus fee**: if the chain is congested (i.e., the base price paid for the transaction is higher than the minimum base price), these fees account for executing the transaction on the chain based on any gas price paid above the minimum base price configured. +- **Arbitrum chain surplus fee**: if the chain is congested (i.e., the base price paid for the transaction is higher than the minimum base price), these fees account for executing the transaction on the chain based on any gas price paid above the minimum base price configured. - **Parent chain base fee**: relative fees paid for posting the transaction on the parent chain. This amount is calculated based on the transaction's estimated size and the current view of the parent chain's base fee. @@ -32,7 +32,7 @@ You can find more detailed information about these fee types in these pages: Let's see in what ways we can configure each fee type: -### Arbitrum chain (Orbit) base fee (minimum) +### Arbitrum chain base fee (minimum) Your chain is configured with a minimum base fee for execution. This value can be obtained by calling the method `getMinimumGasPrice()(uint256)` of the [`ArbGasInfo`](/build-decentralized-apps/precompiles/02-reference.mdx#arbgasinfo) precompile. @@ -40,7 +40,7 @@ Your chain is configured with a minimum base fee for execution. This value can b cast call --rpc-url $ORBIT_CHAIN_RPC 0x000000000000000000000000000000000000006C "getMinimumGasPrice() (uint256)" ``` -Alternatively, you can use the Arbitrum chain (Orbit) SDK to retrieve the minimum Orbit base fee configured: +Alternatively, you can use the Chain SDK to retrieve the minimum Arbitrum chain base fee configured: ```typescript const orbitChainClient = createPublicClient({ @@ -65,7 +65,7 @@ To set a new minimum base fee, use the method `setMinimumL2BaseFee(uint256)` of cast send --rpc-url $ORBIT_CHAIN_RPC --private-key $OWNER_PRIVATE_KEY 0x0000000000000000000000000000000000000070 "setMinimumL2BaseFee(uint256) ()" $NEW_MINIMUM_BASE_FEE_IN_WEI ``` -Or using the Arbitrum chain (Orbit) SDK: +Or using the Chain SDK: ```typescript const owner = privateKeyToAccount(); @@ -94,7 +94,7 @@ In periods of congestion, the actual base fee of your Arbitrum chain might be hi cast call --rpc-url $ORBIT_CHAIN_RPC 0x000000000000000000000000000000000000006C "getPricesInWei() (uint256,uint256,uint256,uint256,uint256,uint256)" ``` -You can then calculate the current Orbit surplus fees as `currentBaseFee - minimumBaseFee`. +You can then calculate the current Arbitrum chain surplus fees as `currentBaseFee - minimumBaseFee`. :::note @@ -102,9 +102,9 @@ You can then calculate the current Orbit surplus fees as `currentBaseFee - minim ::: -:::info Orbit surplus fees are automatically adjusted +:::info Arbitrum chain surplus fees are automatically adjusted -Arbitrum chains automatically adjust the Orbit surplus fee based on the traffic of the chain. If the gas consumed goes over the speed limit, the chain's base fee will start increasing. Likewise, the base fee will gradually go down if demand of gas returns to below the configured speed limit, until it reaches the minimum base fee configured. +Arbitrum chains automatically adjust the Arbitrum chain surplus fee based on the traffic of the chain. If the gas consumed goes over the speed limit, the chain's base fee will start increasing. Likewise, the base fee will gradually go down if demand of gas returns to below the configured speed limit, until it reaches the minimum base fee configured. ::: @@ -116,7 +116,7 @@ To obtain the current parent chain base fee of your chain, you can call the meth cast call --rpc-url $ORBIT_CHAIN_RPC 0x000000000000000000000000000000000000006C "getL1BaseFeeEstimate() (uint256)" ``` -Alternatively, you can use the Arbitrum chain (Orbit) SDK to retrieve the current parent chain base fee: +Alternatively, you can use the Chain SDK to retrieve the current parent chain base fee: ```typescript const orbitChainClient = createPublicClient({ @@ -135,7 +135,7 @@ You can modify the current estimate of the parent chain base fee by calling the cast send --rpc-url $ORBIT_CHAIN_RPC --private-key $OWNER_PRIVATE_KEY 0x0000000000000000000000000000000000000070 "setL1PricePerUnit(uint256) ()" $NEW_PARENT_CHAIN_BASE_FEE ``` -Or using the Arbitrum chain (Orbit) SDK: +Or using the Chain SDK: ```typescript const owner = privateKeyToAccount(); @@ -176,7 +176,7 @@ The parent chain surplus fee collected is based on a reward rate configured in t cast call --rpc-url $ORBIT_CHAIN_RPC 0x000000000000000000000000000000000000006C "getL1RewardRate() (uint64)" ``` -Alternatively, you can obtain this information using the Arbitrum chain (Orbit) SDK: +Alternatively, you can obtain this information using the Chain SDK: ```typescript const orbitChainClient = createPublicClient({ @@ -195,7 +195,7 @@ To change the reward rate, you can use the method `setL1PricingRewardRate(uint64 cast send --rpc-url $ORBIT_CHAIN_RPC --private-key $OWNER_PRIVATE_KEY 0x0000000000000000000000000000000000000070 "setL1PricingRewardRate(uint64) ()" $NEW_REWARD_RATE ``` -Or using the Arbitrum chain (Orbit) SDK: +Or using the Chain SDK: ```typescript const owner = privateKeyToAccount(); @@ -234,7 +234,7 @@ The [`ArbOwner`](/build-decentralized-apps/precompiles/02-reference.mdx#arbowner ::: -Alternatively, you can use the Arbitrum chain (Orbit) SDK to retrieve the current address configured as `infraFeeAccount`: +Alternatively, you can use the Chain SDK to retrieve the current address configured as `infraFeeAccount`: ```typescript const orbitChainClient = createPublicClient({ @@ -253,7 +253,7 @@ To set a new `infraFeeAccount`, use the method `setInfraFeeAccount(address)` of cast send --rpc-url $ORBIT_CHAIN_RPC --private-key $OWNER_PRIVATE_KEY 0x0000000000000000000000000000000000000070 "setInfraFeeAccount(address) ()" $NEW_INFRAFEEACCOUNT_ADDRESS ``` -Or using the Arbitrum chain (Orbit) SDK: +Or using the Chain SDK: ```typescript const owner = privateKeyToAccount(); @@ -288,7 +288,7 @@ The [`ArbOwner`](/build-decentralized-apps/precompiles/02-reference.mdx#arbowner ::: -Alternatively, you can use the Arbitrum chain (Orbit) SDK to retrieve the current address configured as `networkFeeAccount`: +Alternatively, you can use the Chain SDK to retrieve the current address configured as `networkFeeAccount`: ```typescript const orbitChainClient = createPublicClient({ @@ -307,7 +307,7 @@ To set a new `networkFeeAccount`, use the method `setNetworkFeeAccount(address)` cast send --rpc-url $ORBIT_CHAIN_RPC --private-key $OWNER_PRIVATE_KEY 0x0000000000000000000000000000000000000070 "setNetworkFeeAccount(address) ()" $NEW_NETWORKFEEACCOUNT_ADDRESS ``` -Or using the Arbitrum chain (Orbit) SDK: +Or using the Chain SDK: ```typescript const owner = privateKeyToAccount(); @@ -334,7 +334,7 @@ Parent chain base fees are paid to the fee collector of the active batch poster #### Getting batch posters -The recommended way to get the current configured batch posters is to use the Arbitrum chain (Orbit) SDK to query the `SequencerInbox` contract on the parent chain. This method reads from events emitted when configuring a new batch poster: +The recommended way to get the current configured batch posters is to use the Chain SDK to query the `SequencerInbox` contract on the parent chain. This method reads from events emitted when configuring a new batch poster: ```typescript const parentChainClient = createPublicClient({ @@ -356,7 +356,7 @@ cast call --rpc-url $PARENT_CHAIN_RPC $SEQUENCER_INBOX_ADDRESS "isBatchPoster(ad **Alternative method using ArbAggregator:** -You can also query batch posters by calling the `getBatchPosters()(address[])` method of the [`ArbAggregator`](/build-decentralized-apps/precompiles/02-reference.mdx#arbaggregator) precompile on your Orbit chain: +You can also query batch posters by calling the `getBatchPosters()(address[])` method of the [`ArbAggregator`](/build-decentralized-apps/precompiles/02-reference.mdx#arbaggregator) precompile on your Arbitrum chain: ```shell cast call --rpc-url $ORBIT_CHAIN_RPC 0x000000000000000000000000000000000000006D "getBatchPosters() (address[])" @@ -379,7 +379,7 @@ Once you have the batch poster address, you can obtain the fee collector address cast call --rpc-url $ORBIT_CHAIN_RPC 0x000000000000000000000000000000000000006D "getFeeCollector(address) (address)" $BATCH_POSTER_ADDRESS ``` -You can also use the Arbitrum chain (Orbit) SDK: +You can also use the Chain SDK: ```typescript const orbitChainClient = createPublicClient({ @@ -408,7 +408,7 @@ To set a new fee collector for a specific batch poster, use the method `setFeeCo cast send --rpc-url $ORBIT_CHAIN_RPC --private-key $OWNER_PRIVATE_KEY 0x000000000000000000000000000000000000006D "setFeeCollector(address,address) ()" $BATCH_POSTER_ADDRESS $NEW_FEECOLLECTOR_ADDRESS ``` -Or using the Arbitrum chain (Orbit) SDK: +Or using the Chain SDK: ```typescript const owner = privateKeyToAccount(); @@ -439,7 +439,7 @@ cast send --rpc-url $PARENT_CHAIN_RPC --private-key $OWNER_PRIVATE_KEY $SEQUENCE **Optional: Pre-register for fee management** -If you want to configure a fee collector before the batch poster sends its first batch, you can optionally pre-register the address on the Orbit chain by calling `addBatchPoster(address)` of the [`ArbAggregator`](/build-decentralized-apps/precompiles/02-reference.mdx#arbaggregator) precompile: +If you want to configure a fee collector before the batch poster sends its first batch, you can optionally pre-register the address on the Arbitrum chain by calling `addBatchPoster(address)` of the [`ArbAggregator`](/build-decentralized-apps/precompiles/02-reference.mdx#arbaggregator) precompile: ```shell cast send --rpc-url $ORBIT_CHAIN_RPC --private-key $OWNER_PRIVATE_KEY 0x000000000000000000000000000000000000006D "addBatchPoster(address) ()" $NEW_BATCH_POSTER_ADDRESS @@ -459,7 +459,7 @@ Parent chain surplus fees are paid to a specific `L1RewardRecipient` address tha cast call --rpc-url $ORBIT_CHAIN_RPC 0x000000000000000000000000000000000000006C "getL1RewardRecipient() (address)" ``` -Alternatively, you can obtain this information using the Arbitrum chain (Orbit) SDK: +Alternatively, you can obtain this information using the Chain SDK: ```typescript const orbitChainClient = createPublicClient({ @@ -478,7 +478,7 @@ To set a new `L1RewardRecipient` address, you can call the method `setL1PricingR cast send --rpc-url $ORBIT_CHAIN_RPC --private-key $OWNER_PRIVATE_KEY 0x0000000000000000000000000000000000000070 "setL1PricingRewardRecipient(address) ()" $NEW_L1REWARDRECIPIENT_ADDRESS ``` -Alternatively, you can use the Arbitrum chain (Orbit) SDK to set the new address: +Alternatively, you can use the Chain SDK to set the new address: ```typescript const owner = privateKeyToAccount(); @@ -505,9 +505,9 @@ In the previous section we described how to set the individual collector address This section shows how to configure a distributor contract to manage the fees of a specific type. -:::info Example scripts available in the Arbitrum chain (Orbit) SDK +:::info Example scripts available in the Chain SDK -This section will explain the process of deploying and configuring a distribution contract manually, but the Arbitrum chain (Orbit) SDK includes an [example to perform this process through a script](https://github.com/OffchainLabs/arbitrum-orbit-sdk/tree/main/examples/setup-fee-distributor-contract). +This section will explain the process of deploying and configuring a distribution contract manually, but the Chain SDK includes an [example to perform this process through a script](https://github.com/OffchainLabs/arbitrum-orbit-sdk/tree/main/examples/setup-fee-distributor-contract). ::: @@ -517,7 +517,7 @@ An example implementation of a distributor contract can be found [in the fund-di ### Step 2. Set the contract address as the desired fee type collector address -Use the instructions provided in the previous section to set the address of the deployed distributor contract as the collector of the desired fee type. For example, if you want the distributor contract to manage the Orbit surplus fees, set the `networkFeeAccount` to the address of the deployed contract. +Use the instructions provided in the previous section to set the address of the deployed distributor contract as the collector of the desired fee type. For example, if you want the distributor contract to manage the Arbitrum chain surplus fees, set the `networkFeeAccount` to the address of the deployed contract. ### Step 3. Configure the recipients of fees in the contract diff --git a/docs/launch-arbitrum-chain/02-configure-your-chain/common-configurations/08-batch-posting-assertion-control.mdx b/docs/launch-arbitrum-chain/02-configure-your-chain/common-configurations/08-batch-posting-assertion-control.mdx index dd04ba63c4..9bcf52393d 100644 --- a/docs/launch-arbitrum-chain/02-configure-your-chain/common-configurations/08-batch-posting-assertion-control.mdx +++ b/docs/launch-arbitrum-chain/02-configure-your-chain/common-configurations/08-batch-posting-assertion-control.mdx @@ -16,7 +16,7 @@ Assertion posting configurations enable validators to periodically create and po ### Maximum wait time to post a batch -The batch posting minimum frequency is primarily controlled by the `--node.batch-poster.max-delay` parameter in the [Nitro node's configuration](https://github.com/OffchainLabs/nitro/blob/master/arbnode/batch_poster.go) (set via the JSON config file or command-line flags when deploying an Orbit chain). This parameter defines the maximum time the batch poster will wait after receiving a transaction before posting a batch that includes it. The default value is one hour (3600 seconds). +The batch posting minimum frequency is primarily controlled by the `--node.batch-poster.max-delay` parameter in the [Nitro node's configuration](https://github.com/OffchainLabs/nitro/blob/master/arbnode/batch_poster.go) (set via the JSON config file or command-line flags when deploying an Arbitrum chain). This parameter defines the maximum time the batch poster will wait after receiving a transaction before posting a batch that includes it. The default value is one hour (3600 seconds). - **Configuration Options**: Set this in the `node.batch-poster` section of the config, e.g., `"max-delay": "30m"` for a 30-minute maximum wait. Lower values increase posting frequency but may result in smaller, less efficient batches during periods of low activity, thereby increasing gas costs on the parent chain. If no transactions are received, no batches will post regardless of this setting. - **Prevention of Issues**: A shorter max delay reduces the opportunity for transaction reordering by minimizing the time transactions sit uncommitted in the sequencer's mempool. It also limits exposure to chain reorgs, as batches post sooner, anchoring them to the parent chain before potential L1 fluctuations can invalidate sequencing. However, extremely low settings (e.g., seconds) could spam the parent chain with tiny batches, resulting in increased costs without any benefits. @@ -24,7 +24,7 @@ The batch posting minimum frequency is primarily controlled by the `--node.batch ### Maximum batch size to post a batch -Maximum size of a batch, if total queued but not posted transaction size archive this number, then batch poster will post this batch, it is controlled by the `--node.batch-poster.max-size` parameter in the [Nitro node's configuration](https://github.com/OffchainLabs/nitro/blob/master/arbnode/batch_poster.go) (set via the JSON config file or command-line flags when deploying an Orbit chain). +Maximum size of a batch, if total queued but not posted transaction size archive this number, then batch poster will post this batch, it is controlled by the `--node.batch-poster.max-size` parameter in the [Nitro node's configuration](https://github.com/OffchainLabs/nitro/blob/master/arbnode/batch_poster.go) (set via the JSON config file or command-line flags when deploying an Arbitrum chain). - **Configuration Options**: Set this in the `node.batch-poster` section of the config, e.g., `"max-size": "100000"` for 100000 bytes. Lower values increase posting frequency but may result in smaller, less efficient batches during periods of low activity, thereby increasing gas costs on the parent chain. If no transactions are received, no batches will post regardless of this setting. - **Prevention of Issues**: A smaller max size reduces the opportunity for transaction reordering by minimizing the time transactions sit uncommitted in the sequencer's mempool. It also limits exposure to chain reorgs, as batches post sooner, anchoring them to the parent chain before potential L1 fluctuations can invalidate sequencing. However, extremely low settings (e.g., seconds) could spam the parent chain with tiny batches, resulting in increased costs without any benefits. @@ -59,7 +59,7 @@ The reorganization resistance margin is configurable via the `--node.batch-poste - **Detailed Explanation of the Message**: The message "Disabling batch posting due to batch being within reorg resistance margin from Layer 1 minimum block or timestamp bounds" signifies that the batch poster's logic has detected the proposed batch's minimum required L1 block or timestamp falls within the configured margin of the current L1 chain head. For example, if the margin is ten minutes and the L1 head timestamp is `T`, the poster disables itself if the batch requires a minimum timestamp greater than (`T - 10m`) or a minimum block that is too close to the head. This message serves as a protective mechanism: L1 chains, such as Ethereum, can undergo short reorganizations (e.g., uncle blocks or brief forks), which could invalidate a posted batch if it references a block/timestamp that gets reorganized. By temporarily disabling posting, the system waits for L1 to stabilize, ensuring the batch remains valid once posted. The disablement is transient; posting resumes once the margin clears (e.g., as L1 advances). This message often appears in logs during periods of high L1 volatility or when the sequencer's clock/L1 sync is slightly off. It's normal in such cases, but it may indicate setup issues if it persists. - **Guidance on Configuration**: Set this in the `node.batch-poster` config section, e.g., `"reorg-resistance-margin": "5m"`. Lower values allow for faster posting but increase the risk; higher values enhance safety. Monitor logs for frequent disablements and adjust accordingly based on the parent chain stability (e.g., Ethereum mainnet vs. testnets). -- **Recommended Settings**: The default of ten minutes is suitable for most Orbit chains settling to Arbitrum One/Nova, as Ethereum reorgs rarely exceed a few blocks (1-2 minutes). For chains on more volatile bases (e.g., alt L1s), increase the time to 15-20 minutes. Test on devnets to observe behavior. +- **Recommended Settings**: The default of ten minutes is suitable for most Arbitrum chains settling to Arbitrum One/Nova, as Ethereum reorgs rarely exceed a few blocks (1-2 minutes). For chains on more volatile bases (e.g., alt L1s), increase the time to 15-20 minutes. Test on devnets to observe behavior. - **Trade-offs Between Consistency and Latency**: A higher margin prioritizes consistency by reducing the chance of orphaned posted batches due to L1 reorgs, which could force manual intervention or state rollbacks—critical for high-value chains. However, it increases latency, as batches may wait longer to post, delaying confirmation times (e.g., from seconds to minutes). A lower margin reduces latency for a better user experience (faster transaction finality) but risks more frequent disablements or invalid postings, potentially leading to temporary chain halts or increased operational overhead. Balance based on chain use case: low margin for gaming/dex chains that require speed; high margin for DeFi/financial apps that emphasize reliability. ### Sequencer max time variation diff --git a/docs/launch-arbitrum-chain/02-configure-your-chain/common-configurations/13-arbos-upgrade.mdx b/docs/launch-arbitrum-chain/02-configure-your-chain/common-configurations/13-arbos-upgrade.mdx index f0a2893a98..9d079a0562 100644 --- a/docs/launch-arbitrum-chain/02-configure-your-chain/common-configurations/13-arbos-upgrade.mdx +++ b/docs/launch-arbitrum-chain/02-configure-your-chain/common-configurations/13-arbos-upgrade.mdx @@ -48,7 +48,7 @@ WASM module roots are backward compatible, so upgrading them before an ArbOS ver To schedule an ArbOS version upgrade for your Arbitrum chain, [follow this guide](https://github.com/OffchainLabs/orbit-actions/tree/main/scripts/foundry/arbos-upgrades/at-timestamp). In addition to the upgrade action contract address and the account address for the chain owner account, you will need the following inputs: 1. **`newVersion`**: Specify the ArbOS version you wish to upgrade to (e.g., `20`). -2. **`timestamp`**: Set the exact UNIX timestamp at which you want your Arbitrum chain (Orbit) to transition to the new ArbOS version. +2. **`timestamp`**: Set the exact UNIX timestamp at which you want your Arbitrum chain to transition to the new ArbOS version. If you would prefer to do this manually, simply call the [`scheduleArbOSUpgrade`](https://github.com/OffchainLabs/nitro-precompile-interfaces/blob/fe4121240ca1ee2cbf07d67d0e6c38015d94e704/ArbOwner.sol#L116) function on the `ArbOwner` precompile of the Arbitrum chain(s) you're upgrading. Because this is an administrative action (similar to upgrading your Wasm module root), the **chain owner account** must call the target chain's `upgrade executor` contract with the appropriate calldata in order to invoke the `scheduleArbOSUpgrade` function of the ArbOwner precompile. This will schedule the ArbOS upgrade using the specified version and timestamp. 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 165a4bbeb5..82d4b988f2 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 @@ -86,7 +86,7 @@ As explained in the [gentle introduction to Timeboost](/how-arbitrum-works/timeb ## Enabling Timeboost for your Arbitrum chain -This guide walks you through the process of enabling Timeboost for your Arbitrum Orbit chain. For a conceptual introduction to Timeboost, see the [Timeboost Introduction](https://docs.arbitrum.io/how-arbitrum-works/timeboost/gentle-introduction). +This guide walks you through the process of enabling Timeboost for your Arbitrum chain. For a conceptual introduction to Timeboost, see the [Timeboost Introduction](https://docs.arbitrum.io/how-arbitrum-works/timeboost/gentle-introduction). ### Prerequisites 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 index a5b7fae6f2..4321a99ca5 100644 --- a/docs/launch-arbitrum-chain/03-deploy-an-arbitrum-chain/02-deploying-an-arbitrum-chain.md +++ b/docs/launch-arbitrum-chain/03-deploy-an-arbitrum-chain/02-deploying-an-arbitrum-chain.md @@ -1,6 +1,6 @@ --- -title: 'How to deploy an Arbitrum chain using the Arbitrum chain (Orbit) SDK' -description: 'How to deploy an Arbitrum chain using the Arbitrum chain (Orbit) SDK ' +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.' @@ -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 (Orbit) 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.md) for an introduction to the process of creating and configuring an Arbitrum chain. :::info About custom gas token Arbitrum chains @@ -32,7 +32,7 @@ Custom gas token Arbitrum chains let participants pay transaction fees in an `ER ## Parameters used when deploying a new chain -Before we describe the process of creating a chain using the Arbitrum chain (Orbit) SDK, let's see what configuration options we have available when creating a 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. @@ -92,7 +92,7 @@ struct Config { } ``` -Most of these parameters don't need to be configured, since the Arbitrum chain (Orbit) SDK will provide the right default values for them. However, the following table describes some of the parameters that you might want to configure: +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 | | :-------------------- | :------ | :-------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | @@ -141,7 +141,7 @@ The `chainConfig` parameter within the `Config` struct is a stringified `JSON` o } ``` -Again, most of these parameters don't need to be configured, since the Arbitrum chain (Orbit) SDK will provide the right default values for them. However, the following table describes some of the parameters that you might want to configure: +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 | | :----------------------------------- | :------ | :-------------------------------------------------------------------------------------------------------------------------------------------------------------- | @@ -158,16 +158,16 @@ The `chainId` and `InitialChainOwner` parameters must be equal to the `chainId` ::: -## How to create a new Arbitrum chain using the Arbitrum chain (Orbit) SDK +## 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 Arbitrum chain (Orbit) SDK. +Now, let's look at the methods to use when creating a new Arbitrum chain with the Chain SDK. :::info Example script -The Arbitrum chain (Orbit) 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: +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-orbit-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-orbit-sdk/tree/main/examples/create-rollup-custom-fee-token) for creating an Arbitrum AnyTrust chain with an ERC-20 as the gas token. +- [`create-rollup-custom-fee-token`](https://github.com/OffchainLabs/arbitrum-orbit-sdk/tree/main/examples/create-rollup-custom-fee-token) for creating an Arbitrum AnyTrust chain with an `ERC-20` as the gas token. ::: @@ -222,7 +222,7 @@ const createRollupConfig = createRollupPrepareDeploymentParamsConfig(parentChain 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 Arbitrum chain (Orbit) 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. +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 @@ -279,11 +279,11 @@ If you're creating an AnyTrust chain, the next step is to set up the keyset of y :::info -The Arbitrum chain (Orbit) 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-orbit-sdk/blob/main/examples/set-valid-keyset/index.ts) script. +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-orbit-sdk/blob/main/examples/set-valid-keyset/index.ts) script. ::: -The Arbitrum chain (Orbit) 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)). +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: 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 index 17782e1309..8aaa8aa550 100644 --- a/docs/launch-arbitrum-chain/03-deploy-an-arbitrum-chain/05-deploying-token-bridge.md +++ b/docs/launch-arbitrum-chain/03-deploy-an-arbitrum-chain/05-deploying-token-bridge.md @@ -1,10 +1,10 @@ --- -title: 'Deploy a token bridge using the Arbitrum chain (Orbit) SDK' -description: 'How to deploy a token bridge using the Arbitrum chain (Orbit) SDK ' +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 Arbitrum chain (Orbit) SDK. +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 --- @@ -25,7 +25,7 @@ Before reading this guide, we recommend: ## Parameters used when deploying a token bridge -Before we describe the process of deploying a token bridge using the Arbitrum chain (Orbit) SDK, let's look at the parameters we need to pass to the token bridge creator contract. +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. @@ -47,15 +47,15 @@ The following table describes these parameters: | `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 Arbitrum chain (Orbit) SDK, the parameters `maxGasForContracts` and `gasPriceBid` don't need to be configured, since the SDK will calculate the right values. +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 (Orbit) SDK +## How to deploy a token bridge using the Arbitrum Chain SDK -Let's look at the methods to create a token bridge using the Arbitrum chain (Orbit) SDK. +Let's look at the methods to create a token bridge using the Chain SDK. :::info Example script -The Arbitrum chain (Orbit) 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-orbit-sdk/blob/main/examples/create-token-bridge-eth/index.ts) and [create-token-bridge-custom-fee-token](https://github.com/OffchainLabs/arbitrum-orbit-sdk/blob/main/examples/create-token-bridge-custom-fee-token/index.ts) scripts. +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-orbit-sdk/blob/main/examples/create-token-bridge-eth/index.ts) and [create-token-bridge-custom-fee-token](https://github.com/OffchainLabs/arbitrum-orbit-sdk/blob/main/examples/create-token-bridge-custom-fee-token/index.ts) scripts. ::: @@ -75,7 +75,7 @@ This step is only a requirement for Arbitrum chains configured to use a custom g ::: -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 Arbitrum chain (Orbit) SDK provides two functions: +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. @@ -279,7 +279,7 @@ if (orbitChainSetWethGatewayRetryableReceipt[0].status !== 'success') { } ``` -:::warning You must verify Arbitrum (Orbit) chain contracts' source code +:::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). 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 e8e192391f..b9c54a2172 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 @@ -12,9 +12,9 @@ Deploying new Arbitrum chains is usually done through a `RollupCreator` contract This page describes the benefits of using these canonical factory contracts and lists their addresses in all supported chains. -:::info Use the Arbitrum chain (Orbit) SDK +:::info Use the Arbitrum Chain SDK -You can use these contracts to create Arbitrum chains. However, it is strongly recommended to go through the [Arbitrum chain (Orbit) 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.md) to interact with them. Doing so prevents misconfiguring parameters and using appropriate defaults for most of them. ::: diff --git a/docs/launch-arbitrum-chain/04-maintain-your-chain/03-ownership-structure-access-control.mdx b/docs/launch-arbitrum-chain/04-maintain-your-chain/03-ownership-structure-access-control.mdx index 1e38081907..d6e6540af8 100644 --- a/docs/launch-arbitrum-chain/04-maintain-your-chain/03-ownership-structure-access-control.mdx +++ b/docs/launch-arbitrum-chain/04-maintain-your-chain/03-ownership-structure-access-control.mdx @@ -37,7 +37,7 @@ Chain owners can either call [`UpgradeExecutor.executeCall`](https://github.com/ ### Ownership flexibility -A chain owner is simply an address; it is set by the Arbitrum chain's deployer and can represent any sort of governance scheme (i.e., it could be an EOA (as is set via the [Orbit SDK Rollup creation example](https://github.com/OffchainLabs/arbitrum-orbit-sdk/tree/main/examples/create-rollup-eth)), a Multisig, a governance token system, etc.) +A chain owner is simply an address; it is set by the Arbitrum chain's deployer and can represent any sort of governance scheme (i.e., it could be an EOA (as is set via the [Chain SDK Rollup creation example](https://github.com/OffchainLabs/arbitrum-orbit-sdk/tree/main/examples/create-rollup-eth)), a Multisig, a governance token system, etc.) The Arbitrum DAO governed chains, while not Arbitrum chains themselves, use a similar architecture and upgrade pattern as Arbitrum chains, with both a governance token and a Multisig (aka, the "Security Council") as chain owners. For more info and best practices on action contracts, see ["DAO Governance Action Contracts"](https://github.com/ArbitrumFoundation/governance/blob/main/src/gov-action-contracts/README.md). diff --git a/docs/launch-arbitrum-chain/04-maintain-your-chain/04-guidance/03-state-growth.mdx b/docs/launch-arbitrum-chain/04-maintain-your-chain/04-guidance/03-state-growth.mdx index d19ac4c7a2..ff7165d0f6 100644 --- a/docs/launch-arbitrum-chain/04-maintain-your-chain/04-guidance/03-state-growth.mdx +++ b/docs/launch-arbitrum-chain/04-maintain-your-chain/04-guidance/03-state-growth.mdx @@ -12,7 +12,7 @@ content_type: how-to As the Arbitrum ecosystem grows, more and more teams are choosing to build on the Arbitrum tech stack. Arbitrum chains offer a feature-rich and scalable Rollup stack that allows teams to focus on their ecosystem growth and build great products. As a result, many Arbitrum chains are seeing usage and throughput increase rapidly, often with sustained transaction load at the chain’s throughput limit for months on end. -This page aims to educate Arbitrum chain operators and owners on safely operating a high throughput chain. Amongst all the factors, the primary consideration is **state growth rate** and **state size**. We’ll discuss how increased state size affects the performance of different components in the Arbitrum chain (Orbit) stack and how certain metrics can be used to indicate a need to upgrade various infrastructure components. +This page aims to educate Arbitrum chain operators and owners on safely operating a high throughput chain. Amongst all the factors, the primary consideration is **state growth rate** and **state size**. We’ll discuss how increased state size affects the performance of different components in the Arbitrum chain stack and how certain metrics can be used to indicate a need to upgrade various infrastructure components. ## Understanding state size and state growth rate diff --git a/docs/launch-arbitrum-chain/04-maintain-your-chain/06-monitoring-tools-and-considerations.mdx b/docs/launch-arbitrum-chain/04-maintain-your-chain/06-monitoring-tools-and-considerations.mdx index 276b94a6e5..60ee7e9a0e 100644 --- a/docs/launch-arbitrum-chain/04-maintain-your-chain/06-monitoring-tools-and-considerations.mdx +++ b/docs/launch-arbitrum-chain/04-maintain-your-chain/06-monitoring-tools-and-considerations.mdx @@ -9,19 +9,19 @@ sidebar_position: 0 When deploying and maintaining an Arbitrum chain, there are several key elements that need to be monitored. This page lists tools that are available for chain maintainers, as well as other considerations to keep in mind when monitoring an Arbitrum chain. -## Arbitrum chain (Orbit) verification script +## Arbitrum chain verification script -The [Arbitrum chain (Orbit) verification script](https://github.com/OffchainLabs/arbitrum-orbit-sdk/tree/feat-add-verification-scripts/examples/verify-rollup) retrieves information from an Arbitrum chain and its parent chain to verify that all parameters are configured correctly. After gathering the data, it generates a comprehensive report and issues warnings for any discrepancies detected. This tool is particularly useful after deploying and configuring an Arbitrum chain, to make sure that the onchain information has been correctly set. +The [Arbitrum chain verification script](https://github.com/OffchainLabs/arbitrum-orbit-sdk/tree/feat-add-verification-scripts/examples/verify-rollup) retrieves information from an Arbitrum chain and its parent chain to verify that all parameters are configured correctly. After gathering the data, it generates a comprehensive report and issues warnings for any discrepancies detected. This tool is particularly useful after deploying and configuring an Arbitrum chain, to make sure that the onchain information has been correctly set. :::info -The Arbitrum chain (Orbit) Verification Script is currently under active development and is considered a work-in-progress (WIP). Consequently, its findings should be approached with caution, as there is a potential for false positives. +The Arbitrum chain Verification Script is currently under active development and is considered a work-in-progress (WIP). Consequently, its findings should be approached with caution, as there is a potential for false positives. ::: -## Arbitrum chain (Orbit) retryables tracker +## Arbitrum chain retryables tracker -[Retryable tickets](/how-arbitrum-works/deep-dives/l1-to-l2-messaging.mdx) are messages sent from a parent chain and executed on the Arbitrum chain. Due to their asynchronous nature (they are executed several minutes after being created), if insufficient funds are provided at the time of creation, they might not automatically redeem (execute) upon arrival at the Arbitrum chain. When this occurs, a manual redemption of the ticket is required. The [Arbitrum chain (Orbit) retryables tracker](https://github.com/OffchainLabs/Orbit-retryable-tracker) is designed to assist in identifying and displaying the status of retryable tickets sent from a parent chain to the Arbitrum chain, and it reports any tickets that have not been automatically redeemed. +[Retryable tickets](/how-arbitrum-works/deep-dives/l1-to-l2-messaging.mdx) are messages sent from a parent chain and executed on the Arbitrum chain. Due to their asynchronous nature (they are executed several minutes after being created), if insufficient funds are provided at the time of creation, they might not automatically redeem (execute) upon arrival at the Arbitrum chain. When this occurs, a manual redemption of the ticket is required. The [Arbitrum chain retryables tracker](https://github.com/OffchainLabs/Orbit-retryable-tracker) is designed to assist in identifying and displaying the status of retryable tickets sent from a parent chain to the Arbitrum chain, and it reports any tickets that have not been automatically redeemed. ## Data Availability Server (DAS) health checks diff --git a/docs/launch-arbitrum-chain/05-customize-your-chain/customize-stf.mdx b/docs/launch-arbitrum-chain/05-customize-your-chain/customize-stf.mdx index e4a1949359..6b71513883 100644 --- a/docs/launch-arbitrum-chain/05-customize-your-chain/customize-stf.mdx +++ b/docs/launch-arbitrum-chain/05-customize-your-chain/customize-stf.mdx @@ -101,7 +101,7 @@ With that, you have now two ways of running your node. #### 1. Using the docker-compose file -This is the recommended way if you're running your Arbitrum chain (Orbit) locally through the provided [docker-compose file](https://github.com/OffchainLabs/orbit-setup-script/blob/main/docker-compose.yaml#L39). In `docker-compose.yml`, modify the Docker image used for the Nitro container: +This is the recommended way if you're running your Arbitrum chain locally through the provided [docker-compose file](https://github.com/OffchainLabs/orbit-setup-script/blob/main/docker-compose.yaml#L39). In `docker-compose.yml`, modify the Docker image used for the Nitro container: ``` ... @@ -123,7 +123,7 @@ docker run --rm -it -v /path/to/your/node/dir:/home/user/.arbitrum -p 0.0.0.0:84 :::info -The instructions provided in [How to run a full node](/run-arbitrum-node/02-run-full-node.mdx) **will not** work with your Arbitrum chain node. See [Optional parameters (Arbitrum chain)](/run-arbitrum-node/02-run-full-node.mdx#optional-parameters) for Arbitrum chain (Orbit)-specific CLI flags. +The instructions provided in [How to run a full node](/run-arbitrum-node/02-run-full-node.mdx) **will not** work with your Arbitrum chain node. See [Optional parameters (Arbitrum chain)](/run-arbitrum-node/02-run-full-node.mdx#optional-parameters) for Arbitrum chain-specific CLI flags. ::: @@ -171,7 +171,7 @@ After that, you'll have, again, two ways of running your node. #### 1. Using the docker-compose file -As mentioned before, this is the recommended way if you're running your Arbitrum chain (Orbit) locally through the provided [docker-compose file](https://github.com/OffchainLabs/orbit-setup-script/blob/main/docker-compose.yaml#L39). In `docker-compose.yml`, modify the Docker image used for the Nitro container. Notice that we'll now use the `custom-nitro-node-dev` you just created: +As mentioned before, this is the recommended way if you're running your Arbitrum chain locally through the provided [docker-compose file](https://github.com/OffchainLabs/orbit-setup-script/blob/main/docker-compose.yaml#L39). In `docker-compose.yml`, modify the Docker image used for the Nitro container. Notice that we'll now use the `custom-nitro-node-dev` you just created: ``` ... 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 2ab21defac..7abebc25d7 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 @@ -28,7 +28,7 @@ We provide a custom `USDC` gateway implementation (for parent and child chains) - On a child chain, `L2USDCGateway` is used. - For the `USDC` token contracts, Circle's reference [implementation](https://github.com/circlefin/stablecoin-evm/blob/master/doc/bridged_USDC_standard.md) is used. -This page describes how to deploy a `USDC` bridge compatible with both the Arbitrum chain (Orbit) token bridge and Circle’s Bridged `USDC` Standard. +This page describes how to deploy a `USDC` bridge compatible with both the Arbitrum chain token bridge and Circle’s Bridged `USDC` Standard. Steps for a transition to native `USDC` issuance are also provided. Note that both Circle and the Arbitrum chain owner must agree to transition to native `USDC` issuance. diff --git a/docs/launch-arbitrum-chain/06-third-party-integrations/02-third-party-providers.md b/docs/launch-arbitrum-chain/06-third-party-integrations/02-third-party-providers.md index bc76bf4f5b..105ed8a7ef 100644 --- a/docs/launch-arbitrum-chain/06-third-party-integrations/02-third-party-providers.md +++ b/docs/launch-arbitrum-chain/06-third-party-integrations/02-third-party-providers.md @@ -17,7 +17,7 @@ This list is not exhaustive, and will be continuously updated as the Arbitrum ec ## Rollup-as-a-Service (RaaS) providers -For most production use-cases, we encourage Arbitrum chain (Orbit) operators to work with one of the following RaaS (Rollup as a Service) providers. These providers manage the infrastructure required to maintain high-performance, secure Arbitrum chain deployments: +For most production use-cases, we encourage Arbitrum chain operators to work with one of the following RaaS (Rollup as a Service) providers. These providers manage the infrastructure required to maintain high-performance, secure Arbitrum chain deployments: - [QuickNode](https://www.quicknode.com/) - [Caldera](https://www.caldera.xyz/) @@ -30,7 +30,7 @@ For most production use-cases, we encourage Arbitrum chain (Orbit) operators to ## Chain explorers -Chain explorers let you view transactions, blocks, addresses, and network activity associated with your Arbitrum chain. The following explorers support Arbitrum chains (Orbit), and can be used to monitor and analyze your chain's activity: +Chain explorers let you view transactions, blocks, addresses, and network activity associated with your Arbitrum chain. The following explorers support Arbitrum chains, and can be used to monitor and analyze your chain's activity: - [Blockscout](https://www.blockscout.com/) - [Socialscan](https://socialscan.io/) @@ -41,7 +41,7 @@ Additionally, Arbitrum chains leveraging blobs for data availability may use too ## Bridges -You can easily launch an Arbitrum chain (Orbit) with a canonical token bridge, which allows transfers to and from the chain via Arbitrum One, Nova, or the parent chain to which your Arbitrum chain settles transactions. +You can easily launch an Arbitrum chain with a canonical token bridge, which allows transfers to and from the chain via Arbitrum One, Nova, or the parent chain to which your Arbitrum chain settles transactions. For applications that require the ability to transfer assets to chains outside of the Arbitrum ecosystem or in an expedited manner (without waiting for complete finality), the following third-party bridging providers can be used: @@ -67,7 +67,7 @@ AnyTrust protocol offers native support data availability. If you are turning on ## Indexers -Indexers provide a convenient way to retrieve historic or application-specific data without having to interface with your chain through an RPC endpoint. The following third-party providers offer indexing services that can be used with Arbitrum chains (Orbit): +Indexers provide a convenient way to retrieve historic or application-specific data without having to interface with your chain through an RPC endpoint. The following third-party providers offer indexing services that can be used with Arbitrum chains: - [Alchemy](https://www.alchemy.com/) - [Chainstack](https://chainstack.com/) @@ -80,7 +80,7 @@ Indexers provide a convenient way to retrieve historic or application-specific d ## Oracles -The following Oracle providers can be used to integrate offchain data with your Arbitrum chain's (Orbit) smart contracts: +The following Oracle providers can be used to integrate offchain data with your Arbitrum chain's smart contracts: - [Chainlink](https://chain.link/) - [Chronicle](https://chroniclelabs.org/) @@ -103,7 +103,7 @@ RPC endpoints are the primary interface through which users and developers inter ## Alternative data availability -One way to reduce transaction fees for Arbitrum chains (Orbit) is to configure a Data Availability (DA) solution that stores chain data offchain. Although the AnyTrust protocol offers native support for this functionality (and is configurable by default on Arbitrum AnyTrust chains), the following third-party providers give you another way to store data offchain. Note that using these services will limit your chain's ability to leverage AnyTrust protocol improvements as they relate to transaction fee and DA configurability: +One way to reduce transaction fees for Arbitrum chains is to configure a Data Availability (DA) solution that stores chain data offchain. Although the AnyTrust protocol offers native support for this functionality (and is configurable by default on Arbitrum AnyTrust chains), the following third-party providers give you another way to store data offchain. Note that using these services will limit your chain's ability to leverage AnyTrust protocol improvements as they relate to transaction fee and DA configurability: - [Celestia](https://celestia.org/) - [EigenDA](https://www.eigenlayer.xyz/) diff --git a/docs/launch-arbitrum-chain/09-faq-troubleshooting/troubleshooting-building-arbitrum-chain.md b/docs/launch-arbitrum-chain/09-faq-troubleshooting/troubleshooting-building-arbitrum-chain.md index 757b45b667..e64d92cd93 100644 --- a/docs/launch-arbitrum-chain/09-faq-troubleshooting/troubleshooting-building-arbitrum-chain.md +++ b/docs/launch-arbitrum-chain/09-faq-troubleshooting/troubleshooting-building-arbitrum-chain.md @@ -1,7 +1,7 @@ --- title: 'Arbitrum chain FAQ' sidebar_position: 7 -description: List of questions and answers frequently asked by developers launching and working on Orbit chains +description: List of questions and answers frequently asked by developers launching and working on Arbitrum chains user_story: As a developer, I want to understand how to troubleshoot common issues when building and launching Arbitrum chains. content_type: faq --- diff --git a/docs/launch-arbitrum-chain/arbitrum-chain-sdk-introduction.md b/docs/launch-arbitrum-chain/arbitrum-chain-sdk-introduction.md index ddba65cebd..3968221953 100644 --- a/docs/launch-arbitrum-chain/arbitrum-chain-sdk-introduction.md +++ b/docs/launch-arbitrum-chain/arbitrum-chain-sdk-introduction.md @@ -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 Arbitrum chain (Orbit) SDK. +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. ## 3. Configure your Arbitrum chain's node diff --git a/docs/launch-arbitrum-chain/arbitrum-chain-supported-parent-chains.mdx b/docs/launch-arbitrum-chain/arbitrum-chain-supported-parent-chains.mdx index 01cd8daf02..a4511ffeb3 100644 --- a/docs/launch-arbitrum-chain/arbitrum-chain-supported-parent-chains.mdx +++ b/docs/launch-arbitrum-chain/arbitrum-chain-supported-parent-chains.mdx @@ -55,6 +55,6 @@ Please note that we cannot guarantee compatibility or offer assistance for custo ### Adding custom parent chains -Although Arbitrum chains primarily supports a predefined set of chains, it provides developers with the flexibility to add custom parent chains through [the `registerCustomParentChain` function of the Arbitrum (Orbit) chain SDK](https://github.com/OffchainLabs/arbitrum-orbit-sdk/blob/729facd4d50156d7a84cf1204552c900eb86655c/src/chains.ts#L102). This capability enables integration with chains beyond the officially supported list, offering opportunities for customization and expanding the Arbtrium ecosystem. +Although Arbitrum chains primarily supports a predefined set of chains, it provides developers with the flexibility to add custom parent chains through [the `registerCustomParentChain` function of the Chain SDK](https://github.com/OffchainLabs/arbitrum-orbit-sdk/blob/729facd4d50156d7a84cf1204552c900eb86655c/src/chains.ts#L102). This capability enables integration with chains beyond the officially supported list, offering opportunities for customization and expanding the Arbtrium ecosystem. However, adding a custom chain requires deploying essential contracts, such as the creator contract and template contract, on the target chain. These contracts are fundamental for ensuring the proper functioning of the Arbitrum chain framework on the custom chain. diff --git a/docs/launch-arbitrum-chain/concepts/public-preview-expectations.mdx b/docs/launch-arbitrum-chain/concepts/public-preview-expectations.mdx index 187562da16..0300645f39 100644 --- a/docs/launch-arbitrum-chain/concepts/public-preview-expectations.mdx +++ b/docs/launch-arbitrum-chain/concepts/public-preview-expectations.mdx @@ -15,7 +15,7 @@ It's important to note that Arbitrum chains are a new technology and as such, ** To mitigate these risks, you're strongly encouraged to **deploy your Arbitrum chain on Testnet first**. If you don't launch on Testnet first, you significantly increase risk. -Refer to the [Orbit SDK Rollup creation example](https://github.com/OffchainLabs/arbitrum-orbit-sdk/tree/main/examples/create-rollup-eth) for instructions that walk you through the process of deploying your Arbitrum chain to Testnet. +Refer to the [Chain SDK Rollup creation example](https://github.com/OffchainLabs/arbitrum-orbit-sdk/tree/main/examples/create-rollup-eth) for instructions that walk you through the process of deploying your Arbitrum chain to Testnet. ### How products like Arbitrum chains developed at Offchain Labs 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 b8d00f0010..8a6352ffa5 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 @@ -1,10 +1,10 @@ --- -title: "How to configure your Arbitrum chain's node using the Arbitrum chain (Orbit) SDK" -description: 'Learn how to configure a node using the Arbitrum chain (Orbit) SDK' +title: "How to configure your Arbitrum chain's node using the Chain SDK" +description: 'Learn how to configure a node 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 configure a node using the Arbitrum chain (Orbit) SDK. +user_story: As a current or prospective Arbitrum chain deployer, I need to understand how to configure a node using the Chain SDK. content_type: how-to --- @@ -84,13 +84,13 @@ For Arbitrum AnyTrust chainsA Domains (RPC/explorer), CDN accounts, SSL certificates, and GitHub/S3 buckets that host snapshots. Your RaaS provider may have different requirements. -#### What is the process involved in migrating an existing Arbitrum (Orbit) chain from one RaaS operator to another? +#### What is the process involved in migrating an existing Arbitrum chain from one RaaS operator to another? Chain migration will require close coordination between the old and new chain operators. With proper planning and coordination, a migration can result in only a few minutes of downtime, with the total transfer process occurring over several days. diff --git a/docs/launch-arbitrum-chain/migrate-from-another-stack.mdx b/docs/launch-arbitrum-chain/migrate-from-another-stack.mdx index 34b63a74ca..3cfa496564 100644 --- a/docs/launch-arbitrum-chain/migrate-from-another-stack.mdx +++ b/docs/launch-arbitrum-chain/migrate-from-another-stack.mdx @@ -19,19 +19,19 @@ This document is provided for informational purposes only and does not constitut -### Why migrate to Arbitrum (Orbit) chain? +### Why migrate to an Arbitrum chain? Teams typically migrate when they need one or more of the following: -- **Lower fees**: Arbitrum (Orbit) chain Rollup or AnyTrust for low transaction fees. +- **Lower fees**: Arbitrum chain Rollup or AnyTrust for low transaction fees. - **Various customization options**: Custom gas token, flexible DA, Timeboost, BoLD, etc. -- **Mature tooling and ecosystem**: Bridges, indexers, wallets, monitoring, and partners with Arbitrum (Orbit) chain-ready integrations. +- **Mature tooling and ecosystem**: Bridges, indexers, wallets, monitoring, and partners with Arbitrum chain-ready integrations. ### Two migration paths Teams coming from other stacks have two viable paths: -- **Ecosystem migration (simpler, faster)**: Launch a fresh Arbitrum (Orbit) chain. Users/app bridge funds and redeploy contracts. This approach is quicker and less risky, but it puts a burden on apps and users. +- **Ecosystem migration (simpler, faster)**: Launch a fresh Arbitrum chain. Users/app bridge funds and redeploy contracts. This approach is quicker and less risky, but it puts a burden on apps and users. - **Chain-state migration (harder, slower)**: Transplant state/history so apps keep addresses and positions. This method requires more engineering, testing, and downtime planning. The right choice depends on your user requirements, partner dependencies, and tolerance for downtime/engineering effort. Your RaaS owns and executes the migration plan. @@ -52,20 +52,20 @@ Teams should determine the canonical bridge for each asset and the authoritative **Recommended actions**: - Publish an official asset list (symbols, decimals, canonical token address, and canonical bridge) before migration. -- Enforce a one-way migration from the legacy chain to the new Arbitrum (Orbit) chain (freeze legacy deposits while allowing Arbitrum (Orbit) chain deposits). +- Enforce a one-way migration from the legacy chain to the new Arbitrum chain (freeze legacy deposits while allowing Arbitrum chain deposits). - Coordinate with third-party bridges/routers to repoint routes. - Deprecate legacy wrappers where needed and communicate exact swap/burn/mint paths. ### How do we preserve data & historical queries? -**Problem**: After migration, historical data remains on the old stack, while new data resides on the Arbitrum (Orbit) chain. +**Problem**: After migration, historical data remains on the old stack, while new data resides on the Arbitrum chain. **Why it matters**: Apps, analytics, and explorers often read historical events. If they must re-integrate two endpoints, things will break. **Recommended action**: Run a dual-RPC gateway that: - Route pre-migration block range to an archive node on the old stack, and -- Route post-migration requests to the new Arbitrum (Orbit) chain. Apps can continue to use a single RPC URL and don’t need to be aware of the boundary. +- Route post-migration requests to the new Arbitrum chain. Apps can continue to use a single RPC URL and don’t need to be aware of the boundary. ### How can we migrate without downtime on my chain? @@ -85,7 +85,7 @@ Pause withdrawals earlier than the main freeze window to ensure no funds get tra You can use the chain-state migration process. The two common approaches are: -- State replay: Re-execute legacy blocks into the Arbitrum (Orbit) chain. This process can be heavy, but it can preserve more historical information. **Caution**: If the legacy stack has different opcode semantics, precompiles, or system contracts, replay can diverge, resulting in a different end state even with identical transactions. Validate equivalence early on a private testnet before committing. +- State replay: Re-execute legacy blocks into the Arbitrum chain. This process can be heavy, but it can preserve more historical information. **Caution**: If the legacy stack has different opcode semantics, precompiles, or system contracts, replay can diverge, resulting in a different end state even with identical transactions. Validate equivalence early on a private testnet before committing. - Genesis import: Export balances/storage and pre-seed them in the chain’s genesis. This process is lighter and can preserve the state at a chosen block. ### How can I migrate without affecting my Apps/ecosystem on my chain? @@ -103,7 +103,7 @@ Coordinate early with wallets, indexers, bridges, and oracles to repoint routes Zero knowledge (zk) pre-compiles don’t carry over. Port logic to Solidity or Stylus or remove/replace functionality. Please check with your RaaS regarding this matter. -#### What is the process for migrating an existing chain on a different stack to Arbitrum (Orbit) chain? +#### What is the process for migrating an existing chain on a different stack to Arbitrum chain? On a high level, there are two paths for migration: @@ -114,7 +114,7 @@ The rest of this answer assumes that the team wants to perform the latter. For c #### Contracts Migration: -1. Moving escrowed funds from the previous Rollup bridge into an Arbitrum (Orbit) chain bridge +1. Moving escrowed funds from the previous Rollup bridge into an Arbitrum chain bridge #### Node Migration & Set Up: @@ -136,7 +136,7 @@ Here is a rough outline of the tasks you need to complete to ensure a smooth cut #### 2 months before → 4 weeks before migration: planning and thinking - [ ] Choose migration path -- [ ] Select Arbitrum (Orbit) chain mode: Rollup (Ethereum DA) vs. AnyTrust (DA committee) +- [ ] Select Arbitrum chain mode: Rollup (Ethereum DA) vs. AnyTrust (DA committee) - [ ] Chain ID strategy: keep or change. #### 4 weeks before → 3 weeks before migration: alignment @@ -146,10 +146,10 @@ Here is a rough outline of the tasks you need to complete to ensure a smooth cut #### 3 weeks before → 2 weeks before migration: build and test -- [ ] RaaS: set up private Arbitrum (Orbit) chain +- [ ] RaaS: set up private Arbitrum chain - [ ] Testnet deployment: Sequencer, batch poster, staker, DA config. - [ ] Inventory contracts & state: Addresses, precompiles, proxies, admin keys, governance -- [ ] Stand up Dual-RPC gateway prototype: Route pre-migration range to old stack archive; post-migration to Arbitrum (Orbit) chain. +- [ ] Stand up Dual-RPC gateway prototype: Route pre-migration range to old stack archive; post-migration to Arbitrum chain. - [ ] Prepare official asset list: Canonical bridge(s), authoritative token addresses, symbols, decimals. - [ ] Set up monitoring & alerts: Retryables, batches, assertions, DAC liveness. @@ -168,7 +168,7 @@ Here is a rough outline of the tasks you need to complete to ensure a smooth cut - [ ] Stop old chain block/transaction production: disable proposer/sequencer, set legacy RPC to read-only, block `eth_sendRawTransaction` method, thus no new blocks or transactions. - [ ] Take a snapshot or confirm the last block for state replay -- [ ] Bring up the new Arbitrum (Orbit) chain mainnet: import state or launch genesis. +- [ ] Bring up the new Arbitrum chain mainnet: import state or launch genesis. - [ ] Start batch poster/staker and verify assertions on L1. - [ ] Flip DNS for RPC/explorer; enable dual-RPC gateway for historical queries - [ ] Open canonical bridges and publish asset list diff --git a/docs/launch-arbitrum-chain/partials/config-alt-da.mdx b/docs/launch-arbitrum-chain/partials/config-alt-da.mdx index 76cf7f86dd..c19a5faddd 100644 --- a/docs/launch-arbitrum-chain/partials/config-alt-da.mdx +++ b/docs/launch-arbitrum-chain/partials/config-alt-da.mdx @@ -1,4 +1,4 @@ -Arbitrum (Orbit) chains allow companies to launch custom Layer 2 (L2) or Layer 3 (L3) chains using the Arbitrum technology stack. By default, chains can utilize Ethereum for data availability (DA). Still, there is support for alternative DA (Alt-DA) options, such as third-party solutions like Celestia, EigenDA, Avail, or NEAR DA, or Arbitrum's AnyTrust mode, which relies on a Data Availability Committee (DAC). Alt-DA offloads transaction data posting from Ethereum to these alternatives, aiming to optimize for cost and performance. Below are the key pros and cons of using an Alt-DA for an Arbitrum Orbit chain: +Arbitrum chains allow companies to launch custom Layer 2 (L2) or Layer 3 (L3) chains using the Arbitrum technology stack. By default, chains can utilize Ethereum for data availability (DA). Still, there is support for alternative DA (Alt-DA) options, such as third-party solutions like Celestia, EigenDA, Avail, or NEAR DA, or Arbitrum's AnyTrust mode, which relies on a Data Availability Committee (DAC). Alt-DA offloads transaction data posting from Ethereum to these alternatives, aiming to optimize for cost and performance. Below are the key pros and cons of using an Alt-DA for an Arbitrum chain: ### Pros diff --git a/docs/launch-arbitrum-chain/partials/config-challenge-period-l1.mdx b/docs/launch-arbitrum-chain/partials/config-challenge-period-l1.mdx index f71a643590..c25b6be529 100644 --- a/docs/launch-arbitrum-chain/partials/config-challenge-period-l1.mdx +++ b/docs/launch-arbitrum-chain/partials/config-challenge-period-l1.mdx @@ -1,4 +1,4 @@ -Arbitrum (Orbit) chains, as optimistic Rollups, use a challenge period (typically 6.4 days on mainnet chains like Arbitrum One, though customizable in Orbit chains) during which assertions about the L2 state—such as batched transactions—are posted to Ethereum (L1) and remain open to dispute. This process enables a validator that suspects an invalid state transition or fraudulent batch to initiate a challenge by submitting fraud proofs to L1 smart contracts. The enforcement on L1 involves the entire dispute resolution process occurring on Ethereum mainnet: assertions occur on L1, challenges trigger an interactive protocol, and if no valid challenge succeeds by the end of the period, the assertion is confirmed, enabling finality for actions like asset withdrawals or cross-layer messages. This protocol leverages Ethereum's consensus and security without requiring immediate onchain verification for every L2 transaction, assuming optimism (i.e., batches are presumed correct unless proven otherwise). +Arbitrum chains, as optimistic Rollups, use a challenge period (typically 6.4 days on mainnet chains like Arbitrum One, though customizable in chains) during which assertions about the L2 state—such as batched transactions—are posted to Ethereum (L1) and remain open to dispute. This process enables a validator that suspects an invalid state transition or fraudulent batch to initiate a challenge by submitting fraud proofs to L1 smart contracts. The enforcement on L1 involves the entire dispute resolution process occurring on Ethereum mainnet: assertions occur on L1, challenges trigger an interactive protocol, and if no valid challenge succeeds by the end of the period, the assertion is confirmed, enabling finality for actions like asset withdrawals or cross-layer messages. This protocol leverages Ethereum's consensus and security without requiring immediate onchain verification for every L2 transaction, assuming optimism (i.e., batches are presumed correct unless proven otherwise). ## Pros of Having the Challenge Period Enforced on Layer 1 @@ -6,7 +6,7 @@ Arbitrum (Orbit) chains, as optimistic Rollups, use a challenge period (typicall - **Permissionless Validation**: Anyone can participate as a challenger on L1, promoting decentralization and reducing reliance on centralized entities, with the period providing ample time to respond to threats like DoS attacks or L1 consensus failures. - **Cost Efficiency for L2 Operations**: Offloads heavy computation to L2 while using L1 only for disputes, enabling lower fees and higher throughput on Arbitrum chains without compromising on Ethereum's security model. - **Finality Assurance**: Once the period passes without challenges, L2 states achieve L1-equivalent finality, supporting reliable cross-layer interactions and protecting against reversion of confirmed batches. -- **Customizability**: In setups like Arbitrum chains (Orbit), the period can be adjusted (e.g., shorter for lower-risk chains), balancing security with specific use case needs while still enforcing via L1 contracts. +- **Customizability**: In setups like Arbitrum chains, the period can be adjusted (e.g., shorter for lower-risk chains), balancing security with specific use case needs while still enforcing via L1 contracts. ## Cons of having the challenge period enforced on L1 diff --git a/docs/launch-arbitrum-chain/partials/config-custom-gas-token.mdx b/docs/launch-arbitrum-chain/partials/config-custom-gas-token.mdx index ee1aa98891..550855aef2 100644 --- a/docs/launch-arbitrum-chain/partials/config-custom-gas-token.mdx +++ b/docs/launch-arbitrum-chain/partials/config-custom-gas-token.mdx @@ -7,7 +7,7 @@ One key feature is the ability to use an `ERC-20` token (other than `ETH`) as th - **Improved user experience and onboarding**: Users can pay fees with a single native token, eliminating the need to manage multiple assets (e.g., acquiring `ETH` separately). Using a single token can reduce friction, simplifying fee estimation, and enabling features like gas subsidies where projects pay fees on behalf of users, which is ideal for mainstream adoption in gaming or social platforms. - **Unified brand and ecosystem identity**: Interactions stay within the project's token economy, reinforcing branding and immersion (e.g., in-game currencies handling all fees). - **Stability and predictability (with stablecoins)**: Using a stable token like USDC mitigates volatility in transaction costs compared to `ETH`, providing consistent and affordable fees. -- **Integration with existing tools**: Native implementation in Arbitrum Orbit ensures compatibility with EVM tooling, deterministic gas accounting, and seamless deployment. +- **Integration with existing tools**: Native implementation in Arbitrum ensures compatibility with EVM tooling, deterministic gas accounting, and seamless deployment. ### Cons @@ -16,4 +16,4 @@ One key feature is the ability to use an `ERC-20` token (other than `ETH`) as th - **Compatibility issues**: May not work well with applications or tools expecting `ETH`, potentially impacting integration with broader Ethereum ecosystems. - **Increased complexity (account abstraction implementation)**: This adds infrastructure, such as paymasters and bundlers, which complicates gas estimation, transaction flows, and tooling configuration (e.g., for explorers or indexers), with the risk of inconsistent adoption. - **Migration challenges**: Changing or migrating the gas token post-deployment involves high technical risks, including contract updates, chain pauses, and potential loss of funds. -- **Requirements and limitations**: The token must meet specific criteria (e.g., standard `ERC-20`). While supported in Orbit, it relies on chain-wide adoption, which may not be suitable for all cases. +- **Requirements and limitations**: The token must meet specific criteria (e.g., standard `ERC-20`). While supported in, it relies on chain-wide adoption, which may not be suitable for all cases. diff --git a/docs/launch-arbitrum-chain/partials/config-hardware.mdx b/docs/launch-arbitrum-chain/partials/config-hardware.mdx index 2d6824de80..3647fe697d 100644 --- a/docs/launch-arbitrum-chain/partials/config-hardware.mdx +++ b/docs/launch-arbitrum-chain/partials/config-hardware.mdx @@ -1,6 +1,6 @@ ### Hardware requirements for Arbitrum chains -Arbitrum chains, including Arbitrum One, Nova, and customizable Orbit L2/L3 chains, have varying hardware needs depending on the node type. Requirements are generally modest compared to Ethereum L1 nodes, with a focus on accessibility for decentralized participation. The specs are for nodes handling limited RPC requests; scale up for high traffic. Full nodes form the base, with validators and sequencers building on them. Archive nodes require more storage for historical data. +Arbitrum chains, including Arbitrum One, Nova, and customizable Arbitrum L2/L3 chains, have varying hardware needs depending on the node type. Requirements are generally modest compared to Ethereum L1 nodes, with a focus on accessibility for decentralized participation. The specs are for nodes handling limited RPC requests; scale up for high traffic. Full nodes form the base, with validators and sequencers building on them. Archive nodes require more storage for historical data. Key considerations: @@ -8,7 +8,7 @@ Key considerations: - **Bandwidth**: At least 100 Mbps for syncing and RPC; higher for sequencers to minimize latency. - **Storage**: NVMe SSD preferred for speed; data grows over time (e.g., Arbitrum One chain data ~1TB+). - **Scaling**: Increase CPU/RAM for multiple RPC requests or during disputes (e.g., BoLD challenges). Use cloud providers like AWS t3.xlarge for baseline. -- **Orbit-Specific**: Storage requirements are similar. If running AnyTrust, you will need to run your own DAS or use a third-party DA service provider. +- **Arbitrum chain-specific**: Storage requirements are similar. If running AnyTrust, you will need to run your own DAS or use a third-party DA service provider. - **General Tip**: Start with minimums and monitor; overprovision for reliability. No internet access needed post-sync, but initial sync requires a stable connection. #### Full node (base for most setups) @@ -36,15 +36,15 @@ Monitors assertions and challenges fraud. Runs on top of a full node with staker #### Sequencer node -Orders transactions, posts batches. Centralized in main chains (run by Offchain Labs), but customizable in Orbit (e.g., via RaaS like Gelato/Caldera). Focus on low latency; hardware similar to full node but optimized for throughput. +Orders transactions, posts batches. Centralized in main chains (run by Offchain Labs), but customizable for Arbitrum chains (e.g., via RaaS like Gelato/Caldera). Focus on low latency; hardware similar to full node but optimized for throughput. -| Component | Minimum | Recommended | Notes | -| ------------- | ------------------ | ---------------------- | ------------------------------------------------------------------- | -| **CPU** | 4-8 cores | 16+ cores | High clock speed for tx processing; latency-sensitive. | -| **RAM** | 16 GB | 32-64 GB | Handles mempool and batching; more for high TPS Orbit chains. | -| **Storage** | 1 TB NVMe SSD | 2 TB+ | For logs and state; fast I/O critical. | -| **Bandwidth** | 1 Gbps | 10 Gbps+ | Low-latency network; private mempool integration. | -| **Other** | Docker/Nitro stack | Dedicated server/cloud | In Orbit AnyTrust, lower due to DAC; self-host or RaaS for control. | +| Component | Minimum | Recommended | Notes | +| ------------- | ------------------ | ---------------------- | ----------------------------------------------------------------------------------- | +| **CPU** | 4-8 cores | 16+ cores | High clock speed for tx processing; latency-sensitive. | +| **RAM** | 16 GB | 32-64 GB | Handles mempool and batching; more for high TPS Arbitrum chains. | +| **Storage** | 1 TB NVMe SSD | 2 TB+ | For logs and state; fast I/O critical. | +| **Bandwidth** | 1 Gbps | 10 Gbps+ | Low-latency network; private mempool integration. | +| **Other** | Docker/Nitro stack | Dedicated server/cloud | In Arbitrum chains using AnyTrust, lower due to DAC; self-host or RaaS for control. | #### Archive node @@ -58,7 +58,7 @@ Optional for full history querying; builds on full node. **Decisions to Make**: -- **Node Type**: Full for basic, validator for security contribution, sequencer for Orbit sovereignty. +- **Node Type**: Full for basic, validator for security contribution, sequencer for Arbitrum chain sovereignty. - **Chain Mode**: Storage requirements are similar for Rollup or AnyTrust. - **Hosting**: Self-host (control, cost) vs. RaaS/cloud (ease, fees). Start local, scale to VPS. - **BoLD Enablement**: For validators, reduces hardware during disputes but requires an upgrade. diff --git a/docs/launch-arbitrum-chain/partials/config-timeboost.mdx b/docs/launch-arbitrum-chain/partials/config-timeboost.mdx index 06aee62c86..1a56eec664 100644 --- a/docs/launch-arbitrum-chain/partials/config-timeboost.mdx +++ b/docs/launch-arbitrum-chain/partials/config-timeboost.mdx @@ -1,4 +1,4 @@ -Timeboost is an optional transaction ordering policy that is configurable on any Arbitrum chain, including Arbitrum (Orbit) chains. It replaces the First-come, First-served (FCFS) ordering by introducing a sealed-bid, second-price auction for an "express lane." This express lane gives the auction winner a temporary time advantage (default: 200ms) for submitting transactions ahead of others, allowing the chain owner to capture Maximal Extractable Value (MEV) from activities like arbitrage or liquidations. +Timeboost is an optional transaction ordering policy that is configurable on any Arbitrum chain, including Arbitrum chains. It replaces the First-come, First-served (FCFS) ordering by introducing a sealed-bid, second-price auction for an "express lane." This express lane gives the auction winner a temporary time advantage (default: 200ms) for submitting transactions ahead of others, allowing the chain owner to capture Maximal Extractable Value (MEV) from activities like arbitrage or liquidations. | Feature | Pros | Cons | | -------------------------------------- | -------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | -------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | diff --git a/docs/partials/_additional-config-params.mdx b/docs/partials/_additional-config-params.mdx index 88706baeed..f9048bd68f 100644 --- a/docs/partials/_additional-config-params.mdx +++ b/docs/partials/_additional-config-params.mdx @@ -8,21 +8,21 @@ last_reviewed: 2025-01-15
-| Parameter | Description | How to set | -| ---------------------------------------------- | ----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | ----------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | -| **Extra challenge period blocks** | Amount of time to wait before a challenge period expires. Like the challenge period parameter, this is measured in blocks on the underlying L1 chain, not the base (L2) chain. The default for this parameter is 200 blocks, or roughly 40 minutes. | Either in the `extraChallengeTimeBlocks` field in the `RollupCreator` config, or by calling `Rollup.setExtraChallengeTimeBlocks()`. | -| **Loser stake escrow** | The address where funds bonded by a validator that has lost a challenge are sent to be escrowed. It is recommended that this be set to an address that is controlled by the chain owners or to the burn address if the desire is for escrowed funds to be lost. | Either in the `loserStakeEscrow` field in the `RollupCreator` config, or by calling `Rollup.setLoserStakeEscrow()`. | -| **WASM module root** | Hash of the WASM module root to be used when validating. The WASM module root is a 32 byte hash usually expressed in hexadecimal which is a merkelization of the replay binary, which is too large to be posted on-chain. This hash is set in the L1 Rollup contract to determine the correct replay binary during fraud proofs. Unless the STF has been customized, the default WASM module root in the latest consensus release should be used. | Either in the `wasmModuleRoot` field in the `RollupCreator` confid, or by calling `Rollup.setWasmModuleRoot()`. | -| **Gas speed limit** | Target gas usage per second, over which the congestion mechanism activates. This parameter is set to seven million on Arbitrum One and Nova, and alterations to this should be considered carefully, as setting it too high may result in state bloat that impacts the performance of the chain. | Call `ArbOwner.setSpeedLimit()` passing in the maximum number of gas units to be executed per second. | -| **Block gas limit** | Maximum amount of gas that can be consumed by all of the transactions within a block. On Arbitrum One this is set to 30 million. It can comfortably be set higher, but may harm UX as the processing time of a block will increase correspondingly. | Call `ArbOwner.setMaxTxGasLimit()` passing in the maximum number of gas units to be executed per block and transaction. | -| **Gas price floor** | Minimum gas price and is defaulted to 0.1 `gwei`. This can be set lower or higher as needed, and will impact the willingness of users to transact on the network. | Either in the `minL2BaseFee` field in the Arbitrum chain (Orbit) setup script config or by calling `ArbOwner.setMinimumL2BaseFee()` passing in the minimum base fee in `wei`. | -| **Network fee account** | Account that will receive the L2 surplus fees. It is recommended this is set to an address controlled by the chain owners, or the burn address if fees are intended to be burned. If set to zero, this defaults to the owner address. | Either in the `networkFeeReceiver` field in the Arbitrum chain (Orbit) setup script config or by calling `ArbOwner.setNetworkFeeAccount()`. | -| **Infrastructure fee account** | Account that will receive the L2 base fees. It is recommended this is set to an address controlled by the chain owners, or the burn address if fees are intended to be burned. If set to zero, this defaults to the owner address. | Either in the `infrastructureFeeCollector` field in the Arbitrum chain (Orbit) setup script config or by calling `ArbOwner.setInfraFeeAccount()`. | -| **L1 pricing reward recipient** | Address that will receive the rewards from the L1 fees. It is recommended this is set to an address controlled by the chain owners, or the burn address if fees are intended to be burned. By default, this is set to the owner address. | Call `ArbOwner.setL1PricingRewardRecipient()`. | -| **L1 pricing reward per unit (rate)** | Amount of rewards per unit to send to the L1 pricing reward recipient (multiplied by the unitsAllocated). The default for this parameter is 15 `wei`. | Call `ArbOwner.setL1PricingRewardRate()` passing in the amount of `wei` per unit to reward. | -| **Sequencer inbox maximum time variation** | Boundaries of the sequencer to manipulate blocks and timestamps. The default values are as follows, and are set as such on Arbitrum One:
  • `delayBlocks`: 5760
  • `futureBlocks`: 12
  • `delaySeconds`: 86400
  • `futureSeconds`: 3600
| Either in the `sequencerInboxMaxTimeVariation` field in the `RollupCreator` config or by calling `SequencerInbox.setMaxTimeVariation` on the parent chain. | -| **Force-include period** | Length of the period after which a delayed message can be included into the inbox without any action from the sequencer, measured in L1 block time. | Corresponds to `delayBlocks` and `delaySeconds` in the sequencer inbox maximum time variation above. | -| **Batch posting minimum frequency** | Maximum time to wait after a transaction is sent to post a batch containing it. Note that if no transactions are sent, no batches will be posted, regardless of this setting. The default setting is one hour, and can be set lower but may reduce efficiency in the case of low activity on the Arbitrum chain. | `--node.batch-poster.max-delay` in the batch poster config. | -| **Validator node (branch) creation frequency** | Minimum time to wait since the last assertion to post a new assertion, if configured to post new assertions (`MakeNodes`). This is bypassed if there is an incorrect assertion and a dispute needs to be made by making a new assertion. Note that if no new batches are posted (and no force inclusion happens), no new assertions will be posted, regardless of this setting. The default setting is 1 hour and is alterable but should always be greater than the rollup contract's `minimumAssertionPeriod`, which is measured in L1 blocks and is defaulted to 75 blocks, or roughly 15 minutes. | `--node.staker.make-assertion-interval` in the validator config. | +| Parameter | Description | How to set | +| ---------------------------------------------- | ----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | --------------------------------------------------------------------------------------------------------------------------------------------------------------------- | +| **Extra challenge period blocks** | Amount of time to wait before a challenge period expires. Like the challenge period parameter, this is measured in blocks on the underlying L1 chain, not the base (L2) chain. The default for this parameter is 200 blocks, or roughly 40 minutes. | Either in the `extraChallengeTimeBlocks` field in the `RollupCreator` config, or by calling `Rollup.setExtraChallengeTimeBlocks()`. | +| **Loser stake escrow** | The address where funds bonded by a validator that has lost a challenge are sent to be escrowed. It is recommended that this be set to an address that is controlled by the chain owners or to the burn address if the desire is for escrowed funds to be lost. | Either in the `loserStakeEscrow` field in the `RollupCreator` config, or by calling `Rollup.setLoserStakeEscrow()`. | +| **WASM module root** | Hash of the WASM module root to be used when validating. The WASM module root is a 32 byte hash usually expressed in hexadecimal which is a merkelization of the replay binary, which is too large to be posted on-chain. This hash is set in the L1 Rollup contract to determine the correct replay binary during fraud proofs. Unless the STF has been customized, the default WASM module root in the latest consensus release should be used. | Either in the `wasmModuleRoot` field in the `RollupCreator` confid, or by calling `Rollup.setWasmModuleRoot()`. | +| **Gas speed limit** | Target gas usage per second, over which the congestion mechanism activates. This parameter is set to seven million on Arbitrum One and Nova, and alterations to this should be considered carefully, as setting it too high may result in state bloat that impacts the performance of the chain. | Call `ArbOwner.setSpeedLimit()` passing in the maximum number of gas units to be executed per second. | +| **Block gas limit** | Maximum amount of gas that can be consumed by all of the transactions within a block. On Arbitrum One this is set to 30 million. It can comfortably be set higher, but may harm UX as the processing time of a block will increase correspondingly. | Call `ArbOwner.setMaxTxGasLimit()` passing in the maximum number of gas units to be executed per block and transaction. | +| **Gas price floor** | Minimum gas price and is defaulted to 0.1 `gwei`. This can be set lower or higher as needed, and will impact the willingness of users to transact on the network. | Either in the `minL2BaseFee` field in the Arbitrum chain setup script config or by calling `ArbOwner.setMinimumL2BaseFee()` passing in the minimum base fee in `wei`. | +| **Network fee account** | Account that will receive the L2 surplus fees. It is recommended this is set to an address controlled by the chain owners, or the burn address if fees are intended to be burned. If set to zero, this defaults to the owner address. | Either in the `networkFeeReceiver` field in the Arbitrum chain setup script config or by calling `ArbOwner.setNetworkFeeAccount()`. | +| **Infrastructure fee account** | Account that will receive the L2 base fees. It is recommended this is set to an address controlled by the chain owners, or the burn address if fees are intended to be burned. If set to zero, this defaults to the owner address. | Either in the `infrastructureFeeCollector` field in the Arbitrum chain setup script config or by calling `ArbOwner.setInfraFeeAccount()`. | +| **L1 pricing reward recipient** | Address that will receive the rewards from the L1 fees. It is recommended this is set to an address controlled by the chain owners, or the burn address if fees are intended to be burned. By default, this is set to the owner address. | Call `ArbOwner.setL1PricingRewardRecipient()`. | +| **L1 pricing reward per unit (rate)** | Amount of rewards per unit to send to the L1 pricing reward recipient (multiplied by the unitsAllocated). The default for this parameter is 15 `wei`. | Call `ArbOwner.setL1PricingRewardRate()` passing in the amount of `wei` per unit to reward. | +| **Sequencer inbox maximum time variation** | Boundaries of the sequencer to manipulate blocks and timestamps. The default values are as follows, and are set as such on Arbitrum One:
  • `delayBlocks`: 5760
  • `futureBlocks`: 12
  • `delaySeconds`: 86400
  • `futureSeconds`: 3600
| Either in the `sequencerInboxMaxTimeVariation` field in the `RollupCreator` config or by calling `SequencerInbox.setMaxTimeVariation` on the parent chain. | +| **Force-include period** | Length of the period after which a delayed message can be included into the inbox without any action from the sequencer, measured in L1 block time. | Corresponds to `delayBlocks` and `delaySeconds` in the sequencer inbox maximum time variation above. | +| **Batch posting minimum frequency** | Maximum time to wait after a transaction is sent to post a batch containing it. Note that if no transactions are sent, no batches will be posted, regardless of this setting. The default setting is one hour, and can be set lower but may reduce efficiency in the case of low activity on the Arbitrum chain. | `--node.batch-poster.max-delay` in the batch poster config. | +| **Validator node (branch) creation frequency** | Minimum time to wait since the last assertion to post a new assertion, if configured to post new assertions (`MakeNodes`). This is bypassed if there is an incorrect assertion and a dispute needs to be made by making a new assertion. Note that if no new batches are posted (and no force inclusion happens), no new assertions will be posted, regardless of this setting. The default setting is 1 hour and is alterable but should always be greater than the rollup contract's `minimumAssertionPeriod`, which is measured in L1 blocks and is defaulted to 75 blocks, or roughly 15 minutes. | `--node.staker.make-assertion-interval` in the validator config. |
diff --git a/docs/partials/_gentle-intro-partial.mdx b/docs/partials/_gentle-intro-partial.mdx index 1b4475a344..11c5d88d33 100644 --- a/docs/partials/_gentle-intro-partial.mdx +++ b/docs/partials/_gentle-intro-partial.mdx @@ -90,9 +90,9 @@ Here’s a snapshot of the chains running on Arbitrum: - ["Nova"](https://nova.arbitrum.io/): an AnyTrust Chain operated by the [Arbitrum Foundation](https://arbitrum.foundation) - On Arbitrum One and Nova: - - Various L3 Arbitrum (Orbit) chain + - Various L3 Arbitrum chain - On other L2s: - - Various L2 Arbitrum (Orbit) chain + - Various L2 Arbitrum chain - + @@ -105,7 +105,7 @@ If you are running more than on node, you should [run a feed relay](/run-arbitru - + diff --git a/docs/run-arbitrum-node/arbos-releases/01-overview.mdx b/docs/run-arbitrum-node/arbos-releases/01-overview.mdx index 5db55b5bbd..47baaeaa01 100644 --- a/docs/run-arbitrum-node/arbos-releases/01-overview.mdx +++ b/docs/run-arbitrum-node/arbos-releases/01-overview.mdx @@ -50,7 +50,7 @@ To view the status and timeline of network upgrades on Arbitrum One and Nova, [p ## Expectations for Arbitrum chain owners -For Arbitrum (Orbit) chain owners or maintainers: it is important to note that _before_ upgrading your Arbitrum chain(s) to the newest ArbOS release, we strongly encourage waiting at least four weeks after the new ArbOS release becomes active on Arbitrum One and Nova before attempting the upgrade yourself. The rationale behind this short time buffer is to allow the Offchain Labs team to address any upgrade issues or stability concerns that may arise with the initial rollout so that we can minimize the chances of your chain(s) hitting the same or similar issues and to maximize the likelihood of an eventual smooth, seamless upgrade. Arbitrum Orbit chains, as always, can pick up new features & enable new customizations as they see fit. However, this delay ensures a consistent user experience (UX) across all Arbitrum chain owners and managers for these critical upgrades. +For Arbitrum chain owners or maintainers: it is important to note that _before_ upgrading your Arbitrum chain(s) to the newest ArbOS release, we strongly encourage waiting at least four weeks after the new ArbOS release becomes active on Arbitrum One and Nova before attempting the upgrade yourself. The rationale behind this short time buffer is to allow the Offchain Labs team to address any upgrade issues or stability concerns that may arise with the initial rollout so that we can minimize the chances of your chain(s) hitting the same or similar issues and to maximize the likelihood of an eventual smooth, seamless upgrade. Arbitrum chains, as always, can pick up new features & enable new customizations as they see fit. However, this delay ensures a consistent user experience (UX) across all Arbitrum chain owners and managers for these critical upgrades. Note that enabling an ArbOS upgrade is not as simple as bumping your chain’s Nitro node version. Instead, there are other steps required that are outlined in our docs on [How to upgrade ArbOS on your Arbitrum chain](/launch-arbitrum-chain/02-configure-your-chain/common-configurations/13-arbos-upgrade.mdx). Please be sure to follow them and let us know if you encounter any issues. diff --git a/docs/run-arbitrum-node/arbos-releases/arbos32.mdx b/docs/run-arbitrum-node/arbos-releases/arbos32.mdx index 165bf99d6b..a160818aae 100644 --- a/docs/run-arbitrum-node/arbos-releases/arbos32.mdx +++ b/docs/run-arbitrum-node/arbos-releases/arbos32.mdx @@ -48,7 +48,7 @@ In order to take advantage of this caching strategy, an additional step is requi ### Additional requirement for Arbitrum chains who wish to enable Fast Withdrawals -After you have upgraded your Arbitrum chain (Orbit) to ArbOS 32 "Bianca" (i.e., you have fully completed [Step 3 in the "How to upgrade ArbOS on your Arbitrum chain" guide](/launch-arbitrum-chain/02-configure-your-chain/common-configurations/13-arbos-upgrade.mdx#step-3-schedule-the-arbos-version-upgrade) for your Arbitrum chain), please follow [these additional instructions](https://github.com/OffchainLabs/orbit-actions/tree/main/scripts/foundry/fast-confirm) in the `orbit-actions` repository to deploy the Safe contract for the fast confirmation committee and set the Safe contract to be both the validator and fast confirmer on your rollup, note that Fast Withdrawals is disabled by default unless explicitly set up and enabled by the Arbitrum chain owner/maintainer. +After you have upgraded your Arbitrum chain to ArbOS 32 "Bianca" (i.e., you have fully completed [Step 3 in the "How to upgrade ArbOS on your Arbitrum chain" guide](/launch-arbitrum-chain/02-configure-your-chain/common-configurations/13-arbos-upgrade.mdx#step-3-schedule-the-arbos-version-upgrade) for your Arbitrum chain), please follow [these additional instructions](https://github.com/OffchainLabs/orbit-actions/tree/main/scripts/foundry/fast-confirm) in the `orbit-actions` repository to deploy the Safe contract for the fast confirmation committee and set the Safe contract to be both the validator and fast confirmer on your rollup, note that Fast Withdrawals is disabled by default unless explicitly set up and enabled by the Arbitrum chain owner/maintainer. ### Reference links for ArbOS 32 Bianca diff --git a/docs/run-arbitrum-node/beacon-nodes-historical-blobs.mdx b/docs/run-arbitrum-node/beacon-nodes-historical-blobs.mdx index 4699d5d9b8..7b1a40aa36 100644 --- a/docs/run-arbitrum-node/beacon-nodes-historical-blobs.mdx +++ b/docs/run-arbitrum-node/beacon-nodes-historical-blobs.mdx @@ -13,7 +13,7 @@ Layer 2 network operators must connect to an Ethereum beacon chain node with his ## Impacted audiences -Required action will be required from: RPC nodes, Arbitrum One / Nova node operators, Arbitrum (Orbit) chain node operators +Required action will be required from: RPC nodes, Arbitrum One / Nova node operators, Arbitrum chain node operators #### If you run a Nitro node and use an external L1 Ethereum beacon chain RPC URL diff --git a/docs/run-arbitrum-node/more-types/02-run-validator-node.mdx b/docs/run-arbitrum-node/more-types/02-run-validator-node.mdx index f72a46fc96..aabbaf2b64 100644 --- a/docs/run-arbitrum-node/more-types/02-run-validator-node.mdx +++ b/docs/run-arbitrum-node/more-types/02-run-validator-node.mdx @@ -99,7 +99,7 @@ Furthermore, the following logs will indicate that all components are working as ## Run a validator for an Arbitrum chain -Validation for Arbitrum chains (Orbit) works the same way as for DAO-governed Arbitrum chains. However, as specified in [How to run a node](/run-arbitrum-node/02-run-full-node.mdx#required-parameters), you need to include the information of the chain when configuring your node by using `--chain.info-json`. +Validation for Arbitrum chains works the same way as for DAO-governed Arbitrum chains. However, as specified in [How to run a node](/run-arbitrum-node/02-run-full-node.mdx#required-parameters), you need to include the information of the chain when configuring your node by using `--chain.info-json`. ```shell --chain.info-json= diff --git a/docs/run-arbitrum-node/partials/run-full-node/_optional-orbit-sequencer-compatible-cli-partial.mdx b/docs/run-arbitrum-node/partials/run-full-node/_optional-orbit-sequencer-compatible-cli-partial.mdx index 32e0e98f23..852f1e05f4 100644 --- a/docs/run-arbitrum-node/partials/run-full-node/_optional-orbit-sequencer-compatible-cli-partial.mdx +++ b/docs/run-arbitrum-node/partials/run-full-node/_optional-orbit-sequencer-compatible-cli-partial.mdx @@ -1,46 +1,46 @@
-| Flag | Description | -| --------------------------------------------------------- | ------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | -| `--execution.rpc.classic-redirect=` | Redirects archive requests for pre-nitro blocks to this RPC of an Arbitrum Classic node with an archive database, **only for Arbitrum One**. | -| `--execution.rpc.classic-redirect=` | Redirects archive requests for pre-nitro blocks to this RPC from an Arbitrum Classic node with an archive database, **only for Arbitrum One**. | -| `--http.api` | Which APIs need to be opened over the HTTP-RPC interface. Default: `net,web3,eth,arb`. Add `debug` for tracing. | -| `--http.corsdomain` | Accepts cross origin requests from these comma-separated domains (browser enforced). | -| `--http.vhosts` | Accepts requests from these comma-separated virtual hostnames (server enforced). Default: `localhost`. Accepts `*`. | -| `--http.addr` | Address to bind RPC to. May require `0.0.0.0` for Docker networking. | -| `--execution.caching.archive` | Will retain past block state. **For archive nodes**. | -| `--node.feed.input.url=` | Default: `wss://.arbitrum.io/feed`. ⚠️ One feed relay per datacenter is advised. See [feed relay guide](/run-arbitrum-node/run-feed-relay.mdx). | -| `--execution.rpc.evm-timeout` | Default: `5s`. Timeout for `eth_call`. (`0` == no timeout). | -| `--execution.rpc.gas-cap` | Default: `50000000`. Gas cap for `eth_call`/`estimateGas`. (`0` = no cap). | -| `--execution.rpc.tx-fee-cap` | Default: `1`. Transaction fee cap (in `ETH`) for RPC APIs. (`0` = no cap). | -| `--ipc.path` | Filename for IPC socket/pipe within `datadir`. Not supported on macOS. **Note**: The path is within the Docker container. | -| `--init.prune` | Prunes database before starting the node. It can be used for **full** or **validator** nodes. | -| `--init.url=""` | **Non-Orbit Nitro nodes only**: URL from which to download the genesis database. Required only for the first startup of an Arbitrum One node. Reference to [snapshots](https://snapshot.arbitrum.foundation/index.html) and [archive node guide](/run-arbitrum-node/more-types/01-run-archive-node.mdx). | -| `--init.download-path="/path/to/dir"` | **Non-Orbit Nitro nodes only**: Temporarily saves the downloaded database snapshot. Defaults to `/tmp/`. Used with `--init.url`. | -| `--node.batch-poster.post-4844-blobs` | Boolean. Default: `false`. Used to enable or disable the posting of transaction data using Blobs to Ethereum mainnet. If using calldata is more expensive and the parent chain supports `EIP4844` blobs, the batch poster will use blobs when this flag is set to `true`. It can be set to `true` or `false`. | -| `--node.batch-poster.ignore-blob-price` | Boolean. Default: `false`. If the parent chain supports `EIP4844` blobs and `ignore-blob-price` is set to `true`, the batch poster will use `EIP4844` blobs even if using calldata is cheaper. It can be set to `true` or `false`. | -| `--execution.sequencer.enable` | Act as sequencer and post to L1. | -| `--execution.sequencer.enable-profiling` | Enable CPU profiling and tracing. | -| `--execution.sequencer.expected-surplus-hard-threshold` | If the expected surplus is lower than this value, new incoming transactions will be denied (default "default"). | -| `--execution.sequencer.expected-surplus-soft-threshold` | Warnings are posted if the expected surplus is lower than this value (default "default"). | -| `--execution.sequencer.forwarder.connection-timeout` | Total time to wait before canceling connection (default 30s). | -| `--execution.sequencer.forwarder.idle-connection-timeout` | Time until idle connections are closed (default 1m0s). | -| `--execution.sequencer.forwarder.max-idle-connections` | Maximum number of idle connections to keep open (default `100`). | -| `--execution.sequencer.forwarder.redis-url` | The recommended Redis URL to use as target. | -| `--execution.sequencer.forwarder.retry-interval` | Minimal time between update retries (default 100ms). | -| `--execution.sequencer.forwarder.update-interval` | Forwarding target update interval (default 1s). | -| `--execution.sequencer.max-acceptable-timestamp-delta` | Maximum acceptable time difference between the local time and the latest L1 block's timestamp (default 1h0m0s). | -| `--execution.sequencer.max-block-speed` | Minimum delay between blocks (sets a maximum speed of block production) (default 250ms). | -| `--execution.sequencer.max-revert-gas-reject` | Maximum gas executed in a revert for the sequencer to reject the transaction instead of posting it (anti-DOS). | -| `--execution.sequencer.max-tx-data-size` | Maximum transaction size the sequencer will accept (default `95000`). | -| `--execution.sequencer.nonce-cache-size` | Size of the transaction sender nonce cache (default `1024`). | -| `--execution.sequencer.nonce-failure-cache-expiry` | Maximum time to wait for a predecessor before rejecting a transaction whose nonce is too high (default 1s). | -| `--execution.sequencer.nonce-failure-cache-size` | Number of transactions whose nonce is too high to keep in memory while waiting for their predecessor (default `1024`). | -| `--execution.sequencer.queue-size` | Size of the pending transaction queue (default `1024`). | -| `--execution.sequencer.queue-timeout` | Maximum time a transaction can wait in a queue (default 12s). | -| `--execution.sequencer.sender-whitelist` | Comma-separated allowlist of authorized senders (if empty, every sender is allowed). | -| `--node.delayed-sequencer.finalize-distance` | Number of blocks in the past L1 block for the transaction to be considered final. This value is ignored when using merge finality. Default: `20`. | -| `--node.delayed-sequencer.require-full-finality` | Whether to wait for full finality before sequencing delayed messages. | -| `--node.delayed-sequencer.use-merge-finality` | Whether to use The Merge's notion of finality before sequencing delayed messages (default to `true`). | +| Flag | Description | +| --------------------------------------------------------- | ----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | +| `--execution.rpc.classic-redirect=` | Redirects archive requests for pre-nitro blocks to this RPC of an Arbitrum Classic node with an archive database, **only for Arbitrum One**. | +| `--execution.rpc.classic-redirect=` | Redirects archive requests for pre-nitro blocks to this RPC from an Arbitrum Classic node with an archive database, **only for Arbitrum One**. | +| `--http.api` | Which APIs need to be opened over the HTTP-RPC interface. Default: `net,web3,eth,arb`. Add `debug` for tracing. | +| `--http.corsdomain` | Accepts cross origin requests from these comma-separated domains (browser enforced). | +| `--http.vhosts` | Accepts requests from these comma-separated virtual hostnames (server enforced). Default: `localhost`. Accepts `*`. | +| `--http.addr` | Address to bind RPC to. May require `0.0.0.0` for Docker networking. | +| `--execution.caching.archive` | Will retain past block state. **For archive nodes**. | +| `--node.feed.input.url=` | Default: `wss://.arbitrum.io/feed`. ⚠️ One feed relay per datacenter is advised. See [feed relay guide](/run-arbitrum-node/run-feed-relay.mdx). | +| `--execution.rpc.evm-timeout` | Default: `5s`. Timeout for `eth_call`. (`0` == no timeout). | +| `--execution.rpc.gas-cap` | Default: `50000000`. Gas cap for `eth_call`/`estimateGas`. (`0` = no cap). | +| `--execution.rpc.tx-fee-cap` | Default: `1`. Transaction fee cap (in `ETH`) for RPC APIs. (`0` = no cap). | +| `--ipc.path` | Filename for IPC socket/pipe within `datadir`. Not supported on macOS. **Note**: The path is within the Docker container. | +| `--init.prune` | Prunes database before starting the node. It can be used for **full** or **validator** nodes. | +| `--init.url=""` | **Non-Arbitrum chain Nitro nodes only**: URL from which to download the genesis database. Required only for the first startup of an Arbitrum One node. Reference to [snapshots](https://snapshot.arbitrum.foundation/index.html) and [archive node guide](/run-arbitrum-node/more-types/01-run-archive-node.mdx). | +| `--init.download-path="/path/to/dir"` | **Non-Arbitrum chain Nitro nodes only**: Temporarily saves the downloaded database snapshot. Defaults to `/tmp/`. Used with `--init.url`. | +| `--node.batch-poster.post-4844-blobs` | Boolean. Default: `false`. Used to enable or disable the posting of transaction data using Blobs to Ethereum mainnet. If using calldata is more expensive and the parent chain supports `EIP4844` blobs, the batch poster will use blobs when this flag is set to `true`. It can be set to `true` or `false`. | +| `--node.batch-poster.ignore-blob-price` | Boolean. Default: `false`. If the parent chain supports `EIP4844` blobs and `ignore-blob-price` is set to `true`, the batch poster will use `EIP4844` blobs even if using calldata is cheaper. It can be set to `true` or `false`. | +| `--execution.sequencer.enable` | Act as sequencer and post to L1. | +| `--execution.sequencer.enable-profiling` | Enable CPU profiling and tracing. | +| `--execution.sequencer.expected-surplus-hard-threshold` | If the expected surplus is lower than this value, new incoming transactions will be denied (default "default"). | +| `--execution.sequencer.expected-surplus-soft-threshold` | Warnings are posted if the expected surplus is lower than this value (default "default"). | +| `--execution.sequencer.forwarder.connection-timeout` | Total time to wait before canceling connection (default 30s). | +| `--execution.sequencer.forwarder.idle-connection-timeout` | Time until idle connections are closed (default 1m0s). | +| `--execution.sequencer.forwarder.max-idle-connections` | Maximum number of idle connections to keep open (default `100`). | +| `--execution.sequencer.forwarder.redis-url` | The recommended Redis URL to use as target. | +| `--execution.sequencer.forwarder.retry-interval` | Minimal time between update retries (default 100ms). | +| `--execution.sequencer.forwarder.update-interval` | Forwarding target update interval (default 1s). | +| `--execution.sequencer.max-acceptable-timestamp-delta` | Maximum acceptable time difference between the local time and the latest L1 block's timestamp (default 1h0m0s). | +| `--execution.sequencer.max-block-speed` | Minimum delay between blocks (sets a maximum speed of block production) (default 250ms). | +| `--execution.sequencer.max-revert-gas-reject` | Maximum gas executed in a revert for the sequencer to reject the transaction instead of posting it (anti-DOS). | +| `--execution.sequencer.max-tx-data-size` | Maximum transaction size the sequencer will accept (default `95000`). | +| `--execution.sequencer.nonce-cache-size` | Size of the transaction sender nonce cache (default `1024`). | +| `--execution.sequencer.nonce-failure-cache-expiry` | Maximum time to wait for a predecessor before rejecting a transaction whose nonce is too high (default 1s). | +| `--execution.sequencer.nonce-failure-cache-size` | Number of transactions whose nonce is too high to keep in memory while waiting for their predecessor (default `1024`). | +| `--execution.sequencer.queue-size` | Size of the pending transaction queue (default `1024`). | +| `--execution.sequencer.queue-timeout` | Maximum time a transaction can wait in a queue (default 12s). | +| `--execution.sequencer.sender-whitelist` | Comma-separated allowlist of authorized senders (if empty, every sender is allowed). | +| `--node.delayed-sequencer.finalize-distance` | Number of blocks in the past L1 block for the transaction to be considered final. This value is ignored when using merge finality. Default: `20`. | +| `--node.delayed-sequencer.require-full-finality` | Whether to wait for full finality before sequencing delayed messages. | +| `--node.delayed-sequencer.use-merge-finality` | Whether to use The Merge's notion of finality before sequencing delayed messages (default to `true`). |
diff --git a/docs/run-arbitrum-node/partials/run-full-node/_orbit-chains-parameters.mdx b/docs/run-arbitrum-node/partials/run-full-node/_orbit-chains-parameters.mdx index 09179b996a..36fcc0201f 100644 --- a/docs/run-arbitrum-node/partials/run-full-node/_orbit-chains-parameters.mdx +++ b/docs/run-arbitrum-node/partials/run-full-node/_orbit-chains-parameters.mdx @@ -32,7 +32,7 @@ You can find beacon providers in our [list of Ethereum beacon chain RPC provider #### 2. Child chain parameters -The parameter `--chain.info-json` specifies a JSON string that contains the information about the Arbitrum (Orbit) chain required by the node. +The parameter `--chain.info-json` specifies a JSON string that contains the information about the Arbitrum chain required by the node. ```shell --chain.info-json= @@ -58,7 +58,7 @@ Use the parameter `--node.feed.input.url` to point at the sequencer feed endpoin --node.feed.input.url= ``` -Use the parameter `--execution.forwarding-target` to point at the sequencer node of the Arbitrum (Orbit) chain, which should also be provided by the chain owner. +Use the parameter `--execution.forwarding-target` to point at the sequencer node of the Arbitrum chain, which should also be provided by the chain owner. ```shell --execution.forwarding-target= diff --git a/docs/run-arbitrum-node/sequencer/04-run-sequencer-node.mdx b/docs/run-arbitrum-node/sequencer/04-run-sequencer-node.mdx index 500811f52c..1512e2a4e4 100644 --- a/docs/run-arbitrum-node/sequencer/04-run-sequencer-node.mdx +++ b/docs/run-arbitrum-node/sequencer/04-run-sequencer-node.mdx @@ -1,6 +1,6 @@ --- -title: 'How to run a normal sequencer node for an Orbit chain' -description: Learn how to run an normal Arbitrum orbit sequencer node on your local machine +title: 'How to run a normal sequencer node for an Arbitrum chain' +description: Learn how to run an normal Arbitrum chain sequencer node on your local machine author: Jason Wan sme: Jason Wan content_type: how-to @@ -8,9 +8,9 @@ content_type: how-to :::caution -The following instructions are meant for Arbitrum Orbit chains only. This article only applies to test environments. If you need support spinning up a production Orbit chain, we recommend contacting a [provider](/launch-arbitrum-chain/06-third-party-integrations/02-third-party-providers.md#rollup-as-a-service-raas-providers). +The following instructions are meant for Arbitrum chains only. This article only applies to test environments. If you need support spinning up a production Arbitrum chain, we recommend contacting a [provider](/launch-arbitrum-chain/06-third-party-integrations/02-third-party-providers.md#rollup-as-a-service-raas-providers). -We also provide a guide for running a high-availability sequencer node for an Orbit chain. You can find it [here](./05-high-availability-sequencer-docs.mdx). +We also provide a guide for running a high-availability sequencer node for an Arbitrum chain. You can find it [here](./05-high-availability-sequencer-docs.mdx). ::: This how-to provides step-by-step instructions for running a sequencer node on your local machine. @@ -196,7 +196,7 @@ chmod -fR 777 /data/arbitrum ## Optional parameters -Here's a list of the parameters that are most commonly used when running your Orbit sequencer node. You can also use the flag `--help` for a comprehensive list of available parameters. +Here's a list of the parameters that are most commonly used when running your Arbitrum chain sequencer node. You can also use the flag `--help` for a comprehensive list of available parameters. import OptionalOrbitSequencerCompatibleCLIFlagsPartial from '../partials/run-full-node/_optional-orbit-sequencer-compatible-cli-partial.mdx'; From 2110ae677707f4d87e5b708ceb96d4f7c8c81ae1 Mon Sep 17 00:00:00 2001 From: Pete Date: Thu, 13 Nov 2025 12:50:19 -0600 Subject: [PATCH 02/10] Updating glossary and FAQs --- docs/partials/_glossary-partial.mdx | 4 +- ...troubleshooting-arbitrum-chain-partial.mdx | 50 +++++++-------- .../_troubleshooting-bridging-partial.mdx | 8 --- .../_troubleshooting-building-partial.mdx | 10 +-- .../_troubleshooting-nodes-partial.mdx | 14 +---- .../_troubleshooting-stylus-partial.mdx | 8 --- .../_troubleshooting-users-partial.mdx | 8 --- static/building-faqs.json | 2 +- static/building-orbit-faqs.json | 62 +++++++++---------- static/glossary.json | 14 ++--- 10 files changed, 66 insertions(+), 114 deletions(-) diff --git a/docs/partials/_glossary-partial.mdx b/docs/partials/_glossary-partial.mdx index b7cadaa4b3..8aee4296a8 100644 --- a/docs/partials/_glossary-partial.mdx +++ b/docs/partials/_glossary-partial.mdx @@ -3,7 +3,7 @@ partial_type: glossary title: 'Arbitrum Glossary Definitions' description: 'Comprehensive glossary of Arbitrum terminology and definitions' author: anegg0 -last_reviewed: 2025-10-16 +last_reviewed: 2025-11-13 --- ### Active Validator {#active-validator} @@ -49,7 +49,7 @@ A blockchain that runs on the Arbitrum protocol. Arbitrum chains are EVM compati ### Arbitrum Chains {#arbitrum-chains} -Arbitrum chains (Orbit) refers to the ability for anyone to permissionlessly deploy [Layer 3 (L3)](/intro/glossary#layer-3-l3) chains on top of Arbitrum [Layer 2 (L2)](/intro/glossary#layer-2-l2) chains. +Arbitrum chains refers to the ability for anyone to permissionlessly deploy [Layer 3 (L3)](/intro/glossary#layer-3-l3) chains on top of Arbitrum [Layer 2 (L2)](/intro/glossary#layer-2-l2) chains. ### Arbitrum Classic {#arbitrum-classic} diff --git a/docs/partials/_troubleshooting-arbitrum-chain-partial.mdx b/docs/partials/_troubleshooting-arbitrum-chain-partial.mdx index e300b39366..ec31f66b5c 100644 --- a/docs/partials/_troubleshooting-arbitrum-chain-partial.mdx +++ b/docs/partials/_troubleshooting-arbitrum-chain-partial.mdx @@ -1,67 +1,59 @@ ---- -partial_type: troubleshooting -title: 'Arbitrum Chain Troubleshooting Guide' -description: 'Common issues and solutions for Arbitrum chain operations' -author: anegg0 -last_reviewed: 2025-11-06 ---- +### Can I use the Chain SDK to deploy a mainnet chain? -### Can I use Orbit to deploy a mainnet chain? +Yes! The Arbitrum Chain SDK's core technology has undergone a comprehensive audit and is now capable of supporting deployments to mainnet. You can read more about it [here](https://docs.arbitrum.io/launch-orbit-chain/concepts/public-preview-expectations#arbitrum-orbit-is-mainnet-ready-but-deploy-to-testnet-first). -Yes! Arbitrum Orbit's core technology has undergone a comprehensive audit and is now capable of supporting deployments to mainnet. You can read more about it [in our public preview annoucement](https://docs.arbitrum.io/launch-orbit-chain/concepts/public-preview-expectations#arbitrum-orbit-is-mainnet-ready-but-deploy-to-testnet-first). +### Do I need permission/license to launch an Arbitrum chain? -### Do I need permission/license to launch an Orbit chain? - -You can launch any Arbitrum Orbit chain permissionlessly. +You can launch any Arbitrum chain permissionlessly. Nitro's license is under a [Business Source license](https://github.com/OffchainLabs/nitro?tab=License-1-ov-file), similar to DeFi protocols like Uniswap and Aave, among others. This license contains an Additional Use Grant that permits the permissionless deployment of Nitro software on blockchains that settle to Arbitrum One or Nova. -However, Arbitrum Orbit chains that settle to a parent chain other than Arbitrum One or Nova are subject to additional licensing guidelines under the [AEP](https://docs.arbitrum.foundation/aep/ArbitrumExpansionProgramTerms.pdf). +However, Arbitrum chains that settle to a parent chain other than Arbitrum One or Nova are subject to additional licensing guidelines under the [AEP](https://docs.arbitrum.foundation/aep/ArbitrumExpansionProgramTerms.pdf). ### Does Arbitrum officially deploy and/or maintain L3s for external teams? No. Teams are required to deploy and maintain their Arbitrum Orbit chains. There are, however, several RaaS (Rollup as a Service) providers that can deploy and maintain your Arbitrum Orbit chain on your behalf. -### Can I modify Orbit's underlying technology to customize my chain? +### Can I modify the underlying technology to customize my Arbitrum chain? Yes, you can make any changes you require to the underlying Nitro code base. -### What Data Availability (DA) solutions are currently available for Orbit chains? +### What Data Availability (DA) solutions are currently available for Arbitrum chains? -Arbitrum Orbit currently supports three different DA solutions: +Arbitrum chains currently support three different DA solutions: - Rollup, posting data to the parent chain, which ultimately posts the data to Ethereum. - AnyTrust, posting data to a Data Availability Committee, selected by the chain owner. - Celestia, posting data to the [Celestia network](https://blog.celestia.org/celestia-is-first-modular-data-availability-network-to-integrate-with-arbitrum-orbit/). Note that using AnyTrust provides the chain owner with the most flexibility and the most cost-effective fees. -### What token is used to pay gas fees on Orbit chains? +### What token is used to pay gas fees on Arbitrum chains? -By default, Arbitrum Orbit chains pay gas in `ETH`. However, Arbitrum Orbit chains that use AnyTrust are configurable to use any `ERC-20` token for the gas fee token of the chain. +By default, Arbitrum chains pay gas in `ETH`. However, Arbitrum chains that use AnyTrust are configurable to use any `ERC-20` token for the gas fee token of the chain. -### Can I use Ethereum toolkits to develop on my Orbit chain? +### Can I use Ethereum toolkits to develop on my Arbitrum chain? -Arbitrum Orbit chains are fully EVM-compatible. Most tools that support Ethereum should be able to support an Arbitrum Orbit chain. There are, however, specific differences that developers need to consider when building on an Orbit chain. You can find them [in our Arbitrum vs. Ethereum overview](https://docs.arbitrum.io/for-devs/concepts/differences-between-arbitrum-ethereum/overview). +Arbitrum chains are fully EVM-compatible. Most tools that support Ethereum should be able to support an Arbitrum chain. There are, however, specific differences that developers need to consider when building on an Arbitrum chain. You can find them [here](https://docs.arbitrum.io/for-devs/concepts/differences-between-arbitrum-ethereum/overview). -### Do Orbit chains have any built-in AA solution? +### Do Arbitrum chains have any built-in AA solution? Not by default, but they can be customized to have native AA. -### Is there any cross-chain bridging solution between two Orbit chains? +### Is there any cross-chain bridging solution between two Arbitrum chains? -There is currently no native Orbit-to-Orbit chain bridging solution, except for going through the parent chain (even if they share the same parent chain). However, many third-party bridges have expressed interest in supporting Arbitrum Orbit chains. +There is currently no native Arbitrum-to-Arbitrum chain bridging solution, except for going through the parent chain (even if they share the same parent chain). However, many third-party bridges have expressed interest in supporting Arbitrum chains. -### Is there an official block explorer for Orbit chains? +### Is there an official block explorer for Arbitrum chains? -Arbitrum Orbit chains deployments usually come with an open-source Blockscout explorer by default, but there are many third-party solutions that have expressed interest in supporting Arbitrum Orbit chains. +Arbitrum chains deployments usually come with an open-source Blockscout explorer by default, but there are many third-party solutions that have expressed interest in supporting Arbitrum chains. -### Is there any indexing solution that supports Orbit chains? +### Is there any indexing solution that supports Arbitrum chains? -Similar to bridges and block explorers, there are many third-party indexing solutions that have expressed interest in supporting Arbitrum Orbit chains. +Similar to bridges and block explorers, there are many third-party indexing solutions that have expressed interest in supporting Arbitrum chains. -### Can I increase the maximum contract size for my Orbit chain? +### Can I increase the maximum contract size for my Arbitrum chain? -Yes, Arbitrum Orbit chains support an increased smart contract size limit of up to 96kB. You can use our [Chain SDK](https://github.com/OffchainLabs/arbitrum-orbit-sdk) and configure the parameters `[MaxCodeSize](https://github.com/OffchainLabs/arbitrum-orbit-sdk/blob/main/src/prepareChainConfig.ts#L29)`[ and ](https://github.com/OffchainLabs/arbitrum-orbit-sdk/blob/main/src/prepareChainConfig.ts#L29)`[MaxInitCodeSize](https://github.com/OffchainLabs/arbitrum-orbit-sdk/blob/main/src/prepareChainConfig.ts#L29)` when calling `[prepareNodeConfig](https://github.com/OffchainLabs/arbitrum-orbit-sdk/blob/main/examples/prepare-node-config/index.ts#L43)`. Once deployed, you cannot change the parameters for the smart contract size limit through an upgrade. +Yes, Arbitrum chains support an increased smart contract size limit of up to 96kB. You can use our [Chain SDK](https://github.com/OffchainLabs/arbitrum-orbit-sdk) and configure the parameters `[MaxCodeSize](https://github.com/OffchainLabs/arbitrum-orbit-sdk/blob/main/src/prepareChainConfig.ts#L29)`[ and ](https://github.com/OffchainLabs/arbitrum-orbit-sdk/blob/main/src/prepareChainConfig.ts#L29)`[MaxInitCodeSize](https://github.com/OffchainLabs/arbitrum-orbit-sdk/blob/main/src/prepareChainConfig.ts#L29)` when calling `[prepareNodeConfig](https://github.com/OffchainLabs/arbitrum-orbit-sdk/blob/main/examples/prepare-node-config/index.ts#L43)`. Once deployed, you cannot change the parameters for the smart contract size limit through an upgrade. ### How can I modify Nitro to force posting an invalid assertion and test the fraud proof mechanism? diff --git a/docs/partials/_troubleshooting-bridging-partial.mdx b/docs/partials/_troubleshooting-bridging-partial.mdx index 43cc06fbfc..7172a50dd8 100644 --- a/docs/partials/_troubleshooting-bridging-partial.mdx +++ b/docs/partials/_troubleshooting-bridging-partial.mdx @@ -1,11 +1,3 @@ ---- -partial_type: troubleshooting -title: 'Bridging Troubleshooting Guide' -description: 'Common issues and solutions for bridging assets to/from Arbitrum' -author: anegg0 -last_reviewed: 2025-11-06 ---- - ### How do I move assets between One and Nova? Both Arbitrum One and Arbitrum Nova run as layers on top of Ethereum. Thus, you can always move assets between the two chains in two steps by going "through" Ethereum. In other words: withdraw your assets from Arbitrum One to Ethereum and then deposit them onto Nova, or conversely, withdraw your assets from Nova to Ethereum and then deposit them to Arbitrum One. You can complete these steps using the [Arbitrum Bridge](https://bridge.arbitrum.io/). diff --git a/docs/partials/_troubleshooting-building-partial.mdx b/docs/partials/_troubleshooting-building-partial.mdx index f1496f7d10..b4d9bf8bea 100644 --- a/docs/partials/_troubleshooting-building-partial.mdx +++ b/docs/partials/_troubleshooting-building-partial.mdx @@ -1,11 +1,3 @@ ---- -partial_type: troubleshooting -title: 'Building Troubleshooting Guide' -description: 'Common issues and solutions for building on Arbitrum' -author: anegg0 -last_reviewed: 2025-11-06 ---- - ### How does gas work on Arbitrum? Fees on Arbitrum chains are collected on L2 in the chains' native currency (ETH on both Arbitrum One and Nova). @@ -156,7 +148,7 @@ The WASM module root is a 32-byte hash, which is a Merkelization of the Go repla The replay binary is much too large to post on-chain, so this hash is set in the L1 rollup contract to determine the correct replay binary during fraud proofs. -You can find more information in [How to Customize your Orbit chain's behavior](https://docs.arbitrum.io/launch-orbit-chain/how-tos/customize-stf#step-4-enable-fraud-proofs). +You can find more information in [How to Customize your Arbitrum chain's behavior](https://docs.arbitrum.io/launch-orbit-chain/how-tos/customize-stf#step-4-enable-fraud-proofs). ### Why do I get a "gas required exceeds allowance" when trying to estimate the gas costs of a request? diff --git a/docs/partials/_troubleshooting-nodes-partial.mdx b/docs/partials/_troubleshooting-nodes-partial.mdx index 767479be47..c4bd413d6c 100644 --- a/docs/partials/_troubleshooting-nodes-partial.mdx +++ b/docs/partials/_troubleshooting-nodes-partial.mdx @@ -1,14 +1,6 @@ ---- -partial_type: troubleshooting -title: 'Node Running Troubleshooting Guide' -description: 'Common issues and solutions for running Arbitrum nodes' -author: anegg0 -last_reviewed: 2025-11-06 ---- - ### How do I run a node? -See instructions in the tutorial explaining how to [run a full node](https://developer.arbitrum.io/node-running/how-tos/running-a-full-node)! +See instructions [here](https://developer.arbitrum.io/node-running/how-tos/running-a-full-node)! ### How to verify the integrity of the Nitro database I currently have? @@ -36,7 +28,7 @@ Running an Arbitrum relay locally as a [Feed Relay](https://docs.arbitrum.io/nod ### How do I run a node locally for development? -See instructions on [how to set up a local dev node](https://developer.arbitrum.io/node-running/how-tos/local-dev-node). +See instructions [here](https://developer.arbitrum.io/node-running/how-tos/local-dev-node). We recommend running Nitro nodes via Docker; to compile directly / run without Docker, you can follow the steps in [How to build Nitro locally](https://docs.arbitrum.io/node-running/how-tos/build-nitro-locally). @@ -44,7 +36,7 @@ We recommend running Nitro nodes via Docker; to compile directly / run without D The pre-Nitro stack is also called the "classic" stack. Full Nitro nodes start with a database that contains the information from the "classic" era. -However, a Nitro node can't query archive information contained in "classic" blocks right away. To do that, you also need to run a classic node. You can find detailed instructions [in this detailed How To](https://developer.arbitrum.io/node-running/how-tos/running-a-classic-node) and set the parameter `—node.rpc.classic-redirect=your-classic-node-RPC`. +However, a Nitro node can't query archive information contained in "classic" blocks right away. To do that, you also need to run a classic node ([instructions here](https://developer.arbitrum.io/node-running/how-tos/running-a-classic-node)) and set the parameter `—node.rpc.classic-redirect=your-classic-node-RPC`. Please note that this information only applies to Arbitrum One nodes. Arbitrum Nova and Sepolia nodes started with a Nitro stack, so they don't have "classic" data. diff --git a/docs/partials/_troubleshooting-stylus-partial.mdx b/docs/partials/_troubleshooting-stylus-partial.mdx index 28cdc3f141..58b313374a 100644 --- a/docs/partials/_troubleshooting-stylus-partial.mdx +++ b/docs/partials/_troubleshooting-stylus-partial.mdx @@ -1,11 +1,3 @@ ---- -partial_type: troubleshooting -title: 'Stylus Troubleshooting Guide' -description: 'Common issues and solutions for Stylus smart contract development' -author: anegg0 -last_reviewed: 2025-11-06 ---- - ### How does Stylus manage security issues in smart contracts when interacting with so many different languages? All languages are compiled to WASM for them to be able to work with Stylus. So it just needs to verify that the produced WASM programs behave as they should inside the new virtual machine. diff --git a/docs/partials/_troubleshooting-users-partial.mdx b/docs/partials/_troubleshooting-users-partial.mdx index 6b23b50681..a38dca3fe4 100644 --- a/docs/partials/_troubleshooting-users-partial.mdx +++ b/docs/partials/_troubleshooting-users-partial.mdx @@ -1,11 +1,3 @@ ---- -partial_type: troubleshooting -title: 'User Troubleshooting Guide' -description: 'Common issues and solutions for Arbitrum users' -author: anegg0 -last_reviewed: 2025-11-06 ---- - ### Why do I need ETH to use the Arbitrum network? `ETH` is the currency used to pay gas fees on Arbitrum, and it powers all transactions on Arbitrum. You can bridge `ETH` (and other tokens) from Ethereum to Arbitrum through [Arbitrum's bridge](https://bridge.arbitrum.io/). diff --git a/static/building-faqs.json b/static/building-faqs.json index 9c38dd6373..dcd5b45112 100644 --- a/static/building-faqs.json +++ b/static/building-faqs.json @@ -96,7 +96,7 @@ }, { "question": "What is the WASM module root?", - "answer": "The WASM module root is a 32-byte hash, which is a Merkelization of the Go replay binary and its dependencies.\n\nThe replay binary is much too large to post on-chain, so this hash is set in the L1 rollup contract to determine the correct replay binary during fraud proofs.\n\nYou can find more information in [How to Customize your Orbit chain's behavior](https://docs.arbitrum.io/launch-orbit-chain/how-tos/customize-stf#step-4-enable-fraud-proofs).\n\n\n\n", + "answer": "The WASM module root is a 32-byte hash, which is a Merkelization of the Go replay binary and its dependencies.\n\nThe replay binary is much too large to post on-chain, so this hash is set in the L1 rollup contract to determine the correct replay binary during fraud proofs.\n\nYou can find more information in [How to Customize your Arbitrum chain's behavior](https://docs.arbitrum.io/launch-orbit-chain/how-tos/customize-stf#step-4-enable-fraud-proofs).\n\n\n\n", "key": "what-is-the-wasm-module-root" }, { diff --git a/static/building-orbit-faqs.json b/static/building-orbit-faqs.json index e096404e32..d58b7f0ed0 100644 --- a/static/building-orbit-faqs.json +++ b/static/building-orbit-faqs.json @@ -1,13 +1,13 @@ [ { - "question": "Can I use Orbit to deploy a mainnet chain?", - "answer": "Yes! Arbitrum Orbit's core technology has undergone a comprehensive audit and is now capable of supporting deployments to mainnet. You can read more about it [here](https://docs.arbitrum.io/launch-orbit-chain/concepts/public-preview-expectations#arbitrum-orbit-is-mainnet-ready-but-deploy-to-testnet-first).\n\n\n\n", - "key": "can-i-use-orbit-to-deploy-a-mainnet-chain" + "question": "Can I use the Chain SDK to deploy a mainnet chain?", + "answer": "Yes! The Arbitrum Chain SDK's core technology has undergone a comprehensive audit and is now capable of supporting deployments to mainnet. You can read more about it [here](https://docs.arbitrum.io/launch-orbit-chain/concepts/public-preview-expectations#arbitrum-orbit-is-mainnet-ready-but-deploy-to-testnet-first).\n\n\n\n", + "key": "can-i-use-the-chain-sdk-to-deploy-a-mainnet-chain" }, { - "question": "Do I need permission/license to launch an Orbit chain?", - "answer": "You can launch any Arbitrum Orbit chain permissionlessly.\n\nNitro's license is under a [Business Source license](https://github.com/OffchainLabs/nitro?tab=License-1-ov-file), similar to DeFi protocols like Uniswap and Aave, among others. This license contains an Additional Use Grant that permits the permissionless deployment of Nitro software on blockchains that settle to Arbitrum One or Nova.\n\nHowever, Arbitrum Orbit chains that settle to a parent chain other than Arbitrum One or Nova are subject to additional licensing guidelines under the [AEP](https://docs.arbitrum.foundation/aep/ArbitrumExpansionProgramTerms.pdf).\n\n", - "key": "do-i-need-permissionlicense-to-launch-an-orbit-chain" + "question": "Do I need permission/license to launch an Arbitrum chain?", + "answer": "You can launch any Arbitrum chain permissionlessly.\n\nNitro's license is under a [Business Source license](https://github.com/OffchainLabs/nitro?tab=License-1-ov-file), similar to DeFi protocols like Uniswap and Aave, among others. This license contains an Additional Use Grant that permits the permissionless deployment of Nitro software on blockchains that settle to Arbitrum One or Nova.\n\nHowever, Arbitrum chains that settle to a parent chain other than Arbitrum One or Nova are subject to additional licensing guidelines under the [AEP](https://docs.arbitrum.foundation/aep/ArbitrumExpansionProgramTerms.pdf).\n\n", + "key": "do-i-need-permissionlicense-to-launch-an-arbitrum-chain" }, { "question": "Does Arbitrum officially deploy and/or maintain L3s for external teams?", @@ -15,49 +15,49 @@ "key": "does-arbitrum-officially-deploy-andor-maintain-l3s-for-external-teams" }, { - "question": "Can I modify Orbit's underlying technology to customize my chain?", + "question": "Can I modify the underlying technology to customize my Arbitrum chain?", "answer": "Yes, you can make any changes you require to the underlying Nitro code base.\n\n\n\n", - "key": "can-i-modify-orbits-underlying-technology-to-customize-my-chain" + "key": "can-i-modify-the-underlying-technology-to-customize-my-arbitrum-chain" }, { - "question": "What Data Availability (DA) solutions are currently available for Orbit chains?", - "answer": "Arbitrum Orbit currently supports three different DA solutions:\n\n- Rollup, posting data to the parent chain, which ultimately posts the data to Ethereum.\n- AnyTrust, posting data to a Data Availability Committee, selected by the chain owner.\n- Celestia, posting data to the [Celestia network](https://blog.celestia.org/celestia-is-first-modular-data-availability-network-to-integrate-with-arbitrum-orbit/).\nNote that using AnyTrust provides the chain owner with the most flexibility and the most cost-effective fees.\n\n", - "key": "what-data-availability-da-solutions-are-currently-available-for-orbit-chains" + "question": "What Data Availability (DA) solutions are currently available for Arbitrum chains?", + "answer": "Arbitrum chains currently support three different DA solutions:\n\n- Rollup, posting data to the parent chain, which ultimately posts the data to Ethereum.\n- AnyTrust, posting data to a Data Availability Committee, selected by the chain owner.\n- Celestia, posting data to the [Celestia network](https://blog.celestia.org/celestia-is-first-modular-data-availability-network-to-integrate-with-arbitrum-orbit/).\nNote that using AnyTrust provides the chain owner with the most flexibility and the most cost-effective fees.\n\n", + "key": "what-data-availability-da-solutions-are-currently-available-for-arbitrum-chains" }, { - "question": "What token is used to pay gas fees on Orbit chains?", - "answer": "By default, Arbitrum Orbit chains pay gas in `ETH`. However, Arbitrum Orbit chains that use AnyTrust are configurable to use any `ERC-20` token for the gas fee token of the chain.\n\n\n\n", - "key": "what-token-is-used-to-pay-gas-fees-on-orbit-chains" + "question": "What token is used to pay gas fees on Arbitrum chains?", + "answer": "By default, Arbitrum chains pay gas in `ETH`. However, Arbitrum chains that use AnyTrust are configurable to use any `ERC-20` token for the gas fee token of the chain.\n\n\n\n", + "key": "what-token-is-used-to-pay-gas-fees-on-arbitrum-chains" }, { - "question": "Can I use Ethereum toolkits to develop on my Orbit chain?", - "answer": "Arbitrum Orbit chains are fully EVM-compatible. Most tools that support Ethereum should be able to support an Arbitrum Orbit chain. There are, however, specific differences that developers need to consider when building on an Orbit chain. You can find them [here](https://docs.arbitrum.io/for-devs/concepts/differences-between-arbitrum-ethereum/overview).\n\n\n\n", - "key": "can-i-use-ethereum-toolkits-to-develop-on-my-orbit-chain" + "question": "Can I use Ethereum toolkits to develop on my Arbitrum chain?", + "answer": "Arbitrum chains are fully EVM-compatible. Most tools that support Ethereum should be able to support an Arbitrum chain. There are, however, specific differences that developers need to consider when building on an Arbitrum chain. You can find them [here](https://docs.arbitrum.io/for-devs/concepts/differences-between-arbitrum-ethereum/overview).\n\n\n\n", + "key": "can-i-use-ethereum-toolkits-to-develop-on-my-arbitrum-chain" }, { - "question": "Do Orbit chains have any built-in AA solution?", + "question": "Do Arbitrum chains have any built-in AA solution?", "answer": "Not by default, but they can be customized to have native AA.\n\n", - "key": "do-orbit-chains-have-any-builtin-aa-solution" + "key": "do-arbitrum-chains-have-any-builtin-aa-solution" }, { - "question": "Is there any cross-chain bridging solution between two Orbit chains?", - "answer": "There is currently no native Orbit-to-Orbit chain bridging solution, except for going through the parent chain (even if they share the same parent chain). However, many third-party bridges have expressed interest in supporting Arbitrum Orbit chains.\n\n\n\n", - "key": "is-there-any-crosschain-bridging-solution-between-two-orbit-chains" + "question": "Is there any cross-chain bridging solution between two Arbitrum chains?", + "answer": "There is currently no native Arbitrum-to-Arbitrum chain bridging solution, except for going through the parent chain (even if they share the same parent chain). However, many third-party bridges have expressed interest in supporting Arbitrum chains.\n\n\n\n", + "key": "is-there-any-crosschain-bridging-solution-between-two-arbitrum-chains" }, { - "question": "Is there an official block explorer for Orbit chains?", - "answer": "Arbitrum Orbit chains deployments usually come with an open-source Blockscout explorer by default, but there are many third-party solutions that have expressed interest in supporting Arbitrum Orbit chains.\n\n\n\n", - "key": "is-there-an-official-block-explorer-for-orbit-chains" + "question": "Is there an official block explorer for Arbitrum chains?", + "answer": "Arbitrum chains deployments usually come with an open-source Blockscout explorer by default, but there are many third-party solutions that have expressed interest in supporting Arbitrum chains.\n\n\n\n", + "key": "is-there-an-official-block-explorer-for-arbitrum-chains" }, { - "question": "Is there any indexing solution that supports Orbit chains?", - "answer": "Similar to bridges and block explorers, there are many third-party indexing solutions that have expressed interest in supporting Arbitrum Orbit chains.\n\n\n\n", - "key": "is-there-any-indexing-solution-that-supports-orbit-chains" + "question": "Is there any indexing solution that supports Arbitrum chains?", + "answer": "Similar to bridges and block explorers, there are many third-party indexing solutions that have expressed interest in supporting Arbitrum chains.\n\n\n\n", + "key": "is-there-any-indexing-solution-that-supports-arbitrum-chains" }, { - "question": "Can I increase the maximum contract size for my Orbit chain?", - "answer": "Yes, Arbitrum Orbit chains support an increased smart contract size limit of up to 96kB. You can use our [Orbit SDK](https://github.com/OffchainLabs/arbitrum-orbit-sdk) and configure the parameters `[MaxCodeSize](https://github.com/OffchainLabs/arbitrum-orbit-sdk/blob/main/src/prepareChainConfig.ts#L29)`[ and ](https://github.com/OffchainLabs/arbitrum-orbit-sdk/blob/main/src/prepareChainConfig.ts#L29)`[MaxInitCodeSize](https://github.com/OffchainLabs/arbitrum-orbit-sdk/blob/main/src/prepareChainConfig.ts#L29)` when calling `[prepareNodeConfig](https://github.com/OffchainLabs/arbitrum-orbit-sdk/blob/main/examples/prepare-node-config/index.ts#L43)`. Once deployed, you cannot change the parameters for the smart contract size limit through an upgrade.\n\n\n\n", - "key": "can-i-increase-the-maximum-contract-size-for-my-orbit-chain" + "question": "Can I increase the maximum contract size for my Arbitrum chain?", + "answer": "Yes, Arbitrum chains support an increased smart contract size limit of up to 96kB. You can use our [Chain SDK](https://github.com/OffchainLabs/arbitrum-orbit-sdk) and configure the parameters `[MaxCodeSize](https://github.com/OffchainLabs/arbitrum-orbit-sdk/blob/main/src/prepareChainConfig.ts#L29)`[ and ](https://github.com/OffchainLabs/arbitrum-orbit-sdk/blob/main/src/prepareChainConfig.ts#L29)`[MaxInitCodeSize](https://github.com/OffchainLabs/arbitrum-orbit-sdk/blob/main/src/prepareChainConfig.ts#L29)` when calling `[prepareNodeConfig](https://github.com/OffchainLabs/arbitrum-orbit-sdk/blob/main/examples/prepare-node-config/index.ts#L43)`. Once deployed, you cannot change the parameters for the smart contract size limit through an upgrade.\n\n\n\n", + "key": "can-i-increase-the-maximum-contract-size-for-my-arbitrum-chain" }, { "question": "How can I modify Nitro to force posting an invalid assertion and test the fraud proof mechanism?", diff --git a/static/glossary.json b/static/glossary.json index ea0486df72..53d3193b97 100644 --- a/static/glossary.json +++ b/static/glossary.json @@ -7,6 +7,10 @@ "title": "Address Alias", "text": "

An address deterministically generated from a parent chain contract address used on child chain to safely identify the source of an parent to child chain message.

\n" }, + "dapp": { + "title": "Decentralized application", + "text": "

A decentralized application typically consists of smart contracts as well as a user-interface for interacting with them.\nNote: In our documentation, "apps" and "decentralized applications" are used interchangeably.

\n" + }, "arb-token-bridge": { "title": "Arb Token Bridge", "text": "

A series of contracts on an Arbitrum chain and its underlying chain that facilitate trustless movement of ERC-20 tokens between the two layers.

\n" @@ -37,7 +41,7 @@ }, "arbitrum-chains": { "title": "Arbitrum Chains", - "text": "

Arbitrum chains (Orbit) refers to the ability for anyone to permissionlessly deploy Layer 3 (L3) chains on top of Arbitrum Layer 2 (L2) chains.

\n" + "text": "

Arbitrum chains refers to the ability for anyone to permissionlessly deploy Layer 3 (L3) chains on top of Arbitrum Layer 2 (L2) chains.

\n" }, "arbitrum-classic": { "title": "Arbitrum Classic", @@ -73,7 +77,7 @@ }, "assertion": { "title": "Assertion", - "text": "

A bonded claim made by an Arbitrum Validator representing a claim about an Arbitrum chain's state. An Assertion may, e.g., propose a new assertion, or may be a step in a Challenge.

\n" + "text": "

A bonded claim made by an Arbitrum Validator representing a claim about an Arbitrum chain's state. An Assertion may, e.g., propose a new assertion, or may be a step in a Challenge.

\n

Assertions can have different states:

\n
    \n
  • Proposed: When a validator submits an assertion
    • \n
  • Challenged: If another validator disputes the assertion, an interactive fraud-proof initiates.
    • \n
  • Confirmed: An assertion becomes final if no one challenges it within the dispute window (6.4 days).
    • \n
\n" }, "auction-contract": { "title": "Auction Contract", @@ -151,10 +155,6 @@ "title": "Custom gateway", "text": "

Any Token Gateway that isn't the StandardERC20 gateway.

\n" }, - "dapp": { - "title": "dApp", - "text": "

Short for "decentralized application." A dApp typically consists of smart contracts as well as a user-interface for interacting with them.

\n" - }, "data-availability-certificate": { "title": "Data Availability Certificate", "text": "

Signed promise from a Data Availability Committee (DAC) attesting to the availability of a batch of data for an Arbitrum AnyTrust Chain.

\n" @@ -361,7 +361,7 @@ }, "state-transition-function": { "title": "State Transition Function", - "text": "

The STF (State Transition Function) defines how new blocks are produced from input messages (i.e., transactions) in an Arbitrum chain.

\n" + "text": "

The STF (State Transition Function) defines how new blocks are produced from input messages (i.e., transactions) in an Arbitrum chain. The State Transition Function's output is the result of applying those input messages (transactions).

\n" }, "stylus": { "title": "Stylus", From 2bded06b2f144cc8e690938d9c0f2b8cf84f1bd6 Mon Sep 17 00:00:00 2001 From: Pete Date: Thu, 13 Nov 2025 13:04:37 -0600 Subject: [PATCH 03/10] Re-running FAQs --- .../_troubleshooting-arbitrum-chain-partial.mdx | 12 ++++++------ static/building-orbit-faqs.json | 10 +++++----- 2 files changed, 11 insertions(+), 11 deletions(-) diff --git a/docs/partials/_troubleshooting-arbitrum-chain-partial.mdx b/docs/partials/_troubleshooting-arbitrum-chain-partial.mdx index ec31f66b5c..7b5106efe4 100644 --- a/docs/partials/_troubleshooting-arbitrum-chain-partial.mdx +++ b/docs/partials/_troubleshooting-arbitrum-chain-partial.mdx @@ -12,7 +12,7 @@ However, Arbitrum chains that settle to a parent chain other than Arbitrum One o ### Does Arbitrum officially deploy and/or maintain L3s for external teams? -No. Teams are required to deploy and maintain their Arbitrum Orbit chains. There are, however, several RaaS (Rollup as a Service) providers that can deploy and maintain your Arbitrum Orbit chain on your behalf. +No. Teams are required to deploy and maintain their Arbitrum chains. There are, however, several RaaS (Rollup as a Service) providers that can deploy and maintain your Arbitrum chain on your behalf. ### Can I modify the underlying technology to customize my Arbitrum chain? @@ -66,9 +66,9 @@ go test ./system_tests/ -tags=challengetest -run=TestChallenge ### What fee collectors can be configured on my chain? -Four fee types are configurable on an Orbit chain: +Four fee types are configurable on an Arbitrum chain: -- **L2 base fee**: L2 execution fees corresponding to the minimum base price of the chain. This fee is deposited into the infraFeeAccount, which can be set by calling `ArbOwner.setInfraFeeAccount().` +- **L2 base fee**: L2 execution fees corresponding to the minimum base price of the chain. This fee is deposited into the `infraFeeAccount`, which can be set by calling `ArbOwner.setInfraFeeAccount().` - **L2 surplus fee**: L2 execution fees above the minimum base price (in the case of congestion). This fee goes to the `networkFeeAccount`, which can be set by calling `ArbOwner.setNetworkFeeAccount().` - **L1 base fee**: Relative fees for posting a transaction on the parent chain. This fee is paid ultimately to the fee collector of the active batch poster. A call to `SequencerInbox.setIsBatchPoster()` on the parent chain will set the batch poster. Delegating a different fee collector for that batch poster can be specified by calling `ArbAggregator.setFeeCollector()`. - **L1 surplus fee**: Any extra fees rewarded to the batch poster. This is paid to a specific `L1RewardRecipient`, which can be set by calling `ArbOwner.setL1PricingRewardRecipient()`. @@ -78,7 +78,7 @@ To learn more about precompiles, refer to the [Precompiles reference page](https ### What is the lowest you can set the base fee to? -You can set the base fee to any amount to charge users less. You can even set it to `0` (however, this would open the chain to DOS attacks). If the Orbit base fee is `0`, users are then only paying for the cost of DA. +You can set the base fee to any amount to charge users less. You can even set it to `0` (however, this would open the chain to DOS attacks). If the Arbitrum chain base fee is `0`, users are then only paying for the cost of DA. ### How does fee collection work in Nitro? @@ -126,7 +126,7 @@ Test this thoroughly on a testnet first. ### What is the max theoretical TPS for an Arbitrum Chain? -Max TPS is a challenging metric to measure, as it relies on network activity and the type of submitted transactions. We can, however, calculate the max throughput using default orbit chain parameters. +Max TPS is a challenging metric to measure, as it relies on network activity and the type of submitted transactions. We can, however, calculate the max throughput using default Arbitrum chain parameters. The actual maximum throughput depends on the configurable execution parameters: @@ -144,7 +144,7 @@ The actual maximum throughput depends on the configurable execution parameters: ### Why is the WETH Gateway not necessary for custom gas token chains? -The `WETH` gateway used in the token bridge is a special, custom gateway that unwraps the `WETH` deposits and sends them to the Arbitrum chain, then wraps them again on the Arbitrum chain. Since `ETH` is the gas token in the Arbitrum (Orbit) chain, there's no need to perform this operation, so you can use a standard `ERC-20` for `WETH` (this is the default case of the token bridge so that you wouldn't need a special `WETH` gateway). +The `WETH` gateway used in the token bridge is a special, custom gateway that unwraps the `WETH` deposits and sends them to the Arbitrum chain, then wraps them again on the Arbitrum chain. Since `ETH` is the gas token in the Arbitrum chain, there's no need to perform this operation, so you can use a standard `ERC-20` for `WETH` (this is the default case of the token bridge so that you wouldn't need a special `WETH` gateway). If you want to enable extra custom operations with `WETH`, you can create a custom token and a custom gateway to handle this case. diff --git a/static/building-orbit-faqs.json b/static/building-orbit-faqs.json index d58b7f0ed0..d65ef51918 100644 --- a/static/building-orbit-faqs.json +++ b/static/building-orbit-faqs.json @@ -11,7 +11,7 @@ }, { "question": "Does Arbitrum officially deploy and/or maintain L3s for external teams?", - "answer": "No. Teams are required to deploy and maintain their Arbitrum Orbit chains. There are, however, several RaaS (Rollup as a Service) providers that can deploy and maintain your Arbitrum Orbit chain on your behalf.\n\n\n\n", + "answer": "No. Teams are required to deploy and maintain their Arbitrum chains. There are, however, several RaaS (Rollup as a Service) providers that can deploy and maintain your Arbitrum chain on your behalf.\n\n\n\n", "key": "does-arbitrum-officially-deploy-andor-maintain-l3s-for-external-teams" }, { @@ -66,12 +66,12 @@ }, { "question": "What fee collectors can be configured on my chain?", - "answer": "Four fee types are configurable on an Orbit chain:\n\n- **L2 base fee**: L2 execution fees corresponding to the minimum base price of the chain. This fee is deposited into the infraFeeAccount, which can be set by calling `ArbOwner.setInfraFeeAccount().`\n- **L2 surplus fee**: L2 execution fees above the minimum base price (in the case of congestion). This fee goes to the `networkFeeAccount`, which can be set by calling `ArbOwner.setNetworkFeeAccount().`\n- **L1 base fee**: Relative fees for posting a transaction on the parent chain. This fee is paid ultimately to the fee collector of the active batch poster. A call to `SequencerInbox.setIsBatchPoster()` on the parent chain will set the batch poster. Delegating a different fee collector for that batch poster can be specified by calling `ArbAggregator.setFeeCollector()`.\n- **L1 surplus fee**: Any extra fees rewarded to the batch poster. This is paid to a specific `L1RewardRecipient`, which can be set by calling `ArbOwner.setL1PricingRewardRecipient()`.\nFor more detailed information about fees, please refer to the [L1 Fees](https://docs.arbitrum.io/arbos/l1-pricing) and [L2 Fees](https://docs.arbitrum.io/arbos/gas) pages.\n\nTo learn more about precompiles, refer to the [Precompiles reference page](https://docs.arbitrum.io/build-decentralized-apps/precompiles/reference).\n\n", + "answer": "Four fee types are configurable on an Arbitrum chain:\n\n- **L2 base fee**: L2 execution fees corresponding to the minimum base price of the chain. This fee is deposited into the `infraFeeAccount`, which can be set by calling `ArbOwner.setInfraFeeAccount().`\n- **L2 surplus fee**: L2 execution fees above the minimum base price (in the case of congestion). This fee goes to the `networkFeeAccount`, which can be set by calling `ArbOwner.setNetworkFeeAccount().`\n- **L1 base fee**: Relative fees for posting a transaction on the parent chain. This fee is paid ultimately to the fee collector of the active batch poster. A call to `SequencerInbox.setIsBatchPoster()` on the parent chain will set the batch poster. Delegating a different fee collector for that batch poster can be specified by calling `ArbAggregator.setFeeCollector()`.\n- **L1 surplus fee**: Any extra fees rewarded to the batch poster. This is paid to a specific `L1RewardRecipient`, which can be set by calling `ArbOwner.setL1PricingRewardRecipient()`.\nFor more detailed information about fees, please refer to the [L1 Fees](https://docs.arbitrum.io/arbos/l1-pricing) and [L2 Fees](https://docs.arbitrum.io/arbos/gas) pages.\n\nTo learn more about precompiles, refer to the [Precompiles reference page](https://docs.arbitrum.io/build-decentralized-apps/precompiles/reference).\n\n", "key": "what-fee-collectors-can-be-configured-on-my-chain" }, { "question": "What is the lowest you can set the base fee to?", - "answer": "You can set the base fee to any amount to charge users less. You can even set it to `0` (however, this would open the chain to DOS attacks). If the Orbit base fee is `0`, users are then only paying for the cost of DA.\n\n", + "answer": "You can set the base fee to any amount to charge users less. You can even set it to `0` (however, this would open the chain to DOS attacks). If the Arbitrum chain base fee is `0`, users are then only paying for the cost of DA.\n\n", "key": "what-is-the-lowest-you-can-set-the-base-fee-to" }, { @@ -101,12 +101,12 @@ }, { "question": "What is the max theoretical TPS for an Arbitrum Chain?", - "answer": "Max TPS is a challenging metric to measure, as it relies on network activity and the type of submitted transactions. We can, however, calculate the max throughput using default orbit chain parameters.\n\nThe actual maximum throughput depends on the configurable execution parameters:\n\n**Using standard Arbitrum chain defaults**\n\n- Block time: 250ms\n- Block gas limit: 32M L2 gas\n- Max L2 gas per second: 128M gas/sec\n- These parameters are entirely configurable, for example, by dropping the block time to 100ms or by increasing the block gas limit (which comes at the cost of faster state bloat).\n- Dropping to 100ms and doubling the block gas limit to 64m L2 gas would achieve 640m L2 gas per second.\n**The actual TPS varies depending on the gas cost per transaction:**\n\n- A simple transfer (~21,000 gas) could approximately achieve around 6,000 TPS.\n- A more complex transaction (~200,000 gas) would enable approximately 640 TPS.\n", + "answer": "Max TPS is a challenging metric to measure, as it relies on network activity and the type of submitted transactions. We can, however, calculate the max throughput using default Arbitrum chain parameters.\n\nThe actual maximum throughput depends on the configurable execution parameters:\n\n**Using standard Arbitrum chain defaults**\n\n- Block time: 250ms\n- Block gas limit: 32M L2 gas\n- Max L2 gas per second: 128M gas/sec\n- These parameters are entirely configurable, for example, by dropping the block time to 100ms or by increasing the block gas limit (which comes at the cost of faster state bloat).\n- Dropping to 100ms and doubling the block gas limit to 64m L2 gas would achieve 640m L2 gas per second.\n**The actual TPS varies depending on the gas cost per transaction:**\n\n- A simple transfer (~21,000 gas) could approximately achieve around 6,000 TPS.\n- A more complex transaction (~200,000 gas) would enable approximately 640 TPS.\n", "key": "what-is-the-max-theoretical-tps-for-an-arbitrum-chain" }, { "question": "Why is the WETH Gateway not necessary for custom gas token chains?", - "answer": "The `WETH` gateway used in the token bridge is a special, custom gateway that unwraps the `WETH` deposits and sends them to the Arbitrum chain, then wraps them again on the Arbitrum chain. Since `ETH` is the gas token in the Arbitrum (Orbit) chain, there's no need to perform this operation, so you can use a standard `ERC-20` for `WETH` (this is the default case of the token bridge so that you wouldn't need a special `WETH` gateway).\n\nIf you want to enable extra custom operations with `WETH`, you can create a custom token and a custom gateway to handle this case.\n\n", + "answer": "The `WETH` gateway used in the token bridge is a special, custom gateway that unwraps the `WETH` deposits and sends them to the Arbitrum chain, then wraps them again on the Arbitrum chain. Since `ETH` is the gas token in the Arbitrum chain, there's no need to perform this operation, so you can use a standard `ERC-20` for `WETH` (this is the default case of the token bridge so that you wouldn't need a special `WETH` gateway).\n\nIf you want to enable extra custom operations with `WETH`, you can create a custom token and a custom gateway to handle this case.\n\n", "key": "why-is-the-weth-gateway-not-necessary-for-custom-gas-token-chains" }, { From 0c75e6a55464e436028fcfa420ad28609dc552df Mon Sep 17 00:00:00 2001 From: Pete Date: Thu, 13 Nov 2025 13:06:34 -0600 Subject: [PATCH 04/10] Updating sidebars to remove Orbit --- sidebars.js | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/sidebars.js b/sidebars.js index 091f647d93..12a8d315e1 100644 --- a/sidebars.js +++ b/sidebars.js @@ -56,7 +56,7 @@ const sidebars = { }, { type: 'link', - label: 'Run an Arbitrum (Orbit) chain', + label: 'Run an Arbitrum chain', href: '/launch-arbitrum-chain/a-gentle-introduction', }, { @@ -99,7 +99,7 @@ const sidebars = { runArbitrumChainSidebar: [ { type: 'category', - label: 'Run an Arbitrum (Orbit) chain', + label: 'Run an Arbitrum chain', collapsed: false, items: [ { From f114bca549fe28496c01eb31ce9ef6ed28af2965 Mon Sep 17 00:00:00 2001 From: Pete Date: Thu, 13 Nov 2025 13:17:06 -0600 Subject: [PATCH 05/10] Adding redirects --- vercel.json | 7 ++++++- 1 file changed, 6 insertions(+), 1 deletion(-) diff --git a/vercel.json b/vercel.json index 14b7835eba..d0db84d91e 100644 --- a/vercel.json +++ b/vercel.json @@ -70,6 +70,11 @@ "destination": "/(docs/get-started/overview/?)", "permanent": true }, + { + "source": "/(/node-running/how-tos/running-an-orbit-node/?)", + "destination": "launch-arbitrum-chain/a-gentle-introduction", + "permanent": false + }, { "source": "/(anytrust/inside-anytrust/?)", "destination": "/how-arbitrum-works/deep-dives/anytrust-protocol", @@ -1413,7 +1418,7 @@ }, { "source": "/(launch-orbit-chain/reference/command-line-options/?)", - "destination": "/node-running/how-tos/running-an-orbit-node", + "destination": "/launch-arbitrum-chain/a-gentle-introduction", "permanent": false }, { From d03f1f8f88018dcf45d680f4abde119e615d7e48 Mon Sep 17 00:00:00 2001 From: Pete Date: Thu, 13 Nov 2025 14:04:02 -0600 Subject: [PATCH 06/10] Updating old website link with new URL --- docs/get-started/overview.mdx | 2 +- .../how-tos/customize-deployment-configuration.mdx | 2 +- 2 files changed, 2 insertions(+), 2 deletions(-) diff --git a/docs/get-started/overview.mdx b/docs/get-started/overview.mdx index 6d4b2ac034..dc2c22f2c5 100644 --- a/docs/get-started/overview.mdx +++ b/docs/get-started/overview.mdx @@ -23,7 +23,7 @@ The Arbitrum suite includes the protocols, chains, services, and SDKs that power | [Arbitrum One](https://portal.arbitrum.io/?chains=arbitrum-one) | A public Rollup **chain**. | | [Arbitrum Nova](https://portal.arbitrum.io/?chains=arbitrum-nova) | A public AnyTrust **chain**. | | [Arbitrum bridge](https://bridge.arbitrum.io/) | Lets you move `ETH` and `ERC-20` tokens between Ethereum, Arbitrum, and select Arbitrum chains. | -| [Arbitrum chains](https://orbit.arbitrum.io/) | Lets you run your own Rollup and AnyTrust chains. | +| [Arbitrum chains](https://arbitrum.io/launch-chain) | Lets you run your own Rollup and AnyTrust chains. | | [Arbitrum Stylus](/stylus/gentle-introduction.mdx) | Lets you write EVM-compatible smart contracts in Rust and any other language that compiles to Wasm. | ## Arbitrum for users diff --git a/docs/launch-arbitrum-chain/how-tos/customize-deployment-configuration.mdx b/docs/launch-arbitrum-chain/how-tos/customize-deployment-configuration.mdx index bd8491b33e..ac8f94e582 100644 --- a/docs/launch-arbitrum-chain/how-tos/customize-deployment-configuration.mdx +++ b/docs/launch-arbitrum-chain/how-tos/customize-deployment-configuration.mdx @@ -5,7 +5,7 @@ author: symbolpunk sidebar_position: 1 --- -When you visit the [Arbitrum chain deployment portal](https://orbit.arbitrum.io/) to launch your Arbitrum chain, you'll be prompted to complete a form that looks like this: +When you visit the [Arbitrum chain deployment portal](https://arbitrum.io/launch-chain) to launch your Arbitrum chain, you'll be prompted to complete a form that looks like this: import { PlaceholderForm } from '/src/components/PlaceholderForm/PlaceholderForm'; From 9c522977e9e708318cbf6ee9e1959a8fe470399d Mon Sep 17 00:00:00 2001 From: Pete Date: Thu, 13 Nov 2025 14:07:19 -0600 Subject: [PATCH 07/10] yarn:format --- docs/notices/fusaka-upgrade-notice.mdx | 14 +++++++------- 1 file changed, 7 insertions(+), 7 deletions(-) diff --git a/docs/notices/fusaka-upgrade-notice.mdx b/docs/notices/fusaka-upgrade-notice.mdx index da39d775e2..a7e32270dc 100644 --- a/docs/notices/fusaka-upgrade-notice.mdx +++ b/docs/notices/fusaka-upgrade-notice.mdx @@ -50,13 +50,13 @@ Confirm that your external L1 beacon chain RPC provider has configured their L1 Ensure that your consensus layer client & Nitro node is configured as per the table below. -| Client | Compatible with Nitro | Required Nitro Flag | Required flag for subscribing to all subnets | Required Flag to serve historical blobs | -| ------------- | --------------------- | ------------------------------------------------------------------- | --------------------------------------------- | -------------------------------------------------------------- | -| Prysm | ✅ | None | `--subscribe-all-data-subnets` | `--blob-retention-epochs` | -| Lighthouse | ✅ | None | `--supernode` | `--prune-blobs false` or `--blob-prune-margin-epochs` | -| Teku | ✅ | None | `p2p-subscribe-all-subnets-enabled` | N/A | -| Lodestar | ✅ | None | `--supernode` | `--chain.archiveDataEpochs` | -| Erigon Caplin | ❌ | N/A | N/A | N/A | +| Client | Compatible with Nitro | Required Nitro Flag | Required flag for subscribing to all subnets | Required Flag to serve historical blobs | +| ------------- | --------------------- | ------------------- | -------------------------------------------- | ----------------------------------------------------- | +| Prysm | ✅ | None | `--subscribe-all-data-subnets` | `--blob-retention-epochs` | +| Lighthouse | ✅ | None | `--supernode` | `--prune-blobs false` or `--blob-prune-margin-epochs` | +| Teku | ✅ | None | `p2p-subscribe-all-subnets-enabled` | N/A | +| Lodestar | ✅ | None | `--supernode` | `--chain.archiveDataEpochs` | +| Erigon Caplin | ❌ | N/A | N/A | N/A | For additional information regarding specific client flags visit their docs: [Prysm](https://prysm.offchainlabs.com/docs/learn/concepts/blobs), [Lighthouse](https://lighthouse-book.sigmaprime.io/advanced_blobs.html), [Teku](https://docs.teku.consensys.io/concepts/proto-danksharding#what-are-blobs), and [Lodestar](https://chainsafe.github.io/lodestar/run/beacon-management/beacon-cli/). From 0e27222194684ee43472c78c4b1fc157596ad2ff Mon Sep 17 00:00:00 2001 From: =?UTF-8?q?Ga=C3=ABl=20Blanchemain?= Date: Fri, 14 Nov 2025 12:35:18 -0800 Subject: [PATCH 08/10] reformat faqs + troubleshooting and add descriptive links --- docs/partials/_troubleshooting-arbitrum-chain-partial.mdx | 4 ++-- docs/partials/_troubleshooting-building-partial.mdx | 4 ++-- docs/partials/_troubleshooting-nodes-partial.mdx | 4 ++-- docs/partials/_troubleshooting-users-partial.mdx | 6 +----- static/building-faqs.json | 2 +- static/building-orbit-faqs.json | 4 ++-- static/get-started-faqs.json | 7 +------ static/node-running-faqs.json | 4 ++-- 8 files changed, 13 insertions(+), 22 deletions(-) diff --git a/docs/partials/_troubleshooting-arbitrum-chain-partial.mdx b/docs/partials/_troubleshooting-arbitrum-chain-partial.mdx index 7b5106efe4..7b61754aa8 100644 --- a/docs/partials/_troubleshooting-arbitrum-chain-partial.mdx +++ b/docs/partials/_troubleshooting-arbitrum-chain-partial.mdx @@ -1,6 +1,6 @@ ### Can I use the Chain SDK to deploy a mainnet chain? -Yes! The Arbitrum Chain SDK's core technology has undergone a comprehensive audit and is now capable of supporting deployments to mainnet. You can read more about it [here](https://docs.arbitrum.io/launch-orbit-chain/concepts/public-preview-expectations#arbitrum-orbit-is-mainnet-ready-but-deploy-to-testnet-first). +Yes! The Arbitrum Chain SDK's core technology has undergone a comprehensive audit and is now capable of supporting deployments to mainnet. You can read more about it in our [preview expectations notice](https://docs.arbitrum.io/launch-orbit-chain/concepts/public-preview-expectations#arbitrum-orbit-is-mainnet-ready-but-deploy-to-testnet-first). ### Do I need permission/license to launch an Arbitrum chain? @@ -33,7 +33,7 @@ By default, Arbitrum chains pay gas in `ETH`. However, Arbitrum chains that use ### Can I use Ethereum toolkits to develop on my Arbitrum chain? -Arbitrum chains are fully EVM-compatible. Most tools that support Ethereum should be able to support an Arbitrum chain. There are, however, specific differences that developers need to consider when building on an Arbitrum chain. You can find them [here](https://docs.arbitrum.io/for-devs/concepts/differences-between-arbitrum-ethereum/overview). +Arbitrum chains are fully EVM-compatible. Most tools that support Ethereum should be able to support an Arbitrum chain. There are, however, specific differences that developers need to consider when building on an Arbitrum chain. You can find them in our [overview of the differences between Arbitrum and Ethereum](https://docs.arbitrum.io/for-devs/concepts/differences-between-arbitrum-ethereum/overview). ### Do Arbitrum chains have any built-in AA solution? diff --git a/docs/partials/_troubleshooting-building-partial.mdx b/docs/partials/_troubleshooting-building-partial.mdx index b4d9bf8bea..c6dc5e4687 100644 --- a/docs/partials/_troubleshooting-building-partial.mdx +++ b/docs/partials/_troubleshooting-building-partial.mdx @@ -54,9 +54,9 @@ There are two differences between `createRetryableTicket` and `unsafeCreateRe ### Why do I get "custom tx type" errors when I use hardhat? -In Arbitrum, we use a number of non-standard [EIP-2718](https://eips.ethereum.org/EIPS/eip-2718) typed transactions. See [here](https://developer.arbitrum.io/arbos/geth#transaction-types) for the full list and the rationale. +In Arbitrum, we use a number of non-standard [EIP-2718](https://eips.ethereum.org/EIPS/eip-2718) typed transactions. Feel free to consult the [full list of transaction types](https://developer.arbitrum.io/arbos/geth#transaction-types) and the rationale. -Note that if you're using Hardhat, [v2.12.2](https://github.com/NomicFoundation/hardhat/releases/tag/hardhat%402.12.2) added support for forking networks like Arbitrum with custom transaction types (find more information [here](https://github.com/NomicFoundation/hardhat/issues/2995)). +Note that if you're using Hardhat, [v2.12.2](https://github.com/NomicFoundation/hardhat/releases/tag/hardhat%402.12.2) added support for forking networks like Arbitrum with custom transaction types (find more information [in this HardHat GitHub issue](https://github.com/NomicFoundation/hardhat/issues/2995)). ### Why does it look like two identical transactions consume a different amount of gas? diff --git a/docs/partials/_troubleshooting-nodes-partial.mdx b/docs/partials/_troubleshooting-nodes-partial.mdx index c4bd413d6c..188a0b285c 100644 --- a/docs/partials/_troubleshooting-nodes-partial.mdx +++ b/docs/partials/_troubleshooting-nodes-partial.mdx @@ -1,6 +1,6 @@ ### How do I run a node? -See instructions [here](https://developer.arbitrum.io/node-running/how-tos/running-a-full-node)! +See instructions [in our guide about running a full node](https://developer.arbitrum.io/node-running/how-tos/running-a-full-node)! ### How to verify the integrity of the Nitro database I currently have? @@ -36,7 +36,7 @@ We recommend running Nitro nodes via Docker; to compile directly / run without D The pre-Nitro stack is also called the "classic" stack. Full Nitro nodes start with a database that contains the information from the "classic" era. -However, a Nitro node can't query archive information contained in "classic" blocks right away. To do that, you also need to run a classic node ([instructions here](https://developer.arbitrum.io/node-running/how-tos/running-a-classic-node)) and set the parameter `—node.rpc.classic-redirect=your-classic-node-RPC`. +However, a Nitro node can't query archive information contained in "classic" blocks right away. To do that, you also need to run a classic node ([instructions in our guide about running a classic node](https://developer.arbitrum.io/node-running/how-tos/running-a-classic-node)) and set the parameter `—node.rpc.classic-redirect=your-classic-node-RPC`. Please note that this information only applies to Arbitrum One nodes. Arbitrum Nova and Sepolia nodes started with a Nitro stack, so they don't have "classic" data. diff --git a/docs/partials/_troubleshooting-users-partial.mdx b/docs/partials/_troubleshooting-users-partial.mdx index a38dca3fe4..b571e8f493 100644 --- a/docs/partials/_troubleshooting-users-partial.mdx +++ b/docs/partials/_troubleshooting-users-partial.mdx @@ -97,13 +97,9 @@ Although we currently don't maintain any stats dashboard for Arbitrum, you can f There is no notion of a mempool on Arbitrum; transactions are processed on a first-come, first-served basis by the Sequencer. Thus, the gas price bid parameter does not affect the order in which transactions get processed. -### Where can I find a list of the current validators of the Arbitrum chains? - -Validation on both Arbitrum One and Arbitrum Nova is currently allow-listed to a committee of public entities. You can see the list of validators **[here](https://docs.arbitrum.foundation/state-of-progressive-decentralization#allowlisted-validators)**. Governance currently has the power to change this status. - ### Where can I find the current Data Availability Committee members? -The Arbitrum Nova chain has a 7-party DAC, whose members can be seen **[here](https://docs.arbitrum.foundation/state-of-progressive-decentralization#data-availability-committee-members)**. Governance has the ability to remove or add members to the committee. +The Arbitrum Nova chain has a 7-party DAC, whose members can be seen in the [Arbitrum Foundation's state of progressive decentralization status document](https://docs.arbitrum.foundation/state-of-progressive-decentralization#data-availability-committee-members). Governance has the ability to remove or add members to the committee. ### Can I withdraw my funds from Arbitrum back to Ethereum without going through the Sequencer? What about funds that are in a contract? diff --git a/static/building-faqs.json b/static/building-faqs.json index dcd5b45112..ceef1f7ac5 100644 --- a/static/building-faqs.json +++ b/static/building-faqs.json @@ -26,7 +26,7 @@ }, { "question": "Why do I get \"custom tx type\" errors when I use hardhat?", - "answer": "In Arbitrum, we use a number of non-standard [EIP-2718](https://eips.ethereum.org/EIPS/eip-2718) typed transactions. See [here](https://developer.arbitrum.io/arbos/geth#transaction-types) for the full list and the rationale.\n\nNote that if you're using Hardhat, [v2.12.2](https://github.com/NomicFoundation/hardhat/releases/tag/hardhat%402.12.2) added support for forking networks like Arbitrum with custom transaction types (find more information [here](https://github.com/NomicFoundation/hardhat/issues/2995)).\n\n\n\n", + "answer": "In Arbitrum, we use a number of non-standard [EIP-2718](https://eips.ethereum.org/EIPS/eip-2718) typed transactions. Feel free to consult the [full list of transaction types](https://developer.arbitrum.io/arbos/geth#transaction-types) and the rationale.\n\nNote that if you're using Hardhat, [v2.12.2](https://github.com/NomicFoundation/hardhat/releases/tag/hardhat%402.12.2) added support for forking networks like Arbitrum with custom transaction types (find more information [in this HardHat GitHub issue](https://github.com/NomicFoundation/hardhat/issues/2995)).\n\n\n\n", "key": "why-do-i-get-custom-tx-type-errors-when-i-use-hardhat" }, { diff --git a/static/building-orbit-faqs.json b/static/building-orbit-faqs.json index d65ef51918..2aa9374480 100644 --- a/static/building-orbit-faqs.json +++ b/static/building-orbit-faqs.json @@ -1,7 +1,7 @@ [ { "question": "Can I use the Chain SDK to deploy a mainnet chain?", - "answer": "Yes! The Arbitrum Chain SDK's core technology has undergone a comprehensive audit and is now capable of supporting deployments to mainnet. You can read more about it [here](https://docs.arbitrum.io/launch-orbit-chain/concepts/public-preview-expectations#arbitrum-orbit-is-mainnet-ready-but-deploy-to-testnet-first).\n\n\n\n", + "answer": "Yes! The Arbitrum Chain SDK's core technology has undergone a comprehensive audit and is now capable of supporting deployments to mainnet. You can read more about it in our [preview expectations notice](https://docs.arbitrum.io/launch-orbit-chain/concepts/public-preview-expectations#arbitrum-orbit-is-mainnet-ready-but-deploy-to-testnet-first).\n\n\n\n", "key": "can-i-use-the-chain-sdk-to-deploy-a-mainnet-chain" }, { @@ -31,7 +31,7 @@ }, { "question": "Can I use Ethereum toolkits to develop on my Arbitrum chain?", - "answer": "Arbitrum chains are fully EVM-compatible. Most tools that support Ethereum should be able to support an Arbitrum chain. There are, however, specific differences that developers need to consider when building on an Arbitrum chain. You can find them [here](https://docs.arbitrum.io/for-devs/concepts/differences-between-arbitrum-ethereum/overview).\n\n\n\n", + "answer": "Arbitrum chains are fully EVM-compatible. Most tools that support Ethereum should be able to support an Arbitrum chain. There are, however, specific differences that developers need to consider when building on an Arbitrum chain. You can find them in our [overview of the differences between Arbitrum and Ethereum](https://docs.arbitrum.io/for-devs/concepts/differences-between-arbitrum-ethereum/overview).\n\n\n\n", "key": "can-i-use-ethereum-toolkits-to-develop-on-my-arbitrum-chain" }, { diff --git a/static/get-started-faqs.json b/static/get-started-faqs.json index b3229e30ec..4f095c33dd 100644 --- a/static/get-started-faqs.json +++ b/static/get-started-faqs.json @@ -79,14 +79,9 @@ "answer": "There is no notion of a mempool on Arbitrum; transactions are processed on a first-come, first-served basis by the Sequencer. Thus, the gas price bid parameter does not affect the order in which transactions get processed.\n\n\n\n", "key": "will-transactions-with-a-higher-gas-price-bid-be-confirmed-first" }, - { - "question": "Where can I find a list of the current validators of the Arbitrum chains?", - "answer": "Validation on both Arbitrum One and Arbitrum Nova is currently allow-listed to a committee of public entities. You can see the list of validators **[here](https://docs.arbitrum.foundation/state-of-progressive-decentralization#allowlisted-validators)**. Governance currently has the power to change this status.\n\n\n\n", - "key": "where-can-i-find-a-list-of-the-current-validators-of-the-arbitrum-chains" - }, { "question": "Where can I find the current Data Availability Committee members?", - "answer": "The Arbitrum Nova chain has a 7-party DAC, whose members can be seen **[here](https://docs.arbitrum.foundation/state-of-progressive-decentralization#data-availability-committee-members)**. Governance has the ability to remove or add members to the committee.\n\n\n\n", + "answer": "The Arbitrum Nova chain has a 7-party DAC, whose members can be seen in the [Arbitrum Foundation's state of progressive decentralization status document](https://docs.arbitrum.foundation/state-of-progressive-decentralization#data-availability-committee-members). Governance has the ability to remove or add members to the committee.\n\n\n\n", "key": "where-can-i-find-the-current-data-availability-committee-members" }, { diff --git a/static/node-running-faqs.json b/static/node-running-faqs.json index 2daefd9a41..c1a01fa3f9 100644 --- a/static/node-running-faqs.json +++ b/static/node-running-faqs.json @@ -1,7 +1,7 @@ [ { "question": "How do I run a node?", - "answer": "See instructions [here](https://developer.arbitrum.io/node-running/how-tos/running-a-full-node)! \n\n\n\n", + "answer": "See instructions [in our guide about running a full node](https://developer.arbitrum.io/node-running/how-tos/running-a-full-node)!\n\n\n\n", "key": "how-do-i-run-a-node" }, { @@ -36,7 +36,7 @@ }, { "question": "Is there any way to retrieve pre-Nitro archive data from a Nitro node?", - "answer": "The pre-Nitro stack is also called the \"classic\" stack. Full Nitro nodes start with a database that contains the information from the \"classic\" era.\n\nHowever, a Nitro node can't query archive information contained in \"classic\" blocks right away. To do that, you also need to run a classic node ([instructions here](https://developer.arbitrum.io/node-running/how-tos/running-a-classic-node)) and set the parameter `—node.rpc.classic-redirect=your-classic-node-RPC`.\n\nPlease note that this information only applies to Arbitrum One nodes. Arbitrum Nova and Sepolia nodes started with a Nitro stack, so they don't have \"classic\" data.\n\n", + "answer": "The pre-Nitro stack is also called the \"classic\" stack. Full Nitro nodes start with a database that contains the information from the \"classic\" era.\n\nHowever, a Nitro node can't query archive information contained in \"classic\" blocks right away. To do that, you also need to run a classic node ([instructions in our guide about running a classic node](https://developer.arbitrum.io/node-running/how-tos/running-a-classic-node)) and set the parameter `—node.rpc.classic-redirect=your-classic-node-RPC`.\n\nPlease note that this information only applies to Arbitrum One nodes. Arbitrum Nova and Sepolia nodes started with a Nitro stack, so they don't have \"classic\" data.\n\n\n\n", "key": "is-there-any-way-to-retrieve-prenitro-archive-data-from-a-nitro-node" }, { From 7760c0a6f0aac255be5cacb89e040c6c6ef8da3a Mon Sep 17 00:00:00 2001 From: =?UTF-8?q?Ga=C3=ABl=20Blanchemain?= Date: Fri, 14 Nov 2025 12:41:44 -0800 Subject: [PATCH 09/10] fix non-descriptive link --- docs/partials/_troubleshooting-nodes-partial.mdx | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/docs/partials/_troubleshooting-nodes-partial.mdx b/docs/partials/_troubleshooting-nodes-partial.mdx index 188a0b285c..f9b857ea34 100644 --- a/docs/partials/_troubleshooting-nodes-partial.mdx +++ b/docs/partials/_troubleshooting-nodes-partial.mdx @@ -28,7 +28,7 @@ Running an Arbitrum relay locally as a [Feed Relay](https://docs.arbitrum.io/nod ### How do I run a node locally for development? -See instructions [here](https://developer.arbitrum.io/node-running/how-tos/local-dev-node). +See instructions in our  [our guide about running a local devnet node](https://developer.arbitrum.io/node-running/how-tos/local-dev-node). We recommend running Nitro nodes via Docker; to compile directly / run without Docker, you can follow the steps in [How to build Nitro locally](https://docs.arbitrum.io/node-running/how-tos/build-nitro-locally). From b0ee5bd1da0d79715ca18bcbfe87ec0030036a33 Mon Sep 17 00:00:00 2001 From: Pete Date: Thu, 20 Nov 2025 13:04:53 -0600 Subject: [PATCH 10/10] Update docs/run-arbitrum-node/sequencer/04-run-sequencer-node.mdx MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit Co-authored-by: Gaël Blanchemain --- docs/run-arbitrum-node/sequencer/04-run-sequencer-node.mdx | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/docs/run-arbitrum-node/sequencer/04-run-sequencer-node.mdx b/docs/run-arbitrum-node/sequencer/04-run-sequencer-node.mdx index 1512e2a4e4..56d3a91d2e 100644 --- a/docs/run-arbitrum-node/sequencer/04-run-sequencer-node.mdx +++ b/docs/run-arbitrum-node/sequencer/04-run-sequencer-node.mdx @@ -10,7 +10,7 @@ content_type: how-to The following instructions are meant for Arbitrum chains only. This article only applies to test environments. If you need support spinning up a production Arbitrum chain, we recommend contacting a [provider](/launch-arbitrum-chain/06-third-party-integrations/02-third-party-providers.md#rollup-as-a-service-raas-providers). -We also provide a guide for running a high-availability sequencer node for an Arbitrum chain. You can find it [here](./05-high-availability-sequencer-docs.mdx). +We also provide a [guide for running a high-availability sequencer node for an Arbitrum chain](./05-high-availability-sequencer-docs.mdx). ::: This how-to provides step-by-step instructions for running a sequencer node on your local machine.