Last updated 3 months ago
Developers and DAOs on lack a private, verifiable voting DApp; existing on‑chain voting exposes voter identities and choices, enabling coercion and undermining Midnight’s privacy goals.
OpenVote is a Compact‑based reference DApp that lets DAOs run private, verifiable votes on Midnight using real ZK proofs, with one‑wallet‑one‑vote, time‑limited proposals, and public tallies only.
Please provide your proposal title
Veil Protocol - Midnight Vote and DAO Management Platform
Please specify how many months you expect your project to last
3
Please indicate if your proposal has been auto-translated
No
Original Language
en
What is the problem you want to solve?
Developers and DAOs on lack a private, verifiable voting DApp; existing on‑chain voting exposes voter identities and choices, enabling coercion and undermining Midnight’s privacy goals.
Supporting links
Does your project have any dependencies on other organizations, technical or otherwise?
No
Describe any dependencies or write 'No dependencies'
No dependencies
Will your project's outputs be fully open source?
Yes
Please provide here more information on the open source status of your project outputs
MIT
Please choose the most relevant theme and tag related to the outcomes of your proposal
Governance
What is useful about your DApp within one of the specified industry or enterprise verticals?
OpenVote primarily targets the governance vertical by providing a concrete, production‑style example of how to run private, verifiable decision‑making on Midnight without sacrificing transparency or fairness. In most existing DAO and protocol governance systems, every vote is fully public: wallet addresses, voting choices, and often timing can be inspected by anyone. This makes it easy to audit tallies, but it also introduces strong disincentives for honest participation. Whales can pressure delegates, employers can infer an employee’s stance, rivals can retaliate for controversial votes, and entire communities can be discouraged from voting against dominant narratives because their on‑chain preferences will follow them forever. For a data‑protection chain like Midnight, this “everything is public by default” model is misaligned with the core value proposition: programmable privacy.
It demonstrates a different pattern that is only realistically possible on a chain like Midnight. The DApp allows communities to create proposals with clear start and end times, and lets eligible participants vote using real zero‑knowledge proofs rather than plain transactions that expose addresses and raw inputs. The smart contract verifies that the rules are satisfied (for example, “this wallet has not already voted on this proposal”, “this wallet is part of the allowed voter set”) without learning who the voter is or what they chose. Only the aggregated tallies are public. As a result, governance outcomes remain fully auditable at the level that matters—total Yay vs Nay for each proposal and confirmation that the vote followed the rules—while the sensitive metadata that could be used to coerce, shame, or deanonymize voters stays protected.
From an industry perspective, this pattern is useful well beyond token‑voting DAOs. Any organization that needs to collect sensitive preferences or decisions but also prove fairness can reuse this architecture. Examples include: private committee votes, university or research board decisions, employee surveys where anonymity must be preserved, or even civic‑style experiments such as community budgeting. OpenVote shows how those workflows can be implemented without standing up proprietary infrastructure: the same compact contract and proof flow can be parameterized for many environments. By anchoring these capabilities on Midnight, the project also underlines how the network’s privacy guarantees and proof tooling can be applied to real governance processes rather than just simple demos.
In addition, OpenVote helps bridge the gap between web‑native DAOs and more traditional organizations. Many entities are reluctant to adopt blockchain‑based governance because they cannot expose internal voting data and sensitive strategic questions on a fully public ledger. OpenVote provides a credible template in which only the high‑level results are visible while individual votes and identities are kept private, making it easier for these organizations to experiment with decentralized decision‑making on Midnight. In short, the DApp is useful because it converts privacy from an abstract platform feature into a tangible governance building block that projects can adopt immediately, while also serving as a reference implementation for any vertical that requires trusted yet confidential collective decision‑making.
What exactly will you build? List the Compact contract(s) and key functions/proofs, the demo UI flow, Lace (Midnight) wallet integration, and your basic test plan.
The project will deliver a full reference stack for private voting on Midnight, consisting of Compact contracts, real zero‑knowledge circuits, a web UI, wallet integration, and a documented testing approach. At the core is a single main Compact contract (for example voting.compact) that defines the public and private state of the system. The public state includes the list of proposals, for each proposal its metadata (title, description hash, creator, start and end times), and the running vote tallies (Yay and Nay counts). The private state keeps track of which wallet identities have already voted on which proposals in a way that is not directly observable from the chain. Associated ZK circuits enforce three main rules: a voter is eligible, a voter has not yet voted on the proposal, and the submitted choice is well‑formed. The contract exposes entrypoints for creating proposals, submitting a private vote with an attached proof, and finalizing a proposal once the deadline has expired.
On top of this, the project will implement a React + TypeScript frontend that guides users through the full governance flow. There will be a “Create Proposal” screen where a connected wallet can define a title, description, and voting duration expressed in blocks or timestamps, and then submit a transaction via the contract bindings. A “Proposals” view lists all active and past proposals, showing their status, remaining time, and tally (for completed votes, the final result). Each proposal has a detail page where the user can see the description and choose to vote Yay or Nay. When a vote is cast, the frontend talks to a Dockerized proof server that generates the appropriate ZK proof in the browser or via a local service, then submits the resulting proof and encrypted vote to the contract. Throughout this process, the UI surfaces clear loading and error states (waiting for wallet, proof generation failure, vote already cast, proposal expired, etc.) and live‑updates tallies as new blocks are observed.
For wallet integration, the DApp will rely on Lace (Midnight) as the primary wallet. The web client detects and connects to Lace, requests permission to use the account, and then signs transactions using Midnight.js or equivalent SDKs. The app will be configured for Midnight testnet endpoints, and environment variables will let developers or deployers switch RPC configuration if needed. The architecture is designed such that all sensitive information—such as the link between a wallet and a specific proposal vote—is handled via proofs and private state, not exposed directly in normal transaction data. This demonstrates recommended patterns for wallet‑level privacy on Midnight, showing developers how to manage keys, proofs, and state while preserving user anonymity.
The project will also ship a basic but meaningful test plan. On the contract side, unit tests will cover creating proposals, rejecting malformed parameters, enforcing deadlines, and applying vote tally updates correctly. Additional tests will simulate duplicate votes, attempts to vote after a deadline, and proofs that fail eligibility checks. On the integration side, scripts and/or automated tests will spin up the proof server, deploy the contract to a local or testnet environment, and run multi‑wallet scenarios: one script creates a set of proposals; another script simulates several voters casting valid votes; a third script tries invalid behaviors (double voting, voting with wrong proposal IDs, or using malformed proofs) and asserts that they are rejected. Manual testing guidance will be documented for reviewers and developers to reproduce these flows on Midnight testnet. Together, these elements form a complete, realistic example that others can fork and adapt while trusting that the core logic has been exercised and validated.
How will other developers learn from and reuse your repo? Describe repo structure, README contents, docs/tutorials, test instructions, and extension points. Which developer personas benefit, and how will you gauge impact (forks, stars, issues, remixes)?
OpenVote is intentionally structured as a teaching and reuse‑friendly repository rather than a one‑off hack. At the top level, the repo will clearly separate concerns into directories such as contract/ (for Compact code and circuits), frontend/ (for React/TypeScript UI), and infra/ or zk/ (for proof‑server configuration and Docker files). Within the contract folder, the voting.compact file will include comments explaining each type, state field, and transition, focusing on how private state and zero‑knowledge constraints implement one‑wallet‑one‑vote and eligibility checks. Developers can read this file to see exactly how Midnight’s privacy features are used in a real DApp rather than a trivial example.
The root README will act as a step‑by‑step guide. It will start with a high‑level overview of the problem and architecture, then list prerequisites (Node.js, Docker, Lace wallet, access to Midnight testnet) and detailed setup instructions. These include commands to install dependencies, start the proof server, compile the Compact contract, generate TypeScript bindings, deploy to testnet, configure environment variables (such as RPC URLs and contract address), and finally start the frontend dev server. The README will also link to deeper documentation in a docs/ folder, where topics like “How the ZK proofs work in this project”, “Understanding the private state model”, and “Adapting OpenVote for your own DAO” are covered in more depth. Short tutorials may walk through common modifications—for instance, switching from binary Yay/Nay votes to multiple options, or restricting eligible voters to a specific list of addresses or roles.
For test instructions, the repository will include scripts such as npm run test:contract and npm run test:integration, with explanations in both README and docs. These scripts will run local or testnet scenarios and produce logs that clearly show which behaviors are being validated. Example test vectors (sample proposal IDs, timestamps, and expected tallies) will be provided, along with guidance on how to inspect transactions on a Midnight explorer without compromising the intended privacy properties. This makes the repo not just an artifact to run, but also a teaching resource for best practices in testing privacy‑sensitive contracts and flows.
Several developer personas benefit directly. Compact and backend engineers gain a concrete example of modeling private vs public state and embedding ZK circuits into a contract. Frontend developers and full‑stack engineers see how to integrate Lace wallet, handle asynchronous proof generation, and build user‑friendly flows on top of privacy‑preserving infrastructure. Educators and technical writers can reference the project in workshops, tutorials, and hackathons as a canonical pattern for Midnight governance. Even auditors and security reviewers can use the codebase as a reference when evaluating other private‑voting implementations.
To gauge impact and reuse, the project will rely on transparent public metrics and qualitative feedback. On GitHub, forks, stars, and external issues or pull requests will be tracked as indicators that other teams are using or improving the code. References to OpenVote in other Catalyst proposals, hackathon submissions, or ecosystem documentation will also be monitored. Within the Midnight and Cardano developer communities, feedback channels such as Discord or forum posts can be used to collect reports from projects that adopted or adapted the pattern. Over time, the goal is to see a growing set of DAOs and applications that either directly fork the OpenVote repository or implement similar architectures while crediting it as inspiration, demonstrating that the DApp has become a genuine “reference implementation” for private, verifiable voting on Midnight.
Please describe your proposed solution and how it addresses the problem
OpenVote solves the problem of unsafe, fully transparent on‑chain voting by delivering a complete private‑governance reference DApp built specifically for Midnight. The core idea is to let DAOs, protocols, and communities make binding decisions where everyone can verify the final tallies and rules, but no one can see who voted for what, or even which addresses participated. To achieve this, the solution combines a Compact smart contract, real zero‑knowledge proofs, a Dockerized proof server, and a modern React/TypeScript frontend integrated with the Lace wallet, all wired together in a way that other builders can easily understand, run, and extend.
At the smart‑contract level, OpenVote defines a clear separation between public and private state. The public state stores proposals, including their titles, description hashes, creators, start times, and deadlines, along with the running Yay and Nay tallies that the community can inspect at any time. The private state, managed by Midnight’s data‑protection architecture, tracks which logical voters have already participated in each proposal. Zero‑knowledge circuits are used to prove that a voter is eligible and has not already voted on that proposal, without revealing their wallet address or vote choice. When a vote is submitted, the contract verifies the proof, updates the tallies, and records in private state that this voter has used their one vote, but no external observer can link that update to a specific identity. This is how the solution addresses coercion and retaliation risks while preserving the integrity of the process.
On the user‑experience side, the project provides a full governance flow that mirrors what DAOs and communities already expect, but with Midnight’s privacy properties embedded by default. A “Create Proposal” screen allows authorized users to define a proposal’s title, text, and duration, then send a transaction through Lace that creates the proposal on‑chain. A “Proposals” view lists active and closed proposals, showing the current status and tallies, and lets users drill down into a detailed page for each proposal. From there, a voter connects their Lace wallet, chooses Yay or Nay, and triggers the ZK proof generation process. The frontend communicates with a Dockerized proof server to construct the proof locally, then submits it along with the encrypted vote to the Compact contract. Throughout this workflow, the app surfaces clear progress indicators and error states—such as “already voted”, “proposal closed”, or “proof server not reachable” so that even non‑technical users can understand what is happening without needing to know the mathematics behind ZK proofs.
The solution has been designed from the outset as a reusable reference DApp, not a one‑off demo. All components are structured to be understandable and extensible: the Compact contract is written with descriptive comments, the TypeScript interaction layer exposes strongly typed methods for calling contract entrypoints, and the frontend components are modular so that developers can replace the design system or embed the voting widgets into their own dashboards. A comprehensive README and doc set explain the architecture, the privacy model, deployment steps, configuration options, and the main extension points. Examples include how to adapt OpenVote for token‑weighted voting, how to restrict proposals or voting to specific groups, or how to add additional options and quorum rules. This documentation focus ensures that the solution does not just address your own project’s needs but also lowers the barrier for the entire Midnight ecosystem to adopt private governance patterns.
From an operational standpoint, OpenVote also addresses reliability and maintainability concerns that often block adoption of privacy‑heavy systems. The project includes scripts and test plans for deploying the contract and proof server to Midnight testnet, seeding sample proposals, and simulating realistic voting scenarios with multiple wallets. These tests cover both happy‑path usage and adversarial behaviors like double‑voting attempts, off‑deadline voting, or malformed proofs. By publishing these tests and expected behaviors, the solution gives reviewers, auditors, and integrators high confidence that the voting logic does what it claims, and that regressions can be caught early if the codebase is modified. Ultimately, OpenVote addresses the original problem unsafe, fully transparent governance by giving Midnight a battle‑tested, open‑source blueprint for private, verifiable voting that any DAO, community, or application team can fork, adapt, and deploy.
Please define the positive impact your project will have on Midnight ecosystem
OpenVote is designed to have a broad, long‑lasting positive impact on the Midnight ecosystem by turning private governance from a theoretical feature into a ready‑to‑use building block. Today, many DAOs and projects either avoid on‑chain governance or accept fully transparent voting because building a robust private system is complex and time‑consuming. By delivering an open‑source, production‑style reference DApp that uses real zero‑knowledge proofs and Compact contracts, OpenVote gives Midnight a concrete example that any team can fork, audit, and adapt, dramatically lowering the barrier for adopting privacy‑preserving decision‑making on the network.
First, the project strengthens Midnight’s value proposition as a data‑protection chain. Marketing materials and technical docs often highlight programmable privacy as a differentiator, but developers and stakeholders need tangible examples to understand what that means in practice. OpenVote showcases a clear, intuitive use case secret ballots with verifiable public tallies—that resonates with DAOs, enterprises, and communities alike. When a team can see and use a live DApp where voters remain anonymous while the process stays fully auditable, it becomes much easier to justify building on Midnight instead of on a transparent smart‑contract platform. This helps attract new projects, especially those dealing with sensitive coordination, such as internal protocol parameters, hiring decisions, or experimental forms of civic governance.
Second, the DApp serves as a reference implementation and learning tool for the entire developer community. Compact contracts, private state, and ZK proofs have a learning curve; many builders are comfortable with EVM‑style public contracts but unsure how to design with privacy in mind. OpenVote provides them with a thoroughly documented blueprint: how to model public vs private state, how to structure circuits that enforce one‑wallet‑one‑vote, how to integrate a proof server, and how to handle UX around proof generation and error cases. Hackathon participants, new ecosystem teams, and even university courses can use this repository as a starting point. As more developers learn these patterns, the overall quality and sophistication of Midnight DApps improves, leading to richer use cases and a stronger ecosystem flywheel.
Third, OpenVote acts as a reusable component for other projects. Instead of every DAO or protocol implementing its own bespoke voting system, teams can plug in OpenVote or adapt it with minimal changes. For example, a DeFi protocol could use OpenVote to run parameter votes; an NFT community could use it to manage treasury allocations; a research collective could use it for grant approvals. Because the codebase is open and permissively licensed, these teams can fork it, modify eligibility logic, add token‑weighting, or extend it with delegation and quorum rules. This reuse reduces duplicated engineering effort, shortens time‑to‑launch for governance features, and encourages consistent, battle‑tested patterns across the ecosystem.
Finally, the project provides measurable signals of Midnight’s growth and impact. Metrics such as the number of forks and stars of the OpenVote repository, the count of independent deployments and active proposals on testnet and mainnet, and the number of distinct wallets that participate in votes can all serve as concrete indicators of ecosystem engagement. Feedback from DAOs and community managers will inform future improvements to the stack and guide additional reference DApps in other categories (for example, private attestations or selective‑disclosure identity flows). In this way, OpenVote is not just a single application but a strategic investment in Midnight’s governance, developer education, and reputation as the go‑to chain for serious privacy‑preserving coordination.
What is your capability to deliver your project with high levels of trust and accountability? How do you intend to validate if your approach is feasible?
The OpenVote project is designed around a realistic assessment of what can be delivered by a small, experienced team within three months, and the plan explicitly reflects that. The lead builder has strong practical experience with smart contract development, full‑stack web engineering, and privacy‑oriented DApp design across EVM and newer ecosystems, including Compact and Midnight‑style tooling. This includes past work on production‑grade DeFi and governance projects, familiarity with wallet integrations, and hands‑on experience shipping TypeScript/React applications backed by Dockerized infrastructure and automated deployment flows. That combination of backend, frontend, and dev‑ops skills reduces coordination overhead and makes it feasible for a compact team to own the entire stack end‑to‑end contracts, proof server, web UI, and documentation without outsourcing core tasks.
The project’s feasibility also comes from the way the work is structured into three focused milestones: (1) Compact contract and ZK logic, (2) frontend and wallet integration, and (3) documentation and test hardening. Each milestone has concrete, verifiable outputs and clear acceptance criteria, such as a deployed testnet contract address, working proof generation, and recorded voting demos. This structure ensures that at the end of each month there is a usable, testable increment of the system, reducing delivery risk and allowing for early feedback from the Midnight community. Because OpenVote builds on existing Midnight tooling Compact language, Midnight.js, Lace wallet, and recommended proof‑server patterns it does not depend on unproven infrastructure or external vendors. The only external requirements are access to Midnight testnet and standard open‑source libraries, which keeps the risk profile low.
To validate that the approach is feasible and trustworthy, the team will rely on transparent, repeatable testing and open development practices. All code will live in a public repository under a permissive license, with issues, milestones, and pull requests used to track progress. Automated and manual tests will cover the most critical behaviors: one‑wallet‑one‑vote enforcement, correct handling of deadlines, rejection of invalid proofs, and resilience of the frontend when the proof server or network has transient errors. Test instructions and scripts will be documented so that reviewers, auditors, and other developers can reproduce the scenarios on Midnight testnet using their own wallets. In addition, the project will share progress updates and solicit feedback from Midnight and Cardano developer channels as each milestone is completed, using that input to refine UX and technical choices. This combination of relevant experience, staged delivery, reliance on existing Midnight infrastructure, and open, test‑driven development gives strong confidence that OpenVote can be delivered on time with the level of trust and accountability expected for a reference governance DApp.
Please provide a cost breakdown of the proposed work and resources
The requested budget for OpenVote is USDM 10,000 over three months, aligned with the Midnight: Compact DApps funding range and sized for a small, highly technical team focusing on core engineering, testing, and documentation rather than marketing or non‑technical activities. The budget is distributed evenly across the work phases with additional weight on the final reference‑packaging stage: Milestone 1 (Smart Contract & ZK Infrastructure) – USDM 3,000; Milestone 2 (Frontend, Wallet Integration & UX) – USDM 3,000; Milestone 3 (Documentation, Test Suite & Reference Packaging) – USDM 4,000. This breakdown reflects that the first two months are primarily intensive development and integration work, while the final month combines ongoing coding with time‑consuming writing, testing, and polish needed to make OpenVote a high‑quality reference DApp for other builders.
Each budget line maps directly to eligible cost categories such as smart contract engineering, frontend development, proof‑server and infrastructure configuration, testnet deployment, and preparation of developer documentation and tutorials. There are no allocations for external agencies or non‑technical overhead; the same core builder(s) who design and implement the system are responsible for delivering milestones, which improves accountability and reduces management layers. Milestone 1 covers design and implementation of the Compact contract, zero‑knowledge circuits, and deployment scripts, as well as initial internal testing. Milestone 2 funds the creation of the React/TypeScript DApp, Lace wallet integration, proof‑server wiring in the UI, and UX refinement to ensure that non‑technical users can successfully create proposals and vote. Milestone 3 supports deeper test coverage, documentation, example scenarios, and packaging the repository and guides so other projects can reuse OpenVote with minimal friction.
In terms of value for money, the cost of USDM 10,000 is modest compared to commissioning multiple independent teams to build similar private voting systems from scratch. By investing once in a robust, open‑source reference implementation, the Midnight ecosystem gains a reusable asset that many DAOs and protocols can adopt, significantly multiplying the impact of the initial funding. The deliverables auditable open‑source code, test suites, docs, and demo deployments—remain available to the community long after the project period ends. This approach mirrors best practices from other ecosystems where a small number of well‑maintained reference DApps become the backbone for dozens of subsequent applications, allowing developers to focus on domain‑specific logic while relying on proven patterns for foundational components like governance.
How does the cost of the project represent value for the Midnight ecosystem?
The requested budget of USDM 10,000 represents strong value for the Midnight ecosystem because it funds not just a single governance tool, but a reusable reference implementation that many future projects can adopt with minimal additional cost. Instead of each DAO or protocol hiring separate teams to design, implement, and audit their own private voting systems, this project concentrates resources on building one high‑quality, open‑source stack that covers Compact contracts, ZK proof integration, wallet flows, frontend UX, and documentation. The resulting codebase can be forked or adapted by multiple initiatives, reducing duplicated engineering effort and allowing new teams to bring secure, privacy‑preserving governance online much faster than if they started from scratch.
From a cost‑effectiveness perspective, the budget is tightly scoped to core technical work—smart contract development, proof infrastructure, frontend engineering, testing, and docs—without including marketing campaigns, large management overheads, or third‑party agency fees. The milestone‑based structure (3k + 3k + 4k) means funds are tied to clear deliverables: a deployed Compact contract and proof server, a functioning testnet DApp, and a fully documented, test‑covered repository ready for reuse. Each of these outputs retains long‑term value: the contract and circuits provide audited patterns for private voting; the frontend demonstrates best‑practice UX for proof‑based actions; and the documentation and test suite become teaching material for hackathons, workshops, and new ecosystem teams. Compared with typical commercial development rates for specialized ZK and privacy work, delivering this entire package for 10k USDM is highly competitive.
Finally, the project generates measurable ecosystem returns. If even a handful of DAOs and protocols adopt or fork OpenVote, the cost per governance deployment rapidly drops, and each additional reuse is effectively “free” from Midnight’s perspective. Public metrics—such as forks, stars, external issues, and the number of independent OpenVote deployments—will allow the community to see how much leverage is being created from the initial investment. In this way, funding OpenVote functions as a strategic ecosystem grant: it unlocks a foundational capability (private, verifiable voting) that will be required repeatedly across many future projects, while keeping the one‑time cost low and the outputs permanently open to everyone building on Midnight.
I confirm that the proposal clearly provides a basic prototype reference application for one of the areas of interest.
Yes
I confirm that the proposal clearly defines which part of the developer journey it improves and how it makes building on Midnight easier and more productive.
Yes
I confirm that the proposal explicitly states the chosen permissive open-source license (e.g., MIT, Apache 2.0) and commits to a public code repository.
Yes
I confirm that the team provides evidence of their technical ability and experience in creating developer tools or high-quality technical content (e.g., GitHub, portfolio).
Yes
I confirm that a plan for creating and maintaining clear, comprehensive documentation is a core part of the proposal's scope.
Yes
I confirm that the budget and timeline (3 months) are realistic for delivering the proposed tool or resource.
Yes
I Agree
Yes
Armando Medina - Compact Developer
Compact developer
More than 100 hackathons participated
Winner in Midnight Berlin Hackathon
Finalist Sweet 16 in Midnight Hackathon London
Giovanni Fu Lin - Frontend Developer
NextJs, CSS and JS/TS Developer
prev frontend gitcoin, ethglobal finalist, many hackathons.