This is really insightful! thanks for sharing!
I think any proposal that will generate discussion and could lead to delegates either changing their minds after their vote , regardless of whether it’s a Yes/No vote or not. This is especially the case now that the voting system is in Beta and votes might be miscast.
The purpose of a voting platform should not be to change the behaviour of delegates, but simply to facilitate delegates to express their vote opinions as easily as possible. If someone wants to change their vote every 24 hours for no reason that is completely up to them, and the Social Layer should deal with this kind of behaviour, as opposed to Agora pre-emptively stopping these edge cases.
This is a very important point to mention, thanks @griff I forgot about it! If an offchain pre-vote was present then I wouldnt mind vote locking once it’s onchain, the problem here is that most of the time the real discussion happens once the voting cycle starts, and the current behaviour incentivises people to vote as late as possible to absorb the discussion.
I disagree with this. If the community decides that vote editing is disallowed, then that should be enforced on the tech layer if possible.
Snapshot enables vote editing, but it also enables blind voting. I’m not sure I am in favor of vote editing if everyone can see the vote in real time. I think this could potentially have adverse effects on how delegates vote and make decisions for the collective.
Also, any change in a voting platform changes the behavior of delegates. The voting platform should try to have the goal of neutrality (not shifting the collective towards any single decision), and fairness (however that is defined by us).
Thanks for opening this line of conversation @Oxytocin
Would we need to edit if we had more flexible off chain signalling mechanisms in advance of on chain commit?
Imo there are multiple positive benefits to introducing off-chain mechnisms including
- process improvements
- diversity of perspective
- accessibility as @lefterisjp mentions here
Current approval voting is a process where
-
Meeting quorum threshold - currently as few as three (3) delegates - removes the requirement for simple majority approval required under Yes/No
-
The general understanding of ‘Abstain’ - typically a mechanism to meet quorum, while remaining unconfirmed for any reason - is altered.
-
Unless a voter means to vote ‘no to all’ Abstain is a poor proxy for No.
-
We can not signal and capture where the collective diverges on individual proposals.
-
Once quorum threshold is met approval can not be challenged
I’d suggest that the need to edit is symptomatic of process issues. My suggestion to address the on-chain stage process is that even under omnibus conditions Yes No Abstain should be minimum available options for every individual funding approval to capture diversity and ensure majority support.
If the community had explicitly voted for this, then I would agree that you have a point, but as far as I know nowhere on the original implementation did we say that vote editing was disallowed. Right now, the only advantage I see from vote locking is fighting against a theoretical we have not seen before (unusual voting behaviour from delegates) in exchange for many lost compromises (no ability change to change one’s mind, voters waiting until the last minute for the choice, bugs cannot be amended, etc).
I would not mind if a proposal was made outlining specifically what delegate voting patterns we would endorse, of course. I’ll let others speak their mind about how we should go forward with this, but I think @lee0007 's idea of an offchain temp check could be a simple short-term solution to remove barriers to participation.
Hi, I was also wondering if it’s possible to add Delegate Name
to the Delegate information page (if we have that info)?
For example - I can see this delegate’s statement, but it’s hard to figure out who they are unless they linked a social profile: Optimism Agora
Hey there! It’s an idea that’s been brought up before, and definitely an issue I run into as an Agora user too. Our default approach has been trying to encourage folks to set up an ENS for their profile.
A name field would be easy to add, but I worry that it can lead to impersonation since there would be no way to verify the veracity of an address’ claim to be a specififc entity.
Makes me wonder if you could create a peer verification system.
Hey everyone – for those of you not following Github closely, we’ve been posting lots of progress updates on our work on both Gov v2 and RPGF UI. In the future, we’ll also be mirroring updates from these two github threads to this thread as well.
Any progress on the partial and fuzzy search for the platform?
I feel that would be very helpful prior to the distribution of tokens that may be coming in the future from optimism.
That way it’s really easy for people to find who they need when it’s time to delegate after a new AirDrop occurs.
I hope all is well with the agora team…!
Keep working your hardest. We appreciate you.
Hey folks – for those not following Github here, we just published some major updates on our two biggest workstreams: the RetroPGF integration as well as Governor v2. I’ll copy paste them below here:
RetroPGF integration
We just shipped the voting API today. It’s still in dev as we work through some kinks with the Supermodular team, who will be developing their frontend with this API. If you happen to poke around and find issues, please flag them to @stepandel or me .
Milestone | Delivery Date | Status |
---|---|---|
Lock in EAS schema and List architecture | August 18th, 2023 | |
Design and release API schema | September 1st, 2023 | |
Voting API launch | September 21st, 2023 | |
Launch discovery of projects, profile & lists** | October 6th, 2023 | |
Full launch (full feature list with voting) | October 19th, 2023 | |
Monitoring and support | Mid-October |
Coming up next:
Launch EAS indexer API for projects and lists up on Sep 29
Launch discovery of projects, profile & lists on Oct 6
Links here:
Dev endpoint
API Docs
Github repo
Governor v2
we just deployed a draft v2 contract for testing! We’re sharing this version with the community so that we can get folks to poke around, and provide feedback as early as possible. Disclaimer: this is NOT the final version, has not been audited, and should not be considered safe.
One area in particular that’s worth highlighting is our implementation of partial delegation as this was a particularly tricky challenge given we couldn’t upgrade the token. In short, it was important to us that users were able to use this feature without escrowing their tokens into a contract. To achieve this, our implementation accepts some significant tradeoffs when it comes to gas efficiency.
We’ve collaborated with many folks in this thread and in our network to arrive at this solution (thank you @apbendi and @gigamesh), have made many optimizations, and feel confident that we have strategies to manage around the gas cost such that the end user experience can be as seamless as possible. But of course, if you have more ideas here, we’d welcome any input!
Otherwise, please ping me or @jjranalli if you have questions.
Milestone | Delivery Date | Status |
---|---|---|
Publish smart contract design on Github | August 9, 2023 | |
Publish a draft smart contract code on Github for audit and community review | August 14th, 2023 | |
Deploy test contract to Optimism mainnet (updated) | September 21, 2023 | |
Launch new functionalities with beta users for testing | October 19th, 2023 | |
All new functionalities live in production | November 30th, 2023 |
Links:
governor: 0x1f9937F1505543916c790d3934d140Cc4B51C03c
votableSupplyOracle: 0xa881468900C0927ad2494963D57314C9a75d1572
proposalTypesConfigurator: 0xc0c4772d96F749e659401671Edd5bAEef58b48c9
alligator: 0x7B41BaF548A738b99F255c3EDCc0B67FCff3CDDc
Other updates
Hey @FractalVisions thanks for the update here! We’d love to have fuzzy search on Agora too. It’s been a personal pain point for me too. It’s taken a little bit as it’s actually a more complex feature than anticipated. We’ll make our first foray into fuzzy search with the launch of RetroPGF on Agora where you can fuzzy search projects. After that, we’ll leverage that work for delegates.
Just a quick update on the Advance Delegation Rollout Plan:
This will enable:
- Partial “Split” Delegation: Delegate to more than 1 person at a time. Instead of choosing A or B, you can delegate fluidly between multiple parties now!
- Re-delegation: Allow your delegate to delegate again to someone else. Helpful if they are on vacation or need to “pass the baton” for a smooth transition.
As always, if you have questions or feedback, please don’t hesitate to reach out!
I’ll share my thoughts on the great Advance Delegation Rollout Plan in the dedicated thread.
But, I have quick reflexion/feedback about the voting history stats in delegate profiles, currently showing something like “Proposals Voted 45 (23.20%)”. This % seems to reflect the total history of governance votes, which might not accurately represent the engagement of newer delegates.
Active delegates, even with a year+ of consistent involving&voting, could appear less involved due to this long-term only percentage. It’s a bit discouraging for new delegates…
Could we consider adding more nuanced stats, like voting percentages over the past year, since a delegate’s first vote, or since their delegate statement was registered onchain?
(Sorry if this question has already been addressed)
Hey OP Collective,
Kent here from Agora with our bi-weekly changelog.
Also, excited to announce a monthly Agora Office Hours (first one tomorrow). Office hours is open to the public and we encourage anyone who wants to come and meet some of the team, and let us know what is on your mind. We are excited to meet and connect! You can subscribe to the calendar here, Google Calendar link.
Have a great day everyone.
Morning OP Collective.
Kent here from Agora with our bi-weekly changlelog.
Let us know if you have any questions or concerns. We are here to serve.
Have a great day everyone.
Hey team!
I stumbled across this transaction which I believe is to @Agora from the Foundation for ~2.4 Million OP. OP Mainnet Transaction Hash (Txhash) Details | OP Mainnet Etherscan
In an effort for transparency, is this a payment for building out governance infrastructure? Or is it some kind of test of the partial delegation features?
I don’t remember seeing any kind of post about it. Thanks for the clarification! @zcf @lavande @yitong
Hey Michael - good eye! For transparency, this transaction was to let projects and individuals who’ve received grants vote with some portion of their funds.
The transaction you’ve identified was sent to a multisig controlled by the Foundation, and used advanced delegation (which is a new featured built by Agora) to make the process of bulk delegation easier to manage.
Agora does not control this address, and was not the recipient of these funds. Although I can see the potential confusion since yitong.eth did send some a bit of OP into this multisig for testing purposes when we were helping the Foundation set up this complex delegation schema.
Please let us know if we can provide any additional transparency!
Appreciate the quick response and the clarification!
Yeah I did see Yitong’s test transactions haha. Appreciate the good work!
I hope you’re doing well! Earlier this week, we started using the Agora API as an alternative data source for our platform. While working with the data, we noticed some discrepancies between Agora’s and Curia’s start and end dates for several proposals. To avoid potential confusion or misinformation for other platforms building on top of this data, I wanted to bring these to your attention.
Voting Cycle: Special Voting Cycle #12a
-
Proposal: Protocol Delegation Program Renewal
- Agora: April 7, 2023 – April 7, 2023
- Curia: April 27, 2023 – May 11, 2023
View Proposal
-
Proposal: Intent #3 Budget Proposal
- Agora: April 7, 2023 – April 7, 2023
- Curia: April 27, 2023 – May 11, 2023
View Proposal
-
Proposal: Intent #2 - Council Intent Budget Proposal
- Agora: April 7, 2023 – April 7, 2023
- Curia: April 27, 2023 – May 11, 2023
View Proposal
-
Proposal: Intent #4 Budget Proposal
- Agora: April 7, 2023 – April 7, 2023
- Curia: April 27, 2023 – May 11, 2023
View Proposal
-
Proposal: Intent #1 Budget Proposal
- Agora: April 7, 2023 – April 7, 2023
- Curia: April 27, 2023 – May 11, 2023
View Proposal
Voting Cycle: Special Voting Cycle #12b
-
Proposal: Inflation Adjustment Proposal
- Agora: May 4, 2023 – May 5, 2023
- Curia: May 18, 2023 – May 31, 2023
View Proposal
-
Proposal: Council Reviewer Elections: Growth Experiments Grants
- Agora: May 5, 2023 – May 5, 2023
- Curia: May 18, 2023 – May 31, 2023
View Proposal
-
Proposal: Treasury Appropriation (Foundation Year 2 Budget Approval)
- Agora: May 4, 2023 – May 5, 2023
- Curia: May 18, 2023 – May 31, 2023
View Proposal
-
Proposal: Council Reviewer Elections: Builders Grants
- Agora: May 5, 2023 – May 5, 2023
- Curia: May 18, 2023 – May 31, 2023
View Proposal
Voting Cycle: Voting Cycle 11
- Proposal: Upgrade Proposal: Bedrock
- Agora: January 30, 2023 – January 30, 2023
- Curia: March 23, 2023 – April 5, 2023
View Proposal
- Proposal: Delegate Suspension: Fractal Visions
- Agora: January 30, 2023 – January 30, 2023
- Curia: March 23, 2023 – April 5, 2023
View Proposal
We believe it’s important to fix this issue as soon as possible to prevent misinformation on other platforms using this data. Ensuring accurate and consistent data is crucial for the governance ecosystem, especially for platforms building on top of the Agora API.
Please feel free to reach out if you need more details. Thank you for your attention to this, and we appreciate the great work from the team so far!
Thanks for reporting! DM’ing you to investigate