ethereum-optimism · bradleycamacho · Mar 3, 2025 · Feb 20, 2025 · Feb 20, 2025 · Feb 20, 2025
@@ -72,7 +72,7 @@ These following steps are necessary for every node operator:
   ### Configure the Holocene activation date
 
   <Callout type="warning">
-    If you are operating a node for an OP Chain that have opted into the [hardfork activation inheritance behavior](https://github.com/ethereum-optimism/superchain-registry/blob/main/docs/hardfork-activation-inheritance.md), the Holocene activation date is part of the `op-node` and `op-geth` nodes. So, no action is needed for the sequencer after upgrading to the latest release. Please skip to [Step 3: Verify Your Configuration](#verify-your-configuration).
+    If you are operating a node for an OP Chain that has opted into the [hardfork activation inheritance behavior](https://github.com/ethereum-optimism/superchain-registry/blob/main/docs/hardfork-activation-inheritance.md), the Holocene activation date is part of the `op-node` and `op-geth` nodes. So, no action is needed for the sequencer after upgrading to the latest release. Please skip to [Step 3: Verify Your Configuration](#verify-your-configuration).
 
     For Sepolia that is: `OP Sepolia`, `Base Sepolia`, `Mode Sepolia`, `Zora Sepolia`, and `Metal Sepolia`.
   </Callout>

@@ -49,7 +49,7 @@ amount of data required to reproduce L2 blocks.
 
 `op-deployer` is a tool that simplifies the process of deploying standardized OP Stack chains that comply with Superchain specifications. 
 It compares the state of your chain against the intent, 
-and make whatever changes are necessary for them to match. In its current state, 
+and makes whatever changes are necessary for them to match. In its current state, 
 it is intended to deploy new standard chains that utilize the Superchain wide contracts.
 
 

@@ -86,7 +86,7 @@ You should use at least the following compatible op\* versions when running your
   ### Set your fee configuration
 
   *   Chain operators are not posting everything to Ethereum, just commitments, so chain operators will need to determine fee scalars values to charge users. The fee scalar values are network throughput dependent, so values will need to be adjusted by chain operators as needed.
-  *   Cost structure for Alt-DA Mode: The transaction data is split up into 128kb chunks and then submitted to your DA Layer. Then, 32 byte commitments are submitted (goes to batch inbox address) to L1 for each 128kb chunk. Then, figure out how much that costs relative to the amount of transactions your chain is putting through.
+  *   Cost structure for Alt-DA Mode: The transaction data is split up into 128kb chunks and then submitted to your DA Layer. Then, 32 byte commitments are submitted (goes to batch inbox address) to L1 for each 128kb chunk. Then, figure out how much that costs relative to the number of transactions your chain is putting through.
   *   Set scalar values inside the deploy config. The example below shows some possible fee scalar values, calculated assuming negligible DA Layer costs, but will need to be adjusted up or down based on network throughput - as a reminder of how to set your scalar values, see [this section](/operators/chain-operators/management/blobs#update-your-scalar-values-for-blobs) of the docs.
 
       ```

@@ -8,7 +8,7 @@ import { Callout, Steps } from 'nextra/components'
 
 # Span batches
 
-Span batches are an important feature that optimizes batch processing within the chain. This section provides an overview of span batches, instructions on how to enable them, and links to detailed design documents.
+Span batches are an important feature that optimize batch processing within the chain. This section provides an overview of span batches, instructions on how to enable them, and links to detailed design documents.
 
 ## Overview
 

@@ -40,7 +40,7 @@ Even though the op-geth implementation of this endpoint includes rate limits, it
 *   Transaction targets are only 4337 Entrypoint contracts
 
 <Callout type="info">
-  The motivating factor for this endpoint is to enable permissionless 4337 mempools, hence the restricted usage of this methods to just [Entrypoint](https://github.com/eth-infinitism/account-abstraction/blob/develop/contracts/core/EntryPoint.sol) transactions.
+  The motivating factor for this endpoint is to enable permissionless 4337 mempools, hence the restricted usage of this method to just [Entrypoint](https://github.com/eth-infinitism/account-abstraction/blob/develop/contracts/core/EntryPoint.sol) transactions.
 
   Please open up an issue if you'd like this restriction to be optional via configuration to broaden usage of this endpoint.
 </Callout>

@@ -20,7 +20,7 @@ In this tutorial, you'll modify the Bedrock Rollup. Although there are many ways
 
 ## Getting the idea
 
-Let's quickly recap what you're about to do. The `op-node` is responsible for generating the Engine API payloads that trigger `op-geth` to produce blocks and transactions. The `op-node` already generates a "system transaction"for every L1 block that relays information about the current L1 state to the L2 chain. You're going to modify the `op-node` to add a new system transaction that reports the total burn amount (the base fee multiplied by the gas used) in each block.
+Let's quickly recap what you're about to do. The `op-node` is responsible for generating the Engine API payloads that trigger `op-geth` to produce blocks and transactions. The `op-node` already generates a "system transaction" for every L1 block that relays information about the current L1 state to the L2 chain. You're going to modify the `op-node` to add a new system transaction that reports the total burn amount (the base fee multiplied by the gas used) in each block.
 
 Although it might sound like a lot, the whole process only involves deploying a single smart contract, adding one new file to `op-node`, and modifying one existing file inside `op-node`. It'll be painless. Let's go!