Spec for a privacy‑focused funding app using MACI

# Spec for a privacy‑focused funding app using MACI ## Context We are proposing a dedicated privacy round in the upcoming GG24 grants round. The round would use quadratic funding to allocate donations to privacy projects. Here is an [inital discussion](https://gov.gitcoin.co/t/the-case-for-privacy-gg24-maci-allo-capital/22491) for the domain we've started. Given the Ethereum ecosystem lacks robust and well-adopted privacy infrastructure, with the vast majority of actions happening transparently - this round proposal aims to specifically target privacy protocols to address this infrastructure and adoption gap. The underlying voting protocol for this round would be MACI, this aligns closely with the theme of a privacy project funding round. In the context of capital allocation, privacy is critical to enabling a fair process. This proposal outlines the requirements for a new web application that will host the privacy round. ## Project description The app will be a frontend application that allows donors to contribute to privacy projects and cast votes using MACI v2.5. It will need to integrate with some other logic for funding. This could be Gitcoin’s Allo grants stack for quadratic funding, or it could be maci-platform, a previously maintained frontend by the MACI team. Users will connect a wallet, sign up to the MACI contract and poll via specific [eligibility criteria](https://github.com/privacy-scaling-explorations/maci/tree/v2.5.0/packages/contracts/contracts/gatekeepers) (e.g. Gitcoin Passport), view a list of projects seeking funding, allocate voice credits across projects, and submit encrypted votes. After the voting period ends, the coordinator will finalise the poll, and publish and verify the proofs on‑chain. The app must display final funding allocations once the zero‑knowledge proofs have been verified and the funding logic has been applied. The app can take inspiration or re-use [allo-kit](https://github.com/allocapital/allo-kit), [maci-platform](https://github.com/privacy-scaling-explorations/maci-platform), or another frontend. There will be tradeoffs to each option, we should prioritise something simple. Any smart contract work should be minimised - we will allocate a small amount of budget for an audit. ## Participants Participants will include voters, project owners and a coordinator. Voters connect a wallet, pass the gatekeeper check and receive a fixed number of voice credits as defined by the `ConstantInitialVoiceCreditProxy` in MACI. A voter can distribute voice credits (votes) across multiple projects to signal their preferences. Project owners can register their projects during an application period, after approval they appear on the round page. The coordinator deploys the MACI contracts, generates the coordinator key, manages the poll configuration and processes the vote tally. This can be discussed further, but for this round, the MACI team can act as the coordinator, or the app developer building the frontend. The app should abstract these organiser tasks into separate pages on the frontend. For example, maci-platform handles this by showing different pages based on whether a connected wallet it that of the predetermined organiser. Tasks suchs as creating rounds, configuring poll durations and gatekeeper settings, and triggering finalisation should be done by the coordinator, via the maci CLI. The coordinator and organiser here are different entities, the organiser need only be an address responsible for accepting proposals. We cannot use the newer coordinator service since we are using MACI v2.5, which is not compatible with it. Once the final assigned voice credits are public, we will need to assign these votes to projects in order to distribute funds. ## Functional requirements **1. Round creation and configuration:** the coordinator will have to use the MACI CLI to organise the round. This includes creating a round, defining application and voting dates, choosing the gatekeeper, and specifying the number of voice credits per voter. We deploy a poll contract per proposal/poll, this can be done on proposal creation on the frontend. The frontend will need to reference exisitng MACI contracts - contract deployment should also be done by the coordinator. **2. Project application:** Project owners submit proposals (including info such name, description, funding address) and any authentication during the application phase. Organisers review and approve projects. **3. User sign‑up and authentication:** Voters connect their Ethereum wallet and sign a message to generate a maci key pair. The app invokes the selected gatekeeper contract to verify eligibility. Upon passing the gatekeeper, the voter is registered in the MACI state tree and receives voice credits. A user needs to sign up to the maci contract (deployed once), and also individual polls (also deployed once for this round, but can be deployed many times for a maci contract) - so there are two distinct sign up phases. **4. Voting:** During the voting period, the UI shows the list of approved projects, but due to the properties of MACI, cannot not show individual voter preferences. Users allocate their voice credits and submit their encrypted vote message. The frontend can inform users that they can change their vote once cast. The app will handle donations, the user donates ETH or stablecoins through the Allo, maci-platform, or other contracts - and the vote determines the allocation of matching funds. **5. Tally and results:** After the voting period ends, the coordinator merges sign‑ups and messages, and generates proofs. The coordinator will trigger this via the CLI. Once proofs are verified and results are posted on‑chain, the frontend fetches the final allocations and displays funding distribution and matching amounts to donors and project owners. ## Non‑functional considerations **Funding implementation** * While an integration with allo stack is possible. There is more logic built out of the box with maci-platform - importantly funding logic already built into the voting [contracts](https://github.com/privacy-scaling-explorations/maci-platform/blob/main/packages/contracts/contracts/maci/Tally.sol). Therefore for using the maci-platform has advanatges for simplicity. We leave this decision up to the developer however. * The maci-platoform funding logic is unaudited - as mentioned we would reserve funding ourselves (between Gitcoin and MACI) to pay for this. **Security and privacy:** * Only use audited MACI version (v3 won't be audited). Exception being maci-platform contracts as mentioned above. * Code should be open source. **Performance:** * Poll finalisation requires proof generation from the coordinator service - the UI should indicate progress and provide clear messaging that tallying may take some time. * Loading states and error handling should be robust **User experience:** * We want to make private voting as seamless as possible. The sign‑up process should guide users through wallet connection, Passport verification and voice credit allocation without jargon. * Informational pop ups can explain why MACI is used and how quadratic funding works. ## Deliverables The final deliverables will include a web application integrating MACI and the chosen option to distribute funding, supporting wallet connection, eligibility gating, project applications, vote casting, funds transfers, and results display. ## Why MACI v2.5 The latest audited version of the circuits is v2.5.0, and a trusted setup ceremony currently exists only for versions up to 2.x, so the app will use MACI v2.5 rather than the un‑audited v3. ### Examples of apps using MACI * https://github.com/privacy-scaling-explorations/maci-platform - quadratic voting but not supporting latest v3 MACI * https://github.com/privacy-scaling-explorations/maci-aragon-osx-gov-app - using latest maci but for full credit voting for a DAO vote, not QF * https://github.com/PriVote-Project/privote-frontend - uses latest maci but just for voting, not QF *The MACI team will be available to answer questions and support development.*