@maci-protocol/website 0.0.0-ci.26f28d6 → 0.0.0-ci.2d2f5fb

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

@@ -7,7 +7,7 @@ sidebar_position: 2
 
 There are a number of MACI's smart contracts which can be re-used by different deployments. These are the following:
 
-- [VkRegistry](https://github.com/privacy-scaling-explorations/maci/blob/dev/contracts/contracts/VkRegistry.sol)
+- [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)
@@ -29,7 +29,7 @@ cd cli && node build/ts/index.js checkVerifyingKeys -q false -vk 0x74569d524a193
 ```
 
 :::info
-You should change the -vk parameter to the VkRegistry address for the chain you are deploying to. Also you might need to modify the parameters based on the circuit configuration. Please refer to the [circuits page](/docs/technical-references/zk-snark-circuits/setup) for more information. Also you can add `-uq false` if you want to check non quadratic voting keys.
+You should change the -vk parameter to the VerifyingKeysRegistry address for the chain you are deploying to. Also you might need to modify the parameters based on the circuit configuration. Please refer to the [circuits page](/docs/technical-references/zk-snark-circuits/setup) for more information. Also you can add `-uq false` if you want to check non quadratic voting keys.
 :::
 
 ## Contract Addresses

package/versioned_docs/version-v3.x/technical-references/coordinator-service/_category_.json

@@ -0,0 +1,8 @@
+{
+  "label": "Coordinator Service",
+  "position": 1,
+  "link": {
+    "type": "generated-index",
+    "description": "The Coordinator Service is a backend service that aims to automate MACI-related operations, such as contracts deployment, proof generation and poll finalisation."
+  }
+}

package/versioned_docs/version-v3.x/technical-references/coordinator-service/index.md

@@ -0,0 +1,10 @@
+---
+title: Introduction
+description: The Coordinator Service is a service that allows to automate MACI coordinator tasks.
+sidebar_label: Introduction
+sidebar_position: 1
+---
+
+# Coordinator Service
+
+Welcome to the Coordinator Service technical reference. Here you will find the technical details of the Coordinator Service, including the API endpoints and code examples.

package/versioned_docs/version-v3.x/technical-references/coordinator-service/installation.md

@@ -0,0 +1,43 @@
+---
+title: Installation and setup
+description: Learn how to install and setup the Coordinator Service.
+sidebar_label: Installation
+sidebar_position: 2
+---
+
+1. Add `.env` file (see `.env.example`).
+2. Generate RSA key pair with `pnpm run generate-keypair`.
+3. Download zkey files using `pnpm run download-zkeys:{type}` (only test type is available for now).
+4. Make sure you copied RSA public key to your application. This will be needed for encrypting `Authorization` header and coordinator private key for proof generation. Also it can be accessed through API method `GET v1/proof/publicKey`.
+5. Run `pnpm run start` to run the service.
+6. All API calls must be called with `Authorization` header, where the value is encrypted with RSA public key you generated before. Header value contains message signature and message digest created by `COORDINATOR_ADDRESSES`. The format is `publicEncrypt({signature}:{digest})`.
+   Make sure you set `COORDINATOR_ADDRESSES` env variable and sign any message with the addresses from your application (see [AccountSignatureGuard](./ts/auth/AccountSignatureGuard.service.ts)).
+7. Proofs can be generated with `POST v1/proof/generate` API method or with Websockets (see [dto spec](./ts/proof/dto.ts), [controller](./ts/app.controller.ts) and [wsgateway](./ts/events/events.gateway.ts)).
+
+## Subgraph deployment
+
+It is possible to deploy subgraph using coordinator service.
+
+First, you need to setup subgraph and create a project. [Subgraph dashboard](https://thegraph.com/studio/).
+
+Then, set env variables:
+
+```
+# Subgraph name
+SUBGRAPH_NAME="maci-subgraph"
+
+# Subgraph provider url
+SUBGRAPH_PROVIDER_URL=https://api.studio.thegraph.com/deploy/
+
+# Subgraph deploy key
+SUBGRAPH_DEPLOY_KEY=*******
+
+# Subgraph project folder
+SUBGRAPH_FOLDER=../subgraph
+```
+
+After deployment, subgraph url will be available in studio dashboard and you can use this type of url to get latest deployed version in your application:
+
+```
+https://api.studio.thegraph.com/.../{SUBGRAPH_NAME}/version/latest
+```

package/versioned_docs/version-v3.x/technical-references/offchain-relayer/_category_.json

@@ -0,0 +1,8 @@
+{
+  "label": "Offchain Relayer",
+  "position": 1,
+  "link": {
+    "type": "generated-index",
+    "description": "The Offchain Relayer is a service that allows users to vote on MACI polls free of charge."
+  }
+}

package/versioned_docs/version-v3.x/technical-references/offchain-relayer/index.md

@@ -0,0 +1,51 @@
+---
+title: Introduction
+description: The Offchain Relayer is a service that allows users to vote on MACI polls free of charge.
+sidebar_label: Introduction
+sidebar_position: 1
+---
+
+# Coordinator Service
+
+Welcome to the Offchain Relayer technical reference. Here you will find the technical details of the Offchain Relayer: how to set it up and and how to use it.
+
+## Flow Diagram
+
+Below is a high-level diagram illustrating the flow of the Relayer Service:
+
+![MACI Relayer Flow](/img/relayer-diagram.png)
+
+## High-Level Overview of the Relayer:
+
+### Functionality
+
+The Relayer serves as an intermediary between users and the MACI system. It performs the following tasks:
+
+- Allows users to send messages without having to pay gas fees by processing these messages off-chain.
+- Receives user messages.
+- Prepare messages batches and upload it to IPFS
+- Submits the message hashes to the Poll contract with IPFS hash of the batch.
+
+This process ensures that user actions are recorded on-chain without compromising their privacy.
+
+### Privacy Preservation
+
+By verifying the zero-knowledge proofs, the Relayer ensures that only authorized users can send messages.
+Users must know the pre-image to a state leaf in the poll state tree.
+
+### Decentralization and Trust
+
+It's recommended that the coordinator only runs this service for now. That is because if the service malfunctions and batch hashes are pushed on chain without the messages actually being stored on ipfs, then polls can't be finalized.
+
+### Integration with MACI Components
+
+The Relayer interacts with other components of the MACI system, such as the **Coordinator** and the on-chain smart contracts:
+
+- The **Coordinator** fetches all the messages stored in IPFS and uses them as regular on-chain messages.
+- This ensures that user messages are properly processed and recorded, contributing to the overall functionality and security of the voting protocol.
+
+### Additional Information
+
+For more details, you can read the following post on EthResearch:
+
+[MACI with Mostly Off-Chain Happy Path](https://ethresear.ch/t/maci-with-mostly-off-chain-happy-path/19527)

package/versioned_docs/version-v3.x/technical-references/offchain-relayer/installation.md

@@ -0,0 +1,109 @@
+---
+title: Installation and setup
+description: Learn how to install and setup the Offchain Relayer service.
+sidebar_label: Setup
+sidebar_position: 2
+---
+
+## Prerequisites
+
+Make sure you have the following tools installed on your system:
+
+- **Docker**: [Install Docker](https://www.docker.com/products/docker-desktop)
+- **Docker Compose**: [Install Docker Compose](https://docs.docker.com/compose/install/)
+
+## Getting Started
+
+Follow these steps to run the MACI Relayer service using Docker.
+
+### 1. Clone the Repository
+
+First, clone the repository to your local machine.
+
+```bash
+git clone https://github.com/privacy-scaling-explorations/maci
+cd maci
+```
+
+## 2. Configure Environment Variables
+
+The `.env` file contains sensitive configuration values that will be injected into the Docker containers at runtime. To set them up:
+
+1. Copy the `.env.example` file to `.env`.
+
+```bash
+cp .env.example .env
+```
+
+2. Edit the `.env` file and configure the variables.
+
+## 3. Build and Run the Docker Containers
+
+Now that your environment is set up, it's time to build and run the Docker containers.
+
+Run the following command from the root directory of your project:
+
+```bash
+docker-compose up --build
+```
+
+This command does the following:
+
+- Builds the Docker images based on the Dockerfile and `docker-compose.yml` files.
+- Starts the service container (the MACI relayer application) and the mongodb container.
+
+The MACI Relayer service will be available on port 3000 by default (you can modify this in the `.env` file).
+
+## 4. Access the Service
+
+Once the containers are up and running, you can access the relayer service at:
+
+```
+http://localhost:3000
+```
+
+Additionally, the Swagger UI documentation for the Relayer service API can be accessed at:
+
+```
+http://localhost:3000/api
+```
+
+You can interact with the API through the Swagger interface, which provides a convenient way to test endpoints and view the API methods.
+
+## 5. Check Logs
+
+To view the logs from the containers and troubleshoot any issues, run:
+
+```bash
+docker-compose logs
+```
+
+This will display logs from both the service (relayer) and mongodb containers.
+
+## 6. Stop the Services
+
+To stop the containers and remove the containers (but keep the volumes), use the following command:
+
+```bash
+docker-compose down
+```
+
+This will stop and remove the containers but retain the volumes (like MongoDB data). To also remove the volumes, run:
+
+```bash
+docker-compose down --volumes
+```
+
+## 7. MongoDB Persistence
+
+MongoDB data is persisted using Docker volumes (`mongodb-data`). Even if you remove and recreate the MongoDB container, the data will persist.
+
+This ensures that any data stored in the MongoDB database is not lost even if the container is restarted or removed.
+
+If you'd like to remove the persisted data as well, you can remove the volume by running:
+
+```bash
+docker volume rm your-repo_mongodb-data
+```
+
+This will delete the volume, along with all the data stored in MongoDB.

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

@@ -62,12 +62,12 @@ This function does the following:
 - hashes the public key and inserts it into the state tree.
 
 ```ts
-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();
   }
 
