OffchainLabs · pete-vielhaber · Jan 12, 2026 · Jan 12, 2026 · Jan 12, 2026 · Jan 12, 2026
diff --git a/docs/get-started/overview.mdx b/docs/get-started/overview.mdx
@@ -50,12 +50,12 @@ The Arbitrum suite includes the protocols, chains, services, and SDKs that power
 
 **Node runners** run the machines that support the Arbitrum ecosystem.
 
-| Resource                                                                                                      | Description                                                                                                      |
-| ------------------------------------------------------------------------------------------------------------- | ---------------------------------------------------------------------------------------------------------------- |
-| [Run a full node](/run-arbitrum-node/02-run-full-node.mdx)                                                    | For node runners who want to access Arbitrum chains without having to connect to a third-party node.             |
-| [Configure a Data Availability Committee](/run-arbitrum-node/data-availability-committees/01-get-started.mdx) | For Data Availability Committee members and Arbitrum chain operators who want to run a Data Availability Server. |
-| [Run an Arbitrum feed relay](/run-arbitrum-node/run-feed-relay.mdx)                                           | For node runners running multiple nodes.                                                                         |
-| [how to run an Arbitrum archive node](/run-arbitrum-node/more-types/01-run-archive-node.mdx)                  | When access to extensive historical data or advanced analytical purposes is required.                            |
+| Resource                                                                                                                                                           | Description                                                                                                      |
+| ------------------------------------------------------------------------------------------------------------------------------------------------------------------ | ---------------------------------------------------------------------------------------------------------------- |
+| [Run a full node](/run-arbitrum-node/02-run-full-node.mdx)                                                                                                         | For node runners who want to access Arbitrum chains without having to connect to a third-party node.             |
+| [Configure a Data Availability Committee](/launch-arbitrum-chain/02-configure-your-chain/common/data-availability/data-availability-committees/01-get-started.mdx) | For Data Availability Committee members and Arbitrum chain operators who want to run a Data Availability Server. |
+| [Run an Arbitrum feed relay](/run-arbitrum-node/run-feed-relay.mdx)                                                                                                | For node runners running multiple nodes.                                                                         |
+| [how to run an Arbitrum archive node](/run-arbitrum-node/more-types/01-run-archive-node.mdx)                                                                       | When access to extensive historical data or advanced analytical purposes is required.                            |
 
 ## Arbitrum for chain operators
 

