@maci-protocol/website 0.0.0-ci.d0dddbc → 0.0.0-ci.d231815

package/blog/2024-02-28-maci-v1.2.0.md

@@ -94,7 +94,7 @@ Following the successful completion of our [MACI trusted setup ceremony](https:/
 
 To accomplish this, we'll leverage the tooling of [P0tion](https://github.com/privacy-scaling-explorations/p0tion), which helps to streamline and automate Groth16 phase2 ceremonies.
 
-We'll update this page after the ceremony completes to include the production-ready zkey artifacts. In the meantime, the artifacts for v.1.1.1 can be found on our [website](/docs/security/trusted-setup), and the [`tallyVotes`](https://github.com/privacy-scaling-explorations/maci/blob/dev/circuits/circom/tallyVotes.circom) artifacts can still be used in production.
+We'll update this page after the ceremony completes to include the production-ready zkey artifacts. In the meantime, the artifacts for v.1.1.1 can be found on our [website](/docs/security/trusted-setup), and the [`tallyVotes`](https://github.com/privacy-scaling-explorations/maci/blob/main/circuits/circom/tallyVotes.circom) artifacts can still be used in production.
 
 ## Get Involved
 

package/blog/2025-03-21-roadmap-2025.md

@@ -26,7 +26,7 @@ We are happy to announce that we completed the work on developing a service to a
 
 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](https://github.com/privacy-scaling-explorations/maci/tree/dev/apps/coordinator).
+For anyone interested in the code, you can find it [here](https://github.com/privacy-scaling-explorations/maci/tree/main/apps/coordinator).
 
 ### MACI Offchain voting support
 

package/blog/2025-08-18-maci-aragon-plugin.md

@@ -0,0 +1,107 @@
+---
+slug: maci-aragon-plugin
+title: MACI Aragon Plugin
+description: A MACI plugin for Aragon OSx to enable private voting in DAOs
+authors:
+  - name: ctrlc03
+    title: MACI former team lead
+    url: https://x.com/ctrlc03
+    image_url: https://avatars.githubusercontent.com/u/93448202?v=4
+  - name: John Guilding
+    title: MACI team lead
+    url: https://x.com/john_guilding
+    image_url: https://pbs.twimg.com/profile_images/1629144990914945024/C6_xsK78_400x400.jpg
+  - name: NicoSerranoP
+    title: MACI team member
+    url: https://x.com/NicoSerranoP
+    image_url: https://avatars.githubusercontent.com/u/38594836?v=4
+tags: [voting, security, anonymity, Aragon, MACI, development]
+excerpt: "A MACI plugin for Aragon OSx to enable private voting in DAOs"
+---
+
+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](https://www.aragon.org/osx).
+
+As mentioned in our [latest roadmap blog post](https://maci.pse.dev/blog/2025-Roadmap#2025---what-will-we-focus-the-rest-of-the-year), our team decided to focus on supporting governance projects by integrating with tooling providers such as [Aragon](https://www.aragon.org/). 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](https://x.com/LefterisJP/status/1921562225333916094) 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](https://www.tronweekly.com/arbitrum-vote-buying-scandal-how-5-eth-shook/), 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](https://maci.pse.dev/blog/maci-for-beginners) and our comprehensive documentation [website](https://maci.pse.dev/docs/introduction).
+
+### 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](https://docs.aragon.org/token-voting/1.x/index.html) and [multisig](https://docs.aragon.org/multisig/1.x/index.html), 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](https://github.com/privacy-scaling-explorations/maci/tree/dev/apps/coordinator)), 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:
+
+![new-flow-maci](https://hackmd.io/_uploads/Sktza18Xge.png)
+
+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.
+
+![dao1](https://hackmd.io/_uploads/rk7C3dHXll.png)
+
+The familiar voting interface makes privacy seamless - voters simply select their choice without needing to understand the cryptography running behind the scenes.
+
+![voting1](https://hackmd.io/_uploads/H1TR3OHXxg.png)
+
+### 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](https://maci.pse.dev/docs/supported-networks/) 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](https://maci.pse.dev/docs/supported-networks/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](mailto:maci@pse.dev) or join our [Discord](https://discord.com/invite/sF5CT5rzrR). 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](https://github.com/privacy-scaling-explorations/maci)
+- [MACI voting plugin](https://github.com/privacy-scaling-explorations/maci-voting-plugin-aragon)
+- [MACI -Aragon sample frontend](https://github.com/privacy-scaling-explorations/maci-aragon-osx-gov-app)
+- [Aragon OSx](https://github.com/aragon/osx)
+- [Aragon docs](https://docs.aragon.org/)
+
+## Acknowledgements
+
+Thanks to the Aragon team for review.

package/blog/2025-09-05-maci-coordinator-service.md

@@ -0,0 +1,167 @@
+---
+slug: maci-coordinator-service
+title: MACI Coordinator Service
+description: Announcing our coordinator service for MACI
+authors:
+  - name: ctrlc03
+    title: MACI former team lead
+    url: https://x.com/ctrlc03
+    image_url: https://avatars.githubusercontent.com/u/93448202?v=4c
+  - name: NicoSerranoP
+    title: MACI team member
+    url: https://x.com/NicoSerranoP
+    image_url: https://avatars.githubusercontent.com/u/38594836?v=4
+tags: [voting, security, anonymity, MACI, coordinator]
+excerpt: "A MACI plugin for Aragon OSx to enable private voting in DAOs"
+---
+
+Hey Anon,
+
+Welcome back to our MACI blog.
+
+Today, we are excited to officially announce something we have referenced frequently: the Coordinator Service.
+
+If you ever used MACI, for instance to run a Retroactive Public Goods Funding (RPGF) or Quadratic Funding (QF) round, you might be aware of how tedious it was to operate. The manual process of running scripts to finalise a round and calculate the tally as well as all of the zk-SNARK proofs could require some time and technical expertise. All these steps had to be done in the terminal and you needed to be familiar with MACI's inner workings to understand the process.
+
+**Fear no more - the coordinator service is here to make your life easier.**
+
+## The vision: MACI for everyone
+
+Our goal is ambitious, yet simple: **completely eliminate the need for any technical knowledge to use MACI**. No more terminal commands, no more manual proof generation, no more complex scripts. Just configure once, run inside a Docker container on your server, and enjoy the full power of MACI's privacy-preserving voting infrastructure.
+
+## Technical implementation
+
+The service was built with the following technologies for reliability and scalability:
+
+- TypeScript for type-safe, maintainable code
+- Nest.js framework for enterprise-grade architecture
+- REST API for standard CRUD operations
+- WebSocket endpoints for real-time updates during intensive computations
+- MACI SDK package to have all the logic and functions ready to use
+- Docker-ready for simple deployment anywhere
+
+The core functionalities of the service are as follows:
+
+- Deploy a MACI [subgraph](https://github.com/privacy-scaling-explorations/maci/tree/dev/apps/coordinator/ts/subgraph) to query on-chain data easily
+- [Deploy](https://github.com/privacy-scaling-explorations/maci/tree/dev/apps/coordinator/ts/deployer) the MACI smart contracts, including polls
+- [Finalise](https://github.com/privacy-scaling-explorations/maci/tree/dev/apps/coordinator/ts/proof) polls by processing votes and tallying the results
+- [Schedule](https://github.com/privacy-scaling-explorations/maci/tree/main/apps/coordinator/ts/scheduler) polls for automatic finalization when the voting period ends
+- [Health](https://github.com/privacy-scaling-explorations/maci/tree/main/apps/coordinator/ts/health) endpoint to check everything is setup and working
+
+Let's dive into more details in the following sections.
+
+### Subraph deployment
+
+The endpoint to deploy a subgraph requires some configuration in the `.env` file, as well as an HTTP request to the endpoint responsible for this `https://coordinator.maci.vote/v1/subgraph/deploy`. Make sure you have an account in [The Graph](https://thegraph.com/studio/) to setup your `.env` file before starting the coordinator service.
+
+### Contracts deployment
+
+There are two endpoints in this module: deploy maci (`https://coordinator.maci.vote/v1/deploy/maci`) and deploy poll (`https://coordinator.maci.vote/v1/deploy/poll`). This will take care of all contracts deployment and configuration. It is worth pointing out that you should read the [coordinator service API documentation](https://coordinator.maci.vote/api) and the [MACI guides](https://maci.pse.dev/docs/core-concepts/workflow) to understand the roles of each contract (MACI, poll, policy, initialVoiceCredit).
+
+You can deploy one MACI contract (and its internal smart contracts) that will have one gatekeeper policy (e.g. FreeForAll) for all voters to sign up. After that you can deploy multiple polls with different settings (start date, end date, gatekeeper policy, etc). Each voter will have to join each poll to be eligible to participate in. The poll's gatekeeper will check the voter eligibility to join the poll.
+
+### Finalisation
+
+This step includes three separate actions:
+
+1. Merge - calculate the state merkle tree root and store a commitment to its root (`https://coordinator.maci.vote/v1/proof/merge`)
+2. Process - fetch all smart contracts events to reconstruct the state locally and process all votes. This includes decrypting votes, checking validity, and finally tallying them. zk-SNARK proofs are generated for each batch of votes processed (`https://coordinator.maci.vote/v1/proof/generate`)
+3. Submit - submitting all of the zk-SNARK proofs on chain to prove that the poll was processed correctly. Finally, submit the tally results on chain so that they can be seen by everyone (`https://coordinator.maci.vote/v1/proof/submit`)
+
+We chose to separate each action into its own endpoint to avoid long-running computations that could lead to network errors or timeouts.
+
+### Schedule
+
+After finishing up the finalisation module, we realized that it would be a lot easier for users to create polls and schedule the finalization process. This removes the need for users to manually call the finalization endpoints described above.
+
+1. To schedule a deployed poll you can use `https://coordinator.maci.vote/v1/scheduler/register`.
+2. To check if a poll is scheduled you can use `https://coordinator.maci.vote/v1/scheduler/status`
+3. To delete a scheduled poll you can use `https://coordinator.maci.vote/v1/scheduler/delete`
+
+## How to use
+
+### Run it from source
+
+1. Clone the MACI repository: [https://github.com/privacy-scaling-explorations/maci](https://github.com/privacy-scaling-explorations/maci)
+2. Install dependencies and build the project
+
+```bash
+pnpm install
+pnpm run build
+```
+
+3. Download the zkeys for the coordinator
+
+```bash
+pnpm run download-zkeys:ceremony:coordinator
+```
+
+4. Generate a coordinator MACI keypair. Remember to store those values for later.
+
+```bash
+pnpm run generate-maci-keypair
+```
+
+5. Move to the coordinator service directory
+
+```bash
+cd apps/coordinator
+```
+
+6. Configure your `.env` file. Make sure to configure it with your own secure values. The coordinator MACI private key from the previous step should be set here
+
+```bash
+cp .env.example .env
+```
+
+7. Start the service
+
+```bash
+pnpm run start
+# or
+pnpm run start:prod
+```
+
+### Run it with Docker
+
+1. Clone the MACI repository: [https://github.com/privacy-scaling-explorations/maci](https://github.com/privacy-scaling-explorations/maci)
+2. Go inside the project directory
+
+```bash
+cd maci
+```
+
+3. Build the docker image and run the container
+
+```bash
+# Build docker
+docker compose -f apps/coordinator/docker-compose.yml build
+
+# Run container detached
+docker compose -f apps/coordinator/docker-compose.yml up -d
+```
+
+## Usage notes
+
+1. You can check out the documentation while the service is running in [http://localhost:3001/api](http://localhost:3001/api)
+
+2. We have a [e2e.deploy.test.ts](https://github.com/privacy-scaling-explorations/maci/blob/main/apps/coordinator/tests/e2e.deploy.test.ts) file that performs a complete process: deployment, voting and finalization. You can use it to guide yourself.
+
+## Future work
+
+We are researching about different cryptographic methods to decentralize the coordinator. The idea is to eliminate reliance on a single centralized service for finalizing polls. A group of people would be able to spin up their own coordinator services and finalize the poll in a multi-party computation. For more info check out our MACI v4 research.
+
+## Conclusion
+
+The MACI Coordinator Service represents a significant leap forward in making MACI accessible to everyone. Whether you're running a small community poll or a large-scale funding round, the coordinator service handles the complexity so you can focus on what matters - empowering your community with private, secure voting.
+
+Ready to get started? Head over to our documentation and deploy your first MACI round today!
+
+Please reach out if you would like to integrate the service into your frontend.
+
+## References
+
+- [MACI repo](https://github.com/privacy-scaling-explorations/maci)
+- [Sample frontend](https://github.com/privacy-scaling-explorations/maci-aragon-osx-gov-app) using the coordinator service
+- [Code examples](https://github.com/privacy-scaling-explorations/maci-aragon-osx-gov-app/blob/main/plugins/maciVoting/contexts/CoordinatorContext.tsx)
+- [Documentation](https://maci.pse.dev/docs/category/coordinator-service)

package/docusaurus.config.ts

@@ -204,9 +204,15 @@ async function getConfig(): Promise<Config> {
         phpLoader: "matomo.php",
         jsLoader: "matomo.js",
       },
+      mermaid: {
+        theme: { light: "neutral", dark: "forest" },
+      },
     } satisfies Preset.ThemeConfig,
+    markdown: {
+      mermaid: true,
+    },
+    themes: ["@docusaurus/theme-mermaid"],
   };
-
   return config;
 }
 

package/package.json

@@ -1,6 +1,6 @@
 {
   "name": "@maci-protocol/website",
-  "version": "0.0.0-ci.d0dddbc",
+  "version": "0.0.0-ci.d231815",
   "private": false,
   "publishConfig": {
     "access": "public"
@@ -25,26 +25,27 @@
     "@docusaurus/preset-classic": "^3.8.1",
     "@docusaurus/theme-classic": "^3.8.1",
     "@docusaurus/theme-common": "^3.8.1",
-    "@easyops-cn/docusaurus-search-local": "^0.51.0",
+    "@docusaurus/theme-mermaid": "^3.8.1",
+    "@easyops-cn/docusaurus-search-local": "^0.55.1",
     "@mdx-js/react": "^3.1.0",
     "clsx": "^2.1.1",
     "docusaurus-plugin-image-zoom": "^3.0.1",
     "docusaurus-plugin-matomo": "^0.0.8",
     "gray-matter": "^4.0.3",
     "prism-react-renderer": "^2.4.1",
-    "react": "^19.1.0",
-    "react-dom": "^19.1.0",
+    "react": "^19.2.4",
+    "react-dom": "^19.2.4",
     "rehype-katex": "^7.0.1",
     "remark-math": "^6.0.0"
   },
   "devDependencies": {
-    "@docusaurus/module-type-aliases": "^3.8.1",
+    "@docusaurus/module-type-aliases": "^3.9.2",
     "@docusaurus/tsconfig": "^3.8.1",
     "@docusaurus/types": "^3.8.1",
-    "@types/node": "^24.0.1",
-    "@types/react": "^19.1.8",
+    "@types/node": "^24.11.0",
+    "@types/react": "^19.1.9",
     "ts-node": "^10.9.2",
-    "typescript": "^5.8.3"
+    "typescript": "^5.9.2"
   },
   "browserslist": {
     "production": [
@@ -59,7 +60,7 @@
     ]
   },
   "engines": {
-    "node": ">=18.0"
+    "node": "20"
   },
-  "gitHead": "f41939d7f430a8b5c9b3729d6d12ca15d94cf181"
+  "gitHead": "271bc779ccbd8510ae0fcbc43063aacffe39d4d9"
 }

package/versioned_docs/version-v0.x/contract.md

@@ -84,7 +84,7 @@ uint256[] memory _finalSaltedResults,
 uint256[8] memory _proof
 ```
 
-This allows the coordinator to prove the correctness of their vote tally (in `_finalSaltedResults`). They do this in batches of state leaves. Each batch of state leaves is accumulated into an intermediate state root, and the Merkle root of all the intermediate state roots is the full state root. The proof shows that the result of adding the votes in the current batch to the culmulative results is computed correctly, but hides the results by salting and hashing them.
+This allows the coordinator to prove the correctness of their vote tally (in `_finalSaltedResults`). They do this in batches of state leaves. Each batch of state leaves is accumulated into an intermediate state root, and the Merkle root of all the intermediate state roots is the full state root. The proof shows that the result of adding the votes in the current batch to the cumulative results is computed correctly, but hides the results by salting and hashing them.
 
 `_finalSaltedResults` can be any value but for the final batch, it must be the correct quadratic vote tally.
 

package/versioned_docs/version-v0.x/introduction.md

@@ -41,9 +41,7 @@ Refer to the [Glossary](#glossary) for definitions of terms.
 3. The signup period ends after a fixed amount of time. From that point onwards, users may no longer invoke `signUp()` in this contract.
 
 4. Each user votes. To do this, they:
-
    - Sign their command using the key which they had signed up with and then use a random (ephemeral) key as well as the coordinator's public key to generate a shared key (via ECDH) encrypt it.
-
      - If they are bribed, the user should sign it using an old public key which has already been replaced with a new one.
 
      - Otherwise, the user should use the most current public key they have registered.
@@ -53,9 +51,7 @@ Refer to the [Glossary](#glossary) for definitions of terms.
 5. The coordinator processes all the commands after the voting period ends.
 
 6. For each batch of commands, they perform the following steps:
-
    - Generate a new state root which is the result of:
-
      - For each valid command, in reverse order, update the state leaf accordingly
 
      - Ignore all invalid commands

package/versioned_docs/version-v0.x/quadratic-vote-tallying-circuit.md

@@ -47,7 +47,7 @@ The MACI contract's `quadraticVoteTally()` function should verify a proof create
 | `currentResultsSalt`            | Private             | A random value to hash with the vote tally for state leaves up to the current batch                        | Coordinator |
 | `currentResultsCommitment`      | Public              | The salted commitment of the values in `currentResults`                                                    | Contract    |
 | `newResultsCommitment`          | Public              | The salted commitment of the vote tally for this batch of leaves plus the vote tally from `currentResults` | Contract    |
-| `salt`                          | Private             | A random value to hash with the culmulate vote tally for this batch of state leaves                        | Coordinator |
+| `salt`                          | Private             | A random value to hash with the cumulate vote tally for this batch of state leaves                         | Coordinator |
 | `stateLeaves[m][p]`             | Private             | The batch of leaves of the state tree to tally.                                                            | Coordinator |
 | `voteLeaves[m][n]`              | Private             | The vote leaves for each user in this batch of state leaves.                                               | Coordinator |
 

package/versioned_docs/version-v1.2/circuits.md

@@ -11,11 +11,11 @@ MACI uses zk-SNARKs to essentially hide how each person voted while still reveal
 
 ## MACI Circuits
 
-MACI has three main zk-SNARK [circuits](https://github.com/privacy-scaling-explorations/maci/tree/dev/circuits):
+MACI has three main zk-SNARK [circuits](https://github.com/privacy-scaling-explorations/maci/tree/main/circuits):
 
-1. [`ProcessMessages.circom`](https://github.com/privacy-scaling-explorations/maci/blob/dev/circuits/circom/processMessages.circom), which takes a batch of encrypted messages, decrypts them, and generates a proof that the coordinator's local processing was performed correctly.
-2. [`TallyVotes.circom`](https://github.com/privacy-scaling-explorations/maci/blob/dev/circuits/circom/tallyVotes.circom), which counts votes from users' ballots, batch by batch.
-3. [`Subsidy.circom`](https://github.com/privacy-scaling-explorations/maci/blob/dev/circuits/circom/subsidy.circom), which implements [pairwise subsidy](https://hackmd.io/@chaosma/H1_9xmT2K). Please note this is an optional feature.
+1. [`ProcessMessages.circom`](https://github.com/privacy-scaling-explorations/maci/blob/main/circuits/circom/processMessages.circom), which takes a batch of encrypted messages, decrypts them, and generates a proof that the coordinator's local processing was performed correctly.
+2. [`TallyVotes.circom`](https://github.com/privacy-scaling-explorations/maci/blob/main/circuits/circom/tallyVotes.circom), which counts votes from users' ballots, batch by batch.
+3. [`Subsidy.circom`](https://github.com/privacy-scaling-explorations/maci/blob/main/circuits/circom/subsidy.circom), which implements [pairwise subsidy](https://hackmd.io/@chaosma/H1_9xmT2K). Please note this is an optional feature.
 
 The rest of the circuits are utilities templates that are required for the main circuits to work correctly. These include utilities such as float math, conversion of private keys, and Poseidon hashing/encryption.
 
@@ -45,7 +45,7 @@ The circuits are used by the coordinator (the prover) to prove that they have co
 
 ## How do the circuits work?
 
-### Message processing ([`processMessages`](https://github.com/privacy-scaling-explorations/maci/blob/dev/circuits/circom/processMessages.circom))
+### Message processing ([`processMessages`](https://github.com/privacy-scaling-explorations/maci/blob/main/circuits/circom/processMessages.circom))
 
 This circuit allows the coordinator to prove that they have correctly processed each message in reverse order, in a consecutive batch of 5 ^ msgBatchDepth messages to the respective state leaf within the state tree. Coordinators would use this circuit to prove correct execution at the end of each Poll.
 
@@ -162,7 +162,7 @@ A simplified example using a tree of arity 2:
 
 To prove that `a...d` are leaves of the tree with root `r`, we prove that the leaves have the subroot `s` with depth 2, and _then_ prove that `s` is a member of `r` at depth 1.
 
-The implementation for this is in the `QuinBatchLeavesExists` circuit in `https://github.com/privacy-scaling-explorations/maci/blob/dev/circuits/circom/trees/incrementalQuinTree.circom`.
+The implementation for this is in the `QuinBatchLeavesExists` circuit in `https://github.com/privacy-scaling-explorations/maci/blob/main/circuits/circom/trees/incrementalQuinTree.circom`.
 
 This method requires fewer circuit constraints than if we verified a Merkle proof for each leaf.
 
@@ -177,7 +177,7 @@ This method requires fewer circuit constraints than if we verified a Merkle proo
 7. That each message in `msgs` exists in the message tree
 8. That after decrypting and applying each message, in reverse order, to the corresponding state and ballot leaves, the new state root, new ballot root, and `newSbSalt` are the preimage to `newSbCommitment`
 
-### Tally Votes ([`tallyVotes`](https://github.com/privacy-scaling-explorations/maci/blob/dev/circuits/circom/tallyVotes.circom))
+### Tally Votes ([`tallyVotes`](https://github.com/privacy-scaling-explorations/maci/blob/main/circuits/circom/tallyVotes.circom))
 
 #### Parameters
 
@@ -280,7 +280,7 @@ $poseidon_3([tc_r, tc_t, tc_p])$
 6. That the tally is valid, which is:
    - That the sum of votes per vote option is correct
 
-### Subsisdy ([`subsidy`](https://github.com/privacy-scaling-explorations/maci/blob/dev/circuits/circom/subsidy.circom))
+### Subsisdy ([`subsidy`](https://github.com/privacy-scaling-explorations/maci/blob/main/circuits/circom/subsidy.circom))
 
 This circuit is an optional feature - it's not required for MACI to function.  
 The subsidy circuit is used to implement pairwise subsidy. This is a technique that can be used to detect voters collusion. It currently is not optimized for production and the team will work on a more efficient implementation in the future.

package/versioned_docs/version-v1.2/contributing/contributing.md

@@ -37,13 +37,13 @@ Pull requests are great if you want to add a feature or fix a bug. Here's a quic
 
 7. Make the test pass.
 
-8. Commit your changes. Please make sure your forked `dev` branch is synched as well feature/fix branch and there are no "temp" commits (like wip, fix typo/lint/types and etc). We recommend to squash the feature/fix branch commits before creating PR. You can use this command for it:
+8. Commit your changes. Please make sure your forked `main` branch is synched as well feature/fix branch and there are no "temp" commits (like wip, fix typo/lint/types and etc). We recommend to squash the feature/fix branch commits before creating PR. You can use this command for it:
 
 ```bash
-git reset $(git merge-base dev $(git rev-parse --abbrev-ref HEAD))
+git reset $(git merge-base main $(git rev-parse --abbrev-ref HEAD))
 ```
 
-9. Push to your fork and submit a pull request on our `dev` branch. Please provide us with some explanation of why you made the changes you made. For new features make sure to explain a standard use case to us.
+9. Push to your fork and submit a pull request on our `main` branch. Please provide us with some explanation of why you made the changes you made. For new features make sure to explain a standard use case to us.
 
 10. Link any issues that the PR is addressing as described in our processes documentation.
 
@@ -111,7 +111,7 @@ Just as in the subject, use the imperative, present tense: "change" not "changed
 
 ### Branch rules
 
-- Branches should generally be created off of the base branch (`dev` )
+- Branches should generally be created off of the base branch (`main` )
 - Avoid long descriptive names for long-lived branches
 - Use kebab-case (no CamelCase)
 - Use grouping tokens (words) at the beginning of your branch names (in a similar way to the `type` of commit)

package/versioned_docs/version-v1.2/deployment.md

@@ -112,7 +112,7 @@ For non-quadratic voting polls, you can use the `--use-quadratic-voting false` f
 5. Run `pnpm deploy-poll` to deploy your first Poll (you can specify the network by appending `:network` to the command, e.g. `pnpm deploy-poll:sepolia` - please refer to the available networks on the `package.json` scripts section)
 
 :::info
-Should you wish to deploy on a different network, you will need to update the [contracts/tasks/helpers/constants.ts](https://github.com/privacy-scaling-explorations/maci/blob/dev/contracts/tasks/helpers/constants.ts) file.
+Should you wish to deploy on a different network, you will need to update the [contracts/tasks/helpers/constants.ts](https://github.com/privacy-scaling-explorations/maci/blob/main/contracts/tasks/helpers/constants.ts) file.
 :::
 
 6. You will find all of the deployed contracts addresses and configs in the `deployed-contracts.json` file inside the contracts folder.

package/versioned_docs/version-v1.2/integrating.md

@@ -140,7 +140,7 @@ function contribute(
 
 ## InitialVoiceCreditProxy
 
-If you'd like to extend the functionality of how votes are distributed among users, you need to extend [InitialVoiceCreditProxy](https://github.com/privacy-scaling-explorations/maci/blob/dev/contracts/contracts/initialVoiceCreditProxy/InitialVoiceCreditProxy.sol) contract. You can see our [basic example](https://github.com/privacy-scaling-explorations/maci/blob/dev/contracts/contracts/initialVoiceCreditProxy/ConstantInitialVoiceCreditProxy.sol) how it's implemented for constant distribution.
+If you'd like to extend the functionality of how votes are distributed among users, you need to extend [InitialVoiceCreditProxy](https://github.com/privacy-scaling-explorations/maci/blob/main/contracts/contracts/initialVoiceCreditProxy/InitialVoiceCreditProxy.sol) contract. You can see our [basic example](https://github.com/privacy-scaling-explorations/maci/blob/main/contracts/contracts/initialVoiceCreditProxy/ConstantInitialVoiceCreditProxy.sol) how it's implemented for constant distribution.
 
 ```javascript
 // SPDX-License-Identifier: MIT

package/versioned_docs/version-v1.2/key-change.md

@@ -178,5 +178,5 @@ expect(stateLeaf2.pubKey.equals(user2Keypair.pubKey)).to.eq(true);
 We see that is important that we set the final message (the one with the new vote) with nonce 1, as this vote would be counted as the first vote.
 
 :::info
-Tests related to key changes have been added to the [core package](https://github.com/privacy-scaling-explorations/maci/blob/dev/core/ts/__tests__/) and to the [cli package](https://github.com/privacy-scaling-explorations/maci/blob/dev/cli/tests/).
+Tests related to key changes have been added to the [core package](https://github.com/privacy-scaling-explorations/maci/blob/main/core/ts/__tests__/) and to the [cli package](https://github.com/privacy-scaling-explorations/maci/blob/main/cli/tests/).
 :::

package/versioned_docs/version-v1.2/poll-types.md

@@ -13,7 +13,7 @@ This document will explain how to use each of these options.
 
 ## Quadratic Voting
 
-MACI has always worked with quadratic voting. Users signing up to MACI are assigned a number of voice credits based on certain conditions (enforced by the [initial voice credit proxy contract](https://github.com/privacy-scaling-explorations/maci/blob/dev/contracts/contracts/initialVoiceCreditProxy/InitialVoiceCreditProxy.sol)), and after each vote, the number of voice credits is reduced by the square of the weight of the vote casted. For instance, if the vote weight is 5, a user must have at least 25 voice credits to cast the vote.
+MACI has always worked with quadratic voting. Users signing up to MACI are assigned a number of voice credits based on certain conditions (enforced by the [initial voice credit proxy contract](https://github.com/privacy-scaling-explorations/maci/blob/main/contracts/contracts/initialVoiceCreditProxy/InitialVoiceCreditProxy.sol)), and after each vote, the number of voice credits is reduced by the square of the weight of the vote casted. For instance, if the vote weight is 5, a user must have at least 25 voice credits to cast the vote.
 
 To run a poll with quadratic voting, the coordinator must set the `useQuadraticVoting` parameter to `true` when creating the MACI instance. This will make the MACI instance use the `Tally` smart contract, which is the one that has been used since the beginning of MACI.
 

package/versioned_docs/version-v1.2/testing-in-detail.md

@@ -171,7 +171,7 @@ Within the circuits folder, there are a number of tests that are used to verify
 
 These tests often use mock data from the `core` package. For instance, when testing the `processMessages` circuit, we are required to generate the parameters from the `core` packing, using the `Poll:processMessages` function. The same applies to vote tallying, where we need the `Poll:tally` function to be run first with mock users and vote messages.
 
-All of the tests run using test parameters, usually `10, 2, 1, 2`, aside from the tests inside: [`ceremonyParam`](https://github.com/privacy-scaling-explorations/maci/blob/dev/circuits/ts/__tests__/CeremonyParams.test.ts) which use the parameters of the latest MACI ceremony. More details on the trusted setup can be found [here](/docs/v1.2/trusted-setup).
+All of the tests run using test parameters, usually `10, 2, 1, 2`, aside from the tests inside: [`ceremonyParam`](https://github.com/privacy-scaling-explorations/maci/blob/main/circuits/ts/__tests__/CeremonyParams.test.ts) which use the parameters of the latest MACI ceremony. More details on the trusted setup can be found [here](/docs/v1.2/trusted-setup).
 
 ### Core
 
@@ -179,7 +179,7 @@ The core package contains a number of tests that are used to verify that the cor
 
 These tests interact with the crypto and dombinobjs packages, where mock data comes from. Their main goal is to ensure that the core functions work as expected, and that the state is as expected after a series of operations.
 
-Currently, there is a blend of e2e and unit tests, where e2e tests are used to verify that the entire MACI local processing works as expected (users signup, publish votes, messages are processed and finally these votes are tallied). Unit tests on the other hand are used to verify that the core functions work as expected, such as `processMessage` and `tallyVotes`. You will find them in separate files, with e2e being [here](https://github.com/privacy-scaling-explorations/maci/blob/dev/core/ts/__tests__/e2e.test.ts) and unit tests in the other files.
+Currently, there is a blend of e2e and unit tests, where e2e tests are used to verify that the entire MACI local processing works as expected (users signup, publish votes, messages are processed and finally these votes are tallied). Unit tests on the other hand are used to verify that the core functions work as expected, such as `processMessage` and `tallyVotes`. You will find them in separate files, with e2e being [here](https://github.com/privacy-scaling-explorations/maci/blob/main/core/ts/__tests__/e2e.test.ts) and unit tests in the other files.
 
 ### Domainobjs/Crypto tests
 
@@ -187,7 +187,7 @@ These tests are used to verify that MACI's primitives such as private keys work
 
 ## "Manual" Testing
 
-To ensure that the MACI stack works as expected, without having to run the entire test suite (or even just the e2e tests), there is a [bash script](https://github.com/privacy-scaling-explorations/maci/blob/dev/cli/testScript.sh) inside the cli folder which can be used.
+To ensure that the MACI stack works as expected, without having to run the entire test suite (or even just the e2e tests), there is a [bash script](https://github.com/privacy-scaling-explorations/maci/blob/main/cli/testScript.sh) inside the cli folder which can be used.
 
 This script contains a number of actions which touch all of the parts of MACI, and resemble exactly what other e2e tests do.
 

package/versioned_docs/version-v1.2/testing.md

@@ -87,7 +87,7 @@ circuits.
 Note the locations of the `.zkey` files as the CLI requires them as
 command-line flags.
 
-For testing purposes you can download the required artifacts using the [`download_zkeys`](https://github.com/privacy-scaling-explorations/maci/blob/dev/integrationTests/scripts/download_zkeys.sh) script inside the `integrationTests/scripts` folder. The script will place all required artifacts inside the `cli/zkeys` folder.
+For testing purposes you can download the required artifacts using the [`download_zkeys`](https://github.com/privacy-scaling-explorations/maci/blob/main/integrationTests/scripts/download_zkeys.sh) script inside the `integrationTests/scripts` folder. The script will place all required artifacts inside the `cli/zkeys` folder.
 You can run the script directly with bash or use pnpm: `pnpm run download:test-zkeys` from the monorepo root.
 
 ### Compile the circuits and generate zkeys (if decided to generate from scratch)

package/versioned_docs/version-v1.2/topup.md

@@ -13,7 +13,7 @@ In a nutshell, this feature was added to support some application like quadratic
 
 ## How topup messages are processed
 
-Topup messages are submitted on chain using the same smart contract used for voting, [`Poll`](https://github.com/privacy-scaling-explorations/maci/blob/dev/contracts/contracts/Poll.sol). With the current design, a TopUpCredit token smart contract is required. In this implementation of MACI, there is an example token, which is an ERC20 contract with 1 decimal, of which the coordinator (or MACI's operator) has ownership of. This privileged figure can mint tokens to users (at their discretion) and users will need to deposit such tokens to the Poll contract in order to topup their voice credits.
+Topup messages are submitted on chain using the same smart contract used for voting, [`Poll`](https://github.com/privacy-scaling-explorations/maci/blob/main/contracts/contracts/Poll.sol). With the current design, a TopUpCredit token smart contract is required. In this implementation of MACI, there is an example token, which is an ERC20 contract with 1 decimal, of which the coordinator (or MACI's operator) has ownership of. This privileged figure can mint tokens to users (at their discretion) and users will need to deposit such tokens to the Poll contract in order to topup their voice credits.
 
 :::info
 MACI is not concerned with the way of distributing such tokens. The operators of the MACI instance should implement their own way of distributing such tokens, as well as withdrawing them from the Poll contract. For instance, if the operator chooses to use a token with a monetary value, the Poll balance could be withdrawn and sent to fund public goods.

package/versioned_docs/version-v1.2/typedoc/core/index.md

@@ -18,7 +18,7 @@ contracts in discrete components which are easy to test.
 
 To this end, this submodule exposes a `MaciState` class and a `Poll` class.
 Developers should instantiate objects from these classes to test MACI. For
-instance, [`MACI.test.ts`](https://github.com/privacy-scaling-explorations/maci/blob/dev/packages/contracts/tests/MACI.test.ts) creates a
+instance, [`MACI.test.ts`](https://github.com/privacy-scaling-explorations/maci/blob/main/packages/contracts/tests/MACI.test.ts) creates a
 `MaciState` object and every time it interacts with the MACI smart contract, it
 mirrors said interaction on the `MaciState` and `Poll`. As such, the developer
 can then use their helper functions like `maciState.signUp()`,
@@ -38,7 +38,7 @@ call `maciState.signUp()` as well, so that the off-chain representation of MACI
 is kept up to date.
 
 In production, `genMaciStateFromContract()` in
-[`genMaciState.ts`](https://github.com/privacy-scaling-explorations/maci/blob/dev/contracts/ts/genMaciState.ts) uses this function when it
+[`genMaciState.ts`](https://github.com/privacy-scaling-explorations/maci/blob/main/contracts/ts/genMaciState.ts) uses this function when it
 scans a MACI contract's event log for signups, so as to bring its `MaciState`
 instance up to date.