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,73 @@
+---
+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
+
+:::info How time is measured in challenges
+Chains settling to Ethereum or Arbitrum chains use `block.number` for all block calculations, which corespond to the chain's view of Ethereum's block number. For example, an L3 Arbitrum chain settling to Arbitrum One, will calculate block progression based on Ethereum's (L1) block number.
+:::
+
+By default, the challenge period lasts approximately one week, which equates to roughly 45,818 L1 blocks for chains that settle to Ethereum or an Arbitrum chain. 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 40 minutes by default, 200 L1 blocks for chains settling to Ethereum or an Arbitrum chain. 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.number`. 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, the following command can update the extra challenge period to 300 blocks based on the parent chain’s notion of `block.number`:
+
+```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 Ethereum blocks (approximately one week).
+- **Extra challenge period blocks**: 200 Ethereum 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,10 +39,14 @@ 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).
 
-![SVG diagram](./assets/aep-scenario-1.svg)
-![SVG diagram](./assets/aep-scenario-2.svg)
-![SVG diagram](./assets/aep-scenario-3.svg)
-![SVG diagram](./assets/aep-scenario-4.svg)
-![SVG diagram](./assets/aep-scenario-5.svg)
+![400px-img](../../assets/aep-scenario-1.svg)
+
+![400px-img](../../assets/aep-scenario-2.svg)
+
+![400px-img](../../assets/aep-scenario-3.svg)
+
+![400px-img](../../assets/aep-scenario-4.svg)
+
+![400px-img](../../assets/aep-scenario-5.svg)

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

@@ -0,0 +1,75 @@
+---
+title: 'How to upgrade ArbOS on your Orbit chain'
+sidebar_label: 'Upgrade ArbOS'
+description: 'Learn how to upgrade ArbOS on your Orbit chain.'
+author: greatsoshiant
+sme: greatsoshiant
+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](/launch-orbit-chain/concepts/chain-ownership.mdx) 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).
+
+#### Step 1: Update Nitro on nodes and validators
+
+Refer to the [requirements for the targeted ArbOS release](/run-arbitrum-node/arbos-releases/01-overview.mdx) to identify the specific [Nitro release](https://github.com/OffchainLabs/nitro/releases/) that supports the ArbOS version that you're upgrading to. For example, if your upgrade targets ArbOS 20, you'd use Nitro `v2.3.1` (Docker image: `offchainlabs/nitro-node:v2.3.1-26fad6f`) or higher. This is the version of the Nitro stack that needs to be running on each of your Orbit chain's nodes. A list of [all Nitro releases can be found on Github](https://github.com/OffchainLabs/nitro/releases).
+
+Begin by upgrading your validator node(s) to the specified Nitro version, then update each remaining Orbit node to match this version.
+
+Note that upgrading your node version _must occur_ before the deadline established for the target ArbOS upgrade. Refer to the timestamp in the ArbOS upgrade schedule for a precise deadline.
+
+#### Step 2: Upgrade the Wasm module root & your chain's Nitro contracts
+
+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.
+
+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)):
+
+- The WASM module root, and if necessary,
+- The required `nitro-contracts` version
+
+Once you have the WASM module root and have identified the required `nitro-contracts` version for the target ArbOS release, if any, [please follow the instructions in this guide](https://github.com/OffchainLabs/orbit-actions?tab=readme-ov-file#nitro-contracts-upgrades) for specific actions based on the `nitro-contracts` version you are deploying. Note that each ArbOS release will require performing this step with a different Wasm module root and may require a different version of `nitro-contracts`. The guide linked above will be kept updated with the instructions for each specific ArbOS release.
+
+The `WASM module root` is a 32-byte hash created from the Merkelized Go replay binary and its dependencies. When ArbOS is upgraded, a new Wasm module root is generated due to modifications in the State Transition Function. This new Wasm module root must be set in the rollup contract on the parent chain. You can get the For example, the Wasm module root for ArbOS 20 Atlas is `0x8b104a2e80ac6165dc58b9048de12f301d70b02a0ab51396c22b4b4b802a16a4`.
+
+To set the Wasm module root manually (i.e. not using the above guide), use the `Rollup proxy` contract's [setWasmModuleRoot](https://github.com/OffchainLabs/nitro-contracts/blob/38a70a5e14f8b52478eb5db08e7551a82ced14fe/src/rollup/RollupAdminLogic.sol#L321) method. Note that the `upgrade executor` contract on the parent chain is the designated owner of the rollup contract, so the **chain owner account** needs to initiate a call to the `upgrade executor` contract in order to perform the upgrade. This call should include the correct calldata for setting the new Wasm module root.
+
+:::tip Backward compatibility
+
+Wasm module roots are backward compatible, so upgrading them before an ArbOS version upgrade will not disrupt your chain's functionality.
+
+:::
+
+#### Step 3: Schedule the ArbOS version upgrade
+
+To schedule an ArbOS version upgrade for your Orbit 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 Orbit 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-contracts/blob/acb0ef919cce9f41da531f8dab1b0b31d9860dcb/src/precompiles/ArbOwner.sol#L61) function on the `ArbOwner` precompile of the Orbit 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.
+
+:::tip Immediate upgrades
+
+To upgrade immediately (without scheduling), set the timestamp to `0`.
+
+:::
+
+:::info Obtaining the current ArbOS version
+
+You can obtain the current ArbOS version of your chain by calling `ArbSys.ArbOSVersion()`. Keep in mind that this function adds `55` to the current ArbOS version. For example, if your chain is running on ArbOS 10, calling this function will return `65`.
+
+When scheduling the ArbOS upgrade through `ArbOwner.scheduleArbOSUpgrade` you must use the actual ArbOS version you're upgrading to. For example, if you're upgrading to ArbOS 11, you will pass `11` when calling this function.
+
+:::
+
+#### Step 4: Enable ArbOS specific configurations or feature flags (not always required)
+
+For some ArbOS upgrades, such as [ArbOS 20 Atlas](/run-arbitrum-node/arbos-releases/arbos20.mdx), there may be additional requirements or steps that need to be satisfied to ensure your Orbit chain can use all of the new features and improvements made available in that particular ArbOS release.
+
+If there are additional requirements for the targeted ArbOS release you're attempting to upgrade to; the additional requirements will be listed on the reference pages for [the targeted ArbOS release](/run-arbitrum-node/arbos-releases/01-overview.mdx#list-of-available-arbos-releases). For example, the additional requirements for Orbit chains upgrading to ArbOS 20 can be found [here on the ArbOS 20 docs](/run-arbitrum-node/arbos-releases/arbos20.mdx).
+
+Congratulations! You've upgraded your Orbit chain(s) to the specified ArbOS version.

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'
+---