pete-vielhaber · Sep 8, 2026 · Sep 8, 2026 · Sep 8, 2026 · Sep 8, 2026 · Sep 8, 2026
diff --git a/docs/arbitrum-bridge/06-withdrawal-monitoring.mdx b/docs/arbitrum-bridge/06-withdrawal-monitoring.mdx
@@ -298,7 +298,7 @@ Work through the stages in order—each row's check assumes the previous rows pa
 
 <VanillaAdmonition type="caution" title="Historical data availability">
 
-Ethereum consensus nodes are required to serve blob data for only 4,096 epochs (≈18 days). Monitors that reconstruct old withdrawal history need archive access: an [archive beacon endpoint for historical blobs](/run-arbitrum-node/beacon-nodes-historical-blobs.mdx) to re-derive the chain from batch data, and an archive child chain node for the event logs that `constructOutboxProof` reads. On AnyTrust chains, the equivalent concern is the <a data-quicklook-from="data-availability-committee-dac">Data Availability Committee</a>'s retention window. Claiming a confirmed withdrawal itself is unaffected—proofs are built from child chain logs, not blobs.
+Ethereum consensus nodes are required to serve blob data for only 4,096 epochs (≈18 days). Monitors that reconstruct old withdrawal history need archive access: an [archive beacon endpoint for historical blobs](/run-arbitrum-node/data-availability/beacon-nodes-historical-blobs.mdx) to re-derive the chain from batch data, and an archive child chain node for the event logs that `constructOutboxProof` reads. On AnyTrust chains, the equivalent concern is the <a data-quicklook-from="data-availability-committee-dac">Data Availability Committee</a>'s retention window. Claiming a confirmed withdrawal itself is unaffected—proofs are built from child chain logs, not blobs.
 
 </VanillaAdmonition>
 

diff --git a/docs/get-started/overview.mdx b/docs/get-started/overview.mdx
@@ -79,7 +79,7 @@ Run the machines that power the Arbitrum ecosystem.
 >
   <Card title="Run a full node" description="Access Arbitrum chains without connecting to a third-party node." href="/run-arbitrum-node/run-full-node" />
   <Card title="Run an archive node" description="Access extensive historical data for advanced analytical purposes." href="/run-arbitrum-node/more-types/run-archive-node" />
-  <Card title="Run a feed relay" description="Distribute the sequencer feed across multiple nodes." href="/run-arbitrum-node/run-feed-relay" />
+  <Card title="Run a feed relay" description="Distribute the sequencer feed across multiple nodes." href="/run-arbitrum-node/data-availability/run-feed-relay" />
   <Card title="Configure a DAC" description="Run a Data Availability Server for AnyTrust chains." href="/launch-arbitrum-chain/chain-config/data-availability/dac-get-started" />
 </div>
 

diff --git a/docs/how-arbitrum-works/01-inside-arbitrum-nitro.mdx b/docs/how-arbitrum-works/01-inside-arbitrum-nitro.mdx
@@ -163,7 +163,7 @@ AnyTrust enables cost-optimized data availability with a mild trust model that r
 
 Keysets define member keys and thresholds; DACerts include hashes, expirations, and signatures; and servers support various storage, such as local files or Amazon S3. The Sequencer sends batches to the committee, gathers signatures for DACerts, and posts them to Layer 1, defaulting to full data if the required signatures are not present. Ideal for low-cost apps like gaming.
 
-For a more complete understanding of AnyTrust, refer to the [AnyTrust protocol documentation](/how-arbitrum-works/deep-dives/anytrust-protocol.mdx). For the operator-side view of running a DAS, see the [data availability node guide](/run-arbitrum-node/data-availability.mdx).
+For a more complete understanding of AnyTrust, refer to the [AnyTrust protocol documentation](/how-arbitrum-works/deep-dives/anytrust-protocol.mdx). For the operator-side view of running a DAS, see the [data availability node guide](/how-arbitrum-works/deep-dives/data-availability.mdx).
 
 ## Related topics
 

