Merge branch 'master' into fix-fast-withdrawal-frequency

Author: anegg0

README.md

@@ -15,7 +15,7 @@ This repository is organized as follows:
   - `for-users/` - User-focused documentation
   - `how-arbitrum-works/` - Technical explanations of Arbitrum
   - `intro/` - Introduction and glossary
-  - `launch-arbitrum-chain/` - Arbitrum Orbit chain deployment guides
+  - `launch-arbitrum-chain/` - Arbitrum chain deployment guides
   - `learn-more/` - Additional learning resources
   - `node-running/` - Node operation guides
   - `partials/` - Reusable content components and troubleshooting guides

docs/arbitrum-bridge/04-embedded-bridge-widget.mdx

@@ -61,7 +61,7 @@ You can adopt the bridge functionality permissionlessly if your chain is already
 
 If you are interested in on-ramp support, please contact [[email protected]](mailto:[email protected]).
 
-#### 2. If I'm an Orbit chain and I want support, how do I adopt?
+#### 2. If I'm an Arbitrum chain and I want support, how do I adopt?
 
 You'll need an integration with Li.fi and a minimum number of bridges to enable a good experience. Contact [[email protected]](mailto:[email protected]) to discuss adding support for your chain.
 

docs/audit-reports.mdx

@@ -2,6 +2,8 @@
 
 | Auditor                 | Audit date (MM/DD/YYY) | Audited code                                                                              | View report                                                                                                                              |
 | ----------------------- | ---------------------- | ----------------------------------------------------------------------------------------- | ---------------------------------------------------------------------------------------------------------------------------------------- |
