fix: typo fix roundup

README.md

@@ -29,7 +29,11 @@ To build the C++ code, follow the [instructions in the circuits subdirectory](./
 To build Typescript code, make sure to have [`nvm`](https://github.com/nvm-sh/nvm) (node version manager) installed.
 
 To build noir code, make sure that you are using the version from `yarn-project/noir-compiler/src/noir-version.json`.
-Install nargo by running `noirup -v TAG_FROM_THE_FILE`.
+
+Install nargo by running 
+```
+noirup -v TAG_FROM_THE_FILE
+```
 
 ## Continuous Integration
 

circuits/README.md

@@ -215,7 +215,7 @@ See pseudocode in [this diagram](https://miro.com/app/board/uXjVPlafJWM=/) and t
 
 ## Public Kernel Circuit
 
-The public kernel circuit performs many of the functions of the private kernel circuit but for public functions. Public functions differ from public functions in that they they are exeucted by the sequencer and can modify the public state tree. Like private functions, public functions can include calls to other public functions and these calls are validated within the circuit.
+The public kernel circuit performs many of the functions of the private kernel circuit but for public functions. Public functions differ from public functions in that they they are executed by the sequencer and can modify the public state tree. Like private functions, public functions can include calls to other public functions and these calls are validated within the circuit.
 
 The public kernel circuit in Aztec 3 is implemented in [`circuit/kernel/public`](https://github.com/AztecProtocol/aztec3-packages/tree/master/circuits/cpp/src/aztec3/circuits/kernel/publlic) directory. The input and output interface of the private kernel circuit is written in [`circuits/abis/public_kernel`](https://github.com/AztecProtocol/aztec3-packages/tree/master/circuits/cpp/src/aztec3/circuits/abis/public_kernel).
 

docs/docs/concepts/advanced/public_vm.md

@@ -17,7 +17,7 @@ Point 2 requires a Virtual Machine architecture. The older model of having ACIR
 
 The kernel circuit cannot prevent this by _requiring_ the public function proof to succeed, as it is trivial for a malicious contract writer to create unsatisfiable programs (e.g. `assert(true == false)`).
 
-We cannot require a Prover/Sequencer simulates the transaction to determine whether it is possible to include it in the block proof, as this amounts to unpaid compute that can be used as a DoS attack vector.
+We cannot require that a Prover/Sequencer simulates the transaction to determine whether it is possible to include it in the block proof, as this amounts to unpaid compute that can be used as a DoS attack vector.
 
 ### VM Solution
 
@@ -51,7 +51,7 @@ The following L1 costs also apply:
 
 Under a VM model, the VM simulator can perform opcode-by-opcode gas metering.
 
-(need to define VM arch for more detail)
+(need to define VM architecture for more detail)
 
 ## VM ABI
 
@@ -242,7 +242,7 @@ Additional witness commitments required that are not part of UltraPlonk/Honk:
 
 $PC, I, C_{w1}, C_{w2}, C_{w3}, C_{w4}, E, G, T_{w1}, T_{w2}, T_{w3}, T_{w4}$
 
-In addition, selector context polynomials $C_{q}$ will likely represent least 4 selectors in order to handle ACIR's linear combination instruction
+In addition, selector context polynomials $C_{q}$ will likely represent at least 4 selectors in order to handle ACIR's linear combination instruction
 
 That's 28 additional witness polynomial commitments on top of the usual Honk commitments.
 

docs/docs/concepts/foundation/state_model/main.md

@@ -6,7 +6,7 @@ Aztec has a hybrid public/private state model. Aztec contract developers can spe
 
 ## Public State
 
-Aztec has public state that will be familiar to developers coming that have worked on other blockchains. Public state is transparent is managed by the associated smart contract logic.
+Aztec has public state that will be familiar to developers coming that have worked on other blockchains. Public state is transparent and is managed by the associated smart contract logic.
 
 Internal to the Aztec network, public state is stored and updated by the sequencer. The sequencer executes state transitions, generates proofs of correct execution (or delegates proof generation to the prover network), and publishes the associated data to Ethereum.
 

docs/docs/concepts/foundation/state_model/storage_slots.md

@@ -3,7 +3,7 @@ title: Storage Slots
 description: How are storage slots derived for public and private state
 ---
 
-In Aztec private data and public data are stored in two trees, a public data tree and a note hashes tree. 
+In Aztec, private data and public data are stored in two trees; a public data tree and a note hashes tree. 
 
 These trees have in common that they store state for *all* accounts on the Aztec network directly as leaves. This is different from Ethereum, where a state trie contains smaller tries that hold the individual accounts' storage.
 
@@ -28,7 +28,7 @@ For structs and arrays, we are logically using a similar storage slot computatio
 
 Private storage is a different beast. As you might remember from [State Model](./main.md), private state is stored in encrypted logs and the corresponding private state commitments in append-only tree where each leaf is a commitment. Being append-only, means that leaves are never updated or deleted; instead a nullifier is emitted to signify that some note is no longer valid. A major reason we used this tree, is that lookups at a specific storage slot would leak information in the context of private state. If you could look up a specific address balance just by looking at the storage slot, even if encrypted you would be able to see it changing! That is not good privacy. 
 
-Following this. The storage slot as we know it doesn't really exists. The leaves of the note hashes tree are just commitments to content (think of it as a hash of its content). 
+Following this, the storage slot as we know it doesn't really exist. The leaves of the note hashes tree are just commitments to content (think of it as a hash of its content). 
 
 Nevertheless, the concept of a storage slot is very useful when writing applications, since it allows us to reason about distinct and disjoint pieces of data. For example we can say that the balance of an account is stored in a specific slot and that the balance of another account is stored in another slot with the total supply stored in some third slot. By making sure that these slots are disjoint, we can be sure that the balances are not mixed up and that someone cannot use the total supply as their balance. 
 
@@ -62,4 +62,4 @@ By doing this address-siloing at the kernel circuit we *force* the inserted comm
 To ensure that nullifiers don't collide across contracts we also force this contract siloing at the kernel level.
 :::
 
-For an example of this see [developer documentation storage slots](./../../../dev_docs/contracts/syntax/storage/storage_slots.md).
+For an example of this see [developer documentation storage slots](./../../../dev_docs/contracts/syntax/storage/storage_slots.md).

docs/docs/dev_docs/limitations/main.md

@@ -221,7 +221,7 @@ Note that there is no plan to change this in the future.
 
 ### Example
 
-Let us assume that the main function named $f_1$ is calling in order $f_2$, $f_3$ (which calls $f_5$ folllowed by $f_6$), and $f_4$.
+Let us assume that the main function named $f_1$ is calling in order $f_2$, $f_3$ (which calls $f_5$ followed by $f_6$), and $f_4$.
 
 Call Dependency:
 
@@ -239,13 +239,13 @@ Private Kernel Processing Order:
 
 #### What are the consequences?
 
-Transaction output elements such as notes in encrypted logs, note hashes (commitments), nullifiers might be ordered differently than the one exepected by the execution.
+Transaction output elements such as notes in encrypted logs, note hashes (commitments), nullifiers might be ordered differently than the one expected by the execution.
 
 ### Chopped Transient Notes are still Emitted in Logs
 
 A note which is created and nullified during the very same transaction is called transient. Such a note is chopped by the [private kernel circuit](../../concepts/advanced/circuits/kernels/private_kernel.md) and is never stored in any persistent data tree.
 
-For the time being, such chopped notes are still emitted through encrypted logs (which is the communication channel to transmit notes). When a log containing a chopped note is processed, a warning will be logged about a decrypted note which does not exist in data tree. We [improved](https://github.com/AztecProtocol/aztec-packages/issues/1603) error logging to help identify such an occurence. However, this might be a source of confusion.
+For the time being, such chopped notes are still emitted through encrypted logs (which is the communication channel to transmit notes). When a log containing a chopped note is processed, a warning will be logged about a decrypted note which does not exist in data tree. We [improved](https://github.com/AztecProtocol/aztec-packages/issues/1603) error logging to help identify such an occurrence. However, this might be a source of confusion.
 This issue is tracked in ticket [#1641](https://github.com/AztecProtocol/aztec-packages/issues/1641).
 
 ### Note Terminology: Note Commitments and Note Hashes

docs/docs/dev_docs/privacy/main.md

@@ -65,7 +65,7 @@ Tl;dr: app developers should think about the _timing_ of user transactions, and
 
 ### Function Fingerprints and Tx Fingerprints
 
-A 'Function Fingerprint' is any data which is exposed by a function to the outside world. A 'Tx Fingerprint' is any data which is exposed by a tx to the outside world. We're interested in minimising leakages of information from private txs. The leakiness of a Tx Fingerprint depends on the leakiness of its consituent functions' Function Fingerprints _and_ on the appearance of the tx's Tx Fingerprint as a whole. For a private function (and by extension, for a private tx), the following information _could_ be leaked (depending on the function, of course):
+A 'Function Fingerprint' is any data which is exposed by a function to the outside world. A 'Tx Fingerprint' is any data which is exposed by a tx to the outside world. We're interested in minimising leakages of information from private txs. The leakiness of a Tx Fingerprint depends on the leakiness of its constituent functions' Function Fingerprints _and_ on the appearance of the tx's Tx Fingerprint as a whole. For a private function (and by extension, for a private tx), the following information _could_ be leaked (depending on the function, of course):
 
 - All calls to public functions.
   - The contract address of the private function (if it calls an internal public function).

yarn-project/README.md

@@ -6,15 +6,36 @@ All the Typescript packages that make up [Aztec](https://docs.aztec.network/azte
 
 All scripts are run in the `yarn-project` workspace root:
 
-- Run `yarn` to install dependencies
-- Run `yarn build:dev` to compile all packages on file changes
-- Run `yarn prepare` to update `tsconfig.json` and `build_manifest.json` references
-- Run `yarn format` to prettify all files
-- Run `yarn formatting` to check prettier and eslint rules on each package (slow)
+- To install dependencies run
+```
+yarn
+```
+- To compile all packages on file changes run
+```
+yarn build:dev
+```
+- To update `tsconfig.json` and `build_manifest.json` references run
+```
+yarn prepare
+```
+- To prettify all files run
+```
+yarn format
+```
+- To check prettier and eslint rules on each package (slow) run
+```
+yarn formatting
+```
 
 ## Tests
 
-To run tests for a specific package, just run `yarn test` in its folder. Note that `end-to-end` tests require `anvil` to be running, which is installed as part of the Foundry toolchain.
+To run tests for a specific package, in its folder just run 
+
+```
+yarn test
+```
+
+Note that `end-to-end` tests require `anvil` to be running, which is installed as part of the Foundry toolchain.
 
 ## Useful extensions
 
@@ -27,7 +48,13 @@ Consider installing the Prettier and ESLint extensions if using VSCode. Configur
 
 ## Package.json inheritance
 
-To simplify the management of all package.json files, we have a custom script that injects the contents of `package.common.json` into all packages that reference it via the `inherits` custom field. To run the script, just run `yarn prepare`. To override any of the fields from `package.common.json`, declare a `package.local.json` local to the package and add it to the `inherits` field.
+To simplify the management of all package.json files, we have a custom script that injects the contents of `package.common.json` into all packages that reference it via the `inherits` custom field. To run the script, just run 
+
+```
+yarn prepare
+```
+
+To override any of the fields from `package.common.json`, declare a `package.local.json` local to the package and add it to the `inherits` field.
 
 ## Adding a new package
 
@@ -61,4 +88,4 @@ COMMIT_TAG=<RELEASE_TAG_NUMBER_YOU_WANT e.g. aztec-packages-v0.8.8>
     - Locally update the package version in package.json using `jq` as shown in the script
     - Do a dry-run
     - If dry run succeeds, publish the package!
-5. Create a PR by adding your package into the `deploy-npm` script so next release onwards, CI can cut releases for your package.
+5. Create a PR by adding your package into the `deploy-npm` script so next release onwards, CI can cut releases for your package.

yarn-project/aztec-sandbox/README.md

@@ -1,12 +1,12 @@
 # aztec-sandbox
 
-Aztec Sandbox is a package that allows for a simple development environment on Aztec stack. It creates an Private eXecution Environment (PXE) that listens for HTTP requests on `localhost:8080` by default. When started, it deploys all necessary L1 Aztec contracts and then starts listening for RPC requests.
+Aztec Sandbox is a package that allows for a simple development environment on Aztec stack. It creates a Private eXecution Environment (PXE) that listens for HTTP requests on `localhost:8080` by default. When started, it deploys all necessary L1 Aztec contracts and then starts listening for RPC requests.
 
 ## How to run:
 
 ### Docker Compose
 
-The easiesty way to run is by using `docker compose up`. This will create two containers:
+The easiest way to run is by using `docker compose up`. This will create two containers:
 
 1. The sandbox listening on port `8080`
 2. An anvil instance listening on port `8545`

yarn-project/boxes/README.md

@@ -1,3 +1,14 @@
-This contains the "boxes" that are meant for quickstarts for Aztec smart contract developers, containing simple Noir smart contracts and frontends.
+# Aztec Boxes
+A minimal framework for building full stack applications for Aztec (using React).
 
-If CI is failing, it may be due to incompatibility with previous build artifacts - running "./bootstrap.sh" inside this boxes folder should regenerate the artifacts.
+## Introduction
+
+This folder contains the "boxes" that are meant for quickstarts for Aztec smart contract developers, including simple Noir smart contracts and frontends.
+
+## Debugging
+
+If CI is failing, it may be due to incompatibility with previous build artifacts - running the following command inside this boxes folder should regenerate the artifacts.
+
+```
+./bootstrap.sh
+```