youssefea · Oct 8, 2026 · Oct 8, 2026 · Oct 8, 2026 · Oct 9, 2026
diff --git a/docs/base-chain/api-reference/rpc-overview.mdx b/docs/base-chain/api-reference/rpc-overview.mdx
@@ -74,7 +74,7 @@
 
 ### Debug API
 
-Development and debugging utilities for deep transaction inspection and block replay. Debug methods replay transactions and are computationally expensive — availability and rate limits vary among providers in the [Builder Stack](/get-started/builder-stack).
+Development and debugging utilities for deep transaction inspection and block replay. Debug methods replay transactions and are computationally expensive — availability and rate limits vary among providers in the [Builder Stack](/get-started/builder-stack). The public `https://mainnet.base.org` endpoint does not serve the `debug`, `trace`, or `txpool` namespaces.
 
 | Method | Description |
 | --- | --- |
@@ -116,7 +116,7 @@

 **Error response:**

 ```json Error Response lines wrap expandable
 {
  "jsonrpc": "2.0",
  "id": 1,

diff --git a/docs/get-started/connect-to-base.mdx b/docs/get-started/connect-to-base.mdx
@@ -20,6 +20,10 @@ Base is a standard EVM chain, so any Ethereum tool, wallet, or library works unc
 Use the transaction submission endpoint only to send transactions. Use the RPC endpoint for all other requests.
 </Note>
 
+<Warning>
+The public RPC endpoints are free, rate limited, and best effort, and are not suitable for production apps. Since October 8, 2026, `https://mainnet.base.org` no longer serves the `debug`, `trace`, or `txpool` namespaces, and read requests have a lower rate limit. If your app uses these namespaces or needs higher throughput, use a dedicated RPC provider from the [Builder Stack](/get-started/builder-stack).
+</Warning>
+
 ## Next Steps
 
 <CardGroup cols={2}>

