npm - @maci-protocol/website - Versions diffs - 0.0.0-ci.eb89f0b → 0.0.0-ci.ebb44e9 - Mend

@maci-protocol/website 0.0.0-ci.eb89f0b → 0.0.0-ci.ebb44e9

This diff represents the content of publicly available package versions that have been released to one of the supported registries. The information contained in this diff is provided for informational purposes only and reflects changes between package versions as they appear in their respective public registries.

Files changed (33) hide show

package/docusaurus.config.ts CHANGED Viewed

@@ -46,7 +46,7 @@ async function getConfig(): Promise<Config> {
             routeBasePath: "docs/",
             sidebarPath: "./sidebars.ts",
             editUrl: ({ versionDocsDirPath, docPath }) =>
-              `${GITHUB_URL}/edit/dev/website/${versionDocsDirPath}/${docPath}`,
+              `${GITHUB_URL}/edit/dev/apps/website/${versionDocsDirPath}/${docPath}`,
             remarkPlugins: [remarkMath],
             rehypePlugins: [rehypeKatex],
             includeCurrentVersion: false,
@@ -59,7 +59,7 @@ async function getConfig(): Promise<Config> {
           blog: {
             showReadingTime: true,
-            editUrl: ({ blogDirPath, blogPath }) => `${GITHUB_URL}/edit/dev/website/${blogDirPath}/${blogPath}`,
+            editUrl: ({ blogDirPath, blogPath }) => `${GITHUB_URL}/edit/dev/apps/website/${blogDirPath}/${blogPath}`,
             remarkPlugins: [remarkMath],
             rehypePlugins: [rehypeKatex],
             onUntruncatedBlogPosts: "ignore",

package/package.json CHANGED Viewed

@@ -1,6 +1,6 @@
 {
   "name": "@maci-protocol/website",
-  "version": "0.0.0-ci.eb89f0b",
+  "version": "0.0.0-ci.ebb44e9",
   "private": false,
   "publishConfig": {
     "access": "public"
@@ -21,11 +21,11 @@
     "types": "tsc -p tsconfig.json --noEmit"
   },
   "dependencies": {
-    "@docusaurus/core": "^3.7.0",
-    "@docusaurus/preset-classic": "^3.7.0",
-    "@docusaurus/theme-classic": "^3.7.0",
-    "@docusaurus/theme-common": "^3.7.0",
-    "@easyops-cn/docusaurus-search-local": "^0.49.1",
+    "@docusaurus/core": "^3.8.1",
+    "@docusaurus/preset-classic": "^3.8.1",
+    "@docusaurus/theme-classic": "^3.8.1",
+    "@docusaurus/theme-common": "^3.8.1",
+    "@easyops-cn/docusaurus-search-local": "^0.51.0",
     "@mdx-js/react": "^3.1.0",
     "clsx": "^2.1.1",
     "docusaurus-plugin-image-zoom": "^3.0.1",
@@ -38,11 +38,11 @@
     "remark-math": "^6.0.0"
   },
   "devDependencies": {
-    "@docusaurus/module-type-aliases": "^3.7.0",
-    "@docusaurus/tsconfig": "^3.7.0",
-    "@docusaurus/types": "^3.7.0",
-    "@types/node": "^22.15.8",
-    "@types/react": "^19.1.2",
+    "@docusaurus/module-type-aliases": "^3.8.1",
+    "@docusaurus/tsconfig": "^3.8.1",
+    "@docusaurus/types": "^3.8.1",
+    "@types/node": "^24.0.3",
+    "@types/react": "^19.1.8",
     "ts-node": "^10.9.2",
     "typescript": "^5.8.3"
   },
@@ -61,5 +61,5 @@
   "engines": {
     "node": ">=18.0"
   },
-  "gitHead": "2f14979eea13a7fa94af48ad270832fdaf95c152"
+  "gitHead": "b4863ef769205fddf83c2b4aca9cedd8924f7e43"
 }

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

@@ -35,25 +35,25 @@ The MACI contract's `quadraticVoteTally()` function should verify a proof create
 ## Inputs
-| Pseudocode name               | zk-SNARK input type | Description                                                                                                | Set by      |
-| ----------------------------- | ------------------- | ---------------------------------------------------------------------------------------------------------- | ----------- |
-| `fullStateRoot`               | Public              | The final Merkle root of the state tree                                                                    | Contract    |
-| `fullStateTreeDepth`          | Hardcoded           | The depth of the state tree                                                                                | Contract    |
-| `intermediateStateTreeDepth`  | Hardcoded           | The depth of the intermediate state tree                                                                   | Contract    |
-| `intermediateStateRoot`       | Public              | The intermediate Merkle root generated by the given state leaves                                           | Contract    |
-| `intermediatePathElements[k]` | Private             | The Merkle path elements from `intermediateStateRoot` to `stateRoot`.                                      | Coordinator |
-| `intermediatePathIndex`       | Public              | The Merkle path index from `intermediateStateRoot` to `stateRoot`.                                         | Contract    |
-| `currentResults[n]`           | Private             | The vote tally of all prior batches of state leaves                                                        | Coordinator |
-| `currentResultsSalt`          | Private             | A random value to hash with the vote tally for state leaves up to the current batch                        | Coordinator |
-| `currentResultsCommitment`    | Public              | The salted commitment of the values in `currentResults`                                                    | Contract    |
-| `newResultsCommitment`        | Public              | The salted commitment of the vote tally for this batch of leaves plus the vote tally from `currentResults` | Contract    |
-| `salt`                        | Private             | A random value to hash with the culmulate vote tally for this batch of state leaves                        | Coordinator |
-| `stateLeaves[m][p]`           | Private             | The batch of leaves of the state tree to tally.                                                            | Coordinator |
-| `voteLeaves[m][n]`            | Private             | The vote leaves for each user in this batch of state leaves.                                               | Coordinator |
+| Pseudocode name                 | zk-SNARK input type | Description                                                                                                | Set by      |
+| ------------------------------- | ------------------- | ---------------------------------------------------------------------------------------------------------- | ----------- |
+| `fullStateRoot`                 | Public              | The final Merkle root of the state tree                                                                    | Contract    |
+| `fullStateTreeDepth`            | Hardcoded           | The depth of the state tree                                                                                | Contract    |
+| `tallyProcessingStateTreeDepth` | Hardcoded           | The depth of the intermediate state tree                                                                   | Contract    |
+| `intermediateStateRoot`         | Public              | The intermediate Merkle root generated by the given state leaves                                           | Contract    |
+| `intermediatePathElements[k]`   | Private             | The Merkle path elements from `intermediateStateRoot` to `stateRoot`.                                      | Coordinator |
+| `intermediatePathIndex`         | Public              | The Merkle path index from `intermediateStateRoot` to `stateRoot`.                                         | Contract    |
+| `currentResults[n]`             | Private             | The vote tally of all prior batches of state leaves                                                        | Coordinator |
+| `currentResultsSalt`            | Private             | A random value to hash with the vote tally for state leaves up to the current batch                        | Coordinator |
+| `currentResultsCommitment`      | Public              | The salted commitment of the values in `currentResults`                                                    | Contract    |
+| `newResultsCommitment`          | Public              | The salted commitment of the vote tally for this batch of leaves plus the vote tally from `currentResults` | Contract    |
+| `salt`                          | Private             | A random value to hash with the culmulate vote tally for this batch of state leaves                        | Coordinator |
+| `stateLeaves[m][p]`             | Private             | The batch of leaves of the state tree to tally.                                                            | Coordinator |
+| `voteLeaves[m][n]`              | Private             | The vote leaves for each user in this batch of state leaves.                                               | Coordinator |
 `n` is the number of options in `voteOptionTree`.
 `m` is the number of state leaves in this batch.
-`k` is `fullStateTreeDepth - intermediateStateTreeDepth`
+`k` is `fullStateTreeDepth - tallyProcessingStateTreeDepth`
 `p` is the message length
 A result commitment is the hash of a Merkle root of all the vote leaves, and a salt. For instance:

package/versioned_docs/version-v3.x/core-concepts/maci-keys.md CHANGED Viewed

@@ -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 CHANGED Viewed

@@ -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 CHANGED Viewed

@@ -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 CHANGED Viewed

@@ -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 CHANGED Viewed

@@ -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 CHANGED Viewed

@@ -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 CHANGED Viewed

@@ -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/sdk.md ADDED Viewed

@@ -0,0 +1,121 @@
+---
+title: MACI SDK
+description: How to use the MACI SDK
+sidebar_label: MACI SDK
+sidebar_position: 6
+---
+In this guide we will be looking at how to use the MACI SDK to interact with the MACI protocol.
+## Installation
+```bash
+npm install @maci-protocol/sdk
+```
+## Browser compatibility
+As the SDK imports functions from the `@maci-protocol/contracts` package which uses hardhat, certain functionality is not browser compatible.
+However, all it takes to use browser compatible functions is to import from `@maci-protocol/sdk/browser`.
+As an example, we can import the `signUp` function from the `@maci-protocol/sdk/browser` package.
+```typescript
+import { signUp } from "@maci-protocol/sdk/browser";
+```
+Let's take a look at an example of how to use the `joinPoll` function to register a user to a poll.
+### JoinPoll
+This step is required to register a user to a specific poll for which they want to vote. In short, it requires the user to generate a zk-SNARK proof that they know the private key to a public key registered to the MACI contract (proving they passed the initial gatekeeping requirements). This forces them to join with the same MACI key to each poll, greatly increasing the value of the key. Should they have been allowed to join with a throwaway key, they could simply sell their key for polls they do not care about.
+**How does the flow look like?**
+1. Reconstruct the MACI state tree by pulling all public keys from the MACI contract (events from RPC or from Subgraph)
+2. Generate a merkle tree inclusion proof for the user's public key
+3. Generate a zk-SNARK proof that the user knows the private key to the public key in the merkle tree inclusion proof
+4. Call the `joinPoll` function on the Poll smart contract
+**How to use the SDK for this?**
+> This example is browser specific, as it uses the `@maci-protocol/sdk/browser` package and WASM for witness generation
+Option 1: Use the `joinPoll` function from the `@maci-protocol/sdk/browser` package.
+1. Download the `pollJoining` zk artifacts using [downloadPollJoiningArtifactsBrowser](https://github.com/privacy-scaling-explorations/maci/blob/dev/packages/sdk/ts/proof/download.ts#L46)
+```typescript
+import { downloadPollJoiningArtifactsBrowser } from "@maci-protocol/sdk/browser";
+const artifacts = await downloadPollJoiningArtifactsBrowser({
+  testing: true,
+  stateTreeDepth: 10,
+});
+```
+2. Use the `joinPoll` function to join the poll
+```typescript
+import { joinPoll } from "@maci-protocol/sdk/browser";
+const joinedPollData = await joinPoll({
+  maciAddress: PUBLIC_MACI_ADDRESS,
+  privateKey: maciKeypair.privateKey.serialize(),
+  signer,
+  pollId,
+  inclusionProof,
+  pollJoiningZkey: artifacts.zKey as unknown as string,
+  pollWasm: artifacts.wasm as unknown as string,
+  sgDataArg: DEFAULT_SG_DATA,
+  ivcpDataArg: DEFAULT_IVCP_DATA,
+  blocksPerBatch: 1000,
+});
+```
+This is not really efficient, as we are using the user RPC to fetch events, which can be quite slow and prone to errors. A better approach is to use a Subgraph to fetch the events.
+Option 2: Fetch the MACI keys using a subgraph and reconstruct the state tree locally.
+1. Deploy the subgraph - instructions [here](/guides/subgraph)
+2. Fetch the MACI keys
+```typescript
+import { MaciSubgraph } from "@maci-protocol/sdk/browser";
+const subgraph = new MaciSubgraph("https://api.studio.thegraph.com/query/x/maci/version/latest");
+const keys = await subgraph.getKeys();
+```
+3. Generate the merkle tree
+```typescript
+import { generateSignUpTreeFromKeys } from "@maci-protocol/sdk/browser";
+const signUpTree = generateSignUpTreeFromKeys(keys);
+```
+4. Generate the inclusion proof - you will need to know the index of the user's public key in the merkle tree
+```typescript
+const inclusionProof = signUpTree.generateProof(publicKeyIndex);
+```
+5. Generate the zk-SNARK proof and join the poll
+```typescript
+import { joinPoll } from "@maci-protocol/sdk/browser";
+const joinedPollData = await joinPoll({
+  maciAddress: PUBLIC_MACI_ADDRESS,
+  privateKey: maciKeypair.privateKey.serialize(),
+  signer,
+  pollId,
+  inclusionProof,
+  pollJoiningZkey: artifacts.zKey as unknown as string,
+  pollWasm: artifacts.wasm as unknown as string,
+  sgDataArg: DEFAULT_SG_DATA,
+  ivcpDataArg: DEFAULT_IVCP_DATA,
+});
+```

package/versioned_docs/version-v3.x/guides/testing/testing-in-detail.md CHANGED Viewed

@@ -162,7 +162,7 @@ The core package contains a number of tests that are used to verify that the cor
 These tests interact with the crypto and dombinobjs packages, where mock data comes from. Their main goal is to ensure that the core functions work as expected, and that the state is as expected after a series of operations.
-Currently, there is a blend of e2e and unit tests, where e2e tests are used to verify that the entire MACI local processing works as expected (users signup, publish votes, messages are processed and finally these votes are tallied). Unit tests on the other hand are used to verify that the core functions work as expected, such as `processMessage` and `tallyVotes`. You will find them in separate files, with e2e being [here](https://github.com/privacy-scaling-explorations/maci/blob/dev/core/ts/__tests__/e2e.test.ts) and unit tests in the other files.
+Currently, there is a blend of e2e and unit tests, where e2e tests are used to verify that the entire MACI local processing works as expected (users signup, publish votes, messages are processed and finally these votes are tallied). Unit tests on the other hand are used to verify that the core functions work as expected, such as `MessageProcessor` and `VoteTally`. You will find them in separate files, with e2e being [here](https://github.com/privacy-scaling-explorations/maci/blob/dev/core/ts/__tests__/e2e.test.ts) and unit tests in the other files.
 ### Domainobjs/Crypto tests

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

@@ -53,6 +53,32 @@ To run Contracts only tests, run:
 pnpm run test
 ```
+To run e2e tests for hardhat tasks for `contracts` using the in-memory hardhat network:
+```bash
+pnpm run test:hardhat
+```
+You can update the `deploy-config.json` file to change policies or other deployment settings used by the test.
+You can enhance test reporting and gas cost estimation by adding the following variables to your `.env` file:
+```bash
+# CoinMarkerCap api key for prices (gas reporter)
+COINMARKETCAP_API_KEY=
+# Gas price for gas reporter
+# Allows you to manually specify the gas price (e.g. 3 gwei)
+GAS_REPORTER_PRICE=
+```
+These variables are used by `hardhat-gas-reporter` to show cost estimates for gas usage in the test reports.
+If you would like to run these E2E tests against a different [supported networks](/docs/supported-networks/), you can override the network like this:
+```bash
+pnpm exec hardhat test --network {NETWORK} ./tests/e2e/hardhatTasks.test.ts
+```
 ### Circuits
 To test the circuits, from the main `maci/` directory, run:
@@ -71,10 +97,10 @@ or download them. Please remember to not use these testing `.zkey` files in prod
 ### Download `.zkey` files or the witness generation binaries
-MACI has two main zk-SNARK circuits, `processMessages` and `tallyVotes`.
+MACI has two main zk-SNARK circuits, `MessageProcessor` and `VoteTally`.
 :::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 `MessageProcessor` and `VoteTally` 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 +177,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