Orbit V3

arbitrum-docs/launch-orbit-chain/02-configure-your-chain/advanced-configurations/01-layer-leap.mdx

@@ -0,0 +1,7 @@
+---
+title: 'Layer leap'
+description: 'Learn how to configure Layer Leap on your Orbit chain'
+author:
+sme:
+content_type: how-to
+---

arbitrum-docs/launch-orbit-chain/02-configure-your-chain/advanced-configurations/02-fast-withdrawals.mdx

@@ -0,0 +1,7 @@
+---
+title: 'Fast withdrawals'
+description: 'Learn how to configure fast withdrawals on your Orbit chain'
+author:
+sme:
+content_type: how-to
+---

arbitrum-docs/launch-orbit-chain/02-configure-your-chain/advanced-configurations/03-aep-fee-router.mdx

@@ -0,0 +1,7 @@
+---
+title: 'AEP fee router'
+description: 'Learn how to configure your Orbit chain AEP fee router.'
+author:
+sme:
+content_type: how-to
+---

arbitrum-docs/launch-orbit-chain/02-configure-your-chain/common-configurations/02-customizable-challenge-period.mdx

@@ -0,0 +1,69 @@
+---
+title: 'Customizable challenge period'
+description: "Learn how to customize your Orbit chain's challenge period"
+author: 'mahsamoosavi'
+sme: 'mahsamoosavi'
+content_type: how-to
+---
+
+The challenge period defines the time frame during which state updates (assertions) submitted to the parent chain remain open for scrutiny and potential challenges before they are finalized. This mechanism ensures that participants in the system have the opportunity to verify the validity of state updates and raise challenges if necessary.
+
+The length of the challenge period is measured based on the parent chain's notion of time, typically reflected in `block.number`. For L3s settling to Arbitrum chains, this period is determined by L1 block progression rather than Arbitrum's (L2) blocks.
+
+In addition to the main challenge period, ** an extra challenge period ** provides a buffer to resolve any pending challenges after the main period ends. Together, these parameters help balance security and confirm the chain's state.
+
+## Default challenge period and extra challenge period
+
+By default, the challenge period lasts approximately one week, corresponding to the parent chain’s notion of block progression. This equates to roughly 45,818 L1 blocks for chains that settle to Ethereum. The default duration design is to provide sufficient time for validators to detect and challenge fraudulent assertions.
+
+On the other hand, the extra challenge period adds a buffer of 200 blocks based on the parent chain’s notion of block progression. For chains settling to Ethereum, this corresponds to approximately 40 minutes. This time ensures that any last-minute challenges or ongoing dispute resolution processes can be completed before the rollup finalizes its state.
+
+These default values are selected to carefully balance security and performance for most rollup use cases. However, developers and Orbit chain owners may wish to customize these parameters to suit their specific requirements.
+
+## Customizing the challenge period
+
+#### Challenge period blocks
+
+The main challenge period configuration uses the `confirmPeriodBlocks` parameter, which specifies the duration of the challenge window based on the parent chain’s notion of block progression. This parameter can is customizable in two ways:
+
+1. **During deployment**: Developers can specify the desired value in the `confirmPeriodBlocks` field of the RollupCreator configuration when deploying the rollup.
+2. **Post-deployment**: The chain owner can update this value dynamically by calling the `Rollup.setConfirmPeriodBlocks(newValue)` function.
+
+For example, setting `confirmPeriodBlocks` to 30,000 blocks reduces the challenge period to approximately 4.5 days. This configuration might be suitable for applications prioritizing faster state confirmation, while increasing the value would extend the challenge period, improving security.
+
+#### Extra challenge period blocks
+
+The extra challenge period is governable using the `extraChallengeTimeBlocks` parameter, which defines the additional buffer duration after the main challenge period. This period ensures that pending challenges are processed before the rollup state gets finalized.
+
+By default, the extra challenge period is set to **200 blocks**, providing a short but sufficient buffer for most networks. However, developers can increase this value for applications requiring additional dispute resolution time or operate in environments with higher latency between the parent and child chain.
+
+Like the main challenge period, this parameter is customizable in two ways:
+
+1. **During deployment**: The value can be set in the `extraChallengeTimeBlocks` field of the RollupCreator configuration.
+2. **Post-deployment**: The chain owner can dynamically adjust the parameter using the `Rollup.setExtraChallengeTimeBlocks(newExtraTimeBlocks)` function. For example:
+
+For example, the following command can update the extra challenge period to 300 blocks based on the parent chain’s notion of block progression:
+
+```shell
+cast send <ROLLUP_ADMIN_ADDRESS> "setExtraChallengeTimeBlocks(uint256)" 300 \
+  --rpc-url <RPC_URL> \
+  --private-key <PRIVATE_KEY>
+```
+
+Replace:
+
+`<ROLLUP_ADMIN_ADDRESS>` with the contract address of the rollup admin.
+`<RPC_URL>` with the appropriate RPC endpoint.
+`<PRIVATE_KEY>` with the private key of the authorized admin account (e.g., chain owner).
+
+## Recommended values and best practices
+
+For Orbit chains aligned with Arbitrum One's configuration, the recommended settings are:
+
+- **Challenge period blocks**: 45,818 parent chain blocks (approximately one week).
+- **Extra challenge period blocks**: 200 parent chain blocks (approximately 40 minutes).
+
+These values offer a robust and balanced setup for most rollup use cases. Developers should consider their application’s requirements when adjusting these parameters:
+
+- **Shorter periods**: Suitable for applications that benefit from faster state confirmation, such as rollups prioritizing quicker exits or user withdrawals. For chains settling to Ethereum or an Arbitrum chain, this reduces challenge duration based on L1 block times.
+- **Longer periods**: Recommended for applications requiring higher security, such as cross-chain asset transfers or large-value transactions. The actual duration depends on the parent chain’s block intervals (e.g., Ethereum vs. other chains).

