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.
| - **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
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.