@maci-protocol/website 0.0.0-ci.4b8eeec → 0.0.0-ci.4bfa285

package/versioned_docs/version-v2.x/technical-references/smart-contracts/MACI.md

@@ -6,7 +6,7 @@ sidebar_position: 1
 ---
 
 :::info
-Code location: [MACI.sol](https://github.com/privacy-scaling-explorations/maci/blob/dev/contracts/contracts/MACI.sol)
+Code location: [MACI.sol](https://github.com/privacy-scaling-explorations/maci/blob/main/contracts/contracts/MACI.sol)
 :::
 
 `MACI.sol` is the core contract of the project, as it provides the base layer for user signups and Polls to be created.

package/versioned_docs/version-v2.x/technical-references/smart-contracts/MessageProcessor.md

@@ -6,7 +6,7 @@ sidebar_position: 4
 ---
 
 :::info
-Code location: [MessageProcessor.sol](https://github.com/privacy-scaling-explorations/maci/blob/dev/contracts/contracts/MessageProcessor.sol)
+Code location: [MessageProcessor.sol](https://github.com/privacy-scaling-explorations/maci/blob/main/contracts/contracts/MessageProcessor.sol)
 :::
 
 This contract is used to prepare parameters for the zk-SNARK circuits as well as for verifying proofs. It should be deployed alongside a `Poll` and ownership assigned to the coordinator.

package/versioned_docs/version-v2.x/technical-references/smart-contracts/Params.md

@@ -6,7 +6,7 @@ sidebar_position: 9
 ---
 
 :::info
-Code location: [Params.sol](https://github.com/privacy-scaling-explorations/maci/blob/dev/contracts/contracts/utils/Params.sol)
+Code location: [Params.sol](https://github.com/privacy-scaling-explorations/maci/blob/main/contracts/contracts/utils/Params.sol)
 :::
 
 A contract holding three structs:

package/versioned_docs/version-v2.x/technical-references/smart-contracts/Poll.md

@@ -6,7 +6,7 @@ sidebar_position: 2
 ---
 
 :::info
-Code location: [Poll.sol](https://github.com/privacy-scaling-explorations/maci/blob/dev/contracts/contracts/Poll.sol)
+Code location: [Poll.sol](https://github.com/privacy-scaling-explorations/maci/blob/main/contracts/contracts/Poll.sol)
 :::
 
 This contract allows users to submit their votes.

package/versioned_docs/version-v2.x/technical-references/smart-contracts/PollFactory.md

@@ -6,7 +6,7 @@ sidebar_position: 3
 ---
 
 :::info
-Code location: [PollFactory.sol](https://github.com/privacy-scaling-explorations/maci/blob/dev/contracts/contracts/PollFactory.sol)
+Code location: [PollFactory.sol](https://github.com/privacy-scaling-explorations/maci/blob/main/contracts/contracts/PollFactory.sol)
 :::
 
 `PollFactory` is a smart contract that is used to deploy new Polls. This is used by MACI inside the `deployPoll` function.

package/versioned_docs/version-v2.x/technical-references/smart-contracts/Tally.md

@@ -6,7 +6,7 @@ sidebar_position: 5
 ---
 
 :::info
-Code location: [Tally.sol](https://github.com/privacy-scaling-explorations/maci/blob/dev/contracts/contracts/Tally.sol)
+Code location: [Tally.sol](https://github.com/privacy-scaling-explorations/maci/blob/main/contracts/contracts/Tally.sol)
 :::
 
 The `Tally` contract is used by the coordinator to submit commitments to the tally results via the `tallyVotes` function. This is done in batches and the final commitment can be used by the users to verify the validity of the results.

package/versioned_docs/version-v2.x/technical-references/smart-contracts/VkRegistry.md

@@ -6,7 +6,7 @@ sidebar_position: 8
 ---
 
 :::info
-Code location: [VkRegistry.sol](https://github.com/privacy-scaling-explorations/maci/blob/dev/contracts/contracts/VkRegistry.sol)
+Code location: [VkRegistry.sol](https://github.com/privacy-scaling-explorations/maci/blob/main/contracts/contracts/VkRegistry.sol)
 :::
 
 The VkRegistry is a contract that holds the verifying keys for the zk-SNARK circuits. It holds two different sets of keys:

package/versioned_docs/version-v2.x/technical-references/smart-contracts/VoiceCreditProxy.md

@@ -6,7 +6,7 @@ sidebar_position: 7
 ---
 
 :::info
-Code location: [InitialVoiceCreditProxy](https://github.com/privacy-scaling-explorations/maci/tree/dev/contracts/contracts/initialVoiceCreditProxy)
+Code location: [InitialVoiceCreditProxy](https://github.com/privacy-scaling-explorations/maci/tree/main/contracts/contracts/initialVoiceCreditProxy)
 :::
 
 The VoiceCreditProxy contract is used to assign voice credits to users. Whichever implementation should the MACI deployers use, this must implement a view function that returns the balance for a user, such as the one below:

package/versioned_docs/version-v2.x/technical-references/zk-snark-circuits/processMessages.md

@@ -5,11 +5,11 @@ sidebar_label: Process Messages Circuit
 sidebar_position: 3
 ---
 
-[**Repo link**](https://github.com/privacy-scaling-explorations/maci/blob/dev/circuits/circom/core)
+[**Repo link**](https://github.com/privacy-scaling-explorations/maci/blob/main/circuits/circom/core)
 
 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.
 
-The [`processMessages`](https://github.com/privacy-scaling-explorations/maci/blob/dev/circuits/circom/core/qv/processMessages.circom) circuit will try to decrypt the messages, and based on the content of the message, update within itself the trees, to generate a proof that the coordinator's off-chain processing was done correctly. In other words, the circuit takes a final state, an initial state, and the leaves (messages and user signups) - it processes these messages via the different state transitions to finally check that the expected state is correct.
+The [`processMessages`](https://github.com/privacy-scaling-explorations/maci/blob/main/circuits/circom/core/qv/processMessages.circom) circuit will try to decrypt the messages, and based on the content of the message, update within itself the trees, to generate a proof that the coordinator's off-chain processing was done correctly. In other words, the circuit takes a final state, an initial state, and the leaves (messages and user signups) - it processes these messages via the different state transitions to finally check that the expected state is correct.
 The pre-requisites for this circuit are:
 
 - the related Poll has ended
@@ -21,7 +21,7 @@ This circuit requires the coordinator's private key, hence a proof for this circ
 ![ProcessMessages](/img/circuits/processMessages_2_0.svg)
 
 :::info
-A version working with non quadratic voting (non-qv) is also [available](https://github.com/privacy-scaling-explorations/maci/blob/dev/circuits/circom/core/non-qv/processMessages.circom). This version is called `processMessagesNonQV` and is to be used when the Poll is not using the quadratic voting feature. Note that by default MACI works with quadratic voting.
+A version working with non quadratic voting (non-qv) is also [available](https://github.com/privacy-scaling-explorations/maci/blob/main/circuits/circom/core/non-qv/processMessages.circom). This version is called `processMessagesNonQV` and is to be used when the Poll is not using the quadratic voting feature. Note that by default MACI works with quadratic voting.
 :::
 
 #### Parameters
@@ -93,7 +93,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.
 

package/versioned_docs/version-v2.x/technical-references/zk-snark-circuits/tallyVotes.md

@@ -5,7 +5,7 @@ sidebar_label: Tally Votes Circuit
 sidebar_position: 4
 ---
 
-[**Repo link**](https://github.com/privacy-scaling-explorations/maci/blob/dev/circuits/circom/core)
+[**Repo link**](https://github.com/privacy-scaling-explorations/maci/blob/main/circuits/circom/core)
 
 #### Parameters
 
@@ -18,7 +18,7 @@ sidebar_position: 4
 ![TallyVotes](/img/circuits/tallyVotes.svg)
 
 :::info
-A version working with non quadratic voting (non-qv) is also [available](https://github.com/privacy-scaling-explorations/maci/blob/dev/circuits/circom/core/non-qv/tallyVotes.circom). This version is called `tallyVotesNonQv` and is to be used when the Poll is not using the quadratic voting feature. Note that by default MACI works with quadratic voting.
+A version working with non quadratic voting (non-qv) is also [available](https://github.com/privacy-scaling-explorations/maci/blob/main/circuits/circom/core/non-qv/tallyVotes.circom). This version is called `tallyVotesNonQv` and is to be used when the Poll is not using the quadratic voting feature. Note that by default MACI works with quadratic voting.
 :::
 
 #### Input signals

package/versioned_docs/version-v2.x/technical-references/zk-snark-circuits/zk-snark-circuits.md

@@ -5,10 +5,10 @@ sidebar_label: zk-SNARK Circuits
 sidebar_position: 1
 ---
 
-MACI has two main zk-SNARK [circuits](https://github.com/privacy-scaling-explorations/maci/tree/dev/circuits):
+MACI has two main zk-SNARK [circuits](https://github.com/privacy-scaling-explorations/maci/tree/main/circuits):
 
-1. ProcessMessages.circom, which takes a batch of encrypted messages, decrypts them, and generates a proof that the coordinator's local processing was performed correctly. [QV](https://github.com/privacy-scaling-explorations/maci/blob/dev/circuits/circom/core/qv/processMessages.circom) and [non-QV](https://github.com/privacy-scaling-explorations/maci/blob/dev/circuits/circom/core/non-qv/processMessages.circom) versions are available.
-2. TallyVotes.circom, which counts votes from users' ballots, batch by batch. [QV](https://github.com/privacy-scaling-explorations/maci/blob/dev/circuits/circom/core/qv/tallyVotes.circom) and [non-QV](https://github.com/privacy-scaling-explorations/maci/blob/dev/circuits/circom/core/non-qv/tallyVotes.circom) versions are available.
+1. ProcessMessages.circom, which takes a batch of encrypted messages, decrypts them, and generates a proof that the coordinator's local processing was performed correctly. [QV](https://github.com/privacy-scaling-explorations/maci/blob/main/circuits/circom/core/qv/processMessages.circom) and [non-QV](https://github.com/privacy-scaling-explorations/maci/blob/main/circuits/circom/core/non-qv/processMessages.circom) versions are available.
+2. TallyVotes.circom, which counts votes from users' ballots, batch by batch. [QV](https://github.com/privacy-scaling-explorations/maci/blob/main/circuits/circom/core/qv/tallyVotes.circom) and [non-QV](https://github.com/privacy-scaling-explorations/maci/blob/main/circuits/circom/core/non-qv/tallyVotes.circom) versions are available.
 
 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.
 

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

@@ -57,13 +57,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 synced 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 synced 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.
 
@@ -131,7 +131,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-v3.x/core-concepts/key-change.md

@@ -175,5 +175,5 @@ expect(stateLeaf2.publicKey.equals(user2Keypair.publicKey)).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-v3.x/core-concepts/maci-keys.md

@@ -78,7 +78,7 @@ Serialized, these will look like **macipk.0e5194a54562ea4d440ac6a0049a41d4b600e3
 After successfully [installing](/docs/quick-start#installation) MACI, you can easily generate your MACI key pair by running:
 
 ```bash
-pnpm run generateMaciKeyPair
+pnpm run generate-maci-keypair
 ```
 
 This command will create the necessary public and private keys required for running various MACI operations.

package/versioned_docs/version-v3.x/core-concepts/poll-types.md

@@ -5,25 +5,25 @@ sidebar_label: Poll types
 sidebar_position: 9
 ---
 
-MACI allows to conduct polls in both a quadratic voting and non quadratic voting fashion. One should be aware that the only distinction between the two happens when messages are processed and votes tallied. On top of that, the Tally smart contract has been split into two different ones, with the non quadratic voting version one being slightly smaller, due to the need of one less function.
+MACI allows to conduct polls in both a quadratic voting and non quadratic voting fashion. One should be aware that the only distinction between the two happens when messages are processed and votes tallied. On top of that, the Tally smart contract has been split into two different ones, with the non quadratic voting version one being slightly smaller, due to the need of one less function. Additionally, there is a variation of non quadratic voting that allows participants to cast their entire voice credit balance for a single option only.
 
 This document will explain how to use each of these options. Hardhat tasks are the currently recommended way to deploy contracts and run polls but you can also use the MACI cli.
 
 ## 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/packages/contracts/contracts/initialVoiceCreditProxy/ConstantInitialVoiceCreditProxy.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 deploy the Poll with the mode set to quadratic voting.
 
 ### Using Hardhat tasks
 
-In the deploy-config.json file set the `useQuadraticVoting` value to **true**.
+In the deploy-config.json file set the `mode` value to **qv**.
 
 ```json
 "Poll": {
     "pollDuration": 604800,
     "coordinatorPublicKey": "macipk",
-    "useQuadraticVoting": true
+    "mode": "qv"
 }
 ```
 
@@ -37,17 +37,41 @@ pnpm deploy-poll:NETWORK
 
 The non quadratic voting option is a new feature that has been added to MACI with the v1.2 release. It allows to conduct polls without the quadratic voting mechanism. This means that the number of voice credits is not reduced by the square of the weight of the vote casted. This option is useful for polls where the quadratic voting mechanism is not necessary, and it is also slightly cheaper for coordinators to tally votes, as there are less checks required in the Tally smart contract.
 
-To run a poll with non quadratic voting, the coordinator must set the `useQuadraticVoting` parameter to `false` when creating the MACI instance. This will make the MACI instance use the `TallyNonQv` smart contract, which is a smaller version of the `Tally` smart contract, as it does not require the checks for the quadratic voting mechanism.
+To run a poll with non quadratic voting, the coordinator must set the `mode` parameter to `non-qv` when creating the MACI instance. This will make the MACI instance use the `TallyNonQv` smart contract, which is a smaller version of the `Tally` smart contract, as it does not require the checks for the quadratic voting mechanism.
 
 ### Using Hardhat tasks
 
-In the deploy-config.json file set the `useQuadraticVoting` value to **false**.
+In the deploy-config.json file set the `mode` value to **non-qv**.
 
 ```json
 "Poll": {
     "pollDuration": 604800,
     "coordinatorPublicKey": "macipk",
-    "useQuadraticVoting": false
+    "mode": "non-qv"
+}
+```
+
+Then run the task to create a poll:
+
+```bash
+pnpm deploy-poll:NETWORK
+```
+
+## Full Credits Voting
+
+Full Credits Voting is a new feature introduced in MACI v3. This voting mode disables the quadratic voting mechanism and requires participants to allocate their entire voice credit balance to a single option. Unlike quadratic voting, where the cost of votes increases quadratically with the number of votes cast, Full Credits Voting uses a linear model: participants spend all their available voice credits on one chosen option. No splitting across multiple options is allowed. This option is useful for polls where the quadratic voting mechanism is not necessary and where it's important to ensure voters fully commit to a single choice—eliminating fragmented or spread-out voting behavior. It also offers a slight cost advantage for coordinators, as tallying is more efficient with fewer checks required in the Tally smart contract.
+
+To run a poll full credits voting, the coordinator must set the `mode` parameter to `full` when creating the MACI instance. This will make the MACI instance use the `TallyNonQv` smart contract, which is a smaller version of the `Tally` smart contract, as it does not require the checks for the quadratic voting mechanism.
+
+### Using Hardhat tasks
+
+In the deploy-config.json file set the `mode` value to **full**.
+
+```json
+"Poll": {
+    "pollDuration": 604800,
+    "coordinatorPublicKey": "macipk",
+    "mode": "full"
 }
 ```
 

package/versioned_docs/version-v3.x/core-concepts/polls.md

@@ -11,7 +11,7 @@ Currently, you can configure the following parameters for a poll:
 
 - Poll duration, in the form of a unix timestamp for start and end times. This allows polls to be scheduled to start at a certain time, and run for a certain amount of time.
 - Vote option - how many vote options are allowed for a poll.
-- Vote mode - quadratic or non quadratic voting. One should be aware that the only distinction between the two happens when messages are processed and votes tallied.
+- Vote mode - quadratic, non quadratic, full credits voting. One should be aware that the only distinction between them happens when messages are processed and votes tallied.
 - Policy - the Excubiae policy that will be used to gate access to the poll.
 - Initial voice credit proxy - the initial voice credit proxy that will be used to assign voice credits to voters.
 - Relayer - the list of addresses that will be able to relay messages on behalf of other users (for now this is recommended to be the coordinator only)
@@ -34,19 +34,19 @@ The full configuration for a poll looks like this:
 
 ## Quadratic Voting
 
-MACI has always worked with quadratic voting. Users joining a Poll 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 joining a Poll 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/packages/contracts/contracts/initialVoiceCreditProxy/ConstantInitialVoiceCreditProxy.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 deploy the Poll with the mode set to quadratic voting.
 
 ### Using Hardhat tasks
 
-In the deploy-config.json file set the `useQuadraticVoting` value to **true**.
+In the deploy-config.json file set the `mode` value to **qv**.
 
 ```json
 "Poll": {
     [...]
     "coordinatorPublicKey": "macipk",
-    "useQuadraticVoting": true
+    "mode": "qv"
 }
 ```
 
@@ -60,17 +60,41 @@ pnpm deploy-poll:NETWORK
 
 The non quadratic voting option is a new feature that has been added to MACI with the v1.2 release. It allows to conduct polls without the quadratic voting mechanism. This means that the number of voice credits is not reduced by the square of the weight of the vote casted. This option is useful for polls where the quadratic voting mechanism is not necessary, and it is also slightly cheaper for coordinators to tally votes, as there are less checks required in the Tally smart contract.
 
-To run a poll with non quadratic voting, the coordinator must set the `useQuadraticVoting` parameter to `false` when creating the MACI instance.
+To run a poll with non quadratic voting, the coordinator must set the `mode` parameter to `non-qv` when creating the MACI instance.
 
 ### Using Hardhat tasks
 
-In the deploy-config.json file set the `useQuadraticVoting` value to **false**.
+In the deploy-config.json file set the `mode` value to **non-qv**.
 
 ```json
 "Poll": {
     [...]
     "coordinatorPublicKey": "macipk",
-    "useQuadraticVoting": false
+    "mode": "non-qv"
+}
+```
+
+Then run the task to create a poll:
+
+```bash
+pnpm deploy-poll:NETWORK
+```
+
+## Full Credits Voting
+
+Full Credits Voting is a new feature introduced in MACI v3. This voting mode disables the quadratic voting mechanism and requires participants to allocate their entire voice credit balance to a single option. Unlike quadratic voting, where the cost of votes increases quadratically with the number of votes cast, Full Credits Voting uses a linear model: participants spend all their available voice credits on one chosen option. No splitting across multiple options is allowed. This option is useful for polls where the quadratic voting mechanism is not necessary and where it's important to ensure voters fully commit to a single choice—eliminating fragmented or spread-out voting behavior. It also offers a slight cost advantage for coordinators, as tallying is more efficient with fewer checks required in the Tally smart contract.
+
+To run a poll with full credits voting, the coordinator must set the `mode` parameter to `full` when creating the MACI instance.
+
+### Using Hardhat tasks
+
+In the deploy-config.json file set the `mode` value to **full**.
+
+```json
+"Poll": {
+    [...]
+    "coordinatorPublicKey": "macipk",
+    "mode": "full"
 }
 ```
 

package/versioned_docs/version-v3.x/core-concepts/spec.md

@@ -580,7 +580,7 @@ Please note that MACI requires the coordinator to generate proofs on an x86 mach
 
 ### 6.1. Message processing circuit
 
-The message processing circuit, defined in `circuits/circom/processMessages.circom`, allows the coordinator to prove that they have correctly applied each message in reverse order, in a consecutive batch of `5 ^ messageBatchDepth` messages to the respective state leaf within the state tree.
+The message processing circuit, defined in `circuits/circom/coordinator/qv/MessageProcessor.circom`, allows the coordinator to prove that they have correctly applied each message in reverse order, in a consecutive batch of `5 ^ messageBatchDepth` messages to the respective state leaf within the state tree.
 
 #### Parameters
 
@@ -747,15 +747,15 @@ The final tally should be:
 2. Total voice credits per vote option: `[3, 9, 19, 33, 26]`
 3. Total spent voice credits: `66`
 
-The coordinator uses the ballot tallying circuit (`tallyVotes.circom`) to generate proofs that they have correctly computed the tally. As there are many ballots to tally, each proof only computes the tally for a batch of ballots. Each proof is chained to the previous one such that each proof is also a proof of knowledge of the preimage of the previous tally commitment.
+The coordinator uses the ballot tallying circuit (`VoteTally.circom`) to generate proofs that they have correctly computed the tally. As there are many ballots to tally, each proof only computes the tally for a batch of ballots. Each proof is chained to the previous one such that each proof is also a proof of knowledge of the preimage of the previous tally commitment.
 
 #### Parameters
 
-| Parameter             | Description                                                                                                             |
-| --------------------- | ----------------------------------------------------------------------------------------------------------------------- |
-| `stateTreeDepth`      | Depth of the state tree, this value must be equal to `10`                                                               |
-| `intStateTreeDepth`   | Depth of the intermediate state tree, `5 ** intStateTreeDepth` is the batch size                                        |
-| `voteOptionTreeDepth` | Depth of the vote option tree, this must be the same value passed to the `deployPoll()` contract function of `MACI.sol` |
+| Parameter                       | Description                                                                                                             |
+| ------------------------------- | ----------------------------------------------------------------------------------------------------------------------- |
+| `stateTreeDepth`                | Depth of the state tree, this value must be equal to `10`                                                               |
+| `tallyProcessingStateTreeDepth` | Depth of the intermediate state tree, `5 ** tallyProcessingStateTreeDepth` is the batch size                            |
+| `voteOptionTreeDepth`           | Depth of the vote option tree, this must be the same value passed to the `deployPoll()` contract function of `MACI.sol` |
 
 #### Input signals
 
@@ -809,7 +809,7 @@ $\mathsf{poseidon_3}([tc_r, tc_t, tc_p])$
 
 1. That the coordinator knows the preimage of `sbCommitment` (see above)
 2. That `index` is less than or equal to `totalSignups`
-3. That each ballot in `ballots` is in a member of the ballot tree with the Merkle root `ballotRoot` at indices `batchStartIndex` to `batchStartIndex + (5 ** intStateTreeDepth)`
+3. That each ballot in `ballots` is in a member of the ballot tree with the Merkle root `ballotRoot` at indices `batchStartIndex` to `batchStartIndex + (5 ** tallyProcessingStateTreeDepth)`
 4. That each set of votes (`votes[i]`) has the Merkle root $blt_r$ whose value equals `ballots[i][1]`
 5. That the tally is valid, which is:
    - That the sum of votes per vote option is correct

package/versioned_docs/version-v3.x/core-concepts/workflow.md

@@ -66,7 +66,7 @@ Therefore, even if a coordinator is corrupt, they are unable to change a user’
 
 To explain the MACI workflow, let's give a quick overview of the key smart contracts.
 
-See our [smart contract docs](/docs/category/smart-contracts) or our [contract source code](https://github.com/privacy-scaling-explorations/maci/tree/dev/contracts/contracts) for a more in-depth explanation of all smart contracts.
+See our [smart contract docs](/docs/category/smart-contracts) or our [contract source code](https://github.com/privacy-scaling-explorations/maci/tree/main/contracts/contracts) for a more in-depth explanation of all smart contracts.
 
 ### MACI.sol
 
@@ -133,7 +133,7 @@ The `MessageProcessor` contract will send the proof to a separate verifier contr
 
 #### Tally Results
 
-Finally, once all messages have been processed, the coordinator tallies the votes of the valid messages (off-chain). The coordinator creates a zk-SNARK proving that the valid messages in the state tree (proved in Process Messages step) contain votes that sum to the given tally result. Then, they call [`Tally.tallyVotes()`](/docs/technical-references/smart-contracts/solidity-docs/Tally#tallyvotes) with a hash of the correct tally results and the zk-SNARK proof. Similarly to the processMessages function, the `tallyVotes` function will send the proof to a verifier contract to ensure that it is valid.
+Finally, once all messages have been processed, the coordinator tallies the votes of the valid messages (off-chain). The coordinator creates a zk-SNARK proving that the valid messages in the state tree (proved in Process Messages step) contain votes that sum to the given tally result. Then, they call [`Tally.tallyVotes()`](/docs/technical-references/smart-contracts/solidity-docs/Tally#tallyvotes) with a hash of the correct tally results and the zk-SNARK proof. Similarly to the `processMessages` function, the `tallyVotes` function will send the proof to a verifier contract to ensure that it is valid.
 
 <!-- "hash of the correct tally results" - so are the final results actually put on chain? or just a hash?? -->
 

package/versioned_docs/version-v3.x/guides/compile-circuits.md

@@ -77,25 +77,25 @@ Remember that if on a ARM64 chip, you will not be able to compile the c++ witnes
 
 ### Configure circomkit
 
-Edit `circuits/circom/circuits` to include the circuits you would like to compile. This comes already configured with the two main coordinator circuits, in both qv and non qv variants, as well as the client side circuit. The parameters are designed to support testing use cases:
+Edit `circuits/circom/circuits` to include the circuits you would like to compile. This comes already configured with the main coordinator circuits, in qv, non qv and full credits variants, as well as the client side circuit. The parameters are designed to support testing use cases:
 
 ```json
 {
   "PollJoining_10_test": {
-    "file": "./anon/voter/PollJoining",
+    "file": "./voter/PollJoining",
     "template": "PollJoining",
     "params": [10],
     "pubs": ["nullifier", "stateRoot", "pollPublicKey", "pollId"]
   },
   "PollJoined_10_test": {
-    "file": "./anon/voter/PollJoined",
+    "file": "./voter/PollJoined",
     "template": "PollJoined",
     "params": [10],
     "pubs": ["stateRoot"]
   },
-  "ProcessMessages_10-20-2_test": {
-    "file": "./core/qv/processMessages",
-    "template": "ProcessMessages",
+  "MessageProcessorQv_10-20-2_test": {
+    "file": "./coordinator/qv/MessageProcessor",
+    "template": "MessageProcessorQv",
     "params": [10, 20, 2],
     "pubs": [
       "totalSignups",
@@ -109,9 +109,9 @@ Edit `circuits/circom/circuits` to include the circuits you would like to compil
       "voteOptions"
     ]
   },
-  "ProcessMessagesNonQv_10-20-2_test": {
-    "file": "./core/non-qv/processMessages",
-    "template": "ProcessMessagesNonQv",
+  "MessageProcessorNonQv_10-20-2_test": {
+    "file": "./coordinator/non-qv/MessageProcessor",
+    "template": "MessageProcessorNonQv",
     "params": [10, 20, 2],
     "pubs": [
       "totalSignups",
@@ -125,15 +125,31 @@ Edit `circuits/circom/circuits` to include the circuits you would like to compil
       "voteOptions"
     ]
   },
-  "TallyVotes_10-1-2_test": {
-    "file": "./core/qv/tallyVotes",
-    "template": "TallyVotes",
+  "ProcessMessagesFull_10-20-2_test": {
+    "file": "./coordinator/non-qv/MessageProcessor",
+    "template": "MessageProcessorFull",
+    "params": [10, 20, 2],
+    "pubs": [
+      "totalSignups",
+      "index",
+      "batchEndIndex",
+      "currentSbCommitment",
+      "newSbCommitment",
+      "outputBatchHash",
+      "actualStateTreeDepth",
+      "coordinatorPublicKeyHash",
+      "voteOptions"
+    ]
+  },
+  "VoteTallyQv_10-1-2_test": {
+    "file": "./coordinator/qv/VoteTally",
+    "template": "VoteTallyQv",
     "params": [10, 1, 2],
     "pubs": ["index", "totalSignups", "sbCommitment", "currentTallyCommitment", "newTallyCommitment"]
   },
-  "TallyVotesNonQv_10-1-2_test": {
-    "file": "./core/non-qv/tallyVotes",
-    "template": "TallyVotesNonQv",
+  "VoteTallyNonQv_10-1-2_test": {
+    "file": "./coordinator/non-qv/VoteTally",
+    "template": "VoteTallyNonQv",
     "params": [10, 1, 2],
     "pubs": ["index", "totalSignups", "sbCommitment", "currentTallyCommitment", "newTallyCommitment"]
   }

package/versioned_docs/version-v3.x/guides/integrating.md

@@ -43,7 +43,7 @@ function signUp(PublicKey memory _publicKey, bytes memory _signUpPolicyData) pub
 
 ## 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'll need to build you own initial voice credit proxy contract by following the [IInitialVoiceCreditProxy interface](https://github.com/privacy-scaling-explorations/maci/blob/main/packages/contracts/contracts/interfaces/IInitialVoiceCreditProxy.sol). You can see our [basic example](https://github.com/privacy-scaling-explorations/maci/blob/main/packages/contracts/contracts/initialVoiceCreditProxy/ConstantInitialVoiceCreditProxy.sol) how it's implemented for constant distribution.
 
 ```ts
 contract ConstantInitialVoiceCreditProxy is InitialVoiceCreditProxy {
@@ -118,7 +118,7 @@ Given the verification functions being exposed by the Tally contract, quadratic
 
 ## SDK
 
-Another important component of MACI is the [SDK](https://github.com/privacy-scaling-explorations/maci/tree/dev/packages/sdk). This is a TypeScript library that allows you to interact with MACI.
+Another important component of MACI is the [SDK](https://github.com/privacy-scaling-explorations/maci/tree/main/packages/sdk). This is a TypeScript library that allows you to interact with MACI.
 
 You can find the following subdirectories, where functions are organised as follows: