3 posts tagged with "development"

Hey Anon,

Welcome to another MACI blogpost. Today we are going to be looking at a voting plugin we have been developing to work with the Aragon OSx stack.

As mentioned in our latest roadmap blog post, our team decided to focus on supporting governance projects by integrating with tooling providers such as Aragon. Look out for further announcements over the next month. We're working on some exciting additions to the roadmap to accelerate private governance on Ethereum.

So why integrate MACI with Aragon OSx? Our thesis is simple: **private voting will increase voter participation and protect those voting. It will also lead to more honest and accurate outcomes as people can vote more honestly.**

Current public voting systems create barriers to honest participation. Voters face social pressure, fear of retaliation, and concerns about how their choices might affect future opportunities. Private voting removes these barriers, enabling DAOs to capture the true preferences of their communities.

We chose to integrate with Aragon because their OSx platform provides an excellent foundation for custom DAO governance, and as a reputable team building in the open, they're the perfect partner for this integration.

The real cost of public voting​

While transparency is often celebrated in crypto, public voting creates serious barriers to honest participation that threaten the legitimacy of DAO governance.

Fear of retaliation keeps voters silent. Large token holders can pressure smaller voters by threatening to exclude them from future opportunities, airdrops, or partnerships. When voting records are public, retaliation becomes easy to execute, leading many to abstain rather than risk consequences.

Social pressure distorts genuine preferences. Voters often wait to see how others vote before casting their own ballot, leading to herding behavior that doesn't reflect genuine preferences. Some even say governance voting has devolved into a game of politics. The "follow the whale" mentality and politics involved undermine the democratic ideals DAOs strive for.

Vote verification enables problematic markets. When votes are public, it also creates conditions where governance power can be openly traded, as buyers can verify they received what they paid for.

Public real time results can enable whales intervention. If the votes are public and visible in real time while the voting period is happening, whales (or users through token loans) could influence the decision by using their voting power to overpower the community decision.

Why MACI​

MACI (Minimal Anti Collusion Infrastructure) is a private voting protocol that aims to reduce collusion and coercion with receipt freeness - this makes it the logical next step for DAOs that really care about the problems highlighted above.

In more detail, every vote is encrypted and can only be decrypted for tallying, by a trusted entity referred to as the coordinator. Voters can override their votes at any point during the voting period, and thus without a clear receipt for their vote, they are not able to prove beyond reasonable doubt that they actually voted for an option. This discourages bribers from buying votes and other voters from attempting to collude.

While the coordinator can decrypt votes, they cannot produce an incorrect tally or censor votes, thanks to zero knowledge proofs and smart contracts.

For more details about MACI and how it works, we recommend reading our other blogposts such as this introductory article and our comprehensive documentation website.

How does Aragon OSx work​

Aragon OSx is a smart contract framework that works on EVM compatible chains. DAOs can easily deploy custom governance stacks using Aragon OSx, and can benefit from several plugins to extend their functionality over time. This plugin architecture allows DAOs to customise their governance without rebuilding from scratch.

A plugin is a smart contract with custom governance logic, limited in scope, and with single-purpose logic that can be used to extend OSx-based organisations. Examples include token voting and multisig, and now.. privacy-preserving voting through MACI.

How does the MACI plugin work​

The plugin allows DAO members to create new proposals by calling a smart contract function: createProposal. The function checks that the caller has enough governance tokens - this minimum amount is set by the DAO at deployment time. The plugin creates a new MACI poll that hosts the encrypted private votes for that particular proposal.