@@ -76,13 +76,13 @@ function signUp(PubKey memory _pubKey, bytes memory _signUpPolicyData) public vi
   signUpPolicy.register(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);
 }
 ```
 
@@ -156,5 +156,5 @@ Polls require the following information:
 - `voteOptions`: the number of vote options for the poll
 
 :::info
-Please be advised that the number of signups in the MACI contract (number of leaves in the merkle tree holding MACI's state) considers the initial zero leaf as one signup. For this reason, when accounting for the real users signed up to MACI, you should subtract one from the value returned from the `numSignUps` function.
+Please be advised that the number of signups in the MACI contract (number of leaves in the merkle tree holding MACI's state) considers the initial zero leaf as one signup. For this reason, when accounting for the real users signed up to MACI, you should subtract one from the value returned from the `totalSignups` function.
 :::

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

@@ -26,7 +26,7 @@ The `joinPoll` function looks as follows:
   /// @inheritdoc IPoll
   function joinPoll(
     uint256 _nullifier,
-    PubKey calldata _pubKey,
+    PublicKey calldata _publicKey,
     uint256 _stateRootIndex,
     uint256[8] calldata _proof,
     bytes memory _signUpPolicyData,
@@ -41,7 +41,7 @@ The `joinPoll` function looks as follows:
     pollNullifiers[_nullifier] = true;
 
     // Verify user's proof
-    if (!verifyJoiningPollProof(_nullifier, _stateRootIndex, _pubKey, _proof)) {
+    if (!verifyJoiningPollProof(_nullifier, _stateRootIndex, _publicKey, _proof)) {
       revert InvalidPollProof();
     }
 
@@ -55,7 +55,7 @@ The `joinPoll` function looks as follows:
     );
 
     // 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);
 
@@ -63,7 +63,7 @@ The `joinPoll` function looks as follows:
     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);
   }
 ```
 
