@maci-protocol/website 0.0.0-ci.00107eb

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

@@ -0,0 +1,153 @@
+---
+title: What is MACI?
+description: High-level introduction to Minimum Anti-Collusion Infrastructure (MACI)
+sidebar_label: What is MACI?
+sidebar_position: 1
+---
+
+# Welcome to MACI
+
+![MACI card](/img/maci-card.png)
+
+## What is MACI?
+
+**Minimal Anti-Collusion Infrastructure (MACI)** is an open-source public good that serves as infrastructure for private on-chain voting.
+
+MACI is an Ethereum application that provides privacy and collusion resistance for on-chain voting, both in a [quadratic](https://vitalik.eth.limo/general/2019/12/07/quadratic.html) and non-quadratic fashion. A common problem among today’s on-chain voting (or public good funding) processes is how easy it is to bribe voters into voting for a particular option. Since all transactions on the blockchain are public by default, without MACI, voters can easily prove to the briber which option they voted for and therefore receive the bribe rewards.
+
+MACI counters this problem by using encryption and zero-knowledge proofs (zk-SNARKs) to hide how each person voted while still publicly revealing the final result. User’s cannot prove which option they voted for, and therefore bribers cannot reliably trust that a user voted for their preferred option. For example, a voter can tell a briber that they are voting for option A, but in reality they voted for option B. There is no reliable way to prove which option the voter actually voted for, so the briber has less incentive to pay voters to vote their way.
+
+Applications like [clr.fund](https://clr.fund/) or protocols like [Allo](https://github.com/gitcoinco/MACI_QF) build atop MACI to increase
+user privacy and discourage collusion or bribery for public goods funding.
+
+## Why MACI Matters
+
+To understand the promise of on-chain voting and the purpose of MACI, we highly recommend reading [Vitalik's post on blockchain voting](https://vitalik.eth.limo/general/2021/05/25/voting2.html). He provides an overview of the incredible potential of e-voting and why blockchains are an excellent technology to implement e-voting solutions on top of.
+
+Below we attempt to summarize some of the points laid out in that post:
+
+### Security requirements of a voting system
+
+Any voting system requires a few crucial security properties in order to be trusted by users:
+
+- **Correct execution**: the result (tally of votes) must be correct, and the result must be guaranteed by a transparent process (so that everyone is convinced that the result is correct)
+- **Censorship resistance**: anyone eligible to vote should be able to vote, and it should not be possible to interfere with anyone's attempt to vote or to prevent anyone’s vote from being counted
+- **Privacy:** you should not be able to tell which candidate someone specific voted for, or even if they voted at all
+- **Coercion resistance:** you should not be able to prove to someone else how you voted, even if you want to
+
+### Voting systems
+
+Looking at various approaches to implement a voting system, we can see how they compare across these properties.
+
+#### In-person voting systems
+
+In short, it's hard to know for sure how current voting systems operate. Governments and corporations spend lots of resources on their systems and processes in an attempt to ensure their integrity, but ultimately neither the systems nor the processes are fully auditable, so we must trust that these security properties are being enforced.
+
+|                       | In-person |
+| --------------------- | --------- |
+| Correct execution     | 🤷‍♂️        |
+| Censorship resistance | 🤷‍♂️        |
+| Privacy               | 🤷‍♂️        |
+| Collusion resistance  | 🤷‍♂️        |
+
+#### Blockchain voting systems
+
+Blockchains provide two key properties: correct execution and censorship resistance. In terms of execution, the blockchain accepts inputs (transaction) from users, correctly processes them according to some pre-defined rules, and returns the correct output. No one is able to change the rules. Any user that wants to send a transaction and is willing to pay a high enough fee can send the transaction and expect to see it quickly included on-chain.
+
+By default, however, Blockchain voting applications face challenges. Ethereum, like most blockchains, is completely transparent - all transaction data is public, so there is no privacy for voters or their votes. This makes bribery very easy as a result: someone can easily show a transaction receipt that proves how they voted. In some cases, bribery can be completely automated via smart contracts to make collusion entirely trustless.
+
+|                       | In-person | Ethereum |
+| --------------------- | --------- | -------- |
+| Correct execution     | 🤷‍♂️        | ✅       |
+| Censorship resistance | 🤷‍♂️        | ✅       |
+| Privacy               | 🤷‍♂️        | ❌       |
+| Collusion resistance  | 🤷‍♂️        | ❌       |
+
+#### Blockchain voting systems (with ZKPs)
+
+Enter zero-knowledge proofs (ZKPs), which when combined with blockchains like Ethereum, can enable private on-chain voting but maintain public on-chain results that are verifiable by anyone (including smart contracts). Vote tallying takes place off-chain but ZKPs are submitted and verified on-chain, which guarantees votes are counted correctly without revealing the individual votes.
+
+|                       | In-person | Ethereum | Ethereum w/ ZK |
+| --------------------- | --------- | -------- | -------------- |
+| Correct execution     | 🤷‍♂️        | ✅       | ✅             |
+| Censorship resistance | 🤷‍♂️        | ✅       | ✅             |
+| Privacy               | 🤷‍♂️        | ❌       | ✅             |
+| Collusion resistance  | 🤷‍♂️        | ❌       | ✅             |
+
+This, in essence, is why MACI exists. By combining these technologies in novel ways, we believe we can achieve all the core security properties that a voting system must have.
+
+## Features
+
+MACI offers the following guarantees:
+
+| Property                 | Description                                                                                                             |
+| ------------------------ | ----------------------------------------------------------------------------------------------------------------------- |
+| **Collusion Resistance** | No one except a trusted coordinator should be certain of the validity of a vote, reducing the effectiveness of bribery. |
+| **Receipt-freeness**     | No one can prove (besides to the coordinator) which way they voted.                                                     |
+| **Privacy**              | No one except a trusted coordinator should be able to decrypt a vote.                                                   |
+| **Uncensorability**      | No one — not even the trusted coordinator, should be able to censor a vote.                                             |
+| **Unforgeability**       | Only the owner of a user's private key may cast a vote tied to its corresponding public key.                            |
+| **Non-repudiation**      | No one may modify or delete a vote after it is cast, although a user may cast another vote to nullify it.               |
+| **Correct execution**    | No one, not even the trusted coordinator, should be able to produce a false tally of votes.                             |
+
+Under the hood, MACI uses Ethereum smart contracts, ECDH encryption, and zero-knowledge proofs.
+It inherits security and uncensorability from the underlying Ethereum
+blockchain, ensures unforgeability via asymmetric encryption, and achieves
+collusion resistance, privacy, and correct execution via zk-SNARK proofs.
+
+The participants of a MACI voting process are: 1) the voters and 2) a trusted coordinator. The coordinator is in charge of setting up the system, deploying polls, and computing the tally of the votes. Through smart contracts and ZK-proofs, MACI ensures that everything is done in a fair manner. Although MACI can provide collusion resistance only if the coordinator is honest, a dishonest coordinator can neither censor nor tamper with its execution.
+
+Note that MACI presumes an identity system where each legitimate member
+controls a unique Ethereum private key.
+
+For information on MACI's latest features, please check out our [MACI v2.0.0 release post](/blog/2024-v2).
+
+## Background
+
+MACI was originally proposed by Vitalik Buterin in [this ethresear.ch
+post](https://ethresear.ch/t/minimal-anti-collusion-infrastructure/5413) and has been maintained and improved since thanks to support from the Ethereum Foundation. For a general overview, the history and the importance of MACI, see [Release Announcement: MACI 1.0](/blog/maci-1-0-release) by Wei Jie, one of the creators. He also created a helpful [overview of MACI video](https://www.youtube.com/watch?v=sKuNj_IQVYI). Kyle Charbonnet wrote a great [Technical Introduction to MACI 1.0](/blog/maci-1-0-technical-introduction) that provides a walkthrough on how MACI operates.
+
+## Credits
+
+MACI is a public good infrastructure that is supported by the [Ethereum Foundation](https://ethereum.foundation/) within [Privacy & Scaling Explorations (PSE)](https://pse.dev/). It's also continuously improved by our open source community! Many people have contributed to MACI, but below are some notable contributors.
+
+**[MACI v1.0](/blog/maci-1-0-release) was originally developed by:**
+
+- [Barry WhiteHat](https://github.com/barryWhiteHat)
+- [Cory Dickson](https://github.com/corydickson)
+- [Chih-Cheng Liang](https://twitter.com/ChihChengLiang)
+- [Han Jian](https://han0110.github.io/)
+- [Kendrick Tan](https://kndrck.co/)
+- [Kirill Goncharov](https://github.com/xuhcc)
+- [Kobi Gurkan](http://kobi.one/)
+- [Koh Wei Jie](https://kohweijie.com)
+- [Samuel Gosling](https://twitter.com/xGozzy)
+
+**[MACI v1.1.1](/blog/maci-v1-1-1-release) was primarily developed by:**
+
+- [ctrlc03](https://github.com/ctrlc03)
+- [chaosma](https://github.com/chaosma)
+- [baumstern](https://github.com/baumstern)
+- [daodesigner](https://github.com/daodesigner)
+- [0xjei](https://github.com/0xjei)
+
+**[MACI v1.2 till v3.0](/blog/2024-v2) was primarily developed by:**
+
+- [ctrlc03](https://github.com/ctrlc03)
+- [samajammin](https://github.com/samajammin)
+- [0xmad](https://github.com/0xmad)
+- [kittybest](https://github.com/kittybest)
+- [crisgarner](https://github.com/crisgarner)
+
+**Currently, MACI (v3.0 and beyond) is maintained and continuously improved by a core development team:**
+
+- [ctrlc03](https://github.com/ctrlc03)
+- [0xmad](https://github.com/0xmad)
+- [nicoserranop](https://github.com/NicoSerranoP)
+- [john](https://github.com/JohnGuilding)
+
+Our core team continues to work on improving the protocol and its documentation with help from our open source community.
+
+:::info
+If you are using one of the previous versions of MACI, see the [MACI v2.0](/docs/v2.x/introduction) documentation.
+:::

package/versioned_docs/version-v3.x/processes/_category_.json

@@ -0,0 +1,4 @@
+{
+  "label": "Processes",
+  "position": 11
+}

package/versioned_docs/version-v3.x/processes/ci-pipeline.md

@@ -0,0 +1,38 @@
+---
+title: CI Pipeline
+description: Introduction to how MACI's CI works
+sidebar_label: CI
+sidebar_position: 2
+---
+
+# Continuous Integration (CI) Pipeline
+
+CI (Continuous Integration) pipeline is an automated workflow to ensure that software is always in a working state. An event like opening a pull request causes a pipeline to run. The pipeline consists of an automated build process and a suite of automated tests (See [Testing](https://pse.dev/docs/guides/testing) for more details).
+
+![cicd-maci drawio-7](https://user-images.githubusercontent.com/1610146/185962260-091cd952-5444-44f3-89e3-be64e81d4c21.png)
+
+## Pipeline Triggers
+
+### Commit to Main Branch
+
+Each commit (i.e. a merged PR) to the main branch triggers the pipeline. The pipeline creates packages that can be deployed to any environment. Packages are uploaded to an artifact repository (e.g. npm).
+
+![cicd-maci drawio-12](https://user-images.githubusercontent.com/1610146/183404579-8bcb76fe-34b6-4748-a5ae-e2e4b010bd86.png)
+
+### Pull Request (PR)
+
+When a pull request has been created (or updated), it triggers the PR pipeline. It gives the reviewer confidence that the software works as expected with the introduced code changes.
+
+![cicd-maci drawio-9](https://user-images.githubusercontent.com/1610146/183391880-d3a20f29-2708-4d72-988d-4781c0396e48.png)
+
+### Nightly
+
+Nightly build runs every midnight. It is to ensure that all required dependencies are present and to show no bugs have been introduced.
+
+![cicd-maci drawio-11](https://user-images.githubusercontent.com/1610146/183404455-cc2aaace-fe52-40f4-b5e4-3c852c5ff516.png)
+
+### Tag Push
+
+When a tag has been pushed, it triggers a release pipeline. It will draft a release note with an auto-generated changelog and publish npm package(s).
+
+![cicd-maci drawio-5](https://user-images.githubusercontent.com/1610146/185958513-51dadaf1-7f72-404b-b482-149b91edcaab.png)

package/versioned_docs/version-v3.x/processes/versioning.md

@@ -0,0 +1,94 @@
+---
+title: MACI versioning and release process
+description: How MACI's versioning and release process works
+sidebar_label: MACI versioning
+sidebar_position: 1
+---
+
+# MACI versioning and release process
+
+This document outlines the approach to versioning and releasing the MACI project. The primary goal here is to set clear expectations and provide a consistent user experience for developers integrating MACI and its packages.
+
+## MACI code
+
+MACI code consists 3 core parts: Circom circuits, Solidity contracts and JS (TS) libraries, from which we release a total of 7 NPM packages. See the [codebase overview](/docs/technical-references/) for more details.
+
+## MACI versioning
+
+MACI follows the [Semantic Versioning Specification (SemVer)](https://semver.org/).
+
+All MACI packages are organized in our monorepo and follow a global release approach, meaning that all packages have the same version.
+
+Currently, MACI core team manually decides when to release and what the version should be. Packages are released [automatically via CI](https://github.com/privacy-scaling-explorations/maci/blob/main/.github/workflows/release.yml) when a new tag is created in GitHub. [You can view our releases and tags in GitHub](https://github.com/privacy-scaling-explorations/maci/releases).
+
+## MACI Release Process
+
+To release a new version of MACI, follow these steps:
+
+:::warning
+Version number '1.2.3' is used here as an example. You should replace the version number '1.2.3' with the version number you are planning to release
+:::
+
+1. Verify that tests have passed on GitHub Actions
+
+2. Clone maci:
+
+```
+git clone https://github.com/privacy-scaling-explorations/maci
+```
+
+3. Switch to the `main` branch:
+
+```
+git checkout main
+```
+
+4. Install required dependencies:
+
+```
+pnpm install
+```
+
+5. Run `lerna version` to update CHANGELOG and version numbers of sub-packages:
+
+```
+pnpm exec lerna version --no-push --no-git-tag-version --conventional-commits 1.2.3
+```
+
+6. Commit changes:
+
+```
+git commit --message "chore(release): publish 1.2.3"
+```
+
+7. Push changes and create a pull request
+
+After the pull request has been merged:
+
+8. Retrieve merged commit
+
+9. Add a tag:
+
+```
+git tag --sign v1.2.3 --message v1.2.3
+```
+
+10. Publish tag:
+
+```
+git push v1.2.3
+```
+
+Once the tag is pushed, GitHub Actions will automatically publish the packages to npm.js and create a release on GitHub.
+
+---
+
+The following packages will be published on NPM:
+
+- [`@maci-circuits`](https://www.npmjs.com/package/maci-circuits)
+- [`@maci-contracts`](https://www.npmjs.com/package/maci-contracts)
+- [`@maci-cli`](https://www.npmjs.com/package/maci-cli)
+- [`@maci-core`](https://www.npmjs.com/package/maci-core)
+- [`@maci-crypto`](https://www.npmjs.com/package/maci-crypto)
+- [`@maci-domainobjs`](https://www.npmjs.com/package/maci-domainobjs)
+- [`@maci-integrationtests`](https://www.npmjs.com/package/maci-integrationtests)

package/versioned_docs/version-v3.x/quick-start.md

@@ -0,0 +1,326 @@
+---
+title: Quick Start
+description: Getting with MACI
+sidebar_label: Quick Start
+sidebar_position: 2
+---
+
+# Quick Start
+
+## Requirements
+
+You need the following to use MACI:
+
+- Node.js: use a JS toolchain manager like [`nvm`](https://github.com/nvm-sh/nvm) or [`volta`](https://volta.sh/) to install Node.js. We recommend using Node 20 or above.
+- [pnpm](https://pnpm.io/installation): Fast, disk space efficient package manager.
+
+## Installation
+
+To install MACI you need to run the following commands:
+
+```bash
+git clone https://github.com/privacy-scaling-explorations/maci.git && \
+cd maci && \
+pnpm install && \
+pnpm run build
+```
+
+:::note
+We suggest you use the latest released version. You can check all the releases [here](https://github.com/privacy-scaling-explorations/maci/releases).
+:::
+
+#### Decide whether you need to compile new circuits or use the test ones
+
+If you are going to be making any changes to the circom circuits, then you can follow the [compile circuits guide](./guides/compile-circuits.md) and skip the next section.
+
+### Download the zero knowledge artifacts
+
+MACI has two main zk-SNARK circuits, and each of them is parameterized. In order to prove and verify them we need to use the `.zkey` Artifacts. 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](/docs/security/trusted-setup) page.
+
+:::important
+Note the locations of the `.zkey` files cause you will need it when deploying contracts.
+:::
+
+#### Download test artifacts
+
+For all but production use cases, we suggest using the test artifacts, with the latest dev updates you can do it by running:
+
+```bash
+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:
+
+```bash
+pnpm download-zkeys:ceremony
+```
+
+:::info
+Currently, the ceremony artifacts work with MACI version up to 2.x
+:::
+
+## Deploy Contracts
+
+### 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 command in the root of the project:
+
+```bash
+pnpm run generate-maci-keypair
+```
+
+### Set the .env
+
+Head to the `packages/contracts` folder and copy the `.env.example` file.
+
+```bash
+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).
+
+```js
+MNEMONIC = "your_ethereum_secret_key";
+NETWORK_RPC_URL = "the_eth_provider_url";
+NETWORK_ETHERSCAN_API_KEY = "etherscan api key";
+```
+
+### Set the configuration file
+
+In the folder and copy the config example and update the fields as necessary:
+
+```bash
+cd ./packages/contracts && \
+cp deploy-config-example.json deploy-config.json
+
+```
+
+#### ConstantInitialVoiceCreditProxy
+
+Specifies the number of credits allocated to each voter.
+
+| Property   | Description                                              |
+| ---------- | -------------------------------------------------------- |
+| **deploy** | Defines if the contract needs to be deployed.            |
+| **amount** | Defines how many vote credits each participant will get. |
+
+#### Policy
+
+MACI uses a "policy" 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 [policy page in the documentation](/docs/technical-references/smart-contracts/Policies) for more information on the supported Policies.
+
+| Property   | Description                                      |
+| ---------- | ------------------------------------------------ |
+| **deploy** | Defines if the contract is going to be deployed. |
+
+:::important
+For testing we suggest using the **FreeForAlPolicy** as it allows anyone to signup on MACI.
+:::
+
+#### MACI
+
+| Property           | Description                                 |
+| ------------------ | ------------------------------------------- |
+| **stateTreeDepth** | Defines how many users the system supports. |
+| **policy**         | Defines which policy to use.                |
+
+#### VerifyingKeysRegistry
+
+The VerifyingKeysRegistry 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.
+
+| Property                          | Description                                                                          |
+| --------------------------------- | ------------------------------------------------------------------------------------ |
+| **stateTreeDepth**                | Defines how many users the system supports.                                          |
+| **tallyProcessingStateTreeDepth** | Defines how many ballots can be processed per batch when tallying the results.       |
+| **messageTreeDepth**              | Defines how many messages (votes) the system supports.                               |
+| **voteOptionTreeDepth**           | Defines how many vote options the system supports.                                   |
+| **messageBatchDepth**             | Defines how many messages in a batch can the circuit process.                        |
+| **zkeys**                         | Defines the path to the zkey files for QV, Non QV and Full Credits keys.             |
+| **pollJoiningZkey**               | Defines the zkey to the poll joining circuit which allows to join polls for voting.  |
+| **pollJoinedZkey**                | Defines the zkey to the poll joined circuit which allows to prove you joined a poll. |
+
+:::important
+The recommended values for test keys are: **10-1-2-2-1**. For ceremony keys: **14-5-9-3-2**.
+:::
+
+#### Poll
+
+| Property                    | Description                                                       |
+| --------------------------- | ----------------------------------------------------------------- |
+| **pollStartDate**           | Defines when the poll starts in seconds.                          |
+| **pollEndDate**             | Defines how long is going to be the poll in seconds.              |
+| **coordinatorPublicKey**    | Defines the coordinator public MACI key.                          |
+| **useQuadraticVoting**      | Defines if the poll uses quadratic voting or not.                 |
+| **policy**                  | Defines the policy of the poll.                                   |
+| **relayers**                | Defines an array of addresses that are allowed to relay messages. |
+| **initialVoiceCreditProxy** | Defines the type of voice credit proxy to use for this poll.      |
+| **voteOptions**             | Defines how many votes options are valid for this poll.           |
+
+### 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 available networks on the package.json scripts section.
+
+```bash
+pnpm deploy:NETWORK
+```
+
+There are already some deployed contracts that could be reused, copy the `default-deployed-contracts.json` file if you need them to avoid deploying redundant contracts and save your gas fee.
+
+```bash
+cp default-deployed-contracts.json deployed-contracts.json
+```
+
+Delete any contract you want to redeploy and then run the following command to save gas:
+
+```bash
+pnpm deploy:NETWORK --incremental
+```
+
+### 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:
+
+```sh
+pnpm deploy-poll:NETWORK
+```
+
+:::important
+Starting another poll doesn't require deploying MACI contracts again, you can run `pnpm deploy-poll:NETWORK` command and then use the new poll-id.
+:::
+
+## Poll Finalization
+
+As a coordinator, first you need to merge signups and messages (votes). 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:
+
+```bash
+pnpm merge:[network] --poll [poll-id]
+```
+
+:::info
+`poll-id` starts at 0 and increments for each deployed poll
+:::
+
+Then you need to generate the proofs for the message processing, and tally calculations. This allows to publish the poll results on-chain and then everyone can verify the results:
+
+```bash
+pnpm run prove:[network] --poll [poll-id] \
+    --coordinator-private-key [coordinator-maci-private-key] \
+    --tally-file ../results/tally.json \
+    --output-dir ../results/proofs/ \
+    --start-block [block-number] \
+    --blocks-per-batch [number-of-blocks]
+```
+
+:::info
+The `--coordinator-private-key` is the one you generated earlier with `pnpm run generate-maci-keypair`.
+
+`--start-block` is the block number from which to start looking for events from. You can use the block that you deployed the contracts in.
+
+You can reduce the time of the proving by including more blocks per batch with `--blocks-per-batch`, you can try with 500.
+:::
+
+#### Submit On-chain
+
+Now it's time to submit the poll results on-chain so that everyone can verify the results:
+
+```bash
+pnpm submitOnChain:[network] --poll [poll-id] \
+    --output-dir ../results/proofs/ \
+    --tally-file ../results/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:
+
+```json
+{
+  "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"
+  },
+  "perVoteOptionSpentVoiceCredits": {
+    "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 `perVoteOptionSpentVoiceCredits` 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.

package/versioned_docs/version-v3.x/resources.md

@@ -0,0 +1,34 @@
+---
+title: Resources
+description: A collection of resources for better understanding MACI
+sidebar_label: Resources
+sidebar_position: 13
+---
+
+## Articles
+
+- [ethresear](https://ethresear.ch/t/minimal-anti-collusion-infrastructure/5413) - Vitalik Buterin 05/2019
+- [MACI Anonymization](https://ethresear.ch/t/maci-anonymization-using-rerandomizable-encryption/7054) - Kobi Gurkan 03/2020
+- [Release Announcement: MACI 1.0](/blog/maci-1-0-release) - Koh Wei Jie 05/2020
+- [Technical Introduction to MACI 1.0](/blog/maci-1-0-technical-introduction) - Kyle Charbonnet 01/2022
+- [MACI v1.1.1 Release](/blog/maci-v1-1-1-release) - ctrlc03 && chaosma 01/2023
+- [MACI v1.2.0 release post](/blog/maci-v1-2-0-release) - ctrlc03 02/2024
+- [MACI v2.0.0 release post](/blog/2024-v2) - ctrlc03 08/2024
+- [Getting Started With MACI](https://medium.com/@bbaraona/getting-started-with-maci-5cc145d00e04) - Benjamin Barahona 12/04/2024
+
+## Videos
+
+- [Overview of MACI](https://www.youtube.com/watch?v=sKuNj_IQVYI) - Koh Wei Jie 05/2020
+- [Making sense of MACI](https://www.youtube.com/watch?v=ooxgPzdaZ_s) - Koh Wei Jie 08/2020
+- [MACI on ZKPodcast](https://www.youtube.com/watch?v=f9nUGPD5I3o) - Koh Wei Jie 12/2020
+- [Anonymity in MACI](https://www.youtube.com/watch?v=X54LaXfJTn4) - Marija Mikić 07/2023
+- [Seeing like a Voting](https://youtu.be/euhugXsTUgY?si=jNhqmvFYD9F0r-tB) - Daehyun 11/2023
+- [MACI - Private Voting](https://www.youtube.com/watch?v=85bZwcQIgEo&t=1382s) - ctrlc03 03/2024
+- [Construyendo votaciones privadas onchain con MACI](https://www.youtube.com/watch?v=3u5VJJsKLfg) - Crisgarner 03/2024
+- [MACI - Starting From Scratch](https://www.youtube.com/watch?v=qVuhWlHnQF0) - Doris Chan 03/2024
+- [MACI Workshop](https://www.youtube.com/watch?v=AimgqnMjG0o) - ctrlc03 04/2024
+- [MACI Starter Kit Demo](https://www.youtube.com/watch?v=pYoBLLtVEoI&t=1s) - Yash 05/2024
+- [The Promise of Blockchain Voting](https://www.youtube.com/watch?v=TQxR7U52ne0) - Sam Richards 06/2024
+- [MACI Tutorial Deploying Contracts and Subgraph](https://www.youtube.com/watch?v=-QA0VB9EUMk) - Crisgarner 09/2024
+- [MACI Tutorial Frontend Deployment 🚀](https://www.youtube.com/watch?v=q0yS8RfwDcw) - Crisgarner 09/2024
+- [Finalizing a MACI Round](https://www.youtube.com/watch?v=nlS3hOC0ljw) - Crisgarner 09/2024

package/versioned_docs/version-v3.x/security/_category_.json

@@ -0,0 +1,4 @@
+{
+  "label": "Security",
+  "position": 8
+}