feat: governance permissionless proposals #260
Conversation
| # 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 `Top100DelegatesProposalValidator`. However, direct on-chain approvals are simpler, reduce errors, and avoid coordination overhead. |
There was a problem hiding this comment.
Figuring out exactly how to get these transactions onchain is one open question we need to address. Some options I can think of include:
- Chrome extension/bookmarklet to use within the forum
- Standalone local CLI or other tool which pulls data from a forum URL
- Standalone site which pulls data from forum URL
I suppose there are really two flows here -- submitting the proposal initially and then verifying it as a top delegate -- the former is probably harder, feels like we could do the latter with Etherscan, though verifiability that the forum post matches the onchain post is something to consider. Probably sufficient to be able to query size of the funds transfer as that's the most critical bit.
Notably we will need to support regular wallets and SAFEs here due to diversity of delegate wallets.
There was a problem hiding this comment.
Regarding the submission of the proposal, this can either happen through etherscan or Agora's UI.
For the approval of the proposal, by a top delegate, we suggest having this available through Agora's UI where they can display all the proposal data, that the delegate will be called to approve, by listening to an event that is being emitted when a proposal is successfully submitted.
There was a problem hiding this comment.
Let's discuss with Agora, but I concur with this approach. Given we want to do one through Agora and it's the same kind of data, probably makes sense to do both there.
| - **Intercept proposal submissions**: Provide functions such as `propose()` and `proposeWithModule()` that include pre-validation steps. | ||
| - **Delegate approval verification**: Require that a proposal submission gathers the sufficient delegate sign-offs before moving it for voting. These approvals will be validated by setting a minimum threshold of voting power that a delegate needs in order to approve, this threshold will be set by the manager along with the voting window. | ||
| - **Submission window check:** Ensure the proposal is submitted within a defined short window relative to the current voting cycle. (Type proposal check, this is not valid of all types of proposals) | ||
| - **Type-aware validation:** Confirm that the proposal meets any additional criteria based on its type (e.g. higher thresholds for larger OP grants) as defined in the `ProposalTypesConfigurator`. |
There was a problem hiding this comment.
Concretely, this is specified by the MVP tab here
There was a problem hiding this comment.
I think the most significant change implied by the above is to add a AttestationGatedProposal which verifies proposer is allowed based on e.g. an attestation by OF
There was a problem hiding this comment.
Yes, we agree, for verifying an approved proposer we will use an attestation that is attested by OP Foundation that defines these addresses for each proposal type.
|
|
||
| Delegate -->|submit DRAFT proposal| ForumDraft | ||
| Community -->|provide feedback| ForumDraft | ||
| ForumDraft -->|submit FINAL proposal with proposalId| ForumFinal |
There was a problem hiding this comment.
for some reason the proposald here is hidden in the markdown render
| FinalValidator[ProposalValidator] | ||
| OPGov[OPGov] | ||
|
|
||
| Proposer -->|propose| Validator |
There was a problem hiding this comment.
It seems like there is a tradeoff here between preventing a footgun where we validate certain things (e.g. OP amount) up front in this function call. However this does split validation logic between propose and moveToVote. Maybe that's fine, feels worth discussing briefly
There was a problem hiding this comment.
Another question is whether this two-step flow should exist for proposal types which do not require the two steps (e.g. Maintenance Upgrade Proposal can be validated/submitted immediately)
There was a problem hiding this comment.
We should "cut-off" any proposal that doesn't meet the requirements as soon as possible, so for the requested amount of OP we should have this check on submitting the proposal, while checks like approval by top delegates or voting cycle eligibility that can not be checked on submission should be validated when trying to move the proposal for voting.
Regarding the flow of proposal that dont require two steps (submission - move to vote) we should do both steps in one, meaning the moment the proposal is submitted it is also being move for voting.
* fix: design doc * fix: proposal voting type section * fix: purpose description * fix: grammar
|
|
||
| # Risks and Uncertainties | ||
|
|
||
| - **Proposal type flexibility**: The current design relies on a permissioned `ProposalTypesConfigurator` to define and update proposal types. This is acceptable for the MVP but introduces centralization risk. In the future, we’ll need a more permissionless or community-driven mechanism to support new proposal types without relying on a single role. |
There was a problem hiding this comment.
I still don't have clarity on whether we will shove this new stuff into ProposalTypesConfigurator, or leave that exclusively for "how we count votes" and have a new configurator for this layer
There was a problem hiding this comment.
I believe this first MVP can have them separated and maybe merge them in a following iteration
| # 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 `Top100DelegatesProposalValidator`. However, direct on-chain approvals are simpler, reduce errors, and avoid coordination overhead. |
There was a problem hiding this comment.
Let's discuss with Agora, but I concur with this approach. Given we want to do one through Agora and it's the same kind of data, probably makes sense to do both there.
| Delegate([Delegate]) -->|Submit DRAFT proposal| OPGov1[OPGov Forum] | ||
| Community([Community]) -->|Provide feedback| OPGov1 | ||
| OPGov1 -->|Submit FINAL proposal| OPGov2[OPGov Forum] |
There was a problem hiding this comment.
| Delegate([Delegate]) -->|Submit DRAFT proposal| OPGov1[OPGov Forum] | |
| Community([Community]) -->|Provide feedback| OPGov1 | |
| OPGov1 -->|Submit FINAL proposal| OPGov2[OPGov Forum] | |
| Delegate([Delegate]) -->|Submit DRAFT proposal| OPGov[OPGov Forum] | |
| Community([Community]) -->|Provide feedback| OPGov | |
| OPGov -->|`submitProposal()` once FINAL| OnchainGov[ProposalValidator] |
It should be this right? I see the same diagram you have now in figma, but I think just a typo, as the figma comment confirms "final == onchain"
|
@0xOneTony, the two open comments above, about what happens proposal types not in the table, and what happens to vetoes, they both need to be addressed in the design docs, not on the comments of this PR. Thanks :) |
…design doc (#23) * fix: add proposal is not approved case * fix: veto case mentioned
- Change propose(...) or moveToVote(...) Co-authored-by: Alberto Cuesta Cañada <[email protected]>
…n the design doc. (#24)
| ``` | ||
|
|
||
| 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(...)`. |
There was a problem hiding this comment.
A bit of a UX nit, but the "Approve Proposal" should only change to "Move To Vote" if ALL the conditions pass, 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".
The button should stay in "Approve Proposal" while all of "being submitted within the correct time window, not going over the distribution rate limit, and adhering to any proposal type-specific threshold" are met, but "having the required top 100 delegate approvals" is not.
If any of "being submitted within the correct time window, not going over the distribution rate limit, and adhering to any proposal type-specific threshold" are not met, the "Approve Proposal" button should be disabled, and the reason shown.
There was a problem hiding this comment.
"Approve Proposal" should only change to "Move To Vote" if ALL the conditions pass
That is what is going to happen. We can clarify that in the step. Working on it.
|
|
||
| | **Proposal Type** | **Description** | **Proposer** | **Proposal Voting Type** | **Submission Checks** | **Moving To Vote Checks** | | ||
| |-------------------------------|----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------|---------------------------------------|--------------------------|----------------------------------------------------------------------------------------------------------------------|--------------------------------------------------------------------| | ||
| | Protocol or Governor Upgrade | Scheduled changes to the on-chain smart contracts comprising the mainnet Optimism protocol or governance contract. | Any approved address by OP Foundation | Optimistic | - Input valid proposal type<br>- Proposer is an approved address<br>- No funds are transferred<br>- No state changes | - Gathered needed delegate approvals | |
There was a problem hiding this comment.
What does "No state changes" mean here?
Protocol Upgrades (and Maintenance Upgrade Proposals) change the state in the L1 smart contracts, which is something we want to restrict (hence the permissioned model).
Governance Fund (Missions) and Council Budget do not change the state of the smart contracts, beyond moving funds around. It makes sense that those can be made permissionless with checks on the amount not exceeding the OP cap. These we should also require that don't cause any state changes in any contracts except the OP Token contract.
There was a problem hiding this comment.
It means the proposal has an empty actions array and performs no on-chain calls that write storage or transfer assets. It’s signaling-only. Adding this to the design doc.
There was a problem hiding this comment.
In that case the design docs must be wrong. We have Protocol or Governor Upgrade and Maintenance Upgrade Proposals as "No state changes", and those two definitely do on-chain calls that write to storage.
Co-authored-by: Alberto Cuesta Cañada <[email protected]>
#25) * fix: improve proposal voting flow and UI feedback in permissionless proposals design doc * fix: clarify requirements for no state changes proposals in permissionless proposals design doc * fix: update proposer requirements and clarify UI feedback for proposal approval * fix: improve clarity on proposal approval conditions * fix: formatting * fix: formatting * fix: formatting
5 participants
Description
This document outlines the design for a step towards permissionless proposals in the Optimism governance system. The goal is to allow top delegates to submit a proposal on-chain without requiring prior approval or gatekeeping by the manager. Instead, if all automated gating rules are met, the proposal is submitted for voting.
This validation process is aimed to happen on-chain from a new contract that we introduce Top100DelegatesProposalValidator.