@@ -72,7 +72,7 @@ The `joinPoll` function looks as follows:
 The `publishMessage` function looks as follows:
 
 ```ts
-function publishMessage(Message calldata _message, PubKey calldata _encPubKey) public virtual isOpenForVoting {
+function publishMessage(Message calldata _message, PublicKey calldata _encPubKey) public virtual isOpenForVoting {
   // check if the public key is on the curve
   if (!CurveBabyJubJub.isOnCurve(_encPubKey.x, _encPubKey.y)) {
     revert InvalidPubKey();
@@ -84,7 +84,7 @@ function publishMessage(Message calldata _message, PubKey calldata _encPubKey) p
   }
 
   // compute current message hash
-  uint256 messageHash = hashMessageAndEncPubKey(_message, _encPubKey);
+  uint256 messageHash = hashMessageAndPublicKey(_message, _encPubKey);
 
   // update current message chain hash
   updateChainHash(messageHash);
@@ -96,7 +96,7 @@ function publishMessage(Message calldata _message, PubKey calldata _encPubKey) p
 The `publishMessageBatch` function looks as follows:
 
 ```ts
-function publishMessageBatch(Message[] calldata _messages, PubKey[] calldata _encPubKeys) public virtual {
+function publishMessageBatch(Message[] calldata _messages, PublicKey[] calldata _encPubKeys) public virtual {
   if (_messages.length != _encPubKeys.length) {
     revert InvalidBatchLength();
   }

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

@@ -16,14 +16,14 @@ This contract should be deployed alongside a `Poll`, with the the constructor ac
 ```ts
   constructor(
     address _verifier,
-    address _vkRegistry,
+    address _verifyingKeysRegistry,
     address _poll,
     address _mp,
     address _tallyOwner,
     Mode _mode
   ) payable {
     verifier = IVerifier(_verifier);
-    vkRegistry = IVkRegistry(_vkRegistry);
+    vkRegistry = IVkRegistry(_verifyingKeysRegistry);
     poll = IPoll(_poll);
     messageProcessor = IMessageProcessor(_mp);
     mode = _mode;

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

@@ -1,15 +1,15 @@
 ---
-title: VkRegistry Smart Contract
-description: VkRegistry smart contract
-sidebar_label: VkRegistry
+title: VerifyingKeysRegistry Smart Contract
+description: VerifyingKeysRegistry smart contract
+sidebar_label: VerifyingKeysRegistry
 sidebar_position: 8
 ---
 
 :::info
-Code location: [VkRegistry.sol](https://github.com/privacy-scaling-explorations/maci/blob/dev/contracts/contracts/VkRegistry.sol)
+Code location: [VerifyingKeysRegistry.sol](https://github.com/privacy-scaling-explorations/maci/blob/dev/contracts/contracts/VerifyingKeysRegistry.sol)
 :::
 
-The VkRegistry is a contract that holds the verifying keys for the zk-SNARK circuits. It holds four different sets of keys:
+The VerifyingKeysRegistry is a contract that holds the verifying keys for the zk-SNARK circuits. It holds four different sets of keys:
 
 - `processVks` - The keys for the processMessages circuit
 - `tallyVks` - The keys for the tallyVotes circuit

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

@@ -21,8 +21,8 @@ Users need to provide a valid proof to the Poll smart contract to join a poll, a
 
 | Input signal           | Description                                                                                                                                                                        |
 | ---------------------- | ---------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- |
-| `privKey`              | The user's private key                                                                                                                                                             |
-| `pollPubKey`           | The poll's public key                                                                                                                                                              |
+| `privateKey`           | The user's private key                                                                                                                                                             |
+| `pollPublicKey`        | The poll's public key                                                                                                                                                              |
 | `siblings`             | The siblings for the merkle tree inclusion proof                                                                                                                                   |
 | `indices`              | The indices for the merkle tree inclusion proof                                                                                                                                    |
 | `nullifier`            | The nullifier                                                                                                                                                                      |
@@ -44,9 +44,8 @@ Users will use this circuit to anonymously prove that they joined a poll. This c
 
 | Input signal           | Description                                                                                                                                                                        |
 | ---------------------- | ---------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- |
-| `privKey`              | The user's private key                                                                                                                                                             |
+| `privateKey`           | The user's private key                                                                                                                                                             |
 | `voiceCreditsBalance`  | The user's initial voice credits balance                                                                                                                                           |
-| `joinTimestamp`        | The timestamp of when the user joined the poll                                                                                                                                     |
 | `pathElements`         | The path elements for the merkle tree inclusion proof                                                                                                                              |
 | `pathIndices`          | The path indices for the merkle tree inclusion proof                                                                                                                               |
 | `stateRoot`            | The MACI state tree root                                                                                                                                                           |

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

@@ -7,7 +7,7 @@ sidebar_position: 3
 
 [**Repo link**](https://github.com/privacy-scaling-explorations/maci/blob/dev/circuits/circom/core)
 
-This circuit allows the coordinator to prove that they have correctly processed each message in reverse order, in a consecutive batch of 5 ^ msgBatchDepth messages to the respective state leaf within the state tree. Coordinators would use this circuit to prove correct execution at the end of each Poll.
+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 pre-requisites for this circuit are:
@@ -36,17 +36,17 @@ A version working with non quadratic voting (non-qv) is also [available](https:/
 
 | Input signal                     | Description                                                                             |
 | -------------------------------- | --------------------------------------------------------------------------------------- |
-| `numSignUps`                     | Number of users that have completed the sign up                                         |
+| `totalSignups`                   | Number of users that have completed the sign up                                         |
 | `index`                          | The batch index of current message batch                                                |
 | `pollEndTimestamp`               | The Unix timestamp at which the poll ends                                               |
-| `msgRoot`                        | The root of the message tree                                                            |
-| `msgs`                           | The batch of messages as an array of arrays                                             |
-| `msgSubrootPathElements`         | As described below                                                                      |
+| `messageRoot`                    | The root of the message tree                                                            |
+| `messages`                       | The batch of messages as an array of arrays                                             |
+| `messageSubrootPathElements`     | As described below                                                                      |
 | `coordinatorPublicKeyHash`       | $\mathsf{poseidon_2}([cPk_x, cPk_y])$                                                   |
 | `newSbCommitment`                | As described below                                                                      |
-| `coordPrivKey`                   | The coordinator's private key                                                           |
+| `coordinatorPrivateKey`          | The coordinator's private key                                                           |
 | `batchEndIndex`                  | The last batch index                                                                    |
-| `encPubKeys`                     | The public keys used to generate shared ECDH encryption keys to encrypt the messages    |
+| `encryptionPublicKeys`           | The public keys used to generate shared ECDH encryption keys to encrypt the messages    |
 | `currentStateRoot`               | The state root before the commands are applied                                          |
 | `currentStateLeaves`             | The state leaves upon which messages are applied                                        |
 | `currentStateLeavesPathElements` | The Merkle path to each incremental state root                                          |
@@ -74,9 +74,9 @@ The salt used to produce `currentSbCommitment` (see above).
 
 The salt used to produce `newSbCommitment` (see above).
 
-##### `msgSubrootPathElements`
+##### `messageSubrootPathElements`
 
-The index of each message in `msgs` is consecutive. As such, in order to prove that each message in `msgs` is indeed a leaf of the message tree, we compute the subtree root of `msgs`, and then verify that the subtree root is indeed a subroot of `msgRoot`.
+The index of each message in `messages` is consecutive. As such, in order to prove that each message in `messages` is indeed a leaf of the message tree, we compute the subtree root of `messages`, and then verify that the subtree root is indeed a subroot of `messageRoot`.
 
 A simplified example using a tree of arity 2:
 
@@ -100,7 +100,7 @@ This method requires fewer circuit constraints than if we verified a Merkle proo
 
 1. That the prover knows the preimage to `currentSbCommitment` (that is, the state root, ballot root, and `currentSbSalt`)
 2. That `maxVoteOptions <= (5 ^ voteOptionTreeDepth)`
-3. That `numSignUps <= (2 ^ stateTreeDepth)`
-4. That `coordinatorPublicKeyHash` is a hash of public key that is correctly derived from `coordPrivKey`
-5. That each message in `msgs` exists in the message tree
+3. That `totalSignups <= (2 ^ stateTreeDepth)`
+4. That `coordinatorPublicKeyHash` is a hash of public key that is correctly derived from `coordinatorPrivateKey`
+5. That each message in `messages` exists in the message tree
 6. That after decrypting and applying each message, in reverse order, to the corresponding state and ballot leaves, the new state root, new ballot root, and `newSbSalt` are the preimage to `newSbCommitment`

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

@@ -25,7 +25,7 @@ A version working with non quadratic voting (non-qv) is also [available](https:/
 
 | Input signal                            | Description                                                      |
 | --------------------------------------- | ---------------------------------------------------------------- |
-| `numSignUps`                            | The number of users that signup                                  |
+| `totalSignups`                          | The number of users that signup                                  |
 | `index`                                 | Start index of given batch                                       |
 | `sbCommitment`                          | Described below                                                  |
 | `currentTallyCommitment`                | Described below                                                  |
@@ -72,7 +72,7 @@ $poseidon_3([tc_r, tc_t, tc_p])$
 #### Statements that the circuit proves
 
 1. That the coordinator knows the preimage of `sbCommitment`
-2. That `index` is less than or equal to `numSignUps`
+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)`
 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:

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

@@ -15,7 +15,7 @@ It outputs one field element, which is the SHA256 hash of the following inputs:
 
 1. `packedVals`
 2. `pollEndTimestamp`
-3. `msgRoot`
+3. `messageRoot`
 4. `coordinatorPubKeyHash`
 5. `newSbCommitment`
 6. `currentSbCommitment`