+| **Trail of Bits**       | 12/08/2025             | Delegated Voting Power (DVP) Quorum                                                       | [view](hosted-pdfs/audit-reports/2025-12-offchain-arbitrum-quorum-changes-securityreview.pdf)                                            |
+| **Trail of Bits**       | 12/01/2025             | ArbOS 50 & 51 Security Review                                                             | [view](hosted-pdfs/audit-reports//2025-12-offchain-arbos50-and-51-securityreview.pdf)                                                    |
 | **Trail of Bits**       | 07/30/2025             | Upgrade Executor                                                                          | [view](hosted-pdfs/audit-reports//2025-07-offchainlabs-upgrade-executor-report.pdf)                                                      |
 | **Trail of Bits**       | 06/02/2025             | Block Hash Pusher                                                                         | [view](hosted-pdfs/audit-reports/2025-06-offchain-arbitrum-block-hash-pusher-securityreview.pdf)                                         |
 | **Trail of Bits**       | 06/02/2025             | Mint/Burn Precompile                                                                      | [view](hosted-pdfs/audit-reports//2025-06-offchain-arbitrum-mint-burn-precompile-securityreview.pdf)                                     |

docs/build-decentralized-apps/02-how-to-estimate-gas.mdx

@@ -22,7 +22,7 @@ Multiplying the value obtained from `eth_estimateGas` by the child chain gas pri
 
 Alternatively, to obtain the gas limit for your transaction, you can call `NodeInterface.gasEstimateComponents()` and then use the first result, which is `gasEstimate`. Next, to find the total cost, you need to multiply this amount by the child chain gas price, which is available in the third result, `baseFee`.
 
-Note that when working with parent to child chain messages (also known as [retryable tickets](/how-arbitrum-works/deep-dives/l1-to-l2-messaging.mdx)), you can use the function [`L1ToL2MessageGasEstimator.estimateAll()`](https://github.com/OffchainLabs/arbitrum-sdk/blob/main/src/lib/message/L1ToL2MessageGasEstimator.ts#L215) of the Arbitrum SDK or [`NodeInterface.estimateRetryableTicket()`](https://github.com/OffchainLabs/@@nitroRepositorySlug=nitro@@/blob/@@nitroVersionTag=v3.8.0@@/nodeInterface/NodeInterface.go#L120) to get all the gas information needed to send a successful transaction.
+Note that when working with parent to child chain messages (also known as [retryable tickets](/how-arbitrum-works/deep-dives/l1-to-l2-messaging.mdx)), you can use the function [`L1ToL2MessageGasEstimator.estimateAll()`](https://github.com/OffchainLabs/arbitrum-sdk/blob/main/src/lib/message/L1ToL2MessageGasEstimator.ts#L215) of the Arbitrum SDK or [`NodeInterface.estimateRetryableTicket()`](https://github.com/OffchainLabs/@@nitroRepositorySlug=nitro@@/blob/@@nitroVersionTag=v3.9.3@@/nodeInterface/NodeInterface.go#L120) to get all the gas information needed to send a successful transaction.
 
 ## Breaking down the formula
 

docs/build-decentralized-apps/arbitrum-vs-ethereum/02-block-numbers-and-time.mdx

@@ -9,6 +9,8 @@ content_type: concept
 displayed_sidebar: buildAppsSidebar
 ---
 
+import { VanillaAdmonition } from '@site/src/components/VanillaAdmonition/';
+
 :::info block number vs `block.number`
 
 Throughout this and other pages, we note that the block number of a chain does not match the value obtained from `block.number`. When using `block.number` in a smart contract, the value obtained will be the block of the first non-Arbitrum ancestor chain. That is:
@@ -22,7 +24,7 @@ As with Ethereum, Arbitrum clients submit transactions, and the system executes
 
 Once in the chain's core inbox contract, transaction processing occurs in order. Generally, some time will elapse between when a message is put into the inbox (and timestamped) and when the contract processes the message and carries out the transaction requested by the message.
 
-Additionally, since the calldata of Arbitrum transactions (or the DAC certificate on <a data-quicklook-from= "arbitrum-anytrust-chain">AnyTrust</a>chains) is posted to Ethereum, the gas paid when executing them includes a component for the parent chain to cover the costs of the batch poster.
+Additionally, since the calldata/blobs of Arbitrum transactions (or the DAC certificate on <a data-quicklook-from= "arbitrum-anytrust-chain">AnyTrust</a>chains) is posted to Ethereum, the gas paid when executing them includes a component for the parent chain to cover the costs of the batch poster.
 
 This page explains the implications of this mechanism for the block gas limit, block numbers, and the time assumptions associated with transactions submitted to Arbitrum.
 
@@ -42,7 +44,7 @@ A single Ethereum block can include multiple Arbitrum blocks; however, an Arbitr
 
 ### Ethereum (or parent chain) block numbers within Arbitrum
 
-Accessing block numbers within an Arbitrum smart contract (i.e., `block.number` in Solidity) will return a value _close to_ (but not necessarily exactly) the block number of the first non-Arbitrum ancestor chain at which the sequencer received the transaction.
+Accessing block numbers within an Arbitrum smart contract (i.e., `block.number` in Solidity) will return a value _close to_ (but not necessarily exactly) the block number of the first non-Arbitrum ancestor chain where the sequencer received the transaction.
 
 The "first non-Arbitrum ancestor chain" is:
 
@@ -73,15 +75,14 @@ A client that queries an Arbitrum node's RPC interface (e.g., transaction receip
 ```typescript
 const txnReceipt = await arbitrumProvider.getTransactionReceipt('0x...');
 /** 
-    txnReceipt.blockNumber => Arbitrum block number
     txnReceipt.l1BlockNumber => Approximate block number of the first non-Arbitrum ancestor chain
 */
 ```
 
 The Arbitrum block number can also be retrieved within an Arbitrum contract via [ArbSys](/build-decentralized-apps/precompiles/02-reference.mdx#arbsys) precompile:
 
 ```solidity
- ArbSys(100).arbBlockNumber() // returns Arbitrum block number
+ArbSys(100).arbBlockNumber() // returns Arbitrum block number
 ```
 
 ### Example
@@ -94,7 +95,13 @@ The following example illustrates timings on a chain that settles to Ethereum (s
 | Chain's `block.number` \*             | 1000     | 1000        | 1000        | 1000        | 1004     | 1004        |
 | Chain's block number (from RPCs) \*\* | 370000   | 370005      | 370006      | 370008      | 370012   | 370015      |
 
-_\* **The chain's `block.number`:** updated to sync with Ethereum's `block.number` approximately every minute. Thus, over time, it will, like Ethereum's `block.number`, average to ~12 seconds per block._
+<VanillaAdmonition type="info">
+
+    txnReceipt.blockNumber => Arbitrum block number
+
+\_\* **The chain's `block.number`:** updated to sync with Ethereum's `block.number` every 13 to 15 seconds (occasionally longer).
+
+</VanillaAdmonition>
 
 _\*\* **Chain's block number from RPCs:** note that this can be updated multiple times per Ethereum block (this lets the sequencer give sub-Ethereum-block-time transaction receipts.)_
 

docs/build-decentralized-apps/nodeinterface/01-overview.mdx

@@ -8,6 +8,6 @@ displayed_sidebar: buildAppsSidebar
 
 <!-- todo: remove this doc, redirect to existing ref doc -->
 
-The Arbitrum Nitro software includes a special `NodeInterface` contract available at address `0xc8` that is only accessible via RPCs (it's not actually deployed onchain and thus can't be called by smart contracts). The way it works is that the node uses Geth's [`InterceptRPCMessage`](https://github.com/OffchainLabs/go-ethereum/blob/@@goEthereumCommit=e845151eb649647a8d2d2b5c874377ffe5d2a8c9@@/internal/ethapi/api.go#L1034) hook to detect messages sent to the address `0xc8`, and swaps out the message it's handling before deriving a transaction from it.
+The Arbitrum Nitro software includes a special `NodeInterface` contract available at address `0xc8` that is only accessible via RPCs (it's not actually deployed onchain and thus can't be called by smart contracts). The way it works is that the node uses Geth's [`InterceptRPCMessage`](https://github.com/OffchainLabs/go-ethereum/blob/@@goEthereumCommit=ae34a6a9ef5af5079c8eef6571895d703023efef@@/internal/ethapi/api.go#L1034) hook to detect messages sent to the address `0xc8`, and swaps out the message it's handling before deriving a transaction from it.
 
 The [reference page](/build-decentralized-apps/nodeinterface/02-reference.mdx) contains information about all methods available in the `NodeInterface`.