diff --git a/docs/specifications/b20/changelog.mdx b/docs/specifications/b20/changelog.mdx
@@ -52,10 +52,10 @@ Shipped with the [Beryl upgrade](/upgrades/beryl/overview).
 - The B20 standard as a native precompile: a superset of ERC-20 with full selector and behavior parity for `transfer`, `transferFrom`, `approve`, `allowance`, `balanceOf`, `totalSupply`, `name`, `symbol`, `decimals`, `Transfer`, and `Approval`
 - [Role-based access control](/specifications/b20/concepts/roles-and-pause#2-roles) with built-in roles, user-defined roles in the role graph, and `renounceLastAdmin` for permanent admin-less operation
 - [PolicyRegistry](/specifications/b20/concepts/policies#21-the-registry-and-the-token) singleton precompile with `BLOCKLIST`, `ALLOWLIST`, `UNION`, and `INTERSECT` policy types, two-step admin transfer, and the `ALWAYS_ALLOW` and `ALWAYS_BLOCK` built-ins
-- [Six policy scopes](/specifications/b20/concepts/policies#32-policy-scopes) on every token, covering transfer sender, receiver, and executor, mint receiver, and seize holder and receiver
-- [`seizeWithMemo`](/specifications/b20/reference/interfaces/ib20/seize-with-memo) for compliance-driven balance transfers
-- [Memo variants](/specifications/b20/reference/interfaces/ib20) of transfer, transferFrom, mint, burn, and seize, emitting `Memo` immediately after the primary event
-- [Granular pausing](/specifications/b20/concepts/roles-and-pause#3-pause) by `PausableFeature`: `TRANSFER`, `MINT`, `BURN`, and `SEIZE`
+- [Four policy scopes](/specifications/b20/concepts/policies#32-policy-scopes) on every token, covering transfer sender, receiver, and executor, and mint receiver
+- [Memo variants](/specifications/b20/reference/interfaces/ib20) of transfer, transferFrom, mint, and burn, emitting `Memo` immediately after the primary event
+- [Granular pausing](/specifications/b20/concepts/roles-and-pause#3-pause) by `PausableFeature`: `TRANSFER`, `MINT`, and `BURN`
+- `burnBlocked` and `BURN_BLOCKED_ROLE` for administrative removal of a blocked holder's balance
 - [Optional supply caps](/specifications/b20/reference/interfaces/ib20/supply-cap), with `type(uint128).max` as the uncapped sentinel and maximum supply
 - [ERC-2612 `permit`](/specifications/b20) with an EIP-712 domain at version `"1"`
 - [ERC-7572 `contractURI`](/specifications/b20/reference/interfaces/ib20/contract-uri) and `METADATA_ROLE`-gated name, symbol, and URI updates
@@ -64,6 +64,4 @@ Shipped with the [Beryl upgrade](/upgrades/beryl/overview).
 - The [`ASSET` variant](/specifications/b20/concepts/token-types#4-asset): `OPERATOR_ROLE`, WAD-precision UI multipliers with scheduled and instant updates, announcements, `batchMint`, and issuer-defined extra metadata
 - The [`STABLECOIN` variant](/specifications/b20/concepts/token-types#5-stablecoin): fixed 6 decimals and a `currency()` code set once at creation
 
-**Deprecated**
-
-- `burnBlocked` and `BURN_BLOCKED_ROLE`, retained for backwards compatibility. New seizure flows use `seizeWithMemo`.
+`seizeWithMemo`, the `SEIZE` pause feature, the two seize policy scopes, and the deprecation of `burnBlocked` shipped later with Cobalt. See the [seize changelog entry](/base-chain/specs/reference/b20/changelog/02-cobalt-b20-seize).
diff --git a/docs/specifications/base-protocol/proofs/proposer.mdx b/docs/specifications/base-protocol/proofs/proposer.mdx
@@ -65,6 +65,16 @@
 BLOCK_INTERVAL / INTERMEDIATE_BLOCK_INTERVAL
 ```
 
+On Base Mainnet, the [`AggregateVerifier`](/specifications/reference/base-contracts) implementation registered
+for game type `621` sets `BLOCK_INTERVAL` to `600` and `INTERMEDIATE_BLOCK_INTERVAL` to `30`. With
+2-second blocks, a new proposal covers about 20 minutes of L2 blocks. You can read the current values
+onchain:
+
+```bash Read the Mainnet Proposal Interval
+cast call 0xeF9eCeA15265321753047EBF7D54C858D53cB94f "BLOCK_INTERVAL()(uint256)" --rpc-url <l1-rpc>
+cast call 0xeF9eCeA15265321753047EBF7D54C858D53cB94f "INTERMEDIATE_BLOCK_INTERVAL()(uint256)" --rpc-url <l1-rpc>
+```
+
 The proposer defaults to finalized L2 state. If explicitly configured to allow non-finalized
 proposals, it may use the rollup node's safe L2 state instead.
 
@@ -196,7 +206,7 @@

 where `journal` is packed as:

 ```text Journal Packing lines wrap expandable
 proposer(20)
 || l1OriginHash(32)
 || prevOutputRoot(32)

diff --git a/docs/specifications/node-operators/run-a-node.mdx b/docs/specifications/node-operators/run-a-node.mdx
@@ -22,7 +22,7 @@ If you're just getting started and need an RPC URL, you can use our free endpoin
 - **Mainnet**: `https://mainnet.base.org`
 - **Testnet (Sepolia)**: `https://sepolia.base.org`
 
-**Note:** Our RPCs are rate-limited, they are not suitable for production apps.
+**Note:** Our RPCs are rate-limited, they are not suitable for production apps. The public Mainnet endpoint does not serve the `debug`, `trace`, or `txpool` namespaces.
 
 If you're looking to harden your app and avoid rate-limiting for your users, choose an RPC provider from the [Builder Stack](/get-started/builder-stack).
 </Warning>
@@ -198,6 +198,8 @@ Your Flashblocks-aware node supports all standard Ethereum JSON-RPC methods plus
 
 To serve methods like `eth_getProof`, `debug_executionWitness` and `debug_executePayload` efficiently, you'll need to set up the historical proofs execution extension (ExEx). This ExEx manages a separate database with data required to serve these methods. This database can add hundreds of GB of additional storage and requires a machine with higher I/O throughput. Most people do not need these RPCs to be available.
 
+Without the proofs ExEx, `eth_getProof` only serves blocks within `--rpc.eth-proof-window` blocks of the chain tip. Reth's default window is `0`, so only the latest block can be proven, and the maximum is `1209600` blocks (28 days at 2-second blocks). The `.env.mainnet` and `.env.sepolia` files in [base/base](https://github.com/base/base) do not set this flag. To serve historical proofs, use the proofs ExEx described below.
+
 In order to run the historical proofs ExEx, you simply need to set this environment variable:
 
 ```bash Terminal

diff --git a/docs/specifications/node-operators/snapshots.mdx b/docs/specifications/node-operators/snapshots.mdx
@@ -9,14 +9,12 @@ Using a snapshot significantly reduces the initial time required to sync a Base
 If you're a prospective or current Base node operator, you can restore from a snapshot to speed up your initial sync. Follow the steps below carefully.
 
 <Warning>
-**Action required: migrate to reth V2 storage.** Base Mainnet operators must upgrade and migrate to reth V2 storage **by mid-August**. V1 snapshots are being decommissioned over the next few weeks, so plan to migrate soon.
+**V1 snapshots are no longer published.** Base stopped publishing V1 node database snapshots on October 5, 2026 ([status notice](https://status.base.org/incidents/jx4p15jppftm)). Only reth V2 storage snapshots are available, from [chain.base.org/snapshots](https://chain.base.org/snapshots).
 
-You have two migration paths:
+If your node still uses V1 storage, upgrade to `base-reth-node` [v1.2.0](https://github.com/base/base/releases/tag/v1.2.0) or later and migrate to V2 storage using one of two paths:
 
 - **Download a fresh V2 snapshot** (recommended, faster) — use `base-reth-node download` as described in [Restoring from Snapshot](#restoring-from-snapshot) below.
 - **Migrate existing V1 data in place** — run `base-reth-node db migrate-v2`. This is expected to take **much** longer than downloading, and non-archival nodes are not supported.
-
-Because migration can take a while, we strongly recommend starting now. For details, see the [v1.2.0 release notes](https://github.com/base/base/releases/tag/v1.2.0).
 </Warning>
 
 ## Restoring from Snapshot

diff --git a/docs/specifications/transactions/transaction-finality.mdx b/docs/specifications/transactions/transaction-finality.mdx
@@ -24,8 +24,8 @@ For transactions on Base, finality is not a single time to wait for. Instead, th
 <Steps>
 <Step title="Flashblock Inclusion: ~200ms" titleSize="h3">
 After roughly 200ms, the transaction is included in a preconfirmation block (Flashblock) by the Base sequencer.
-<Accordion title="Under 0.001% Probability of a Reorg.">
-* Flashblocks reorg less than 0.001% of the time
+<Accordion title="Under 0.1% Probability of a Reorg.">
+* Base targets a Flashblock reorg rate of less than 0.1%, as listed in [Throughput and Limits](/specifications/transactions/throughput-and-limits#flashblock-performance)
 * You can see the reorg history in our [public stats page.](https://base.org/stats)
 </Accordion>
 
@@ -58,7 +58,7 @@ This describes finality of transactions that move funds from Base to Ethereum
 
 **Only withdrawals to Ethereum must wait for a finalization window before the funds can be released to the address on Ethereum L1.** This allows Base's proof system to provide extremely high security guarantees for funds bridged to Base.
 
-Since the [Beryl upgrade](/upgrades/beryl/reducing-canonical-withdrawal-delay), the finalization window is 5 days for a single-proof dispute game and 1 day on the dual-proof fast path, when both a TEE proof and a ZK proof back the same proposal. The window accounts for most of the end-to-end time; waiting for the relevant Base state to be proposed on Ethereum usually adds only about 20 to 60 minutes, plus the prove and finalize transactions. Third-party bridges that release funds faster use their own liquidity and do not change this window.
+Since the [Beryl upgrade](/upgrades/beryl/reducing-canonical-withdrawal-delay), the finalization window is 5 days for a single-proof dispute game and 1 day on the dual-proof fast path, when both a TEE proof and a ZK proof back the same proposal. The window accounts for most of the end-to-end time; waiting for the relevant Base state to be proposed on Ethereum usually adds only about 20 to 60 minutes, plus the prove and finalize transactions. Each proposal on Base Mainnet covers 600 L2 blocks (about 20 minutes at 2-second blocks); see [Proposer](/specifications/base-protocol/proofs/proposer#startup-configuration) for details. Third-party bridges that release funds faster use their own liquidity and do not change this window.
 
 <Accordion title="What Happens During the Finalization Window?">
 After a withdrawal is initiated on Base, a proposer submits a checkpoint claim on Ethereum through an `AggregateVerifier` game with a TEE or ZK proof. An independent challenger can dispute an invalid claim with a ZK proof. The game's finalization window gives other participants time to verify the claim; when TEE and ZK proofs support the same proposal, the dual-proof path is shorter. See the [Azul proof system](/upgrades/azul/proofs) for the proof flow.

diff --git a/docs/upgrades/azul/proofs.mdx b/docs/upgrades/azul/proofs.mdx
@@ -37,6 +37,10 @@ The Azul design supports three settlement paths for a proposal on Ethereum:
 | ZK only        | Long window     | 7 days        | Permissionless path without TEE reliance |
 | TEE + ZK       | Short window    | 1 day         | Faster finality when both systems agree  |
 
+<Note>
+The [Beryl upgrade](/upgrades/beryl/reducing-canonical-withdrawal-delay) later reduced the single-proof long window from 7 days to 5 days. The TEE + ZK window remains 1 day.
+</Note>
+
 The long window gives independent provers time to verify a claim and dispute it if needed. The
 short window is available only when both proof systems back the same proposal. A ZK prover can also
 dispute an invalid TEE-backed claim and claim the TEE prover's bond as a reward. In Azul, that delay

diff --git a/docs/upgrades/beryl/reth-v2.mdx b/docs/upgrades/beryl/reth-v2.mdx
@@ -14,3 +14,5 @@ Reth V2 replaces the previous Reth execution client as the reference implementat
 ## Migration
 
 Node operators should upgrade to the Reth V2 binary before Beryl activation. No application-level changes are required.
+
+Nodes must also use reth V2 storage. Base no longer publishes V1 node snapshots, so download a V2 snapshot or migrate existing data with `base-reth-node db migrate-v2`. See [Node Snapshots](/specifications/node-operators/snapshots) for both paths.
Original file line number	Diff line number	Diff line change
Expand Up		@@ -14,3 +14,5 @@ Reth V2 replaces the previous Reth execution client as the reference implementat
		## Migration

		Node operators should upgrade to the Reth V2 binary before Beryl activation. No application-level changes are required.

		Nodes must also use reth V2 storage. Base no longer publishes V1 node snapshots, so download a V2 snapshot or migrate existing data with `base-reth-node db migrate-v2`. See [Node Snapshots](/specifications/node-operators/snapshots) for both paths.