fix: grammar issues

.github/ISSUE_TEMPLATE/🐞-bug-report.md

@@ -9,7 +9,7 @@ assignees: ''
 ---
 
 Thanks for helping us keep the Wonderland Handbook sharp and functional 🧹  
-If something isn’t behaving the way it should — from broken links to rendering issues — use this template to help us fix it fast.
+If something isn’t behaving the way it should: from broken links to rendering issues, use this template to help us fix it fast.
 
 ---
 

sites/optimism/docs/governance/bye.md

@@ -6,7 +6,7 @@ sidebar_label: Wrapping up
 
 # Wrapping Up
 
-To wrap up, where the OP Stack defines *how the system runs*, governance defines *how it changes*. It encodes: who can propose, who can vote, and who can veto. And because governance must evolve with the Collective, it’s designed to be both programmable and flexible—via modules, managers, and community experimentation.
+To wrap up, where the OP Stack defines *how the system runs*, governance defines *how it changes*. It encodes: who can propose, who can vote, and who can veto. And because governance must evolve with the Collective, it’s designed to be both programmable and flexible: via modules, managers, and community experimentation.
 
 As you’ve seen, governance isn’t just about casting votes. It’s about trust minimization, fault tolerance, consent, and credible neutrality. The system must balance legitimacy with execution, and decentralization with security.
 

sites/optimism/docs/governance/governance-overview.md

@@ -22,7 +22,7 @@ By the end of this section, you should be able to answer:
 - What’s the difference between an approval and a vote on Optimism?
 - Who can propose? Who can vote? What powers are delegated?
 - How do proposals move through states like Pending → Active → Executed?
-- How is quorum calculated, and what makes a proposal “pass”?
+- How is quorum calculated, and what constitutes “pass”?
 - What is Alligator, and why is delegation logic so complicated?
 - What happens if a delegate tries to push a proposal that violates cycle rules?
 - What is permissionless governance, and what tradeoffs does it introduce?

sites/optimism/docs/governance/governor-walkthrough.md

@@ -6,9 +6,9 @@ sidebar_label: Governor Walkthrough
 
 # The Optimism Governor Walkthrough
 
-The Optimism Governor is based on the OpenZeppelin’s Governor, customized to support Optimism’s governance needs: signaling proposals, customizable voting rules, subdelegations, and so on.
+The Optimism Governor is based on OpenZeppelin’s Governor, customized to support Optimism’s governance needs: signalling proposals, customizable voting rules, subdelegations, and so on.
 
-In the long run anyone should be able to propose changes, but safeguards like delegate approvals, quorum thresholds, and timelocks are required to ensure quality and protect against manipulation.
+In the long run, anyone should be able to propose changes, but safeguards like delegate approvals, quorum thresholds, and timelocks are required to ensure quality and protect against manipulation.
 
 Some useful resources: 
 