arbitrum-docs/launch-orbit-chain/02-configure-your-chain/common-configurations/03-stake-and-validator-configurations.mdx

@@ -0,0 +1,11 @@
+---
+title: 'Stake and validator configurations'
+description: 'Learn how to configure your Orbit chain with a custom stake and validator configurations'
+author:
+sme:
+content_type: how-to
+---
+
+- **Base Stake**: Minimum stake required for validators.
+- **Stake Token**: Token used for staking.
+- **Loser Stake Escrow**: Address for escrowed funds from losing validators.

arbitrum-docs/launch-orbit-chain/02-configure-your-chain/common-configurations/04-arbos-configuration.mdx

@@ -0,0 +1,7 @@
+---
+title: 'ArbOS configuration'
+description: 'Learn how to configure ArbOS on your Orbit chain'
+author: jose-franco
+sme: jose-franco
+content_type: how-to
+---

arbitrum-docs/launch-orbit-chain/02-configure-your-chain/common-configurations/05-gas-optimization-tools.mdx

@@ -0,0 +1,7 @@
+---
+title: 'Gas Optimization Tools'
+description: 'Learn how to configure gas optimization tools for your Orbit chain'
+author:
+sme:
+content_type: how-to
+---

arbitrum-docs/launch-orbit-chain/02-configure-your-chain/common-configurations/06-fee-management.mdx

@@ -0,0 +1,7 @@
+---
+title: 'Fee Management'
+description: 'Learn how to configure fee management for your Orbit chain'
+author:
+sme:
+content_type: how-to
+---

arbitrum-docs/launch-orbit-chain/02-configure-your-chain/common-configurations/07-batch-posting-assertion-control.mdx

@@ -0,0 +1,7 @@
+---
+title: 'Batch Posting and Assertion Control'
+description: 'Learn how to configure batch posting and assertion control for your Orbit chain'
+author:
+sme:
+content_type: how-to
+---

