@maci-protocol/website 0.0.0-ci.fd5247e → 0.0.0-ci.ffabe48

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/dev/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/dev/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

@@ -751,11 +751,11 @@ The coordinator uses the ballot tallying circuit (`tallyVotes.circom`) to genera
 
 #### 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/guides/compile-circuits.md

@@ -77,24 +77,24 @@ 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",
+    "file": "./coordinator/qv/processMessages",
     "template": "ProcessMessages",
     "params": [10, 20, 2],
     "pubs": [
@@ -110,7 +110,7 @@ Edit `circuits/circom/circuits` to include the circuits you would like to compil
     ]
   },
   "ProcessMessagesNonQv_10-20-2_test": {
-    "file": "./core/non-qv/processMessages",
+    "file": "./coordinator/non-qv/processMessages",
     "template": "ProcessMessagesNonQv",
     "params": [10, 20, 2],
     "pubs": [
@@ -125,14 +125,30 @@ Edit `circuits/circom/circuits` to include the circuits you would like to compil
       "voteOptions"
     ]
   },
+  "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"
+    ]
+  },
   "TallyVotes_10-1-2_test": {
-    "file": "./core/qv/tallyVotes",
+    "file": "./coordinator/qv/tallyVotes",
     "template": "TallyVotes",
     "params": [10, 1, 2],
     "pubs": ["index", "totalSignups", "sbCommitment", "currentTallyCommitment", "newTallyCommitment"]
   },
   "TallyVotesNonQv_10-1-2_test": {
-    "file": "./core/non-qv/tallyVotes",
+    "file": "./coordinator/non-qv/tallyVotes",
     "template": "TallyVotesNonQv",
     "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/dev/packages/contracts/contracts/interfaces/IInitialVoiceCreditProxy.sol). You can see our [basic example](https://github.com/privacy-scaling-explorations/maci/blob/dev/packages/contracts/contracts/initialVoiceCreditProxy/ConstantInitialVoiceCreditProxy.sol) how it's implemented for constant distribution.
 
 ```ts
 contract ConstantInitialVoiceCreditProxy is InitialVoiceCreditProxy {

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

@@ -74,7 +74,7 @@ or download them. Please remember to not use these testing `.zkey` files in prod
 MACI has two main zk-SNARK circuits, `processMessages` and `tallyVotes`.
 
 :::info
-The `processMessages` and `tallyVotes` circuits are also provided in a non-quadratic voting (non-QV) version. Currently these new versions have not undergone a trusted setup ceremony.
+The `processMessages` and `tallyVotes` circuits are also provided in a non-quadratic voting (non-QV) and in a full credits voting (full) versions. Currently these new versions have not undergone a trusted setup ceremony.
 :::
 
 Each circuit is parameterised and there should be one
@@ -151,6 +151,12 @@ To run e2e tests with normal voting (not quadratic voting):
 pnpm run test:e2e-non-qv
 ```
 
+To run e2e tests with full credits voting (full):
+
+```bash
+pnpm run test:e2e-full
+```
+
 To run integration tests:
 
 ```bash

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

@@ -135,16 +135,16 @@ For testing we suggest using the **FreeForAlPolicy** as it allows anyone to sign
 
 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.                                          |
-| **intStateTreeDepth**   | 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 and Non QV 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. |
+| 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**.
@@ -203,6 +203,10 @@ As a coordinator, first you need to merge signups and messages (votes). This opt
 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
@@ -210,12 +214,16 @@ 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]
+    --start-block [block-number] \
     --blocks-per-batch [number-of-blocks]
 ```
 
-:::important
-You can reduce the time of the proving by including more blocks per batch, you can try with 500.
+:::info
+The `--coordinator-private-key` is the one you generated earlier with `pnpm run generateMaciKeyPair`.
+
+`--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
@@ -224,8 +232,8 @@ Now it's time to submit the poll results on-chain so that everyone can verify th
 
 ```bash
 pnpm submitOnChain:[network] --poll [poll-id] \
-    --output-dir proofs/ \
-    --tally-file proofs/tally.json
+    --output-dir ../results/proofs/ \
+    --tally-file ../results/tally.json
 ```
 
 ### Tally

package/versioned_docs/version-v3.x/security/audit.md

@@ -38,7 +38,7 @@ We would like to thank the Veridise team for their effort in keeping open source
 
 **Description**
 
-In the template `QuinSelector`, if you want to confirm the input signal index is a valid integer less than 2\*\*3, you should add Num2bits(3) to check it.
+In the template `QuinarySelector`, if you want to confirm the input signal index is a valid integer less than 2\*\*3, you should add Num2bits(3) to check it.
 
 **Code Location**
 
@@ -119,7 +119,7 @@ greaterThan[i].in[1] <== index;
 
 **Description**
 
-In the template `QuinGeneratePathIndices`, the constraints of the `signal n[levels + 1]` don't perform well for division and modulo counting.
+In the template `QuinaryGeneratePathIndices`, the constraints of the `signal n[levels + 1]` don't perform well for division and modulo counting.
 
 **Code Location**
 

package/versioned_docs/version-v3.x/supported-networks/deployed-contracts.md

@@ -7,14 +7,14 @@ sidebar_position: 2
 
 There are a number of MACI's smart contracts which can be re-used by different deployments. These are the following:
 
-- [VerifyingKeysRegistry](https://github.com/privacy-scaling-explorations/maci/blob/dev/contracts/contracts/VerifyingKeysRegistry.sol)
-- [PoseidonHashers](https://github.com/privacy-scaling-explorations/maci/blob/dev/contracts/contracts/crypto/Hasher.sol)
-- [PollFactory](https://github.com/privacy-scaling-explorations/maci/blob/dev/contracts/contracts/PollFactory.sol)
-- [MessageProcessorFactory](https://github.com/privacy-scaling-explorations/maci/blob/dev/contracts/contracts/MessageProcessorFactory.sol)
-- [TallyFactory](https://github.com/privacy-scaling-explorations/maci/blob/dev/contracts/contracts/TallyFactory.sol)
-- [Verifier](https://github.com/privacy-scaling-explorations/maci/blob/dev/contracts/contracts/crypto/Verifier.sol)
+- [VerifyingKeysRegistry](https://github.com/privacy-scaling-explorations/maci/blob/dev/packages/contracts/contracts/VerifyingKeysRegistry.sol)
+- [PoseidonHashers](https://github.com/privacy-scaling-explorations/maci/blob/dev/packages/contracts/contracts/crypto/Hasher.sol)
+- [PollFactory](https://github.com/privacy-scaling-explorations/maci/blob/dev/packages/contracts/contracts/PollFactory.sol)
+- [MessageProcessorFactory](https://github.com/privacy-scaling-explorations/maci/blob/dev/packages/contracts/contracts/MessageProcessorFactory.sol)
+- [TallyFactory](https://github.com/privacy-scaling-explorations/maci/blob/dev/packages/contracts/contracts/TallyFactory.sol)
+- [Verifier](https://github.com/privacy-scaling-explorations/maci/blob/dev/packages/contracts/contracts/crypto/Verifier.sol)
 - [FreeForAllPolicy](https://github.com/privacy-scaling-explorations/excubiae/tree/main/packages/contracts/contracts/extensions/freeForAll)
-- [ConstantInitialVoiceCreditProxy](https://github.com/privacy-scaling-explorations/maci/blob/dev/contracts/contracts/initialVoiceCreditProxy/ConstantInitialVoiceCreditProxy.sol) - if you are happy to work with a fixed amount of credits
+- [ConstantInitialVoiceCreditProxy](https://github.com/privacy-scaling-explorations/maci/blob/dev/packages/contracts/contracts/initialVoiceCreditProxy/ConstantInitialVoiceCreditProxy.sol) - if you are happy to work with a fixed amount of credits
 
 VkRegistries can be re-used by different protocols to share the same set of verifying keys. Please be advised that you should be verifying that those verifying keys are the ones that have undergone a trusted setup ceremony.
 

package/versioned_docs/version-v3.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/dev/packages/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.
@@ -149,7 +149,7 @@ Polls require the following information:
 - `coordinatorPubKey`: the public key of the poll's coordinator
 - `verifier`: the address of the zk-SNARK verifier contract
 - `vkRegistry`: the address of the vk registry contract
-- `mode`: the mode of the poll, to set whether it supports quadratic voting or non quadratic voting
+- `mode`: the mode of the poll, to set whether it supports quadratic voting, non quadratic voting, full credits voting
 - `signUpPolicy`: the address of the sign up policy contract
 - `initialVoiceCreditProxy`: the address of the initial voice credit proxy contract
 - `relayers`: the addresses of the relayers for the poll (if offchain voting is enabled)

package/versioned_docs/version-v3.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/dev/packages/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`.

package/versioned_docs/version-v3.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/dev/packages/contracts/contracts/utilities/Params.sol)
 :::
 
 A contract holding three structs:
@@ -14,7 +14,7 @@ A contract holding three structs:
 ```ts
 /// @notice A struct holding the depths of the merkle trees
 struct TreeDepths {
-  uint8 intStateTreeDepth;
+  uint8 tallyProcessingStateTreeDepth;
   uint8 voteOptionTreeDepth;
 }
 

package/versioned_docs/version-v3.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/dev/packages/contracts/contracts/Poll.sol)
 :::
 
 This contract allows users to submit their votes.

package/versioned_docs/version-v3.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/dev/packages/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-v3.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/dev/packages/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.
@@ -34,7 +34,7 @@ This contract should be deployed alongside a `Poll`, with the the constructor ac
 - `vkRegistry` - The address of the vkRegistry contract
 - `poll` - The address of the poll contract
 - `messageProcessor` - The address of the messageProcessor contract
-- `mode` - The mode of the tally contract - depending on this, the commitments will be processed differently, and it must equal the Poll mode (quadratic vs non quadratic voting)
+- `mode` - The mode of the tally contract - depending on this, the commitments will be processed differently, and it must equal the Poll mode (quadratic vs non quadratic vs full credits voting)
 
 Users can use the verification functions to verify the Tally results. These are as follows:
 

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

@@ -6,7 +6,7 @@ sidebar_position: 8
 ---
 
 :::info
-Code location: [VerifyingKeysRegistry.sol](https://github.com/privacy-scaling-explorations/maci/blob/dev/contracts/contracts/VerifyingKeysRegistry.sol)
+Code location: [VerifyingKeysRegistry.sol](https://github.com/privacy-scaling-explorations/maci/blob/dev/packages/contracts/contracts/VerifyingKeysRegistry.sol)
 :::
 
 The VerifyingKeysRegistry is a contract that holds the verifying keys for the zk-SNARK circuits. It holds four different sets of keys:
@@ -18,7 +18,7 @@ The VerifyingKeysRegistry is a contract that holds the verifying keys for the zk
 
 Each circuit will have a signature which is its compile-time constants represented as a uint256.
 
-Please note that each Verifying Key should be set with the corresponding mode. Available modes are quadratic voting and non quadratic voting.
+Please note that each Verifying Key should be set with the corresponding mode. Available modes are quadratic, non quadratic and full credits voting.
 
 The contract owner can set them using the `setVerifyingKeysBatch` function:
 

package/versioned_docs/version-v3.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/dev/circuits/circom/coordinator)
 
 This circuit allows the coordinator to prove that they have correctly processed each message in reverse order, in a consecutive batch of 5 ^ messageBatchDepth 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/dev/circuits/circom/coordinator/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,11 @@ 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/dev/circuits/circom/coordinator/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.
+:::
+
+:::info
+A version working with full credits voting (full) is also [available](https://github.com/privacy-scaling-explorations/maci/blob/dev/circuits/circom/coordinator/full/MessageProcessor.circom). This version is called `MessageProcessorFull` and is to be used when the Poll is not using the quadratic or non quadratic voting features. Note that by default MACI works with quadratic voting.
 :::
 
 #### Parameters

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

@@ -37,7 +37,7 @@ MACI's circuits are parameterized, and thus can be configured to support differe
 - **STATE_TREE_DEPTH** = how many users the system supports
 - **VOTE_OPTIONS_TREE_DEPTH** = how many vote options the system supports
 - **MESSAGE_BATCH_SIZE** = how many messages in a batch the circuit should process
-- **INT_STATE_TREE_DEPTH** = how many ballots can be processed per batch when tallying the results (`5 ** INT_STATE_TREE_DEPTH` ballots)
+- **TALLY_PROCESSING_STATE_TREE_DEPTH** = how many ballots can be processed per batch when tallying the results (`5 ** TALLY_PROCESSING_STATE_TREE_DEPTH` ballots)
 
 Please refer to the individual circuit documentation for more details on the inner working of each circuit and where parameters fit.
 

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

@@ -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 and full credits voting (non-qv, full) is also [available](https://github.com/privacy-scaling-explorations/maci/blob/dev/circuits/circom/coordinator/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
@@ -73,7 +73,7 @@ $poseidon_3([tc_r, tc_t, tc_p])$
 
 1. That the coordinator knows the preimage of `sbCommitment`
 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/technical-references/zk-snark-circuits/utilities.md

@@ -39,11 +39,11 @@ A utility circuit used by the main `tallyVotes` circuit to verify that the resul
 
 ![ResultsCommitmentVerifier](/img/circuits/resultsCommitmentVerifier.svg)
 
-#### QuinCheckRoot
+#### QuinaryCheckRoot
 
 Utility circuit that given a quin Merkle root and a list of leaves, check if the root is the correct result of inserting all the leaves into the tree in the given order.
 
-![QuinCheckRoot](/img/circuits/quinCheckRoot.svg)
+![QuinaryCheckRoot](/img/circuits/quinCheckRoot.svg)
 
 #### CalculateTotal
 
@@ -100,11 +100,11 @@ Utility circuit used to unpack an input element.
 
 ![UnpackElement](/img/circuits/unpackElement.svg)
 
-#### QuinSelector
+#### QuinarySelector
 
 Utility circuit used to select one element from an array of n elements at a given index.
 
-![QuinSelector](/img/circuits/quinSelector.svg)
+![QuinarySelector](/img/circuits/quinSelector.svg)
 
 #### Splicer
 
@@ -118,11 +118,11 @@ Utility circuit used to check if a batch of leaves exists in a quinary tree.
 
 ![QuinBatchLeavesExists](/img/circuits/quinBatchLeavesExists.svg)
 
-#### QuinGeneratePathIndices
+#### QuinaryGeneratePathIndices
 
 Utility circuit used to generate the indices needed to traverse the tree until we find the leaf we are looking for.
 
-![QuinGeneratePathIndices](/img/circuits/quinGeneratePathIndices.svg)
+![QuinaryGeneratePathIndices](/img/circuits/quinGeneratePathIndices.svg)
 
 #### ProcessOne