chore: redo typo PR by cypherpepe (#9687)

Thanks cypherpepe for #9683. Our policy is to redo typo changes to dissuade metric farming. This is an automated script. --------- Co-authored-by: Cypher Pepe <[email protected]>
AztecProtocol · Nov 2, 2024 · c2455bd · c2455bd
1 parent 8e8e16b
commit c2455bd
Show file tree

Hide file tree

Showing 8 changed files with 10 additions and 10 deletions.
diff --git a/docs/docs/reference/developer_references/smart_contract_reference/macros.md b/docs/docs/reference/developer_references/smart_contract_reference/macros.md
@@ -11,7 +11,7 @@ It is also worth mentioning Noir's `unconstrained` function type [here (Noir doc
 
 - `#[aztec]` - Defines a contract, placed above `contract ContractName{}`
 - `#[public]` or `#[private]` - Whether the function is to be executed from a public or private context (see Further Reading)
-- `#[initializer]` - If one or more functions are marked as an initializer, then one of them must be called before any non-initilizer functions
+- `#[initializer]` - If one or more functions are marked as an initializer, then one of them must be called before any non-initializer functions
 - `#[noinitcheck]` - The function is able to be called before an initializer (if one exists)
 - `#[view]` - Makes calls to the function static (see also [Static calls in the protocol spec](../../../protocol-specs/calls/static-calls.md))
 - `#[internal]` - Function can only be called from within the contract

diff --git a/...als/codealong/contract_tutorials/advanced/token_bridge/1_depositing_to_aztec.md b/...als/codealong/contract_tutorials/advanced/token_bridge/1_depositing_to_aztec.md
@@ -58,7 +58,7 @@ Here is an explanation of what it is doing:
      - We use our utility method that creates a sha256 hash but truncates it to fit into a field
    - Since we want to mint tokens on Aztec publicly, the content here is the amount to mint and the address on Aztec who will receive the tokens.
    - We encode this message as a mint_public function call, to specify the exact intentions and parameters we want to execute on L2.
-     - In reality the content can be constructed in any manner as long as the sister contract on L2 can also create it. But for clarity, we are constructing the content like a abi encoded function call.
+     - In reality the content can be constructed in any manner as long as the sister contract on L2 can also create it. But for clarity, we are constructing the content like an ABI encoded function call.
      - It is good practice to include all parameters used by L2 into this content (like the amount and to) so that a malicious actor can’t change the to to themselves when consuming the message.
 3. The tokens are transferred from the user to the portal using `underlying.safeTransferFrom()`. This puts the funds under the portal's control.
 4. Next we send the message to the inbox contract. The inbox expects the following parameters:

diff --git a/docs/docs/tutorials/codealong/simple_dapp/3_contract_interaction.md b/docs/docs/tutorials/codealong/simple_dapp/3_contract_interaction.md
@@ -104,7 +104,7 @@ While [private and public state](../../../aztec/concepts/state_model/index.md) a
 #include_code showPublicBalances yarn-project/end-to-end/src/sample-dapp/index.mjs javascript
 
 :::info
-Since this we are working with pubic balances, we can now query the balance for any address, not just those registered in our local PXE. We can also send funds to addresses for which we don't know their [public encryption key](../../../aztec/concepts/accounts/keys.md#encryption-keys).
+Since this we are working with public balances, we can now query the balance for any address, not just those registered in our local PXE. We can also send funds to addresses for which we don't know their [public encryption key](../../../aztec/concepts/accounts/keys.md#encryption-keys).
 :::
 
 Here, since the token contract does not mint any initial funds upon deployment, the balances for all of our user's accounts will be zero.

diff --git a/l1-contracts/README.md b/l1-contracts/README.md
@@ -10,7 +10,7 @@ Alternatively you can use docker instead, it will handle installations and run t
 
 ## Structure
 
-The `src` folder contain contracts that is to be used by the local developer testnet. It is grouped into 3 catagories:
+The `src` folder contain contracts that is to be used by the local developer testnet. It is grouped into 3 categories:
 
 - `core` contains the required contracts, the bare minimum
 - `mock` contains stubs, for now an always true verifier.

diff --git a/noir-projects/aztec-nr/README.md b/noir-projects/aztec-nr/README.md
@@ -1,5 +1,5 @@
 <div align="center">
-  <img height="210x" src="./assets/Aztec_banner.png" />
+  <img height="210" src="./assets/Aztec_banner.png" />
 
   <h1>Aztec.nr</h1>
 

diff --git a/noir/README.md b/noir/README.md
@@ -15,6 +15,6 @@ To start the sync run [this action](https://github.com/AztecProtocol/aztec-packa
 
 ## Syncing from aztec-packages to Noir.
 
-When syncing from aztec-packages to Noir it's important to check that the latest release of `bb` uses the same ACIR serialization format as the current master commit. This is because Noir uses a released version of barretenberg rather than being developed in sync with it, it's then not possible to sync if there's been serialization changes since the last release.
+When syncing from aztec-packages to Noir it's important to check that the latest release of `bb` uses the same ACIR serialization format as the current master commit. This is because Noir uses a released version of barretenberg rather than being developed in sync with it, it's then not possible to sync if there's been serialization changes since the latest release.
 
 To start the sync run [this action](https://github.com/AztecProtocol/aztec-packages/actions/workflows/mirror-noir-subrepo.yml) manually (click the "Run Workflow" button in the top right). aztec-bot will then open a new PR in the `noir-lang/noir` repository which does the initial sync, this will have merge conflicts with master which will need to be resolved.
diff --git a/spartan/README.md b/spartan/README.md
@@ -84,9 +84,9 @@ kubectl config use-context <context-name>
 
 ### Connecting to Spartan using k8Lens
 
-A popular GUI than can be used to connect to the Spartan cluster is the free version of k8Lens. ([Download Link](https://k8slens.dev/))
+A popular GUI that can be used to connect to the Spartan cluster is the free version of k8Lens. ([Download Link](https://k8slens.dev/))
 
-As long as all CLI tools have been configured, k8Lens will automatically read your local `kubeconfig` file to provide cluster access. The Spartan cluster can then be located by navigating the k8Lens "catelog" as shown below.
+As long as all CLI tools have been configured, k8Lens will automatically read your local `kubeconfig` file to provide cluster access. The Spartan cluster can then be located by navigating the k8Lens "catalog" as shown below.
 
 ![k8Lens Cluster Connection](./img/k8lens_1.png)
 
@@ -106,4 +106,4 @@ Outside of Aztec network deployments, the Spartan cluster has a few additional s
 
 ### Prometheus and Grafana
 
-_(coming soon...)_
+_(coming soon...)_
diff --git a/yarn-project/kv-store/README.md b/yarn-project/kv-store/README.md
@@ -1,6 +1,6 @@
 # KV Store
 
-The Aztec KV store is an implementation of a durable key-value database with a pluggable backend. THe only supported backend right now is LMDB by using the [`lmdb-js` package](https://github.com/kriszyp/lmdb-js).
+The Aztec KV store is an implementation of a durable key-value database with a pluggable backend. The only supported backend right now is LMDB by using the [`lmdb-js` package](https://github.com/kriszyp/lmdb-js).
 
 This package exports a number of primitive data structures that can be used to build domain-specific databases in each node component (e.g. a PXE database or an Archiver database). The data structures supported: