updating broken links, .DS_Store to .gitignore

.gitignore

@@ -2,3 +2,4 @@
 arbitrum-docs/sdk
 arbitrum-docs/stylus-by-example
 .vercel
+.DS_Store

arbitrum-docs/how-arbitrum-works/arbos/geth.mdx

@@ -21,7 +21,7 @@ Please note any links on this page may be referencing old releases of Nitro or o
 
 Arbitrum uses various hooks to modify Geth's behavior when processing transactions. Each provides an opportunity for ArbOS to update its state and make decisions about the transaction during its lifetime. Transactions are applied using Geth's [`ApplyTransaction`][applytransaction_link] function.
 
-Below is [`ApplyTransaction`][applytransaction_link]'s callgraph, with additional info on where the various Arbitrum-specific hooks are inserted. Click on any to go to their section. By default, these hooks do nothing so as to leave Geth's default behavior unchanged, but for chains configured with [`EnableArbOS`](#EnableArbOS) set to true, [`ReadyEVMForL2`](#ReadyEVMForL2) installs the alternative L2 hooks.
+Below is [`ApplyTransaction`][applytransaction_link]'s callgraph, with additional info on where the various Arbitrum-specific hooks are inserted. Click on any to go to their section. By default, these hooks do nothing so as to leave Geth's default behavior unchanged, but for chains configured with [`EnableArbOS`](/how-arbitrum-works/arbos/geth#EnableArbOS) set to true, [`ReadyEVMForL2`](#ReadyEVMForL2) installs the alternative L2 hooks.
 
 - `core.ApplyTransaction` ⮕ `core.applyTransaction` ⮕ `core.ApplyMessage`
   - `core.NewStateTransition`
@@ -34,7 +34,7 @@ Below is [`ApplyTransaction`][applytransaction_link]'s callgraph, with additiona
       - `evm.Call`
         - `core.vm.EVMInterpreter.Run`
           - [`PushCaller`](#PushCaller)
-          - [`PopCaller`](#PopCaller)
+          - [`PopCaller`](/how-arbitrum-works/arbos/geth#PopCaller)
       - `core.StateTransition.refundGas`
         - [`ForceRefundGas`](#ForceRefundGas)
         - [`NonrefundableGas`](#NonrefundableGas)
@@ -176,7 +176,7 @@ Represents a user deposit from L1 to L2. This increases the user's balance by th
 
 ### [`ArbitrumSubmitRetryableTx`][arbitrumsubmitretryabletx_link]{#ArbitrumSubmitRetryableTx}
 
-Represents a retryable submission and may schedule an [`ArbitrumRetryTx`](#ArbitrumRetryTx) if provided enough gas. Please see the [retryables documentation](/how-arbitrum-works/arbos/introduction.mdx#Retryables) for more info.
+Represents a retryable submission and may schedule an [`ArbitrumRetryTx`](#ArbitrumRetryTx) if provided enough gas. Please see the [retryables documentation](/how-arbitrum-works/arbos/introduction.mdx#retryables) for more info.
 
 ### [`ArbitrumRetryTx`][arbitrumretrytx_link]{#ArbitrumRetryTx}
 

arbitrum-docs/how-arbitrum-works/arbos/introduction.mdx

@@ -81,7 +81,7 @@ Based on this information, ArbOS maintains an L1 data fee, also tracked as part
 
 The L2 pricing state tracks L2 resource usage to determine a reasonable L2 gas price. This process considers a variety of factors, including user demand, the state of Geth, and the computational speed limit. The primary mechanism for doing so consists of a pair of pools, one larger than the other, that drain as L2-specific resources are consumed and filled as time passes. L1-specific resources like L1 `calldata` are not tracked by the pools, as they have little bearing on the actual work done by the network actors that the speed limit is meant to keep stable and synced.
 
-While much of this state is accessible through the [`ArbGasInfo`](/build-decentralized-apps/precompiles/02-reference.mdx#arbgasinfo) and [`ArbOwner`](/build-decentralized-apps/precompiles/02-reference.mdx#arbowner) precompiles, most changes are automatic and happen during [block production][block_production_link] and [the transaction hooks](geth#Hooks). Each of an incoming message's transactions removes from the pool the L2 component of the gas it uses, and afterward the message's timestamp [informs the pricing mechanism][notify_pricer_link] of the time that's passed as ArbOS [finalizes the block][finalizeblock_link].
+While much of this state is accessible through the [`ArbGasInfo`](/build-decentralized-apps/precompiles/02-reference.mdx#arbgasinfo) and [`ArbOwner`](/build-decentralized-apps/precompiles/02-reference.mdx#arbowner) precompiles, most changes are automatic and happen during [block production][block_production_link] and [the transaction hooks](/how-arbitrum-works/arbos/geth#Hooks). Each of an incoming message's transactions removes from the pool the L2 component of the gas it uses, and afterward the message's timestamp [informs the pricing mechanism][notify_pricer_link] of the time that's passed as ArbOS [finalizes the block][finalizeblock_link].
 
 ArbOS's larger gas pool [determines][maintain_limit_link] the per-block gas limit, setting a dynamic [upper limit][per_block_limit_link] on the amount of compute gas an L2 block may have. This limit is always enforced, though for the [first transaction][first_transaction_link] it's done in the [GasChargingHook](geth#GasChargingHook) to avoid sharp decreases in the L1 gas price from over-inflating the compute component purchased to above the gas limit. This improves UX by allowing the first transaction to succeed rather than requiring a resubmission. Because the first transaction lowers the amount of space left in the block, subsequent transactions do not employ this strategy and may fail from such compute-component inflation. This is acceptable because such transactions are only present in cases where the system is under heavy load and the result is that the user's transaction is dropped without charges since the state transition fails early. Those trusting the sequencer can rely on the transaction being automatically resubmitted in such a scenario.
 

arbitrum-docs/how-arbitrum-works/assertion-tree.mdx

@@ -30,4 +30,4 @@ The only delay that users experience during a dispute is of their [L2 to L1 mess
 
 ### Detailed Spec
 
-For a more detailed breakdown / specification of the assertion tree protocol, see [Inside Arbitrum](/how-arbitrum-works/inside-arbitrum-nitro.mdx#arbitrum#rollup#protocol).
+For a more detailed breakdown / specification of the assertion tree protocol, see [Inside Arbitrum](/how-arbitrum-works/inside-arbitrum-nitro.mdx#arbitrum-rollup-protocol).

arbitrum-docs/launch-orbit-chain/how-tos/orbit-sdk-deploying-rollup-chain.md

@@ -194,7 +194,7 @@ The Orbit SDK provides two APIs, `createRollupPrepareDeploymentParamsConfig` and
 
 This API is designed to take parameters defined in the Config struct and fill in the rest with default values. It outputs a complete Config struct that is ready for use.
 
-For example, to create a Config struct with a specific chain ID (`chainId`), an owner address (`deployer_address`), and a `chainConfig` as described in the [previous section](#chain-config-parameter), you would use the Orbit SDK as follows:
+For example, to create a Config struct with a specific chain ID (`chainId`), an owner address (`deployer_address`), and a `chainConfig` as described in the [previous section](/launch-orbit-chain/how-tos/orbit-sdk-deploying-rollup-chain#chain-config-parameter), you would use the Orbit SDK as follows:
 
 ```js
 import { createPublicClient, http } from 'viem';

arbitrum-docs/launch-orbit-chain/how-tos/orbit-sdk-deploying-token-bridge.md

@@ -44,8 +44,8 @@ Once an Orbit chain has been deployed and initialized, the bridge contracts need
 
 The token bridge deployment process is the same for all Orbit chains types except for the following:
 
-- **Custom fee token Orbit chains** which require [token approval](#step-1).
-- **`ETH`-based Orbit chains**, for which you need to [set up a WETH gateway](#step-5).
+- **Custom fee token Orbit chains** which require [token approval](/launch-orbit-chain/how-tos/orbit-sdk-deploying-token-bridge#step-1).
+- **`ETH`-based Orbit chains**, for which you need to [set up a WETH gateway](/launch-orbit-chain/how-tos/orbit-sdk-deploying-token-bridge#step-5).
 
 :::
 

arbitrum-docs/run-arbitrum-node/03-run-full-node.mdx

@@ -61,7 +61,7 @@ Even though there are alpha and beta versions of the <a data-quicklook-from='arb
   - Note: this parameter was called `--l1.url` in versions prior to `v2.1.0`
   - Note: 8545 is usually the default port for the execution layer. For the Beacon endpoint port, you should connect to the correct port set on your parent chain's consensus client.
 - L2 chain ID or name
-  - Use the parameter `--chain.id=<L2 chain ID>` to set the L2 chain from its chain id. See [RPC endpoints and providers](/build-decentralized-apps/reference/01-node-providers.mdx#rpc-endpoints) for a list of Arbitrum chains and their respective L2 chain IDs.
+  - Use the parameter `--chain.id=<L2 chain ID>` to set the L2 chain from its chain id. See [RPC endpoints and providers](/build-decentralized-apps/reference/01-node-providers.mdx) for a list of Arbitrum chains and their respective L2 chain IDs.
   - Alternatively, you can use the parameter `--chain.name=<L2 chain name>` to set the L2 chain from its name (options are: `arb1`, `nova` and `sepolia-rollup`)
   - Note: this parameter was called --l2.chain-id and only accepted chain IDs in versions before `v2.1.0`
 

arbitrum-docs/stylus/stylus-quickstart.mdx

@@ -14,7 +14,7 @@ This guide will get you started with <a data-quicklook-from="stylus">Stylus</a>'
 2. [Creating a Stylus project with cargo stylus](./stylus-quickstart#creating-a-stylus-project-with-cargo-stylus)
 3. [Checking the validity of your contract](./stylus-quickstart#checking-if-your-stylus-project-is-valid)
 4. [Deploying your contract](./stylus-quickstart#deploying-your-contract)
-5. [Exporting your contract's ABIs](./stylus-quickstart#exporting-solidity-abis)
+5. [Exporting your contract's ABIs](/stylus/stylus-quickstart#exporting-solidity-abis)
 6. [Calling your contract](./stylus-quickstart#calling-your-contract)
 7. [Sending a transaction to your contract](./stylus-quickstart#sending-a-transaction-to-your-contract)