path fixes

docs/docs/aztec/aztec/concepts/accounts/index.md

@@ -144,4 +144,4 @@ In order to be considered valid, an account must prove that it has locked enough
 
 However, there is one major consideration around public execution reverts. In the current design, if one of the public function executions enqueued in a transaction fails, then the entire transaction is reverted. But reverting the whole transaction would also revert the fee payment, and leave the sequencer with their hands empty after running the public execution. This means we will need to enshrine an initial verification and fee payment phase that is _not_ reverted if public execution fails.
 
-You can read the latest information about fees in the [protocol specs](../../../protocol-specs/gas-and-fees/index.md).
+You can read the latest information about fees in the [protocol specs](/protocol-specs/gas-and-fees/index.md).

docs/docs/aztec/aztec/concepts/smart_contracts/contract_creation.md

@@ -2,7 +2,7 @@
 title: Contract Deployment
 ---
 
-The latest information about contract deployment has moved to the protocol specification. You can find it [here](../../../protocol-specs/contract-deployment/index.md).
+The latest information about contract deployment has moved to the protocol specification. You can find it [here](/protocol-specs/contract-deployment/index.md).
 
 ## Further reading
 

docs/docs/aztec/aztec/concepts/wallets/index.md

@@ -4,7 +4,7 @@ title: Wallets
 
 In this page we will cover the main responsibilities of a wallet in the Aztec network.
 
-Refer to [_writing an account contract_](../contracts/writing_contracts/accounts/write_accounts_contract.md) for a tutorial on how to write a contract to back a user's account.
+Refer to [_writing an account contract_](/tutorials/tutorials/write_accounts_contract.md) for a tutorial on how to write a contract to back a user's account.
 
 Go to [\_wallet architecture](./architecture.md) for an overview of its architecture and a reference on the interface a wallet must implement.
 
@@ -18,7 +18,7 @@ In addition to these usual responsibilities, wallets in Aztec also need to track
 
 The first step for any wallet is to let the user set up their [accounts](/aztec/aztec/concepts/index.md). An account in Aztec is represented on-chain by its corresponding account contract that the user must deploy to begin interacting with the network. This account contract dictates how transactions are authenticated and executed.
 
