fix: language to match manual

governance/permissionless-proposals.md

@@ -8,7 +8,7 @@ We propose introducing a `ProposalValidator` contract that sits in front of the
 
 # Problem Statement + Context
 
-The current process, per the [**Operating Manual v0.4.2**](https://github.com/ethereum-optimism/OPerating-manual/blob/main/manual.md), involves proposals being drafted on the forum, receiving delegate approvals (explicit sign-offs from four of the top 100 delegates), and then being submitted for a vote during a specific voting cycle. The existing flow is partially off-chain and manually enforced: delegates post drafts in the forum, approvals are coordinated in the comments, and a designated manager is responsible for calling the Governor to formally start the voting cycle.
+The current process, per the [**Operating Manual v1.0.0**](https://github.com/ethereum-optimism/OPerating-manual/blob/main/manual.md), involves proposals being drafted on the forum, receiving delegate approvals (explicit sign-offs from four of the top 100 delegates), and then being submitted for a vote during a specific voting cycle. The existing flow is partially off-chain and manually enforced: delegates post drafts in the forum, approvals are coordinated in the comments, and a designated manager is responsible for calling the Governor to formally start the voting cycle.
 
 We need to replicate this process on-chain so that:
 
@@ -24,8 +24,8 @@ At a high-level, we propose the creation of a `ProposalValidator` contract that
 - **Intercept proposal submissions**: Provide functions such as `submitProposal()` and `moveToVote()` that ensure a proposal is correctly validated before moving to the governor.
 - **Proposer Role:** This is the address that initiates a governance proposal. There are two classes of proposers, depending on the proposal type:
   - **Approved Proposer:** An address that has been explicitly attested, by the OP Foundation, as eligible to submit a given proposal type. These proposers must hold an on-chain attestation that confirms they are authorized to submit proposals of a specific `ProposalType`. This model is used for sensitive categories like protocol upgrades or elections, where tighter permissioning is necessary.
-  - **Permissionless Proposer:** Any address may submit a proposal (no attestation required) as long as the proposal type allows it. In this case, the proposer must gather the required number of sign-offs (from top 100 delegates) before calling `moveToVote(...)`. This model is used for more open categories like the Governance Fund and Council Budget, supporting broader community participation.
-- **Delegate approval verification**: Require that a proposal submission gathers sufficient delegate sign-offs before moving it for voting through the Agora UI. These approvals will be validated by setting a minimum threshold of voting power that a delegate needs to approve. This threshold will be set by the manager along with the voting window. This check will also happen for the specific proposal types that are shown below.
+  - **Permissionless Proposer:** Any address may submit a proposal (no attestation required) as long as the proposal type allows it. In this case, the proposer must gather the required number of approvals (from top 100 delegates) before calling `moveToVote(...)`. This model is used for more open categories like the Governance Fund and Council Budget, supporting broader community participation.
+- **Delegate approval verification**: Require that a proposal submission gathers sufficient delegate approvals before moving it for voting through the Agora UI. These approvals will be validated by setting a minimum threshold of voting power that a delegate needs to approve. This threshold will be set by the manager along with the voting window. This check will also happen for the specific proposal types that are shown below.
 - **Move to Vote window check:** Ensure the proposal is forwarded to the Governor within a defined short window relative to the current voting cycle. (Submission window checks may not apply to all `ProposalTypes`).
 - **Proposal Voting Type Validation:** Each proposal must be validated to ensure it uses the correct voting configuration as defined by the ProposalTypeConfigurator. This includes verifying the appropriate voting system (e.g., approval voting, ranked choice, optimistic)
 - **No-ops checker:** This will be a guard that ensures non-executable proposals (those with no on-chain actions) do not execute OP transfers.
@@ -47,7 +47,7 @@ Each proposal type and their validation steps are detailed in the following tabl
 The general workflow would be:
 
 1. **Draft Proposal:** A delegate starts by creating a Draft proposal and posting it on the optimism governance forum. At this stage, the proposal is open to the entire community for feedback. 
-2. **Proposal Finalization**: After the proposal has been drafted and shared on the forum, delegates provide feedback, ask clarifying questions, and propose changes. Once the delegate incorporates this input and the proposal is refined, the delegate updates its status to "Final Draft". At this point, the delegate must create an on-chain transaction to create the proposal metadata record in the `ProposalValidator` by calling `submitProposal()`, which can be done either through Etherscan or Agora UI. This call emits a `ProposalSubmitted` event, which includes the `proposalId` and other relevant data. Agora listens for this event and uses it to fetch and display the finalized proposal on its UI, allowing delegates to begin the sign-off process.
+2. **Proposal Finalization**: After the proposal has been drafted and shared on the forum, delegates provide feedback, ask clarifying questions, and propose changes. Once the delegate incorporates this input and the proposal is refined, the delegate updates its status to "Final". At this point, the delegate must create an on-chain transaction to create the proposal metadata record in the `ProposalValidator` by calling `submitProposal()`, which can be done either through Etherscan or Agora UI. This call emits a `ProposalSubmitted` event, which includes the `proposalId` and other relevant data. Agora listens for this event and uses it to fetch and display the submitted proposal on its UI, allowing delegates to begin the approval process.
 
 ```mermaid
 flowchart LR
@@ -56,9 +56,9 @@ flowchart LR
     OPGov -->|submitProposal once FINAL| OnChainGov[ProposalValidator]
 ```
 
-3. **On-chain Sign-Offs via Agora**: With the final proposal ready, the top 100 delegates can start signing-off on the on-chain proposal using the `proposalId` through Agora. Their sign-offs are recorded via the `approveProposal(...)` function in the `ProposalValidator` contract, that emits a `ProposalApproved` event. Agora will display the real-time signature status for each proposal.
-4. **Move to vote via** `ProposalValidator`**:** Once the required number of sign-offs is reached, the "Approve Proposal" button in Agora changes to "Propose". Any user can click this button to call `moveToVote(...)` on the `ProposalValidator`. If the proposal meets the necessary rules, such as having the required top 100 delegates sign-offs, being submitted within the correct time window, not going over the distribution rate limit, and adhering to any proposal type-specific threshold it will be moved to the Governor for voting. This is done by internally calling `proposeWithModule(...)` **within `moveToVote(...)`.
-5. **Governor:** If the `ProposalValidator` checks that the proposal is valid, it forwards the proposal to the OP Governor contract. Then, the voting time begins as usual.
+3. **On-chain approvals via Agora**: With the final proposal submitted, the top 100 delegates can start approving the on-chain proposal using the `proposalId` through Agora. Their approvals are recorded via the `approveProposal(...)` function in the `ProposalValidator` contract, that emits a `ProposalApproved` event. Agora will display the real-time signature status for each proposal.
+4. **Move to vote via** `ProposalValidator`**:** Once the required number of approvals is reached, the "Approve Proposal" button in Agora changes to "Move To Vote". Any user can click this button to call `moveToVote(...)` on the `ProposalValidator`. If the proposal meets the necessary rules, such as having the required top 100 delegate approvals, being submitted within the correct time window, not going over the distribution rate limit, and adhering to any proposal type-specific threshold it will be moved to the Governor for voting. This is done by internally calling `proposeWithModule(...)` **within `moveToVote(...)`.
+5. **Governor:** If the `ProposalValidator` checks that the proposal is approved, it forwards the proposal to the OP Governor contract. Then, the voting time begins as usual.
 
 ```mermaid
 flowchart LR
@@ -79,9 +79,9 @@ Detailed flows for each Proposal Type can be seen [here](https://www.figma.com/b
 
 # Alternatives Considered
 
-- **Permissioned voting cycle configuration**: As an MVP, we allow a permissioned role to set the voting cycle and delegate approval thresholds. While not fully decentralized, this is acceptable given OF’s existing veto power. A future improvement could use an optimistic oracle to fetch these values on-chain, but this adds complexity we don’t believe is needed yet.
-- **Forum sign-offs with signature verification**: The current process relies on forum comments from top delegates as attestations. We considered maintaining this model, where proposers collect these off-chain signatures and verify them in the `ProposalValidator`. However, direct on-chain approvals are simpler, reduce errors, and avoid coordination overhead.
-- **On-chain sign-offs initiated from the Forum**: An alternative flow would be to allow sign-offs to begin directly from the forum once a proposal is marked as “Final Draft.” In this model, delegates would click a “Approve Proposal” button embedded in the forum interface. Once the required number of sign-offs is collected, any user could call `propose(...)`. While feasible, this option creates more fragmented UX across governance tools and adds complexity for users interacting with the proposal lifecycle. We opted for Agora as the source of truth to unify coordination and finalization into a single interface.
+- **Permissioned voting cycle configuration**: As an MVP, we allow a permissioned role to set the voting cycle and delegate approval thresholds. While not fully decentralized, this is acceptable given OP Foundation’s existing veto power. A future improvement could use an optimistic oracle to fetch these values on-chain, but this adds complexity we don’t believe is needed yet.
+- **Forum approvals with signature verification**: The current process relies on forum comments from top delegates as attestations. We considered maintaining this model, where proposers collect these off-chain signatures and verify them in the `ProposalValidator`. However, direct on-chain approvals are simpler, reduce errors, and avoid coordination overhead.
+- **On-chain approvals initiated from the Forum**: An alternative flow would be to allow approvals to begin directly from the forum once a proposal is marked as “Final”. In this model, delegates would click a “Approve Proposal” button embedded in the forum interface. Once the required number of approvals are collected, any user could call `propose(...)`. While feasible, this option creates more fragmented UX across governance tools and adds complexity for users interacting with the proposal lifecycle. We opted for Agora as the source of truth to unify coordination and finalization into a single interface.
 - **Constant Voting Power Threshold**: Another option considered for identifying if an approver is in the top 100 delegates was to define a minimum threshold of voting power, set by OP Foundation, and check if the caller has more voting power than the threshold. However, it was decided to use the Dynamic Attestation Service that updates the top 100 delegates automatically every day.
 
 # Risks and Uncertainties