diff --git a/docs/run-arbitrum-node/data-availability.mdx → ...um-works/deep-dives/data-availability.mdx b/docs/run-arbitrum-node/data-availability.mdx → ...um-works/deep-dives/data-availability.mdx
@@ -97,7 +97,7 @@ Arbitrum full nodes decode data received from the parent chain (and, in the case
 Once Arbitrum full nodes have caught up with the chain, they switch from initial synchronization to a real-time update mode. This switch involves receiving data from the sequencer feed, which continuously broadcasts updates about newly queued transactions.
 
 1. Data acquisition:
-   1. Full nodes maintain a connection to the sequencer feed or your private feed. For how to run a private feed, please refer to [**How to run a feed relay**](/run-arbitrum-node/run-feed-relay.mdx)
+   1. Full nodes maintain a connection to the sequencer feed or your private feed. For how to run a private feed, please refer to [**How to run a feed relay**](/run-arbitrum-node/data-availability/run-feed-relay.mdx)
    2. The sequencer feed transmits data packets containing information about the latest queued transactions.
 2. Data decoding:
    1. Full nodes decode the received data packets using the methods described in [How to read the sequencer feed](/run-arbitrum-node/sequencer/02-read-sequencer-feed.mdx).

diff --git a/docs/how-arbitrum-works/deep-dives/finality.mdx b/docs/how-arbitrum-works/deep-dives/finality.mdx
@@ -66,7 +66,7 @@ Hard finality occurs when batched transactions are posted to the parent chain an
 
 - **Strong security guarantees**: When included in blocks on the parent chain, transactions inherit the parent chain’s security assurances.
 - **Irreversibility**: Once finalized, transactions are immutable and cannot be altered or reversed.
-- **Data availability**: In the default [Rollup mode](/run-arbitrum-node/data-availability.mdx#rollup-mode), all transaction data is recorded onchain (via calldata or <a data-quicklook-from="blob">blobs</a>), ensuring transparency and verifiability. On <a data-quicklook-from="arbitrum-anytrust-chain">AnyTrust chains</a>, batch data is instead kept offchain by a <a data-quicklook-from="data-availability-committee-dac">Data Availability Committee (DAC)</a>, and only a <a data-quicklook-from="data-availability-certificate">data availability certificate</a> is posted onchain — trading full onchain data availability for lower cost.
+- **Data availability**: In the default [Rollup mode](/how-arbitrum-works/deep-dives/data-availability.mdx#rollup-mode), all transaction data is recorded onchain (via calldata or <a data-quicklook-from="blob">blobs</a>), ensuring transparency and verifiability. On <a data-quicklook-from="arbitrum-anytrust-chain">AnyTrust chains</a>, batch data is instead kept offchain by a <a data-quicklook-from="data-availability-committee-dac">Data Availability Committee (DAC)</a>, and only a <a data-quicklook-from="data-availability-certificate">data availability certificate</a> is posted onchain — trading full onchain data availability for lower cost.
 
 ### Advantages of hard finality
 

diff --git a/docs/how-arbitrum-works/deep-dives/sequencer-transaction-flow.mdx b/docs/how-arbitrum-works/deep-dives/sequencer-transaction-flow.mdx
@@ -97,7 +97,7 @@ The queue is deliberately a short buffer, not a mempool: with default settings i
 
 ## From block to the rest of the network
 
-As soon as a block is created, the transaction streamer hands the new message to the broadcaster, which publishes it over WebSocket on the <a data-quicklook-from="sequencer-feed">sequencer feed</a> ([`transaction_streamer.go#L1307`](https://github.com/OffchainLabs/nitro/blob/a618155919315241665356fe60f3cd00d66d5e46/arbnode/transaction_streamer.go#L1307)). Full nodes and [feed relays](/run-arbitrum-node/run-feed-relay.mdx) consume the feed to give sub-second <a data-quicklook-from="soft-confirmation">soft confirmations</a>; see [How to read the sequencer feed](/run-arbitrum-node/sequencer/02-read-sequencer-feed.mdx).
+As soon as a block is created, the transaction streamer hands the new message to the broadcaster, which publishes it over WebSocket on the <a data-quicklook-from="sequencer-feed">sequencer feed</a> ([`transaction_streamer.go#L1307`](https://github.com/OffchainLabs/nitro/blob/a618155919315241665356fe60f3cd00d66d5e46/arbnode/transaction_streamer.go#L1307)). Full nodes and [feed relays](/run-arbitrum-node/data-availability/run-feed-relay.mdx) consume the feed to give sub-second <a data-quicklook-from="soft-confirmation">soft confirmations</a>; see [How to read the sequencer feed](/run-arbitrum-node/sequencer/02-read-sequencer-feed.mdx).
 
 Independently, the [batch poster](/how-arbitrum-works/deep-dives/batchposter.mdx) compresses the sequenced transactions and posts them to the <a data-quicklook-from="sequencer-inbox">sequencer inbox</a> on the parent chain, at which point they inherit the parent chain's finality. Validators then re-execute the posted sequence and assert the resulting state. [The Sequencer and censorship resistance](/how-arbitrum-works/deep-dives/sequencer.mdx#sequencing-and-broadcasting) covers the feed, batch posting, and the finality trade-offs in detail, and [Assertions](/how-arbitrum-works/deep-dives/assertions.mdx) covers validation.
 
@@ -124,4 +124,4 @@ This pattern complements rather than replaces queue tuning: `queue-size` and `qu
 - [RPC endpoints and providers](/arbitrum-essentials/reference/node-providers.mdx): public endpoint behavior, retries, and fallback patterns
 - [How to set up a high-availability sequencer](/launch-arbitrum-chain/run-a-node/high-availability-sequencer.mdx): redundant Sequencers with Redis-based coordination
 - [How to run a Sequencer Coordinator Manager](/run-arbitrum-node/sequencer/03-run-sequencer-coordination-manager.mdx): managing the sequencer priority list
-- [How to read the sequencer feed](/run-arbitrum-node/sequencer/02-read-sequencer-feed.mdx) and [How to run a feed relay](/run-arbitrum-node/run-feed-relay.mdx)
+- [How to read the sequencer feed](/run-arbitrum-node/sequencer/02-read-sequencer-feed.mdx) and [How to run a feed relay](/run-arbitrum-node/data-availability/run-feed-relay.mdx)
diff --git a/docs/launch-arbitrum-chain/chain-config/costs/custom-gas-token-rollup.mdx b/docs/launch-arbitrum-chain/chain-config/costs/custom-gas-token-rollup.mdx
@@ -8,7 +8,7 @@ content_type: how-to
 
 import CustomGasTokenNote from '../../partials/_custom-gas-token-note.mdx';
 
-When deploying an <a data-quicklook-from="arbitrum-chain">Arbitrum chain</a> in [Rollup mode](/run-arbitrum-node/data-availability.mdx#rollup-mode), you can use a custom **ERC-20** token as the native gas token. This token is usable for <a data-quicklook-from="transaction">Transaction</a> fees on that specific Arbitrum chain and reimbursing the [Batch Poster](/how-arbitrum-works/deep-dives/assertions.mdx) for data posted to Ethereum. An example would be an <a data-quicklook-from="L2">L2</a> Rollup that uses **USDC** as its custom gas token but pays **ETH** to post data to <a data-quicklook-from="L1">L1</a> Ethereum.
+When deploying an <a data-quicklook-from="arbitrum-chain">Arbitrum chain</a> in [Rollup mode](/how-arbitrum-works/deep-dives/data-availability.mdx#rollup-mode), you can use a custom **ERC-20** token as the native gas token. This token is usable for <a data-quicklook-from="transaction">Transaction</a> fees on that specific Arbitrum chain and reimbursing the [Batch Poster](/how-arbitrum-works/deep-dives/assertions.mdx) for data posted to Ethereum. An example would be an <a data-quicklook-from="L2">L2</a> Rollup that uses **USDC** as its custom gas token but pays **ETH** to post data to <a data-quicklook-from="L1">L1</a> Ethereum.
 
 Enabling a custom fee token for a Rollup chain requires additional configuration compared to an [AnyTrust chain](/launch-arbitrum-chain/chain-config/costs/custom-gas-token-anytrust.mdx); it also introduces important exchange-rate considerations. This guide outlines specific implementation steps and operational considerations for chain owners or operators to consider when enabling a custom fee token for Rollups.
 

diff --git a/docs/launch-arbitrum-chain/chain-config/sequencer/sequencer-config-reference.mdx b/docs/launch-arbitrum-chain/chain-config/sequencer/sequencer-config-reference.mdx
@@ -8,7 +8,7 @@ user_story: As an Arbitrum chain operator, I need to understand what each sequen
 content_type: reference
 ---
 
-This page explains what the operational <a data-quicklook-from="sequencer">sequencer</a> flags do and what changes when you set them. For the complete list of every Nitro flag, see the [CLI flags reference](/run-arbitrum-node/nitro/cli-flags-reference.mdx). For failure diagnosis, see [Sequencer troubleshooting](/launch-arbitrum-chain/operate/sequencer-troubleshooting.mdx).
+This page explains what the operational <a data-quicklook-from="sequencer">sequencer</a> flags do and what changes when you set them. For the complete list of every Nitro flag, see the [CLI flags reference](/run-arbitrum-node/reference/cli-flags-reference.mdx). For failure diagnosis, see [Sequencer troubleshooting](/launch-arbitrum-chain/operate/sequencer-troubleshooting.mdx).
 
 All flags take the prefix `--execution.sequencer.` or `--node.seq-coordinator.` as shown.
 

diff --git a/docs/launch-arbitrum-chain/chain-config/sequencer/sequencer-timing-adjustments.mdx b/docs/launch-arbitrum-chain/chain-config/sequencer/sequencer-timing-adjustments.mdx
@@ -163,7 +163,7 @@ With `reorg-resistance-margin=0`, a parent-chain reorg — or simply a batch lan
 
 </VanillaAdmonition>
 
-Note the interaction with `maxTimeVariation`: a wider past window (`delayBlocks` and `delaySeconds`) gives the batch poster more room before the margin is threatened, while a narrower window makes the margin bite sooner. See the [CLI flags reference](/run-arbitrum-node/nitro/cli-flags-reference.mdx) for the full batch-poster flag set.
+Note the interaction with `maxTimeVariation`: a wider past window (`delayBlocks` and `delaySeconds`) gives the batch poster more room before the margin is threatened, while a narrower window makes the margin bite sooner. See the [CLI flags reference](/run-arbitrum-node/reference/cli-flags-reference.mdx) for the full batch-poster flag set.
 
 ## Changing `maxTimeVariation`
 

diff --git a/docs/launch-arbitrum-chain/extend-the-protocol/precompiles.mdx b/docs/launch-arbitrum-chain/extend-the-protocol/precompiles.mdx
@@ -232,7 +232,7 @@ Our function now emits an event, which means that when calling it, the state wil
 function sayHi() external returns(string memory);
 ```
 
-Next, build Nitro by following the instructions in [How to build Nitro locally](/run-arbitrum-node/nitro/01-build-nitro-locally.mdx). Note that if you've already built the Docker image, you still need run the last step to rebuild.
+Next, build Nitro by following the instructions in [How to build Nitro locally](/run-arbitrum-node/build-nitro-locally.mdx). Note that if you've already built the Docker image, you still need run the last step to rebuild.
 
 Run Nitro with the following command:
 
@@ -310,7 +310,7 @@ func (con ArbInfo) GetBalanceCustom(c ctx, evm mech, account addr) (huge, error)
 
 To register this new precompile method, refer to Option 1 above.
 
-Next, build Nitro by following the instructions in [How to build Nitro locally](/run-arbitrum-node/nitro/01-build-nitro-locally.mdx). Note that if you've already built the Docker image, you still need run the last step to rebuild.
+Next, build Nitro by following the instructions in [How to build Nitro locally](/run-arbitrum-node/build-nitro-locally.mdx). Note that if you've already built the Docker image, you still need run the last step to rebuild.
 
 Run Nitro with the following command:
 

diff --git a/docs/launch-arbitrum-chain/extend-the-protocol/stf.mdx b/docs/launch-arbitrum-chain/extend-the-protocol/stf.mdx
@@ -18,7 +18,7 @@ Before customizing your Arbitrum chain, it's important to understand what the St
 This guide is only necessary for changes that modify the STF.
 
 To customize other node behavior, such as RPC behavior or the sequencer's ordering policy, you can simply
-[build your own node](/run-arbitrum-node/nitro/01-build-nitro-locally.mdx) without worrying about the rest of this guide. However, changes that modify the STF require updating the fraud proving system to recognize the new behavior as correct. Otherwise, the fraud prover would side with unmodified nodes, which would win fraud proofs against your modified node.
+[build your own node](/run-arbitrum-node/build-nitro-locally.mdx) without worrying about the rest of this guide. However, changes that modify the STF require updating the fraud proving system to recognize the new behavior as correct. Otherwise, the fraud prover would side with unmodified nodes, which would win fraud proofs against your modified node.
 
 Here's some examples of modifications that affect the STF:
 

diff --git a/docs/launch-arbitrum-chain/operate/monitoring.mdx b/docs/launch-arbitrum-chain/operate/monitoring.mdx
@@ -65,7 +65,7 @@ nitro --metrics \
   --metrics-server.port 6070
 ```
 
-For metrics-server flags, memory-related metrics, health-check patterns, and Kubernetes `ServiceMonitor` examples, see [Node tuning and monitoring](/run-arbitrum-node/nitro/node-tuning-and-monitoring.mdx).
+For metrics-server flags, memory-related metrics, health-check patterns, and Kubernetes `ServiceMonitor` examples, see [Node tuning and monitoring](/run-arbitrum-node/operation/node-tuning-and-monitoring.mdx).
 
 The signals that are not Nitro metrics — onchain events and account balances on the parent chain — are called out explicitly in each table below.
 

diff --git a/docs/launch-arbitrum-chain/operate/sequencer-troubleshooting.mdx b/docs/launch-arbitrum-chain/operate/sequencer-troubleshooting.mdx
@@ -47,7 +47,7 @@ sequencers  →  sequencer relays  →  external relays  →  public subscribers
 
 Sequencer relays subscribe to _every_ sequencer replica, not just the active one. Non-chosen sequencers still broadcast, so aggregating all of them means no messages are lost when the chosen sequencer changes. This is why the Helm setup needs per-replica headless services—a single load-balanced address would connect to only one replica. See [How to set up a high-availability sequencer](/launch-arbitrum-chain/run-a-node/high-availability-sequencer.mdx#2-relays-setup).
 
-For installation steps, see [How to run a feed relay](/run-arbitrum-node/run-feed-relay.mdx). For the message format, see [How to read the sequencer feed](/run-arbitrum-node/sequencer/02-read-sequencer-feed.mdx).
+For installation steps, see [How to run a feed relay](/run-arbitrum-node/data-availability/run-feed-relay.mdx). For the message format, see [How to read the sequencer feed](/run-arbitrum-node/sequencer/02-read-sequencer-feed.mdx).
 
 ### Timeouts that govern a feed connection
 
@@ -127,7 +127,7 @@ The feed carries no _heartbeat_ at the application level, so silence is ambiguou
 
 <VanillaAdmonition type="caution" title="Redundant feed connections">
 
-You can point a relay at the same endpoint twice to survive a reset without waiting for a reconnect. This doubles bandwidth and risks rate limiting. Configure it at the relay, never at individual nodes, and never use more than one redundant connection. See [How to run a feed relay](/run-arbitrum-node/run-feed-relay.mdx).
+You can point a relay at the same endpoint twice to survive a reset without waiting for a reconnect. This doubles bandwidth and risks rate limiting. Configure it at the relay, never at individual nodes, and never use more than one redundant connection. See [How to run a feed relay](/run-arbitrum-node/data-availability/run-feed-relay.mdx).
 
 </VanillaAdmonition>
 

diff --git a/docs/launch-arbitrum-chain/operate/upgrade-runbook.mdx b/docs/launch-arbitrum-chain/operate/upgrade-runbook.mdx
@@ -323,4 +323,4 @@ Rolling `nitro-contracts` back is only remotely viable if no assertions have bee
 - [Monitoring tools and considerations](/launch-arbitrum-chain/operate/monitoring.mdx)—what to watch during and after an upgrade
 - [Batch poster troubleshooting](/launch-arbitrum-chain/operate/batch-poster-troubleshooting.mdx)—diagnosing batch poster errors
 - [Customize your chain's behavior](/launch-arbitrum-chain/extend-the-protocol/stf.mdx)—building a custom STF and its replay binary
-- [Nitro CLI flags reference](/run-arbitrum-node/nitro/cli-flags-reference.mdx)—reference for the Nitro configuration flags named here (`dangerous` flags are not listed)
+- [Nitro CLI flags reference](/run-arbitrum-node/reference/cli-flags-reference.mdx)—reference for the Nitro configuration flags named here (`dangerous` flags are not listed)
diff --git a/docs/launch-arbitrum-chain/operate/validator-troubleshooting.mdx b/docs/launch-arbitrum-chain/operate/validator-troubleshooting.mdx
@@ -52,7 +52,7 @@ Two rules to check when tuning these:
 - **The posting interval must exceed the Rollup contract's `minimumAssertionPeriod`.** That is an onchain constraint measured in <a data-quicklook-from="parent-chain">parent-chain</a> blocks (`block.number` units — on an Arbitrum parent these track the underlying L1 block number, not the Arbitrum block height). The validator checks it before posting and waits until enough blocks have passed, so a shorter posting interval silently caps you at the onchain floor rather than causing reverted transactions. Read `minimumAssertionPeriod` from your Rollup contract rather than assuming the default.
 - **Do not tune the confirming interval to make confirmations happen sooner.** Confirmation timing is governed onchain by `confirmPeriodBlocks` and, where a challenge occurred, `challengeGracePeriodBlocks`. Lowering `--node.bold.assertion-confirming-interval` only increases how often the validator checks, which adds parent-chain RPC load without advancing anything.
 
-For the full flag list, see the [Nitro CLI flags reference](/run-arbitrum-node/nitro/cli-flags-reference.mdx). For the onchain parameters, see the parameter table in [BoLD for Arbitrum chains](/launch-arbitrum-chain/chain-config/validation/bold.mdx#table-of-arbitrum-bold-parameters).
+For the full flag list, see the [Nitro CLI flags reference](/run-arbitrum-node/reference/cli-flags-reference.mdx). For the onchain parameters, see the parameter table in [BoLD for Arbitrum chains](/launch-arbitrum-chain/chain-config/validation/bold.mdx#table-of-arbitrum-bold-parameters).
 
 ## Parent-chain read consistency