@@ -30,7 +30,7 @@ While proposals today are signaling-only for most types (i.e., they do not trigg
 
 - **`admin`**: Owns the proxy and controls upgrades. Does not vote or propose.
 - **`manager`**: Can create proposals, execute them, or update system parameters.
-- **`voters`**: Any address with delegated OP — either directly or through Alligator.
+- **`voters`**: Any address with delegated OP, either directly or through Alligator.
 
 ## Inheritance
 
@@ -64,7 +64,7 @@ propose(...):               // Standard proposal
 proposeWithModule(...):     // Proposal with custom voting module
 ```
 
-Only the `manager` or `timelock()` can call propose. Each proposal is assigned a `proposalType`, which maps to specific quorum/approval thresholds in the `ProposalTypesConfigurator`.
+Only the `manager` or `timelock()` can propose. Each proposal is assigned a `proposalType`, which maps to specific quorum/approval thresholds in the `ProposalTypesConfigurator`.
 
 Voting is handled via:
 - `castVote()`: standard token-based voting
@@ -77,7 +77,7 @@ Proposals are executed via the Timelock contract, using `execute()` or `executeW
 
 ### Alligator - Subdelegations
 
-The Alligator enables partial delegation, a user can split their voting power across multiple delegates using absolute or relative rules. These delegations can be chained (A → B → C) and validated onchain using authority[] arrays.
+The Alligator enables partial delegation; a user can split their voting power across multiple delegates using absolute or relative rules. These delegations can be chained (A → B → C) and validated onchain using authority[] arrays.
 
 The key structures are:
 - `subdelegations[from][to]`: maps delegations
@@ -102,9 +102,9 @@ Proposal thresholds are stored with 1e4 scaling (10000 = 100%). The Governor cal
 
 ## Votable Supply Oracle
 
-Instead of total token supply, quorum is based on votable supply — the total OP that has been delegated. This is retrieved at proposal creation block and used to calculate thresholds dynamically.
+Instead of the total token supply, quorum is based on votable supply — the total OP that has been delegated. This is retrieved at the proposal creation block and used to calculate thresholds dynamically.
 
-- **Fallback**: if `votableSupply()` returns zero, the Governor falls back to total token supply.
+- **Fallback**: if `votableSupply()` returns zero, the Governor falls back to the total token supply.
 
 ## Functions Summary
 
@@ -125,4 +125,4 @@ Instead of total token supply, quorum is based on votable supply — the total O
 
 ## Future Extensions
 
-We are working on an upgrade that is evolving toward permissionless proposals, enforced via `DelegatesProposalValidator` contract, it gates access to `propose()` based on delegate approvals and submission windows, allowing any qualifying participant to propose, while still preserving cycle alignment.
+We are working on an upgrade that is evolving toward permissionless proposals, enforced via `DelegatesProposalValidator` contract, which gates access to `propose()` based on delegate approvals and submission windows, allowing any qualifying participant to propose, while still preserving cycle alignment.

sites/optimism/docs/governance/intro-to-governance.md

@@ -8,13 +8,13 @@ sidebar_label: Governance in a nutshell
 
 Before we get into Optimism-specific contracts, let’s zoom out.
 
-On-chain governance is a mechanism for managing shared infrastructure using verifiable rules. In practice, governance contracts behave similar to multisigs, but with vote weights distributed across token holders rather than multisig signers.
+On-chain governance is a mechanism for managing shared infrastructure using verifiable rules. In practice, governance contracts behave similarly to multisigs, but with vote weights distributed across token holders rather than multisig signers.
 
 At its core, governance is about managing change. A **proposal** is just a transaction (or set of transactions): a list of target addresses, call data, and sometimes ETH values. Token holders vote to approve or reject the proposal. If the vote passes and quorum is met, the transaction can be executed onchain. If it fails, it’s simply discarded.
 
 Voting power is usually determined by the number of tokens an address holds at a specific snapshot block. Most systems also allow **delegation**, meaning you can assign your voting power to another address to vote on your behalf.
 
-Some proposals affect onchain systems directly (e.g. upgrading a contract). Others are **signaling-only** (e.g. changing a community guideline or legal structure). In those cases, proposals still follow the same governance flow, but their “execution” happens through offchain coordination or manual implementation.
+Some proposals affect onchain systems directly (e.g. upgrading a contract). Others are **signalling-only** (e.g. changing a community guideline or legal structure). In those cases, proposals still follow the same governance flow, but their “execution” happens through offchain coordination or manual implementation.
 
 ## Common Terms
 
@@ -33,7 +33,7 @@ These are the core terms used across most governance systems, including Optimism
 While implementations vary, the lifecycle of a proposal usually looks like this:
 
 ```nasm
-Pending ⭢ Active ⭢ Defeated ⭢ Canceled
+Pending ⭢ Active ⭢ Defeated ⭢ Cancelled
 			                 ⮑ Succeeded ⭢ Queued ⭢ Executed
 				                   ⮑----------⮑-------⮑  Expired
 ```
@@ -92,12 +92,12 @@ In particular, the [`GovernorCompatibilityBravo`](https://github.com/OpenZeppeli
 Most governance systems in Ethereum share the same building blocks:
 - A voting mechanism that calculates token-weighted power at a specific block (snapshot).
 - A registry of proposals with metadata like start/end blocks, vote tallies, and actions.
-- A timelock controller that enforces a minimum delay before execution.
+- A time lock controller that enforces a minimum delay before execution.
 - A quorum and approval threshold to ensure decisions are legitimate.
 
-On top of this, each protocol adds its own mechanics: delegation systems, role-based permissions, modular thresholds, and custom voting logic.
+On top of this, each protocol adds its mechanics: delegation systems, role-based permissions, modular thresholds, and custom voting logic.
 
-Some proposals are executable, others are advisory. Some are submitted by anyone, others require approvals. Governance is always opinionated, the trick is making those opinions legible and upgradeable.
+Some proposals are executable, others are advisory. Some are submitted by anyone, others require approval. Governance is always opinionated; the trick is making those opinions legible and upgradeable.
 
 ## Limitations and Responsibilities
 

sites/optimism/docs/governance/our-work/overview.md

@@ -8,7 +8,7 @@ This section documents active governance-related development initiatives led by
 
 ## Why it matters
 
-The governance is designed to evolve. Improvements often arise from practical bottlenecks observed by delegates, contributors, and protocol developers. This section records how those pain points are being addressed—through new contracts, improved interfaces, or procedural upgrades.
+The governance is designed to evolve. Improvements often arise from practical bottlenecks observed by delegates, contributors, and protocol developers. This section records how those pain points are being addressed through new contracts, improved interfaces, or procedural upgrades.
 
 Each entry aims to explain:
 

sites/optimism/docs/governance/our-work/permissionless-proposals.md

@@ -35,7 +35,7 @@ This contract wraps the proposal submission functions (`propose()` and `proposeW
 
 Its responsibilities include:
 
-- **Delegate approvals**: Verifies that the proposal has received enough sign-offs from top 100 delegates. Both the number of signers and their minimum voting power are configurable.
+- **Delegate approvals**: Verifies that the proposal has received enough sign-offs from the top 100 delegates. Both the number of signers and their minimum voting power are configurable.
 - **Window enforcement**: Ensures proposals are submitted within a designated submission window relative to the current voting cycle.
 - **GovernanceType validation**: Each proposal is tagged with a `GovernanceType`, which defines its eligibility rules, proposer constraints, and thresholds. There is no 1:1 mapping between GovernanceType and UI-facing proposal categories—one category (e.g., Protocol Upgrade) may have multiple GovernanceTypes depending on proposer roles and validation logic.
 - **Distribution limit**: Applies to funding proposals—checks that the requested OP does not exceed a configured limit for the cycle.
@@ -64,7 +64,7 @@ Its responsibilities include:
 ## Risks and Uncertainties
 
 - **GovernanceType complexity**: GovernanceTypes may proliferate as the system expands, especially since different proposers (e.g., Foundation vs. delegates) may have different rules for similar proposal categories. Care must be taken to manage and communicate this complexity to avoid confusion.
-- **Subdelegation ambiguity**: The system currently does not account for Alligator-style subdelegation. A delegate may appear in the top 100 due to delegated voting power, which may already be partially committed elsewhere—leading to unclear eligibility.
+- **Subdelegation ambiguity**: The system currently does not account for Alligator-style subdelegation. A delegate may appear in the top 100 due to delegated voting power, which may already be partially committed elsewhere, leading to unclear eligibility.
 - **Centralized configuration authority (MVP)**: Governance parameters are currently set by a single role. Long-term decentralization remains a critical roadmap goal.
 
 :::info reference

sites/optimism/docs/governance/the-operating-manual/the-citizens-house.md

@@ -23,7 +23,7 @@ Its core responsibility is managing the Retro Funding, and, increasingly, partic
 Citizens are individuals who hold an attestation of citizenship, managed via Ethereum Attestation Service (EAS). Citizenship is currently:
 - Temporary, and may evolve through experimental iterations
 - Granted experimentally, often through guest voter rounds
-- Revocable, if criteria are no longer met or based on conduct
+- Revocable, if the criteria are no longer met or based on conduct
 
 🔗 View the current [Citizen Schema on EAS](https://optimism.easscan.org/schema/view/0xc35634c4ca8a54dce0a2af61a9a9a5a3067398cb3916b133238c4f6ba721bc8a)
 
@@ -48,7 +48,7 @@ The Citizens’ House governs primarily through two processes:
     - Missions follow clear stages: scoping → applications → review → voting → disbursement → compliance
     - Voting takes place on [Snapshot](https://snapshot.org/#/citizenshouse.eth) with EAS-verified Citizen identities
 
-2. Veto Powers: Citizens have the ability to veto certain governance proposals approved by the Token House.
+2. Veto Powers: Citizens can veto certain governance proposals approved by the Token House.
 
     | Proposal Type | Veto Threshold | Notes |
     |--------------|----------------|--------|
@@ -65,7 +65,7 @@ Guest voters are temporary Citizens selected for experimental rounds of Retro Fu
 - Enable reversibility in experiments
 
 Inputs and outputs are measured via:
-- Surveys to voters and applicants
+- Surveys of voters and applicants
 - Voting behavior analysis
 - Social graph analysis
 - Reputation signals (contributions, usage, etc.)

sites/optimism/docs/governance/the-operating-manual/the-operating-manual.md

@@ -6,15 +6,15 @@ sidebar_label: The Operating Manual
 
 # The Operating Manual (v0.4.2)
 
-In this section we will describe the current governance proposal process of the Collective. It will evolve over time. The authoritative version is maintained [here](https://github.com/ethereum-optimism/OPerating-manual/blob/main/manual.md) on GitHub.
+In this section, we will describe the current governance proposal process of the Collective. It will evolve. The authoritative version is maintained [here](https://github.com/ethereum-optimism/OPerating-manual/blob/main/manual.md) on GitHub.
 
 ## Bicameral Governance
 
 The Collective is governed by two Houses:
 - **Token House** handles most formal governance processes: protocol upgrades, OP allocation, representative elections, and proposal approvals.
 - **Citizens’ House** governs the distribution of Retro Funding and can **veto** proposals like protocol upgrades and inflation changes to protect the Collective from plutocratic or short-sighted decisions.
 
-They were designed to serve different roles, and to check and balance each other’s influence.
+They were designed to serve different roles and to check and balance each other’s influence.
 
 | House | Who votes? | Main Responsibilities | Voting System | Veto Powers |
 |-------|------------|------------------------|----------------|--------------|
@@ -50,7 +50,7 @@ Most proposals follow a three-week cycle:
 
 - Week 3: Voting
     -  Voting lasts 7 days via Optimism Governance Portal (Token House) or Snapshot (Citizens’ House).
-    - Snapshot of voting power is taken at the start of the voting period.
+    - A snapshot of voting power is taken at the start of the voting period.
     - Quorum and approval thresholds depend on the Proposal Type.
 
 ## Veto Process
@@ -110,7 +110,7 @@ Experiments with Guest Voters are ongoing. The Citizen Attestation Schema tracks
 
 ![citizen-attestaion.png](img/citizens-attestation.png)
 
-Experiments follow this principles:
+Experiments follow these principles:
 - Measurable inputs + outcomes
 - Short feedback cycles
 - Reversibility (e.g. guest voter rounds)

sites/optimism/docs/governance/the-operating-manual/the-token-house.md

@@ -24,7 +24,7 @@ The Token House is responsible for voting on most governance proposals, includin
 - Governance procedures (elections, structure changes, ratifications)
 - Code of conduct violations or representative removals
 
-The Token House also participates in veto power when applicable—particularly over certain Citizens’ House proposals.
+The Token House also participates in veto power when applicable, particularly over certain Citizens’ House proposals.
 
 ## Governance Mechanism
 
@@ -54,13 +54,13 @@ Although the Token House formally approves proposals through on-chain voting, ex
 - Coordinating technical upgrades or disbursements
 - Communicating implementation status post-approval
 
-The Foundation operates as a steward, and is expected to decentralize its role over time.
+The Foundation operates as a steward and is expected to decentralize its role over time.
 
 ## Constitutional Alignment
 
 The Token House operates within the framework defined by the Working Constitution, which has the following principles:
 
-- **Governance minimization**: when multiple options achieve the same outcome, choose the least complex
+- **Governance minimization**: When multiple options achieve the same outcome, choose the least complex
 - **Forkability and exit**: collective freedom must be protected
 - **Anti-plutocracy**: token-based governance must be balanced by human-centric governance (Citizens)
 - **Impact = Profit**: proposals should aim to reward meaningful contributions to the ecosystem

sites/optimism/docs/interoperability/bye.md

@@ -67,7 +67,7 @@ Messages from unsafe blocks might later be invalidated during reorgs. Including
 <summary>Why is ETH never minted directly in the Superchain?</summary>
 
 
-All ETH originates from L1 and must be conserved. ETH is “burned” on the source chain via `ETHLiquidity.burn()` and “minted” on the destination chain via mint(), but this is really just moving pre-allocated liquidity.
+All ETH originates from L1 and must be conserved. ETH is “burned” on the source chain via `ETHLiquidity.burn()` and “minted” on the destination chain via mint(), but this is just moving pre-allocated liquidity.
 
 </details>
 
@@ -76,7 +76,7 @@ All ETH originates from L1 and must be conserved. ETH is “burned” on the sou
 <summary>What does it mean for a block to be 'cross-unsafe'?</summary>
 
 
-A cross-unsafe block has valid cross-chain messages, but the block itself or some dependencies are still unsafe. It’s part of the transition to ‘safe’, but not yet finalized.
+A cross-unsafe block has valid cross-chain messages, but the block itself or some dependencies are still unsafe. It’s part of the transition to ‘safe’, but not yet finalised.
 
 </details>