Fix typos and grammatical errors in notices and reference documentation

notices/archive/blob-fee-bug.mdx

@@ -1,9 +1,9 @@
 ---
 title: Superchain testnets' blob fee bug
-description: Learn about the blob fee bug that effects OP Stack testnets on the Superchain and how to fix it.
+description: Learn about the blob fee bug that affects OP Stack testnets on the Superchain and how to fix it.
 ---
 
-At the time of writing, all OP Stack testnets are currently sequencing a "wrong" chain. The L1 Block's blob base fee is calculated with pre-Prague blob schedule parameters. This is not a critical security issue on any OP Sepolia (or Holesky) chain. However, when L1 blob base fees rise to 100 Mwei or higher on the L1 testnet, there is a temporary liveness risk, because we'd be overcharge L1 fees.
+At the time of writing, all OP Stack testnets are currently sequencing a "wrong" chain. The L1 Block's blob base fee is calculated with pre-Prague blob schedule parameters. This is not a critical security issue on any OP Sepolia (or Holesky) chain. However, when L1 blob base fees rise to 100 Mwei or higher on the L1 testnet, there is a temporary liveness risk, because we'd overcharge L1 fees.
 
 This was fixed on the `develop` branch with this [PR](https://github.com/ethereum-optimism/optimism/pull/14500) and there will be no impact on any mainnet chains. Mainnet chains will just need to update their binaries to the latest release prior to the activation of Pectra on Ethereum, so the bug isn't triggered when Pectra activates.
 
@@ -25,9 +25,9 @@
 
 | BBF Prague (actual) | BBF Cancun (we charge) |
 | ------------------- | ---------------------- |
 | 1 Mwei              | 1 Gwei                 |
 | 10 Mwei             | 31.6 Gwei              |
 | 100 Mwei            | 1 Twei                 |
 | 1 Gwei              | 31.6 Twei (31.6e12)    |
 | 10 Gwei             | 1e15 Wei = 1 PetaWei   |
 | 100 Gwei            | 31.6e15 PetaWei        |
@@ -99,7 +99,7 @@
 
   <Step title="Reorg the chain">
   ```
     cast rpc --rpc-url=http://localhost:8545 debug_setHead 0x5E619D
     ```
   </Step>
 

notices/archive/pectra-changes.mdx

@@ -6,7 +6,7 @@
 <Info>
   Please note that this notice page was updated March 11th, 2025. There was a bug found in previous op-node releases where the L1 Block's blob base fee (for the sake of computing the L1 fees) is calculated with pre-Prague=Cancun blob schedule parameters, instead of using the Prague parameters. This bug has been fixed in the latest release of op-node.
 
   This is not a critical issue on any OP Sepolia chain. However, when L1 blob base fees rise to 100 Mwei or higher on Sepolia, there is a temporary liveness risk, because we'd be overcharge L1 fees. Essentially, our L1 cost computation now overcharges by an exponential of 1.5, BBF\_Cancun = `BBF_Prague^1.5` (where BBF=blob base fee).
 
   You must update your Sepolia nodes to the latest release of op-node and schedule a hardfork activation time to avoid this issue on your network. There are new instructions in the node operator section to help you mitigate this issue.
 
@@ -48,7 +48,7 @@
 
 ## For node operators
 
-Node operators will need to upgrade to the respective releases before the activation dates.These following steps are necessary for every node operator:
+Node operators will need to upgrade to the respective releases before the activation dates. These following steps are necessary for every node operator:
 
 ### Update to the latest release
 
@@ -98,7 +98,7 @@
   The following instructions assume your chain is on the latest contract release `op-contracts/v1.8.0` and has Holocene activated.
 </Info>
 
 All fault proof enabled chains (both permisionless and permissioned fault proof systems) need to update their `op-challenger` binary to [`op-challenger/v1.3.2`](https://github.com/ethereum-optimism/optimism/releases/tag/op-challenger%2Fv1.3.2).
 
 The following steps are to update your absolute prestate with new dispute game contracts. **This is absolutely necessary for chains running permissionless fault proofs.** For chains running the Fault Proof System with permissioned games you can skip this section because games will not be played out and the absolute prestate is not used.
 

notices/archive/superchain-withdrawal-pause-test.mdx

@@ -18,4 +18,4 @@ The Optimism Collective will be testing improved incident response features on t
 
 To learn more about this functionality, please refer to this [documentation](/stack/security/pause).
 
-This functionality is important for the security of the Superchain and should be understood by Chain Operators, users, and especially for centralized exchanges and third-party bridge operators. **Please note that this will not effect any L1-to-L2 deposit transactions or L2 transactions. No action is required from users or operators.**
+This functionality is important for the security of the Superchain and should be understood by Chain Operators, users, and especially for centralized exchanges and third-party bridge operators. **Please note that this will not affect any L1-to-L2 deposit transactions or L2 transactions. No action is required from users or operators.**

notices/fusaka-notice.mdx

@@ -1,6 +1,6 @@
 ---
 title: Fusaka upgrade notice
 description: Learn how to prepare for the Fusaka upgrade
 lang: en-US
 content_type: notice
 topic: fusaka-upgrade
@@ -14,75 +14,75 @@
 ---
 
 
 # Preparing for L1 Fusaka upgrade
 
 This page provides external-facing information about the Fusaka readiness upgrade for OP Stack chains. It summarizes scope, timelines, required actions, and resources for chain operators and partners. This upgrade is necessary for all OP Stack chains deriving from an L1 chain which is due to activate Fusaka (including Ethereum Mainnet and Sepolia).
 
 This is NOT Fusaka adoption on L2. It's a readiness upgrade to make the Optimism protocol compatible with L1 that activates the Fusaka fork. L2 adoption will happen in a future upgrade.
 
 <Info>
   All of the tasks below must be performed before Fusaka activates on L1.
 </Info>
 
 ## What's included in Fusaka
 
 Fusaka contains various breaking changes. See [EIP-7607: Hardfork Meta - Fusaka](https://eips.ethereum.org/EIPS/eip-7607) for more info.
 
 **Important dates:**
 
 Ethereum Sepolia Fusaka hard fork: Tuesday, October 14th, 2025 07:36:00 UTC (affects chains posting data to Sepolia)
 
 Ethereum Mainnet Fusaka hard fork: Wednesday, December 3rd, 2025 21:49:11 UTC,	1764798551
 
 ## For node operators
 
 Update your node software as soon as possible after release:
 
 *   Update `op-node` to [v1.14.1](https://github.com/ethereum-optimism/optimism/releases/tag/op-node%2Fv1.14.1). See the release notes for new config flags and env variables (not necessary for chains deriving from Ethereum Mainnet, Sepolia, Holesky or Hoodi.)
 *   Update `op-geth` to [v1.101603.1](https://github.com/ethereum-optimism/op-geth/releases/tag/v1.101603.1)
 
 ### Ensure your L1 beacon node endpoint can serve all blobs
 
 **For operators using an external L1 Ethereum Beacon:**
 
 Before the Ethereum Fusaka hard fork, ensure your external L1 Beacon Chain RPC provider has configured their node to subscribe to all subnets.
 If your external L1 Beacon Chain RPC provider doesn't subscribe to all subnets, migrate to one that does prior to these deadlines.
 
 **For operators running their own L1 Ethereum Beacon Chain Node:**
 
 **If you operate your own L1 nodes, ensure also both the L1 execution and beacon nodes are upgraded** and configured for the Fusaka fork (see [Fusaka specs here](https://blog.ethereum.org/2025/09/26/fusaka-testnet-announcement)).
 
 Outdated L1 nodes can cause derivation failures, blob unavailability, or chain divergence after the fork.
 
 Configure your Beacon Node with the new flag (detailed below) before the relevant Fusaka hard fork date.
 
 L1 Beacon Chain Node flags:
 
 *   Lighthouse:	`--supernode`
 *   Teku:	`--p2p-subscribe-all-custody-subnets-enabled`
 *   Grandine:	`--subscribe-all-data-column-subnets`
 *   Lodestar:	`--supernode`
 *   Nimbus:	`--debug-peerdas-supernode`
 
 ## For chain operators
 
 <Info>
 Be ready to restart your batcher with the new configuration immediately after the Fusaka fork on L1: e.g. for Sepolia this is at Unix timestamp 1760427360 (Tue Oct 14 2025 07:36:00 UTC). For Mainnet this is at Unix timestamp 1764798551 (Wed Dec 03 2025 21:49:11 UTC).
 </Info>
 
 <Info>
   Although new chains deriving from Holesky are supported, existing chains deriving from Holesky are not supported since Holesky already activated Fusaka on L1.
 </Info>
 
 Update the following:
 
 | Component       | Version                                                                                               | Notes                                                                                                                                                                                          |
 | --------------- | ----------------------------------------------------------------------------------------------------- | ---------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- |
-| `proxyd`        | [v4.19.0](https://github.com/ethereum-optimism/infra/releases/tag/proxyd%2Fv4.19.0) or greater        | You need to whitelist `eth_blobBaseFee` rpc if using proxyd for L1 load balancing. If you use `dugtrio` ensure this is also updated to the latest release.                                                                                                              |
+| `proxyd`        | [v4.19.0](https://github.com/ethereum-optimism/infra/releases/tag/proxyd%2Fv4.19.0) or greater        | You need to whitelist `eth_blobBaseFee` rpc if using proxyd for L1 load balancing. If you use `dugtrio`, ensure this is also updated to the latest release.                                                                                                              |
 | `op-batcher`    | [v1.16.0](https://github.com/ethereum-optimism/optimism/releases/tag/op-batcher%2Fv1.16.0)            | `OP_BATCHER_TXMGR_ENABLE_CELL_PROOFS`: `true` or equivalent CLI flag needs to be set and the batcher restarted just after Fusaka activates on L1.                                              |
 | `op-node`       | [v1.14.1](https://github.com/ethereum-optimism/optimism/releases/tag/op-node%2Fv1.14.1)               | L1 chain config must be supplied via a new flag (see the release notes). Not necessary for chains deriving from Ethereum Mainnet, Sepolia, Holesky or Hoodi.                                            |
 | `op-geth`       | [v1.101603.1](https://github.com/ethereum-optimism/op-geth/releases/tag/v1.101603.1)                  |                                                                                                                                                                                                |
 | `op-challenger` | [v1.6.0](https://github.com/ethereum-optimism/optimism/releases/tag/op-challenger%2Fv1.6.0)           | L1 chain config must be supplied via a new flag (see the release notes). Not necessary for chains deriving from Ethereum Mainnet, Sepolia, Holesky or Hoodi.                                            |
 | `kona-node`     | [v1.1.6](https://github.com/op-rs/kona/releases/tag/kona-node%2Fv1.1.6)                               |                                                                                                                                                                                                |
 | `kona-host`     | [v1.1.6](https://github.com/op-rs/kona/releases/tag/kona-host%2Fv1.1.6)                     |                                                                                                                                                                                                |
 | `kona-client`   | [v1.1.6](https://github.com/op-rs/kona/releases/tag/kona-client%2Fv1.1.6)                   |                                                                                                                                                                                                |
@@ -91,7 +91,7 @@
 <Info>
 **Note:** `op-node` v1.14.1 uses the new `/eth/v1/beacon/blobs/` API for fetching blob data from L1 beacon nodes. If you run a proxy/load balancer in front of your beacon API, ensure it correctly forwards all query parameters. 
 
 Misconfigured proxies may cause blob fetch failures or derivation stalls after the Fusaka fork.
 </Info>
 ### For Permissionless Fault Proof enabled chains
 

notices/upgrade-17.mdx

@@ -25,7 +25,7 @@ Upgrade 17 introduces the following changes:
 
 For more information on the Jovian implementation details, please review the [Jovian specifications](https://specs.optimism.io/protocol/jovian/overview.html).
 
-## Breaking Changes -
+## Breaking Changes
 
 ### Block header changes
 

reference/components.mdx

@@ -12,7 +12,7 @@
 This doesn't include all of the modules or layers that may exist in the future, but it gives a good overview of the major OP Stack components.
 
 <Info>
-  Please note that not all of the modules described on this page already exist in a production state — these are explicitly marked as either "**in development**"or "**proposed**."
+  Please note that not all of the modules described on this page already exist in a production state — these are explicitly marked as either "**in development**" or "**proposed**."
 </Info>
 
 ## Layers
@@ -23,14 +23,14 @@
 
 #### Ethereum DA
 
 Ethereum DA is currently the most widely used Data Availability module for the OP Stack. When using the Ethereum DA module, source data can be derived from any piece of information accessible on the Ethereum blockchain. This includes Ethereum calldata, events, and 4844 data blobs.
 
 *   [Specifications](https://specs.optimism.io/protocol/derivation.html#batch-submission-wire-format?utm_source=op-docs&utm_medium=docs)
 *   [Source code](https://github.com/ethereum-optimism/optimism/tree/v1.1.4/op-batcher)
 
 ### Sequencing
 
 The Sequencing Layer determines how user transactions on an OP Stack chain are collected and published to the Data Availability Layer module(s) in use. In the default Rollup configuration of the OP Stack, Sequencing is typically handled by a single dedicated Sequencer. Rules defined in the Derivation Layer generally restrict the Sequencer's ability to withhold transactions for more than a specific period of time. In the future, Sequencing will be modular such that chains can easily select and change the mechanism that controls their current Sequencer.
 
 #### Single sequencer
 
@@ -57,7 +57,7 @@
 
 ### Execution
 
 The Execution Layer defines the structure of state within an OP Stack system and defines the state transition function that mutates this state. State transitions are triggered when inputs are received from the Derivation Layer via the Engine API. The Execution Layer abstraction opens up the door to EVM modifications or different underlying VMs entirely.
 
 #### EVM
 

reference/contribute/stack-contribute.mdx

@@ -18,7 +18,7 @@ To start contributing components to the stack, check out some of these [useful i
 
 The OP Stack codebase is not a product (in the traditional sense) but rather a collection of software components that power the Optimism ecosystem.
 If you'd like to contribute to the current release of OP Stack codebase, rather than creating new components, your contribution would be greatly appreciated.
-**A "Release"of the OP Stack codebase is a particular set of software components that are production-ready and which fit the stack's design principles and goals.**
+**A "Release" of the OP Stack codebase is a particular set of software components that are production-ready and which fit the stack's design principles and goals.**
 
 To make your first contribution to the codebase, check out the [open issues](https://github.com/ethereum-optimism/optimism/issues) on the Optimism Monorepo.
 

reference/glossary.mdx

@@ -17,7 +17,7 @@
 
 ### Address aliasing
 
-When a contract submits a [deposit](#deposit) from L1 to L2, it's address (as returned by `ORIGIN` and `CALLER`) will be
+When a contract submits a [deposit](#deposit) from L1 to L2, its address (as returned by `ORIGIN` and `CALLER`) will be
 aliased with a modified representation of the address of a contract.
 
 ### Block
@@ -85,10 +85,10 @@
 ### PGA or priority gas auction
 
 Transactions in ethereum are ordered by the price that the transaction pays to the miner. Priority Gas Auctions
 (PGAs) occur when multiple parties are competing to be the first transaction in a block. Each party continuously
 updates the gas price of their transaction. PGAs occur when there is value in submitting a transaction before other
 parties (like being the first deposit or submitting a deposit before there is not more guaranteed gas remaining).
 PGAs tend to have negative externalities on the network due to a large amount of transactions being submitted in a
 very short amount of time.
 
 ### Receipt
@@ -131,7 +131,7 @@
 ### Validator mode
 
 The rollup node performs derivation as indicated in sequencer mode, but is also able to "run ahead" of the L1
 chain by getting blocks directly from the sequencer, in which case derivation serves to validate the sequencer's
 behavior. A rollup node running in validator mode is sometimes called *a replica*.
 
 \[[return to top](#table-of-contents)]
@@ -189,7 +189,7 @@
 
 ### Attestation proof
 
 A proof which consists of some number of signatures from a pre-agreed upon set of chain attestors.
 
 ### Cannon fault proof
 
@@ -215,7 +215,7 @@
 
 the L1 origin of an L2 block is the L1 block corresponding to its [sequencing epoch](#sequencing-epoch).
 
 ### Merkle patricia trie
 
 sparse [trie](https://en.wikipedia.org/wiki/Trie), which is a tree-like structure that maps keys to values.
 The root hash of a MPT is a commitment to the contents of the tree, which allows a proof to be constructed for any key-value mapping encoded in the tree. Such a proof is called a Merkle proof, and can be
@@ -314,7 +314,7 @@
 
 Transaction submitted by a [batcher](#batcher) to a data availability provider, in order to make
 channels available. These transactions carry one or more full frames, which may belong to different channels. A
 channel's frame may be split between multiple batcher transactions. When submitted to Ethereum calldata, the batcher
 transaction's receiver must be the sequencer inbox address. The transaction must also be signed by a recognized batch submitter account.
 
 ### Channel
@@ -355,7 +355,7 @@
 
 Guarantee that some data will be "available" (i.e. *retrievable*) during a reasonably long time
 window. In Optimism's case, the data in question are [sequencer batches](#sequencer-batch) that [validators](#validator)
 need in order to verify the sequencer's work and validate the L2 chain. The [finalization period](#finalization-period)
 should be taken as the lower bound on the availability window, since that is when data availability is the most crucial,
 as it is needed to perform a [fault proof](#fault-proof). "Availability" **does not** mean guaranteed long-term storage of the data.
 
@@ -375,8 +375,8 @@
 emitted as log records (in Solidity, these are called *events*) for consumption by [rollup nodes](#rollup-node).
 
 <Info>
   The deposits are not stored in calldata because they can be sent by contracts, in which case the calldata
   is part of the *internal* execution between contracts, and this intermediate calldata is not captured in one of the
   [Merkle Patricia Trie roots](#merkle-patricia-trie) included in the L1 block.
 </Info>
 
@@ -394,7 +394,7 @@
 ### Depositing Call
 
 L1 call to the deposit contract, which will be derived to a [user-deposited transaction](#user-deposited-transaction) by the rollup driver.
 This call specifies all the data (destination, value, calldata, ...) for the deposited transaction.
 
 ### Depositing Transaction
 
@@ -416,7 +416,7 @@
 ### Finalization Period
 
 The minimum amount of time (in seconds) that must elapse before a withdrawal can be finalized, sometimes called **withdrawal delay**.
 The finalization period is necessary to afford sufficient time for validators to make a fault proof.
 
 ### L1 Attributes Deposited Transaction
 
@@ -451,7 +451,7 @@
 then passed to the [execution engine](#execution-engine) to construct L2 blocks. The payload attributes object essentially
 encodes a [block](#block) without output properties.
 
 ### Relayer
 
 EOA on L1 which finalizes a withdrawal by submitting the data necessary to verify its inclusion on L2.