Hi Sam!
First of all, welcome to the Optimism Collective! 
I’m incredibly excited to see more and more teams from the Privacy space joining and contributing to improve the governance infrastructure and tooling at Optimism and solve for concerns that have been identified through rounds. Additionally, as more members of the Superchain and even ecosystems adjacent or that are part of the Optimism Collective are experimenting with their own RetroPGF rounds (which reduces the load for Optimism to shoulder the costs for all public goods in the ecosystem) this new build offers them more privacy as well.
Feedback:
From the four security guarantees that you mention I believe 4 is the least prone to materialize with the current design of the infrastructure/process, and would therefore encourage the prioritization of research to implement proof-of-exclusion to this build.
While bribery is a threat, Badgeholders currently are unable to successfully prove to someone that they voted in a specific direction; to do so, they would need to get their signed ballot from the Agora team or the Foundation, which would require a much more complex set up with multiple stakeholders across different groups with different interests. However, we have seen the importance of being able to verify that Badgeholders are not voting for their own projects/conflicts of interest.
Based on comments from our last Badgeholder meetup, the sentiment was that there is currently a healthy degree of trust in the Optimism Foundation as an operator, and while moving for a decentralized process is in the interest of the Collective as a whole (aligned with the goal to decentralize governance) it seems the more pressing matter is to solve for CoI’s verification.
Additionally, including new rules of enforcement for CoIs seems to be aligned with the incentives that are now in place for Badgeholders to report their CoI publicly, which means that the build will serve to double down on this requirement while preserving the integrity of the process (internally and externally).
EAS would probably be the best tool to register this data on chain with a specific schema, where if people need to update their CoI’s (as happened in the last round) MACI could just look at the latest attestation to generate the proof when validating the signed ballot. Given that the MACI team is already leveraging EAS to gate voting, it may be a low hanging fruit to explore including it into another circuit (maybe).
Questions:
- On “correct execution” would this build enable more complex calculations for distributions beyond “tallying the votes”? Or would what MACI enable is the building of a DataFrame as described here? Would an additional proof be required to ensure the right calculation was carried out, or is this proof of calculation contained in MACI?
As a Badgeholder, I’d also be interested in being a user-tester for the demo once it’s live. 