The plugin then captures the current block number (minus one) as a snapshot to determine voter eligibility. Once they decide to vote, they can register their interest to vote via their DAO frontend (in MACI's context we call this process join a poll), and their voting power is determined by their token balance at the time of proposal creation. Voters can use their real wallet holding their tokens to register themselves by publishing a MACI public key created on their devices. After that, the voter can use any wallet to submit an encrypted message containing the registered public key and their selected option.

Voters are then able to vote using their full voting power by choosing one of the options available, which at this time are Yes, No or Abstain. Voting is completely handled by MACI’s smart contracts, therefore voters do not actually ever interact with the DAO plugin.

Once the proposal ends, MACI’s backend service (the coordinator service), starts processing the votes, and generate zk-SNARK proofs to be validated on chain. Voters can be sure of the correct execution thanks to those proofs verifying on chain. Finally, the results are uploaded and the proposal execution can be triggered.

The full flow can be observed in the diagram below:

A proposal execution can range from transferring funds, calling a function on the DAO smart contract itself, calling out an external contract (for instance to initiate a token swap), or setting up a new plugin.

An example proposal shown below, with a proposal requesting users to vote on whether they are happy to convert part of the DAOs USDC reserves to ETH.

The familiar voting interface makes privacy seamless - voters simply select their choice without needing to understand the cryptography running behind the scenes.

Implementation Considerations​

• Network Support: Currently compatible with all EVM chains such as Ethereum, Arbitrum, Optimism, and some zkEVM networks such as Scroll and Linea. Here is a list of all compatible networks.
• Timeline: Vote processing is not immediate due to the need to process votes offchain and to generate zk-SNARK proofs of correct execution. The time it takes to process votes can be reduced by using more powerful hardware.
• Reliance on trusted coordinator: MACI in its current form relies on a trusted coordinator entity which can decrypt the votes - this is an automated piece of software that can run on a server or a Trusted Execution Environment for more security. The team is working on decentralising the coordinator entity and will soon begin working on an upgraded version that uses homomorphic encryption and threshold encryption to distribute the responsibilities across multiple entities. Please note that while the coordinator can see the votes, they cannot censor users nor provide incorrect results.
• Costs: Using MACI can be more costly than traditional blockchain-based voting. While these costs are negligible in layer 2 networks, costs can increase in Ethereum mainnet. Please refer to our costs section in the documentation website for more details on current benchmarks.

Next steps​

As DAOs evolve from experimental communities to serious organisations managing significant resources, governance systems must evolve too. The current landscape presents an ideal opportunity for DAOs to pioneer MACI, thus we are looking for forward-thinking DAOs to pilot MACI’s governance plugin - especially those facing challenges around voter participation, sensitive decision-making, or community pressure. Ready to be among the first? Reach out at maci@pse.dev or join our Discord. Governance on Ethereum needs a privacy shake up, stay in the loop if you're interested in hearing what else the team has been working on.

References and resources​

• MACI repo
• MACI voting plugin
• MACI -Aragon sample frontend
• Aragon OSx
• Aragon docs

Acknowledgements​

Thanks to the Aragon team for review.

Greetings anon, it’s been a while.

We’re excited to share with you what we're planning to build over 2025. Yes, we know it’s already March, so let’s start with a recap of what the team has been up to in the recent months, before moving to what’s up next.

MACI Coordinator service​

We are happy to announce that we completed the work on developing a service to automate MACI coordinator functionality. This includes:

• Contract deployment
• Subgraph deploying
• Proof generation
• Proof and results submission

This server exposes a REST API, as well as some Websocket endpoints (for proof generation only). We soon will publish a detailed guide on how to use, and how to integrate it via its SDK -stay tuned for a separate blog post.

For anyone interested in the code, you can find it here.

MACI Offchain voting support​

After Vitalik’s post original idea, the team worked on an implementation of offchain voting for MACI. This comes in the form of a relayer service, which can be run by the coordinator to support offchain vote submission, effectively reducing the cost for users to only the signup transaction.

In the future we plan to research how to extend support to signups too.

In a nutshell, the service exposes a REST API that allows voters to submit MACI messages, they only need to prove that they are signed up by posting a zk proof to avoid spam on the service. The coordinator will wait for batches of n messages to be collected, then post the hashes of the messages to the Poll smart contract, alongside an IPFS hash where these messages are stored. This allows to keep costs down for coordinators, as they would only need to post the message hashes compared to relaying message by message and hashing them on-chain. At the same time, users can vote for free, and if they do believe they have been censored, for instance they do not see their vote on the IPFS file, they can go directly on-chain and use MACI as normal.

It should be noted that at this time, using this feature might result in failure if either of the two are true:

• The coordinator calls relayMessagesBatch with invalid message hashes (there is no corresponding message on IPFS or local relayer storage)
• The coordinator posts message hashes on chain before they are stored on IPFS and local storage is lost

While both of these result in a liveness issue, MACI does not provide liveness guarantees either way, as in its current form the coordinator could choose to not complete a poll, and no one else would be able to process votes on their behalf. We will be looking to improve on this guarantees in out future work.

MACI v3​

We are very close to completing a new version of MACI - v3. This new version comes with features that have been requested in the past, such as polls being more customisable, in terms of voice credits assigned to voters, and gatekeeping mechanisms.

At a high level, the new features/improvements are:

1. Custom voice credits per poll
2. Custom gatekeeping per poll
3. Replacement of vote merkle trees for more efficient hash-chains

Up until now, MACI has not prioritised reusability of the smart contracts. More often than not, production votes using MACI relied on deploying new instances of the main MACI smart contract, resulting in users joining with a new set of keys every time. This by consequence results in these keys not holding more value than a single vote, thus enabling key selling. With this new version, we envision a single MACI smart contract to be the entry point for several polls, where voters are “forced” to signup to individual polls with the same key that they used to signup to the main smart contract. In production use cases, this could be follow this script:

1. The main MACI contract is set to gatekeep access using a very strong sybil mechanism, such as proof of passport
2. Users signup by proving they are human
3. For each poll that is created, voters can join with the same key if they wish to participate and if they can pass the specific poll gatekeeping requirements. For instance a specific poll might allow only Indian voters, thus use a Anon Adhaar policy to gate access

User research​

In order to inform MACI’s future roadmap and which use cases to tackle, we started to conduct user research. MACI has been historically used only in public goods funding, via protocols such as clr.fund, QFI, Gitcoin’s Allo stack, and MACI Platform. As we see a diminished interest and need for private voting in public goods funding, we decided to focus on a new use case which clearly has a larger demand for MACI - governance.

While still in the early discovery phase, we identified demand for MACI to be integrated into DAO governance protocol stacks like Aragon’s OSX in the form of a plugin. We are aiming to build a demo plugin and showcase it to Aragon in the coming months.

We hope to partner with several governance providers to enhance your voting offerings through modules/plugins.

2025 - What will we focus the rest of the year​

For this year, we plan to tackle a few different epics:

1. Release of MACI v3
2. Begin work to decentralize the coordinator using either homomorphic encryption or collaborative SNARKs
3. Integrate MACI into Aragon OSX’s stack
4. Continue with user research

MACI v3

We have just talked about MACI v3, so what is left to add is that we will be looking to complete the documentation updates, clean up the code and release it as soon as possible. Get ready for an even better version of MACI, and please reach out if you would like to integrate v3, we are here to support.

What about coordinator decentralisation?

That sounds interesting.. Let’s talk about that.

One of MACI long standing issues has been the privileges that the coordinator role has. They are able to see all of the votes in cleartext, which allows them to collude with bribers themselves, as well as voters. As we look to tackle use cases such as DAO governance where lot of money is involved in proposals, we need to ensure that collusion between the coordinator and voters/bribers is reduced. This can be accomplished in several ways:

• Use Multi Party Computation (MPC)
• Use Homomorphic Encryption (HE)
• Use a Trusted Execution Environment (TEE)

Without going into much details here (keep an eye out for a separate post), to actually decentralise the coordinator role we will need either MPC (in the forms of co-SNARKs) or HE. The team is researching the available technologies to come up with a proposal on how to tackle this problem. We are very excited to improve MACI’s security and bring an even better primitive to projects that want private and secure voting.

Integrating MACI into the Aragon OSX stack

After some discussion with Aragon, we decided to build a demo to showcase how MACI could be used in DAOs created using Aragon’s OSX stack.

The goal is to get a working demo in the coming months that allow to create new voting proposals where DAO token holders can vote Yes, No, or Abstain. At this time, we will be making a very simple integration, and in the future we plan to integrate some features into the MACI protocol which would make it more suited for DAO governance, such as:

• Have a custom type of polls where one can only vote with all of their voting power (currently there is no option to restrict this and voters can allocate their voting power as they prefer across several available options)
• Count the number of votes for each option (currently this is not possible, the coordinator would need to provide this information, without a way to prove its correctness)

Once the demo is out and some DAOs test it out, we look forward to preparing this to be production ready and target running some DAO voting, from a supportive perspective.

You can track progress of development on this repo.

Continue with user research

While we have identified a new use case to tackle, governance, we still want to continue speaking with different projects and individuals to learn even more where can provide value in the short, and long term.

We have identified some projects that we want to chat with, however are open to suggestion - know anyone that is interested in private and anti collusion voting? Introduce them to us to help us understand how we can help democracy thrive.

Hey folks! We’re thrilled to kick off a series of tutorials covering everything you need to know about MACI. This guide will focus on installing MACI and deploying the contracts to a testnet. Let’s get started!

Understanding Roles​

MACI protocol has two main roles, User (Voter) and Coordinator. A simplified version would be to say that the coordinator is in charge of deploying the MACI smart contracts, initiating the polls, tallying the final results of a vote, and finalizing polls by publishing the final results on-chain. Usually the contract deployer is the coordinator, but this can be a separate entity.

Requirements​

Let's install the required tools first:

• Node.js: use a JS toolchain manager like nvm or volta to install Node.js. We recommend using Node 20 or above.
• pnpm: Fast, disk space efficient package manager.

Installation​

Now you can run the following commands to install MACI locally:

git clone https://github.com/privacy-scaling-explorations/maci.git && \
cd maci && \
git checkout v2.5.0 && \
pnpm i && \
pnpm run build

Download the zero knowledge artifacts​

MACI has two main zk-SNARK circuits, and each of them is parameterized. There should be one .zkey file for each circuit and set of parameters.

Unless you wish to generate a fresh set of .zkey files, you should obtain them from someone who has performed a multi-party trusted setup for said circuits. For more details on which artifacts have undergone a trusted setup, please refer to the Trusted Setup page.

Download test artifacts​

For all but production use cases, we suggest using the test artifacts, with the latest dev code, you can download them by running:

pnpm download-zkeys:test

Download ceremony artifacts​

For production you need to use the ceremony artifacts which have undergone a trusted setup, you can download them with the command:

pnpm download-zkeys:ceremony

Deploy Contracts​

Before deploying the contracts we need to do some final configurations to our repository.

Set the environment variables​

Head to the packages/contracts folder and copy the .env.example file.

cd packages/contracts && \
cp .env.example .env

Make sure to include a mnemonic and RPC url (make sure to replace NETWORK with the network you want to use).

MNEMONIC = "your ethereum secret key";
NETWORK_RPC_URL = "the eth provider url";
NETWORK_ETHERSCAN_API_KEY = "etherscan api key";

Generate Coordinator Keys​

In order to run MACI polls, a coordinator is required to publish their MACI public key. You will need to generate a MACI keypair, and treat the private key just as your ethereum private keys. Please store them in a safe place as you won't be able to finish a round if you lose access, or if compromised a bad actor could decrypt the vote and publish them online. You can generate a new key pair using maci-cli by running the following commands:

cd packages/cli && \
node build/ts/index.js genMaciKeyPair

Set the configuration file​

Head back to the contracts folder and copy the config example and update the fields as necessary:

cd ../contracts && \
cp deploy-config-example.json deploy-config.json

ConstantInitialVoiceCreditProxy​

Defines how many credits will get each voter.

Gatekeeper​

MACI uses a "gatekeeper" contract to configure and enforce the eligibility criteria of voters who can participate in MACI polls. In other words, it is a way to allowlist signups to the system to protect against sybil attacks. Please refer to the gatekeeper page in the documentation for more information on the supported Gatekeepers.

MACI​

This property defines which Gatekeeper and stateTreeDepth MACI is going to use. The stateTreeDepth defines how many users the system supports.

VkRegistry​

The VkRegistry hold the verifying keys used to verify the proofs, on the zkeys field we define the path to the zero knowledge artifacts we downloaded in the previous steps.

Poll​

Configures the poll duration in seconds, determines whether quadratic voting is enabled, and sets the public key of the Coordinator.

Deploy MACI Contracts​

To deploy the MACI contracts to a specific network you can append :network to the deployment commands, e.g. pnpm deploy:sepolia - please refer to the supported networks documentation page to see all available networks.

pnpm deploy:NETWORK

Deploy Poll​

Before deploying a Poll, make sure you have set the coordinator MACI public key to which you own the private key. To deploy your first Poll you can run the following command:

pnpm deploy-poll:NETWORK

Poll Finalization​

As a coordinator, first you need to merge signups and messages (votes). Messages are stored in a queue so when the poll is over, the coordinator needs to create the merkle tree from the queue (AccQueue). This optimization is needed to reduce gas cost for voters. Then the coordinator generates proofs for the message processing, and tally calculations. This allows to publish the poll results on-chain and then everyone can verify the results when the poll is over. You run a merge with:

pnpm merge:[network] --poll [poll-id]

Then you need to generate the proofs with the following command:

pnpm run prove:[network] --poll [poll-id] \
    --coordinator-private-key [coordinator-maci-private-key] \
    --tally-file ../proofs/tally.json \
    --output-dir ../proofs/proofs/ \
    --start-block [block-number]  \
    --blocks-per-batch [number-of-blocks]

Submit On-chain​

Now it's time to submit the poll results on-chain so that everyone can verify the results:

pnpm submitOnChain:[network] --poll [poll-id] \
    --output-dir proofs/ \
    --tally-file proofs/tally.json

Tally​

Once the proofs are generated, and results tallied, the results (Tally) are written to a file. Let's take a look at one:

{
  "maci": "0xd54b47F8e6A1b97F3A84f63c867286272b273b7C",
  "pollId": "0",
  "network": "localhost",
  "chainId": "31337",
  "isQuadratic": true,
  "tallyAddress": "0xD4fbAF1dFe100d07f8Ef73d8c92e93d0Bcf7b45D",
  "newTallyCommitment": "0x2f55cc85f7f141098ba791a9f6a646f8773b9bb4f5852ccc33b5a28e7b0756e5",
  "results": {
    "tally": [
      "9",
      "0",
      "0",
      "0",
      "0",
      "0",
      "0",
      "0",
      "0",
      "0",
      "0",
      "0",
      "0",
      "0",
      "0",
      "0",
      "0",
      "0",
      "0",
      "0",
      "0",
      "0",
      "0",
      "0",
      "0"
    ],
    "salt": "0x2e9cd240b86cf456fa4deced8e7420c45e3c16941d2dcec308f8b6d48264dda3",
    "commitment": "0x296eac2a7289974f23497bebd39e86599d0b7032796fb84dcc1f6bbda38262ca"
  },
  "totalSpentVoiceCredits": {
    "spent": "81",
    "salt": "0x24f57b75c227987727c13d1e83409d70478b42bdc12a4a4df8129c72fbaf5aaf",
    "commitment": "0xb4ebe68b0da828c0b978ddee86ba934b8e215499ac766491f236ad85fd606de"
  },
  "perVOSpentVoiceCredits": {
    "tally": [
      "81",
      "0",
      "0",
      "0",
      "0",
      "0",
      "0",
      "0",
      "0",
      "0",
      "0",
      "0",
      "0",
      "0",
      "0",
      "0",
      "0",
      "0",
      "0",
      "0",
      "0",
      "0",
      "0",
      "0",
      "0"
    ],
    "salt": "0x2590434ea2d600f7bd2396ba7fa454ad4c975c29424ee481561d9786538a5e48",
    "commitment": "0x54ec996599886da21c4b07c25d1de544292a8b7c38b79726995c869c9e95db"
  }
}

We observe an array named results, which holds the aggregated votes for each option. Each option corresponds to an index in the array. In the example above, the first option (index 0) received a total of 9 votes, while all other options received no votes

The totalSpentVoiceCredits object contains the total amount of voice credits spent in the poll. This is the sum of all voice credits spent by all voters, and in quadratic voting, is the sum of the squares of all votes.

The perVOSpentVoiceCredits will contain the amount of voice credits spent per vote option. In this case, the first option received 81 voice credits, and every other option received 0 voice credits. This is because there was only one valid vote casted, with a weight of 9. Given the quadratic voting formula, the total amount of voice credits spent is 81.

That should be all for this tutorial, feel free to join our discord for any questions or recommendations, and feel free to read our documentation for more in depth resources.