feat(docs): nits

README.md

@@ -1,6 +1,6 @@
 # Aztec Monorepo
 
-All the packages that make up [Aztec](https://docs.aztec.network). 
+All the packages that make up [Aztec](https://docs.aztec.network).
 
 - [**`l1-contracts`**](/l1-contracts): Solidity code for the Ethereum contracts that process rollups
 - [**`yarn-project`**](/yarn-project): Typescript code for client and backend
@@ -17,7 +17,7 @@ All the packages that make up [Aztec](https://docs.aztec.network).
 
 ## Issues Board
 
-All issues being worked on are tracked on the [Aztec Github Project](https://github.com/orgs/AztecProtocol/projects/22). For a higher-level roadmap, check the [milestones overview](https://docs.aztec.network/aztec/roadmap) section of our docs.
+All issues being worked on are tracked on the [Aztec Github Project](https://github.com/orgs/AztecProtocol/projects/22). For a higher-level roadmap, check the [milestones overview](https://aztec.network/roadmap) section of our website.
 
 ## Development Setup
 

docs/docs/aztec/concepts/accounts/keys.md

@@ -6,6 +6,8 @@ tags: [accounts, keys]
 The goal of this section is to give app developer a good idea what keys there are used in the system.
 For a detailed description head over to the [protocol specification](../../../protocol-specs/addresses-and-keys/index.md).
 
+In short, there is a **nullifier key** (to spend your notes), an **incoming viewing key** (to view any notes or logs that were sent to you), an **outgoing viewing key** (to view any logs or notes you sent to another entity), a **tagging key** (to quickly find notes relevant to you) and oftentimes a signing key. A signing key is not strictly required by the protocol, but are often used with specific account contracts for authorization purposes.
+
 Each account in Aztec is backed by 4 key pairs:
 
 - A **nullifier key pair** used for note nullifier computation, comprising the master nullifier secret key (`nsk_m`) and master nullifier public key (`Npk_m`).

docs/docs/aztec/concepts/storage/partial_notes.md

@@ -104,7 +104,7 @@ $$
 
 We also need to create a point for the owner of the FPC (whom we call Bob) to receive the transaction fee, which will also need randomness.
 
-So in the contract we compute $\text{rand}_b := h(\text{rand}_a, \text{msg_sender})$.
+So in the contract we compute $\text{rand}_b := h(\text{rand}_a, \text{msg sender})$.
 
 :::warning
 We need to use different randomness for Bob's note here to avoid potential privacy leak (see [description](https://github.com/AztecProtocol/aztec-packages/blob/#include_aztec_version/noir-projects/noir-contracts/contracts/token_contract/src/main.nr#L491) of `setup_refund` function)
@@ -116,7 +116,7 @@ $$
 
 Here, the $P'$s "partially encode" the notes that we are _going to create_ for Alice and Bob. So we can use points as "Partial Notes".
 
-We pass these points and the funded amount to public, and at the end of public execution, we compute tx fee point $P_{fee} := (\text{transaction fee}) * G_{amount}$ and refund point $P_{refund} := (\text{funded_amount - transaction_fee}) * G_{amount}$
+We pass these points and the funded amount to public, and at the end of public execution, we compute tx fee point $P_{fee} := (\text{transaction fee}) * G_{amount}$ and refund point $P_{refund} := (\text{funded amount} - \text{transaction fee}) * G_{amount}$
 
 Then, we arrive at the point that corresponds to the complete note by
 

docs/docs/aztec/glossary/call_types.md

@@ -94,7 +94,7 @@ While Ethereum contracts are defined by bytecode that runs on the EVM, Aztec con
 
 ### Private Execution
 
-Contract functions marked with `#[aztec(private)]` can only be called privately, and as such 'run' in the user's device. Since they're circuits, their 'execution' is actually the generation of a zk-SNARK proof that'll later be sent to the sequencer for verification.
+Contract functions marked with `#[private]` can only be called privately, and as such 'run' in the user's device. Since they're circuits, their 'execution' is actually the generation of a zk-SNARK proof that'll later be sent to the sequencer for verification.
 
 #### Private Calls
 
@@ -112,7 +112,7 @@ Since the public call is made asynchronously, any return values or side effects
 
 #include_code enqueue_public /noir-projects/noir-contracts/contracts/lending_contract/src/main.nr rust
 
-It is also possible to create public functions that can _only_ be invoked by privately enqueueing a call from the same contract, which can very useful to update public state after private execution (e.g. update a token's supply after privately minting). This is achieved by annotating functions with `#[aztec(internal)]`.
+It is also possible to create public functions that can _only_ be invoked by privately enqueueing a call from the same contract, which can very useful to update public state after private execution (e.g. update a token's supply after privately minting). This is achieved by annotating functions with `#[internal]`.
 
 A common pattern is to enqueue public calls to check some validity condition on public state, e.g. that a deadline has not expired or that some public value is set.
 
@@ -148,7 +148,7 @@ For this reason it is encouraged to try to avoid public function calls and inste
 
 ### Public Execution
 
-Contract functions marked with `#[aztec(public)]` can only be called publicly, and are executed by the sequencer. The computation model is very similar to the EVM: all state, parameters, etc. are known to the entire network, and no data is private. Static execution like the EVM's `STATICCALL` is possible too, with similar semantics (state can be accessed but not modified, etc.).
+Contract functions marked with `#[public]` can only be called publicly, and are executed by the sequencer. The computation model is very similar to the EVM: all state, parameters, etc. are known to the entire network, and no data is private. Static execution like the EVM's `STATICCALL` is possible too, with similar semantics (state can be accessed but not modified, etc.).
 
 Since private calls are always run in a user's device, it is not possible to perform any private execution from a public context. A reasonably good mental model for public execution is that of an EVM in which some work has already been done privately, and all that is know about it is its correctness and side-effects (new notes and nullifiers, enqueued public calls, etc.). A reverted public execution will also revert the private side-effects.
 

docs/docs/aztec/smart_contracts/functions/inner_workings.md

@@ -8,11 +8,11 @@ Below, we go more into depth of what is happening under the hood when you create
 
 If you are looking for a reference of function macros, go [here](../../../reference/developer_references/smart_contract_reference/macros.md).
 
-## Private functions #[aztec(private)]
+## Private functions #[private]
 
-A private function operates on private information, and is executed by the user on their device. Annotate the function with the `#[aztec(private)]` attribute to tell the compiler it's a private function. This will make the [private context](./context.md#the-private-context) available within the function's execution scope. The compiler will create a circuit to define this function.
+A private function operates on private information, and is executed by the user on their device. Annotate the function with the `#[private]` attribute to tell the compiler it's a private function. This will make the [private context](./context.md#the-private-context) available within the function's execution scope. The compiler will create a circuit to define this function.
 
-`#aztec(private)` is just syntactic sugar. At compile time, the Aztec.nr framework inserts code that allows the function to interact with the [kernel](../../../aztec/concepts/circuits/kernels/private_kernel.md).
+`#[private]` is just syntactic sugar. At compile time, the Aztec.nr framework inserts code that allows the function to interact with the [kernel](../../../aztec/concepts/circuits/kernels/private_kernel.md).
 
 To help illustrate how this interacts with the internals of Aztec and its kernel circuits, we can take an example private function, and explore what it looks like after Aztec.nr's macro expansion.
 
@@ -107,15 +107,15 @@ Beyond using them inside your other functions, they are convenient for providing
 Note, that unconstrained functions can have access to both public and private data when executed on the user's device. This is possible since it is not actually part of the circuits that are executed in contract execution.
 :::
 
-## `Public` Functions #[aztec(public)]
+## `Public` Functions #[public]
 
 A public function is executed by the sequencer and has access to a state model that is very similar to that of the EVM and Ethereum. Even though they work in an EVM-like model for public transactions, they are able to write data into private storage that can be consumed later by a private function.
 
 :::note
 All data inserted into private storage from a public function will be publicly viewable (not private).
 :::
 
-To create a public function you can annotate it with the `#[aztec(public)]` attribute. This will make the public context available within the function's execution scope.
+To create a public function you can annotate it with the `#[public]` attribute. This will make the public context available within the function's execution scope.
 
 #include_code set_minter /noir-projects/noir-contracts/contracts/token_contract/src/main.nr rust
 
@@ -139,17 +139,17 @@ let storage = Storage::init(&mut context);
 - Visibility Control: The function is marked as pub, making it accessible from outside the contract.
 - Unconstrained Execution: Public functions are marked as unconstrained, meaning they don't generate proofs and are executed directly by the sequencer.
 
-## Constrained `view` Functions #[aztec(view)]
+## Constrained `view` Functions #[view]
 
-The `#[aztec(view)]` attribute is used to define constrained view functions in Aztec contracts. These functions are similar to view functions in Solidity, in that they are read-only and do not modify the contract's state. They are similar to the [`unconstrained`](#unconstrained-functions-aztecunconstrained) keyword but are executed in a constrained environment. It is not possible to update state within an `#[aztec(view)]` function.
+The `#[view]` attribute is used to define constrained view functions in Aztec contracts. These functions are similar to view functions in Solidity, in that they are read-only and do not modify the contract's state. They are similar to the [`unconstrained`](#unconstrained-functions-aztecunconstrained) keyword but are executed in a constrained environment. It is not possible to update state within an `#[view]` function.
 
 This means the results of these functions are verifiable and can be trusted, as they are part of the proof generation and verification process. This is unlike unconstrained functions, where results are provided by the PXE and are not verified.
 
-This makes `#[aztec(view)]` functions suitable for critical read-only operations where the integrity of the result is crucial. Unconstrained functions, on the other hand, are executed entirely client-side without generating any proofs. It is better to use `#[aztec(view)]` if the result of the function will be used in another function that will affect state, and they can be used for cross-contract calls.
+This makes `#[view]` functions suitable for critical read-only operations where the integrity of the result is crucial. Unconstrained functions, on the other hand, are executed entirely client-side without generating any proofs. It is better to use `#[view]` if the result of the function will be used in another function that will affect state, and they can be used for cross-contract calls.
 
-`#[aztec(view)]` functions can be combined with other Aztec attributes like `#[aztec(private)]` or `#[aztec(public)]`.
+`#[view]` functions can be combined with other Aztec attributes like `#[private]` or `#[public]`.
 
-## `Initializer` Functions #[aztec(initializer)]
+## `Initializer` Functions #[initializer]
 
 This is used to designate functions as initializers (or constructors) for an Aztec contract. These functions are responsible for setting up the initial state of the contract when it is first deployed. The macro does two important things:
 
@@ -159,30 +159,30 @@ This is used to designate functions as initializers (or constructors) for an Azt
 Key things to keep in mind:
 
 - A contract can have multiple initializer functions defined, but only one initializer function should be called for the lifetime of a contract instance
-- Other functions in the contract will have an initialization check inserted, ie they cannot be called until the contract is initialized, unless they are marked with [`#[aztec(noinitcheck)]`](#aztecnoinitcheck)
+- Other functions in the contract will have an initialization check inserted, ie they cannot be called until the contract is initialized, unless they are marked with [`#[noinitcheck]`](#aztecnoinitcheck)
 
-## #[aztec(noinitcheck)]
+## #[noinitcheck]
 
-In normal circumstances, all functions in an Aztec contract (except initializers) have an initialization check inserted at the beginning of the function body. This check ensures that the contract has been initialized before any other function can be called. However, there may be scenarios where you want a function to be callable regardless of the contract's initialization state. This is when you would use `#[aztec(noinitcheck)]`.
+In normal circumstances, all functions in an Aztec contract (except initializers) have an initialization check inserted at the beginning of the function body. This check ensures that the contract has been initialized before any other function can be called. However, there may be scenarios where you want a function to be callable regardless of the contract's initialization state. This is when you would use `#[noinitcheck]`.
 
-When a function is annotated with `#[aztec(noinitcheck)]`:
+When a function is annotated with `#[noinitcheck]`:
 
 - The Aztec macro processor skips the [insertion of the initialization check](#initializer-functions-aztecinitializer) for this specific function
 - The function can be called at any time, even if the contract hasn't been initialized yet
 
-## `Internal` functions #[aztec(internal)]
+## `Internal` functions #[internal]
 
 This macro inserts a check at the beginning of the function to ensure that the caller is the contract itself. This is done by adding the following assertion:
 
 ```rust
 assert(context.msg_sender() == context.this_address(), "Function can only be called internally");
 ```
 
-## Custom notes #[aztec(note)]
+## Custom notes #[note]
 
-The `#[aztec(note)]` attribute is used to define custom note types in Aztec contracts. Learn more about notes [here](../../concepts/storage/index.md).
+The `#[note]` attribute is used to define custom note types in Aztec contracts. Learn more about notes [here](../../concepts/storage/index.md).
 
-When a struct is annotated with `#[aztec(note)]`, the Aztec macro applies a series of transformations and generates implementations to turn it into a note that can be used in contracts to store private data.
+When a struct is annotated with `#[note]`, the Aztec macro applies a series of transformations and generates implementations to turn it into a note that can be used in contracts to store private data.
 
 1. **NoteInterface Implementation**: The macro automatically implements most methods of the `NoteInterface` trait for the annotated struct. This includes:
 
@@ -208,7 +208,7 @@ When a struct is annotated with `#[aztec(note)]`, the Aztec macro applies a seri
 Here is how you could define a custom note:
 
 ```rust
-#[aztec(note)]
+#[note]
 struct CustomNote {
     data: Field,
     owner: Address,
@@ -293,11 +293,11 @@ Key things to keep in mind:
 - Developers can override any of the auto-generated methods by specifying a note interface
 - The note's fields are automatically serialized and deserialized in the order they are defined in the struct
 
-## Storage struct #[aztec(storage)]
+## Storage struct #[storage]
 
-The `#[aztec(storage)]` attribute is used to define the storage structure for an Aztec contract.
+The `#[storage]` attribute is used to define the storage structure for an Aztec contract.
 
-When a struct is annotated with `#[aztec(storage)]`, the macro does this under the hood:
+When a struct is annotated with `#[storage]`, the macro does this under the hood:
 
 1. **Context Injection**: injects a `Context` generic parameter into the storage struct and all its fields. This allows the storage to interact with the Aztec context, eg when using `context.msg_sender()`
 
@@ -310,7 +310,7 @@ When a struct is annotated with `#[aztec(storage)]`, the macro does this under t
 ### Before expansion
 
 ```rust
-#[aztec(storage)]
+#[storage]
 struct Storage {
     balance: PublicMutable<Field>,
     owner: PublicMutable<Address>,

docs/docs/guides/developer_guides/getting_started.md

@@ -10,9 +10,10 @@ The Sandbox is an Aztec network running fully on your machine, and interacting w
 
 ## Prerequisites
 
-You need two global dependencies iyour machine:
+You need two global dependencies on your machine:
 
-- Node.js >= v18 (recommend installing with [nvm](https://github.com/nvm-sh/nvm))
+- Node.js {'>='} v18.xx.x and {'<='} v20.17.x (lts/iron) (later versions, eg v22.9, gives an error around 'assert')
+  - Recommend installing with [nvm](https://github.com/nvm-sh/nvm)
 - Docker (visit [this page of the Docker docs](https://docs.docker.com/get-docker/) on how to install it)
 
 ## Install and run the sandbox

docs/docs/guides/developer_guides/smart_contracts/how_to_compile_contract.md

@@ -243,14 +243,14 @@ contract FPC {
     ...
 
 
-   #[aztec(private)]
+   #[private]
     fn fee_entrypoint_private(amount: Field, asset: AztecAddress, secret_hash: Field, nonce: Field) {
         assert(asset == storage.other_asset.read_private());
         Token::at(asset).unshield(context.msg_sender(), context.this_address(), amount, nonce).call(&mut context);
         FPC::at(context.this_address()).pay_fee_with_shielded_rebate(amount, asset, secret_hash).enqueue(&mut context);
     }
 
-    #[aztec(private)]
+    #[private]
     fn fee_entrypoint_public(amount: Field, asset: AztecAddress, nonce: Field) {
         FPC::at(context.this_address()).prepare_fee(context.msg_sender(), amount, asset, nonce).enqueue(&mut context);
         FPC::at(context.this_address()).pay_fee(context.msg_sender(), amount, asset).enqueue(&mut context);

docs/docs/guides/developer_guides/smart_contracts/writing_contracts/authwit.md

@@ -74,7 +74,7 @@ Note in particular that the request for a witness is done by the token contract,
 As part of `AuthWit` we are assuming that the `on_behalf_of` implements the private function:
 
 ```rust
-#[aztec(private)]
+#[private]
 fn verify_private_authwit(inner_hash: Field) -> Field;
 ```
 

docs/docs/guides/developer_guides/smart_contracts/writing_contracts/common_patterns/index.md

@@ -46,14 +46,14 @@ You can't read public storage in private domain. But nevertheless reading public
 1. You pass the data as a parameter to your private method and later assert in public that the data is correct. E.g.:
 
 ```rust
-#[aztec(storage)]
+#[storage]
 struct Storage {
    token: PublicMutable<Field>,
 }
 
 contract Bridge {
 
-    #[aztec(private)]
+    #[private]
     fn burn_token_private(
         token: AztecAddress, // pass token here since this is a private method but can't access public storage
         amount: Field,