docs: anytrust-gaps-and-feature-cross-refs

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

@@ -367,7 +367,7 @@ await walletClient.writeContract({
 - Setting `loserStakeEscrow` to a burn address increases the cost of failed challenges, enhancing security.
 - Deploy on testnets first; mainnet deployments are costly and permanent.
 
-## Validator configurations and how to setup them up
+## Validator configurations and how to set them up
 
 Validators are configured during chain deployment and can be run post-launch. Arbitrum chains support permissioned validators, that can be added to an allowlist.
 

docs/launch-arbitrum-chain/02-configure-your-chain/common-configurations/bold-adoption-for-arbitrum-chains.mdx

@@ -17,12 +17,12 @@ This document is currently in **public preview** and may change significantly as
 
 :::
 
-## Launch details and key dates
+## Launch status and key dates
 
 - **Status:** Generally available for L2s and launched on Arbitrum One and Arbitrum Nova. _BoLD for L3s are not yet supported at the time of writing._
 - **Arbitrum Sepolia** Dec 11, 2024
-- <a data-quicklook-from="arbitrum-one">**Arbitrum One**</a> 09:00 ET (GMT-5) on Feb 12, 2025{' '}
-- <a data-quicklook-from="arbitrum-nova">**Arbitrum Nova**</a> 09:00 ET (GMT-5) on Feb 12, 2025{' '}
+- **Arbitrum One** 09:00 ET (GMT-5) on Feb 12, 2025{' '}
+- **Arbitrum Nova** 09:00 ET (GMT-5) on Feb 12, 2025{' '}
 
 ### tldr;
 

docs/launch-arbitrum-chain/02-configure-your-chain/common-configurations/timeboost-for-arbitrum-chains.mdx

@@ -22,7 +22,7 @@ AEP fees will apply here in the future.
 
 </VanillaAdmonition>
 
-## Launch details and key dates
+## Launch status and key dates
 
 - **Status:** Alpha - not formally supported yet for deployments on Arbitrum chains
 - **Arbitrum Sepolia**: Feb 12, 2025

docs/launch-arbitrum-chain/03-deploy-an-arbitrum-chain/02-deploying-an-arbitrum-chain.md → docs/launch-arbitrum-chain/03-deploy-an-arbitrum-chain/02-deploying-an-arbitrum-chain.mdx

@@ -22,7 +22,7 @@ You can explore the code of these contracts in the [nitro-contracts repository](
 
 Upon deployment, an Arbitrum chain can be configured as a <a data-quicklook-from="arbitrum-rollup-chain">Rollup</a> or <a data-quicklook-from="arbitrum-anytrust-chain">AnyTrust</a> chain, and use `ETH` or any standard `ERC-20 `token as its gas token.
 
-This page explains how to deploy an <a data-quicklook-from="arbitrum-chain">Arbitrum chain</a> using the Arbitrum Chain SDK. See the [Overview](/launch-arbitrum-chain/arbitrum-chain-sdk-introduction.md) for an introduction to the process of creating and configuring an Arbitrum chain.
+This page explains how to deploy an <a data-quicklook-from="arbitrum-chain">Arbitrum chain</a> using the Arbitrum Chain SDK. See the [Overview](/launch-arbitrum-chain/arbitrum-chain-sdk-introduction.mdx) for an introduction to the process of creating and configuring an Arbitrum chain.
 
 :::info About custom gas token Arbitrum chains
 

docs/launch-arbitrum-chain/03-deploy-an-arbitrum-chain/05-deploying-token-bridge.md → docs/launch-arbitrum-chain/03-deploy-an-arbitrum-chain/05-deploying-token-bridge.mdx

@@ -16,11 +16,11 @@ The Arbitrum stack doesn't natively support specific token bridging standards at
 
 The token bridge architecture includes contracts deployed on the parent and child chains. These entities communicate via the <a data-quicklook-from='retryable-ticket'>retryable ticket</a> protocol, ensuring efficient and secure interactions.
 
-Once you have deployed your Arbitrum chain and have a node running, you can deploy a token bridge for your chain. See the [Overview](/launch-arbitrum-chain/arbitrum-chain-sdk-introduction.md) for an introduction to creating and configuring an Arbitrum chain.
+Once you have deployed your Arbitrum chain and have a node running, you can deploy a token bridge for your chain. See the [Overview](/launch-arbitrum-chain/arbitrum-chain-sdk-introduction.mdx) for an introduction to creating and configuring an Arbitrum chain.
 
 Before reading this guide, we recommend:
 
-- Becoming familiar with the general process of creating new chains explained in [How to deploy an Arbitrum chain](/launch-arbitrum-chain/03-deploy-an-arbitrum-chain/02-deploying-an-arbitrum-chain.md)
+- Becoming familiar with the general process of creating new chains explained in [How to deploy an Arbitrum chain](/launch-arbitrum-chain/03-deploy-an-arbitrum-chain/02-deploying-an-arbitrum-chain.mdx)
 - Learning about the canonical token bridge in the [Token bridging](/build-decentralized-apps/token-bridging/01-overview.mdx) section
 
 ## Parameters used when deploying a token bridge

docs/launch-arbitrum-chain/03-deploy-an-arbitrum-chain/07-canonical-factory-contracts.mdx

@@ -14,7 +14,7 @@ This page describes the benefits of using these canonical factory contracts and
 
 :::info Use the Arbitrum Chain SDK
 
-You can use these contracts to create Arbitrum chains. However, it is strongly recommended to go through the [Chain SDK](/launch-arbitrum-chain/arbitrum-chain-sdk-introduction.md) to interact with them. Doing so prevents misconfiguring parameters and using appropriate defaults for most of them.
+You can use these contracts to create Arbitrum chains. However, it is strongly recommended to go through the [Chain SDK](/launch-arbitrum-chain/arbitrum-chain-sdk-introduction.mdx) to interact with them. Doing so prevents misconfiguring parameters and using appropriate defaults for most of them.
 
 :::
 

docs/launch-arbitrum-chain/05-customize-your-chain/customize-arbos.mdx

@@ -109,7 +109,7 @@ It should be noted that when you initialize the state (initial code is in [custo
 Also, please make sure your program cannot call the `state.SetNewMyNumber` or other functions may change the value of `myNumber` before ArbOS v21.
 To prevent this, if you are using an external call to the precompile contract to change the value, you can refer to [point 1](./customize-arbos.mdx#1-add-a-new-method-to-existing-precompile-on-a-specific-arbos-version) or
 [point 2](./customize-arbos.mdx#2-create-a-new-precompile-contract-on-a-specific-arbos-version) to set the activation time of the precompile contract method.
-If your nitro code needs to call this method to change the state, you can continue reading [point 4](./customize-arbos.mdx#4-any-changes-in-the-stf-logic-that-will-affect-the-final-execution-result).
+If your nitro code needs to call this method to change the state, you can continue reading [Step 4](./customize-arbos.mdx#4-any-changes-in-the-stf-logic-that-will-affect-the-final-execution-result-arbos-version-control).
 
 ### 4. Any changes in the STF logic that will affect the final execution result (ArbOS version control)
 

docs/launch-arbitrum-chain/06-third-party-integrations/01-bridged-usdc-standard.md

@@ -41,7 +41,7 @@ Other requirements:
 
 - It is assumed there is already a `USDC` token deployed and used on the parent chain.
 - Also, it is assumed that the standard Arbitrum chain ownership system is used, i.e., `UpgradeExecutor` is the owner of the `ownable` contracts, and there is an EOA or multi-sig that has the executor role on the `UpgradeExecutor`.
-- Refer to the [token bridge overview page](/launch-arbitrum-chain/03-deploy-an-arbitrum-chain/05-deploying-token-bridge.md) for more information about the token bridge design and operational dynamics. You can learn more in our [overview of gateways operating models](/build-decentralized-apps/token-bridging/03-token-bridge-erc20.mdx#other-flavors-of-gateways).
+- Refer to the [token bridge overview page](/launch-arbitrum-chain/03-deploy-an-arbitrum-chain/05-deploying-token-bridge.mdx) for more information about the token bridge design and operational dynamics. You can learn more in our [overview of gateways operating models](/build-decentralized-apps/token-bridging/03-token-bridge-erc20.mdx#other-flavors-of-gateways).
 
 ## Deployment steps
 

docs/launch-arbitrum-chain/arbitrum-chain-sdk-introduction.md → docs/launch-arbitrum-chain/arbitrum-chain-sdk-introduction.mdx

@@ -38,12 +38,12 @@ Additionally, Arbitrum chains can be configured to use `ETH` or any standard `ER
 
 ## 2. Deploy your chain
 
-After selecting a chain type, follow [this guide](/launch-arbitrum-chain/03-deploy-an-arbitrum-chain/02-deploying-an-arbitrum-chain.md) to deploy your chain using the Chain SDK.
+After selecting a chain type, follow [this guide](/launch-arbitrum-chain/03-deploy-an-arbitrum-chain/02-deploying-an-arbitrum-chain.mdx) to deploy your chain using the Chain SDK.
 
 ## 3. Configure your Arbitrum chain's node
 
 Once the chain is deployed, you'll need to generate the configuration to run its node. To learn how, visit [Configure your Arbitrum chain's node](/launch-arbitrum-chain/how-tos/arbitrum-chain-sdk-preparing-node-config.md).
 
 ## 4. Deploy your Arbitrum chain's token bridge
 
-Your Arbitrum chain's token bridge contracts allow `ERC-20` tokens to move between your Arbitrum chain and its underlying parent chain. Read [Deploy your Arbitrum chain's token bridge](/launch-arbitrum-chain/03-deploy-an-arbitrum-chain/05-deploying-token-bridge.md) to learn how to set up your bridge.
+Your Arbitrum chain's token bridge contracts allow `ERC-20` tokens to move between your Arbitrum chain and its underlying parent chain. Read [Deploy your Arbitrum chain's token bridge](/launch-arbitrum-chain/03-deploy-an-arbitrum-chain/05-deploying-token-bridge.mdx) to learn how to set up your bridge.

docs/launch-arbitrum-chain/features/advanced/choose-arbos-version.mdx

@@ -12,7 +12,7 @@ Customizing the <a data-quicklook-from="arbos">ArbOS</a> version involves modify
 
 - **ArbOS**: The hypervisor-like layer in Nitro that manages the chain's execution environment, including STF, precompiles, state, and upgrades. Versions are numbered (e.g., starting from 20 in increments of 10 for canonical releases like "Atlas"), with names taken from planetary moons (e.g., "Atlas" for 20, "Bianca" for 30). Custom versions can use intermediates (e.g., 21-29) for project-specific forks.
 - **State Transition Function (STF)**: The deterministic process for computing new states from transactions. Customizations here (e.g., new logic or states) often necessitate an ArbOS upgrade to integrate changes into the replay binary used for fraud proofs.
-- **<a data-quicklook-from="wasm">WASM</a> Module Root**: A 32-byte hash of the STF's implementation (e.g., 0x8b104a2e80ac6165dc58b9048de12f301d70b02a0ab51396c22b4b4b802a16a4 for ArbOS 20). Customizations require updating this on the <a data-quicklook-from="parent-chain">parent chain</a> for compatibility validation.
+- **<a data-quicklook-from="wasm">WASM</a> Module Root**: A 32-byte hash of the STF's implementation (e.g., `0x8b104a2e80ac6165dc58b9048de12f301d70b02a0ab51396c22b4b4b802a16a4` for ArbOS 20). Customizations require updating this on the <a data-quicklook-from="parent-chain">parent chain</a> for compatibility validation.
 - **Backward compatibility**: Changes must preserve old block results; new features activate only post-upgrade via version gates (e.g., `if state.ArbOSVersion() >= targetVersion`). For more details, please refer to [ArbOS version control](/launch-arbitrum-chain/05-customize-your-chain/customize-arbos.mdx#4-any-changes-in-the-stf-logic-that-will-affect-the-final-execution-result-arbos-version-control).
 
 ### Compatibility

docs/launch-arbitrum-chain/features/advanced/choose-chain-precompiles.mdx

@@ -6,7 +6,7 @@ sme: jason-w123
 content_type: configuration
 ---
 
-Customizing your chain's precompiles refers to modifying or extending the built-in, system-level <a data-quicklook-from="smart-contract">smart contract</a>-like functions (precompiles) that provide efficient access to chain-specific operations, such as interacting with the <a data-quicklook-from="parent-chain">parent chain</a> (<a data-quicklook-from="l1">L1</a> or <a data-quicklook-from="l2">L2</a>), querying state, or performing computations. Precompiles are hardcoded at specific addresses (e.g., 0x64 for `ArbSys`) and executed outside the EVM bytecode level for performance. They inherit Ethereum's standard precompiles (e.g., for hashing or elliptic curves) while adding <a data-quicklook-from="arbitrum">Arbitrum</a>-specific ones (e.g., `ArbAddressTable` for address compression).
+Customizing your chain's precompiles refers to modifying or extending the built-in, system-level <a data-quicklook-from="smart-contract">smart contract</a>-like functions (precompiles) that provide efficient access to chain-specific operations, such as interacting with the <a data-quicklook-from="parent-chain">parent chain</a> (L1/L2), querying state, or performing computations. Precompiles are hardcoded at specific addresses (e.g., 0x64 for `ArbSys`) and executed outside the EVM bytecode level for performance. They inherit Ethereum's standard precompiles (e.g., for hashing or elliptic curves) while adding <a data-quicklook-from="arbitrum">Arbitrum</a>-specific ones (e.g., `ArbAddressTable` for address compression).
 
 Customization allows developers to add new methods, events, gas logic, or state interactions tailored to the chain's needs, such as app-specific utilities or optimizations. This flexibility is an advanced feature requiring modifications to the Nitro software stack, enabling deeper chain personalization beyond defaults like custom gas tokens or DA modes.
 

docs/launch-arbitrum-chain/features/advanced/choose-custom-delay-inbox-finality.mdx

@@ -71,3 +71,7 @@ This affects only incoming (parent-to-child) Delayed Inbox flows; outgoing (chil
 - **DACert-optimized**: On Nova settlement with default flags, finality ties to DACert posting (~tens of minutes); configuring low-distance speeds reduces this to ~1 minute for gaming apps needing quick asset transfers.
 
 This feature underscores Arbitrum's modularity for performance tuning while inheriting parent security. For implementation, refer to the latest Nitro sequencer docs or your <a data-quicklook-from="raas">RaaS</a>; a [list of RaaSes is on the Third-party providers page](/launch-arbitrum-chain/06-third-party-integrations/02-third-party-providers.md#rollup-as-a-service-raas-providers).
+
+## How to configure
+
+For instructions on how to configure the delayed inbox finality, refer to the [How to configure Delayed Inbox finality](/launch-arbitrum-chain/02-configure-your-chain/common-configurations/arbitrum-chain-finality.mdx) page.

docs/launch-arbitrum-chain/features/common/configure-aep/configure-aep-fees.mdx

@@ -43,6 +43,18 @@ The configuration ensures compliance with the AEP terms, streamlines reporting,
 
 ## How to configure
 
+:::warning Caution
+
+This is an abbreviated set of instructions on how to configure AEP fees. For a complete set of instructions refer to the [AEP fee router introduction](/launch-arbitrum-chain/02-configure-your-chain/advanced-configurations/aep-fee-router/01-aep-fee-router-introduction.mdx).
+
+Additional resources:
+
+- [Setup AEP fee router](/launch-arbitrum-chain/02-configure-your-chain/advanced-configurations/aep-fee-router/02-set-up-aep-fee-router.mdx)
+- [Calculate AEP fees](/launch-arbitrum-chain/02-configure-your-chain/advanced-configurations/aep-fee-router/03-calculate-aep-fees.mdx)
+- [Reporting on AEP fees](/launch-arbitrum-chain/02-configure-your-chain/advanced-configurations/aep-fee-router/04-reporting-on-fees.mdx)
+
+:::
+
 1. **Calculate net revenue**: Use tools or scripts to track total fees minus settlement costs (e.g., via on-chain queries or off-chain monitoring). For custom tokens, deploy a pricer contract to value fees in `ETH` equivalents.
 2. **Deploy fee router**: Use the Arbitrum Chain SDK script (e.g., [`aep-fee-router`](https://github.com/OffchainLabs/arbitrum-chain-sdk/tree/main/examples/setup-aep-fee-router)) to deploy contracts like RewardDistributor on your chain. Set it as a fee collector (e.g., for surplus fees via `ArbOwner` precompile).
 3. **Route and <a data-quicklook-from="bridge">bridge</a> fees**: Configure the router to send the 10% share to Ethereum (e.g., via native bridges), then deposit to the DAO address on Arbitrum One. Use functions like `RewardDistributor.distributeRewards` for periodic transfers.

docs/launch-arbitrum-chain/features/common/data-availability/choose-alt-da.mdx

@@ -20,7 +20,7 @@ Selecting Alt-DA means integrating an external provider into your Arbitrum chain
 ## How it differs:
 
 - From **Rollup**: Alt-DA moves data off Ethereum entirely, avoiding L1 gas costs but potentially sacrificing some decentralization if the external layer has different security properties (e.g., Celestia uses data availability sampling for efficiency).
-- From **AnyTrust**: While both are off-chain, AnyTrust uses Arbitrum's own DAC (permissioned and integrated), whereas Alt-DA leverages independent networks with their own consensus and incentives, offering more modularity but requiring additional setup and trust in the provider's model.
+- From **AnyTrust**: While both are offchain, AnyTrust uses Arbitrum's own DAC (permissioned and integrated), whereas Alt-DA leverages independent networks with their own consensus and incentives, offering more modularity but requiring additional setup and trust in the provider's model.
 
 <!-- Render Alt-DA Pros & Cons Partial -->
 
@@ -35,4 +35,4 @@ Arbitrum chains supports integrations with several Alt-DA solutions, including:
 - **EigenDA (via EigenLayer)**: Leverages restaking for secure, decentralized DA.
 - For a list of Alt-DA providers, refer to the [Third-party providers page](launch-arbitrum-chain/06-third-party-integrations/02-third-party-providers.md#data-availability-providers-for-anytrust-chains)
 
-This option reflects the growing trend toward modular blockchain architectures, where DA handling is separate to scale ecosystems like Arbitrum without compromising core security. For implementation, refer to the docs or your <a data-quicklook-from="raas">RaaS</a>; a [list of RaaSes is on the Third-party providers page](/launch-arbitrum-chain/06-third-party-integrations/02-third-party-providers.md#rollup-as-a-service-raas-providers).
+This option reflects the growing trend toward modular blockchain architectures, where DA handling is separate to scale ecosystems like Arbitrum without compromising core security.

docs/launch-arbitrum-chain/features/common/data-availability/choose-anytrust.mdx

@@ -26,4 +26,28 @@ It's ideal for use cases where ultra-low fees are a priority over Ethereum's ful
 
 <AnytrustPCPartial />
 
-This option reflects the growing trend toward modular <a data-quicklook-from="blockchain">blockchain</a> architectures, where DA handling is separate to scale ecosystems like Arbitrum without compromising core security. For implementation, refer to the docs or your RaaS; a [list of RaaSes is on the Third-party providers page](/launch-arbitrum-chain/06-third-party-integrations/02-third-party-providers.md#rollup-as-a-service-<a data-quicklook-from="raas">RaaS</a>-providers).
+This option reflects the growing trend toward modular <a data-quicklook-from="blockchain">blockchain</a> architectures, where DA handling is separate to scale ecosystems like Arbitrum without compromising core security. For implementation, refer to the docs or your RaaS; a [list of RaaSes is on the Third-party providers page](/launch-arbitrum-chain/06-third-party-integrations/02-third-party-providers.md#rollup-as-a-service-raas-providers).
+
+## How to configure
+
+To configure AnyTrust this is a pre-deployment decision. You must choose whether or not you will be leveraging AnyTrust prior to deploying your chain.
+
+When calling the `prepareChainConfig` function, it will create a `chainConfig` structure. It sets the appropriate default values for most of the parameters, which allows you to override any of the defaults.
+
+Below is an example of how to use `prepareChainConfig` to set the chain configuration for an AnyTrust chain (`chainId` and `InitialChainOwner` are not set by default):
+
+```typescript
+import { prepareChainConfig } from '@arbitrum/chain-sdk';
+
+const chainConfig = prepareChainConfig({
+  chainId: 123_456,
+  arbitrum: {
+    InitialChainOwner: 0x123...890,
+    // The following parameter determines whether this is an AnyTrust chain
+    // AnyTrust = true, Rollup = false
+    DataAvailabilityCommittee: true,
+  },
+});
+```
+
+For complete deployment instructions refer to the [Deploy an Arbitrum chain](/launch-arbitrum-chain/03-deploy-an-arbitrum-chain/02-deploying-an-arbitrum-chain.mdx) page.

docs/launch-arbitrum-chain/features/common/data-availability/choose-rollup.mdx

@@ -27,3 +27,9 @@ This flexibility allows developers to tailor chains to specific needs while buil
 <RollupPCPartial />
 
 For implementation, refer to the docs or your <a data-quicklook-from="raas">RaaS</a>; a [list of RaaSes is on the Third-party providers page](/launch-arbitrum-chain/06-third-party-integrations/02-third-party-providers.md#rollup-as-a-service-raas-providers).
+
+## Configuration
+
+For an example standard (`ETH` as gas token) configuration of deploying an Arbitrum chain as a Rollup, refer to the [`create-rollup-eth`](https://github.com/OffchainLabs/arbitrum-chain-sdk/tree/main/examples/create-rollup-eth) example in the Arbitrum Chain SDK repo.
+
+To use a custom gas token you can read more on the [Use a custom gas token Rollup](/launch-arbitrum-chain/02-configure-your-chain/common-configurations/02-use-a-custom-gas-token-rollup.mdx) page, or you can view an example deployment configuration in the Arbitrum Chain SDK repo, [`create-rollup-custom-fee-token`](https://github.com/OffchainLabs/arbitrum-chain-sdk/tree/main/examples/create-rollup-custom-fee-token).