-A wallet must support at least one specific [account contract implementation](../contracts/writing_contracts/accounts/write_accounts_contract.md), which means being able to deploy such a contract, as well as interacting with it when sending transactions. Code-wise, this requires [implementing the `AccountContract` interface](https://github.com/AztecProtocol/aztec-packages/blob/master/yarn-project/aztec.js/src/account_contract/index.ts).
+A wallet must support at least one specific [account contract implementation](/tutorials/tutorials/write_accounts_contract.md), which means being able to deploy such a contract, as well as interacting with it when sending transactions. Code-wise, this requires [implementing the `AccountContract` interface](https://github.com/AztecProtocol/aztec-packages/blob/master/yarn-project/aztec.js/src/account_contract/index.ts).
 
 Note that users must be able to receive funds in Aztec before deploying their account. A wallet should let a user generate a [deterministic complete address](/aztec/aztec/concepts/accounts/keys.md#addresses-partial-addresses-and-public-keys) without having to interact with the network, so they can share it with others to receive funds. This requires that the wallet pins a specific contract implementation, its initialization arguments, a deployment salt, and a privacy key. These values yield a deterministic address, so when the account contract is actually deployed, it is available at the precalculated address. Once the account contract is deployed, the user can start sending transactions using it as the transaction origin.
 

docs/docs/aztec/aztec/glossary/call_types.md

@@ -121,7 +121,7 @@ A common pattern is to enqueue public calls to check some validity condition on
 #include_code deadline /noir-projects/noir-contracts/contracts/crowdfunding_contract/src/main.nr rust
 
 :::warning
-Calling public functions privately leaks some privacy! The caller of the function and all arguments will be revelead, so exercise care when mixing the private and public domains. To learn about alternative ways to access public state privately, look into [Shared State](../../developers/contracts/references/storage/shared_state.md).
+Calling public functions privately leaks some privacy! The caller of the function and all arguments will be revelead, so exercise care when mixing the private and public domains. To learn about alternative ways to access public state privately, look into [Shared State](/reference/reference/smart_contract_reference/storage/shared_state.md).
 :::
 
 ### Public Execution

docs/docs/aztec/aztec/limitations.md

@@ -53,7 +53,7 @@ That's right, the Sandbox doesn't actually generate or verify any zk-SNARKs yet!
 
 The main goal of the Sandbox is to enable developers to experiment with building apps, and hopefully to provide feedback. We want the developer experience to be as fast as possible, much like how Ethereum developers use Ganache or Anvil to get super-fast block times, instead of the slow-but-realistic 12-second block times that they'll encounter in production. A fast Sandbox enables fast testing, which enables developers to iterate quickly.
 
-That's not to say a super-fast proving system isn't being worked on [as we speak](/aztec/aztec/what_is_aztec/roadmap/cryptography_roadmap.md).
+That's not to say a super-fast proving system isn't being worked on [as we speak](/aztec/aztec/roadmap/cryptography_roadmap.md).
 
 #### What are the consequences?
 
@@ -172,11 +172,11 @@ This will be patched in the near future, but unfortunately, app developers might
 
 ### New Privacy Standards are required
 
-There are many [patterns](/aztec/aztec/what_is_aztec/privacy_considerations.md) which can leak privacy, even on Aztec. Standards haven't been developed yet, to encourage best practices when designing private smart contracts.
+There are many [patterns](/reference/reference/privacy_considerations.md) which can leak privacy, even on Aztec. Standards haven't been developed yet, to encourage best practices when designing private smart contracts.
 
 #### What are the consequences?
 
-For example, until community standards are developed to reduce the uniqueness of ['Tx Fingerprints'](/aztec/aztec/what_is_aztec/privacy_considerations.md#function-fingerprints-and-tx-fingerprints) app developers might accidentally forfeit some function privacy.
+For example, until community standards are developed to reduce the uniqueness of ['Tx Fingerprints'](/reference/reference/privacy_considerations.md#function-fingerprints-and-tx-fingerprints) app developers might accidentally forfeit some function privacy.
 
 ## Circuit limitations
 

docs/docs/aztec/vision.mdx → docs/docs/aztec/index.mdx

@@ -3,7 +3,7 @@ title: Vision
 sidebar_position: 1
 ---
 
-import Disclaimer from "../../../../src/components/Disclaimers/_wip_disclaimer.mdx";
+import Disclaimer from "../../src/components/Disclaimers/_wip_disclaimer.mdx";
 
 ## The world's encrypted ledger
 

docs/docs/getting_started/getting_started/index.md

@@ -16,7 +16,7 @@ This creates a codespace with a prebuilt image containing one of the "Aztec Boxe
 
 The above method uses Aztec boxes to install the sandbox and clone the repo. You can use it too to get started on your own machine and use your own IDE.
 
-You can also [install the sandbox manually](../sandbox/references/sandbox-reference.md).
+You can also [install the sandbox manually](/reference/reference/sandbox_reference).
 
 ### Prerequisites
 

docs/docs/guides/guides/local_env/creating_schnorr_accounts.md

@@ -61,4 +61,4 @@ Once this has completed, the L2 block is retrieved and pulled down to the PXE so
 
 ## Next Steps
 
-Check out our section on [Writing your own Account Contract](../contracts/writing_contracts/accounts/write_accounts_contract.md) leveraging our account abstraction
+Check out our section on [Writing your own Account Contract](/tutorials/tutorials/write_accounts_contract.md) leveraging our account abstraction

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

@@ -82,7 +82,7 @@ Both return the value `0xabf64ad4` (`IS_VALID` selector) for a successful authen
 
 As part of [Aztec.nr](https://aztec.nr), we are providing a library that can be used to implement authentication witness for your contracts.
 
-This library also provides a basis for account implementations such that these can more easily implement authentication witness. For more on the wallets, see [writing an account contract](../../writing_contracts/accounts/write_accounts_contract.md).
+This library also provides a basis for account implementations such that these can more easily implement authentication witness. For more on the wallets, see [writing an account contract](/tutorials/tutorials/write_accounts_contract.md).
 
 For our purposes here (not building a wallet), the most important part of the library is the `auth` utility which exposes a couple of helper methods for computing the action hash, retrieving witnesses, validating them and emitting the nullifier.
 

docs/docs/guides/guides/smart_contracts/writing_contracts/storage/notes.md

@@ -69,7 +69,7 @@ To update a value, its previous note hash(es) are nullified. The new note value
 
 ## Supplementary components
 Some optional background resources on notes can be found here:
-- [High level network architecture](/aztec/aztec/what_is_aztec/core_components.md#high-level-network-architecture), specifically the Private Execution Environment
+- [High level network architecture](/aztec/aztec/core_components.md#high-level-network-architecture), specifically the Private Execution Environment
 - [Transaction lifecycle (simple diagram)](/aztec/aztec/concepts/transactions.md#simple-example-of-the-private-transaction-lifecycle)
 - [Public and Private state](/aztec/aztec/concepts/state_model)
 

docs/docs/index.mdx

@@ -36,7 +36,7 @@ Aztec is:
 
 ### Learn 📚
 
-Start on the [Technical Overview page](/aztec/aztec/what_is_aztec/core_components) to read about how Aztec works.
+Start on the [Technical Overview page](/aztec/aztec/core_components) to read about how Aztec works.
 
 ### Build 🧑‍💻
 

docs/docs/reference/reference/sandbox_reference/sandbox-reference.md

@@ -10,7 +10,7 @@ For a quick start, follow the [guide](/getting_started/getting_started) to insta
 
 ## Manual Install
 
-You can manually install the sandbox via the underlying script used in the [Aztec Boxes](../../getting_started/quickstart.md#run-the-npx-script).
+You can manually install the sandbox via the underlying script used in the [Aztec Boxes](/getting_started/getting_started/index.md#run-the-npx-script).
 
 ### Prerequisites
 

docs/docs/reference/reference/smart_contract_reference/aztec-nr/aztec/context/private_context.md

@@ -8,6 +8,7 @@ When finished, one can call .finish() to convert back to the abi
 | inputs | PrivateContextInputs |
 | side_effect_counter | u32 |
 | min_revertible_side_effect_counter | u32 |
+| is_fee_payer | bool |
 | args_hash | Field |
 | return_hash | Field |
 | max_block_number | MaxBlockNumber |
@@ -91,6 +92,17 @@ PrivateContext::finish(self);
 | --- | --- |
 | self |  |
 
+### set_as_fee_payer
+
+```rust
+PrivateContext::set_as_fee_payer(&mut self);
+```
+
+#### Parameters
+| Name | Type |
+| --- | --- |
+| &mut self |  |
+
 ### end_setup
 
 ```rust
@@ -208,7 +220,7 @@ PrivateContext::emit_contract_class_unencrypted_log(&mut self, log);
 ### emit_encrypted_log
 
 ```rust
-PrivateContext::emit_encrypted_log(&mut self, contract_address, storage_slot, note_type_id, encryption_pub_key, preimage);
+PrivateContext::emit_encrypted_log(&mut self, contract_address, storage_slot, note_type_id, ivpk_m, preimage);
 ```
 
 #### Parameters
@@ -218,7 +230,7 @@ PrivateContext::emit_encrypted_log(&mut self, contract_address, storage_slot, no
 | contract_address | AztecAddress |
 | storage_slot | Field |
 | note_type_id | Field |
-| encryption_pub_key | GrumpkinPoint |
+| ivpk_m | GrumpkinPoint |
 | preimage | [Field; N] |
 
 ### call_private_function

docs/docs/reference/reference/smart_contract_reference/aztec-nr/aztec/note/utils.md

@@ -80,6 +80,17 @@ compute_note_hash_for_insertion(note);
 | --- | --- |
 | note | Note |
 
+### compute_note_hash_for_read_request
+
+```rust
+compute_note_hash_for_read_request(note);
+```
+
+#### Parameters
+| Name | Type |
+| --- | --- |
+| note | Note |
+
 ### compute_note_hash_for_consumption
 
 ```rust

docs/docs/reference/reference/smart_contract_reference/aztec-nr/aztec/oracle/logs.md

@@ -19,7 +19,7 @@ emit_encrypted_log_oracle(_contract_address, _storage_slot, _note_type_id, _encr
 ### emit_encrypted_log
 
 ```rust
-emit_encrypted_log(contract_address, storage_slot, note_type_id, encryption_pub_key, preimage, counter);
+emit_encrypted_log(contract_address, storage_slot, note_type_id, ivpk_m, preimage, counter);
 ```
 
 #### Parameters
@@ -28,7 +28,7 @@ emit_encrypted_log(contract_address, storage_slot, note_type_id, encryption_pub_
 | contract_address | AztecAddress |
 | storage_slot | Field |
 | note_type_id | Field |
-| encryption_pub_key | GrumpkinPoint |
+| ivpk_m | GrumpkinPoint |
 | preimage | [Field; N] |
 | counter | u32 |
 

docs/docs/tutorials/tutorials/simple_dapp/testing.md

@@ -67,4 +67,4 @@ yarn node --experimental-vm-modules $(yarn bin jest) --testRegex '.*\.test\.mjs$
 
 ## Next steps
 
-Now that you have finished the tutorial, you can learn more about [writing contracts with Noir](/aztec/aztec/concepts/smart_contracts/index.md) or read about the [fundamental concepts behind Aztec Network](/aztec/aztec/what_is_aztec/core_components).
+Now that you have finished the tutorial, you can learn more about [writing contracts with Noir](/aztec/aztec/concepts/smart_contracts/index.md) or read about the [fundamental concepts behind Aztec Network](/aztec/aztec/core_components).

docs/docs/tutorials/tutorials/write_accounts_contract.md

@@ -15,7 +15,7 @@ You will learn:
 
 Writing your own account contract allows you to define the rules by which user transactions are authorized and paid for, as well as how user keys are managed (including key rotation and recovery). In other words, writing an account contract lets you make the most out of [account abstraction](/aztec/aztec/concepts/index.md#what-is-account-abstraction) in the Aztec network.
 
-It is highly recommended that you understand how an [account](/aztec/aztec/concepts/index.md) is defined in Aztec, as well as the differences between privacy and authentication [keys](/aztec/aztec/concepts/accounts/keys.md). You will also need to know how to write a [contract in Noir](../layout.md), as well as some basic [Typescript](https://www.typescriptlang.org/).
+It is highly recommended that you understand how an [account](/aztec/aztec/concepts/index.md) is defined in Aztec, as well as the differences between privacy and authentication [keys](/aztec/aztec/concepts/accounts/keys.md). You will also need to know how to write a contract in Noir, as well as some basic [Typescript](https://www.typescriptlang.org/).
 
 For this tutorial, we will write an account contract that uses Schnorr signatures for authenticating transaction requests.
 
@@ -29,7 +29,7 @@ Let's start with the account contract itself in Aztec.nr. Create a new Aztec.nr
 
 #include_code contract noir-projects/noir-contracts/contracts/schnorr_hardcoded_account_contract/src/main.nr rust
 
-The important part of this contract is the `entrypoint` function, which will be the first function executed in any transaction originated from this account. This function has two main responsibilities: authenticating the transaction and executing calls. It receives a `payload` with the list of function calls to execute, and requests a corresponding [authentication witness](../../../../learn/concepts/accounts/authwit.md) from an oracle to validate it. Authentication witnesses are used for authorizing actions for an account, whether it is just checking a signature, like in this case, or granting authorization for another account to act on an accounts behalf (e.g. token approvals). You will find this logic implemented in the `AccountActions` module, which use the `AppPayload` and `FeePayload` structs:
+The important part of this contract is the `entrypoint` function, which will be the first function executed in any transaction originated from this account. This function has two main responsibilities: authenticating the transaction and executing calls. It receives a `payload` with the list of function calls to execute, and requests a corresponding [authentication witness](/aztec/aztec/concepts/accounts/authwit.md) from an oracle to validate it. Authentication witnesses are used for authorizing actions for an account, whether it is just checking a signature, like in this case, or granting authorization for another account to act on an accounts behalf (e.g. token approvals). You will find this logic implemented in the `AccountActions` module, which use the `AppPayload` and `FeePayload` structs:
 
 #include_code entrypoint noir-projects/aztec-nr/authwit/src/account.nr rust
 
@@ -49,7 +49,7 @@ For our account contract, we will take the hash of the action to authorize, requ
 
 ### Fee Abstraction
 
-The `FeePayload`, being distinct from the `AppPayload`, allows for fee abstraction, meaning the account paying the fee for the transaction can be different than the account that is initiating the transaction. This is also useful for maintaining privacy, as fee payments on the network must be public. For example, Alice could pay a relayer transaction fees in private, and the relayer could pay the transaction fee in public. This also allows for accounts without a fee paying asset to use a non-fee paying asset to pay for fees, provided they can find a relayer willing to accept a non-fee paying asset as payment (or do it for free). You can read more about that works in the protocol specification on fees [here](../../../../protocol-specs/gas-and-fees/tx-setup-and-teardown.md).
+The `FeePayload`, being distinct from the `AppPayload`, allows for fee abstraction, meaning the account paying the fee for the transaction can be different than the account that is initiating the transaction. This is also useful for maintaining privacy, as fee payments on the network must be public. For example, Alice could pay a relayer transaction fees in private, and the relayer could pay the transaction fee in public. This also allows for accounts without a fee paying asset to use a non-fee paying asset to pay for fees, provided they can find a relayer willing to accept a non-fee paying asset as payment (or do it for free). You can read more about that works in the protocol specification on fees [here](/protocol-specs/gas-and-fees/tx-setup-and-teardown.md).
 
 ### Nonce Abstraction