arbitrum-docs/launch-orbit-chain/02-configure-your-chain/common-configurations/08-sequencer-timing-adjustments.mdx

@@ -0,0 +1,7 @@
+---
+title: 'Sequencer Timing Adjustments'
+description: 'Learn how to configure sequencer timing adjustments for your Orbit chain'
+author:
+sme:
+content_type: how-to
+---

arbitrum-docs/launch-orbit-chain/02-configure-your-chain/common-configurations/09-per-batch-gas-cost.mdx

@@ -0,0 +1,7 @@
+---
+title: 'Per batch gas cost'
+description: 'Learn how to configure per batch gas cost  for your Orbit chain'
+author:
+sme:
+content_type: how-to
+---

arbitrum-docs/launch-orbit-chain/02-configure-your-chain/common-configurations/10-smart-contract-size-limit.mdx

@@ -0,0 +1,7 @@
+---
+title: 'Smart contract size limit'
+description: 'Learn how to configure smart contract size limits on your Orbit chain'
+author:
+sme:
+content_type: how-to
+---

arbitrum-docs/launch-orbit-chain/02-configure-your-chain/common-configurations/11-customizing-anytrust.mdx

@@ -0,0 +1,7 @@
+---
+title: 'Customizing AnyTrust'
+description: 'Learn how to customize AnyTrust on your Orbit chain'
+author:
+sme:
+content_type: how-to
+---

arbitrum-docs/launch-orbit-chain/aep-fee-router-introduction.mdx → arbitrum-docs/launch-orbit-chain/02-configure-your-chain/common-configurations/aep-fee-router-introduction.mdx

@@ -39,4 +39,4 @@ The Arbitrum Foundation will track compliance based on fees received through the
 
 ## How can I set up an AEP fee router on my Orbit chain?
 
-You can learn how to set up your AEP fee router in [implementation guide](/launch-orbit-chain/how-tos/set-up-aep-fee-router.mdx).
+You can learn how to set up your AEP fee router in [implementation guide](/launch-orbit-chain/02-configure-your-chain/common-configurations/set-up-aep-fee-router.mdx).

arbitrum-docs/launch-orbit-chain/how-tos/arbos-upgrade.md → arbitrum-docs/launch-orbit-chain/02-configure-your-chain/common-configurations/arbos-upgrade.md

@@ -8,7 +8,7 @@ target_audience: 'Developers maintaining Orbit chains.'
 sidebar_position: 3
 ---
 