diff --git a/...advanced-configurations/04-layer-leap.mdx → ...ure-your-chain/advanced/04-layer-leap.mdx b/...advanced-configurations/04-layer-leap.mdx → ...ure-your-chain/advanced/04-layer-leap.mdx
diff --git a/...nfigurations/da-api-integration-guide.mdx → ...ain/advanced/da-api-integration-guide.mdx b/...nfigurations/da-api-integration-guide.mdx → ...ain/advanced/da-api-integration-guide.mdx
@@ -97,7 +97,7 @@ Your DA provider exposes JSON-RPC methods that Nitro nodes call to store and ret
 
 1. **Design your certificate format** ([Section 6](#6-designing-your-certificate-format))
 2. **Implement reader RPC methods** to recover data from certificates ([Section 3](#3-implementing-reader-rpc-methods))
-3. **Implement writer RPC method** to generate certificates ([Section 4](#4-implementing-the-writer-rpc-method))
+3. **Implement writer RPC method** to generate certificates ([Section 4](#4-implementing-the-writer-rpc-methods))
 4. **Implement validator RPC methods** to generate proofs ([Section 5](#5-implementing-validator-rpc-methods))
 5. **Implement the onchain validator contract** for proof validation (Section 7)
 6. **Create your JSON-RPC server** exposing these methods ([Section 9](#9-configuration--deployment))

diff --git a/...ce/additional-configuration-parameters.md → ...n/additional-configuration-parameters.mdx b/...ce/additional-configuration-parameters.md → ...n/additional-configuration-parameters.mdx
@@ -5,6 +5,6 @@ sidebar_label: Additional configuration parameters
 
 The following configuration parameters can be used when deploying or managing your Arbitrum chain:
 
-import OptionalOrbitCompatibleCLIFlagsPartial from '../../partials/_additional-config-params.mdx';
+import OptionalOrbitCompatibleCLIFlagsPartial from '../../../partials/_additional-config-params.mdx';
 
 <OptionalOrbitCompatibleCLIFlagsPartial />
diff --git a/...router/01-aep-fee-router-introduction.mdx → ...p-fees/01-aep-fee-router-introduction.mdx b/...router/01-aep-fee-router-introduction.mdx → ...p-fees/01-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 Arbitrum chain?
 
-You can learn how to set up your AEP fee router in the [implementation guide](/launch-arbitrum-chain/02-configure-your-chain/advanced-configurations/aep-fee-router/02-set-up-aep-fee-router.mdx).
+You can learn how to set up your AEP fee router in the [implementation guide](/launch-arbitrum-chain/02-configure-your-chain/common/aep-fees/02-set-up-aep-fee-router.mdx).
diff --git a/...p-fee-router/02-set-up-aep-fee-router.mdx → ...mon/aep-fees/02-set-up-aep-fee-router.mdx b/...p-fee-router/02-set-up-aep-fee-router.mdx → ...mon/aep-fees/02-set-up-aep-fee-router.mdx
diff --git a/.../aep-fee-router/03-calculate-aep-fees.mdx → ...common/aep-fees/03-calculate-aep-fees.mdx b/.../aep-fee-router/03-calculate-aep-fees.mdx → ...common/aep-fees/03-calculate-aep-fees.mdx
diff --git a/...s/aep-fee-router/04-reporting-on-fees.mdx → .../common/aep-fees/04-reporting-on-fees.mdx b/...s/aep-fee-router/04-reporting-on-fees.mdx → .../common/aep-fees/04-reporting-on-fees.mdx
diff --git a/...-chain/common/data-availability/data-availability-committees/01-get-started.mdx b/...-chain/common/data-availability/data-availability-committees/01-get-started.mdx
@@ -0,0 +1,51 @@
+---
+title: 'How to configure a Data Availability Committee: Introduction'
+description: Learn what's needed to configure a Data Availability Committee for your chain
+author: jose-franco
+sidebar_position: 1
+content_type: overview
+---
+
+<p>
+  <a data-quicklook-from="arbitrum-anytrust-protocol">AnyTrust</a> chains rely on an external Data
+  Availability Committee (DAC) to store data and provide it on-demand instead of using its{' '}
+  <a data-quicklook-from="parent-chain">parent chain</a> as the Data Availability (DA) layer. The
+  members of the DAC run a Data Availability Server (DAS) to handle these operations.
+</p>
+
+This section offers information and a series of how-to guides to help you along the process of setting up a Data Availability Committee. These guides target two audiences: Committee members who wish to deploy a Data Availability Server, and chain owners who wish to configure their chain with the information of the Committee.
+
+Before following the guides in this section, you should be familiar with how the AnyTrust protocol works and the role of the DAC in the protocol. Refer to the [AnyTrust Protocol](/how-arbitrum-works/deep-dives/anytrust-protocol.mdx) documentation to learn more.
+
+## If you are a DAC member
+
+Committee members will need to run a DAS. To do that, they will first need to generate a pair of keys and deploy a DAS. They may also choose to deploy an additional mirror DAS. Find more information in [How to deploy a DAS](/launch-arbitrum-chain/02-configure-your-chain/common/data-availability/data-availability-committees/02-deploy-das.mdx) and [How to deploy a mirror DAS](/launch-arbitrum-chain/02-configure-your-chain/common/data-availability/data-availability-committees/03-deploy-mirror-das.mdx).
+
+Here's a basic checklist of actions to complete for DAC members:
+
+- [Deploy a DAS](/launch-arbitrum-chain/02-configure-your-chain/common/data-availability/data-availability-committees/02-deploy-das.mdx). Send the following information to the chain owner:
+  - Public BLS key
+  - The https URL for the RPC endpoint which includes some random string (e.g., das.your-chain.io/rpc/randomstring123), communicated through a secure channel
+  - The https URL for the REST endpoint (e.g., das.your-chain.io/rest)
+- [Deploy a mirror DAS](/launch-arbitrum-chain/02-configure-your-chain/common/data-availability/data-availability-committees/03-deploy-mirror-das.mdx) if you want to complement your setup with a mirror DAS. Send the following information to the chain owner:
+  - The https URL for the REST endpoint (e.g., das.your-chain.io/rest)
+
+## If you are a chain owner
+
+Chain owners will need to gather the information from the committee members to craft the necessary data to update their chain and the batch poster (more information in [How to configure the DAC in your chain](/launch-arbitrum-chain/02-configure-your-chain/common/data-availability/data-availability-committees/04-configure-dac.mdx)). They might also want to test each DAS individually, by following the testing guides available in [How to deploy a DAS](/launch-arbitrum-chain/02-configure-your-chain/common/data-availability/data-availability-committees/02-deploy-das.mdx#testing-the-das) and [How to deploy a mirror DAS](/launch-arbitrum-chain/02-configure-your-chain/common/data-availability/data-availability-committees/03-deploy-mirror-das.mdx#testing-the-das).
+
+Here's a basic checklist of actions to complete for chain owners:
+
+- Gather the following information from every member of the committee:
+  - Public BLS Key
+  - URL of the RPC endpoint
+  - URL(s) of the REST endpoint(s)
+- Ensure that at least one DAS is running as an [archive DAS](/launch-arbitrum-chain/02-configure-your-chain/common/data-availability/data-availability-committees/02-deploy-das.mdx#archive-da-servers)
+- [Generate the keyset and keyset hash](/launch-arbitrum-chain/02-configure-your-chain/common/data-availability/data-availability-committees/04-configure-dac.mdx#step-1-generate-the-keyset-and-keyset-hash-with-all-the-information-from-the-servers) with all the information from the servers
+- [Update the `SequencerInbox` contract](/launch-arbitrum-chain/02-configure-your-chain/common/data-availability/data-availability-committees/04-configure-dac.mdx#step-2-update-the-sequencerinbox-contract)
+- [Craft the new configuration for the batch poster](/launch-arbitrum-chain/02-configure-your-chain/common/data-availability/data-availability-committees/04-configure-dac.mdx#step-3-craft-the-new-configuration-for-the-batch-poster)
+- [Craft the new configuration for your chain's nodes](/launch-arbitrum-chain/02-configure-your-chain/common/data-availability/data-availability-committees/04-configure-dac.mdx#step-4-craft-the-new-configuration-for-your-chains-nodes)
+
+## Ask for help
+
+Configuring a DAC might be a complex process. If you need help setting it up, don't hesitate to ask us on [Discord](https://discord.gg/arbitrum).
diff --git a/...availability-committees/02-deploy-das.mdx → ...availability-committees/02-deploy-das.mdx b/...availability-committees/02-deploy-das.mdx → ...availability-committees/02-deploy-das.mdx
@@ -18,7 +18,7 @@ In this how-to, you'll learn how to deploy a DAS that exposes:
 1. **An RPC interface** that the sequencer uses to store batches of data on the DAS.
 2. **An HTTP REST interface** that lets the DAS respond to requests for those batches of data.
 
-For more information related to configuring a DAC, refer to the [Introduction](/run-arbitrum-node/data-availability-committees/01-get-started.mdx).
+For more information related to configuring a DAC, refer to the [Introduction](/launch-arbitrum-chain/02-configure-your-chain/common/data-availability/data-availability-committees/01-get-started.mdx).
 
 This how-to assumes that you're familiar with:
 
@@ -171,10 +171,10 @@ Finally, for the storage backends you wish to configure, use the following param
 
 import Tabs from '@theme/Tabs';
 import TabItem from '@theme/TabItem';
-import S3Parameters from '../../node-running/how-tos/data-availability-committee/partials/parameters/_s3-parameters.mdx';
-import LocalFilesParameters from '../../node-running/how-tos/data-availability-committee/partials/parameters/_local-files-parameters.mdx';
-import GoogleCloudStorageParameters from '../../node-running/how-tos/data-availability-committee/partials/parameters/_gcs-parameters.mdx';
-import LocalBadgerDBParameters from '../../node-running/how-tos/data-availability-committee/partials/parameters/_local-badger-db-parameters.mdx';
+import S3Parameters from './/partials/parameters/_s3-parameters.mdx';
+import LocalFilesParameters from './/partials/parameters/_local-files-parameters.mdx';
+import GoogleCloudStorageParameters from './/partials/parameters/_gcs-parameters.mdx';
+import LocalBadgerDBParameters from './/partials/parameters/_local-badger-db-parameters.mdx';
 
 <div className="dynamic-content-tabs">
   <Tabs className="tabgroup" defaultValue={null}>
@@ -440,7 +440,7 @@ In general, mirror DA servers serve two main purposes:
 1. Prevent the main DAS from having to serve requests for data, allowing it to focus only on storing the data received.
 2. Provide resiliency to the network in the case of a DAS going down.
 
-Find information about how to setup a mirror DAS in [How to deploy a mirror DAS](/run-arbitrum-node/data-availability-committees/03-deploy-mirror-das.mdx).
+Find information about how to setup a mirror DAS in [How to deploy a mirror DAS](/launch-arbitrum-chain/02-configure-your-chain/common/data-availability/data-availability-committees/03-deploy-mirror-das.mdx).
 
 ## Security considerations
 
@@ -486,8 +486,8 @@ Once the DAS is deployed and tested, you'll have to communicate the following in
 - The https URL for the RPC endpoint which includes some random string (e.g., das.your-chain.io/rpc/randomstring123), communicated through a secure channel
 - The https URL for the REST endpoint (e.g., das.your-chain.io/rest)
 
-import DASOptionalParameters from '../../node-running/how-tos/data-availability-committee/partials/_das-optional-parameters.mdx';
-import DASMetrics from '../../node-running/how-tos/data-availability-committee/partials/_das-metrics.mdx';
+import DASOptionalParameters from './/partials/_das-optional-parameters.mdx';
+import DASMetrics from './/partials/_das-metrics.mdx';
 
 ## Optional parameters
 

diff --git a/...ility-committees/03-deploy-mirror-das.mdx → ...ility-committees/03-deploy-mirror-das.mdx b/...ility-committees/03-deploy-mirror-das.mdx → ...ility-committees/03-deploy-mirror-das.mdx
@@ -8,7 +8,7 @@ content_type: how-to
 
 :::caution Running a regular DAS vs running a mirror DAS
 
-The main use-case for running a mirror DAS is to complement your setup as a Data Availability Committee (DAC) member. That means that you should run your main DAS first, and then configure the mirror DAS. Refer to [How to deploy a DAS](/run-arbitrum-node/data-availability-committees/02-deploy-das.mdx) if needed.
+The main use-case for running a mirror DAS is to complement your setup as a Data Availability Committee (DAC) member. That means that you should run your main DAS first, and then configure the mirror DAS. Refer to [How to deploy a DAS](/launch-arbitrum-chain/02-configure-your-chain/common/data-availability/data-availability-committees/02-deploy-das.mdx) if needed.
 
 :::
 
@@ -19,16 +19,16 @@ The main use-case for running a mirror DAS is to complement your setup as a Data
   members of the DAC run a Data Availability Server (DAS) to handle these operations.
 </p>
 
-In this how-to, you'll learn how to configure a mirror DAS that serves `GET` requests for stored batches of information through a REST HTTP interface. For a refresher on DACs, refer to the [Introduction](/run-arbitrum-node/data-availability-committees/01-get-started.mdx).
+In this how-to, you'll learn how to configure a mirror DAS that serves `GET` requests for stored batches of information through a REST HTTP interface. For a refresher on DACs, refer to the [Introduction](/launch-arbitrum-chain/02-configure-your-chain/common/data-availability/data-availability-committees/01-get-started.mdx).
 
 This how-to assumes that you're familiar with:
 
-- How a regular DAS works and what configuration options are available. Refer to [How to deploy a DAS](/run-arbitrum-node/data-availability-committees/02-deploy-das.mdx) for a refresher.
+- How a regular DAS works and what configuration options are available. Refer to [How to deploy a DAS](/launch-arbitrum-chain/02-configure-your-chain/common/data-availability/data-availability-committees/02-deploy-das.mdx) for a refresher.
 - [Kubernetes](https://kubernetes.io/). The examples in this guide use Kubernetes to containerize your DAS.
 
 ## What is a mirror DAS?
 
-To avoid exposing the REST interface of your main DAS to the public in order to prevent spamming attacks (as explained in [How to deploy a DAS](/run-arbitrum-node/data-availability-committees/02-deploy-das.mdx#security-considerations)), you can choose to run a mirror DAS to complement your setup. The mirror DAS will handle all public REST requests, while reading information from the main DAS via its (now private) REST interface.
+To avoid exposing the REST interface of your main DAS to the public in order to prevent spamming attacks (as explained in [How to deploy a DAS](/launch-arbitrum-chain/02-configure-your-chain/common/data-availability/data-availability-committees/02-deploy-das.mdx#security-considerations)), you can choose to run a mirror DAS to complement your setup. The mirror DAS will handle all public REST requests, while reading information from the main DAS via its (now private) REST interface.
 
 In general, mirror DA servers serve two main purposes:
 
@@ -37,7 +37,7 @@ In general, mirror DA servers serve two main purposes:
 
 ## Configuration options
 
-A mirror DAS will use the same tool and, thus, the same configuration options as your main DAS. You can find an explanation of those options in [How to deploy a DAS](/run-arbitrum-node/data-availability-committees/02-deploy-das.mdx#configuration-options).
+A mirror DAS will use the same tool and, thus, the same configuration options as your main DAS. You can find an explanation of those options in [How to deploy a DAS](/launch-arbitrum-chain/02-configure-your-chain/common/data-availability/data-availability-committees/02-deploy-das.mdx#configuration-options).
 
 ## How to deploy a mirror DAS
 
@@ -117,10 +117,10 @@ A migration tool has been included in Nitro to migrate all data from the local b
 
 import Tabs from '@theme/Tabs';
 import TabItem from '@theme/TabItem';
-import S3Parameters from '../../node-running/how-tos/data-availability-committee/partials/parameters/_s3-parameters.mdx';
-import LocalFilesParameters from '../../node-running/how-tos/data-availability-committee/partials/parameters/_local-files-parameters.mdx';
-import GoogleCloudStorageParameters from '../../node-running/how-tos/data-availability-committee/partials/parameters/_gcs-parameters.mdx';
-import LocalBadgerDBParameters from '../../node-running/how-tos/data-availability-committee/partials/parameters/_local-badger-db-parameters.mdx';
+import S3Parameters from './/partials/parameters/_s3-parameters.mdx';
+import LocalFilesParameters from './/partials/parameters/_local-files-parameters.mdx';
+import GoogleCloudStorageParameters from './/partials/parameters/_gcs-parameters.mdx';
+import LocalBadgerDBParameters from './/partials/parameters/_local-badger-db-parameters.mdx';
 
 <div className="dynamic-content-tabs">
   <Tabs className="tabgroup" defaultValue={null}>
@@ -287,8 +287,8 @@ Once the DAS is deployed and tested, you'll have to communicate the following in
 
 - The https URL for the REST endpoint (e.g., `das.your-chain.io/rest`)
 
-import DASOptionalParameters from '../../node-running/how-tos/data-availability-committee/partials/_das-optional-parameters.mdx';
-import DASMetrics from '../../node-running/how-tos/data-availability-committee/partials/_das-metrics.mdx';
+import DASOptionalParameters from './/partials/_das-optional-parameters.mdx';
+import DASMetrics from './/partials/_das-metrics.mdx';
 
 ## Optional parameters
Original file line number	Diff line number	Diff line change
Expand Up		@@ -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 Arbitrum chain?

		You can learn how to set up your AEP fee router in the [implementation guide](/launch-arbitrum-chain/02-configure-your-chain/advanced-configurations/aep-fee-router/02-set-up-aep-fee-router.mdx).
		You can learn how to set up your AEP fee router in the [implementation guide](/launch-arbitrum-chain/02-configure-your-chain/common/aep-fees/02-set-up-aep-fee-router.mdx).