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

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

@@ -17,12 +17,12 @@ As an example, a [contract](https://github.com/ctrlc03/minimalQF/blob/main/contr
 
 ```javascript
 /// @inheritdoc IMACI
-function signUp(PubKey memory _pubKey, bytes memory _signUpPolicyData) public virtual {
+function signUp(PublicKey memory _publicKey, bytes memory _signUpPolicyData) public virtual {
   // ensure we do not have more signups than what the circuits support
   if (leanIMTData.size >= maxSignups) revert TooManySignups();
 
   // ensure that the public key is on the baby jubjub curve
-  if (!CurveBabyJubJub.isOnCurve(_pubKey.x, _pubKey.y)) {
+  if (!CurveBabyJubJub.isOnCurve(_publicKey.x, _publicKey.y)) {
     revert InvalidPubKey();
   }
 
@@ -31,19 +31,19 @@ function signUp(PubKey memory _pubKey, bytes memory _signUpPolicyData) public vi
   signUpPolicy.enforce(msg.sender, _signUpPolicyData);
 
   // Hash the public key and insert it into the tree.
-  uint256 pubKeyHash = hashLeftRight(_pubKey.x, _pubKey.y);
+  uint256 pubKeyHash = hashLeftRight(_publicKey.x, _publicKey.y);
   uint256 stateRoot = InternalLeanIMT._insert(leanIMTData, pubKeyHash);
 
   // Store the current state tree root in the array
   stateRootsOnSignUp.push(stateRoot);
 
-  emit SignUp(leanIMTData.size - 1, block.timestamp, _pubKey.x, _pubKey.y);
+  emit SignUp(leanIMTData.size - 1, block.timestamp, _publicKey.x, _publicKey.y);
 }
 ```
 
 ## 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 {
@@ -71,7 +71,7 @@ On the other hand, the Poll contract can be inherited to expand functionality su
 ```javascript
 function joinPoll(
   uint256 _nullifier,
-  PubKey calldata _pubKey,
+  PublicKey calldata _publicKey,
   uint256 _stateRootIndex,
   uint256[8] calldata _proof,
   bytes memory _signUpPolicyData,
@@ -86,7 +86,7 @@ function joinPoll(
   pollNullifiers[_nullifier] = true;
 
   // Verify user's proof
-  if (!verifyJoiningPollProof(_nullifier, _stateRootIndex, _pubKey, _proof)) {
+  if (!verifyJoiningPollProof(_nullifier, _stateRootIndex, _publicKey, _proof)) {
     revert InvalidPollProof();
   }
 
@@ -100,7 +100,7 @@ function joinPoll(
   );
 
   // Store user in the pollStateTree
-  uint256 stateLeaf = hashStateLeaf(StateLeaf(_pubKey, voiceCreditBalance, block.timestamp));
+  uint256 stateLeaf = hashStateLeaf(StateLeaf(_publicKey, voiceCreditBalance, block.timestamp));
 
   uint256 stateRoot = InternalLazyIMT._insert(pollStateTree, stateLeaf);
 
@@ -108,7 +108,7 @@ function joinPoll(
   pollStateRootsOnJoin.push(stateRoot);
 
   uint256 pollStateIndex = pollStateTree.numberOfLeaves - 1;
-  emit PollJoined(_pubKey.x, _pubKey.y, voiceCreditBalance, block.timestamp, _nullifier, pollStateIndex);
+  emit PollJoined(_publicKey.x, _publicKey.y, voiceCreditBalance, block.timestamp, _nullifier, pollStateIndex);
 }
 ```
 

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

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

@@ -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
 
@@ -176,7 +176,7 @@ This script contains a number of actions which touch all of the parts of MACI, a
 
 Looking at this in more details we do the following:
 
-1. Deploy a `VkRegistry` contract
+1. Deploy a `VerifyingKeysRegistry` contract
 2. Set the verification keys on this smart contract
 3. Deploy a `MACI` contract (and associated utility contracts)
 4. Deploy a Poll from the MACI contract.

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

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

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

@@ -7,21 +7,21 @@ sidebar_position: 5
 
 # Troubleshooting
 
-## cli: `genProofs` command failure
+## cli: `generateProofs` command failure
 
 ### Case: missing `.dat` files
 
-If your logs look like the following, then make sure you have `ProcessMessages_10-2-1-2_test.dat` and `TallyVotes_10-1-2_test.dat` files in the same directory as your zkeys:
+If your logs look like the following, then make sure you have `MessageProcessorQv_10-2-1-2_test.dat` and `VoteTallyQv_10-1-2_test.dat` files in the same directory as your zkeys:
 
 ```
-node build/ts/index.js genProofs -x 0xf204a4Ef082f5c04bB89F7D5E6568B796096735a \
+node build/ts/index.js generateProofs -x 0xf204a4Ef082f5c04bB89F7D5E6568B796096735a \
 >     -sk macisk.49953af3585856f539d194b46c82f4ed54ec508fb9b882940cbe68bbc57e59e \
 >     -o 0 \
 >     -r ~/rapidsnark/build/prover \
->     -wp ./zkeys/ProcessMessages_10-2-1-2_test \
->     -wt ./zkeys/TallyVotes_10-1-2_test \
->     -zp ./zkeys/ProcessMessages_10-2-1-2_test.0.zkey \
->     -zt ./zkeys/TallyVotes_10-1-2_test.0.zkey \
+>     -wp ./zkeys/MessageProcessorQv_10-2-1-2_test \
+>     -wt ./zkeys/VoteTallyQv_10-1-2_test \
+>     -zp ./zkeys/MessageProcessorQv_10-2-1-2_test.0.zkey \
+>     -zt ./zkeys/VoteTallyQv_10-1-2_test.0.zkey \
 >     -t tally.json \
 >     -f proofs
 
@@ -36,12 +36,12 @@ terminate called after throwing an instance of 'std::system_error'
 Aborted (core dumped)
 
 Error: could not generate proof.
-Error: Error executing ./zkeys/ProcessMessages_10-2-1-2_test /tmp/tmp-9904-zG0k8YPTATWB/input.json /tmp/tmp-9904-zG0k8YPTATWB/output.wtns
+Error: Error executing ./zkeys/MessageProcessorQv_10-2-1-2_test /tmp/tmp-9904-zG0k8YPTATWB/input.json /tmp/tmp-9904-zG0k8YPTATWB/output.wtns
     at genProof (/home/ubuntu/maci/circuits/ts/index.ts:44:15)
-    at /home/ubuntu/maci/cli/ts/genProofs.ts:339:25
-    at step (/home/ubuntu/maci/cli/build/genProofs.js:33:23)
-    at Object.next (/home/ubuntu/maci/cli/build/genProofs.js:14:53)
-    at fulfilled (/home/ubuntu/maci/cli/build/genProofs.js:5:58)
+    at /home/ubuntu/maci/cli/ts/generateProofs.ts:339:25
+    at step (/home/ubuntu/maci/cli/build/generateProofs.js:33:23)
+    at Object.next (/home/ubuntu/maci/cli/build/generateProofs.js:14:53)
+    at fulfilled (/home/ubuntu/maci/cli/build/generateProofs.js:5:58)
 ```
 
 You can generate the missing `.dat` files using the following command:
@@ -54,7 +54,7 @@ pnpm build:circuits-c -- --outPath ../cli/zkeys
 
 ### Case `Commitment mismatch`
 
-If your log looks like the following, that's because you have already run the `prove` command. You can access the `cli` and attempt again by executing the `genProofs` command.
+If your log looks like the following, that's because you have already run the `prove` command. You can access the `cli` and attempt again by executing the `generateProofs` command.
 
 ```
 Error: commitment mismatch
@@ -69,7 +69,7 @@ Error: commitment mismatch
  ELIFECYCLE  Command failed with exit code 1.
 ```
 
-This is because commitments are generated using random salts, thus will differ at each `genProofs` run.
+This is because commitments are generated using random salts, thus will differ at each `generateProofs` run.
 
 In [core/Poll.ts](https://github.com/privacy-scaling-explorations/maci/blob/dev/packages/core/ts/Poll.ts):
 
@@ -84,7 +84,7 @@ while (this.sbSalts[this.currentMessageBatchIndex!] === newSbSalt) {
 
 ### Case `AssertionError`
 
-This could happen when you run `prove` in the `contracts` package, or run `genProofs` in the `cli` package. If your log looks like the following, there are two possible reasons:
+This could happen when you run `prove` in the `contracts` package, or run `generateProofs` in the `cli` package. If your log looks like the following, there are two possible reasons:
 
 1. If your MACI keypair for the coordinator was generated based on a previous version, it may have been generated incorrectly due to a breaking change in a third-party package (`zk-kit/eddsa-poseidon`). Please generate a new pair and run the whole process again.
 2. The provided private key is unmatched to the public key which deployed the poll, you will need to input the correct private key.
@@ -130,7 +130,7 @@ TypeError: cannot filter non-indexed parameters; must be null (argument="contrac
 }
 ```
 
-This could happen during running `genProofs` in `cli` package, or running `prove` in `contracts` package.
+This could happen during running `generateProofs` in `cli` package, or running `prove` in `contracts` package.
 Be aware that we updated several parameters to `indexed`:
 
 ```javascript
@@ -144,7 +144,7 @@ Please remember to pull the latest MACI repo updates(`git fetch origin && git pu
 
 ### Verifier contract found the proof invalid
 
-If your log looks like the following, that's because the zkey and wasm files added to the [`VkRegistry` contract](/docs/technical-references/smart-contracts/VkRegistry) are different from what you use to run the **prove** command. Check if you're using the correct zkey and wasm files.
+If your log looks like the following, that's because the zkey and wasm files added to the [`VerifyingKeysRegistry` contract](/docs/technical-references/smart-contracts/VerifyingKeysRegistry) are different from what you use to run the **prove** command. Check if you're using the correct zkey and wasm files.
 
 ```
 Error: The verifier contract found the proof invalid.
@@ -159,3 +159,48 @@ Error: The verifier contract found the proof invalid.
 ### The on-chain verification of total spent voice credits failed
 
 If you ran the `verify` command and got this error, please ensure consistency in your use of quadratic voting throughout interactions with MACI, including poll deployment, proof generation, and verification.
+
+### Proof generation process is killed
+
+If your terminal output ends like this:
+
+```
+[i] Starting to fetch logs from block 8386826
+[i] Generating proofs of message processing...
+[i] Progress: 1 / 1
+[i] Wait until proof generation is finished
+Killed
+ELIFECYCLE  Command failed with exit code 137.
+```
+
+This typically indicates the proof generation process was terminated due to exceeding the system's available memory limit (exit code `137` = SIGKILL by the OS, often due to OOM).
+
+Increase Node.js' memory allocation by setting the `NODE_OPTIONS` environment variable before running the command:
+
+```bash
+export NODE_OPTIONS="--max-old-space-size=4096"
+# You can increase the value further (e.g., 8192 for 8GB) if your system has enough RAM:
+export NODE_OPTIONS="--max-old-space-size=8192"
+```
+
+### Error: Not enough or too many values for input signals
+
+If you see errors like:
+
+```
+Error: Not enough values for input signal currentVoteWeightsPathElements
+at /home/maci/node_modules/.pnpm/circom_runtime@0.1.28/node_modules/circom_runtime/build/main.cjs:513:27
+...
+```
+
+```
+Error: Too many values for input signal ballots
+at /home/maci/node_modules/.pnpm/circom_runtime@0.1.28/node_modules/circom_runtime/build/main.cjs:513:27
+...
+```
+
+This usually happens when the Merkle tree depth configured in your MACI deployment does not match the depth expected by the zkey files used during proof generation.
+To solve this:
+
+- Download the correct zkey files from a trusted source.
+- Verify that the `stateTreeDepth`, `messageTreeDepth`, and `voteOptionTreeDepth` used in your CLI or config match the values used to generate those zkey files.

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

@@ -73,7 +73,7 @@ Currently, the ceremony artifacts work with MACI version up to 2.x
 In order to run MACI polls, a coordinator is required to publish their MACI public key. You will need to generate a MACI keypair, and treat the private key just as your ethereum private keys. Please store them in a safe place as you won't be able to finish a round if you lose access, or if compromised a bad actor could decrypt the vote and publish them online. You can generate a new key pair using maci-cli by running the following command in the root of the project:
 
 ```bash
-pnpm run genMaciKeyPair
+pnpm run generate-maci-keypair
 ```
 
 ### Set the .env
@@ -131,20 +131,20 @@ For testing we suggest using the **FreeForAlPolicy** as it allows anyone to sign
 | **stateTreeDepth** | Defines how many users the system supports. |
 | **policy**         | Defines which policy to use.                |
 
-#### VkRegistry
+#### VerifyingKeysRegistry
 
-The VkRegistry 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.
+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**.
@@ -156,7 +156,7 @@ The recommended values for test keys are: **10-1-2-2-1**. For ceremony keys: **1
 | --------------------------- | ----------------------------------------------------------------- |
 | **pollStartDate**           | Defines when the poll starts in seconds.                          |
 | **pollEndDate**             | Defines how long is going to be the poll in seconds.              |
-| **coordinatorPubkey**       | Defines the coordinator public MACI key.                          |
+| **coordinatorPublicKey**    | Defines the coordinator public MACI key.                          |
 | **useQuadraticVoting**      | Defines if the poll uses quadratic voting or not.                 |
 | **policy**                  | Defines the policy of the poll.                                   |
 | **relayers**                | Defines an array of addresses that are allowed to relay messages. |
@@ -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 generate-maci-keypair`.
+
+`--start-block` is the block number from which to start looking for events from. You can use the block that you deployed the contracts in.
+
+You can reduce the time of the proving by including more blocks per batch with `--blocks-per-batch`, you can try with 500.
 :::
 
 #### Submit On-chain
@@ -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
@@ -277,7 +285,7 @@ Once the proofs are generated, and results tallied, the results (Tally) are writ
     "salt": "0x24f57b75c227987727c13d1e83409d70478b42bdc12a4a4df8129c72fbaf5aaf",
     "commitment": "0xb4ebe68b0da828c0b978ddee86ba934b8e215499ac766491f236ad85fd606de"
   },
-  "perVOSpentVoiceCredits": {
+  "perVoteOptionSpentVoiceCredits": {
     "tally": [
       "81",
       "0",
@@ -315,4 +323,4 @@ We observe an array named results, which holds the aggregated votes for each opt
 
 The `totalSpentVoiceCredits` object contains the total amount of voice credits spent in the poll. This is the sum of all voice credits spent by all voters, and in quadratic voting, is the sum of the squares of all votes.
 
-The `perVOSpentVoiceCredits` will contain the amount of voice credits spent per vote option. In this case, the first option received 81 voice credits, and every other option received 0 voice credits. This is because there was only one valid vote casted, with a weight of 9. Given the quadratic voting formula, the total amount of voice credits spent is 81.
+The `perVoteOptionSpentVoiceCredits` will contain the amount of voice credits spent per vote option. In this case, the first option received 81 voice credits, and every other option received 0 voice credits. This is because there was only one valid vote casted, with a weight of 9. Given the quadratic voting formula, the total amount of voice credits spent is 81.

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

@@ -28,6 +28,7 @@ sidebar_position: 13
 - [MACI - Starting From Scratch](https://www.youtube.com/watch?v=qVuhWlHnQF0) - Doris Chan 03/2024
 - [MACI Workshop](https://www.youtube.com/watch?v=AimgqnMjG0o) - ctrlc03 04/2024
 - [MACI Starter Kit Demo](https://www.youtube.com/watch?v=pYoBLLtVEoI&t=1s) - Yash 05/2024
+- [The Promise of Blockchain Voting](https://www.youtube.com/watch?v=TQxR7U52ne0) - Sam Richards 06/2024
 - [MACI Tutorial Deploying Contracts and Subgraph](https://www.youtube.com/watch?v=-QA0VB9EUMk) - Crisgarner 09/2024
 - [MACI Tutorial Frontend Deployment 🚀](https://www.youtube.com/watch?v=q0yS8RfwDcw) - Crisgarner 09/2024
 - [Finalizing a MACI Round](https://www.youtube.com/watch?v=nlS3hOC0ljw) - Crisgarner 09/2024

package/versioned_docs/version-v3.x/security/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**