-This how-to provides step-by-step instructions for Orbit chain operators who want to upgrade ArbOS on their Orbit chain(s). Familiarity with ArbOS, Orbit, and [chain ownership](../concepts/chain-ownership.md) is expected. Note that Orbit chain owners have full discretion over when and whether to upgrade their ArbOS version.
+This how-to provides step-by-step instructions for Orbit chain operators who want to upgrade ArbOS on their Orbit chain(s). Familiarity with ArbOS, Orbit, and [chain ownership](../../concepts/chain-ownership.md) is expected. Note that Orbit chain owners have full discretion over when and whether to upgrade their ArbOS version.
 
 The specific upgrade requirements for each ArbOS release are located under each reference page for that specific [ArbOS release](/run-arbitrum-node/arbos-releases/01-overview.mdx#list-of-available-arbos-releases).
 
@@ -24,7 +24,7 @@ Note that upgrading your node version _must occur_ before the deadline establish
 
 While every ArbOS upgrade will require an update to the Wasm module root, not every ArbOS upgrade will require an upgrade to the chain's `nitro-contracts` version.
 
-If necessary, as defined in the release notes for each ArbOS release ([example of ArbOS 20](../../run-arbitrum-node/arbos-releases/arbos20.mdx)), you may need to deploy new versions of some (or all) of the Nitro contracts to the parent chain of your Orbit chain. These contracts include the rollup logic, bridging logic, fraud-proof contracts, and interfaces for interacting with Nitro precompiles. To verify the current version of your Nitro contracts, follow [these instructions](https://github.com/OffchainLabs/orbit-actions/blob/main/README.md#check-version-and-upgrade-path) while replacing the inbox contract address and network name with that of your Orbit chain. This information will allow you to find the correct upgrade path for your Nitro contracts.
+If necessary, as defined in the release notes for each ArbOS release ([example of ArbOS 20](/run-arbitrum-node/arbos-releases/arbos20.mdx)), you may need to deploy new versions of some (or all) of the Nitro contracts to the parent chain of your Orbit chain. These contracts include the rollup logic, bridging logic, fraud-proof contracts, and interfaces for interacting with Nitro precompiles. To verify the current version of your Nitro contracts, follow [these instructions](https://github.com/OffchainLabs/orbit-actions/blob/main/README.md#check-version-and-upgrade-path) while replacing the inbox contract address and network name with that of your Orbit chain. This information will allow you to find the correct upgrade path for your Nitro contracts.
 
 To update the Wasm module root and deploy your chain's Nitro contracts to the parent chain for the most recent ArbOS release, you will need the following inputs (obtained from the [requirements for the targeted ArbOS release](/run-arbitrum-node/arbos-releases/01-overview.mdx)):
 

arbitrum-docs/launch-orbit-chain/how-tos/set-up-aep-fee-router.mdx → arbitrum-docs/launch-orbit-chain/02-configure-your-chain/common-configurations/set-up-aep-fee-router.mdx

@@ -49,7 +49,7 @@ This includes:
 
 In the event that a `ChildToParentRouter` does not connect to the address controlled by the Arbitrum Foundation on Ethereum, an Orbit chain must deploy successive `ChildToParentRouter` contracts until a connection to such address is established. Additional `ChildToParentRouter` contracts configured to route ETH have been deployed in certain networks and can be leveraged by chains created on top of these networks. You can see which networks have a router deployed [here](#canonical-contracts).
 
-Optionally, an Orbit chain can decide to deduct assertion costs by following the instructions in the [Deducting Assertion Costs](/launch-orbit-chain/how-tos/calculate-aep-fees#assertion-costs) section:
+Optionally, an Orbit chain can decide to deduct assertion costs by following the instructions in the [Deducting Assertion Costs](/launch-orbit-chain/02-configure-your-chain/common-configurations/calculate-aep-fees.mdx#assertion-costs) section:
 
 <aside>
 🚨 Layer-3 chains with custom gas tokens with L2-based token contracts cannot send their custom gas tokens to Ethereum. A future version of the AEP Fee Router may allow Orbit chains with L2-based tokens to distribute fees using the routing system.

arbitrum-docs/launch-orbit-chain/02-start-your-journey.mdx

@@ -0,0 +1,10 @@
+---
+title: 'Start your journey into Orbit'
+sidebar_label: 'Orbit: get started'
+description: 'Learn how to get started with Orbit'
+sidebar_position: '2'
+author: 'anegg0'
+sme: 'mahsamoosavi'
+editor: 'anegg0'
+target_audience: 'Prospective chain owners, and operators'
+---

arbitrum-docs/launch-orbit-chain/how-tos/orbit-sdk-configuring-orbit-chain.md → arbitrum-docs/launch-orbit-chain/03-deploy-an-orbit-chain/01-configuring-orbit-chain.md

@@ -26,13 +26,13 @@ Orbit chains have three areas of configuration:
 
 ## 1. Parent chain configuration
 
-Configuring the parent chain is the initial step to setting up your Orbit chain. Most of the parent chain configurations are specified during the setup phase. Detailed instructions can be found in the [Rollup Deployment Parameters](/launch-orbit-chain/how-tos/orbit-sdk-deploying-rollup-chain.md#rollup-deployment-parameters) section of the Rollup deployment guide.
+Configuring the parent chain is the initial step to setting up your Orbit chain. Most of the parent chain configurations are specified during the setup phase. Detailed instructions can be found in the [Rollup Deployment Parameters](/launch-orbit-chain/03-deploy-an-orbit-chain/02-deploying-rollup-chain.md#rollup-deployment-parameters) section of the Rollup deployment guide.
 
 After the initial setup, the chain owner can modify configurations as needed. For instance, the validator set can be updated by invoking the [`setValidKeyset`](https://github.com/OffchainLabs/nitro-contracts/blob/90037b996509312ef1addb3f9352457b8a99d6a6/src/bridge/SequencerInbox.sol#L751) function with a new set of validators. This adaptability facilitates your chain's optimization and management.
 
 ## 2. Node configuration
 
-As a chain deployer, you can configure a node during the node config generation process with the `nodeConfig.json` file. `nodeConfig.json` allows you to set up a node as a validator or a sequencer and specify requirements or performance criteria. For more information, refer to the [Node Configuration Preparation](orbit-sdk-preparing-node-config.md) documentation.
+As a chain deployer, you can configure a node during the node config generation process with the `nodeConfig.json` file. `nodeConfig.json` allows you to set up a node as a validator or a sequencer and specify requirements or performance criteria. For more information, refer to the [Node Configuration Preparation](/launch-orbit-chain/how-tos/orbit-sdk-preparing-node-config.md) documentation.
 
 ## 3. Child chain parameter configuration
 
@@ -52,8 +52,8 @@ You can use these setter functions to configure the child chain parameters:
 | `setSpeedLimit`        | The fee mechanism on the Arbitrum Nitro stack differs from the Ethereum blockchain. The Nitro stack has a parameter called the speed limit, which targets the number of gas consumed on the child chain per second. If the amount of gas per second exceeds this pre-specified amount, the base fee on the child chain will increase, and vice versa. The current speed limit on Arbitrum One is 7 million gas per second, meaning if the Arbitrum One chain consumes more than 7 million gas per second, its base fee will increase. For more information on the speed limit, please refer to this [document explaining the concept of speed limit in the Nitro stack](https://docs.arbitrum.io/inside-arbitrum-nitro/#the-speed-limit). |
 | `setInfraFeeAccount`   | Sets the infrastructure fee account address, which receives all fees collected on the child chain. It is meant to receive the minimum base fee, with any amount above that going to the network fee account.                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                              |
 | `setNetworkFeeAccount` | Sets the network fee account address. As mentioned, this address collects all fees above the base fee. Note that if you set this amount to the 0 address on your chain, all fees will be deposited into the infrastructure fee account.                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                   |
-| `scheduleArbOSUpgrade` | If you plan to upgrade the <a data-quicklook-from="arbos">ArbOS</a> version of your chain, this method can help you schedule the upgrade. For a complete guide, please refer to the explanation for the [arbos upgrade](arbos-upgrade.md).                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                |
-| `setChainConfig`       | We discussed the `chainConfig` in the [Rollup deployment guide](./orbit-sdk-deploying-rollup-chain.md#4-chainconfig) in detail. If you wish to change any field of the `chainConfig`, you need to use this method on the child chain.                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                     |
+| `scheduleArbOSUpgrade` | If you plan to upgrade the <a data-quicklook-from="arbos">ArbOS</a> version of your chain, this method can help you schedule the upgrade. For a complete guide, please refer to the explanation for the [arbos upgrade](/launch-orbit-chain/02-configure-your-chain/common-configurations/arbos-upgrade.md).                                                                                                                                                                                                                                                                                                                                                                                                                              |
+| `setChainConfig`       | We discussed the `chainConfig` in the [Rollup deployment guide](/launch-orbit-chain/03-deploy-an-orbit-chain/02-deploying-rollup-chain.md#4-chainconfig) in detail. If you wish to change any field of the `chainConfig`, you need to use this method on the child chain.                                                                                                                                                                                                                                                                                                                                                                                                                                                                 |
 
 ### Getter functions