diff --git a/.github/workflows/release-please.yml b/.github/workflows/release-please.yml
index a08f2a0f8420..a6e5d035eb08 100644
--- a/.github/workflows/release-please.yml
+++ b/.github/workflows/release-please.yml
@@ -24,3 +24,31 @@ jobs:
token: ${{ secrets.AZTEC_BOT_GITHUB_TOKEN }}
command: manifest
default-branch: ${{ env.BRANCH_NAME }}
+
+ update-docs:
+ name: Update docs
+ needs: [release-please]
+ if: ${{ needs.release-please.outputs.release-pr }}
+ runs-on: ubuntu-latest
+
+ steps:
+ - name: Checkout release branch
+ uses: actions/checkout@v4
+ with:
+ ref: ${{ env.BRANCH_NAME }}
+ token: ${{ secrets.AZTEC_BOT_GITHUB_TOKEN }}
+
+ - name: Cut a new version
+ working-directory: ./docs
+ run: yarn version ${{ env.BRANCH_NAME }}
+
+ - name: Configure git
+ run: |
+ git config --global user.email "tech@aztecprotocol.com"
+ git config --global user.name "AztecBot"
+
+ - name: Commit new documentation version
+ run: |
+ git add .
+ git commit -m "chore(docs): cut new docs version for tag ${{ env.BRANCH_NAME }}"
+ git push
diff --git a/docs/.gitignore b/docs/.gitignore
index 08d08db7b026..10688cc967b1 100644
--- a/docs/.gitignore
+++ b/docs/.gitignore
@@ -27,3 +27,5 @@ yarn-error.log*
/docs/developers/reference/smart_contract_reference/aztec-nr
/docs/docs/protocol-specs/public-vm/gen
test-results
+
+versions.json
diff --git a/docs/bootstrap.sh b/docs/bootstrap.sh
index dd533ff45f5c..568615dcf331 100755
--- a/docs/bootstrap.sh
+++ b/docs/bootstrap.sh
@@ -8,8 +8,8 @@ cmd=${1:-}
hash=$(
cache_content_hash \
.rebuild_patterns \
- $(find docs -type f -name "*.md" -exec grep '^#include_code' {} \; | \
- awk '{ gsub("^/", "", $3); print "^" $3 }' | sort -u)
+ $(find docs versioned_docs -type f -name "*.md*" -exec grep '^#include_code' {} \; |
+ awk '{ print "^" $1 }' | sort -u)
)
if semver check $REF_NAME; then
@@ -27,13 +27,8 @@ function build_and_preview {
if cache_download docs-$hash.tar.gz; then
return
fi
- rm -rf \
- processed-docs \
- processed-docs-cache \
- docs/reference/developer_references/aztecjs \
- docs/reference/developer_references/smart_contract_reference/aztec-nr
npm_install_deps
- denoise "yarn docusaurus clear && yarn preprocess && yarn typedoc && scripts/move_processed.sh && yarn docusaurus build"
+ denoise "yarn build"
cache_upload docs-$hash.tar.gz build
if [ "${CI:-0}" -eq 1 ] && [ "$(arch)" == "amd64" ]; then
@@ -44,11 +39,6 @@ function build_and_preview {
# If we're an AMD64 CI run and have a PR, do a preview release.
function release_preview {
- if [ -z "${NETLIFY_SITE_ID:-}" ] || [ -z "${NETLIFY_AUTH_TOKEN:-}" ]; then
- echo "No netlify credentials available, skipping release preview."
- return
- fi
-
echo_header "docs release preview"
# Deploy and capture exit code and output.
diff --git a/docs/docs/aztec/concepts/accounts/keys.md b/docs/docs/aztec/concepts/accounts/keys.md
index f95405e21578..ff67c653cc90 100644
--- a/docs/docs/aztec/concepts/accounts/keys.md
+++ b/docs/docs/aztec/concepts/accounts/keys.md
@@ -28,7 +28,7 @@ To spend a note, the user computes a nullifier corresponding to this note. A nul
Address keys are used for account [address derivation](../accounts/index.md).
-
+
Address keys are a pair of keys `AddressPublicKey` and `address_sk` where `address_sk` is a scalar defined as `address_sk = pre_address + ivsk` and `AddressPublicKey` is an elliptic curve point defined as `AddressPublicKey = address_sk * G`. This is useful for encrypting notes for the recipient with only their address.
diff --git a/docs/docs/aztec/concepts/advanced/authwit.md b/docs/docs/aztec/concepts/advanced/authwit.md
index fae1972c8ebc..01f8997bacec 100644
--- a/docs/docs/aztec/concepts/advanced/authwit.md
+++ b/docs/docs/aztec/concepts/advanced/authwit.md
@@ -15,7 +15,7 @@ When building DeFi or other smart contracts, it is often desired to interact wit
In the EVM world, this is often accomplished by having the user `approve` the protocol to transfer funds from their account, and then calling a `deposit` function on it afterwards.
-
+
This flow makes it rather simple for the application developer to implement the deposit function, but does not come without its downsides.
@@ -30,7 +30,7 @@ This can lead to a series of issues though, eg:
To avoid this, many protocols implement the `permit` flow, which uses a meta-transaction to let the user sign the approval off-chain, and pass it as an input to the `deposit` function, that way the user only has to send one transaction to make the deposit.
-
+
This is a great improvement to infinite approvals, but still has its own sets of issues. For example, if the user is using a smart-contract wallet (such as Argent or Gnosis Safe), they will not be able to sign the permit message since the usual signature validation does not work well with contracts. [EIP-1271](https://eips.ethereum.org/EIPS/eip-1271) was proposed to give contracts a way to emulate this, but it is not widely adopted.
@@ -90,7 +90,7 @@ This can be read as "defi is allowed to call token transfer function with the ar
With this out of the way, let's look at how this would work in the graph below. The exact contents of the witness will differ between implementations as mentioned before, but for the sake of simplicity you can think of it as a signature, which the account contract can then use to validate if it really should allow the action.
-
+
:::info Static call for AuthWit checks
The call to the account contract for checking authentication should be a static call, meaning that it cannot change state or make calls that change state. If this call is not static, it could be used to re-enter the flow and change the state of the contract.
@@ -104,7 +104,7 @@ The above flow could be re-entered at token transfer. It is mainly for show to i
As noted earlier, we could use the ERC20 standard for public. But this seems like a waste when we have the ability to try righting some wrongs. Instead, we can expand our AuthWit scheme to also work in public. This is actually quite simple, instead of asking an oracle (which we can't do as easily because not private execution) we can just store the AuthWit in a shared registry, and look it up when we need it. While this needs the storage to be updated ahead of time (can be same tx), we can quite easily do so by batching the AuthWit updates with the interaction - a benefit of Account Contracts. A shared registry is used such that execution from the sequencers point of view will be more straight forward and predictable. Furthermore, since we have the authorization data directly in public state, if they are both set and unset (authorized and then used) in the same transaction, there will be no state effect after the transaction for the authorization which saves gas ⛽.
-
+
### Replays
diff --git a/docs/docs/aztec/concepts/advanced/storage/indexed_merkle_tree.mdx b/docs/docs/aztec/concepts/advanced/storage/indexed_merkle_tree.mdx
index 22e7ea7603bd..2452782e609c 100644
--- a/docs/docs/aztec/concepts/advanced/storage/indexed_merkle_tree.mdx
+++ b/docs/docs/aztec/concepts/advanced/storage/indexed_merkle_tree.mdx
@@ -36,13 +36,17 @@ Currently the only feasible way to get privacy in public blockchains is via a UT
A classic merkle tree:
-
+
To destroy state, the concept of a "nullifier" tree is introduced. Typically represented as a sparse Merkle Tree, the structure is utilized to store notes deterministically linked to values in the append-only tree of encrypted notes.
A sparse merkle tree (not every leaf stores a value):
-
+
In order to spend / modify a note in the private state tree, one must create a nullifier for it, and prove that the nullifier does not already exist in the nullifier tree. As nullifier trees are modeled as sparse merkle trees, non membership checks are (conceptually) trivial.
@@ -132,23 +136,33 @@ A visual aid for insertion is presented below:
1. Initial state
-
+
2. Add a new value $v=30$
-
+
3. Add a new value $v=10$
-
+
4. Add a new value $v=20$
-
+
5. Add a new value $v=50$
-
+
By studying the transitions between each diagram you can see how the pointers are updated between each insertion.
@@ -193,31 +207,45 @@ In the following example we insert a subtree of size 4 into our tree at step 4.
1. Prepare to insert subtree $[35,50,60,15]$
-
+
2. Update low nullifier for new nullifier $35$.
-
+
3. Update low nullifier for new nullifier $50$. (Notice how the low nullifier exists within our pending insertion subtree, this becomes important later).
-
+
4. Update low nullifier for new nullifier $60$.
-
+
5. Update low nullifier for new nullifier $15$.
-
+
6. Update pointers for new nullifier $15$.
-
+
7. Insert subtree.
-
+
### Performance gains from subtree insertion
diff --git a/docs/docs/aztec/concepts/communication/cross_chain_calls.md b/docs/docs/aztec/concepts/communication/cross_chain_calls.md
index 439f267ce557..b252e6b8c6da 100644
--- a/docs/docs/aztec/concepts/communication/cross_chain_calls.md
+++ b/docs/docs/aztec/concepts/communication/cross_chain_calls.md
@@ -64,7 +64,7 @@ A "portal" refers to the part of an application residing on L1, which is associa
In a logical sense, a Message Box functions as a one-way message passing mechanism with two ends, one residing on each side of the divide, i.e., one component on L1 and another on L2. Essentially, these boxes are utilized to transmit messages between L1 and L2 via the rollup contract. The boxes can be envisaged as multi-sets that enable the same message to be inserted numerous times, a feature that is necessary to accommodate scenarios where, for instance, "deposit 10 eth to A" is required multiple times. The diagram below provides a detailed illustration of how one can perceive a message box in a logical context.
-
+
- Here, a `sender` will insert a message into the `pending` set, the specific constraints of the actions depend on the implementation domain, but for now, say that anyone can insert into the pending set.
- At some point, a rollup will be executed, in this step messages are "moved" from pending on Domain A, to ready on Domain B. Note that consuming the message is "pulling & deleting" (or nullifying). The action is atomic, so a message that is consumed from the pending set MUST be added to the ready set, or the state transition should fail. A further constraint on moving messages along the way, is that only messages where the `sender` and `recipient` pair exists in a leaf in the contracts tree are allowed!
@@ -78,7 +78,7 @@ By instead pulling, we can have the "message" be something that is derived from
To support messages in both directions we require two of these message boxes (one in each direction). However, due to the limitations of each domain, the message box for sending messages into the rollup and sending messages out are not fully symmetrical. In reality, the setup looks closer to the following:
-
+
:::info
The L2 -> L1 pending messages set only exist logically, as it is practically unnecessary. For anything to happen to the L2 state (e.g., update the pending messages), the state will be updated on L1, meaning that we could just as well insert the messages directly into the ready set.
@@ -149,4 +149,4 @@ To make it possible to hide when a specific message is consumed, the `L1ToL2Msg`
The following diagram shows the overall architecture, combining the earlier sections.
-
+
diff --git a/docs/docs/aztec/concepts/storage/notes.md b/docs/docs/aztec/concepts/storage/notes.md
index e5209ad4cefc..0bae4ddadfff 100644
--- a/docs/docs/aztec/concepts/storage/notes.md
+++ b/docs/docs/aztec/concepts/storage/notes.md
@@ -16,7 +16,7 @@ Rather than storing entire notes in a data tree, note commitments (hashes of the
When a note is updated, Aztec nullifies the original commitment in the note hash tree by creating a nullifier from the note data, and may create a new note with the updated information, encrypted to a new owner if necessary. This helps to decouple actions of creating, updating and deleting private state.
-
+
Notes are comparable to cash, with some slight differences. When you want to spend \$3.50 USD in real life, you give your \$5 note to a cashier who will keep \$3.50 and give you separate notes that add up to \$1.50. Using private notes on Aztec, when you want to spend a \$5 note, you nullify it and create a \$1.5 note with yourself as the owner and a \$3.5 note with the recipient as the owner. Only you and the recipient are aware of \$3.5 transaction, they are not aware that you "split" the \$5 note.
diff --git a/docs/docs/aztec/concepts/transactions.md b/docs/docs/aztec/concepts/transactions.md
index 07ba01b4b410..be7d8feb0a1a 100644
--- a/docs/docs/aztec/concepts/transactions.md
+++ b/docs/docs/aztec/concepts/transactions.md
@@ -21,7 +21,7 @@ The introduction of the Private eXecution Environment (PXE) provides a safe envi
The accompanying diagram illustrates the flow of interactions between a user, their wallet, the PXE, the node operators (sequencers / provers), and the L1 chain.
-
+
1. **The user initiates a transaction** – In this example, the user decides to privately send 10 DAI to gudcause.eth. After inputting the amount and the receiving address, the user clicks the confirmation button on their wallet.
@@ -45,7 +45,7 @@ _The sequencer has passed the transaction information – proofs of correct exec
Transactions on Aztec start with a call from Aztec.js, which creates a request containing transaction details. This request moves to the Private Execution Environment (PXE) which simulates and processes it. Then the PXE interacts with the Aztec Node which uses the sequencer to ensure that all the transaction details are enqueued properly. The sequencer then submits the block to the rollup contract, and the transaction is successfully mined.
-
+
See [this diagram](https://raw.githubusercontent.com/AztecProtocol/aztec-packages/2fa143e4d88b3089ebbe2a9e53645edf66157dc8/docs/static/img/sandbox_sending_a_tx.svg) for a more detailed overview of the transaction execution process. It highlights 3 different types of transaction execution: contract deployments, private transactions and public transactions.
diff --git a/docs/docs/aztec/index.md b/docs/docs/aztec/index.md
index bb62dd08eec4..d3292e7ac3ee 100644
--- a/docs/docs/aztec/index.md
+++ b/docs/docs/aztec/index.md
@@ -14,7 +14,7 @@ Aztec is a privacy-first Layer 2 on Ethereum. It supports smart contracts with b
## High level view
-
+
1. A user interacts with Aztec through Aztec.js (like web3js or ethersjs)
2. Private functions are executed in the PXE, which is client-side
@@ -46,7 +46,7 @@ Private state works with UTXOs, which are chunks of data that we call notes. To
Public state works similarly to other chains like Ethereum, behaving like a public ledger. Public data is stored in a public data tree.
-
+
Aztec [smart contract](./smart_contracts_overview.md) developers should keep in mind that different data types are used when manipulating private or public state. Working with private state is creating commitments and nullifiers to state, whereas working with public state is directly updating state.
diff --git a/docs/docs/aztec/smart_contracts/functions/context.md b/docs/docs/aztec/smart_contracts/functions/context.md
index fec4eca1aed5..651464ebdddb 100644
--- a/docs/docs/aztec/smart_contracts/functions/context.md
+++ b/docs/docs/aztec/smart_contracts/functions/context.md
@@ -55,7 +55,7 @@ The call context contains information about the current call being made:
> The graphic below illustrates how the message sender changes throughout the kernel circuit iterations.
-
+
2. Storage contract address
diff --git a/docs/docs/aztec/smart_contracts/functions/public_private_calls.md b/docs/docs/aztec/smart_contracts/functions/public_private_calls.md
index bf8727943536..0e4c5667b5c4 100644
--- a/docs/docs/aztec/smart_contracts/functions/public_private_calls.md
+++ b/docs/docs/aztec/smart_contracts/functions/public_private_calls.md
@@ -39,7 +39,7 @@ In this model, instead of informing the builder of our intentions, we construct
On the left-hand side of the diagram below, we see the fully public world where storage is shared, while on the right-hand side, we see the private world where all reads are historical.
-
+
Given that Aztec will comprise both private and public functions, it is imperative that we determine the optimal ordering for these functions. From a logical standpoint, it is reasonable to execute the private functions first as they are executed on a state $S_i$, where $i \le n$, with $S_n$ representing the current state where the public functions always operate on the current state $S_n$. Prioritizing the private functions would also afford us the added convenience of enabling them to invoke the public functions, which is particularly advantageous when implementing a peer-to-pool architecture such as that employed by Uniswap.
@@ -47,11 +47,11 @@ Transactions that involve both private and public functions will follow a specif
It is important to note that the execution of private functions is prioritized before executing any public functions. This means that private functions cannot "wait" on the results of any of their calls to public functions. Stated differently, any calls made across domains are unilateral in nature, akin to shouting into the void with the hope that something will occur at a later time. The figure below illustrates the order of function calls on the left-hand side, while the right-hand side shows how the functions will be executed. Notably, the second private function call is independent of the output of the public function and merely occurs after its execution.
-
+
Multiple of these transactions are then ordered into a L2 block by the sequencer, who will also be executing the public functions (as they require the current head). Example seen below.
-
+
:::info
Be mindful that if part of a transaction is reverting, say the public part of a call, it will revert the entire transaction. Similarly to Ethereum, it might be possible for the block builder to create a block such that your valid transaction reverts because of altered state, e.g., trade incurring too much slippage or the like.
@@ -65,7 +65,7 @@ To summarize:
A more comprehensive overview of the interplay between private and public functions and their ability to manipulate data is presented below. It is worth noting that all data reads performed by private functions are historical in nature, and that private functions are not capable of modifying public storage. Conversely, public functions have the capacity to manipulate private storage (e.g., inserting new note hashes, potentially as part of transferring funds from the public domain to the private domain).
-
+
:::info
You can think of private and public functions as being executed by two actors that can only communicate to each other by mailbox.
diff --git a/docs/docs/aztec_connect_sunset.mdx b/docs/docs/aztec_connect_sunset.mdx
index 70b2311d723d..0861f5fcc721 100644
--- a/docs/docs/aztec_connect_sunset.mdx
+++ b/docs/docs/aztec_connect_sunset.mdx
@@ -41,16 +41,16 @@ Follow the links for more information about each package.
1. Navigate to your zk.money homepage and click “Wallet”.
2. Scroll down to “Tokens” and “Earn Positions”.
3. Click “Earn Positions”.
-4. Click “Claim & Exit” on the position you wish to exit.
+4. Click “Claim & Exit” on the position you wish to exit.
5. All exit transactions are free in “Batched Mode” proceed to step 6 to get a free transaction.
-6. Click “Max” to exit the full amount, and then select a speed for your transaction.
+6. Click “Max” to exit the full amount, and then select a speed for your transaction.
7. Once you have done so, click “Next”.
-8. Review the amount you will receive is correct, tick the disclaimer, and click “Confirm Transaction”.
-9. After clicking confirm transaction, sign the signature request using your connected wallet (e.g. Metamask in this example).
-10. Wait until your transaction is confirmed.
+8. Review the amount you will receive is correct, tick the disclaimer, and click “Confirm Transaction”.
+9. After clicking confirm transaction, sign the signature request using your connected wallet (e.g. Metamask in this example).
+10. Wait until your transaction is confirmed.
11. Navigate back to your wallet homepage and click “Earn Positions”.
-12. The status of your exit will be displayed here, as shown by “Exiting” (1 tick).
-13. To the left, click the transaction hash icon to be taken to the block explorer page to see the transaction status.
+12. The status of your exit will be displayed here, as shown by “Exiting” (1 tick).
+13. To the left, click the transaction hash icon to be taken to the block explorer page to see the transaction status.
14. Your funds will appear in your dashboard once the transaction has settled.
### Exiting LUSD Borrowing
@@ -62,15 +62,15 @@ Liquity: https://docs.liquity.org/
1. Navigate to your zk.money homepage and click “Wallet”.
2. Scroll down to “Tokens” and “Earn Positions”.
3. Click “Earn Positions”.
-4. On your Liquity Trove position, click “Repay & Exit”.
-5. Click “Max” to exit the full amount, then select a speed for your transaction.
+4. On your Liquity Trove position, click “Repay & Exit”.
+5. Click “Max” to exit the full amount, then select a speed for your transaction.
6. Once you have done so, click “Next”.
-7. Review the amount you will receive is correct, tick the disclaimer, and click “Confirm Transaction”.
+7. Review the amount you will receive is correct, tick the disclaimer, and click “Confirm Transaction”.
8. After clicking confirm transaction, sign the signature request using your connected wallet (e.g. Metamask).
9. Wait until your transaction is confirmed.
10. Navigate to your zk.money wallet homepage and click “Earn Positions”.
-11. The status of your exit will be displayed here, as shown by “Exiting” (1 tick).
-12. Click the transaction hash icon to be taken to the block explorer page to see the transaction status.
+11. The status of your exit will be displayed here, as shown by “Exiting” (1 tick).
+12. Click the transaction hash icon to be taken to the block explorer page to see the transaction status.
13. Your funds will appear in your dashboard once the transaction has settled.
### Withdrawing Assets
@@ -80,14 +80,14 @@ How to withdraw ETH, DAI and LUSD.
1. Navigate to your zk.money homepage and click “Wallet”.
2. Scroll down to “Tokens” and “Earn Positions”.
3. Click “Tokens”.
-4. Click “Exit” on the desired token you would like to withdraw.
-5. Click “Withdraw to L1”.
+4. Click “Exit” on the desired token you would like to withdraw.
+5. Click “Withdraw to L1”.
6. Enter your recipient address.
7. Click “Max” to withdraw the full amount.
8. Select a speed for your transaction (transactions are free in “Batched Mode”).
9. Click “Next”.
-10. Review the amount you are withdrawing is correct, tick the disclaimer, and click “Confirm Transaction”.
+10. Review the amount you are withdrawing is correct, tick the disclaimer, and click “Confirm Transaction”.
11. Sign the signature request using your connected wallet (e.g. Metamask).
-12. Wait until your transaction is confirmed.
-13. Navigate back to your wallet homepage, under Transaction History. Click the transaction hash to check the status of your transaction on the block explorer.
+12. Wait until your transaction is confirmed.
+13. Navigate back to your wallet homepage, under Transaction History. Click the transaction hash to check the status of your transaction on the block explorer.
14. Your funds will appear in your recipient wallet once the transaction has settled.
diff --git a/docs/docs/developers/guides/local_env/versions-updating.md b/docs/docs/developers/guides/local_env/versions-updating.md
index 485b65b20fb7..d601788d79e8 100644
--- a/docs/docs/developers/guides/local_env/versions-updating.md
+++ b/docs/docs/developers/guides/local_env/versions-updating.md
@@ -151,7 +151,7 @@ To update Aztec.js packages, go to your `package.json` and replace the versions
```diff
[dependencies]
-"@aztec/accounts": "0.7.5",
-+"@aztec/accounts": "#include_aztec_short_version",
++"@aztec/accounts": "#include_aztec_version",
-"@aztec/noir-contracts.js": "0.35.1",
-+"@aztec/accounts": "#include_aztec_short_version",
++"@aztec/accounts": "#include_aztec_version",
```
diff --git a/docs/docs/developers/index.md b/docs/docs/developers/index.md
index 8edaa1dfdf8c..aa692db11222 100644
--- a/docs/docs/developers/index.md
+++ b/docs/docs/developers/index.md
@@ -45,16 +45,16 @@ title: Build
-
@@ -76,4 +76,4 @@ title: Build
Find requests for applications, potential designs, and existing ecosystem projects
-
\ No newline at end of file
+
diff --git a/docs/docs/developers/tutorials/codealong/contract_tutorials/uniswap/index.md b/docs/docs/developers/tutorials/codealong/contract_tutorials/uniswap/index.md
index a8e97a18ef0a..3ca32b77ffcd 100644
--- a/docs/docs/developers/tutorials/codealong/contract_tutorials/uniswap/index.md
+++ b/docs/docs/developers/tutorials/codealong/contract_tutorials/uniswap/index.md
@@ -24,7 +24,7 @@ This reference will cover:
1. Uniswap Portal - a contract on L1 that talks to the input token portal to withdraw the assets, executes the swap, and deposits the swapped tokens back to L2
2. Uniswap L2 contract - a contract on L2 that creates the needed messages to perform the swap on L1
-
+
This diagram describes the private flow.
diff --git a/docs/docs/developers/tutorials/codealong/js_tutorials/aztecjs-getting-started.md b/docs/docs/developers/tutorials/codealong/js_tutorials/aztecjs-getting-started.md
index 845e80762f22..69fa56d5d843 100644
--- a/docs/docs/developers/tutorials/codealong/js_tutorials/aztecjs-getting-started.md
+++ b/docs/docs/developers/tutorials/codealong/js_tutorials/aztecjs-getting-started.md
@@ -198,7 +198,7 @@ We can see that each account has the expected balance of tokens.
### Calling an unconstrained (view) function
-
+
## Create and submit a transaction
diff --git a/docs/docs/index.mdx b/docs/docs/index.mdx
index 79431c7fa54f..47d3c000147a 100644
--- a/docs/docs/index.mdx
+++ b/docs/docs/index.mdx
@@ -20,19 +20,20 @@ On Ethereum today, everything is publicly visible, by everyone. In the real worl
- composability between private/public execution and private/public state
- public and private messaging with Ethereum
-To make this possible, Aztec is *not EVM compatible* and is extending the Ethereum ecosystem by creating a new alt-VM!
+To make this possible, Aztec is _not EVM compatible_ and is extending the Ethereum ecosystem by creating a new alt-VM!
To learn more about how Aztec achieves these things, check out the [Aztec concepts overview](/aztec).
## Start coding
-
+
Developer Getting Started Guide
- Follow the getting started guide to start developing with the Aztec Sandbox
+ Follow the getting started guide to start developing with the Aztec
+ Sandbox
@@ -40,12 +41,10 @@ To learn more about how Aztec achieves these things, check out the [Aztec concep
## Learn how Aztec works
-
+
Aztec Overview
-
- Learn the core concepts that make up the Aztec Protocol
-
+ Learn the core concepts that make up the Aztec Protocol
diff --git a/docs/docs/protocol-specs/addresses-and-keys/keys.md b/docs/docs/protocol-specs/addresses-and-keys/keys.md
index 5cfdbf5884f3..ee1c6e62a76f 100644
--- a/docs/docs/protocol-specs/addresses-and-keys/keys.md
+++ b/docs/docs/protocol-specs/addresses-and-keys/keys.md
@@ -10,25 +10,25 @@ import Image from "@theme/IdealImage";
The protocol does not enforce the usage of any of the following keys, and does not enforce the keys to conform to a particular length or algorithm. Users are expected to pick a set of keys valid for the encryption and tagging precompile they choose for their account.
-| Cat. | Key | Derivation | Link |
-|---|---|---|---|
-| Seed | $\seed$ | $$\stackrel{\$}{\leftarrow} \mathbb{F}$$ | [Seed](#seed) |
-| | $\sk$ | $$\stackrel{\$}{\leftarrow} \mathbb{F}$$ | [Master Secret Key](#master-secret-key) |
-|||||
-| Master Secret Keys | $\nskm$ | $\text{poseidon2}(\text{``az\_nsk\_m''}, \sk)$ | [Master Nullifier Secret Key](#master-nullifier-secret-key) |
-| | $\ovskm$ | $\text{poseidon2}(\text{``az\_ovsk\_m''}, \sk)$ | [Master Outgoing Viewing Secret Key](#master-outgoing-viewing-secret-key) |
-| | $\ivskm$ | $\text{poseidon2}(\text{``az\_ivsk\_m''}, \sk)$ | [Master Incoming Viewing Secret Key](#master-incoming-viewing-secret-key) |
-| | $\tskm$ | $\text{poseidon2}(\text{``az\_tsk\_m''}, \sk)$ | [Master Tagging Secret Key](#master-tagging-secret-key) |
-|||||
-| Master Public Keys | $\Npkm$ | $\nskm \cdot G$ | [Master Nullifier Public Key](#master-nullifier-public-key) |
-| | $\Ovpkm$ | $\ovskm \cdot G$ | [Master Outgoing Viewing Public Key](#master-outgoing-viewing-public-key) |
-| | $\Ivpkm$ | $\ivskm \cdot G$ | [Master Incoming Viewing Public Key](#master-incoming-viewing-public-key) |
-| | $\Tpkm$ | $\tskm \cdot G$ | [Master Tagging Public Key](#master-tagging-public-key) |
-||||
-| Hardened App-Siloed Secret Keys | $\nskapp$ | $\text{poseidon2}(\text{``az\_nsk\_app''}, \text{app\_address}, \nskm)$ | [Hardened, App-siloed Nullifier Secret Key](#app-siloed-nullifier-secret-key) |
-| | $\ovskapp$ | $\text{poseidon2}(\text{``az\_ovsk\_app''}, \text{app\_address}, \ovskm)$ | [Hardened, App-siloed Outgoing Viewing Secret Key](#app-siloed-outgoing-viewing-secret-key) |
-|||||
-| Other App-siloed Keys| $\Nkapp$ | $\text{poseidon2}(\text{``az\_nk\_app''}, \nskapp)$ | [App-siloed Nullifier Key](#app-siloed-nullifier-key) |
+| Cat. | Key | Derivation | Link |
+| ------------------------------- | ---------- | ------------------------------------------------------------------------- | ------------------------------------------------------------------------------------------- |
+| Seed | $\seed$ | $$\stackrel{\$}{\leftarrow} \mathbb{F}$$ | [Seed](#seed) |
+| | $\sk$ | $$\stackrel{\$}{\leftarrow} \mathbb{F}$$ | [Master Secret Key](#master-secret-key) |
+| | | | |
+| Master Secret Keys | $\nskm$ | $\text{poseidon2}(\text{``az\_nsk\_m''}, \sk)$ | [Master Nullifier Secret Key](#master-nullifier-secret-key) |
+| | $\ovskm$ | $\text{poseidon2}(\text{``az\_ovsk\_m''}, \sk)$ | [Master Outgoing Viewing Secret Key](#master-outgoing-viewing-secret-key) |
+| | $\ivskm$ | $\text{poseidon2}(\text{``az\_ivsk\_m''}, \sk)$ | [Master Incoming Viewing Secret Key](#master-incoming-viewing-secret-key) |
+| | $\tskm$ | $\text{poseidon2}(\text{``az\_tsk\_m''}, \sk)$ | [Master Tagging Secret Key](#master-tagging-secret-key) |
+| | | | |
+| Master Public Keys | $\Npkm$ | $\nskm \cdot G$ | [Master Nullifier Public Key](#master-nullifier-public-key) |
+| | $\Ovpkm$ | $\ovskm \cdot G$ | [Master Outgoing Viewing Public Key](#master-outgoing-viewing-public-key) |
+| | $\Ivpkm$ | $\ivskm \cdot G$ | [Master Incoming Viewing Public Key](#master-incoming-viewing-public-key) |
+| | $\Tpkm$ | $\tskm \cdot G$ | [Master Tagging Public Key](#master-tagging-public-key) |
+| | | |
+| Hardened App-Siloed Secret Keys | $\nskapp$ | $\text{poseidon2}(\text{``az\_nsk\_app''}, \text{app\_address}, \nskm)$ | [Hardened, App-siloed Nullifier Secret Key](#app-siloed-nullifier-secret-key) |
+| | $\ovskapp$ | $\text{poseidon2}(\text{``az\_ovsk\_app''}, \text{app\_address}, \ovskm)$ | [Hardened, App-siloed Outgoing Viewing Secret Key](#app-siloed-outgoing-viewing-secret-key) |
+| | | | |
+| Other App-siloed Keys | $\Nkapp$ | $\text{poseidon2}(\text{``az\_nk\_app''}, \nskapp)$ | [App-siloed Nullifier Key](#app-siloed-nullifier-key) |
## Colour Key
@@ -47,7 +47,7 @@ The protocol does not enforce the usage of any of the following keys, and does n
Diagram is out of date vs the content on this page
:::
-
+
The red boxes are uncertainties, which are explained later in this doc.
@@ -65,7 +65,7 @@ Elliptic curve operators $+$ and $\cdot$ are used to denote addition and scalar
$\text{poseidon2}: \mathbb{F}_r^t \rightarrow \mathbb{F}$ is the Poseidon2 hash function (and $t$ can take values as per the [Poseidon2 spec](https://eprint.iacr.org/2023/323.pdf)).
-Note that $q > r$. Below, we'll often define secret keys as an element of $\mathbb{F}_r$, as this is most efficient within a snark circuit. We'll then use such secret keys in scalar multiplications with Grumpkin points ($E(\mathbb{F}_r)$ whose affine points are of the form $\mathbb{F}_r \times \mathbb{F}_r$). Strictly speaking, such scalars in Grumpkin scalar multiplication should be in $\mathbb{F}_q$.
+Note that $q > r$. Below, we'll often define secret keys as an element of $\mathbb{F}_r$, as this is most efficient within a snark circuit. We'll then use such secret keys in scalar multiplications with Grumpkin points ($E(\mathbb{F}_r)$ whose affine points are of the form $\mathbb{F}_r \times \mathbb{F}_r$). Strictly speaking, such scalars in Grumpkin scalar multiplication should be in $\mathbb{F}_q$.
A potential consequence of using elements of $\mathbb{F}_r$ as secret keys could be that the resulting public keys are not uniformly-distributed in the Grumpkin group, so we should check this. The distribution of such public keys will have a statistical distance of $\frac{2(q - r)}{q}$ from uniform. It turns out that $\frac{1}{2^{126}} < \frac{2(q - r)}{q} < \frac{1}{2^{125}}$, so the statistical distance from uniform is broadly negligible, especially considering that the AltBN254 curve has fewer than 125-bits of security.
## Key Derivation
@@ -122,8 +122,8 @@ This $\sk$ must never enter a circuit. A user or wallet may wish to derive this
$$\sk \stackrel{\$}{\leftarrow} \mathbb{F}_r$$
-> Note: Often $\sk = hash(\seed)$ for some hardware-wallet-supported hash function, would be recommended. Although, care would need to be taken if the hardware wallet doesn't support hashing directly to $\mathbb{F}_r$, since a truncated hash output could be non-uniformly distributed in $\mathbb{F}_r$.
-> For example, if the hardware wallet only supports sha256, then it would not be acceptable to compute $\sk$ as $\text{sha256}(\seed) \mod r$, since the resulting output (of reducing a 256-bit number modulo $r$) would be biased towards smaller values in $\mathbb{F_r}$. More uniformity might be achieved by instead computing $\sk$ as $( \text{sha256}(\seed, 1) || \text{sha256}(\seed, 2) ) \mod r$, for example, as a modulo reduction of a 512-bit number is closer to being uniformly distributed in $\mathbb{F_r}$.
+> Note: Often $\sk = hash(\seed)$ for some hardware-wallet-supported hash function, would be recommended. Although, care would need to be taken if the hardware wallet doesn't support hashing directly to $\mathbb{F}_r$, since a truncated hash output could be non-uniformly distributed in $\mathbb{F}_r$.
+> For example, if the hardware wallet only supports sha256, then it would not be acceptable to compute $\sk$ as $\text{sha256}(\seed) \mod r$, since the resulting output (of reducing a 256-bit number modulo $r$) would be biased towards smaller values in $\mathbb{F_r}$. More uniformity might be achieved by instead computing $\sk$ as $( \text{sha256}(\seed, 1) || \text{sha256}(\seed, 2) ) \mod r$, for example, as a modulo reduction of a 512-bit number is closer to being uniformly distributed in $\mathbb{F_r}$.
> This note is informal, and expert advice should be sought before adopting this approach.
## Nullifier Keys
@@ -143,7 +143,7 @@ $$
> See [`derive_master_secret_key_from_secret_key`](#derive-master-secret-key-from-secret-key).
-> $\nskm$ MUST NOT enter an app circuit.
+> $\nskm$ MUST NOT enter an app circuit.
> $\nskm$ MAY enter the kernel circuit.
### Master Nullifier Public Key
@@ -176,9 +176,9 @@ $$
If an app developer thinks some of their users might wish to have the option to enable some _trusted_ 3rd party to see when a particular user's notes are nullified, then this nullifier key might be of use. This $\Nkapp$ can be used in a nullifier's preimage, rather than $\nskapp$ in such cases, to enable said 3rd party to brute-force identify nullifications.
-> Note: this key can be optionally shared with a trusted 3rd party, and they would not be able to derive the user's secret keys.
-> Note: knowledge of this key enables someone to identify when an emitted nullifier belongs to the user, and to identify which note hashes have been nullified.
-> Note: knowledge of this key would not enable a 3rd party to view the contents of any notes; knowledge of the $\ivsk$ / $\ovskapp$ would be needed for that.
+> Note: this key can be optionally shared with a trusted 3rd party, and they would not be able to derive the user's secret keys.
+> Note: knowledge of this key enables someone to identify when an emitted nullifier belongs to the user, and to identify which note hashes have been nullified.
+> Note: knowledge of this key would not enable a 3rd party to view the contents of any notes; knowledge of the $\ivsk$ / $\ovskapp$ would be needed for that.
> Note: this is intentionally not named as a "public" key, since it must not be shared with the wider public.
$$
@@ -207,7 +207,7 @@ $$
> See [`derive_master_secret_key_from_seed`](#derive-master-secret-key-from-seed).
-> $\ovskm$ MUST NOT enter an app circuit.
+> $\ovskm$ MUST NOT enter an app circuit.
> $\ovskm$ MAY enter the kernel circuit.
### Master Outgoing Viewing Public Key
diff --git a/docs/docs/run_node/concepts/governance/governance.md b/docs/docs/run_node/concepts/governance/governance.md
index 7669574ddd49..883d43d73f0e 100644
--- a/docs/docs/run_node/concepts/governance/governance.md
+++ b/docs/docs/run_node/concepts/governance/governance.md
@@ -8,10 +8,10 @@ import Image from "@theme/IdealImage";
This diagram outlines how governance works on Aztec:
-
+
-Sequencers put forward, or “nominate”, proposals for voting by the Aztec citizens. To do this, sequencers interact with the Governance Proposer smart contract. Nominations are “signals” by sequencers that they wish to put up for vote the execution of certain code by the Governance smart contract.
+Sequencers put forward, or “nominate”, proposals for voting by the Aztec citizens. To do this, sequencers interact with the Governance Proposer smart contract. Nominations are “signals” by sequencers that they wish to put up for vote the execution of certain code by the Governance smart contract.
-If the Governance Proposer smart contract records a certain number of nominations/signals from sequencers, then the Governance Proposer smart contract initiates a voting process where any holders of any Hypothetical Assets (as defined below) can participate. Holders of such Hypothetical Assets are called Aztec citizens.
+If the Governance Proposer smart contract records a certain number of nominations/signals from sequencers, then the Governance Proposer smart contract initiates a voting process where any holders of any Hypothetical Assets (as defined below) can participate. Holders of such Hypothetical Assets are called Aztec citizens.
-All voting and signalling happen on the L1.
+All voting and signalling happen on the L1.
diff --git a/docs/docusaurus.config.js b/docs/docusaurus.config.js
index 43de69519eee..7d6b608ec946 100644
--- a/docs/docusaurus.config.js
+++ b/docs/docusaurus.config.js
@@ -2,15 +2,22 @@
// Note: type annotations allow type checking and IDEs autocompletion
const { themes } = require("prism-react-renderer");
+// @ts-ignore
const lightTheme = themes.github;
+// @ts-ignore
const darkTheme = themes.dracula;
+// @ts-ignore
import math from "remark-math";
+// @ts-ignore
import katex from "rehype-katex";
+// @ts-ignore
const path = require("path");
+// @ts-ignore
const fs = require("fs");
const macros = require("./src/katex-macros.js");
+const versions = require("./versions.json");
/** @type {import('@docusaurus/types').Config} */
const config = {
@@ -56,8 +63,8 @@ const config = {
},
routeBasePath: "/",
include: process.env.SHOW_PROTOCOL_SPECS
- ? ['**/*.{md,mdx}']
- : ['**/*.{md,mdx}', '!protocol-specs/**'],
+ ? ["**/*.{md,mdx}"]
+ : ["**/*.{md,mdx}", "!protocol-specs/**"],
remarkPlugins: [math],
rehypePlugins: [
@@ -70,6 +77,15 @@ const config = {
},
],
],
+ versions: (() => {
+ const versionObject = {};
+ versions.map((version) => {
+ versionObject[version] = {
+ banner: "none",
+ };
+ });
+ return versionObject;
+ })(),
},
blog: false,
theme: {
@@ -88,35 +104,6 @@ const config = {
},
],
plugins: [
- async function loadVersions(context, options) {
- // ...
- return {
- name: "load-versions",
- async loadContent() {
- try {
- const aztecVersionPath = path.resolve(
- __dirname,
- "../.release-please-manifest.json"
- );
- const aztecVersion = JSON.parse(
- fs.readFileSync(aztecVersionPath).toString()
- )["."];
- return {
- "aztec-packages": `v${aztecVersion}`,
- };
- } catch (err) {
- throw new Error(
- `Error loading versions in docusaurus build. Check load-versions in docusaurus.config.js.\n${err}`
- );
- }
- },
- async contentLoaded({ content, actions }) {
- // await actions.createData("versions.json", JSON.stringify(content));
- actions.setGlobalData({ versions: content });
- },
- /* other lifecycle API */
- };
- },
[
"@docusaurus/plugin-ideal-image",
{
@@ -222,6 +209,11 @@ const config = {
src: "img/Aztec_logo_dark-01.svg",
},
items: [
+ {
+ type: "docsVersionDropdown",
+ position: "left",
+ dropdownActiveClassDisabled: true,
+ },
{
type: "doc",
docId: "aztec/index",
@@ -305,13 +297,16 @@ const config = {
label: "Roadmap",
className: "no-external-icon",
},
- ...(process.env.SHOW_PROTOCOL_SPECS ?
- [{
- type: "docSidebar",
- sidebarId: "protocolSpecSidebar",
- label: "Protocol Specification",
- className: "no-external-icon",
- }] : []),
+ ...(process.env.SHOW_PROTOCOL_SPECS
+ ? [
+ {
+ type: "docSidebar",
+ sidebarId: "protocolSpecSidebar",
+ label: "Protocol Specification",
+ className: "no-external-icon",
+ },
+ ]
+ : []),
{
to: "https://noir-lang.org/docs",
label: "Noir docs",
diff --git a/docs/package.json b/docs/package.json
index 35dc9766240d..8af50702defd 100644
--- a/docs/package.json
+++ b/docs/package.json
@@ -13,7 +13,9 @@
"preprocess": "yarn node -r dotenv/config ./src/preprocess/index.js && node src/preprocess/generate_aztecnr_reference.js",
"preprocess:dev": "nodemon --config nodemon.json ./src/preprocess/index.js && nodemon --config nodemon.json src/preprocess/generate_aztecnr_reference.js ",
"typedoc": "docusaurus generate-typedoc",
- "rewrite": "node ./scripts/rewrite_paths.js"
+ "rewrite": "node ./scripts/rewrite_paths.js",
+ "version::stables": "node ./scripts/setStable.js",
+ "version": "yarn version::stables && ./scripts/cut_version.sh"
},
"dependencies": {
"@babel/runtime": "^7.26.0",
diff --git a/docs/scripts/build.sh b/docs/scripts/build.sh
index 2a8f4332a0f2..1036de5df69d 100755
--- a/docs/scripts/build.sh
+++ b/docs/scripts/build.sh
@@ -49,6 +49,9 @@ fi
echo Cleaning...
yarn clean
+echo "Getting the versions to build..."
+yarn version::stables
+
# Now build the docsite
echo Building docsite...
echo "Processing..."
@@ -56,5 +59,6 @@ yarn preprocess
yarn typedoc
sh scripts/move_processed.sh
+
echo "Building..."
yarn docusaurus build
diff --git a/docs/scripts/clean.sh b/docs/scripts/clean.sh
index ce1fe639f84d..01f7ecea52b0 100755
--- a/docs/scripts/clean.sh
+++ b/docs/scripts/clean.sh
@@ -1,5 +1,8 @@
#!/usr/bin/env bash
-rm -rf 'processed-docs' 'processed-docs-cache'
-rm -rf 'docs/developers/reference/aztecjs' 'docs/developers/reference/smart_contract_reference/aztec-nr'
+rm -rf \
+ processed-docs \
+ processed-docs-cache \
+ docs/reference/developer_references/aztecjs \
+ docs/reference/developer_references/smart_contract_reference/aztec-nr
docusaurus clear
diff --git a/docs/scripts/cut_version.sh b/docs/scripts/cut_version.sh
new file mode 100755
index 000000000000..4000707328cc
--- /dev/null
+++ b/docs/scripts/cut_version.sh
@@ -0,0 +1,16 @@
+#!/usr/bin/env bash
+set -eu
+
+cd $(dirname "$0")/..
+
+VERSION=$1
+
+# We assume that the new release tag has been made on github, so setStable.ts will add this to `versions.json`.
+# We don't have a version of the docs for this release however (that's what we're doing right now!) so we need to remove it.
+jq 'map(select(. != "'"$VERSION"'"))' versions.json > tmp.json && mv tmp.json versions.json
+
+# We need to build the docs in order to perform all necessary preprocessing.
+yarn build
+
+# Finally cut the actual new docs version.
+yarn docusaurus docs:version $VERSION
diff --git a/docs/scripts/setStable.js b/docs/scripts/setStable.js
new file mode 100644
index 000000000000..ff8e73fde7fa
--- /dev/null
+++ b/docs/scripts/setStable.js
@@ -0,0 +1,61 @@
+/* eslint-disable @typescript-eslint/no-var-requires */
+const fs = require("fs");
+const path = require("path");
+const axios = require("axios");
+
+const GITHUB_PAGES = 3;
+
+async function main() {
+ const axiosOpts = {
+ params: { per_page: 100 },
+ headers: {},
+ };
+
+ if (process.env.GITHUB_TOKEN)
+ axiosOpts.headers = { Authorization: `token ${process.env.GITHUB_TOKEN}` };
+
+ let stables = [];
+ console.log("Retrieved versions:");
+
+ for (let i = 0; i < GITHUB_PAGES; i++) {
+ const { data } = await axios.get(
+ `https://api.github.com/repos/aztecprotocol/aztec-packages/releases?page=${
+ i + 1
+ }`,
+ axiosOpts
+ );
+
+ stables.push(
+ ...data
+ .filter((release) => {
+ const tag = release.tag_name;
+ return (
+ !tag.includes("aztec") &&
+ (!tag.includes("-alpha-testnet") || tag.includes("-alpha-testnet"))
+ );
+ })
+ .map((release) => release.tag_name)
+ );
+ }
+
+ // After collecting all versions, separate and sort them
+ const alphaTestnetVersions = stables
+ .filter((v) => v.includes("-alpha-testnet"))
+ .sort((a, b) => b.localeCompare(a));
+ const regularVersions = stables
+ .filter((v) => !v.includes("-alpha-testnet"))
+ .filter((v) => !v.includes("-nightly"))
+ .sort((a, b) => b.localeCompare(a));
+
+ // Take the latest of each
+ stables = [regularVersions[0], alphaTestnetVersions[0]].filter(Boolean); // Remove any undefined entries if one type doesn't exist
+
+ console.log("Filtered down to stables: ", stables);
+
+ fs.writeFileSync(
+ path.resolve(__dirname, "../versions.json"),
+ JSON.stringify(stables, null, 2)
+ );
+}
+
+main();
diff --git a/docs/src/preprocess/include_version.js b/docs/src/preprocess/include_version.js
index caa2ababe596..07e9926d647c 100644
--- a/docs/src/preprocess/include_version.js
+++ b/docs/src/preprocess/include_version.js
@@ -1,41 +1,11 @@
-const path = require("path");
-const fs = require("fs");
-
-const VERSION_IDENTIFIERS = ["noir", "aztec", "aztec_short"];
-
-let versions;
-async function getVersions() {
- if (!versions) {
- try {
- const aztecVersionPath = path.resolve(
- __dirname,
- "../../../.release-please-manifest.json"
- );
- const aztecVersion = JSON.parse(
- fs.readFileSync(aztecVersionPath).toString()
- )["."];
- versions = {
- aztec: `v${aztecVersion}`,
- aztec_short: aztecVersion,
- };
- } catch (err) {
- throw new Error(
- `Error loading versions in docusaurus preprocess step.\n${err}`
- );
- }
- }
- return versions;
-}
-
async function preprocessIncludeVersion(markdownContent) {
const originalContent = markdownContent;
- for (const identifier of VERSION_IDENTIFIERS) {
- const version = (await getVersions())[identifier];
- markdownContent = markdownContent.replaceAll(
- `#include_${identifier}_version`,
- version
- );
- }
+
+ markdownContent = markdownContent.replaceAll(
+ `#include_aztec_version`,
+ process.env.COMMIT_TAG || "master"
+ );
+
return {
content: markdownContent,
isUpdated: originalContent !== markdownContent,
diff --git a/docs/tsconfig.json b/docs/tsconfig.json
index 4ffb6f0fb229..89223cb9db25 100644
--- a/docs/tsconfig.json
+++ b/docs/tsconfig.json
@@ -1,3 +1,6 @@
{
- "extends": "@tsconfig/docusaurus/tsconfig.json"
+ "extends": "@tsconfig/docusaurus/tsconfig.json",
+ "compilerOptions": {
+ "resolveJsonModule": true
+ }
}
diff --git a/docs/versioned_docs/version-v0.82.2-alpha-testnet.5/aztec/concepts/_category_.json b/docs/versioned_docs/version-v0.82.2-alpha-testnet.5/aztec/concepts/_category_.json
new file mode 100644
index 000000000000..88de50877b40
--- /dev/null
+++ b/docs/versioned_docs/version-v0.82.2-alpha-testnet.5/aztec/concepts/_category_.json
@@ -0,0 +1,6 @@
+{
+ "label": "Concepts",
+ "position": 1,
+ "collapsible": true,
+ "collapsed": true
+}
diff --git a/docs/versioned_docs/version-v0.82.2-alpha-testnet.5/aztec/concepts/accounts/_category_.json b/docs/versioned_docs/version-v0.82.2-alpha-testnet.5/aztec/concepts/accounts/_category_.json
new file mode 100644
index 000000000000..ddbe59a365c3
--- /dev/null
+++ b/docs/versioned_docs/version-v0.82.2-alpha-testnet.5/aztec/concepts/accounts/_category_.json
@@ -0,0 +1,6 @@
+{
+ "label": "Accounts",
+ "position": 5,
+ "collapsible": true,
+ "collapsed": true
+}
diff --git a/docs/versioned_docs/version-v0.82.2-alpha-testnet.5/aztec/concepts/accounts/index.md b/docs/versioned_docs/version-v0.82.2-alpha-testnet.5/aztec/concepts/accounts/index.md
new file mode 100644
index 000000000000..42d2a3f6ca0a
--- /dev/null
+++ b/docs/versioned_docs/version-v0.82.2-alpha-testnet.5/aztec/concepts/accounts/index.md
@@ -0,0 +1,172 @@
+---
+title: Accounts
+sidebar_position: 1
+tags: [accounts]
+---
+
+Aztec has native account abstraction. Every account in Aztec is a smart contract.
+
+In this section, you'll learn about Aztec's account abstraction, Aztec accounts and address derivation, how wallets relate to accounts, and how the entrypoints are defined.
+
+## Account Abstraction (AA)
+
+With account abstraction, the identity of a user is usually represented by a smart contract. That makes user's on-chain identity more flexible than simply using private/public keys. For example, Bitcoin has rigid accounts that must be a private key, whereas a user might want their on-chain identity to be controlled by a physical passport.
+
+Among the account parts to be abstracted are authentication (“Who I am”), authorization (“What I am allowed to do”), replay protection, fee payment, and execution.
+
+Some account features unlocked by account abstraction are account recovery, gas sponsorship, and support of signatures other than ECDSA, such as more efficient signatures (e.g. Schnorr, BLS), or more user-friendly ones (e.g. smartphone secure enclave).
+
+### Protocol vs application level
+
+AA can be implemented at the protocol level is called native Account Abstraction. In this case, all the accounts on the network are smart contracts. AA can also be implemented at the smart-contract level, then we call it non-native Account Abstraction. In this case, there might be both EOAs and accounts controlled by smart contracts.
+
+In the case of Aztec, we have native Account Abstraction.
+
+## Aztec Account Abstraction
+
+### Authorization abstraction and DoS attacks
+
+While we talk about “arbitrary verification logic” describing the intuition behind AA, the logic is usually not really arbitrary. The verification logic (i.e. what is checked as an authorization) is limited to make the verification time fast and bounded. If it is not bounded, an attacker can flood the mempool with expensive invalid transactions, clogging the network. That is the case for all chains where transaction validity is checked by the sequencer.
+
+On Aztec, there is no limitation on the complexity of verification logic (what does it mean for the transaction to be valid). Whatever conditions it checks, the proof (that the sequencer needs to verify) is independent of its complexity.
+
+This unlocks a whole universe of new use cases and optimization of existing ones. Whenever the dapp can benefit from moving expensive computations off-chain, Aztec will provide a unique chance for an optimization. That is to say, on traditional chains users pay for each executed opcode, hence more complex operations (e.g. alternative signature verification) are quite expensive. In the case of Aztec, it can be moved off-chain so that it becomes almost free. The user pays for the operations in terms of client-side prover time. However, this refers to Aztec's client-side proving feature and not directly AA.
+
+Couple of examples:
+
+- Multisig contract with an arbitrary number of parties that can verify any number of signatures for free.
+- Oracle contract with an arbitrary number of data providers that can verify any number of data entries for free.
+
+## Aztec account
+
+Smart contracts on Aztec are represented by an "address", which is a hexadecimal number that uniquely represents an entity on the Aztec network. An address is derived by hashing information specific to the entity represented by the address. This information includes contract bytecode and the public keys used in private execution for encryption and nullification. This means addresses are deterministic.
+
+Aztec has no concept of EOAs (Externally Owned Accounts). Every account is implemented as a contract.
+
+### Entrypoints
+
+Account contracts usually have a specific function called `entrypoint`. It serves as the interface for interaction with the smart contract and can be called by external users or other smart contracts.
+
+An `entrypoint` function receives the actions to be carried out and an authentication payload. In pseudocode:
+
+```
+publicKey: PublicKey;
+
+def entryPoint(payload):
+ let { privateCalls, publicCalls, nonce, signature } = payload;
+ let payloadHash = hash(privateCalls, publicCalls, nonce);
+ validateSignature(this.publicKey, signature, payloadHash);
+
+ foreach privateCall in privateCalls:
+ let { to, data, value } = privateCall;
+ call(to, data, value);
+
+ foreach publicCall in publicCalls:
+ let { to, data, value, gasLimit } = publicCall;
+ enqueueCall(to, data, value, gasLimit);
+```
+
+A request for executing an action requires:
+
+- The `origin` contract to execute as the first step.
+- The initial function to call (usually `entrypoint`).
+- The arguments (which encode the private and public calls to run as well as any signatures).
+
+Read more about how to write an account contract [here](../../../developers/tutorials/codealong/contract_tutorials/write_accounts_contract.md).
+
+### Non-standard entrypoints
+
+Since the `entrypoint` interface is not enshrined, there is nothing that differentiates an account contract from an application contract. This allows implementing functions that can be called by any user and are just intended to advance the state of a contract.
+
+For example, a lottery contract, where at some point a prize needs to be paid out to its winners. This `pay` action does not require authentication and does not need to be executed by any user in particular, so anyone could submit a transaction that defines the lottery contract itself as `origin` and `pay` as `entrypoint` function. However, it's on the contract to define how fees for the prize claim will be paid as they won't be paid by the account contract.
+
+For an example of this behavior see our [e2e_crowdfunding_and_claim test](https://github.com/AztecProtocol/aztec-packages/blob/88b5878dd4b95d691b855cd84153ba884adf25f8/yarn-project/end-to-end/src/e2e_crowdfunding_and_claim.test.ts#L322) and the [SignerLess wallet](https://github.com/AztecProtocol/aztec-packages/blob/master/yarn-project/aztec.js/src/wallet/signerless_wallet.ts) implementation. Notice that the Signerless wallet doesn't invoke an `entrypoint` function of an account contract but instead invokes the target contract function directly.
+
+:::info
+
+Entrypoints for the following cases:
+
+- If no contract `entrypoint` is used `msg_sender` is set to `Field.max`.
+- In a private to public `entrypoint`, `msg_sender` is the contract making the private to public call.
+- When calling the `entrypoint` on an account contract, `msg_sender` is set to the account contract address.
+
+:::
+
+### Account contracts and wallets
+
+Account contracts are tightly coupled to the wallet software that users use to interact with the protocol. Dapps submit to the wallet software one or more function calls to be executed (e.g. "call swap in X contract"), and the wallet encodes and signs the request as a valid payload for the user's account contract. The account contract then validates the request encoded and signed by the wallet, and executes the function calls requested by the dapp.
+
+### Account Initialization
+
+When a user wants to interact with the network's **public** state, they need to deploy their account contract. A contract instance is considered to be publicly deployed when it has been broadcasted to the network via the canonical `ContractInstanceDeployer` contract, which also emits a deployment nullifier associated to the deployed instance.
+
+However, to send fully **private** transactions, it's enough to initialize the account contract (public deployment is not needed). The default state for any given address is to be uninitialized, meaning a function with the [initializer annotation](../../../developers/tutorials/codealong/contract_tutorials/nft_contract.md#initializer) has not been called. The contract is initialized when one of the functions marked with the `#[initializer]` annotation has been invoked. Multiple functions in the contract can be marked as initializers. Contracts may have functions that skip the initialization check (marked with `#[noinitcheck]`).
+
+Account deployment and initialization are not required to receive notes. The user address is deterministically derived from the encryption public key and the account contract they intend to deploy, so that funds can be sent to an account that hasn't been deployed yet.
+
+Users will need to pay transaction fees in order to deploy their account contract. This can be done by sending fee juice to their account contract address (which can be derived deterministically, as mentioned above), so that the account has funds to pay for its own deployment. Alternatively, the fee can be paid for by another account, using [fee abstraction](#fee-abstraction).
+
+## What is an account address
+
+Address is derived from the [address keys](keys.md#address-keys). While the AddressPublicKey is an elliptic curve point of the form (x,y) on the [Grumpkin elliptic curve](https://github.com/AztecProtocol/aztec-connect/blob/9374aae687ec5ea01adeb651e7b9ab0d69a1b33b/markdown/specs/aztec-connect/src/primitives.md), the address is its x coordinate. The corresponding y coordinate can be derived if needed. For x to be a legitimate address, address there should exist a corresponding y that satisfies the curve equation. Any field element cannot work as an address.
+
+### Complete address
+
+Because of the contract address derivation scheme, you can check that a given set of public [keys](keys.md) corresponds to a given address by trying to recompute it.
+
+If Alice wants Bob to send her a note, it's enough to share with him her address (x coordinate of the AddressPublicKey).
+
+However, if Alice wants to spend her notes (i.e. to prove that the nullifier key inside her address is correct) she needs her complete address. It is represented by:
+
+- all the user's public keys,
+- [partial address](keys.md#address-keys),
+- contract address.
+
+## Authorizing actions
+
+Account contracts are also expected, though not required by the protocol, to implement a set of methods for authorizing actions on behalf of the user. During a transaction, a contract may call into the account contract and request the user authorization for a given action, identified by a hash. This pattern is used, for instance, for transferring tokens from an account that is not the caller.
+
+When executing a private function, this authorization is checked by requesting an authentication witness from the execution oracle, which is usually a signed message. Authentication Witness is a scheme for authenticating actions on Aztec, so users can allow third-parties (e.g. contracts) to execute an action on their behalf.
+
+The user's [Private eXecution Environment (PXE)](../pxe/index.md) is responsible for storing these auth witnesses and returning them to the requesting account contract. Auth witnesses can belong to the current user executing the local transaction, or to another user who shared it out-of-band.
+
+However, during a public function execution, it is not possible to retrieve a value from the local [oracle](../../smart_contracts/oracles/index.md). To support authorizations in public functions, account contracts should save in a public authwit registry what actions have been pre-authorized by their owner.
+
+These two patterns combined allow an account contract to answer whether an action `is_valid_impl` for a given user both in private and public contexts.
+
+You can read more about authorizing actions with authorization witnesses on [this page](../advanced/authwit.md).
+
+:::info
+
+Transaction simulations in the PXE are not currently simulated, this is future work described [here](https://github.com/AztecProtocol/aztec-packages/issues/9133). This means that any transaction simulations that call into a function requiring an authwit will require the user to provide an authwit. Without simulating simulations, the PXE can't anticipate what authwits a transaction may need, so developers will need to manually request these authwits from users. In the future, transactions requiring authwits will be smart enough to ask the user for the correct authwits automatically.
+
+:::
+
+## Nonce and fee abstraction
+
+Beyond the authentication logic abstraction, there are nonce abstraction and fee abstraction.
+
+### Nonce abstraction
+
+Nonce is a unique number and it is utilized for replay protection (i.e. preventing users from executing a transaction more than once and unauthorized reordering).
+
+In particular, nonce management defines what it means for a transaction to be canceled, the rules of transaction ordering, and replay protection. In Ethereum, nonce is enshrined into the protocol. On the Aztec network, nonce is abstracted i.e. if a developer wants to customize it, they get to decide how they handle replay protection, transaction cancellation, as well as ordering.
+
+Take as an example the transaction cancellation logic. It can be done through managing nullifiers. Even though we usually refer to a nullifier as a creature utilized to consume a note, in essence, a nullifier is an emitted value whose uniqueness is guaranteed by the protocol. If we want to cancel a transaction before it was mined, we can send another transaction with higher gas price that emits the same nullifier (i.e. nullifier with the same value, for example, 5). The second transaction will invalidate the original one, since nullifiers cannot be repeated.
+
+Nonce abstraction is mostly relevant to those building wallets. For example, a developer can design a wallet that allows sending big transactions with very low priority fees because the transactions are not time sensitive (i.e. the preference is that a transaction is cheap and doesn't matter if it is slow). If one tries to apply this logic today on Ethereum (under sequential nonces), when they send a large, slow transaction they can't send any other transactions until that first large, slow transaction is processed.
+
+### Fee abstraction
+
+It doesn't have to be the transaction sender who pays the transaction fees. Wallets or dapp developers can choose any payment logic they want using a paymaster. To learn more about fees on Aztec – check [this page](../fees.md).
+
+Paymaster is a contract that can pay for transactions on behalf of users. It is invoked during the private execution stage and set as the fee payer.
+
+- It can be managed by a dapp itself (e.g. a DEX can have its own paymaster) or operate as a third party service available for everyone.
+- Fees can be paid publicly or privately.
+- Fees can be paid in any token that a paymaster accepts.
+
+Fee abstraction unlocks use cases like:
+
+- Sponsored transactions (e.g. the dapp's business model might assume revenue from other streams besides transaction fees or the dapp might utilize sponsored transaction mechanics for marketing purposes). For example, sponsoring the first ten transactions for every user.
+- Flexibility in the currency used in transaction payments (e.g. users can pay for transactions in ERC-20 token).
diff --git a/docs/versioned_docs/version-v0.82.2-alpha-testnet.5/aztec/concepts/accounts/keys.md b/docs/versioned_docs/version-v0.82.2-alpha-testnet.5/aztec/concepts/accounts/keys.md
new file mode 100644
index 000000000000..07429f388702
--- /dev/null
+++ b/docs/versioned_docs/version-v0.82.2-alpha-testnet.5/aztec/concepts/accounts/keys.md
@@ -0,0 +1,181 @@
+---
+title: Keys
+tags: [accounts, keys]
+---
+
+import Image from "@theme/IdealImage";
+
+In this section, you will learn what keys are used in Aztec, and how the addresses are derived.
+
+## Types of keys
+
+Each Aztec account is backed by four key pairs:
+
+- Nullifier keys – used to spend notes.
+- Address keys – this is an auxiliary key used for the address derivation; it’s internally utilized by the protocol and does not require any action from developers.
+- Incoming viewing keys – used to encrypt a note for the recipient.
+- Signing keys – an optional key pair used for account authorization.
+
+The first three pairs are embedded into the protocol while the signing key is abstracted up to the account contract developer.
+
+### Nullifier keys
+
+Nullifier keys are presented as a pair of the master nullifier public key (`Npk_m`) and the master nullifier secret key (`nsk_m`).
+
+To spend a note, the user computes a nullifier corresponding to this note. A nullifier is a hash of the note hash and app-siloed nullifier secret key, the latter is derived using the nullifier master secret key. To compute the nullifier, the protocol checks that the app-siloed key is derived from the master key for this contract and that master nullifier public key is linked to the note owner's address.
+
+### Address keys
+
+Address keys are used for account [address derivation](../accounts/index.md).
+
+
+
+Address keys are a pair of keys `AddressPublicKey` and `address_sk` where `address_sk` is a scalar defined as `address_sk = pre_address + ivsk` and `AddressPublicKey` is an elliptic curve point defined as `AddressPublicKey = address_sk * G`. This is useful for encrypting notes for the recipient with only their address.
+
+`pre_address` can be thought of as a hash of all account’s key pairs and functions in the account contract.
+
+In particular,
+
+```
+pre_address := poseidon2(public_keys_hash, partial_address)
+public_keys_hash := poseidon2(Npk_m, Ivpk_m, Ovpk_m, Tpk_m)
+partial_address := poseidon2(contract_class_id, salted_initialization_hash)
+contract_class_id := poseidon2(artifact_hash, fn_tree_root, public bytecode commitment)
+salted_initialization_hash := poseidon2(deployer_address, salt, constructor_hash)
+```
+
+where
+
+- `artifact_hash` – hashes data from the Contract Artifact file that contains the data needed to interact with a specific contract, including its name, functions that can be executed, and the interface and code of those functions.
+- `fn_tree_root` – hashes pairs of verification keys and function selector (`fn_selector`) of each private function in the contract.
+- `fn_selector` – the first four bytes of the hashed `function signature` where the last one is a string consisting of the function's name followed by the data types of its parameters.
+- `public bytecode commitment` – takes contract's code as an input and returns short commitment.
+- `deployer_address` – account address of the contract deploying the contract.
+- `salt` – a user-specified 32-byte value that adds uniqueness to the deployment.
+- `constructor_hash` – hashes `constructor_fn_selector` and `constructor_args` where the last one means public inputs of the contract.
+
+:::note
+Under the current design Aztec protocol does not use `Ovpk` (outgoing viewing key) and `Tpk` (tagging key). However, formally they still exist and can be used by developers for some non-trivial design choices if needed.
+:::
+
+### Incoming viewing keys
+
+The incoming viewing public key (`Ivpk`) is used by the sender to encrypt a note for the recipient. The corresponding incoming viewing secret key (`ivsk`) is used by the recipient to decrypt the note.
+
+When it comes to notes encryption and decryption:
+
+- For each note, there is a randomly generated ephemeral key pair (`esk`, `Epk`) where `Epk = esk * G`.
+- The `AddressPublicKey` (derived from the `ivsk`) together with `esk` are encrypted as a secret `S`, `S = esk * AddressPublicKey`.
+- `symmetric_encryption_key = hash(S)`
+- `Ciphertext = aes_encrypt(note, symmetric_encryption_key)`
+- The recipient gets a pair (`Epk`, `Ciphertext`)
+- The recipient uses the `address_sk` to decrypt the secret: `S = Epk * address_sk`.
+- The recipient uses the decrypted secret to decrypt the ciphertext.
+
+### Signing keys
+
+Thanks to the native [account abstraction](../accounts/index.md), authorization logic can be implemented in an alternative way that is up to the developer (e.g. using Google authorization credentials, vanilla password logic or Face ID mechanism). In these cases, signing keys may not be relevant.
+
+However if one wants to implement authorization logic containing signatures (e.g. ECDSA or Shnorr) they will need signing keys. Usually, an account contract will validate a signature of the incoming payload against a known signing public key.
+
+This is a snippet of our Schnorr Account contract implementation, which uses Schnorr signatures for authentication:
+
+```rust title="is_valid_impl" showLineNumbers
+// Load public key from storage
+let storage = Storage::init(context);
+let public_key = storage.signing_public_key.get_note();
+
+// Load auth witness
+// Safety: The witness is only used as a "magical value" that makes the signature verification below pass.
+// Hence it's safe.
+let witness: [Field; 64] = unsafe { get_auth_witness(outer_hash) };
+let mut signature: [u8; 64] = [0; 64];
+for i in 0..64 {
+ signature[i] = witness[i] as u8;
+}
+
+let pub_key = std::embedded_curve_ops::EmbeddedCurvePoint {
+ x: public_key.x,
+ y: public_key.y,
+ is_infinite: false,
+};
+// Verify signature of the payload bytes
+schnorr::verify_signature(pub_key, signature, outer_hash.to_be_bytes::<32>())
+```
+> Source code: noir-projects/noir-contracts/contracts/schnorr_account_contract/src/main.nr#L65-L86
+
+
+### Storing signing keys
+
+Since signatures are fully abstracted, how the public key is stored in the contract is abstracted as well and left to the developer of the account contract. Among a few common approaches are storing the key in a private note, in an immutable private note, using shared mutable state, reusing other in-protocol keys, or a separate keystore. Below, we elaborate on these approaches.
+
+#### Using a private note
+
+Storing the signing public key in a private note makes it accessible from the `entrypoint` function, which is required to be a private function, and allows for rotating the key when needed. However, keep in mind that reading a private note requires nullifying it to ensure it is up-to-date, so each transaction you send will destroy and recreate the public key so the protocol circuits can be sure that the notes are not stale. This incurs cost for every transaction.
+
+#### Using an immutable private note
+
+Using an immutable private note removes the need to nullify the note on every read. This generates no nullifiers or new commitments per transaction. However, it does not allow the user to rotate their key.
+
+```rust title="public_key" showLineNumbers
+signing_public_key: PrivateImmutable,
+```
+> Source code: noir-projects/noir-contracts/contracts/schnorr_account_contract/src/main.nr#L28-L30
+
+
+:::note
+When it comes to storing the signing key in a private note, there are several details that rely on the wallets:
+
+- A note with a key is managed similar to any other private note. Wallets are expected to backup all the notes so that they can be restored on another device (e.g. if the user wants to move to another device).
+- The note with the key might exist locally only (in PXE) or it can be broadcasted as an encrypted note by the wallet to itself. In the second case, this note will also exist on Aztec.
+ :::
+
+#### Using Shared Mutable state
+
+By [Shared Mutable](../../../developers/reference/smart_contract_reference/storage/shared_state.md#sharedmutable) we mean privately readable publicly mutable state.
+
+To make public state accessible privately, there is a delay window in public state updates. One needs this window to be able to generate proofs client-side. This approach would not generate additional nullifiers and commitments for each transaction while allowing the user to rotate their key. However, this causes every transaction to now have a time-to-live determined by the frequency of the mutable shared state, as well as imposing restrictions on how fast keys can be rotated due to minimum delays.
+
+#### Reusing some of the in-protocol keys
+
+It is possible to use some of the key pairs defined in protocol (e.g. incoming viewing keys) as the signing key. Since this key is part of the address preimage, it can be validated against the account contract address rather than having to store it. However, this approach is not recommended since it reduces the security of the user's account.
+
+#### Using a separate keystore
+
+Since there are no restrictions on the actions that an account contract may execute for authenticating a transaction (as long as these are all private function executions), the signing public keys can be stored in a separate keystore contract that is checked on every call. In this case, each user could keep a single contract that acts as a keystore, and have multiple account contracts that check against that keystore for authorization. This will incur a higher proving time for each transaction, but has no additional cost in terms of fees.
+
+### Keys generation
+
+All key pairs (except for the signing keys) are generated in the [Private Execution Environment](../pxe/index.md) (PXE) when a user creates an account. PXE is also responsible for the further key management (oracle access to keys, app siloed keys derivation, etc.)
+
+### Keys derivation
+
+All key pairs are derived using elliptic curve public-key cryptography on the [Grumpkin curve](https://github.com/AztecProtocol/aztec-connect/blob/9374aae687ec5ea01adeb651e7b9ab0d69a1b33b/markdown/specs/aztec-connect/src/primitives.md), where the secret key is represented as a scalar and the public key is represented as an elliptic curve point multiplied by that scalar.
+
+The address private key is an exception and derived in a way described above in the [Address keys](#address-keys) section.
+
+### The special case of escrow contracts
+
+Typically, for account contracts the public keys will be non-zero and for non-account contracts zero.
+
+An exception (a non-account contract which would have some of the keys non-zero) is an escrow contract. Escrow contract is a type of contract which on its own is an "owner" of a note meaning that it has a `Npk_m` registered and the notes contain this `Npk_m`.
+
+Participants in this escrow contract would then somehow get a hold of the escrow's `nsk_m` and nullify the notes based on the logic of the escrow. An example of an escrow contract is a betting contract. In this scenario, both parties involved in the bet would be aware of the escrow's `nsk_m`. The escrow would then release the reward only to the party that provides a "proof of winning".
+
+### App-siloed keys
+
+Nullifier keys and Incoming view keys are app-siloed meaning they are scoped to the contract that requests them. This means that the keys used for the same user in two different application contracts will be different.
+
+App-siloed keys allow to minimize damage of potential key leaks as a leak of the scoped keys would only affect one application.
+
+App-siloed keys are derived from the corresponding master keys and the contract address. For example, for the app-siloed nullifier secret key: `nsk_app = hash(nsk_m, app_contract_address)`.
+
+App-siloed keys [are derived](../advanced/storage/storage_slots.md#implementation) in PXE every time the user interacts with the application.
+
+App-siloed incoming viewing key also allows per-application auditability. A user may choose to disclose this key for a given application to an auditor or regulator (or for 3rd party interfaces, e.g. giving access to a block explorer to display my activity), as a means to reveal all their activity within that context, while retaining privacy across all other applications in the network.
+
+### Key rotation
+
+Key rotation is the process of creating new signing keys to replace existing keys. By rotating encryption keys on a regular schedule or after specific events, you can reduce the potential consequences of the key being compromised.
+
+On Aztec, key rotation is impossible for nullifier keys, incoming viewing keys and address keys as all of them are embedded into the address and address is unchangeable. In the meanwhile, signing keys can be rotated.
diff --git a/docs/versioned_docs/version-v0.82.2-alpha-testnet.5/aztec/concepts/advanced/authwit.md b/docs/versioned_docs/version-v0.82.2-alpha-testnet.5/aztec/concepts/advanced/authwit.md
new file mode 100644
index 000000000000..01f8997bacec
--- /dev/null
+++ b/docs/versioned_docs/version-v0.82.2-alpha-testnet.5/aztec/concepts/advanced/authwit.md
@@ -0,0 +1,143 @@
+---
+title: Authentication Witness (Authwit)
+tags: [accounts, authwit]
+sidebar_position: 2
+keywords: [authwit, authentication witness, accounts]
+---
+
+import Image from "@theme/IdealImage";
+
+Authentication Witness is a scheme for authenticating actions on Aztec, so users can allow third-parties (eg protocols or other users) to execute an action on their behalf.
+
+## Background
+
+When building DeFi or other smart contracts, it is often desired to interact with other contracts to execute some action on behalf of the user. For example, when you want to deposit funds into a lending protocol, the protocol wants to perform a transfer of [ERC20](https://eips.ethereum.org/EIPS/eip-20) tokens from the user's account to the protocol's account.
+
+In the EVM world, this is often accomplished by having the user `approve` the protocol to transfer funds from their account, and then calling a `deposit` function on it afterwards.
+
+
+
+This flow makes it rather simple for the application developer to implement the deposit function, but does not come without its downsides.
+
+One main downside, which births a bunch of other issues, is that the user needs to send two transactions to make the deposit - first the `approve` and then the `deposit`.
+
+To limit the annoyance for return-users, some front-ends will use the `approve` function with an infinite amount, which means that the user will only have to sign the `approve` transaction once, and every future `deposit` will then use some of that "allowance" to transfer funds from the user's account to the protocol's account.
+
+This can lead to a series of issues though, eg:
+
+- The user is not aware of how much they have allowed the protocol to transfer.
+- The protocol can transfer funds from the user's account at any time. This means that if the protocol is rugged or exploited, it can transfer funds from the user's account without the user having to sign any transaction. This is especially an issue if the protocol is upgradable, as it could be made to steal the user's approved funds at any time in the future.
+
+To avoid this, many protocols implement the `permit` flow, which uses a meta-transaction to let the user sign the approval off-chain, and pass it as an input to the `deposit` function, that way the user only has to send one transaction to make the deposit.
+
+
+
+This is a great improvement to infinite approvals, but still has its own sets of issues. For example, if the user is using a smart-contract wallet (such as Argent or Gnosis Safe), they will not be able to sign the permit message since the usual signature validation does not work well with contracts. [EIP-1271](https://eips.ethereum.org/EIPS/eip-1271) was proposed to give contracts a way to emulate this, but it is not widely adopted.
+
+Separately, the message that the user signs can seem opaque to the user and they might not understand what they are signing. This is generally an issue with `approve` as well.
+
+All of these issues have been discussed in the community for a while, and there are many proposals to solve them. However, none of them have been widely adopted - ERC20 is so commonly used and changing a standard is hard.
+
+## In Aztec
+
+Adopting ERC20 for Aztec is not as simple as it might seem because of private state.
+
+If you recall from the [Hybrid State model](../storage/state_model.md), private state is generally only known by its owner and those they have shared it with. Because it relies on secrets, private state might be "owned" by a contract, but it needs someone with knowledge of these secrets to actually spend it. You might see where this is going.
+
+If we were to implement the `approve` with an allowance in private, you might know the allowance, but unless you also know about the individual notes that make up the user's balances, it would be of no use to you! It is private after all. To spend the user's funds you would need to know the decryption key, see [keys for more](../accounts/keys.md).
+
+While this might sound limiting in what we can actually do, the main use of approvals have been for simplifying contract interactions that the user is doing. In the case of private transactions, this is executed on the user device, so it is not a blocker that the user need to tell the executor a secret - the user is the executor!
+
+### So what can we do?
+
+A few more things we need to remember about private execution:
+
+- To stay private, it all happens on the user device.
+- Because it happens on the user device, additional user-provided information can be passed to the contract mid-execution via an oracle call.
+
+For example, when executing a private transfer, the wallet will be providing the notes that the user wants to transfer through one of these oracle calls instead of the function arguments. This allows us to keep the function signature simple, and have the user provide the notes they want to transfer through the oracle call.
+
+For a transfer, it could be the notes provided, but we could also use the oracle to provide any type of data to the contract. So we can borrow the idea from `permit` that the user can provide a signature (or witness) to the contract which allows it to perform some action on behalf of the user.
+
+:::info Witness or signature?
+The doc refers to a witness instead of a signature because it is not necessarily a signature that is required to convince the account contract that we are allowed to perform the action. It depends on the contract implementation, and could also be a password or something similar.
+:::
+
+Since the witness is used to authenticate that someone can execute an action on behalf of the user, we call it an Authentication Witness or `AuthWit` for short. An "action", in this meaning, is a blob of data that specifies what call is approved, what arguments it is approved with, and the actor that is authenticated to perform the call.
+
+In practice, this blob is currently outlined to be a hash of the content mentioned, but it might change over time to make ["simulating simulations"](https://discourse.aztec.network/t/simulating-simulations/2218) easier.
+
+Outlined more clearly, we have the following, where the `H` is a SNARK-friendly hash function and `argsHash` is the hash of function arguments:
+
+```rust
+authentication_witness_action = H(
+ caller: AztecAddress,
+ contract: AztecAddress,
+ selector: Field,
+ argsHash: Field
+);
+```
+
+To outline an example as mentioned earlier, let's say that we have a token that implements `AuthWit` such that transfer funds from A to B is valid if A is doing the transfer, or there is a witness that authenticates the caller to transfer funds from A's account. While this specifies the spending rules, one must also know of the notes to use them for anything. This means that a witness in itself is only half the information.
+
+Creating the authentication action for the transfer of funds to the Defi contract would look like this:
+
+```rust
+action = H(defi, token, transfer_selector, H(alice_account, defi, 1000));
+```
+
+This can be read as "defi is allowed to call token transfer function with the arguments (alice_account, defi, 1000)".
+
+With this out of the way, let's look at how this would work in the graph below. The exact contents of the witness will differ between implementations as mentioned before, but for the sake of simplicity you can think of it as a signature, which the account contract can then use to validate if it really should allow the action.
+
+
+
+:::info Static call for AuthWit checks
+The call to the account contract for checking authentication should be a static call, meaning that it cannot change state or make calls that change state. If this call is not static, it could be used to re-enter the flow and change the state of the contract.
+:::
+
+:::danger Re-entries
+The above flow could be re-entered at token transfer. It is mainly for show to illustrate a logic outline.
+:::
+
+### What about public
+
+As noted earlier, we could use the ERC20 standard for public. But this seems like a waste when we have the ability to try righting some wrongs. Instead, we can expand our AuthWit scheme to also work in public. This is actually quite simple, instead of asking an oracle (which we can't do as easily because not private execution) we can just store the AuthWit in a shared registry, and look it up when we need it. While this needs the storage to be updated ahead of time (can be same tx), we can quite easily do so by batching the AuthWit updates with the interaction - a benefit of Account Contracts. A shared registry is used such that execution from the sequencers point of view will be more straight forward and predictable. Furthermore, since we have the authorization data directly in public state, if they are both set and unset (authorized and then used) in the same transaction, there will be no state effect after the transaction for the authorization which saves gas ⛽.
+
+
+
+### Replays
+
+To ensure that the authentication witness can only be used once, we can emit the action itself as a nullifier. This way, the authentication witness can only be used once. This is similar to how notes are used, and we can use the same nullifier scheme for this.
+
+Note however, that it means that the same action cannot be authenticated twice, so if you want to allow the same action to be authenticated multiple times, we should include a nonce in the arguments, such that the action is different each time.
+
+For the transfer, this could be done simply by appending a nonce to the arguments.
+
+```rust
+action = H(defi, token, transfer_selector, H(alice_account, defi, 1000, nonce));
+```
+
+Beware that the account contract will be unable to emit the nullifier since it is checked with a static call, so the calling contract must do it. This is similar to nonces in ERC20 tokens today. We provide a small library that handles this.
+
+### Differences to approval
+
+The main difference is that we are not setting up an allowance, but allowing the execution of a specific action. We decided on this option as the default since it is more explicit and the user can agree exactly what they are signing.
+
+Also, most uses of the approvals are for contracts where the following interactions are called by the user themselves, so it is not a big issue that they are not as easily "transferrable" as the `permit`s.
+
+:::note
+
+Authwits only work for a single user to authorize actions on contracts that their account is calling. You cannot authorize other users to take actions on your behalf.
+
+:::
+
+In order for another user to be able to take actions on your behalf, they would need access to your nullifier secret key so that they could nullify notes for you, but they should not have access to your nullifier secret key.
+
+### Other use-cases
+
+We don't need to limit ourselves to the `transfer` function, we can use the same scheme for any function that requires authentication. For example, for authenticating to burn, transferring assets from public to private, or to vote in a governance contract or perform an operation on a lending protocol.
+
+### Next Steps
+
+Check out the [developer documentation](../../../developers/guides/smart_contracts/writing_contracts/authwit.md) to see how to implement this in your own contracts.
diff --git a/docs/versioned_docs/version-v0.82.2-alpha-testnet.5/aztec/concepts/advanced/circuits/_category_.json b/docs/versioned_docs/version-v0.82.2-alpha-testnet.5/aztec/concepts/advanced/circuits/_category_.json
new file mode 100644
index 000000000000..611f5ed6919f
--- /dev/null
+++ b/docs/versioned_docs/version-v0.82.2-alpha-testnet.5/aztec/concepts/advanced/circuits/_category_.json
@@ -0,0 +1,6 @@
+{
+ "label": "Circuits",
+ "position": 3,
+ "collapsible": true,
+ "collapsed": true
+}
diff --git a/docs/versioned_docs/version-v0.82.2-alpha-testnet.5/aztec/concepts/advanced/circuits/index.md b/docs/versioned_docs/version-v0.82.2-alpha-testnet.5/aztec/concepts/advanced/circuits/index.md
new file mode 100644
index 000000000000..79f0a9aeaa18
--- /dev/null
+++ b/docs/versioned_docs/version-v0.82.2-alpha-testnet.5/aztec/concepts/advanced/circuits/index.md
@@ -0,0 +1,66 @@
+---
+title: Circuits
+sidebar_position: 2
+tags: [protocol, circuits]
+---
+
+Central to Aztec's operations are 'circuits' derived both from the core protocol and the developer-written Aztec.nr contracts.
+
+The core circuits enhance privacy by adding additional security checks and preserving transaction details - a characteristic Ethereum lacks.
+
+On this page, you’ll learn a bit more about these circuits and their integral role in promoting secure and efficient transactions within Aztec's privacy-centric framework.
+
+## Motivation
+
+In Aztec, circuits come from two sources:
+
+1. Core protocol circuits
+2. User-written circuits (written as Aztec.nr Contracts and deployed to the network)
+
+This page focuses on the core protocol circuits. These circuits check that the rules of the protocol are being adhered to.
+
+When a function in an Ethereum smart contract is executed, the EVM performs checks to ensure that Ethereum's transaction rules are being adhered-to correctly. Stuff like:
+
+- "Does this tx have a valid signature?"
+- "Does this contract address contain deployed code?"
+- "Does this function exist in the requested contract?"
+- "Is this function allowed to call this function?"
+- "How much gas has been paid, and how much is left?"
+- "Is this contract allowed to read/update this state variable?"
+- "Perform the state read / state write"
+- "Execute these opcodes"
+
+All of these checks have a computational cost, for which users are charged gas.
+
+Many existing L2s move this logic off-chain, as a way of saving their users gas costs, and as a way of increasing tx throughput.
+
+zk-Rollups, in particular, move these checks off-chain by encoding them in zk-S(N/T)ARK circuits. Rather than paying a committee of Ethereum validators to perform the above kinds of checks, L2 users instead pay a sequencer to execute these checks via the circuit(s) which encode them. The sequencer can then generate a zero-knowledge proof of having executed the circuit(s) correctly, which they can send to a rollup contract on Ethereum. The Ethereum validators then verify this zk-S(N/T)ARK. It often turns out to be much cheaper for users to pay the sequencer to do this, than to execute a smart contract on Ethereum directly.
+
+But there's a problem.
+
+Ethereum (and the EVM) doesn't have a notion of privacy.
+
+- There is no notion of a private state variable in the EVM.
+- There is no notion of a private function in the EVM.
+
+So users cannot keep private state variables' values private from Ethereum validators, nor from existing (non-private) L2 sequencers. Nor can users keep the details of which function they've executed private from validators or sequencers.
+
+How does Aztec add privacy?
+
+Well, we just encode _extra_ checks in our zk-Rollup's zk-SNARK circuits! These extra checks introduce the notions of private state and private functions, and enforce privacy-preserving constraints on every transaction being sent to the network.
+
+In other words, since neither the EVM nor other rollups have rules for how to preserve privacy, we've written a new rollup which introduces such rules, and we've written circuits to enforce those rules!
+
+What kind of extra rules / checks does a rollup need, to enforce notions of private states and private functions? Stuff like:
+
+- "Perform state reads and writes using new tree structures which prevent tx linkability" (see [indexed merkle tree](../storage/indexed_merkle_tree.mdx).
+- "Hide which function was just executed, by wrapping it in a zk-snark"
+- "Hide all functions which were executed as part of this tx's stack trace, by wrapping the whole tx in a zk-snark"
+
+## Aztec core protocol circuits
+
+So what kinds of core protocol circuits does Aztec have?
+
+### Kernel, Rollup, and Squisher Circuits
+
+The specs of these have recently been updated. Eg for squisher circuits since Honk and Goblin Plonk schemes are still being improved! But we'll need some extra circuit(s) to squish a Honk proof (as produced by the Root Rollup Circuit) into a Standard Plonk or Fflonk proof, for cheap verification on Ethereum.
diff --git a/docs/versioned_docs/version-v0.82.2-alpha-testnet.5/aztec/concepts/advanced/circuits/kernels/_category_.json b/docs/versioned_docs/version-v0.82.2-alpha-testnet.5/aztec/concepts/advanced/circuits/kernels/_category_.json
new file mode 100644
index 000000000000..aa6ead3d71df
--- /dev/null
+++ b/docs/versioned_docs/version-v0.82.2-alpha-testnet.5/aztec/concepts/advanced/circuits/kernels/_category_.json
@@ -0,0 +1,6 @@
+{
+ "label": "Kernel Circuits",
+ "position": 0,
+ "collapsible": true,
+ "collapsed": true
+}
diff --git a/docs/versioned_docs/version-v0.82.2-alpha-testnet.5/aztec/concepts/advanced/circuits/kernels/private_kernel.md b/docs/versioned_docs/version-v0.82.2-alpha-testnet.5/aztec/concepts/advanced/circuits/kernels/private_kernel.md
new file mode 100644
index 000000000000..10f8880efbf1
--- /dev/null
+++ b/docs/versioned_docs/version-v0.82.2-alpha-testnet.5/aztec/concepts/advanced/circuits/kernels/private_kernel.md
@@ -0,0 +1,14 @@
+---
+title: Private Kernel Circuit
+tags: [protocol, circuits]
+---
+
+This circuit is executed by the user, on their own device. This is to ensure private inputs to the circuit remain private!
+
+:::note
+
+**This is the only core protocol circuit which actually needs to be "zk" (zero-knowledge)!!!** That's because this is the only core protocol circuit which handles private data, and hence the only circuit for which proofs must not leak any information about witnesses! (The private data being handled includes: details of the Aztec.nr Contract function which has been executed; the address of the user who executed the function; the intelligible inputs and outputs of that function).
+
+Most so-called "zk-Rollups" do not make use of this "zero-knowledge" property. Their snarks are "snarks"; with no need for zero-knowledge, because they don't seek privacy; they only seek the 'succinct' computation-compression properties of snarks. Aztec's "zk-Rollup" actually makes use of "zero-knowledge" snarks. That's why we sometimes call it a "zk-zk-Rollup", or "_actual_ zk-Rollup".
+
+:::
diff --git a/docs/versioned_docs/version-v0.82.2-alpha-testnet.5/aztec/concepts/advanced/circuits/kernels/public_kernel.md b/docs/versioned_docs/version-v0.82.2-alpha-testnet.5/aztec/concepts/advanced/circuits/kernels/public_kernel.md
new file mode 100644
index 000000000000..a8b8945ffc0f
--- /dev/null
+++ b/docs/versioned_docs/version-v0.82.2-alpha-testnet.5/aztec/concepts/advanced/circuits/kernels/public_kernel.md
@@ -0,0 +1,6 @@
+---
+title: Public Kernel Circuit
+tags: [protocol, circuits]
+---
+
+This circuit is executed by a Sequencer, since only a Sequencer knows the current state of the [public data tree](../../../storage/state_model.md#public-state) at any time. A Sequencer might choose to delegate proof generation to the Prover pool.
diff --git a/docs/versioned_docs/version-v0.82.2-alpha-testnet.5/aztec/concepts/advanced/circuits/rollup_circuits/index.md b/docs/versioned_docs/version-v0.82.2-alpha-testnet.5/aztec/concepts/advanced/circuits/rollup_circuits/index.md
new file mode 100644
index 000000000000..db7a11e0b9bc
--- /dev/null
+++ b/docs/versioned_docs/version-v0.82.2-alpha-testnet.5/aztec/concepts/advanced/circuits/rollup_circuits/index.md
@@ -0,0 +1,17 @@
+---
+title: Rollup Circuits
+tags: [protocol, circuits]
+---
+
+The primary purpose of the Rollup Circuits is to 'squish' all of the many thousands of transactions in a rollup into a single SNARK, which can then be efficiently and verified on Ethereum.
+
+These circuits are executed by a Sequencer, since their primary role is to order transactions. A Sequencer might choose to delegate proof generation to the Prover pool.
+
+The way we 'squish' all this data is in a 'binary tree of proofs' topology.
+
+> Example: If there were 16 txs in a rollup, we'd arrange the 16 kernel proofs into 8 pairs and merge each pair into a single proof (using zk-snark recursion techniques), resulting in 8 output proofs. We'd then arrange those 8 proofs into pairs and again merge each pair into a single proof, resulting in 4 output proofs. And so on until we'd be left with a single proof, which represents the correctness of the original 16 txs.
+> This 'binary tree of proofs' topology allows proof generation to be greatly parallelized across prover instances. Each layer of the tree can be computed in parallel. Or alternatively, subtrees can be coordinated to be computed in parallel.
+
+> Note: 'binary tree of proofs' is actually an oversimplification. The Rollup Circuits are designed so that a Sequencer can actually deviate from a neat, symmetrical tree, for the purposes of efficiency, and instead sometimes create wonky trees.
+
+Some of the Rollup Circuits also do some protocol checks and computations, for efficiency reasons. We might rearrange which circuit does what computation, as we discover opportunities for efficiency.
diff --git a/docs/versioned_docs/version-v0.82.2-alpha-testnet.5/aztec/concepts/advanced/index.md b/docs/versioned_docs/version-v0.82.2-alpha-testnet.5/aztec/concepts/advanced/index.md
new file mode 100644
index 000000000000..9d50557095c8
--- /dev/null
+++ b/docs/versioned_docs/version-v0.82.2-alpha-testnet.5/aztec/concepts/advanced/index.md
@@ -0,0 +1,12 @@
+---
+title: Advanced Concepts
+sidebar_position: 8
+tags: [protocol]
+---
+
+In this section, you'll learn about the more advanced concepts of the Aztec Network. It is not required to understand these in order to start building on Aztec.
+
+import DocCardList from '@theme/DocCardList';
+
+
+
diff --git a/docs/versioned_docs/version-v0.82.2-alpha-testnet.5/aztec/concepts/advanced/storage/_category_.json b/docs/versioned_docs/version-v0.82.2-alpha-testnet.5/aztec/concepts/advanced/storage/_category_.json
new file mode 100644
index 000000000000..537ab73d1a05
--- /dev/null
+++ b/docs/versioned_docs/version-v0.82.2-alpha-testnet.5/aztec/concepts/advanced/storage/_category_.json
@@ -0,0 +1,6 @@
+{
+ "label": "Advanced Storage Concepts",
+ "position": 1,
+ "collapsible": true,
+ "collapsed": true
+}
diff --git a/docs/versioned_docs/version-v0.82.2-alpha-testnet.5/aztec/concepts/advanced/storage/indexed_merkle_tree.mdx b/docs/versioned_docs/version-v0.82.2-alpha-testnet.5/aztec/concepts/advanced/storage/indexed_merkle_tree.mdx
new file mode 100644
index 000000000000..2452782e609c
--- /dev/null
+++ b/docs/versioned_docs/version-v0.82.2-alpha-testnet.5/aztec/concepts/advanced/storage/indexed_merkle_tree.mdx
@@ -0,0 +1,417 @@
+---
+title: Indexed Merkle Tree (Nullifier Tree)
+tags: [storage, concepts, advanced]
+sidebar_position: 2
+---
+
+import Image from "@theme/IdealImage";
+
+## Overview
+
+This article will introduce the concept of an indexed merkle tree, and how it can be used to improve the performance of nullifier trees in circuits.
+
+This page will answer:
+
+- Why we need nullifier trees at all
+- How indexed merkle trees work
+- How they can be used for membership exclusion proofs
+- How they can leverage batch insertions
+- Tradeoffs of using indexed merkle trees
+
+The content was also covered in a presentation for the [Privacy + Scaling Explorations team at the Ethereum Foundation](https://pse.dev/).
+
+
+
+## Primer on Nullifier Trees
+
+Currently the only feasible way to get privacy in public blockchains is via a UTXO model. In this model, state is stored in encrypted UTXO's in merkle trees. However, to maintain privacy, state cannot be updated. The very act of performing an update leaks information. In order to simulate "updating" the state, we "destroy" old UTXO's and create new ones for each state update. Resulting in a merkle tree that is append-only.
+
+A classic merkle tree:
+
+
+
+To destroy state, the concept of a "nullifier" tree is introduced. Typically represented as a sparse Merkle Tree, the structure is utilized to store notes deterministically linked to values in the append-only tree of encrypted notes.
+
+A sparse merkle tree (not every leaf stores a value):
+
+
+
+In order to spend / modify a note in the private state tree, one must create a nullifier for it, and prove that the nullifier does not already exist in the nullifier tree. As nullifier trees are modeled as sparse merkle trees, non membership checks are (conceptually) trivial.
+
+Data is stored at the leaf index corresponding to its value. E.g. if I have a sparse tree that can contain $2^{256}$ values and want to prove non membership of the value $2^{128}$. I can prove via a merkle membership proof that $tree\_values[2^{128}] = 0$, conversely if I can prove that $tree\_values[2^{128}] == 1$ I can prove that the item exists.
+
+## Problems introduced by using Sparse Merkle Trees for Nullifier Trees
+
+While sparse Merkle Trees offer a simple and elegant solution, their implementation comes with some drawbacks. A sparse nullifier tree must have an index for $e \in \mathbb{F}_p$, which for the bn254 curve means that the sparse tree will need to have a depth of 254.
+If you're familiar with hashing in circuits the alarm bells have probably started ringing. A tree of depth 254 means 254 hashes per membership proof.
+In routine nullifier insertions, a non membership check for a value is performed, then an insertion of said value. This amounts to two trips from leaf to root, hashing all the way up. This means that there are $254*2$ hashes per tree insertion. As the tree is sparse, insertions are random and must be performed in sequence. This means the number of hashes performed in the circuit scales linearly with the number of nullifiers being inserted. As a consequence number of constraints in a rollup circuit (where these checks are performed) will sky rocket, leading to long rollup proving times.
+
+## Indexed Merkle Tree Constructions
+
+As it turns out, we can do better. [This paper](https://eprint.iacr.org/2021/1263.pdf) (page 6) introduces the idea of an indexed merkle tree. A Merkle Tree that allows us to perform efficient non-membership proofs. It achieves this by extending each node to include a specialized data structure. Each node not only stores some value $v \in \mathbb{F}_p$ but also some pointers to the leaf with the next higher value. The data structure is as follows:
+
+$$
+\textsf{leaf} = \{v, i_{\textsf{next}}, v_{\textsf{next}}\}.
+$$
+
+Based on the tree's insertion rules, we can assume that there are no leaves in the tree that exist between the range $(v, v_{\textsf{next}})$.
+
+More simply put, the merkle tree pretty much becomes a linked list of increasing size, where once inserted the pointers at a leaf can change, but the nullifier value cannot.
+
+Despite being a minor modification, the performance implications are massive. We no longer position leaves in place $(index == value)$ therefore we no longer need a deep tree, rather we can use an arbitrarily small tree (32 levels should suffice). Some quick back of the napkin maths can show that insertions can be improved by a factor of 8 $(256 / 32)$.
+
+_For the remainder of this article I will refer to the node that provides the non membership check as a "low nullifier"._
+
+The insertion protocol is described below:
+
+1. Look for a nullifier's corresponding low_nullifier where:
+
+ $$
+ low\_nullifier_{\textsf{next\_value}} > new\_nullifier
+ $$
+
+ > if $new\_nullifier$ is the largest use the leaf:
+
+ $$
+ low\_nullifier_{\textsf{next\_value}} == 0
+ $$
+
+2. Perform membership check of the low nullifier.
+3. Perform a range check on the low nullifier's value and next_value fields:
+
+$$
+new\_nullifier > low\_nullifier_{\textsf{value}} \: \&\& \: ( new\_nullifier < low\_nullifier_{\textsf{next\_value}} \: || \: low\_nullifier_{\textsf{next\_value}} == 0 )
+$$
+
+4. Update the low nullifier pointers
+
+ $$
+ low\_nullifier_{\textsf{next\_index}} = new\_insertion\_index
+ $$
+
+ $$
+ low\_nullifier_{\textsf{next\_value}} = new\_nullifier
+ $$
+
+5. Perform insertion of new updated low nullifier (yields new root)
+6. Update pointers on new leaf. Note: low_nullifier is from before update in step 4
+
+$$
+new\_nullifier\_leaf_{\textsf{value}} = new\_nullifier
+$$
+
+$$
+new\_nullifier\_leaf_{\textsf{next\_value}} = low\_nullifier_{\textsf{next\_value}}
+$$
+
+$$
+new\_nullifier\_leaf_{\textsf{next\_index}} = low\_nullifier_{\textsf{next\_index}}
+$$
+
+7. Perform insertion of new leaf (yields new root)
+
+#### Number of insertion constraints, in total:
+
+- `3n` hashes of 2 field elements (where `n` is the height of the tree).
+- `3` hashes of 3 field elements.
+- `2` range checks.
+- A handful of equality constraints.
+
+**Special cases**
+You'll notice at step 3 the $low\_nullifier_{\textsf{next\_value}}$ can be 0. This is a special case as if a value is the max, it will not point to anything larger (as it does not exist). Instead it points to zero. By doing so we close the loop, so we are always inserting into a ring, if we could insert outside the ring we could cause a split.
+
+A visual aid for insertion is presented below:
+
+1. Initial state
+
+
+
+2. Add a new value $v=30$
+
+
+
+3. Add a new value $v=10$
+
+
+
+4. Add a new value $v=20$
+
+
+
+5. Add a new value $v=50$
+
+
+
+By studying the transitions between each diagram you can see how the pointers are updated between each insertion.
+
+A further implementation detail is that we assume the first 0 node is pre-populated. As a consequence, the first insertion into the tree will be made into the second index.
+
+### Non-membership proof
+
+Suppose we want to show that the value `20` doesn't exist in the tree. We just reveal the leaf which 'steps over' `20`. I.e. the leaf whose value is less than `20`, but whose next value is greater than `20`. Call this leaf the `low_nullifier`.
+
+- hash the low nullifier: $low\_nullifier = h(10, 1, 30)$.
+- Prove the low leaf exists in the tree: `n` hashes.
+- Check the new value 'would have' belonged in the range given by the low leaf: `2` range checks.
+ - If ($low\_nullifier_{\textsf{next\_index}} == 0$):
+ - Special case, the low leaf is at the very end, so the new_value must be higher than all values in the tree:
+ - $assert(low\_nullifier_{\textsf{value}} < new\_value_{\textsf{value}})$
+ - Else:
+ - $assert(low\_nullifier_{\textsf{value}} < new\_value_{\textsf{value}})$
+ - $assert(low\_nullifier_{\textsf{next\_value}} > new\_value_{\textsf{value}})$
+
+This is already a massive performance improvement, however we can go further, as this tree is not sparse. We can perform batch insertions.
+
+## Batch insertions
+
+As our nullifiers will all be inserted deterministically (append only), we can insert entire subtrees into our tree rather than appending nodes one by one, this optimization is globally applied to append only merkle trees. I wish this was it, but for every node we insert, we must also update low nullifier pointers, this introduces a bit of complexity while performing subtree insertions, as the low nullifier itself may exist within the subtree we are inserting - we must be careful how we prove these sort of insertions are correct (addressed later).
+We must update all of the impacted low nullifiers before.
+
+First we will go over batch insertions in an append only merkle tree.
+
+1. First we prove that the subtree we are inserting into consists of all empty values.
+1. We work out the root of an empty subtree, and perform an inclusion proof for an empty root, which proves that there is nothing within our subtree.
+1. We re-create our subtree within our circuit.
+1. We then use the same sibling path the get the new root of the tree after we insert the subtree.
+
+In the following example we insert a subtree of size 4 into our tree at step 4. above. Our subtree is greyed out as it is "pending".
+
+**Legend**:
+
+- Green: New Inserted Value
+- Orange: Low Nullifier
+
+**Example**
+
+1. Prepare to insert subtree $[35,50,60,15]$
+
+
+
+2. Update low nullifier for new nullifier $35$.
+
+
+
+3. Update low nullifier for new nullifier $50$. (Notice how the low nullifier exists within our pending insertion subtree, this becomes important later).
+
+
+
+4. Update low nullifier for new nullifier $60$.
+
+
+
+5. Update low nullifier for new nullifier $15$.
+
+
+
+6. Update pointers for new nullifier $15$.
+
+
+
+7. Insert subtree.
+
+
+
+### Performance gains from subtree insertion
+
+Let's go back over the numbers:
+Insertions into a sparse nullifier tree involve 1 non membership check (254 hashes) and 1 insertion (254 hashes). If we were performing insertion for 4 values that would entail 2032 hashes.
+In the depth 32 indexed tree construction, each subtree insertion costs 1 non membership check (32 hashes), 1 pointer update (32 hashes) for each value as well as the cost of constructing and inserting a subtree (~67 hashes. Which is 327 hashes, an incredible efficiency increase.)
+
+_I am ignoring range check constraint costs as they a negligible compared to the costs of a hash_.
+
+## Performing subtree insertions in a circuit context
+
+Some fun engineering problems occur when we inserting a subtree in circuits when the low nullifier for a value exists within the subtree we are inserting. In this case we cannot perform a non membership check against the root of the tree, as our leaf that we would use for non membership has NOT yet been inserted into the tree. We need another protocol to handle such cases, we like to call these "pending" insertions.
+
+**Circuit Inputs**
+
+- `new_nullifiers`: `fr[]`
+- `low_nullifier_leaf_preimages`: `tuple of {value: fr, next_index: fr, next_value: fr}`
+- `low_nullifier_membership_witnesses`: A sibling path and a leaf index of low nullifier
+- `current_nullifier_tree_root`: Current root of the nullifier tree
+- `next_insertion_index`: fr, the tip our nullifier tree
+- `subtree_insertion_sibling_path`: A sibling path to check our subtree against the root
+
+Protocol without batched insertion:
+Before adding a nullifier to the pending insertion tree, we check for its non membership using the previously defined protocol by consuming the circuit inputs:
+Pseudocode:
+
+```cpp
+
+auto empty_subtree_hash = SOME_CONSTANT_EMPTY_SUBTREE;
+auto pending_insertion_subtree = [];
+auto insertion_index = inputs.next_insertion_index;
+auto root = inputs.current_nullifier_tree_root;
+
+// Check nothing exists where we would insert our subtree
+assert(membership_check(root, empty_subtree_hash, insertion_index >> subtree_depth, inputs.subtree_insertion_sibling_path));
+
+for (i in len(new_nullifiers)) {
+ auto new_nullifier = inputs.new_nullifiers[i];
+ auto low_nullifier_leaf_preimage = inputs.low_nullifier_leaf_preimages[i];
+ auto low_nullifier_membership_witness = inputs.low_nullifier_membership_witnesses[i];
+
+ // Membership check for low nullifier
+ assert(perform_membership_check(root, hash(low_nullifier_leaf_preimage), low_nullifier_membership_witness));
+
+ // Range check low nullifier against new nullifier
+ assert(new_nullifier < low_nullifier_leaf_preimage.next_value || low_nullifier_leaf.next_value == 0);
+ assert(new_nullifier > low_nullifier_leaf_preimage.value);
+
+ // Update new nullifier pointers
+ auto new_nullifier_leaf = {
+ .value = new_nullifier,
+ .next_index = low_nullifier_preimage.next_index,
+ .next_value = low_nullifier_preimage.next_value
+ };
+
+ // Update low nullifier pointers
+ low_nullifier_preimage.next_index = next_insertion_index;
+ low_nullifier_preimage.next_value = new_nullifier;
+
+ // Update state vals for next iteration
+ root = update_low_nullifier(low_nullifier, low_nullifier_membership_witness);
+ pending_insertion_subtree.push(new_nullifier_leaf);
+ next_insertion_index += 1;
+}
+
+// insert subtree
+root = insert_subtree(root, inputs.next_insertion_index >> subtree_depth, pending_insertion_subtree);
+
+```
+
+From looking at the code above we can probably deduce why we need pending insertion. If the low nullifier does not yet exist in the tree, all of our membership checks will fail, we cannot produce a non membership proof.
+
+To perform batched insertions, our circuit must keep track of all values that are pending insertion.
+
+- If the `low_nullifier_membership_witness` is identified to be nonsense ( all zeros, or has a leaf index of -1 ) we will know that this is a pending low nullifier read request and we will have to look within our pending subtree for the nearest low nullifier.
+ - Loop back through all "pending_insertions"
+ - If the pending insertion value is lower than the nullifier we are trying to insert
+ - If the pending insertion value is NOT found, then out circuit is invalid and should self abort.
+
+The updated pseudocode is as follows:
+
+```cpp
+
+auto empty_subtree_hash = SOME_CONSTANT_EMPTY_SUBTREE;
+auto pending_insertion_subtree = [];
+auto insertion_index = inputs.next_insertion_index;
+auto root = inputs.current_nullifier_tree_root;
+
+// Check nothing exists where we would insert our subtree
+assert(membership_check(root, empty_subtree_hash, insertion_index >> subtree_depth, inputs.subtree_insertion_sibling_path));
+
+for (i in len(new_nullifiers)) {
+ auto new_nullifier = inputs.new_nullifiers[i];
+ auto low_nullifier_leaf_preimage = inputs.low_nullifier_leaf_preimages[i];
+ auto low_nullifier_membership_witness = inputs.low_nullifier_membership_witnesses[i];
+
+ if (low_nullifier_membership_witness is garbage) {
+ bool matched = false;
+
+ // Search for the low nullifier within our pending insertion subtree
+ for (j in range(0, i)) {
+ auto pending_nullifier = pending_insertion_subtree[j];
+
+ if (pending_nullifier.is_garbage()) continue;
+ if (pending_nullifier[j].value < new_nullifier && (pending_nullifier[j].next_value > new_nullifier || pending_nullifier[j].next_value == 0)) {
+
+ // bingo
+ matched = true;
+
+ // Update pointers
+ auto new_nullifier_leaf = {
+ .value = new_nullifier,
+ .next_index = pending_nullifier.next_index,
+ .next_value = pending_nullifier.next_value
+ }
+
+ // Update pending subtree
+ pending_nullifier.next_index = insertion_index;
+ pending_nullifier.next_value = new_nullifier;
+
+ pending_insertion_subtree.push(new_nullifier_leaf);
+ break;
+ }
+ }
+
+ // could not find a matching low nullifier in the pending insertion subtree
+ assert(matched);
+
+ } else {
+ // Membership check for low nullifier
+ assert(perform_membership_check(root, hash(low_nullifier_leaf_preimage), low_nullifier_membership_witness));
+
+ // Range check low nullifier against new nullifier
+ assert(new_nullifier < low_nullifier_leaf_preimage.next_value || low_nullifier_leaf.next_value == 0);
+ assert(new_nullifier > low_nullifier_leaf_preimage.value);
+
+ // Update new nullifier pointers
+ auto new_nullifier_leaf = {
+ .value = new_nullifier,
+ .next_index = low_nullifier_preimage.next_index,
+ .next_value = low_nullifier_preimage.next_value
+ };
+
+ // Update low nullifier pointers
+ low_nullifier_preimage.next_index = next_insertion_index;
+ low_nullifier_preimage.next_value = new_nullifier;
+
+ // Update state vals for next iteration
+ root = update_low_nullifier(low_nullifier, low_nullifier_membership_witness);
+
+ pending_insertion_subtree.push(new_nullifier_leaf);
+
+ }
+
+ next_insertion_index += 1;
+}
+
+// insert subtree
+root = insert_subtree(root, inputs.next_insertion_index >> subtree_depth, pending_insertion_subtree);
+
+```
+
+#### Drawbacks
+
+Despite offering large performance improvements within the circuits, these come at the expense of increased computation / storage performed by the node. To provide a non membership proof we must find the "low nullifier" for it. In a naive implementation this entails a brute force search against the existing nodes in the tree. This performance can be increased by the node maintaining a sorted data structure of existing nullifiers, increasing its storage footprint.
+
+#### Closing Notes
+
+We have been working with these new trees in order to reduce the proving time for our rollups in Aztec, however we think EVERY protocol leveraging nullifier trees should know about these trees as their performance benefit is considerable.
diff --git a/docs/versioned_docs/version-v0.82.2-alpha-testnet.5/aztec/concepts/advanced/storage/note_discovery.md b/docs/versioned_docs/version-v0.82.2-alpha-testnet.5/aztec/concepts/advanced/storage/note_discovery.md
new file mode 100644
index 000000000000..c916d6c0c40c
--- /dev/null
+++ b/docs/versioned_docs/version-v0.82.2-alpha-testnet.5/aztec/concepts/advanced/storage/note_discovery.md
@@ -0,0 +1,45 @@
+---
+title: Note Discovery
+tags: [storage, concepts, advanced, notes]
+sidebar_position: 3
+---
+
+Note discovery refers to the process of a user identifying and decrypting the [encrypted notes](../../storage/notes.md) that belong to them.
+
+## Existing solutions
+
+### Brute force / trial-decrypt
+
+In some existing protocols, the user downloads all possible notes and tries to decrypt each one. If the decryption succeeds, the user knows they own that note. However, this approach becomes exponentially more expensive as the network grows and more notes are created. It also introduces a third-party server to gather and trial-decrypt notes, which is an additional point of failure. Note that this note discovery technique is not currently implemented for Aztec.
+
+### Off-chain communication
+
+Another proposed solution is having the sender give the note content to the recipient via some off-chain communication. While it solves the brute force issue, it introduces reliance on side channels which we don't want in a self-sufficient network. This option incurs lower transaction costs because fewer logs needs to be posted on-chain. Aztec apps will be able to choose this method if they wish.
+
+## Aztec's solution: Note tagging
+
+Aztec introduces an approach that allows users to identify which notes are relevant to them by having the sender *tag* the log in which the note is created. This is known as note tagging. The tag is generated in such a way that only the sender and recipient can identify it.
+
+### How it works
+
+#### Every log has a tag
+
+In Aztec, each emitted log is an array of fields, eg `[x, y, z]`. The first field (`x`) is a *tag* field used to index and identify logs. The Aztec node exposes an API `getLogsByTags()` that can retrieve logs matching specific tags.
+
+#### Tag generation
+
+The sender and recipient share a predictable scheme for generating tags. The tag is derived from a shared secret and an index (a shared counter that increments each time the sender creates a note for the recipient).
+
+#### Discovering notes in Aztec contracts
+
+This note discovery scheme will be implemented by Aztec contracts rather than by the PXE. This means that users can update or use other types of note discovery to suit their needs.
+
+### Limitations
+
+- **You cannot receive notes from an unknown sender**. If you do not know the sender’s address, you cannot create the shared secret, and therefore cannot create the note tag. There are potential ways around this, such as senders adding themselves to a contract and then recipients searching for note tags from all the senders in the contract. However this is out of scope at this point in time.
+
+- **Index synchronization can be complicated**. If transactions are reverted or mined out of order, the recipient may stop searching after receiving a tag with the latest index they expect. This means they can miss notes that belong to them. We cannot redo a reverted a transaction with the same index, because then the tag will be the same and the notes will be linked, leaking privacy. We can solve this by widening the search window (not too much, or it becomes brute force) and implementing a few restrictions on sending notes. A user will not be able to send a large amount of notes from the same contract to the same recipient within a short time frame.
+
+## Further reading
+
+- [How partial notes are discovered](./partial_notes.md#note-discovery)
\ No newline at end of file
diff --git a/docs/versioned_docs/version-v0.82.2-alpha-testnet.5/aztec/concepts/advanced/storage/partial_notes.md b/docs/versioned_docs/version-v0.82.2-alpha-testnet.5/aztec/concepts/advanced/storage/partial_notes.md
new file mode 100644
index 000000000000..2c67336cc001
--- /dev/null
+++ b/docs/versioned_docs/version-v0.82.2-alpha-testnet.5/aztec/concepts/advanced/storage/partial_notes.md
@@ -0,0 +1,213 @@
+---
+title: Partial Notes [OUTDATED DOCS]
+description: Describes how partial notes are used in Aztec
+tags: [notes, storage]
+sidebar_position: 4
+---
+
+:::warning OUTDATED DOCUMENTATION
+This documentation is outdated and may not reflect the current state of the Aztec protocol. This is to be updated when tackling [this issue](https://github.com/AztecProtocol/aztec-packages/issues/12414).
+TODO(#12414): UPDATE THIS
+:::
+
+Partial notes are a concept that allows users to commit to an encrypted value, and allows a counterparty to update that value without knowing the specific details of the encrypted value.
+
+## Use cases
+
+Why is this useful?
+
+Consider the case where a user wants to pay for a transaction fee, using a fee-payment contract and they want to do this privately. They can't be certain what the transaction fee will be because the state of the network will have progressed by the time the transaction is processed by the sequencer, and transaction fees are dynamic. So the user can commit to a value for the transaction fee, publicly post this commitment, the fee payer (aka paymaster) can update the public commitment, deducting the final cost of the transaction from the commitment and returning the unused value to the user.
+
+So, in general, the user is:
+
+- doing some computation in private
+- encrypting/compressing that computation with a point
+- passing that point as an argument to a public function
+
+And the paymaster is:
+
+- updating that point in public
+- treating/emitting the result(s) as a note hash(es)
+
+The idea of committing to a value and allowing a counterparty to update that value without knowing the specific details of the encrypted value is a powerful concept that can be used in many different applications. For example, this could be used for updating timestamp values in private, without revealing the exact timestamp, which could be useful for many defi applications.
+
+To do this, we leverage the following properties of elliptic curve operations:
+
+1. `x_1 * G + x_2 * G` equals `(x_1 + x_2) * G` and
+2. `f(x) = x * G` being a one-way function.
+
+Property 1 allows us to be continually adding to a point on elliptic curve and property 2 allows us to pass the point to a public realm without revealing anything about the point preimage.
+
+### DEXes
+
+Currently private swaps require 2 transactions. One to start the swap and another to claim the swapped token from the DEX. With partial notes, you can create a note with zero value for the received amount and have another party complete it later from a public function, with the final swapped amount. This reduces the number of transactions needed to swap privately.
+
+Comparing to the flow above, the user is doing some private computation to stage the swap, encrypting the computation with a point and passing the point as an argument to a public function. Then another party is updating that point in public and emitting the result as a note hash for the user doing the swap.
+
+### Lending
+
+A similar pattern can be used for a lending protocol. The user can deposit a certain amount of a token to the lending contract and create a partial note for the borrowed token that will be completed by another party. This reduces the number of required transactions from 2 to 1.
+
+### Private Refunds
+
+Private transaction refunds from paymasters are the original inspiration for partial notes. Without partial notes, you have to claim your refund note. But the act of claiming itself needs gas! What if you overpaid fees on the refund tx? Then you have another 2nd order refund that you need to claim. This creates a never ending cycle! Partial notes allow paymasters to refund users without the user needing to claim the refund.
+
+Before getting to partial notes let's recap what is the flow of standard notes.
+
+## Note lifecycle recap
+
+The standard note flow is as follows:
+
+1. Create a note in your contract,
+2. compute the note hash,
+3. emit the note hash,
+4. emit the note (note hash preimage) as an encrypted note log,
+5. sequencer picks up the transaction, includes it in a block (note hash gets included in a note hash tree) and submits the block on-chain,
+6. nodes and PXEs following the network pick up the new block, update its internal state and if they have accounts attached they search for relevant encrypted note logs,
+7. if a users PXE finds a log it stores the note in its database,
+8. later on when we want to spend a note, a contract obtains it via oracle and stores a note hash read request within the function context (note hash read request contains a newly computed note hash),
+9. based on the note and a nullifier secret key a nullifier is computed and emitted,
+10. protocol circuits check that the note is a valid note by checking that the note hash read request corresponds to a real note in the note hash tree and that the new nullifier does not yet exist in the nullifier tree,
+11. if the conditions in point 10. are satisfied the nullifier is inserted into the nullifier tree and the note is at the end of its life.
+
+Now let's do the same for partial notes.
+
+## Partial notes life cycle
+
+1. Create a partial/unfinished note in a private function of your contract --> partial here means that the values within the note are not yet considered finalized (e.g. `amount` in a `UintNote`),
+2. compute a note hiding point of the partial note using a multi scalar multiplication on an elliptic curve. For `UintNote` this would be done as `G_amt * amount0 + G_npk * npk_m_hash + G_rnd * randomness + G_slot * slot`, where each `G_` is a generator point for a specific field in the note,
+3. emit partial note log,
+4. pass the note hiding point to a public function,
+5. in a public function determine the value you want to add to the note (e.g. adding a value to an amount) and add it to the note hiding point (e.g. `NOTE_HIDING_POINT + G_amt * amount`),
+6. get the note hash by finalizing the note hiding point (the note hash is the x coordinate of the point),
+7. emit the note hash,
+8. emit the value added to the note in public as an unencrypted log (PXE then matches it with encrypted partial note log emitted from private),
+9. from this point on the flow of partial notes is the same as for normal notes.
+
+### Private Fee Payment Example
+
+Alice wants to use a fee-payment contract for fee abstraction, and wants to use private balances. That is, she wants to pay the FPC (fee-payment contract) some amount in an arbitrary token privately (e.g. a stablecoin), and have the FPC pay the `transaction_fee`.
+
+Alice also wants to get her refund privately in the same token (e.g. the stablecoin).
+
+The trouble is that the FPC doesn't know if Alice is going to run public functions, in which case it doesn't know what refund is due until the end of public execution.
+
+And we can't use the normal flow to create a transaction fee refund note for Alice, since that demands we have Alice's address in public.
+
+So we define a new type of note with its `compute_note_hiding_point` defined as:
+
+$$
+\text{amount}*G_{amount} + \text{address}*G_{address} + \text{randomness}*G_{randomness} + \text{slot}*G_{slot}
+$$
+
+Suppose Alice is willing to pay up to a set amount in stablecoins for her transaction. (Note, this amount gets passed into public so that when `transaction_fee` is known the FPC can verify that it isn't losing money. Wallets are expected to choose common values here, e.g. powers of 10).
+
+Then we can subtract the set amount from Alice's balance of private stablecoins, and create a point in private like:
+
+$$
+P_a' := \text{alice address}*G_{address} + \text{rand}_a*G_{randomness} + \text{Alice note slot}*G_{slot}
+$$
+
+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})$.
+
+:::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/v0.82.2/noir-projects/noir-contracts/contracts/token_contract/src/main.nr#L491) of `setup_refund` function)
+:::
+
+$$
+P_b' := \text{bob address}*G_{address} + \text{rand}_b*G_{randomness} + \text{Bob note slot}*G_{slot}
+$$
+
+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} - \text{transaction fee}) * G_{amount}$
+
+Then, we arrive at the point that corresponds to the complete note by
+
+$$
+P_a := P_a'+P_{refund} = (\text{funded amount} - \text{transaction fee})*G_{amount} + \text{alice address}*G_{address} +\text{rand}_a*G_{randomness} + \text{Alice note slot}*G_{slot}
+$$
+
+$$
+P_b := P_b'+P_{fee} = (\text{transaction fee})*G_{amount} + \text{bob address}*G_{address} +\text{rand}_b*G_{randomness} + \text{Bob note slot}*G_{slot}
+$$
+
+Then we just emit `P_a.x` and `P_b.x` as a note hashes, and we're done!
+
+### Private Fee Payment Implementation
+
+TODO(#12414): `setup_refund` no longer exists.
+
+We can see the complete implementation of creating and completing partial notes in an Aztec contract in the `setup_refund` and `complete_refund` functions.
+
+#### `fee_entrypoint_private`
+
+```rust title="fee_entrypoint_private" showLineNumbers
+#[private]
+fn fee_entrypoint_private(max_fee: u128, nonce: Field) {
+ let accepted_asset = storage.config.read().accepted_asset;
+
+ let user = context.msg_sender();
+ let token = Token::at(accepted_asset);
+
+ // TODO(#10805): Here we should check that `max_fee` converted to fee juice is enough to cover the tx
+ // fee juice/mana/gas limit. Currently the fee juice/AA exchange rate is fixed 1:1.
+
+ // Pull the max fee from the user's balance of the accepted asset to the public balance of this contract.
+ token.transfer_to_public(user, context.this_address(), max_fee, nonce).call(&mut context);
+
+ // Prepare a partial note for the refund for the user.
+ let partial_note = token.prepare_private_balance_increase(user, user).call(&mut context);
+
+ // Set a public teardown function in which the refund will be paid back to the user by finalizing the partial note.
+ FPC::at(context.this_address())
+ ._complete_refund(accepted_asset, partial_note, max_fee)
+ .set_as_teardown(&mut context);
+
+ // Set the FPC as the fee payer of the tx.
+ context.set_as_fee_payer();
+}
+```
+> Source code: noir-projects/noir-contracts/contracts/fpc_contract/src/main.nr#L78-L103
+
+
+The `fee_entrypoint_private` function sets the `complete_refund` function to be called at the end of the public function execution (`set_public_teardown_function`).
+This ensures that the refund partial note will be completed for the user.
+
+#### `complete_refund`
+
+```rust title="complete_refund" showLineNumbers
+#[public]
+#[internal]
+fn _complete_refund(
+ accepted_asset: AztecAddress,
+ partial_note: PartialUintNote,
+ max_fee: u128,
+) {
+ let tx_fee = safe_cast_to_u128(context.transaction_fee());
+
+ // 1. Check that user funded the fee payer contract with at least the transaction fee.
+ // TODO(#10805): Nuke this check once we have a proper max_fee check in the fee_entrypoint_private.
+ assert(max_fee >= tx_fee, "max fee not enough to cover tx fee");
+
+ // 2. Compute the refund amount as the difference between funded amount and the tx fee.
+ // TODO(#10805): Introduce a real exchange rate
+ let refund_amount = max_fee - tx_fee;
+
+ Token::at(accepted_asset).finalize_transfer_to_private(refund_amount, partial_note).call(
+ &mut context,
+ );
+}
+```
+> Source code: noir-projects/noir-contracts/contracts/fpc_contract/src/main.nr#L107-L129
+
+
+## Note discovery
+
+Note discovery is detailed [here](./note_discovery.md). Partial notes are handled very similarly, where the partial note creator will add a tag to the beginning of the encrypted log, like a regular note, but the contract knows that it is a partial note and is missing a public component. The contract puts the unfinished note and the public log that will be emitted to complete the note into the PXE's database. When the public log is emitted, the recipient's PXE has all of the info about the note and the partial note is completed. This method of discovery allows partial notes to be started and completed in separate transactions.
+
+## Future work
+
+This pattern of making public commitments to notes that can be modified by another party, privately, can be generalized to work with different kinds of applications. The Aztec labs team is working on adding libraries and tooling to make this easier to implement in your own contracts.
diff --git a/docs/versioned_docs/version-v0.82.2-alpha-testnet.5/aztec/concepts/advanced/storage/storage_slots.md b/docs/versioned_docs/version-v0.82.2-alpha-testnet.5/aztec/concepts/advanced/storage/storage_slots.md
new file mode 100644
index 000000000000..3b86951dea8f
--- /dev/null
+++ b/docs/versioned_docs/version-v0.82.2-alpha-testnet.5/aztec/concepts/advanced/storage/storage_slots.md
@@ -0,0 +1,60 @@
+---
+title: Storage Slots
+tags: [storage, concepts, advanced]
+sidebar_position: 1
+---
+
+# Storage Slots
+
+## Public State Slots
+
+As mentioned in [State Model](../../storage/state_model.md), Aztec public state behaves similarly to public state on Ethereum from the point of view of the developer. Behind the scenes however, the storage is managed differently. As mentioned, public state has just one large sparse tree in Aztec - so we silo slots of public data by hashing it together with its contract address.
+
+The mental model is that we have a key-value store, where the siloed slot is the key, and the value is the data stored in that slot. You can think of the `real_storage_slot` identifying its position in the tree, and the `logical_storage_slot` identifying the position in the contract storage.
+
+```rust
+real_storage_slot = H(contract_address, logical_storage_slot)
+```
+
+The siloing is performed by the [Kernel circuits](../circuits/kernels/private_kernel.md).
+
+For structs and arrays, we are logically using a similar storage slot computation to ethereum, e.g., as a struct with 3 fields would be stored in 3 consecutive slots. However, because the "actual" storage slot is computed as a hash of the contract address and the logical storage slot, the actual storage slot is not consecutive.
+
+## Private State Slots
+
+Private storage is a different beast. As you might remember from [Hybrid State Model](../../storage/state_model.md), private state is stored in encrypted logs and the corresponding private state commitments in append-only tree, called the note hash tree where each leaf is a commitment. 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 updates at a specific storage slot would leak information in the context of private state, even if the value is encrypted. That is not good privacy.
+
+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.
+
+### Implementation
+
+If we include the storage slot, as part of the note whose commitment is stored in the note hashes tree, we can _logically link_ all the notes that make up the storage slot. For the case of a balance, we can say that the balance is the sum of all the notes that have the same storage slot - in the same way that your physical wallet balance is the sum of all the physical notes in your wallet.
+
+Similarly to how we siloed the public storage slots, we can silo our private storage by hashing the packed note together with the logical storage slot.
+
+```rust
+note_hash = H([...packed_note, logical_storage_slot]);
+```
+
+Note hash siloing is done in the application circuit, since it is not necessary for security of the network (but only the application).
+:::info
+The private variable wrappers `PrivateSet` and `PrivateMutable` in Aztec.nr include the `logical_storage_slot` in the commitments they compute, to make it easier for developers to write contracts without having to think about how to correctly handle storage slots.
+:::
+
+When reading the values for these notes, the application circuit can then constrain the values to only read notes with a specific logical storage slot.
+
+To ensure that contracts can only modify their own logical storage, we do a second siloing by hashing the `commitment` with the contract address.
+
+```rust
+siloed_note_hash = H(contract_address, note_hash);
+```
+
+By doing this address-siloing at the kernel circuit we _force_ the inserted commitments to include and not lie about the `contract_address`.
+
+:::info
+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 on storage](../../../../developers/reference/smart_contract_reference/storage/index.md).
diff --git a/docs/versioned_docs/version-v0.82.2-alpha-testnet.5/aztec/concepts/communication/cross_chain_calls.md b/docs/versioned_docs/version-v0.82.2-alpha-testnet.5/aztec/concepts/communication/cross_chain_calls.md
new file mode 100644
index 000000000000..b252e6b8c6da
--- /dev/null
+++ b/docs/versioned_docs/version-v0.82.2-alpha-testnet.5/aztec/concepts/communication/cross_chain_calls.md
@@ -0,0 +1,152 @@
+---
+id: portals
+title: L1 <--> L2 communication (Portals)
+description: "This page is a conceptual introduction to Portals, how Aztec communicates with L1 (Ethereum)"
+keywords: [portals]
+tags: [portals, protocol, ethereum]
+importance: 1
+---
+
+# L1-L2 Communication (Portals)
+
+import Image from "@theme/IdealImage";
+
+In Aztec, what we call _portals_ are the key element in facilitating communication between L1 and L2. While typical L2 solutions rely on synchronous communication with L1, Aztec's privacy-first nature means this is not possible. You can learn more about why in the previous section.
+
+Traditional L1 \<-\> L2 communication might involve direct calls between L2 and L1 contracts. However, in Aztec, due to the privacy components and the way transactions are processed (kernel proofs built on historical data), direct calls between L1 and L2 would not be possible if we want to maintain privacy.
+
+Portals are the solution to this problem, acting as bridges for communication between the two layers. These portals can transmit messages from public functions in L1 to private functions in L2 and vice versa, thus enabling messaging while maintaining privacy.
+
+This page covers:
+
+- How portals enable privacy communication between L1 and L2
+- How messages are sent, received, and processed
+- Message Boxes and how they work
+- How and why linking of contracts between L1 and L2 occurs
+
+## Objective
+
+The goal is to set up a minimal-complexity mechanism, that will allow a base-layer (L1) and the Aztec Network (L2) to communicate arbitrary messages such that:
+
+- L2 functions can `call` L1 functions.
+- L1 functions can `call` L2 functions.
+- The rollup-block size have a limited impact by the messages and their size.
+
+## High Level Overview
+
+This document will contain communication abstractions that we use to support interaction between _private_ functions, _public_ functions and Layer 1 portal contracts.
+
+Fundamental restrictions for Aztec:
+
+- L1 and L2 have very different execution environments, stuff that is cheap on L1 is most often expensive on L2 and vice versa. As an example, `keccak256` is cheap on L1, but very expensive on L2.
+- _Private_ function calls are fully "prepared" and proven by the user, which provides the kernel proof along with commitments and nullifiers to the sequencer.
+- _Public_ functions altering public state (updatable storage) must be executed at the current "head" of the chain, which only the sequencer can ensure, so these must be executed separately to the _private_ functions.
+- _Private_ and _public_ functions within Aztec are therefore ordered such that first _private_ functions are executed, and then _public_. For a more detailed description of why, see above.
+- Messages are consumables, and can only be consumed by the recipient. See [Message Boxes](#message-boxes) for more information.
+
+With the aforementioned restrictions taken into account, cross-chain messages can be operated in a similar manner to when _public_ functions must transmit information to _private_ functions. In such a scenario, a "message" is created and conveyed to the recipient for future use. It is worth noting that any call made between different domains (_private, public, cross-chain_) is unilateral in nature. In other words, the caller is unaware of the outcome of the initiated call until told when some later rollup is executed (if at all). This can be regarded as message passing, providing us with a consistent mental model across all domains, which is convenient.
+
+As an illustration, suppose a private function adds a cross-chain call. In such a case, the private function would not have knowledge of the result of the cross-chain call within the same rollup (since it has yet to be executed).
+
+Similarly to the ordering of private and public functions, we can also reap the benefits of intentionally ordering messages between L1 and L2. When a message is sent from L1 to L2, it has been "emitted" by an action in the past (an L1 interaction), allowing us to add it to the list of consumables at the "beginning" of the block execution. This practical approach means that a message could be consumed in the same block it is included. In a sophisticated setup, rollup $n$ could send an L2 to L1 message that is then consumed on L1, and the response is added already in $n+1$. However, messages going from L2 to L1 will be added as they are emitted.
+
+:::info
+Because everything is unilateral and async, the application developer have to explicitly handle failure cases such that user can gracefully recover. Example where recovering is of utmost importance is token bridges, where it is very inconvenient if the locking of funds on one domain occur, but never the minting or unlocking on the other.
+:::
+
+## Components
+
+### Portal
+
+A "portal" refers to the part of an application residing on L1, which is associated with a particular L2 address (the confidential part of the application). It could be a contract or even an EOA on L1.
+
+### Message Boxes
+
+In a logical sense, a Message Box functions as a one-way message passing mechanism with two ends, one residing on each side of the divide, i.e., one component on L1 and another on L2. Essentially, these boxes are utilized to transmit messages between L1 and L2 via the rollup contract. The boxes can be envisaged as multi-sets that enable the same message to be inserted numerous times, a feature that is necessary to accommodate scenarios where, for instance, "deposit 10 eth to A" is required multiple times. The diagram below provides a detailed illustration of how one can perceive a message box in a logical context.
+
+
+
+- Here, a `sender` will insert a message into the `pending` set, the specific constraints of the actions depend on the implementation domain, but for now, say that anyone can insert into the pending set.
+- At some point, a rollup will be executed, in this step messages are "moved" from pending on Domain A, to ready on Domain B. Note that consuming the message is "pulling & deleting" (or nullifying). The action is atomic, so a message that is consumed from the pending set MUST be added to the ready set, or the state transition should fail. A further constraint on moving messages along the way, is that only messages where the `sender` and `recipient` pair exists in a leaf in the contracts tree are allowed!
+- When the message has been added to the ready set, the `recipient` can consume the message as part of a function call.
+
+A difference when compared to other cross-chain setups, is that Aztec is "pulling" messages, and that the message doesn't need to be calldata for a function call. For other rollups, execution is happening FROM the "message bridge", which then calls the L1 contract. For Aztec, you call the L1 contract, and it should then consume messages from the message box.
+
+Why? _Privacy_! When pushing, we would be needing full `calldata`. Which for functions with private inputs is not really something we want as that calldata for L1 -> L2 transactions are committed to on L1, e.g., publicly sharing the inputs to a private function.
+
+By instead pulling, we can have the "message" be something that is derived from the arguments instead. This way, a private function to perform second half of a deposit, leaks the "value" deposited and "who" made the deposit (as this is done on L1), but the new owner can be hidden on L2.
+
+To support messages in both directions we require two of these message boxes (one in each direction). However, due to the limitations of each domain, the message box for sending messages into the rollup and sending messages out are not fully symmetrical. In reality, the setup looks closer to the following:
+
+
+
+:::info
+The L2 -> L1 pending messages set only exist logically, as it is practically unnecessary. For anything to happen to the L2 state (e.g., update the pending messages), the state will be updated on L1, meaning that we could just as well insert the messages directly into the ready set.
+:::
+
+### Rollup Contract
+
+The rollup contract has a few very important responsibilities. The contract must keep track of the _L2 rollup state root_, perform _state transitions_ and ensure that the data is available for anyone else to synchronize to the current state.
+
+To ensure that _state transitions_ are performed correctly, the contract will derive public inputs for the **rollup circuit** based on the input data, and then use a _verifier_ contract to validate that inputs correctly transition the current state to the next. All data needed for the public inputs to the circuit must be from the rollup block, ensuring that the block is available. For a valid proof, the _rollup state root_ is updated and it will emit an _event_ to make it easy for anyone to find the data.
+
+As part of _state transitions_ where cross-chain messages are included, the contract must "move" messages along the way, e.g., from "pending" to "ready".
+
+### Kernel Circuit
+
+For L2 to L1 messages, the public inputs of a user-proof will contain a dynamic array of messages to be added, of size at most `MAX_MESSAGESTACK_DEPTH`, limited to ensure it is not impossible to include the transaction. The circuit must ensure, that all messages have a `sender/recipient` pair, and that those pairs exist in the contracts tree and that the `sender` is the L2 contract that actually emitted the message.
+For consuming L1 to L2 messages the circuit must create proper nullifiers.
+
+### Rollup Circuit
+
+The rollup circuit must ensure that, provided two states $S$ and $S'$ and the rollup block $B$, applying $B$ to $S$ using the transition function must give us $S'$, e.g., $T(S, B) \mapsto S'$. If this is not the case, the constraints are not satisfied.
+
+For the sake of cross-chain messages, this means inserting and nullifying L1 $\rightarrow$ L2 in the trees, and publish L2 $\rightarrow$ L1 messages on chain. These messages should only be inserted if the `sender` and `recipient` match an entry in the contracts leaf (as checked by the kernel).
+
+### Messages
+
+While a message could theoretically be arbitrarily long, we want to limit the cost of the insertion on L1 as much as possible. Therefore, we allow the users to send 32 bytes of "content" between L1 and L2. If 32 suffices, no packing required. If the 32 is too "small" for the message directly, the sender should simply pass along a `sha256(content)` instead of the content directly (note that this hash should fit in a field element which is ~254 bits. More info on this below). The content can then either be emitted as an event on L2 or kept by the sender, who should then be the only entity that can "unpack" the message.
+In this manner, there is some way to "unpack" the content on the receiving domain.
+
+The message that is passed along, require the `sender/recipient` pair to be communicated as well (we need to know who should receive the message and be able to check). By having the pending messages be a contract on L1, we can ensure that the `sender = msg.sender` and let only `content` and `recipient` be provided by the caller. Summing up, we can use the structs seen below, and only store the commitment (`sha256(LxToLyMsg)`) on chain or in the trees, this way, we need only update a single storage slot per message.
+
+```solidity
+struct L1Actor {
+ address: actor,
+ uint256: chainId,
+}
+
+struct L2Actor {
+ bytes32: actor,
+ uint256: version,
+}
+
+struct L1ToL2Msg {
+ L1Actor: sender,
+ L2Actor: recipient,
+ bytes32: content,
+ bytes32: secretHash,
+}
+
+struct L2ToL1Msg {
+ L2Actor: sender,
+ L1Actor: recipient,
+ bytes32: content,
+}
+```
+
+:::info
+The `bytes32` elements for `content` and `secretHash` hold values that must fit in a field element (~ 254 bits).
+:::
+
+:::info
+The nullifier computation should include the index of the message in the message tree to ensure that it is possible to send duplicate messages (e.g., 2 x deposit of 500 dai to the same account).
+
+To make it possible to hide when a specific message is consumed, the `L1ToL2Msg` is extended with a `secretHash` field, where the `secretPreimage` is used as part of the nullifier computation. This way, it is not possible for someone just seeing the `L1ToL2Msg` on L1 to know when it is consumed on L2.
+:::
+
+## Combined Architecture
+
+The following diagram shows the overall architecture, combining the earlier sections.
+
+
diff --git a/docs/versioned_docs/version-v0.82.2-alpha-testnet.5/aztec/concepts/communication/index.md b/docs/versioned_docs/version-v0.82.2-alpha-testnet.5/aztec/concepts/communication/index.md
new file mode 100644
index 000000000000..8cd693c477e6
--- /dev/null
+++ b/docs/versioned_docs/version-v0.82.2-alpha-testnet.5/aztec/concepts/communication/index.md
@@ -0,0 +1,12 @@
+---
+title: Communication
+sidebar_position: 6
+---
+
+## Cross-chain communication
+
+See [L1 \<--\> L2 communication (Portals)](./cross_chain_calls.md) for information about how Aztec communications with L1 (Ethereum) through Portals.
+
+## Private / Public execution
+
+For in-depth information about how private and public functions can call each other, read the [Smart Contracts section](../../smart_contracts/functions/public_private_calls.md).
diff --git a/docs/versioned_docs/version-v0.82.2-alpha-testnet.5/aztec/concepts/fees.md b/docs/versioned_docs/version-v0.82.2-alpha-testnet.5/aztec/concepts/fees.md
new file mode 100644
index 000000000000..fa537d8a2e7c
--- /dev/null
+++ b/docs/versioned_docs/version-v0.82.2-alpha-testnet.5/aztec/concepts/fees.md
@@ -0,0 +1,96 @@
+---
+title: Fees
+sidebar_position: 4
+tags: [fees]
+---
+
+import { Why_Fees } from '/components/snippets';
+
+
+
+In a nutshell, the pricing of transactions transparently accounts for:
+- L1 costs, including L1 execution of a block, and data availability via blobs,
+- L2 node operating costs, including proving
+
+This is done via multiple variables and calculations explained in detail in the protocol specifications.
+
+## Terminology and factors
+
+Familiar terms from Ethereum mainnet as referred to on the Aztec network:
+
+| Ethereum Mainnet | Aztec | Description |
+| ----------- | ------------------ | - |
+| gas | mana | indication of effort in transaction operations |
+| fee per gas | fee-juice per mana | cost per unit of effort |
+| fee (wei) | fee-juice | amount to be paid |
+
+An oracle informs the price of fee-juice per wei, which can be used to calculate a transaction's fee-juice in the units of wei.
+
+Also Aztec borrows ideas from EIP-1559 including: congestion multipliers, and the ability to specify base and priority fee per mana.
+
+
+### Aztec-specific fields
+
+There are many other fields used in mana and fee calculations, and below shows the ways these fields are determined:
+
+- hard-coded constants (eg congestion update fraction)
+- values assumed constant (eg L1 gas cost of publishing a block, blobs per block)
+- informed from previous block header and/or L1 rollup contract (eg base_fee_juice_per_mana)
+- informed via an oracle (eg wei per mana)
+
+Most of the constants are defined by the protocol, several others are part of the rollup contract on L1.
+
+More information about the design/choices can be found in the fees section of the protocol specification.
+
+### User selected factors
+
+As part of a transaction the follow gas settings are available to be defined by the user.
+
+import { Gas_Settings_Components, Gas_Settings, Tx_Teardown_Phase } from '/components/snippets';
+
+
+
+These are:
+
+```javascript title="gas_settings_vars" showLineNumbers
+/** Gas usage and fees limits set by the transaction sender for different dimensions and phases. */
+export class GasSettings {
+ constructor(
+ public readonly gasLimits: Gas,
+ public readonly teardownGasLimits: Gas,
+ public readonly maxFeesPerGas: GasFees,
+ public readonly maxPriorityFeesPerGas: GasFees,
+ ) {}
+```
+> Source code: yarn-project/stdlib/src/gas/gas_settings.ts#L11-L20
+
+
+
+
+## Fee payment
+
+A fee payer will have bridged fee-juice from L1. On Aztec this fee asset is non-transferrable, and only deducted by the protocol to pay for fees.
+
+The mechanisms for bridging is the same as any other token. For more on this concept see the start of the [Token Bridge Tutorial](../../developers/tutorials/codealong/contract_tutorials/token_bridge) where it describes the components and how bridging works (under the hood this makes use of [portals](https://docs.aztec.network/aztec/concepts/communication/portals)).
+
+### Payment methods
+
+An account with fee-juice can pay for its transactions, including deployment of a new account.
+An account making a transaction can also refer to "fee-paying contracts" (FPCs) to pay for its transactions.
+
+### Teardown phase
+
+
+
+### Operator rewards
+
+The calculated fee-juice of a transaction is deducted from the fee payer (nominated account or fee-paying contract), then pooled together each transaction, block, and epoch.
+Once the epoch is proven, the total fee-juice (minus any burnt congestion amount), is distributed to provers and block validators/sequencers that contributed to the epoch.
+
+The fees section of the protocol specification explains this distribution of fee-juice between proposers and provers.
+
+## Next steps
+
+More comprehensive technical details for implementers will be available from the updated protocol specifications soon.
+
+For a guide showing ways to pay fees programmatically, see [here](../../developers/guides/js_apps/pay_fees).
diff --git a/docs/versioned_docs/version-v0.82.2-alpha-testnet.5/aztec/concepts/pxe/acir_simulator.md b/docs/versioned_docs/version-v0.82.2-alpha-testnet.5/aztec/concepts/pxe/acir_simulator.md
new file mode 100644
index 000000000000..c6bb4ac8c8d7
--- /dev/null
+++ b/docs/versioned_docs/version-v0.82.2-alpha-testnet.5/aztec/concepts/pxe/acir_simulator.md
@@ -0,0 +1,35 @@
+---
+title: ACIR Simulator
+---
+
+The ACIR Simulator is responsible for simulation Aztec smart contract function execution. This component helps with correct execution of Aztec transactions.
+
+Simulating a function implies generating the partial witness and the public inputs of the function, as well as collecting all the data (such as created notes or nullifiers, or state changes) that are necessary for components upstream.
+
+## Simulating functions
+
+It simulates three types of functions:
+
+### Private Functions
+
+Private functions are simulated and proved client-side, and verified client-side in the private kernel circuit.
+
+They are run with the assistance of a DB oracle that provides any private data requested by the function. You can read more about oracle functions in the smart contract section [here](../../smart_contracts/oracles/index.md).
+
+Private functions can call other private functions and can request to call a public function. The public function execution will be performed by the sequencer asynchronously, so private functions don't have direct access to the return values of public functions.
+
+### Public Functions
+
+Public functions are simulated and proved on the sequencer side, and verified by the [public kernel circuit](../../concepts/advanced/circuits/kernels/public_kernel.md).
+
+They are run with the assistance of an oracle that provides any value read from the public state tree.
+
+Public functions can call other public functions as well as private functions. Public function composability can happen atomically, but public to private function calls happen asynchronously (the private function call must happen in a future block).
+
+### Unconstrained Functions
+
+Unconstrained functions are used to extract useful data for users, such as the user balance. They are not proven, and are simulated client-side.
+
+They are run with the assistance of a DB oracle that provides any private data requested by the function.
+
+At the moment, unconstrained functions cannot call any other function. It is not possible for them to call constrained functions, but it is on the roadmap to allow them to call other unconstrained functions.
diff --git a/docs/versioned_docs/version-v0.82.2-alpha-testnet.5/aztec/concepts/pxe/index.md b/docs/versioned_docs/version-v0.82.2-alpha-testnet.5/aztec/concepts/pxe/index.md
new file mode 100644
index 000000000000..893344b7c753
--- /dev/null
+++ b/docs/versioned_docs/version-v0.82.2-alpha-testnet.5/aztec/concepts/pxe/index.md
@@ -0,0 +1,108 @@
+---
+title: Private Execution Environment (PXE)
+sidebar_position: 7
+tags: [PXE]
+keywords: [pxe, private execution environment]
+importance: 1
+---
+
+import Image from "@theme/IdealImage";
+
+This page describes the Private Execution Environment (PXE, pronounced "pixie"), a client-side library for the execution of private operations. It is a TypeScript library that can be run within Node.js, inside wallet software or a browser.
+
+The PXE generates proofs of private function execution, and sends these proofs along with public function execution requests to the sequencer. Private inputs never leave the client-side PXE.
+
+The PXE is responsible for:
+
+- storing secrets (e.g. encryption keys, notes, tagging secrets for note discovery) and exposing an interface for safely accessing them
+- orchestrating private function (circuit) execution and proof generation, including implementing [oracles](../../smart_contracts/oracles/index.md) needed for transaction execution
+- syncing users' relevant network state, obtained from an Aztec node
+- safely handling multiple accounts with siloed data and permissions
+
+One PXE can handle data and secrets for multiple accounts, while also providing isolation between them as required.
+
+## System architecture
+
+```mermaid
+flowchart TB
+ User --Interacts with--> Wallet
+ Wallet --Prompts--> User
+ subgraph Browser
+ Dapp
+ end
+ Dapp --Calls (requires auth)--> Wallet
+ subgraph Client-side
+ Wallet --Scoped--> PXE
+ PXE --Execute/Prove--> Circuits
+ Circuits --Oracle--> PXE
+ end
+ PXE --Queries world-state (causes privacy leaks)--> Node
+ Wallet --Track tx state (may be handled via PXE)--> Node
+```
+
+## Components
+
+### Transaction Simulator
+
+An application will prompt the users PXE to execute a transaction (e.g. execute X function, with Y arguments, from Z account). The application or the wallet may handle gas estimation.
+
+The ACIR (Abstract Circuit Intermediate Representation) simulator handles the execution of smart contract functions by simulating transactions. It generates the required data and inputs for these functions. You can find more details about how it works [here](./acir_simulator.md).
+
+Until there are simulated simulations ([#9133](https://github.com/AztecProtocol/aztec-packages/issues/9133)), authwits are required for simulation, before attempting to prove.
+
+### Proof Generation
+
+After simulation, the wallet calls `proveTx` on the PXE with all of the data generated during simulation and any [authentication witnesses](../advanced/authwit.md) (for allowing contracts to act on behalf of the users' account contract).
+
+Once proven, the wallet sends the transaction to the network and sends the transaction hash back to the application.
+
+### Database
+
+The database stores transactional data and notes within the user's PXE.
+
+The database stores various types of data, including:
+
+- **Notes**: Data representing users' private state. These are often stored on-chain, encrypted to a user. A contract will parse on-chain data to find notes relevant for users' accounts and they are stored in the PXE.
+- **Authentication Witnesses**: Data used to approve others for executing transactions on your behalf. The PXE provides this data to transactions on-demand during transaction simulation via oracles.
+- **Capsules**: External data or data injected into the system via [oracles](#oracles).
+- **Address Book**: A list of expected addresses that a PXE may encrypt notes for, or received encrypted notes from. This list helps the PXE reduce the amount of work required to find notes relevant to it's registered accounts.
+
+The PXE is not in charge of note discovery, ie finding the notes that are owned by the user. This is handled by Aztec contracts, and you can learn more [here](../advanced/storage/note_discovery.md)
+
+### Authorization
+
+The PXE handles access rights by:
+
+1. action
+2. domain
+3. contract
+4. account
+
+For example, uniswap.com (**domain**) can query (**action**, involves execution that has access to an accounts' private state) on these five token **contracts** for these two **accounts** of mine, that are registered in the PXE.
+
+Available actions include:
+
+- Seeing that the accounts exist in the PXE
+- Running queries, simulations, accessing logs, registering contracts, etc at a given a contract address
+- Manually adding notes
+
+Providing an application with an empty scopes array (e.g. `scopes: []`) to the PXE means that no information can be accessed, but no scopes (e.g. `scopes: undefined`) defaults to _all_ scopes being available.
+
+### Contract management
+
+Applications can add contract code required for a user to interact with the application to the users PXE. The PXE will check whether the required contracts have already been registered in users PXE. There are no getters to check whether the contract has been registered, as this could leak privacy (e.g. a dapp could check whether specific contracts have been registered in a users PXE and infer information about their interaction history).
+
+### Keystore
+
+The keystore is a secure storage for private and public keys.
+
+### Oracles
+
+Oracles are pieces of data that are injected into a smart contract function from the client side. You can read more about why and how they work in the [smart contracts section](../../smart_contracts/oracles/index.md).
+
+## For developers
+
+To learn how to develop on top of the PXE, refer to these guides:
+
+- [Run more than one PXE on your local machine](../../../developers/guides/local_env/run_more_than_one_pxe_sandbox.md)
+- [Use in-built oracles including oracles for arbitrary data](../../../developers/guides/smart_contracts/writing_contracts/how_to_use_capsules.md)
diff --git a/docs/versioned_docs/version-v0.82.2-alpha-testnet.5/aztec/concepts/storage/_category_.json b/docs/versioned_docs/version-v0.82.2-alpha-testnet.5/aztec/concepts/storage/_category_.json
new file mode 100644
index 000000000000..0c73c07e5639
--- /dev/null
+++ b/docs/versioned_docs/version-v0.82.2-alpha-testnet.5/aztec/concepts/storage/_category_.json
@@ -0,0 +1,6 @@
+{
+ "label": "Storage",
+ "position": 1,
+ "collapsible": true,
+ "collapsed": true
+}
diff --git a/docs/versioned_docs/version-v0.82.2-alpha-testnet.5/aztec/concepts/storage/index.md b/docs/versioned_docs/version-v0.82.2-alpha-testnet.5/aztec/concepts/storage/index.md
new file mode 100644
index 000000000000..d440a19d8d41
--- /dev/null
+++ b/docs/versioned_docs/version-v0.82.2-alpha-testnet.5/aztec/concepts/storage/index.md
@@ -0,0 +1,12 @@
+---
+title: Storage
+description: How are storage slots derived for public and private state
+sidebar_position: 0
+tags: [protocol, storage]
+---
+
+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.
+
+It also means that we need to be careful about how we allocate storage to ensure that they don't collide! We say that storage should be _siloed_ to its contract. The exact way of siloing differs a little for public and private storage. Which we will see in the following sections.
diff --git a/docs/versioned_docs/version-v0.82.2-alpha-testnet.5/aztec/concepts/storage/notes.md b/docs/versioned_docs/version-v0.82.2-alpha-testnet.5/aztec/concepts/storage/notes.md
new file mode 100644
index 000000000000..0bae4ddadfff
--- /dev/null
+++ b/docs/versioned_docs/version-v0.82.2-alpha-testnet.5/aztec/concepts/storage/notes.md
@@ -0,0 +1,45 @@
+---
+title: Notes (UTXOs)
+sidebar_position: 5
+tags: [notes, storage]
+---
+
+import Image from "@theme/IdealImage";
+
+The [state model page](./state_model.md) explains that there is a difference between public and private state. Private state uses UTXOs (unspent transaction ouputs), also known as notes. This page introduces the concept of UTXOs and how notes are abstracted on Aztec.
+
+## What are notes?
+
+In an account-based model such as Ethereum, each account is typically associated with a specific location in the data tree. In a UTXO model, each note specifies its owner and there is no relationship between an account and data's location in the data tree. Notes are encrypted pieces of data that can only be decrypted by their owner.
+
+Rather than storing entire notes in a data tree, note commitments (hashes of the notes) are stored in a merkle tree, aptly named the note hash tree. Users will prove that they have the note pre-image information when they update private state in a contract.
+
+When a note is updated, Aztec nullifies the original commitment in the note hash tree by creating a nullifier from the note data, and may create a new note with the updated information, encrypted to a new owner if necessary. This helps to decouple actions of creating, updating and deleting private state.
+
+
+
+Notes are comparable to cash, with some slight differences. When you want to spend \$3.50 USD in real life, you give your \$5 note to a cashier who will keep \$3.50 and give you separate notes that add up to \$1.50. Using private notes on Aztec, when you want to spend a \$5 note, you nullify it and create a \$1.5 note with yourself as the owner and a \$3.5 note with the recipient as the owner. Only you and the recipient are aware of \$3.5 transaction, they are not aware that you "split" the \$5 note.
+
+## Sending notes
+
+When creating notes for a recipient, you need a way to send the note to them. There are a few ways to do this:
+
+### On-chain (encrypted logs):
+
+This is the common method and works well for most use cases. You can emit an encrypted log as part of a transaction. The encrypted note data will be posted onchain, allowing the recipient to find the note through [note discovery](../advanced/storage/note_discovery.md).
+
+### Off-chain (out of band):
+
+In some cases, if you know the recipient off-chain, you might choose to share the note data directly with them. The recipient can store that note in their PXE and later spend it.
+
+### Self-created notes (not emitted):
+
+If you create a note for yourself, you don’t need to broadcast it to the network or share anything. You will only need to keep the note somewhere, such as in your PXE, so you can prove ownership and spend it in future transactions.
+
+## Abstracting notes from from apps & users
+
+When using the Aztec protocol, users may not be aware of the specific notes that they own. Their experience should be similar to Ethereum, and should instead see the amount of their assets inside their account.
+
+This is accomplished through the smart contract library, Aztec.nr, which abstracts notes by allowing developers to specify custom note types. This means they can specify how notes are interacted with, nullified, transferred, and displayed. Aztec.nr also helps users discover all of the notes that have been encrypted to their account and posted to the chain, known as [note discovery](../advanced/storage/note_discovery.md).
+
+To understand note abstraction in Aztec.nr, you can read the [Build section](../../../developers/guides/smart_contracts/writing_contracts/notes/index.md).
diff --git a/docs/versioned_docs/version-v0.82.2-alpha-testnet.5/aztec/concepts/storage/state_model.md b/docs/versioned_docs/version-v0.82.2-alpha-testnet.5/aztec/concepts/storage/state_model.md
new file mode 100644
index 000000000000..6ef55640ac5c
--- /dev/null
+++ b/docs/versioned_docs/version-v0.82.2-alpha-testnet.5/aztec/concepts/storage/state_model.md
@@ -0,0 +1,27 @@
+---
+title: State Model
+sidebar_position: 4
+tags: [state]
+---
+
+Aztec has a hybrid public/private state model. Aztec contract developers can specify which data is public and which data is private, as well as the functions that can operate on that data.
+
+## Public State
+
+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.
+
+## Private State
+
+Private state must be treated differently from public state. Private state is encrypted and therefore is "owned" by a user or a set of users (via shared secrets) that are able to decrypt the state.
+
+Private state is represented in an append-only database since updating a record would leak information about the transaction graph.
+
+The act of "deleting" a private state variable can be represented by adding an associated nullifier to a nullifier set. The nullifier is generated such that, without knowing the decryption key of the owner, an observer cannot link a state record with a nullifier.
+
+Modification of state variables can be emulated by nullifying the state record and creating a new record to represent the variable. Private state has an intrinsic UTXO structure.
+
+## Further reading
+
+Read more about how to leverage the Aztec state model in Aztec contracts [here](../../../developers/reference/smart_contract_reference/storage/index.md).
diff --git a/docs/versioned_docs/version-v0.82.2-alpha-testnet.5/aztec/concepts/transactions.md b/docs/versioned_docs/version-v0.82.2-alpha-testnet.5/aztec/concepts/transactions.md
new file mode 100644
index 000000000000..dc302d38b97c
--- /dev/null
+++ b/docs/versioned_docs/version-v0.82.2-alpha-testnet.5/aztec/concepts/transactions.md
@@ -0,0 +1,221 @@
+---
+title: Transactions
+sidebar_position: 3
+tags: [protocol]
+---
+
+import Image from '@theme/IdealImage';
+
+On this page you'll learn:
+
+- The step-by-step process of sending a transaction on Aztec
+- The role of components like PXE, Aztec Node, ACIR simulator, and the sequencer
+- The Aztec Kernel and its two circuits: private and public, and how they execute function calls
+- The call stacks for private & public functions and how they determine a transaction's completion
+
+## Simple Example of the (Private) Transaction Lifecycle
+
+The transaction lifecycle for an Aztec transaction is fundamentally different from the lifecycle of an Ethereum transaction.
+
+The introduction of the Private eXecution Environment (PXE) provides a safe environment for the execution of sensitive operations, ensuring that decrypted data are not accessible to unauthorized applications. However, the PXE exists client-side on user devices, which creates a different model for imagining what the lifecycle of a typical transaction might look like. The existence of a sequencing network also introduces some key differences between the Aztec transaction model and the transaction model used for other networks.
+
+The accompanying diagram illustrates the flow of interactions between a user, their wallet, the PXE, the node operators (sequencers / provers), and the L1 chain.
+
+
+
+1. **The user initiates a transaction** – In this example, the user decides to privately send 10 DAI to gudcause.eth. After inputting the amount and the receiving address, the user clicks the confirmation button on their wallet.
+
+_The transaction has not been broadcasted to the sequencer network yet. For now, the transaction exists solely within the context of the PXE._
+
+2. **The PXE executes transfer locally** – The PXE, running locally on the user's device, executes the transfer method on the DAI token contract on Aztec and computes the state difference based on the user’s intention.
+
+_The transaction has still not been broadcasted to the sequencer network yet and continues to live solely within the context of the PXE._
+
+3. **The PXE proves correct execution** – At this point, the PXE proves correct execution (via zero-knowledge proofs) of the authorization and of the private transfer method. Once the proofs have been generated, the PXE sends the proofs and required inputs (inputs are new note commitments, stored in the note hash tree and nullifiers stored in the nullifiers tree) to the sequencer. Nullifiers are data that invalidate old commitments, ensuring that commitments can only be used once.
+
+_The sequencer has received the transaction proof and can begin to process the transaction - verifying proofs and applying updates to the relevant data trees - alongside other public and private transactions._
+
+4. **The sequencer has the necessary information to act** – the randomly-selected sequencer (based on the Fernet sequencer selection protocol) validates the transaction proofs along with required inputs (e.g. the note commitments and nullifiers) for this private transfer. The sequencer also executes public functions and requests proofs of public execution from a prover network. The sequencer updates the corresponding data trees and does the same for other private transactions. When the sequencer receives proofs from the prover network, the proofs will be bundled into a final rollup proof.
+
+_The sequencer has passed the transaction information – proofs of correct execution and authorization, or public function execution information – to the prover, who will submit the new state root to Ethereum._
+
+5. **The transaction settles to L1** – the verifier contract on Ethereum can now validate the rollup proof and record a new state root. The state root is submitted to the rollup smart contract. Once the state root is verified in an Ethereum transaction, the private transfer has settled and the transaction is considered final.
+
+### Detailed Diagram
+
+Transactions on Aztec start with a call from Aztec.js, which creates a request containing transaction details. This request moves to the Private Execution Environment (PXE) which simulates and processes it. Then the PXE interacts with the Aztec Node which uses the sequencer to ensure that all the transaction details are enqueued properly. The sequencer then submits the block to the rollup contract, and the transaction is successfully mined.
+
+
+
+See [this diagram](https://raw.githubusercontent.com/AztecProtocol/aztec-packages/2fa143e4d88b3089ebbe2a9e53645edf66157dc8/docs/static/img/sandbox_sending_a_tx.svg) for a more detailed overview of the transaction execution process. It highlights 3 different types of transaction execution: contract deployments, private transactions and public transactions.
+
+See the page on [contract communication](../smart_contracts/functions/public_private_calls.md) for more context on transaction execution.
+
+### Transaction Requests
+
+Transaction requests are how transactions are constructed and sent to the network.
+
+In Aztec.js:
+
+```javascript title="constructor" showLineNumbers
+constructor(
+ /** Sender. */
+ public origin: AztecAddress,
+ /** Function data representing the function to call. */
+ public functionData: FunctionData,
+ /** Pedersen hash of function arguments. */
+ public argsHash: Fr,
+ /** Transaction context. */
+ public txContext: TxContext,
+) {}
+```
+> Source code: yarn-project/stdlib/src/tx/tx_request.ts#L15-L26
+
+
+Where:
+
+- `origin` is the account contract where the transaction is initiated from.
+- `functionData` contains the function selector and indicates whether the function is private or public.
+- `argsHash` is the hash of the arguments of all of the calls to be executed. The complete set of arguments is passed to the PXE as part of the [TxExecutionRequest](https://github.com/AztecProtocol/aztec-packages/blob/v0.82.2/yarn-project/stdlib/src/tx/tx_execution_request.ts) and checked against this hash.
+- `txContext` contains the chain id, version, and gas settings.
+
+The `functionData` includes an `AppPayload`, which includes information about the application functions and arguments, and a `FeePayload`, which includes info about how to pay for the transaction.
+
+An account contract validates that the transaction request has been authorized via its specified authorization mechanism, via the `is_valid_impl` function (e.g. [an ECDSA signature](https://github.com/AztecProtocol/aztec-packages/blob/v0.82.2/noir-projects/noir-contracts/contracts/ecdsa_k_account_contract/src/main.nr#L56-L57), generated [in JS](https://github.com/AztecProtocol/aztec-packages/blob/v0.82.2/yarn-project/accounts/src/ecdsa/ecdsa_k/account_contract.ts#L30)).
+
+Transaction requests are simulated in the PXE in order to generate the necessary inputs for generating proofs. Once transactions are proven, a [transaction object](https://github.com/AztecProtocol/aztec-packages/blob/v0.82.2/yarn-project/stdlib/src/tx/tx.ts#L26) is created and can be sent to the network to be included in a block.
+
+#### Contract Interaction Methods
+
+Most transaction requests are created as interactions with specific contracts. The exception is transactions that deploy contracts. Here are the main methods for interacting with contracts related to transactions.
+
+1. [`create`](#create)
+2. [`simulate`](#simulate)
+3. [`prove`](#prove)
+4. [`send`](#send)
+
+And fee utilities:
+
+- [`estimateGas`](#estimategas)
+- [`getFeeOptions`](#getfeeoptions)
+
+##### `create`
+
+```javascript title="create" showLineNumbers
+/**
+ * Create a transaction execution request that represents this call, encoded and authenticated by the
+ * user's wallet, ready to be simulated.
+ * @param options - An optional object containing additional configuration for the transaction.
+ * @returns A Promise that resolves to a transaction instance.
+ */
+public async create(options: SendMethodOptions = {}): Promise {
+```
+> Source code: yarn-project/aztec.js/src/contract/contract_function_interaction.ts#L68-L76
+
+
+##### `simulate`
+
+```javascript title="simulate" showLineNumbers
+/**
+ * Simulate a transaction and get its return values
+ * Differs from prove in a few important ways:
+ * 1. It returns the values of the function execution
+ * 2. It supports `unconstrained`, `private` and `public` functions
+ *
+ * @param options - An optional object containing additional configuration for the transaction.
+ * @returns The result of the transaction as returned by the contract function.
+ */
+public async simulate(options: SimulateMethodOptions = {}): Promise {
+```
+> Source code: yarn-project/aztec.js/src/contract/contract_function_interaction.ts#L118-L129
+
+
+##### `prove`
+
+```javascript title="prove" showLineNumbers
+/**
+ * Proves a transaction execution request and returns a tx object ready to be sent.
+ * @param options - optional arguments to be used in the creation of the transaction
+ * @returns The resulting transaction
+ */
+public async prove(options: SendMethodOptions = {}): Promise {
+```
+> Source code: yarn-project/aztec.js/src/contract/base_contract_interaction.ts#L81-L88
+
+
+##### `send`
+
+```javascript title="send" showLineNumbers
+/**
+ * Sends a transaction to the contract function with the specified options.
+ * This function throws an error if called on an unconstrained function.
+ * It creates and signs the transaction if necessary, and returns a SentTx instance,
+ * which can be used to track the transaction status, receipt, and events.
+ * @param options - An optional object containing 'from' property representing
+ * the AztecAddress of the sender. If not provided, the default address is used.
+ * @returns A SentTx instance for tracking the transaction status and information.
+ */
+public send(options: SendMethodOptions = {}): SentTx {
+```
+> Source code: yarn-project/aztec.js/src/contract/base_contract_interaction.ts#L93-L104
+
+
+##### `estimateGas`
+
+```javascript title="estimateGas" showLineNumbers
+/**
+ * Estimates gas for a given tx request and returns gas limits for it.
+ * @param opts - Options.
+ * @param pad - Percentage to pad the suggested gas limits by, if empty, defaults to 10%.
+ * @returns Gas limits.
+ */
+public async estimateGas(
+ opts?: Omit,
+): Promise> {
+```
+> Source code: yarn-project/aztec.js/src/contract/base_contract_interaction.ts#L112-L122
+
+
+##### `getFeeOptions`
+
+```javascript title="getFeeOptions" showLineNumbers
+/**
+ * Return fee options based on the user opts, estimating tx gas if needed.
+ * @param executionPayload - Execution payload to get the fee for
+ * @param fee - User-provided fee options.
+ * @param options - Additional options for the transaction. They must faithfully represent the tx to get accurate fee estimates
+ * @returns Fee options for the actual transaction.
+ */
+protected async getFeeOptions(
+ executionPayload: ExecutionPayload,
+ fee: UserFeeOptions = {},
+ options: TxExecutionOptions,
+): Promise {
+```
+> Source code: yarn-project/aztec.js/src/contract/base_contract_interaction.ts#L151-L164
+
+
+### Batch Transactions
+
+Batched transactions are a way to send multiple transactions in a single call. They are created by the [`BatchCall` class in Aztec.js](https://github.com/AztecProtocol/aztec-packages/blob/v0.82.2/yarn-project/aztec.js/src/contract/batch_call.ts). This allows a batch of function calls from a single wallet to be sent as a single transaction through a wallet.
+
+### Enabling Transaction Semantics
+
+There are two kernel circuits in Aztec, the private kernel and the public kernel. Each circuit validates the correct execution of a particular function call.
+
+A transaction is built up by generating proofs for multiple recursive iterations of kernel circuits. Each call in the call stack is modeled as new iteration of the kernel circuit and are managed by a [FIFO]() queue containing pending function calls. There are two call stacks, one for private calls and one for public calls.
+
+One iteration of a kernel circuit will pop a call off of the stack and execute the call. If the call triggers subsequent contract calls, these are pushed onto the stack.
+
+Private kernel proofs are generated first. The transaction is ready to move to the next phase when the private call stack is empty.
+
+The public kernel circuit takes in proof of a public/private kernel circuit with an empty private call stack, and operates recursively until the public call stack is also empty.
+
+A transaction is considered complete when both call stacks are empty.
+
+The only information leaked about the transaction is:
+
+1. The number of private state updates triggered
+2. The set of public calls generated
+
+The addresses of all private calls are hidden from observers.
diff --git a/docs/versioned_docs/version-v0.82.2-alpha-testnet.5/aztec/concepts/wallets/architecture.md b/docs/versioned_docs/version-v0.82.2-alpha-testnet.5/aztec/concepts/wallets/architecture.md
new file mode 100644
index 000000000000..408bddf3530c
--- /dev/null
+++ b/docs/versioned_docs/version-v0.82.2-alpha-testnet.5/aztec/concepts/wallets/architecture.md
@@ -0,0 +1,382 @@
+---
+title: Wallet Architecture
+tags: [protocol, accounts]
+---
+
+This page talks about the architecture of a wallet in Aztec. Wallets expose to dapps an interface that allows them to act on behalf of the user, such as querying private state or sending transactions. Bear in mind that, as in Ethereum, wallets should require user confirmation whenever carrying out a potentially sensitive action requested by a dapp.
+
+## Overview
+
+Architecture-wise, a wallet is an instance of an **Private Execution Environment (PXE)** which manages user keys and private state.
+The PXE also communicates with an **Aztec Node** for retrieving public information or broadcasting transactions.
+Note that the PXE requires a local database for keeping private state, and is also expected to be continuously syncing new blocks for trial-decryption of user notes.
+
+Additionally, a wallet must be able to handle one or more account contract implementation. When a user creates a new account, the account is represented on-chain by an account contract. The wallet is responsible for deploying and interacting with this contract. A wallet may support multiple flavours of accounts, such as an account that uses ECDSA signatures, or one that relies on WebAuthn, or one that requires multi-factor authentication. For a user, the choice of what account implementation to use is then determined by the wallet they interact with.
+
+In code, this translates to a wallet implementing an **AccountInterface** interface that defines [how to create an _execution request_ out of an array of _function calls_](./index.md#transaction-lifecycle) for the specific implementation of an account contract and [how to generate an _auth witness_](./index.md#authorizing-actions) for authorizing actions on behalf of the user. Think of this interface as the Javascript counterpart of an account contract, or the piece of code that knows how to format a transaction and authenticate an action based on the rules defined by the user's account contract implementation.
+
+## Account interface
+
+The account interface is used for creating an _execution request_ out of one or more _function calls_ requested by a dapp, as well as creating an _auth witness_ for a given message hash. Account contracts are expected to handle multiple function calls per transaction, since dapps may choose to batch multiple actions into a single request to the wallet.
+
+```typescript title="account-interface" showLineNumbers
+
+/**
+ * Handler for interfacing with an account. Knows how to create transaction execution
+ * requests and authorize actions for its corresponding account.
+ */
+export interface AccountInterface extends EntrypointInterface, AuthWitnessProvider {
+ /** Returns the complete address for this account. */
+ getCompleteAddress(): CompleteAddress;
+
+ /** Returns the address for this account. */
+ getAddress(): AztecAddress;
+
+ /** Returns the chain id for this account */
+ getChainId(): Fr;
+
+ /** Returns the rollup version for this account */
+ getVersion(): Fr;
+}
+```
+> Source code: yarn-project/aztec.js/src/account/interface.ts#L6-L25
+
+
+## PXE interface
+
+A wallet exposes the PXE interface to dapps by running a PXE instance. The PXE requires a keystore and a database implementation for storing keys, private state, and recipient encryption public keys.
+
+```typescript title="pxe-interface" showLineNumbers
+/**
+ * Private eXecution Environment (PXE) runs locally for each user, providing functionality for all the operations
+ * needed to interact with the Aztec network, including account management, private data management,
+ * transaction local simulation, and access to an Aztec node. This interface, as part of a Wallet,
+ * is exposed to dapps for interacting with the network on behalf of the user.
+ */
+export interface PXE {
+ /**
+ * Returns whether an L1 to L2 message is synced by archiver and if it's ready to be included in a block.
+ * @param l1ToL2Message - The L1 to L2 message to check.
+ * @returns Whether the message is synced and ready to be included in a block.
+ */
+ isL1ToL2MessageSynced(l1ToL2Message: Fr): Promise;
+
+ /**
+ * Registers a user account in PXE given its master encryption private key.
+ * Once a new account is registered, the PXE Service will trial-decrypt all published notes on
+ * the chain and store those that correspond to the registered account. Will do nothing if the
+ * account is already registered.
+ *
+ * @param secretKey - Secret key of the corresponding user master public key.
+ * @param partialAddress - The partial address of the account contract corresponding to the account being registered.
+ * @returns The complete address of the account.
+ */
+ registerAccount(secretKey: Fr, partialAddress: PartialAddress): Promise;
+
+ /**
+ * Retrieves the user accounts registered on this PXE Service.
+ * @returns An array of the accounts registered on this PXE Service.
+ */
+ getRegisteredAccounts(): Promise;
+
+ /**
+ * Registers a user contact in PXE.
+ *
+ * Once a new contact is registered, the PXE Service will be able to receive notes tagged from this contact.
+ * Will do nothing if the account is already registered.
+ *
+ * @param address - Address of the user to add to the address book
+ * @returns The address address of the account.
+ */
+ registerSender(address: AztecAddress): Promise;
+
+ /**
+ * Retrieves the addresses stored as senders on this PXE Service.
+ * @returns An array of the senders on this PXE Service.
+ */
+ getSenders(): Promise;
+
+ /**
+ * Removes a sender in the address book.
+ */
+ removeSender(address: AztecAddress): Promise;
+
+ /**
+ * Registers a contract class in the PXE without registering any associated contract instance with it.
+ *
+ * @param artifact - The build artifact for the contract class.
+ */
+ registerContractClass(artifact: ContractArtifact): Promise;
+
+ /**
+ * Adds deployed contracts to the PXE Service. Deployed contract information is used to access the
+ * contract code when simulating local transactions. This is automatically called by aztec.js when
+ * deploying a contract. Dapps that wish to interact with contracts already deployed should register
+ * these contracts in their users' PXE Service through this method.
+ *
+ * @param contract - A contract instance to register, with an optional artifact which can be omitted if the contract class has already been registered.
+ */
+ registerContract(contract: { instance: ContractInstanceWithAddress; artifact?: ContractArtifact }): Promise;
+
+ /**
+ * Updates a deployed contract in the PXE Service. This is used to update the contract artifact when
+ * an update has happened, so the new code can be used in the simulation of local transactions.
+ * This is called by aztec.js when instantiating a contract in a given address with a mismatching artifact.
+ * @param contractAddress - The address of the contract to update.
+ * @param artifact - The updated artifact for the contract.
+ */
+ updateContract(contractAddress: AztecAddress, artifact: ContractArtifact): Promise;
+
+ /**
+ * Retrieves the addresses of contracts added to this PXE Service.
+ * @returns An array of contracts addresses registered on this PXE Service.
+ */
+ getContracts(): Promise;
+
+ /**
+ * Proves the private portion of a simulated transaction, ready to send to the network
+ * (where valiators prove the public portion).
+ *
+ * @param txRequest - An authenticated tx request ready for proving
+ * @param privateExecutionResult - The result of the private execution of the transaction
+ * @returns A result containing the proof and public inputs of the tail circuit.
+ * @throws If contract code not found, or public simulation reverts.
+ * Also throws if simulatePublic is true and public simulation reverts.
+ */
+ proveTx(txRequest: TxExecutionRequest, privateExecutionResult: PrivateExecutionResult): Promise;
+
+ /**
+ * Simulates a transaction based on the provided preauthenticated execution request.
+ * This will run a local simulation of private execution (and optionally of public as well), run the
+ * kernel circuits to ensure adherence to protocol rules (without generating a proof), and return the
+ * simulation results .
+ *
+ *
+ * Note that this is used with `ContractFunctionInteraction::simulateTx` to bypass certain checks.
+ * In that case, the transaction returned is only potentially ready to be sent to the network for execution.
+ *
+ *
+ * @param txRequest - An authenticated tx request ready for simulation
+ * @param simulatePublic - Whether to simulate the public part of the transaction.
+ * @param msgSender - (Optional) The message sender to use for the simulation.
+ * @param skipTxValidation - (Optional) If false, this function throws if the transaction is unable to be included in a block at the current state.
+ * @param skipFeeEnforcement - (Optional) If false, fees are enforced.
+ * @param scopes - (Optional) The accounts whose notes we can access in this call. Currently optional and will default to all.
+ * @returns A simulated transaction result object that includes public and private return values.
+ * @throws If the code for the functions executed in this transaction have not been made available via `addContracts`.
+ * Also throws if simulatePublic is true and public simulation reverts.
+ */
+ simulateTx(
+ txRequest: TxExecutionRequest,
+ simulatePublic: boolean,
+ msgSender?: AztecAddress,
+ skipTxValidation?: boolean,
+ skipFeeEnforcement?: boolean,
+ scopes?: AztecAddress[],
+ ): Promise;
+
+ /**
+ * Profiles a transaction, reporting gate counts (unless disabled) and returns an execution trace.
+ *
+ * @param txRequest - An authenticated tx request ready for simulation
+ * @param msgSender - (Optional) The message sender to use for the simulation.
+ * @param skipTxValidation - (Optional) If false, this function throws if the transaction is unable to be included in a block at the current state.
+ * @returns A trace of the program execution with gate counts.
+ * @throws If the code for the functions executed in this transaction have not been made available via `addContracts`.
+ */
+ profileTx(
+ txRequest: TxExecutionRequest,
+ profileMode: 'gates' | 'execution-steps' | 'full',
+ msgSender?: AztecAddress,
+ ): Promise;
+
+ /**
+ * Sends a transaction to an Aztec node to be broadcasted to the network and mined.
+ * @param tx - The transaction as created via `proveTx`.
+ * @returns A hash of the transaction, used to identify it.
+ */
+ sendTx(tx: Tx): Promise;
+
+ /**
+ * Fetches a transaction receipt for a given transaction hash. Returns a mined receipt if it was added
+ * to the chain, a pending receipt if it's still in the mempool of the connected Aztec node, or a dropped
+ * receipt if not found in the connected Aztec node.
+ *
+ * @param txHash - The transaction hash.
+ * @returns A receipt of the transaction.
+ */
+ getTxReceipt(txHash: TxHash): Promise;
+
+ /**
+ * Get a tx effect.
+ * @param txHash - The hash of a transaction which resulted in the returned tx effect.
+ * @returns The requested tx effect.
+ */
+ getTxEffect(txHash: TxHash): Promise | undefined>;
+
+ /**
+ * Gets the storage value at the given contract storage slot.
+ *
+ * @remarks The storage slot here refers to the slot as it is defined in Noir not the index in the merkle tree.
+ * Aztec's version of `eth_getStorageAt`.
+ *
+ * @param contract - Address of the contract to query.
+ * @param slot - Slot to query.
+ * @returns Storage value at the given contract slot.
+ * @throws If the contract is not deployed.
+ */
+ getPublicStorageAt(contract: AztecAddress, slot: Fr): Promise;
+
+ /**
+ * Gets notes registered in this PXE based on the provided filter.
+ * @param filter - The filter to apply to the notes.
+ * @returns The requested notes.
+ */
+ getNotes(filter: NotesFilter): Promise;
+
+ /**
+ * Fetches an L1 to L2 message from the node.
+ * @param contractAddress - Address of a contract by which the message was emitted.
+ * @param messageHash - Hash of the message.
+ * @param secret - Secret used to compute a nullifier.
+ * @dev Contract address and secret are only used to compute the nullifier to get non-nullified messages
+ * @returns The l1 to l2 membership witness (index of message in the tree and sibling path).
+ */
+ getL1ToL2MembershipWitness(
+ contractAddress: AztecAddress,
+ messageHash: Fr,
+ secret: Fr,
+ ): Promise<[bigint, SiblingPath]>;
+
+ /**
+ * Gets the membership witness for a message that was emitted at a particular block
+ * @param blockNumber - The block number in which to search for the message
+ * @param l2Tol1Message - The message to search for
+ * @returns The membership witness for the message
+ */
+ getL2ToL1MembershipWitness(blockNumber: number, l2Tol1Message: Fr): Promise<[bigint, SiblingPath]>;
+
+ /**
+ * Get the given block.
+ * @param number - The block number being requested.
+ * @returns The blocks requested.
+ */
+ getBlock(number: number): Promise;
+
+ /**
+ * Method to fetch the current base fees.
+ * @returns The current base fees.
+ */
+ getCurrentBaseFees(): Promise;
+
+ /**
+ * Simulate the execution of an unconstrained function on a deployed contract without actually modifying state.
+ * This is useful to inspect contract state, for example fetching a variable value or calling a getter function.
+ * The function takes function name and arguments as parameters, along with the contract address
+ * and optionally the sender's address.
+ *
+ * @param functionName - The name of the function to be called in the contract.
+ * @param args - The arguments to be provided to the function.
+ * @param to - The address of the contract to be called.
+ * @param from - (Optional) The msg sender to set for the call.
+ * @param scopes - (Optional) The accounts whose notes we can access in this call. Currently optional and will default to all.
+ * @returns The result of the view function call, structured based on the function ABI.
+ */
+ simulateUnconstrained(
+ functionName: string,
+ args: any[],
+ to: AztecAddress,
+ authwits?: AuthWitness[],
+ from?: AztecAddress,
+ scopes?: AztecAddress[],
+ ): Promise;
+
+ /**
+ * Gets public logs based on the provided filter.
+ * @param filter - The filter to apply to the logs.
+ * @returns The requested logs.
+ */
+ getPublicLogs(filter: LogFilter): Promise;
+
+ /**
+ * Gets contract class logs based on the provided filter.
+ * @param filter - The filter to apply to the logs.
+ * @returns The requested logs.
+ */
+ getContractClassLogs(filter: LogFilter): Promise;
+
+ /**
+ * Fetches the current block number.
+ * @returns The block number.
+ */
+ getBlockNumber(): Promise;
+
+ /**
+ * Fetches the current proven block number.
+ * @returns The block number.
+ */
+ getProvenBlockNumber(): Promise;
+
+ /**
+ * Returns the information about the server's node. Includes current Node version, compatible Noir version,
+ * L1 chain identifier, protocol version, and L1 address of the rollup contract.
+ * @returns - The node information.
+ */
+ getNodeInfo(): Promise;
+
+ /**
+ * Returns information about this PXE.
+ */
+ getPXEInfo(): Promise;
+
+ /**
+ * Returns the contract metadata given an address.
+ * The metadata consists of its contract instance, which includes the contract class identifier,
+ * initialization hash, deployment salt, and public keys hash; whether the contract instance has been initialized;
+ * and whether the contract instance with the given address has been publicly deployed.
+ * @remark - it queries the node to check whether the contract instance has been initialized / publicly deployed through a node.
+ * This query is not dependent on the PXE.
+ * @param address - The address that the contract instance resides at.
+ * @returns - It returns the contract metadata
+ * TODO(@spalladino): Should we return the public keys in plain as well here?
+ */
+ getContractMetadata(address: AztecAddress): Promise;
+
+ /**
+ * Returns the contract class metadata given a contract class id.
+ * The metadata consists of its contract class, whether it has been publicly registered, and its artifact.
+ * @remark - it queries the node to check whether the contract class with the given id has been publicly registered.
+ * @param id - Identifier of the class.
+ * @param includeArtifact - Identifier of the class.
+ * @returns - It returns the contract class metadata, with the artifact field being optional, and will only be returned if true is passed in
+ * for `includeArtifact`
+ * TODO(@spalladino): The PXE actually holds artifacts and not classes, what should we return? Also,
+ * should the pxe query the node for contract public info, and merge it with its own definitions?
+ * TODO(@spalladino): This method is strictly needed to decide whether to publicly register a class or not
+ * during a public deployment. We probably want a nicer and more general API for this, but it'll have to
+ * do for the time being.
+ */
+ getContractClassMetadata(id: Fr, includeArtifact?: boolean): Promise;
+
+ /**
+ * Returns the private events given search parameters.
+ * @param eventMetadata - Metadata of the event. This should be the class generated from the contract. e.g. Contract.events.Event
+ * @param from - The block number to search from.
+ * @param limit - The amount of blocks to search.
+ * @param vpks - The incoming viewing public keys that can decrypt the log.
+ * @returns - The deserialized events.
+ */
+ getPrivateEvents(eventMetadata: EventMetadataDefinition, from: number, limit: number, vpks: Point[]): Promise;
+
+ /**
+ * Returns the public events given search parameters.
+ * @param eventMetadata - Metadata of the event. This should be the class generated from the contract. e.g. Contract.events.Event
+ * @param from - The block number to search from.
+ * @param limit - The amount of blocks to search.
+ * @returns - The deserialized events.
+ */
+ getPublicEvents(eventMetadata: EventMetadataDefinition, from: number, limit: number): Promise;
+}
+```
+> Source code: yarn-project/stdlib/src/interfaces/pxe.ts#L43-L374
+
diff --git a/docs/versioned_docs/version-v0.82.2-alpha-testnet.5/aztec/concepts/wallets/index.md b/docs/versioned_docs/version-v0.82.2-alpha-testnet.5/aztec/concepts/wallets/index.md
new file mode 100644
index 000000000000..82ec9b09f89b
--- /dev/null
+++ b/docs/versioned_docs/version-v0.82.2-alpha-testnet.5/aztec/concepts/wallets/index.md
@@ -0,0 +1,75 @@
+---
+title: Wallets
+sidebar_position: 2
+tags: [accounts]
+---
+
+On this page we will cover the main responsibilities of a wallet in the Aztec network.
+
+Refer to [writing an account contract](../../../developers/tutorials/codealong/contract_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.
+
+Wallets are the applications through which users manage their accounts. Users rely on wallets to browse through their accounts, monitor their balances, and create new accounts. Wallets also store seed phrases and private keys, or interact with external keystores such as hardware wallets.
+
+Wallets also provide an interface for dapps. Dapps may request access to see the user accounts, in order to show the state of those accounts in the context of the application, and request to send transactions from those accounts as the user interacts with the dapp.
+
+In addition to these usual responsibilities, wallets in Aztec also need to track private state. This implies keeping a local database of all private notes encrypted for any of the user's accounts, so dapps and contracts can query the user's private state. Aztec wallets are also responsible for producing local proofs of execution for private functions.
+
+## Account setup
+
+The first step for any wallet is to let the user set up their [accounts](../accounts/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, 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/v0.82.2/yarn-project/aztec.js/src/account/interface.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](../accounts/keys.md#address-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.
+
+## Transaction lifecycle
+
+Every transaction in Aztec is broadcast to the network as a zero-knowledge proof of correct execution, in order to preserve privacy. This means that transaction proofs are generated on the wallet and not on a remote node. This is one of the biggest differences with regard to EVM chain wallets.
+
+A wallet is responsible for **creating** an _execution request_ out of one or more _function calls_ requested by a dapp. For example, a dapp may request a wallet to "invoke the `transfer` function on the contract at `0x1234` with the following arguments", in response to a user action. The wallet turns that into an execution request with the signed instructions to execute that function call from the user's account contract. In an [ECDSA-based account](https://github.com/AztecProtocol/aztec-packages/blob/master/noir-projects/noir-contracts/contracts/ecdsa_k_account_contract/src/main.nr), for instance, this is an execution request that encodes the function call in the _entrypoint payload_, and includes its ECDSA signature with the account's signing private key.
+
+Once the _execution request_ is created, the wallet is responsible for **simulating** and **proving** the execution of its private functions. The simulation yields an execution trace, which can be used to provide the user with a list of side effects of the private execution of the transaction. During this simulation, the wallet is responsible of providing data to the virtual machine, such as private notes, encryption keys, or nullifier secrets. This execution trace is fed into the prover, which returns a zero-knowledge proof that guarantees correct execution and hides all private information. The output of this process is a _transaction object_.
+
+:::info
+Since private functions rely on a UTXO model, the private execution trace of a transaction is determined exclusively by the notes used as inputs. Since these notes are immutable, the trace of a transaction is always the same, so any effects observed during simulation will be exactly the same when the transaction is mined. However, the transaction may be dropped if it attempts to consume a private note that another transaction nullified before it gets mined. Note that this applies only to private function execution. Public functions rely on an account model, similar to Ethereum, so their execution trace depends on the chain's public state at the point they are included in a block, which may have changed since the transaction was simulated locally.
+:::
+
+Finally, the wallet **sends** the resulting _transaction_ object, which includes the proof of execution, to an Aztec Node. The transaction is then broadcasted through the peer-to-peer network, to be eventually picked up by a sequencer and included in a block.
+
+:::warning
+There are no proofs generated as of the Sandbox release. This will be included in a future release before testnet.
+:::
+
+## Authorizing actions
+
+Account contracts in Aztec expose an interface for other contracts to validate [whether an action is authorized by the account or not](../accounts/index.md#authorizing-actions). For example, an application contract may want to transfer tokens on behalf of a user, in which case the token contract will check with the account contract whether the application is authorized to do so. These actions may be carried out in private or in public functions, and in transactions originated by the user or by someone else.
+
+Wallets should manage these authorizations, prompting the user when they are requested by an application. Authorizations in private executions come in the form of _auth witnesses_, which are usually signatures over an identifier for an action. Applications can request the wallet to produce an auth witness via the `createAuthWit` call. In public functions, authorizations are pre-stored in the account contract storage, which is handled by a call to an internal function in the account contract implementation.
+
+## Key management
+
+As in EVM-based chains, wallets are expected to manage user keys, or provide an interface to hardware wallets or alternative key stores. Keep in mind that in Aztec each account requires [two sets of keys](../accounts/keys.md): privacy keys and authentication keys. Privacy keys are mandated by the protocol and used for encryption and nullification, whereas authentication keys are dependent on the account contract implementation rolled out by the wallet. Should the account contract support it, wallets must provide the user with the means to rotate or recover their authentication keys.
+
+:::info
+Due to limitations in the current architecture, privacy keys need to be available in the wallet software itself and cannot be punted to an external keystore. This restriction may be lifted in a future release.
+:::
+
+## Recipient encryption keys
+
+Wallets are also expected to manage the public encryption keys of any recipients of local transactions. When creating an encrypted note for a recipient given their address, the wallet needs to provide their [complete address](../accounts/keys.md#address-keys). Recipients broadcast their complete addresses when deploying their account contracts, and wallets collect this information and save it in a local registry for easy access when needed.
+
+Note that, in order to interact with a recipient who has not yet deployed their account contract (and thus not broadcasted their complete address), it must also be possible to manually add an entry to a wallet's local registry of complete addresses.
+
+## Private state
+
+Last but not least, wallets also store the user's private state. Wallets currently rely on brute force decryption, where every new block is downloaded and its encrypted data blobs are attempted to be decrypted with the user decryption keys. Whenever a blob is decrypted properly, it is added to the corresponding account's private state. Note that wallets must also scan for private state in blocks prior to the deployment of a user's account contract, since users may have received private state before deployment.
+
+:::info
+At the time of this writing, all private state is encrypted and broadcasted through the network, and eventually committed to L1. This means that a wallet can reconstruct its entire private state out of its encryption keys in the event of local data loss.
+:::
+
+Encrypted data blobs do not carry any public information as to whom their recipient is. Therefore, it is not possible for a remote node to identify the notes that belong to a user, and it is not possible for a wallet to query a remote node for its private state. As such, wallets need to keep a local database of their accounts private state, in order to be able to answer any queries on their private state.
+
+Dapps may require access to the user's private state, in order to show information relevant to the current application. For instance, a dapp for a token may require access to the user's private notes in the token contract in order to display the user's balance. It is responsibility of the wallet to require authorization from the user before disclosing private state to a dapp.
diff --git a/docs/versioned_docs/version-v0.82.2-alpha-testnet.5/aztec/glossary/call_types.md b/docs/versioned_docs/version-v0.82.2-alpha-testnet.5/aztec/glossary/call_types.md
new file mode 100644
index 000000000000..5b7ba8853bd7
--- /dev/null
+++ b/docs/versioned_docs/version-v0.82.2-alpha-testnet.5/aztec/glossary/call_types.md
@@ -0,0 +1,281 @@
+---
+title: Call Types
+---
+
+## What is a Call
+
+We say that a smart contract is called when one of its functions is invoked and its code is run. This means there'll be:
+
+- a caller
+- arguments
+- return values
+- a call status (successful or failed)
+
+There are multiple types of calls, and some of the naming can make things **very** confusing. This page lists the different call types and execution modes, pointing out key differences between them.
+
+## Ethereum Call Types
+
+Even though we're discussing Aztec, its design is heavily influenced by Ethereum and many of the APIs and concepts are quite similar. It is therefore worthwhile to briefly review how things work there and what naming conventions are used to provide context to the Aztec-specific concepts.
+
+Broadly speaking, Ethereum contracts can be thought of as executing as a result of three different things: running certain EVM opcodes, running Solidity code (which compiles to EVM opcodes), or via the node JSON-RPC interface (e.g. when executing transactions).
+
+### EVM
+
+Certain opcodes allow contracts to make calls to other contracts, each with different semantics. We're particularly interested in `CALL` and `STATICCALL`, and how those relate to contract programming languages and client APIs.
+
+#### `CALL`
+
+This is the most common and basic type of call. It grants execution control to the caller until it eventually returns. No special semantics are in play here. Most Ethereum transactions spend the majority of their time in `CALL` contexts.
+
+#### `STATICCALL`
+
+This behaves almost exactly the same as `CALL`, with one key difference: any state-changing operations are forbidden and will immediately cause the call to fail. This includes writing to storage, emitting logs, or deploying new contracts. This call is used to query state on an external contract, e.g. to get data from a price oracle, check for access control permissions, etc.
+
+#### Others
+
+The `CREATE` and `CREATE2` opcodes (for contract deployment) also result in something similar to a `CALL` context, but all that's special about them has to do with how deployments work. `DELEGATECALL` (and `CALLCODE`) are somewhat complicated to understand but don't have any Aztec equivalents, so they are not worth covering.
+
+### Solidity
+
+Solidity (and other contract programming languages such as Vyper) compile down to EVM opcodes, but it is useful to understand how they map language concepts to the different call types.
+
+#### Mutating External Functions
+
+These are functions marked `payable` (which can receive ETH, which is a state change) or with no mutability declaration (sometimes called `nonpayable`). When one of these functions is called on a contract, the `CALL` opcode is emitted, meaning the callee can perform state changes, make further `CALL`s, etc.
+
+It is also possible to call such a function with `STATICCALL` manually (e.g. using assembly), but the execution will fail as soon as a state-changing opcode is executed.
+
+#### `view`
+
+An external function marked `view` will not be able to mutate state (write to storage, etc.), it can only _view_ the state. Solidity will emit the `STATICCALL` opcode when calling these functions, since its restrictions provide added safety to the caller (e.g. no risk of reentrancy).
+
+Note that it is entirely possible to use `CALL` to call a `view` function, and the result will be the exact same as if `STATICCALL` had been used. The reason why `STATICCALL` exists is so that _untrusted or unknown_ contracts can be called while still being able to reason about correctness. From the [EIP](https://eips.ethereum.org/EIPS/eip-214):
+
+> '`STATICCALL` adds a way to call other contracts and restrict what they can do in the simplest way. It can be safely assumed that the state of all accounts is the same before and after a static call.'
+
+### JSON-RPC
+
+From outside the EVM, calls to contracts are made via [JSON-RPC](https://ethereum.org/en/developers/docs/apis/json-rpc/) methods, typically from some client library that is aware of contract ABIs, such as [ethers.js](https://docs.ethers.org/v5) or [viem](https://viem.sh/).
+
+#### `eth_sendTransaction`
+
+This method is how transactions are sent to a node to get them to be broadcast and eventually included in a block. The specified `to` address will be called in a `CALL` context, with some notable properties:
+
+- there are no return values, even if the contract function invoked does return some data
+- there is no explicit caller: it is instead derived from a provided signature
+
+Some client libraries choose to automatically issue `eth_sendTransaction` when calling functions from a contract ABI that are not marked as `view` - [ethers is a good example](https://docs.ethers.org/v5/getting-started/#getting-started--writing). Notably, this means that any return value is lost and not available to the calling client - the library typically returns a transaction receipt instead. If the return value is required, then the only option is to simulate the call `eth_call`.
+
+Note that it is possible to call non state-changing functions (i.e. `view`) with `eth_sendTransaction` - this is always meaningless. What transactions do is change the blockchain state, so all calling such a function achieves is for the caller to lose funds by paying for gas fees. The sole purpose of a `view` function is to return data, and `eth_sendTransaction` does not make the return value available.
+
+#### `eth_call`
+
+This method is the largest culprit of confusion around calls, but unfortunately requires understanding of all previous concepts in order to be explained. Its name is also quite unhelpful.
+
+What `eth_call` does is simulate a transaction (a call to a contract) given the current blockchain state. The behavior will be the exact same as `eth_sendTransaction`, except:
+
+- no actual transaction will be created
+- while gas _will_ be measured, there'll be no transaction fees of any kind
+- no signature is required: the `from` address is passed directly, and can be set to any value (even if the private key is unknown, or if they are contract addresses!)
+- the return value of the called contract is available
+
+`eth_call` is typically used for one of the following:
+
+- query blockchain data, e.g. read token balances
+- preview the state changes produced by a transaction, e.g. the transaction cost, token balance changes, etc
+
+Because some libraries ([such as ethers](https://docs.ethers.org/v5/getting-started/#getting-started--reading)) automatically use `eth_call` for `view` functions (which when called via Solidity result in the `STATICCALL` opcode), these concepts can be hard to tell apart. The following bears repeating: **an `eth_call`'s call context is the same as `eth_sendTransaction`, and it is a `CALL` context, not `STATICCALL`.**
+
+## Aztec Call Types
+
+Large parts of the Aztec Network's design are still not finalized, and the nitty-gritty of contract calls is no exception. This section won't therefore contain a thorough review of these, but rather list some of the main ways contracts can currently be interacted with, with analogies to Ethereum call types when applicable.
+
+While Ethereum contracts are defined by bytecode that runs on the EVM, Aztec contracts have multiple modes of execution depending on the function that is invoked.
+
+### Private Execution
+
+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
+
+Private functions from other contracts can be called either regularly or statically by using the `.call()` and `.static_call` functions. They will also be 'executed' (i.e. proved) in the user's device, and `static_call` will fail if any state changes are attempted (like the EVM's `STATICCALL`).
+
+```rust title="private_call" showLineNumbers
+let _ = Token::at(stable_coin).burn_private(from, amount, nonce).call(&mut context);
+```
+> Source code: noir-projects/noir-contracts/contracts/lending_contract/src/main.nr#L254-L256
+
+
+Unlike the EVM however, private execution doesn't revert in the traditional way: in case of error (e.g. a failed assertion, a state changing operation in a static context, etc.) the proof generation simply fails and no transaction request is generated, spending no network gas or user funds.
+
+#### Public Calls
+
+Since public execution can only be performed by the sequencer, public functions cannot be executed in a private context. It is possible however to _enqueue_ a public function call during private execution, requesting the sequencer to run it during inclusion of the transaction. It will be [executed in public](#public-execution) normally, including the possibility to enqueue static public calls.
+
+Since the public call is made asynchronously, any return values or side effects are not available during private execution. If the public function fails once executed, the entire transaction is reverted including state changes caused by the private part, such as new notes or nullifiers. Note that this does result in gas being spent, like in the case of the EVM.
+
+```rust title="enqueue_public" showLineNumbers
+Lending::at(context.this_address())
+ ._deposit(AztecAddress::from_field(on_behalf_of), amount, collateral_asset)
+ .enqueue(&mut context);
+```
+> Source code: noir-projects/noir-contracts/contracts/lending_contract/src/main.nr#L119-L123
+
+
+It is also possible to create public functions that can _only_ be invoked by privately enqueueing a call from the same contract, which can be 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.
+
+```rust title="enqueueing" showLineNumbers
+Router::at(ROUTER_ADDRESS).check_block_number(operation, value).call(context);
+```
+> Source code: noir-projects/noir-contracts/contracts/router_contract/src/utils.nr#L17-L19
+
+
+Note that this reveals what public function is being called on what contract, and perhaps more importantly which contract enqueued the call during private execution.
+For this reason we've created a canonical router contract which implements some of the checks commonly performed: this conceals the calling contract, as the `context.msg_sender()` in the public function will be the router itself (since it is the router that enqueues the public call).
+
+An example of how a deadline can be checked using the router contract follows:
+
+```rust title="call-check-deadline" showLineNumbers
+privately_check_timestamp(Comparator.LT, config.deadline, &mut context);
+```
+> Source code: noir-projects/noir-contracts/contracts/crowdfunding_contract/src/main.nr#L68-L70
+
+
+`privately_check_timestamp` and `privately_check_block_number` are helper functions around the call to the router contract:
+
+```rust title="helper_router_functions" showLineNumbers
+/// Asserts that the current timestamp in the enqueued public call enqueued by `check_timestamp` satisfies
+/// the `operation` with respect to the `value. Preserves privacy by performing the check via the router contract.
+/// This conceals an address of the calling contract by setting `context.msg_sender` to the router contract address.
+pub fn privately_check_timestamp(operation: u8, value: u64, context: &mut PrivateContext) {
+ Router::at(ROUTER_ADDRESS).check_timestamp(operation, value).call(context);
+}
+
+/// Asserts that the current block number in the enqueued public call enqueued by `check_block_number` satisfies
+/// the `operation` with respect to the `value. Preserves privacy by performing the check via the router contract.
+/// This conceals an address of the calling contract by setting `context.msg_sender` to the router contract address.
+pub fn privately_check_block_number(operation: u8, value: Field, context: &mut PrivateContext) {
+ Router::at(ROUTER_ADDRESS).check_block_number(operation, value).call(context);
+}
+```
+> Source code: noir-projects/noir-contracts/contracts/router_contract/src/utils.nr#L5-L21
+
+
+This is what the implementation of the check timestamp functionality looks like:
+
+```rust title="check_timestamp" showLineNumbers
+/// Asserts that the current timestamp in the enqueued public call satisfies the `operation` with respect
+/// to the `value.
+#[private]
+fn check_timestamp(operation: u8, value: u64) {
+ Router::at(context.this_address())._check_timestamp(operation, value).enqueue_view(
+ &mut context,
+ );
+}
+
+#[public]
+#[internal]
+#[view]
+fn _check_timestamp(operation: u8, value: u64) {
+ let lhs_field = context.timestamp() as Field;
+ let rhs_field = value as Field;
+ assert(compare(lhs_field, operation, rhs_field), "Timestamp mismatch.");
+}
+```
+> Source code: noir-projects/noir-contracts/contracts/router_contract/src/main.nr#L13-L31
+
+
+:::note
+Note that the router contract is not currently part of the [aztec-nr repository](https://github.com/AztecProtocol/aztec-nr).
+To add it as a dependency point to the aztec-packages repository instead:
+```toml
+[dependencies]
+aztec = { git = "https://github.com/AztecProtocol/aztec-packages/", tag = "v0.82.2", directory = "noir-projects/noir-contracts/contracts/router_contract/src" }
+```
+:::
+
+Even with the router contract achieving good privacy is hard.
+For example, if the value being checked against is unique and stored in the contract's public storage, it's then simple to find private transactions that are using that value in the enqueued public reads, and therefore link them to this contract.
+For this reason it is encouraged to try to avoid public function calls and instead privately read [Shared State](../../developers/reference/smart_contract_reference/storage/shared_state.md) when possible.
+
+### Public Execution
+
+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.
+
+Public functions in other contracts can be called both regularly and statically, just like on the EVM.
+
+```rust title="public_call" showLineNumbers
+Token::at(config.accepted_asset)
+ .transfer_in_public(context.msg_sender(), context.this_address(), max_fee, nonce)
+ .enqueue(&mut context);
+```
+> Source code: noir-projects/noir-contracts/contracts/fpc_contract/src/main.nr#L156-L160
+
+
+:::note
+This is the same function that was called by privately enqueuing a call to it! Public functions can be called either directly in a public context, or asynchronously by enqueuing in a private context.
+:::
+
+### Top-level Unconstrained
+
+Contract functions with the `unconstrained` Noir keyword are a special type of function still under development, and their semantics will likely change in the near future. They are used to perform state queries from an off-chain client (from both private and public state!), and are never included in any transaction. No guarantees are made on the correctness of the result since the entire execution is unconstrained and heavily reliant on oracle calls.
+
+Any programming language could be used to construct these queries, since all they do is perform arbitrary computation on data that is either publicly available from any node, or locally available from the PXE. Top-level unconstrained functions exist because they let developers utilize the rest of the contract code directly by being part of the same Noir contract, and e.g. use the same libraries, structs, etc. instead of having to rely on manual computation of storage slots, struct layout and padding, and so on.
+
+A reasonable mental model for them is that of a Solidity `view` function that can never be called in any transaction, and is only ever invoked via `eth_call`. Note that in these the caller assumes that the node is acting honestly by executing the true contract bytecode with correct blockchain state, the same way the Aztec version assumes the oracles are returning legitimate data.
+
+### aztec.js
+
+There are three different ways to execute an Aztec contract function using the `aztec.js` library, with close similarities to their [JSON-RPC counterparts](#json-rpc).
+
+#### `simulate`
+
+This is used to get a result out of an execution, either private or public. It creates no transaction and spends no gas. The mental model is fairly close to that of [`eth_call`](#eth_call), in that it can be used to call any type of function, simulate its execution and get a result out of it. `simulate` is also the only way to run [top-level unconstrained functions](#top-level-unconstrained).
+
+```rust title="public_getter" showLineNumbers
+#[public]
+#[view]
+fn get_authorized() -> AztecAddress {
+ storage.authorized.get_current_value()
+}
+```
+> Source code: noir-projects/noir-contracts/contracts/auth_contract/src/main.nr#L42-L50
+
+
+```typescript title="simulate_function" showLineNumbers
+const balance = await contract.methods.balance_of_public(newWallet.getAddress()).simulate();
+expect(balance).toEqual(1n);
+```
+> Source code: yarn-project/end-to-end/src/composed/docs_examples.test.ts#L54-L57
+
+
+:::warning
+No correctness is guaranteed on the result of `simulate`! Correct execution is entirely optional and left up to the client that handles this request.
+:::
+
+#### `prove`
+
+This creates and returns a transaction request, which includes proof of correct private execution and side-effects. The request is not broadcast however, and no gas is spent. It is typically used in testing contexts to inspect transaction parameters or to check for execution failure.
+
+```typescript title="local-tx-fails" showLineNumbers
+const call = token.methods.transfer(recipient.getAddress(), 200n);
+await expect(call.prove()).rejects.toThrow(/Balance too low/);
+```
+> Source code: yarn-project/end-to-end/src/guides/dapp_testing.test.ts#L123-L126
+
+
+Like most Ethereum libraries, `prove` also simulates public execution to try to detect runtime errors that would only occur once the transaction is picked up by the sequencer. This makes `prove` very useful in testing environments, but users should be wary of both false positives and negatives in production environments, particularly if the node's data is stale. Public simulation can be skipped by setting the `skipPublicSimulation` flag.
+
+#### `send`
+
+This is the same as [`prove`](#prove) except it also broadcasts the transaction and returns a receipt. This is how transactions are sent, getting them to be included in blocks and spending gas. It is similar to [`eth_sendTransaction`](#eth_sendtransaction), except it also performs some work on the user's device, namely the production of the proof for the private part of the transaction.
+
+```typescript title="send_tx" showLineNumbers
+await contract.methods.buy_pack(seed).send().wait();
+```
+> Source code: yarn-project/end-to-end/src/e2e_card_game.test.ts#L129-L131
+
diff --git a/docs/versioned_docs/version-v0.82.2-alpha-testnet.5/aztec/glossary/index.md b/docs/versioned_docs/version-v0.82.2-alpha-testnet.5/aztec/glossary/index.md
new file mode 100644
index 000000000000..efe652c62aff
--- /dev/null
+++ b/docs/versioned_docs/version-v0.82.2-alpha-testnet.5/aztec/glossary/index.md
@@ -0,0 +1,75 @@
+---
+title: Glossary
+---
+
+### `aztec-nargo`
+
+The command line tool used to compile Aztec contracts. It gets its name from the Noir compiler, `nargo`. `aztec-nargo` is really just a specific version of `nargo`. You can read more about `nargo` [here](#nargo).
+
+### Aztec.nr
+
+A [Noir](https://noir-lang.org) framework for writing smart contracts on Aztec.
+
+Read more and review the source code [here](https://aztec.nr).
+
+### Barretenberg
+
+Aztec's cryptography back-end. Refer to the graphic at the top of [this page](https://medium.com/aztec-protocol/explaining-the-network-in-aztec-network-166862b3ef7d) to see how it fits in the Aztec architecture.
+
+Barretenberg's source code can be found [here](https://github.com/AztecProtocol/barretenberg).
+
+### `nargo`
+
+With `nargo`, you can start new projects, compile, execute, prove, verify, test, generate solidity contracts, and do pretty much all that is available in Noir.
+
+You can find more information in the nargo installation docs [here](https://noir-lang.org/docs/getting_started/installation/) and the nargo command reference [here](https://noir-lang.org/docs/reference/nargo_commands).
+
+### Noir
+
+Noir is a Domain Specific Language for SNARK proving systems. It is used for writing smart contracts in Aztec because private functions on Aztec are implemented as SNARKs to support privacy-preserving operations.
+
+### Provers
+
+Aztec will be launched with a fully permissionless proving network that anyone can participate in.
+
+How this works will be discussed via a future RFP process on Discourse, similarly to the Sequencer RFP.
+
+### Private Execution Environment
+
+The Private eXecution Environment (PXE) is a client-side library for the execution of private operations. The PXE generates proofs of private function execution, and sends these proofs along with public function requests to the sequencer. Private inputs never leave the client-side PXE.
+
+Read more [here](../concepts/pxe/index.md).
+
+### Sequencer
+
+Aztec will be launched with a fully permissionless sequencer network that anyone can participate in.
+
+How this works is being discussed actively in the [Discourse forum](https://discourse.aztec.network/t/request-for-proposals-decentralized-sequencer-selection/350/). Once this discussion process is completed, we will update the glossary and documentation with specifications and instructions for how to run.
+
+Sequencers are generally responsible for:
+
+- Selecting pending transactions from the mempool
+- Ordering transactions into a block
+- Verifying all private transaction proofs and execute all public transactions to check their validity
+- Computing the ROLLUP_BLOCK_REQUEST_DATA
+- Computing state updates for messages between L2 & L1
+- Broadcasting the ROLLUP_BLOCK_REQUEST_DATA to the prover network via the proof pool for parallelizable computation.
+- Building a rollup proof from completed proofs in the proof pool
+- Tagging the pending block with an upgrade signal to facilitate forks
+- Publishing completed block with proofs to Ethereum as an ETH transaction
+
+Previously in [Aztec Connect](https://medium.com/aztec-protocol/sunsetting-aztec-connect-a786edce5cae) there was a single sequencer, and you can find the Typescript reference implementation called Falafel [here](https://github.com/AztecProtocol/aztec-connect/tree/master/yarn-project/falafel).
+
+### Smart Contracts
+
+Programs that run on the Aztec network are called smart contracts, similar to [programs](https://ethereum.org/en/developers/docs/smart-contracts/) that run on Ethereum.
+
+However, these will be written in the [Noir](https://noir-lang.org/index.html) programming language, and may optionally include private state and private functions.
+
+### Proving Key
+
+A key that is used to generate a proof. In the case of Aztec, these are compiled from Noir smart contracts.
+
+### Verification Key
+
+A key that is used to verify the validity of a proof generated from a proving key from the same smart contract.
diff --git a/docs/versioned_docs/version-v0.82.2-alpha-testnet.5/aztec/how_to_participate.md b/docs/versioned_docs/version-v0.82.2-alpha-testnet.5/aztec/how_to_participate.md
new file mode 100644
index 000000000000..220d8adeb842
--- /dev/null
+++ b/docs/versioned_docs/version-v0.82.2-alpha-testnet.5/aztec/how_to_participate.md
@@ -0,0 +1,22 @@
+---
+title: How to Participate?
+sidebar_position: 4
+---
+
+Decentralization is one of our core values, so we want to encourage participation as much as possible and in any way you can.
+
+## Improve the protocol
+
+- Join us at our [Discourse forum](https://discourse.aztec.network/) or [Discord server](https://discord.com/invite/aztec) to discuss all things related to Aztec and share your feedback
+
+## Contribute code
+
+- Check out the monorepo on GitHub [here](https://github.com/AztecProtocol/aztec-packages)
+- We have some [good first issues](https://github.com/AztecProtocol/aztec-packages/labels/good%20first%20issue) for newcomers
+- Anyone can open an issue, so please feel free to create one
+- If you've built something for the ecosystem that others should see, add it to the [Awesome-Aztec Repo](https://github.com/AztecProtocol/awesome-aztec)
+
+## Grants
+
+- The Aztec Labs Grants Program supports developers building with, and contributing to, the Noir programming language and the Aztec network. Applications can be submitted on the [Grants page](https://aztec.network/grants/) of the Aztec website.
+- We are currently operating with a retroactive grants funding model, and we strive to respond back to grants applications with a decision within a few days. Check out our [grants page](https://aztec.network/grants/) for more information
diff --git a/docs/versioned_docs/version-v0.82.2-alpha-testnet.5/aztec/index.md b/docs/versioned_docs/version-v0.82.2-alpha-testnet.5/aztec/index.md
new file mode 100644
index 000000000000..d3292e7ac3ee
--- /dev/null
+++ b/docs/versioned_docs/version-v0.82.2-alpha-testnet.5/aztec/index.md
@@ -0,0 +1,152 @@
+---
+title: Aztec Overview
+sidebar_position: 0
+tags: [protocol]
+---
+
+import Image from "@theme/IdealImage";
+
+This page outlines Aztec's fundamental technical concepts. It is recommended to read this before diving into building on Aztec.
+
+## What is Aztec?
+
+Aztec is a privacy-first Layer 2 on Ethereum. It supports smart contracts with both private & public state and private & public execution.
+
+## High level view
+
+
+
+1. A user interacts with Aztec through Aztec.js (like web3js or ethersjs)
+2. Private functions are executed in the PXE, which is client-side
+3. Proofs and tree updates are sent to the Public VM (running on an Aztec node)
+4. Public functions are executed in the Public VM
+5. The Public VM rolls up the transactions that include private and public state updates into blocks
+6. The block data and proof of a correct state transition are submitted to Ethereum for verification
+
+## Private and public execution
+
+Private functions are executed client side, on user devices to maintain maximum privacy. Public functions are executed by a remote network of nodes, similar to other blockchains. These distinct execution environments create a directional execution flow for a single transaction--a transaction begins in the private context on the user's device then moves to the public network. This means that private functions executed by a transaction can enqueue public functions to be executed later in the transaction life cycle, but public functions cannot call private functions.
+
+### Private Execution Environment (PXE)
+
+Private functions are executed first on the user's device in the Private Execution Environment (PXE, pronounced 'pixie'). It is a client-side library for the execution of private operations. It holds keys, notes, and generates proofs. It is included in aztec.js, a TypeScript library, and can be run within Node or the browser.
+
+### Aztec VM
+
+Public functions are executed by the Aztec Virtual Machine (AVM), which is conceptually similar to the Ethereum Virtual Machine (EVM).
+
+The PXE is unaware of the Public VM. And the Public VM is unaware of the PXE. They are completely separate execution environments. This means:
+
+- The PXE and the Public VM cannot directly communicate with each other
+- Private transactions in the PXE are executed first, followed by public transactions
+
+## Private and public state
+
+Private state works with UTXOs, which are chunks of data that we call notes. To keep things private, notes are stored in an [append-only UTXO tree](./concepts/advanced/storage/indexed_merkle_tree.mdx), and a nullifier is created when notes are invalidated (aka deleted). Nullifiers are stored in their own [nullifier tree](./concepts/advanced/storage/indexed_merkle_tree.mdx).
+
+Public state works similarly to other chains like Ethereum, behaving like a public ledger. Public data is stored in a public data tree.
+
+
+
+Aztec [smart contract](./smart_contracts_overview.md) developers should keep in mind that different data types are used when manipulating private or public state. Working with private state is creating commitments and nullifiers to state, whereas working with public state is directly updating state.
+
+## Accounts and keys
+
+### Account abstraction
+
+Every account in Aztec is a smart contract (account abstraction). This allows implementing different schemes for authorizing transactions, nonce management, and fee payments.
+
+Developers can write their own account contract to define the rules by which user transactions are authorized and paid for, as well as how user keys are managed.
+
+Learn more about account contracts [here](./concepts/accounts/index.md).
+
+### Key pairs
+
+Each account in Aztec is backed by 3 key pairs:
+
+- A **nullifier key pair** used for note nullifier computation
+- A **incoming viewing key pair** used to encrypt a note for the recipient
+- A **outgoing viewing key pair** used to encrypt a note for the sender
+
+As Aztec has native account abstraction, accounts do not automatically have a signing key pair to authenticate transactions. This is up to the account contract developer to implement.
+
+## Noir
+
+Noir is a zero-knowledge domain specific language used for writing smart contracts for the Aztec network. It is also possible to write circuits with Noir that can be verified on or offchain. For more in-depth docs into the features of Noir, go to the [Noir documentation](https://noir-lang.org/).
+
+## What's next?
+
+### Start coding
+
+
+
+
+
Developer Getting Started Guide
+
+
+ Follow the getting started guide to start developing with the Aztec Sandbox
+
+
+
+
+### Dive deeper into how Aztec works
+
+Explore the Concepts for a deeper understanding into the components that make up Aztec:
+
+
+
+
+
+
Accounts
+
+
+ Learn about Aztec's native account abstraction - every account in Aztec is a smart contract which defines the rules for whether a transaction is or is not valid
+
+
+
+
+
+
PXE (pronounced 'pixie')
+
+
+ The Private Execution Environment (or PXE) is a client-side library for the execution of private operations
+
+
+
+
+
+
State model
+
+
+ Aztec has a hybrid public/private state model
+
+
+
+
+
+
Storage
+
+
+ In Aztec, private data and public data are stored in two trees: a public data tree and a note hashes tree
+
+
+
+
+
+
Wallets
+
+
+ Wallets expose to dapps an interface that allows them to act on behalf of the user, such as querying private state or sending transactions
+
+
+
+
+
+
Protocol Circuits
+
+
+ Central to Aztec's operations are circuits in the core protocol and the developer-written Aztec.nr contracts
+
+
+
+
diff --git a/docs/versioned_docs/version-v0.82.2-alpha-testnet.5/aztec/network/_category_.json b/docs/versioned_docs/version-v0.82.2-alpha-testnet.5/aztec/network/_category_.json
new file mode 100644
index 000000000000..ea3bb9ef6617
--- /dev/null
+++ b/docs/versioned_docs/version-v0.82.2-alpha-testnet.5/aztec/network/_category_.json
@@ -0,0 +1,6 @@
+{
+ "position": 8,
+ "collapsible": true,
+ "collapsed": true,
+ "label": "Nodes and Clients"
+}
diff --git a/docs/versioned_docs/version-v0.82.2-alpha-testnet.5/aztec/network/sequencer/index.md b/docs/versioned_docs/version-v0.82.2-alpha-testnet.5/aztec/network/sequencer/index.md
new file mode 100644
index 000000000000..e541d1fdd544
--- /dev/null
+++ b/docs/versioned_docs/version-v0.82.2-alpha-testnet.5/aztec/network/sequencer/index.md
@@ -0,0 +1,45 @@
+---
+title: Sequencer
+tags: [protocol, sequencer]
+draft: true
+---
+
+The sequencer is a module responsible for creating and publishing new rollup blocks. This involves fetching txs from the P2P pool, ordering them, executing any public functions, running them through the rollup circuits, assembling the L2 block, and posting it to the L1 rollup contract along with any contract deployment public data.
+
+On every new block assembled, it modifies the world state database to reflect the txs processed, but these changes are only committed once the world state synchronizer sees the new block on L1.
+
+## Components
+
+The **block builder** is responsible for assembling an L2 block out of a set of processed transactions (we say a tx has been processed if all its function calls have been executed). This involves running the txs through the base, merge, and rollup circuits, updating the world state trees, and building the L2 block object.
+
+The **prover** generates proofs for every circuit used. For the time being, no proofs are being actually generated, so the only implementation is an empty one.
+
+The **publisher** deals with sending L1 transactions to the rollup and contract deployment emitter contracts. It is responsible for assembling the Ethereum tx, choosing reasonable gas settings, and monitoring the tx until it gets mined. Note that the current implementation does not handle unstable network conditions (gas price spikes, reorgs, etc).
+
+The **public processor** executes any public function calls in the transactions. Unlike private function calls, which are resolved in the client, public functions require access to the latest data trees, so they are executed by the sequencer, much like in any non-private L2.
+
+The **simulator** is an interface to the wasm implementations of the circuits used by the sequencer.
+
+The **sequencer** pulls txs from the P2P pool, orchestrates all the components above to assemble and publish a block, and updates the world state database.
+
+## Circuits
+
+What circuits does the sequencer depend on?
+
+The **public circuit** is responsible for proving the execution of Brillig (public function bytecode). At the moment, we are using a fake version that actually runs ACIR (intermediate representation for private functions) and does not emit any proofs.
+
+The **public kernel circuit** then validates the output of the public circuit, and outputs a set of changes to the world state in the same format as the private kernel circuit, meaning we get a standard representation for all txs, regardless of whether public or private functions (or both) were run. The kernel circuits are run iteratively for every recursive call in the transaction.
+
+The **base rollup circuit** aggregates the changes from two txs (more precisely, the outputs from their kernel circuits once all call stacks are emptied) into a single output.
+
+The **merge rollup circuit** aggregates two outputs from base rollup circuits into a single one. This circuit is executed recursively until only two outputs are left. This setup means that an L2 block needs to contain always a power-of-two number of txs; if there are not enough, then empty txs are added.
+
+The **root rollup circuit** consumes two outputs from base or merge rollups and outputs the data to assemble an L2 block. The L1 rollup contract then verifies the proof from this circuit, which implies that all txs included in it were correct.
+
+## Source code
+
+You can view the current implementation on Github [here](https://github.com/AztecProtocol/aztec-packages/tree/master/yarn-project/sequencer-client).
+
+## Further Reading
+
+- [Sequencer Selection](sequencer_selection.md)
diff --git a/docs/versioned_docs/version-v0.82.2-alpha-testnet.5/aztec/network/sequencer/sequencer_selection.md b/docs/versioned_docs/version-v0.82.2-alpha-testnet.5/aztec/network/sequencer/sequencer_selection.md
new file mode 100644
index 000000000000..4fb9ad736644
--- /dev/null
+++ b/docs/versioned_docs/version-v0.82.2-alpha-testnet.5/aztec/network/sequencer/sequencer_selection.md
@@ -0,0 +1,102 @@
+---
+title: Sequencer Selection
+tags: [protocol, sequencer]
+draft: true
+---
+
+## Fernet
+
+_A protocol for random sequencer selection for the Aztec Network. Prior versions:_
+
+- [Fernet 52 (Aug 2023)](https://hackmd.io/0cI_xVsaSVi7PToCJ9A2Ew?view)
+- [Sequencer Selection: Fernet (Jun 2023)](https://hackmd.io/0FwyoEjKSUiHQsmowXnJPw?both)
+- [Sequencer Selection: Fernet (Jun 2023, Forum)](https://discourse.aztec.network/t/proposal-sequencer-selection-fernet/533)
+
+## Introduction
+
+_Fair Election Randomized Natively on Ethereum Trustlessly_ (**Fernet**) is a protocol for random _sequencer_ selection. In each iteration, it relies on a VRF to assign a random score to each sequencer in order to rank them. The sequencer with the highest score can propose an ordering for transactions and the block they build upon, and then reveal its contents for the chain to advance under soft finality. _Provers_ must then assemble a proof for this block and submit it to L1 for the block to be finalized.
+
+## Staking
+
+Sequencers are required to stake on L1 in order to participate in the protocol. Each sequencer registers a public key when they stake, which will be used to verify their VRF submission. After staking, a sequencer needs to wait for an activation period of N L1 blocks until they can start proposing new blocks. Unstaking also requires a delay to allow for slashing of dishonest behavior.
+
+## Randomness
+
+We use a verifiable random function to rank each sequencer. We propose a SNARK of a hash over the sequencer private key and a public input, borrowing [this proposal from the Espresso team](https://discourse.aztec.network/t/proposal-sequencer-selection-irish-coffee/483#vrf-specification-4). The public input is the current block number and a random beacon value from RANDAO. The value sourced from RANDAO should be old enough to prevent L1 reorgs from affecting sequencer selection on L2. This approach allows each individual proposer to secretly calculate the likelihood of being elected for a given block with enough anticipation.
+
+Alternatively, we can compute the VRF over the _public_ key of each sequencer. This opens the door to DoS attacks, since the leader for each block becomes public in advance, but it also provides clarity to all sequencers as to who the expected leader is, and facilitates off-protocol PBS.
+
+## Protocol phases
+
+Each block goes through three main phases in L1: proposal, reveal, and proving. Transactions can achieve soft finality at the end of the reveal phase.
+
+
+
+### Proposal phase
+
+During the initial proposal phase, proposers submit to L1 a **block commitment**, which includes a commitment to the transaction ordering in the proposed block, the previous block being built upon, and any additional metadata required by the protocol.
+
+**Block commitment contents:**
+
+- Hash of the ordered list of transaction identifiers for the block (with an optional salt).
+- Identifier of the previous block in the chain.
+- The output of the VRF for this sequencer.
+
+At the end of the proposal phase, the sequencer with the highest score submitted becomes the leader for this cycle, and has exclusive rights to decide the contents of the block. Note that this plays nicely with private mempools, since having exclusive rights allows the leader to disclose private transaction data in the reveal phase.
+
+> _In the original version of Fernet, multiple competing proposals could enter the proving phase. Read more about the rationale for this change [here](https://hackmd.io/0cI_xVsaSVi7PToCJ9A2Ew?both#Mitigation-Elect-single-leader-after-proposal-phase)._
+
+### Reveal phase
+
+The sequencer with the highest score in the proposal phase must then upload the block contents to either L1 or a verifiable DA layer. This guarantees that the next sequencer will have all data available to start building the next block, and clients will have the updated state to create new txs upon. It should be safe to assume that, in the happy path, this block would be proven and become final, so this provides early soft finality to transactions in the L2.
+
+> _This phase is a recent addition and a detour from the original version of Fernet. Read more about the rationale for this addition [here](https://hackmd.io/0cI_xVsaSVi7PToCJ9A2Ew?both#Mitigation-Block-reveal-phase)._
+
+Should the leading sequencer fail to reveal the block contents, we flag that block as skipped, and the next sequencer is expected to build from the previous one. We could consider this to be a slashing condition for the sequencer.
+
+
+
+### Proving phase
+
+During this phase, provers work to assemble an aggregated proof of the winning block. Before the end of this phase, it is expected for the block proof to be published to L1 for verification.
+
+> Prover selection is still being worked on and out of scope of this sequencer selection protocol.
+
+Once the proof for the winning block is submitted to L1, the block becomes final, assuming its parent block in the chain is also final. This triggers payouts to sequencer and provers (if applicable depending on the proving network design).
+
+**Canonical block selection:**
+
+- Has been proven during the proving phase.
+- Its contents have been submitted to the DA layer in the reveal phase.
+- It had the highest score on the proposal phase.
+- Its referenced previous block is also canonical.
+
+## Next block
+
+The cycle for block N+1 (ie from the start of the proposal phase until the end of the proving phase) can start at the end of block N reveal phase, where the network has all data available on L1 or a DA to construct the next block.
+
+
+
+The only way to trigger an L2 reorg (without an L1 one) is if block N is revealed but doesn't get proven. In this case, all subsequent blocks become invalidated and the chain needs to restart from block N-1.
+
+
+
+To mitigate the effect of wasted effort by all sequencers from block N+1 until the reorg, we could implement uncle rewards for these sequencers. And if we are comfortable with slashing, take those rewards out of the pocket of the sequencer that failed to finalize their block.
+
+## Batching
+
+> _Read more approaches to batching [here](https://hackmd.io/0cI_xVsaSVi7PToCJ9A2Ew?both#Batching)._
+
+As an extension to the protocol, we can bake in batching of multiple blocks. Rather than creating one proof per block, we can aggregate multiple blocks into a single proof, in order to amortize the cost of verifying the root rollup ZKP on L1, thus reducing fees.
+
+The tradeoff in batching is delayed finalization: if we are not posting proofs to L1 for every block, then the network needs to wait until the batch proof is submitted for finalization. This can also lead to deeper L2 reorgs.
+
+In a batching model, proving for each block happens immediately as the block is revealed, same as usual. But the resulting proof is not submitted to L1: instead, it is aggregated into the proof of the next block.
+
+
+
+Here all individual block proofs are valid as candidates to finalise the current batch. This opens the door to dynamic batch sizes, so the proof could be verified on L1 when it's economically convenient.
+
+## Resources
+
+- [Excalidraw diagrams](https://excalidraw.com/#json=DZcYDUKVImApNjj17KhAf,fMbieqJpOysX9obVitUDEA)
diff --git a/docs/versioned_docs/version-v0.82.2-alpha-testnet.5/aztec/network_overview.md b/docs/versioned_docs/version-v0.82.2-alpha-testnet.5/aztec/network_overview.md
new file mode 100644
index 000000000000..787a59d2a96a
--- /dev/null
+++ b/docs/versioned_docs/version-v0.82.2-alpha-testnet.5/aztec/network_overview.md
@@ -0,0 +1,12 @@
+---
+title: Overview
+sidebar_position: 0
+tags: [protocol]
+draft: true
+---
+
+# Aztec Network Infrastructure
+
+Explore this section to learn about [sequencers](../aztec/network/sequencer/index.md) and the [sequencer selection process](../aztec/network/sequencer/sequencer_selection.md).
+
+More information will be added here as we develop the protocol.
\ No newline at end of file
diff --git a/docs/versioned_docs/version-v0.82.2-alpha-testnet.5/aztec/roadmap/_category_.json b/docs/versioned_docs/version-v0.82.2-alpha-testnet.5/aztec/roadmap/_category_.json
new file mode 100644
index 000000000000..231aa372f13e
--- /dev/null
+++ b/docs/versioned_docs/version-v0.82.2-alpha-testnet.5/aztec/roadmap/_category_.json
@@ -0,0 +1,7 @@
+{
+ "label": "Roadmap",
+ "collapsible": true,
+ "collapsed": true,
+ "link": { "type": "doc", "id": "roadmap/index" }
+
+}
diff --git a/docs/versioned_docs/version-v0.82.2-alpha-testnet.5/aztec/roadmap/features_initial_ldt.md b/docs/versioned_docs/version-v0.82.2-alpha-testnet.5/aztec/roadmap/features_initial_ldt.md
new file mode 100644
index 000000000000..2ccd80366216
--- /dev/null
+++ b/docs/versioned_docs/version-v0.82.2-alpha-testnet.5/aztec/roadmap/features_initial_ldt.md
@@ -0,0 +1,22 @@
+---
+title: Sandbox Features Roadmap
+sidebar_position: 0
+tags: [sandbox]
+---
+
+The Aztec Sandbox is intended to provide developers with a lightweight and fast local node, running alongside a PXE.
+
+You can learn more about running the Sandbox [here](../../developers/reference/environment_reference/sandbox-reference.md).
+
+Developers should be able to quickly spin up local, emulated instances of an Ethereum blockchain and an Aztec encrypted rollup, and start deploying private contracts and submitting private txs.
+
+The sandbox allows developers to:
+
+- Write and deploy Aztec contracts
+- Leverage private and public state variables in contracts
+- Write private and public functions in contracts
+- Call private and public functions on other Aztec contracts (contract composability)
+- Send messages between Aztec and Ethereum contracts
+- Interact with the Aztec network using a familiar Typescript SDK ([aztec.js](https://github.com/AztecProtocol/aztec-packages/tree/master/yarn-project/aztec.js))
+- Start only a local PXE or Aztec node individually.
+- Start a P2P bootstrap node for Aztec nodes to connect and discover each other.
diff --git a/docs/versioned_docs/version-v0.82.2-alpha-testnet.5/aztec/smart_contracts/contract_creation.md b/docs/versioned_docs/version-v0.82.2-alpha-testnet.5/aztec/smart_contracts/contract_creation.md
new file mode 100644
index 000000000000..4106e0dd25ef
--- /dev/null
+++ b/docs/versioned_docs/version-v0.82.2-alpha-testnet.5/aztec/smart_contracts/contract_creation.md
@@ -0,0 +1,12 @@
+---
+title: Contract Deployment
+tags: [contracts, protocol]
+---
+
+import { Spec_Placeholder } from '/components/snippets';
+
+
+
+## Further reading
+
+To see how to deploy a contract in practice, check out the [dapp development tutorial](../../developers/tutorials/codealong/js_tutorials/simple_dapp/index.md).
diff --git a/docs/versioned_docs/version-v0.82.2-alpha-testnet.5/aztec/smart_contracts/contract_structure.md b/docs/versioned_docs/version-v0.82.2-alpha-testnet.5/aztec/smart_contracts/contract_structure.md
new file mode 100644
index 000000000000..2889475b0ddb
--- /dev/null
+++ b/docs/versioned_docs/version-v0.82.2-alpha-testnet.5/aztec/smart_contracts/contract_structure.md
@@ -0,0 +1,40 @@
+---
+title: Contract Structure
+tags: [contracts]
+---
+
+A contract is a collection of persistent state varibles and [functions](./functions/index.md) which may manipulate these variables. Functions and state variables within a contract's scope are said to belong to that contract. A contract can only access and modify its own state. If a contract wishes to access or modify another contract's state, it must make a call to an external function of the other contract. For anything to happen on the Aztec network, an external function of a contract needs to be called.
+
+## Contract
+
+A contract may be declared and given a name using the `contract` keyword (see snippet below). By convention, contracts are named in `PascalCase`.
+
+```rust title="contract keyword"
+// highlight-next-line
+contract MyContract {
+
+ // Imports
+
+ // Storage
+
+ // Functions
+}
+```
+
+:::info A note for vanilla Noir devs
+There is no [`main()`](https://noir-lang.org/docs/getting_started/project_breakdown/#mainnr) function within a Noir `contract` scope. More than one function can be an entrypoint.
+:::
+
+## Directory structure
+
+Here's a common layout for a basic Aztec.nr Contract project:
+
+```title="layout of an aztec contract project"
+─── my_aztec_contract_project
+ ├── src
+ │ ├── main.nr <-- your contract
+ └── Nargo.toml <-- package and dependency management
+```
+
+- See the vanilla Noir docs for [more info on packages](https://noir-lang.org/docs/noir/modules_packages_crates/crates_and_packages).
+- You can review the structure of a complete contract in the NFT contract tutorial [here](../../developers/tutorials/codealong/contract_tutorials/nft_contract.md).
diff --git a/docs/versioned_docs/version-v0.82.2-alpha-testnet.5/aztec/smart_contracts/functions/attributes.md b/docs/versioned_docs/version-v0.82.2-alpha-testnet.5/aztec/smart_contracts/functions/attributes.md
new file mode 100644
index 000000000000..ca7197ffaa23
--- /dev/null
+++ b/docs/versioned_docs/version-v0.82.2-alpha-testnet.5/aztec/smart_contracts/functions/attributes.md
@@ -0,0 +1,476 @@
+---
+title: Function Attributes and Macros
+sidebar_position: 4
+tags: [functions]
+---
+
+On this page you will learn about function attributes and macros.
+
+If you are looking for a reference of function macros, go [here](../../../developers/reference/smart_contract_reference/macros.md).
+
+## Private functions #[private]
+
+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.
+
+`#[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/advanced/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.
+
+#### Before expansion
+
+```rust title="simple_macro_example" showLineNumbers
+#[private]
+fn simple_macro_example(a: Field, b: Field) -> Field {
+ a + b
+}
+```
+> Source code: noir-projects/noir-contracts/contracts/docs_example_contract/src/main.nr#L307-L312
+
+
+#### After expansion
+
+```rust title="simple_macro_example_expanded" showLineNumbers
+fn simple_macro_example_expanded(
+ // ************************************************************
+ // The private context inputs are made available to the circuit by the kernel
+ inputs: PrivateContextInputs,
+ // ************************************************************
+ // Our original inputs!
+ a: Field,
+ b: Field, // The actual return type of our circuit is the PrivateCircuitPublicInputs struct, this will be the
+ // input to our kernel!
+) -> pub PrivateCircuitPublicInputs {
+ // ************************************************************
+ // The hasher is a structure used to generate a hash of the circuits inputs.
+ let mut args_hasher = dep::aztec::hash::ArgsHasher::new();
+ args_hasher.add(a);
+ args_hasher.add(b);
+ // The context object is created with the inputs and the hash of the inputs
+ let mut context = PrivateContext::new(inputs, args_hasher.hash());
+ let mut storage = Storage::init(&mut context);
+ // ************************************************************
+ // Our actual program
+ let result = a + b;
+ // ************************************************************
+ // Return values are pushed into the context
+ let mut return_hasher = dep::aztec::hash::ArgsHasher::new();
+ return_hasher.add(result);
+ context.set_return_hash(return_hasher);
+ // The context is returned to be consumed by the kernel circuit!
+ context.finish()
+ // ************************************************************
+}
+```
+> Source code: noir-projects/noir-contracts/contracts/docs_example_contract/src/main.nr#L313-L358
+
+
+#### The expansion broken down
+
+Viewing the expanded Aztec contract uncovers a lot about how Aztec contracts interact with the kernel. To aid with developing intuition, we will break down each inserted line.
+
+**Receiving context from the kernel.**
+```rust title="context-example-inputs" showLineNumbers
+inputs: PrivateContextInputs,
+```
+> Source code: noir-projects/noir-contracts/contracts/docs_example_contract/src/main.nr#L317-L319
+
+
+Private function calls are able to interact with each other through orchestration from within the kernel circuits. The kernel circuit forwards information to each contract function (recall each contract function is a circuit). This information then becomes part of the private context.
+For example, within each private function we can access some global variables. To access them we can call on the `context`, e.g. `context.chain_id()`. The value of the chain ID comes from the values passed into the circuit from the kernel.
+
+The kernel checks that all of the values passed to each circuit in a function call are the same.
+
+**Returning the context to the kernel.**
+```rust title="context-example-return" showLineNumbers
+) -> pub PrivateCircuitPublicInputs {
+```
+> Source code: noir-projects/noir-contracts/contracts/docs_example_contract/src/main.nr#L325-L327
+
+
+The contract function must return information about the execution back to the kernel. This is done through a rigid structure we call the `PrivateCircuitPublicInputs`.
+
+> _Why is it called the `PrivateCircuitPublicInputs`?_
+> When verifying zk programs, return values are not computed at verification runtime, rather expected return values are provided as inputs and checked for correctness. Hence, the return values are considered public inputs.
+
+This structure contains a host of information about the executed program. It will contain any newly created nullifiers, any messages to be sent to l2 and most importantly it will contain the return values of the function.
+
+**Hashing the function inputs.**
+```rust title="context-example-hasher" showLineNumbers
+let mut args_hasher = dep::aztec::hash::ArgsHasher::new();
+args_hasher.add(a);
+args_hasher.add(b);
+```
+> Source code: noir-projects/noir-contracts/contracts/docs_example_contract/src/main.nr#L330-L334
+
+
+_What is the hasher and why is it needed?_
+
+Inside the kernel circuits, the inputs to functions are reduced to a single value; the inputs hash. This prevents the need for multiple different kernel circuits; each supporting differing numbers of inputs. The hasher abstraction that allows us to create an array of all of the inputs that can be reduced to a single value.
+
+**Creating the function's context.**
+```rust title="context-example-context" showLineNumbers
+let mut context = PrivateContext::new(inputs, args_hasher.hash());
+```
+> Source code: noir-projects/noir-contracts/contracts/docs_example_contract/src/main.nr#L336-L338
+
+
+Each Aztec function has access to a [context](context) object. This object, although labelled a global variable, is created locally on a users' device. It is initialized from the inputs provided by the kernel, and a hash of the function's inputs.
+
+```rust title="context-example-context-return" showLineNumbers
+let mut return_hasher = dep::aztec::hash::ArgsHasher::new();
+return_hasher.add(result);
+context.set_return_hash(return_hasher);
+```
+> Source code: noir-projects/noir-contracts/contracts/docs_example_contract/src/main.nr#L347-L351
+
+
+We use the kernel to pass information between circuits. This means that the return values of functions must also be passed to the kernel (where they can be later passed on to another function).
+We achieve this by pushing return values to the execution context, which we then pass to the kernel.
+
+**Making the contract's storage available**
+```rust title="storage-example-context" showLineNumbers
+let mut storage = Storage::init(&mut context);
+```
+> Source code: noir-projects/noir-contracts/contracts/docs_example_contract/src/main.nr#L339-L341
+
+
+When a `Storage` struct is declared within a contract, the `storage` keyword is made available. As shown in the macro expansion above, this calls the init function on the storage struct with the current function's context.
+
+Any state variables declared in the `Storage` struct can now be accessed as normal struct members.
+
+**Returning the function context to the kernel.**
+```rust title="context-example-finish" showLineNumbers
+context.finish()
+```
+> Source code: noir-projects/noir-contracts/contracts/docs_example_contract/src/main.nr#L353-L355
+
+
+This function takes the application context, and converts it into the `PrivateCircuitPublicInputs` structure. This structure is then passed to the kernel circuit.
+
+## Unconstrained functions
+
+Unconstrained functions are an underlying part of Noir. In short, they are functions which are not directly constrained and therefore should be seen as untrusted. That they are un-trusted means that the developer must make sure to constrain their return values when used. Note: Calling an unconstrained function from a private function means that you are injecting unconstrained values.
+
+Defining a function as `unconstrained` tells Aztec to simulate it completely client-side in the [ACIR simulator](../../concepts/pxe/index.md) without generating proofs. They are useful for extracting information from a user through an [oracle](../oracles/index.md).
+
+When an unconstrained function is called, it prompts the ACIR simulator to
+
+1. generate the execution environment
+2. execute the function within this environment
+
+To generate the environment, the simulator gets the blockheader from the [PXE database](../../concepts/pxe/index.md#database) and passes it along with the contract address to `UnconstrainedExecutionOracle`. This creates a context that simulates the state of the blockchain at a specific block, allowing the unconstrained function to access and interact with blockchain data as it would appear in that block, but without affecting the actual blockchain state.
+
+Once the execution environment is created, `execute_unconstrained_function` is invoked:
+
+```typescript title="execute_unconstrained_function" showLineNumbers
+/**
+ * Execute an unconstrained function and return the decoded values.
+ */
+export async function executeUnconstrainedFunction(
+ simulatorProvider: SimulationProvider,
+ oracle: UnconstrainedExecutionOracle,
+ artifact: FunctionArtifactWithContractName,
+ contractAddress: AztecAddress,
+ functionSelector: FunctionSelector,
+ args: Fr[],
+ log = createLogger('simulator:unconstrained_execution'),
+): Promise {
+ log.verbose(`Executing unconstrained function ${artifact.name}`, {
+ contract: contractAddress,
+ selector: functionSelector,
+ });
+
+ const initialWitness = toACVMWitness(0, args);
+ const acirExecutionResult = await simulatorProvider
+ .executeUserCircuit(initialWitness, artifact, new Oracle(oracle))
+ .catch((err: Error) => {
+ err.message = resolveAssertionMessageFromError(err, artifact);
+ throw new ExecutionError(
+ err.message,
+ {
+ contractAddress,
+ functionSelector,
+ },
+ extractCallStack(err, artifact.debug),
+ { cause: err },
+ );
+ });
+
+ const returnWitness = witnessMapToFields(acirExecutionResult.returnWitness);
+ return decodeFromAbi(artifact.returnTypes, returnWitness);
+}
+```
+> Source code: yarn-project/simulator/src/private/unconstrained_execution.ts#L17-L54
+
+
+This:
+
+1. Prepares the ACIR for execution
+2. Converts `args` into a format suitable for the ACVM (Abstract Circuit Virtual Machine), creating an initial witness (witness = set of inputs required to compute the function). `args` might be an oracle to request a user's balance
+3. Executes the function in the ACVM, which involves running the ACIR with the initial witness and the context. If requesting a user's balance, this would query the balance from the PXE database
+4. Extracts the return values from the `partialWitness` and decodes them based on the artifact to get the final function output. The artifact is the compiled output of the contract, and has information like the function signature, parameter types, and return types
+
+Beyond using them inside your other functions, they are convenient for providing an interface that reads storage, applies logic and returns values to a UI or test. Below is a snippet from exposing the `balance_of_private` function from a token implementation, which allows a user to easily read their balance, similar to the `balanceOf` function in the ERC20 standard.
+
+```rust title="balance_of_private" showLineNumbers
+pub(crate) unconstrained fn balance_of_private(owner: AztecAddress) -> pub u128 {
+ storage.balances.at(owner).balance_of()
+}
+```
+> Source code: noir-projects/noir-contracts/contracts/token_contract/src/main.nr#L621-L625
+
+
+:::info
+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 #[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 `#[public]` attribute. This will make the public context available within the function's execution scope.
+
+```rust title="set_minter" showLineNumbers
+#[public]
+fn set_minter(minter: AztecAddress, approve: bool) {
+ assert(storage.admin.read().eq(context.msg_sender()), "caller is not admin");
+ storage.minters.at(minter).write(approve);
+}
+```
+> Source code: noir-projects/noir-contracts/contracts/token_contract/src/main.nr#L183-L193
+
+
+Under the hood:
+
+- Context Creation: The macro inserts code at the beginning of the function to create a`PublicContext` object:
+
+```rust
+let mut context = PublicContext::new(args_hasher);
+```
+
+This context provides access to public state and transaction information
+
+- Storage Access: If the contract has a storage struct defined, the macro inserts code to initialize the storage:
+
+```rust
+let storage = Storage::init(&mut context);
+```
+
+- Function Body Wrapping: The original function body is wrapped in a new scope that handles the context and return value
+- 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 #[view]
+
+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) 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 `#[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.
+
+`#[view]` functions can be combined with other Aztec attributes like `#[private]` or `#[public]`.
+
+## `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:
+
+- `assert_initialization_matches_address_preimage(context)`: This checks that the arguments and sender to the initializer match the commitments from the address preimage
+- `mark_as_initialized(&mut context)`: This is called at the end of the function to emit the initialization nullifier, marking the contract as fully initialized and ensuring this function cannot be called again
+
+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 [`#[noinitcheck]`](#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 `#[noinitcheck]`.
+
+When a function is annotated with `#[noinitcheck]`:
+
+- The Aztec macro processor skips the [insertion of the initialization check](#initializer-functions-initializer) for this specific function
+- The function can be called at any time, even if the contract hasn't been initialized yet
+
+## `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");
+```
+
+## Implementing notes
+
+The `#[note]` attribute is used to define notes in Aztec contracts. Learn more about notes [here](../../concepts/storage/index.md).
+
+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. **Note Interface Implementation**: The macro automatically implements the `NoteType`, `NoteHash` and `Packable` traits for the annotated struct. This includes the following methods:
+
+ - `get_id`
+ - `compute_note_hash`
+ - `compute_nullifier`
+ - `pack`
+ - `unpack`
+
+2. **Property Metadata**: A separate struct is generated to describe the note's fields, which is used for efficient retrieval of note data
+
+3. **Export Information**: The note type and its ID are automatically exported
+
+### Before expansion
+
+Here is how you could define a custom note:
+
+```rust
+#[note]
+struct CustomNote {
+ data: Field,
+ owner: Address,
+}
+```
+
+### After expansion
+
+```rust
+impl NoteType for CustomNote {
+ fn get_id() -> Field {
+ // Assigned by macros by incrementing a counter
+ 2
+ }
+}
+
+impl NoteHash for CustomNote {
+ fn compute_note_hash(self, storage_slot: Field) -> Field {
+ let inputs = array_concat(self.pack(), [storage_slot]);
+ poseidon2_hash_with_separator(inputs, GENERATOR_INDEX__NOTE_HASH)
+ }
+
+ fn compute_nullifier(self, context: &mut PrivateContext, note_hash_for_nullify: Field) -> Field {
+ let owner_npk_m_hash = get_public_keys(self.owner).npk_m.hash();
+ let secret = context.request_nsk_app(owner_npk_m_hash);
+ poseidon2_hash_with_separator(
+ [
+ note_hash_for_nullify,
+ secret
+ ],
+ GENERATOR_INDEX__NOTE_NULLIFIER as Field
+ )
+ }
+
+ unconstrained fn compute_nullifier_unconstrained(self, storage_slot: Field, contract_address: AztecAddress, note_nonce: Field) -> Field {
+ // We set the note_hash_counter to 0 as the note is not transient and the concept of transient note does
+ // not make sense in an unconstrained context.
+ let retrieved_note = RetrievedNote { note: self, contract_address, nonce: note_nonce, note_hash_counter: 0 };
+ let note_hash_for_nullify = compute_note_hash_for_nullify(retrieved_note, storage_slot);
+ let owner_npk_m_hash = get_public_keys(self.owner).npk_m.hash();
+ let secret = get_nsk_app(owner_npk_m_hash);
+ poseidon2_hash_with_separator(
+ [
+ note_hash_for_nullify,
+ secret
+ ],
+ GENERATOR_INDEX__NOTE_NULLIFIER as Field
+ )
+ }
+}
+
+impl CustomNote {
+ pub fn new(x: [u8; 32], y: [u8; 32], owner: AztecAddress) -> Self {
+ CustomNote { x, y, owner }
+ }
+}
+
+impl Packable<2> for CustomNote {
+ fn pack(self) -> [Field; 2] {
+ [self.data, self.owner.to_field()]
+ }
+
+ fn unpack(packed_content: [Field; 2]) -> CustomNote {
+ CustomNote { data: packed_content[0], owner: AztecAddress { inner: packed_content[1] } }
+ }
+}
+
+struct CustomNoteProperties {
+ data: aztec::note::note_getter_options::PropertySelector,
+ owner: aztec::note::note_getter_options::PropertySelector,
+}
+```
+
+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 #[storage]
+
+The `#[storage]` attribute is used to define the storage structure for an Aztec contract.
+
+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()`
+
+2. **Storage Implementation Generation**: generates an `impl` block for the storage struct with an `init` function. The developer can override this by implementing a `impl` block themselves
+
+3. **Storage Slot Assignment**: automatically assigns storage slots to each field in the struct based on their serialized length
+
+4. **Storage Layout Generation**: a `StorageLayout` struct and a global variable are generated to export the storage layout information for use in the contract artifact
+
+### Before expansion
+
+```rust
+#[storage]
+struct Storage {
+ balance: PublicMutable,
+ owner: PublicMutable,
+ token_map: Map,
+}
+```
+
+### After expansion
+
+```rust
+struct Storage {
+ balance: PublicMutable,
+ owner: PublicMutable,
+ token_map: Map,
+}
+
+impl Storage {
+ fn init(context: Context) -> Self {
+ Storage {
+ balance: PublicMutable::new(context, 1),
+ owner: PublicMutable::new(context, 2),
+ token_map: Map::new(context, 3, |context, slot| Field::new(context, slot)),
+ }
+ }
+}
+
+struct StorageLayout {
+ balance: dep::aztec::prelude::Storable,
+ owner: dep::aztec::prelude::Storable,
+ token_map: dep::aztec::prelude::Storable,
+}
+
+#[abi(storage)]
+global CONTRACT_NAME_STORAGE_LAYOUT = StorageLayout {
+ balance: dep::aztec::prelude::Storable { slot: 1 },
+ owner: dep::aztec::prelude::Storable { slot: 2 },
+ token_map: dep::aztec::prelude::Storable { slot: 3 },
+};
+```
+
+Key things to keep in mind:
+
+- Only one storage struct can be defined per contract
+- `Map` types and private `Note` types always occupy a single storage slot
+
+## Further reading
+
+- [Macros reference](../../../developers/reference/smart_contract_reference/macros.md)
+- [How do macros work](./attributes.md)
+
+
diff --git a/docs/versioned_docs/version-v0.82.2-alpha-testnet.5/aztec/smart_contracts/functions/context.md b/docs/versioned_docs/version-v0.82.2-alpha-testnet.5/aztec/smart_contracts/functions/context.md
new file mode 100644
index 000000000000..7352424ee691
--- /dev/null
+++ b/docs/versioned_docs/version-v0.82.2-alpha-testnet.5/aztec/smart_contracts/functions/context.md
@@ -0,0 +1,219 @@
+---
+title: Understanding Function Context
+sidebar_position: 1
+tags: [functions, context]
+---
+
+## What is the context
+
+The context is an object that is made available within every function in `Aztec.nr`. As mentioned in the [kernel circuit documentation](../../concepts/advanced/circuits/kernels/private_kernel.md). At the beginning of a function's execution, the context contains all of the kernel information that application needs to execute. During the lifecycle of a transaction, the function will update the context with each of its side effects (created notes, nullifiers etc.). At the end of a function's execution the mutated context is returned to the kernel to be checked for validity.
+
+Behind the scenes, Aztec.nr will pass data the kernel needs to and from a circuit, this is abstracted away from the developer. In a developer's eyes; the context is a useful structure that allows access and mutate the state of the `Aztec` blockchain.
+
+On this page, you'll learn
+
+- The details and functionalities of the private context in Aztec.nr
+- Difference between the private and public contexts and their unified APIs
+- Components of the private context, such as inputs and block header.
+- Elements like return values, read requests, new note hashes, and nullifiers in transaction processing
+- Differences between the private and public contexts, especially the unique features and variables in the public context
+
+## Two contexts, one API
+
+The `Aztec` blockchain contains two environments - public and private.
+
+- Private, for private transactions taking place on user's devices.
+- Public, for public transactions taking place on the network's sequencers.
+
+As there are two distinct execution environments, they both require slightly differing execution contexts. Despite their differences; the API's for interacting with each are unified. Leading to minimal context switch when working between the two environments.
+
+The following section will cover both contexts.
+
+## The Private Context
+
+The code snippet below shows what is contained within the private context.
+```rust title="private-context" showLineNumbers
+pub inputs: PrivateContextInputs,
+pub side_effect_counter: u32,
+
+pub min_revertible_side_effect_counter: u32,
+pub is_fee_payer: bool,
+
+pub args_hash: Field,
+pub return_hash: Field,
+
+pub max_block_number: MaxBlockNumber,
+
+pub note_hash_read_requests: BoundedVec,
+pub nullifier_read_requests: BoundedVec,
+key_validation_requests_and_generators: BoundedVec,
+
+pub note_hashes: BoundedVec,
+pub nullifiers: BoundedVec,
+
+pub private_call_requests: BoundedVec,
+pub public_call_requests: BoundedVec, MAX_ENQUEUED_CALLS_PER_CALL>,
+pub public_teardown_call_request: PublicCallRequest,
+pub l2_to_l1_msgs: BoundedVec,
+```
+> Source code: noir-projects/aztec-nr/aztec/src/context/private_context.nr#L55-L78
+
+
+### Private Context Broken Down
+
+#### Inputs
+
+The context inputs includes all of the information that is passed from the kernel circuit into the application circuit. It contains the following values.
+
+```rust title="private-context-inputs" showLineNumbers
+pub struct PrivateContextInputs {
+ pub call_context: CallContext,
+ pub historical_header: BlockHeader,
+ pub tx_context: TxContext,
+ pub start_side_effect_counter: u32,
+}
+```
+> Source code: noir-projects/aztec-nr/aztec/src/context/inputs/private_context_inputs.nr#L7-L14
+
+
+As shown in the snippet, the application context is made up of 4 main structures. The call context, the block header, and the private global variables.
+
+First of all, the call context.
+
+```rust title="call-context" showLineNumbers
+pub struct CallContext {
+ pub msg_sender: AztecAddress,
+ pub contract_address: AztecAddress,
+ pub function_selector: FunctionSelector,
+ pub is_static_call: bool,
+}
+```
+> Source code: noir-projects/noir-protocol-circuits/crates/types/src/abis/call_context.nr#L9-L16
+
+
+The call context contains information about the current call being made:
+
+1. Msg Sender
+ - The message sender is the account (Aztec Contract) that sent the message to the current context. In the first call of the kernel circuit (often the account contract call), this value will be empty. For all subsequent calls the value will be the previous call.
+
+> The graphic below illustrates how the message sender changes throughout the kernel circuit iterations.
+
+
+
+2. Storage contract address
+
+ - This value is the address of the current context's contract address. This value will be the value of the current contract that is being executed except for when the current call is a delegate call (Warning: This is yet to be implemented). In this case the value will be that of the sending contract.
+
+3. Flags
+ - Furthermore there are a series of flags that are stored within the application context:
+ - is_delegate_call: Denotes whether the current call is a delegate call. If true, then the storage contract address will be the address of the sender.
+ - is_static_call: This will be set if and only if the current call is a static call. In a static call, state changing altering operations are not allowed.
+
+### Block Header
+
+Another structure that is contained within the context is the `BlockHeader` object, which is the header of the block used to generate proofs against.
+
+```rust title="block-header" showLineNumbers
+pub struct BlockHeader {
+ pub last_archive: AppendOnlyTreeSnapshot,
+ pub content_commitment: ContentCommitment,
+ pub state: StateReference,
+ pub global_variables: GlobalVariables,
+ pub total_fees: Field,
+ pub total_mana_used: Field,
+}
+```
+> Source code: noir-projects/noir-protocol-circuits/crates/types/src/block_header.nr#L11-L20
+
+
+### Transaction Context
+
+The private context provides access to the transaction context as well, which are user-defined values for the transaction in general that stay constant throughout its execution.
+
+```rust title="tx-context" showLineNumbers
+pub struct TxContext {
+ pub chain_id: Field,
+ pub version: Field,
+ pub gas_settings: GasSettings,
+}
+```
+> Source code: noir-projects/noir-protocol-circuits/crates/types/src/transaction/tx_context.nr#L8-L14
+
+
+### Args Hash
+
+To allow for flexibility in the number of arguments supported by Aztec functions, all function inputs are reduced to a singular value which can be proven from within the application.
+
+The `args_hash` is the result of pedersen hashing all of a function's inputs.
+
+### Return Values
+
+The return values are a set of values that are returned from an applications execution to be passed to other functions through the kernel. Developers do not need to worry about passing their function return values to the `context` directly as `Aztec.nr` takes care of it for you. See the documentation surrounding `Aztec.nr` [macro expansion](./attributes.md#after-expansion) for more details.
+
+```rust
+return_values : BoundedVec\,
+```
+## Max Block Number
+
+Some data structures impose time constraints, e.g. they may make it so that a value can only be changed after a certain delay. Interacting with these in private involves creating proofs that are only valid as long as they are included before a certain future point in time. To achieve this, the `set_tx_max_block_number` function can be used to set this property:
+
+```rust title="max-block-number" showLineNumbers
+pub fn set_tx_max_block_number(&mut self, max_block_number: u32) {
+```
+> Source code: noir-projects/aztec-nr/aztec/src/context/private_context.nr#L237-L239
+
+
+A transaction that requests a maximum block number will never be included in a block with a block number larger than the requested value, since it would be considered invalid. This can also be used to make transactions automatically expire after some time if not included.
+
+### Read Requests
+
+
+
+### New Note Hashes
+
+New note hashes contains an array of all of the note hashes created in the current execution context.
+
+### New Nullifiers
+
+New nullifiers contains an array of the new nullifiers emitted from the current execution context.
+
+### Nullified Note Hashes
+
+Nullified note hashes is an optimization for introduced to help reduce state growth. There are often cases where note hashes are created and nullified within the same transaction.
+In these cases there is no reason that these note hashes should take up space on the node's commitment/nullifier trees. Keeping track of nullified note hashes allows us to "cancel out" and prove these cases.
+
+### Private Call Stack
+
+The private call stack contains all of the external private function calls that have been created within the current context. Any function call objects are hashed and then pushed to the execution stack.
+The kernel circuit will orchestrate dispatching the calls and returning the values to the current context.
+
+### Public Call Stack
+
+The public call stack contains all of the external function calls that are created within the current context. Like the private call stack above, the calls are hashed and pushed to this stack. Unlike the private call stack, these calls are not executed client side. Whenever the function is sent to the network, it will have the public call stack attached to it. At this point the sequencer will take over and execute the transactions.
+
+### New L2 to L1 msgs
+
+New L2 to L1 messages contains messages that are delivered to the l1 outbox on the execution of each rollup.
+
+## Public Context
+
+The Public Context includes all of the information passed from the `Public VM` into the execution environment. Its interface is very similar to the [Private Context](#the-private-context), however it has some minor differences (detailed below).
+
+### Public Global Variables
+
+The public global variables are provided by the rollup sequencer and consequently contain some more values than the private global variables.
+
+```rust title="global-variables" showLineNumbers
+pub struct GlobalVariables {
+ pub chain_id: Field,
+ pub version: Field,
+ pub block_number: Field,
+ pub slot_number: Field,
+ pub timestamp: u64,
+ pub coinbase: EthAddress,
+ pub fee_recipient: AztecAddress,
+ pub gas_fees: GasFees,
+}
+```
+> Source code: noir-projects/noir-protocol-circuits/crates/types/src/abis/global_variables.nr#L9-L20
+
diff --git a/docs/versioned_docs/version-v0.82.2-alpha-testnet.5/aztec/smart_contracts/functions/function_transforms.md b/docs/versioned_docs/version-v0.82.2-alpha-testnet.5/aztec/smart_contracts/functions/function_transforms.md
new file mode 100644
index 000000000000..e7399d2b152c
--- /dev/null
+++ b/docs/versioned_docs/version-v0.82.2-alpha-testnet.5/aztec/smart_contracts/functions/function_transforms.md
@@ -0,0 +1,239 @@
+---
+title: Inner Workings of Functions
+sidebar_position: 3
+tags: [functions]
+---
+
+Below, we go more into depth of what is happening under the hood when you create a function in an Aztec contract. The [next page](./attributes.md) will give you more information about what the attributes are really doing.
+
+
+## Function transformation
+
+When you define a function in an Aztec contract, it undergoes several transformations when it is compiled. These transformations prepare the function for execution. These transformations include:
+
+- [Creating a context for the function](#context-creation)
+- [Handling function inputs](#private-and-public-input-injection)
+- [Processing return values](#return-value-handling)
+- [Generating function signatures](#function-signature-generation)
+- [Generating contract artifacts](#contract-artifacts)
+
+Let's explore each of these transformations in detail.
+
+## Context creation
+
+Every function in an Aztec contract operates within a specific context which provides some extra information and functionality. This is either a `PrivateContext` or `PublicContext` object, depending on whether it is a private or public function. For private functions, it creates a hash of all input parameters to ensure privacy.
+
+### Private functions
+
+For private functions, the context creation involves hashing all input parameters:
+
+```rust
+let mut args_hasher = ArgsHasher::new();
+// Hash each parameter
+args_hasher.add(param1);
+args_hasher.add(param2);
+// add all parameters
+
+let mut context = PrivateContext::new(inputs, args_hasher.hash());
+```
+
+This hashing process is important because it is used to verify the function's execution without exposing the input data.
+
+### Public functions
+
+For public functions, context creation is simpler:
+
+```rust
+let mut context = PublicContext::new(inputs);
+```
+
+These `inputs` are explained in the [private and public input injection](#private-and-public-input-injection) further down on this page.
+
+### Using the context in functions
+
+Once created, the context object provides various useful methods. Here are some common use cases:
+
+#### Accessing storage
+
+The context allows you to interact with contract storage. eg if you have a function that calls storage like this:
+
+```rust
+let sender_balance = storage.balances.at(owner);
+```
+
+This calls the context to read from the appropriate storage slot.
+
+#### Interacting with other contracts
+
+The context provides methods to call other contracts:
+
+```rust
+let token_contract = TokenContract::at(token);
+```
+
+Under the hood, this creates a new instance of the contract interface with the specified address.
+
+## Private and public input injection
+
+An additional parameter is automatically added to every function.
+
+The injected input is always the first parameter of the transformed function and is of type `PrivateContextInputs` for private functions or `PublicContextInputs` for public functions.
+
+Original function definition
+ ```rust
+ fn my_function(param1: Type1, param2: Type2) { ... }
+ ```
+
+Transformed function with injected input
+ ```rust
+ fn my_function(inputs: PrivateContextInputs, param1: Type1, param2: Type2) { ... }
+ ```
+
+The `inputs` parameter includes:
+
+- msg sender, ie the address of the account calling the function
+- contract address
+- chain ID
+- block context, eg the block number & timestamp
+- function selector of the function being called
+
+This makes these inputs available to be consumed within private annotated functions.
+
+## Return value handling
+
+Return values in Aztec contracts are processed differently from traditional smart contracts when using private functions.
+
+### Private functions
+
+- The original return value is assigned to a special variable:
+ ```rust
+ let macro__returned__values = original_return_expression;
+ ```
+
+- A new `ArgsHasher` is created for the return values:
+ ```rust
+ let mut returns_hasher = ArgsHasher::new();
+ ```
+
+- The hash of the return value is set in the context:
+ ```rust
+ context.set_return_hash(returns_hasher);
+ ```
+
+- The function's return type is changed to `PrivateCircuitPublicInputs`, which is returned by calling `context.finish()` at the end of the function.
+
+This process allows the return values to be included in the function's computation result while maintaining privacy.
+
+### Public functions
+
+In public functions, the return value is directly used, and the function's return type remains as specified by the developer.
+
+## Function signature generation
+
+Unique function signatures are generated for each contract function.
+
+The function signature is computed like this:
+
+```rust
+fn compute_fn_signature_hash(fn_name: &str, parameters: &[Type]) -> u32 {
+ let signature = format!(
+ "{}({})",
+ fn_name,
+ parameters.iter().map(signature_of_type).collect::>().join(",")
+ );
+ let mut keccak = Keccak::v256();
+ let mut result = [0u8; 32];
+ keccak.update(signature.as_bytes());
+ keccak.finalize(&mut result);
+ // Take the first 4 bytes of the hash and convert them to an integer
+ // If you change the following value you have to change NUM_BYTES_PER_NOTE_TYPE_ID in l1_note_payload.ts as well
+ let num_bytes_per_note_type_id = 4;
+ u32::from_be_bytes(result[0..num_bytes_per_note_type_id].try_into().unwrap())
+}
+```
+
+- A string representation of the function is created, including the function name and parameter types
+- This signature string is then hashed using Keccak-256
+- The first 4 bytes of the resulting hash are converted to a u32 integer
+
+### Integration into contract interface
+
+The computed function signatures are integrated into the contract interface like this:
+
+- During contract compilation, placeholder values (0) are initially used for function selectors
+
+- After type checking, the `update_fn_signatures_in_contract_interface()` function is called to replace these placeholders with the actual computed signatures
+
+- For each function in the contract interface:
+ - The function's parameters are extracted
+ - The signature hash is computed using `compute_fn_signature_hash`
+ - The placeholder in the contract interface is replaced with the computed hash
+
+This process ensures that each function in the contract has a unique, deterministic signature based on its name and parameter types. They are inspired by Solidity's function selector mechanism.
+
+## Contract artifacts
+
+Contract artifacts in Aztec are automatically generated structures that describe the contract's interface. They provide information about the contract's functions, their parameters, and return types.
+
+### Contract artifact generation process
+
+For each function in the contract, an artifact is generated like this:
+
+- A struct is created to represent the function's parameters:
+
+ ```rust
+ struct {function_name}_parameters {
+ // Function parameters are listed here
+ }
+ ```
+
+ This struct is only created if the function has parameters.
+
+- An ABI struct is generated for the function:
+
+```rust
+ let export_struct_source = format!(
+ "
+ #[abi(functions)]
+ struct {}_abi {{
+ {}{}
+ }}",
+ func.name(),
+ parameters,
+ return_type
+ );
+```
+
+- These structs are added to the contract's types.
+
+### Content of artifacts
+
+The artifacts contain:
+
+- Function name
+- Parameters (if any), including their names and types
+- Return type (if the function has returns)
+
+For example, for a function `transfer(recipient: Address, amount: Field) -> bool`, the artifact would look like:
+
+```rust
+struct transfer_parameters {
+ recipient: Address,
+ amount: Field,
+}
+
+#[abi(functions)]
+struct transfer_abi {
+ parameters: transfer_parameters,
+ return_type: bool,
+}
+```
+
+Contract artifacts are important because:
+
+- They provide a machine-readable description of the contract
+- They can be used to generate bindings for interacting with the contract (read [here](../../../developers/guides/smart_contracts/how_to_compile_contract.md) to learn how to create TypeScript bindings)
+- They help decode function return values in the simulator
+
+## Further reading
+- [Function attributes and macros](./attributes.md)
diff --git a/docs/versioned_docs/version-v0.82.2-alpha-testnet.5/aztec/smart_contracts/functions/index.md b/docs/versioned_docs/version-v0.82.2-alpha-testnet.5/aztec/smart_contracts/functions/index.md
new file mode 100644
index 000000000000..b0bffb318584
--- /dev/null
+++ b/docs/versioned_docs/version-v0.82.2-alpha-testnet.5/aztec/smart_contracts/functions/index.md
@@ -0,0 +1,29 @@
+---
+title: Defining Functions
+tags: [functions]
+---
+
+Functions serve as the building blocks of smart contracts. Functions can be either **public**, ie they are publicly available for anyone to see and can directly interact with public state, or **private**, meaning they are executed completely client-side in the [PXE](../../concepts/pxe/index.md). Read more about how private functions work [here](./attributes.md#private-functions-private).
+
+For a more practical guide of using multiple types of functions, follow the [NFT tutorial](../../../developers/tutorials/codealong/contract_tutorials/nft_contract.md).
+
+Currently, any function is "mutable" in the sense that it might alter state. However, we also support static calls, similarly to EVM. A static call is essentially a call that does not alter state (it keeps state static).
+
+## Initializer functions
+
+Smart contracts may have one, or many, initializer functions which are called when the contract is deployed.
+
+Initializers are regular functions that set an "initialized" flag (a nullifier) for the contract. A contract can only be initialized once, and contract functions can only be called after the contract has been initialized, much like a constructor. However, if a contract defines no initializers, it can be called at any time. Additionally, you can define as many initializer functions in a contract as you want, both private and public.
+
+## Oracles
+
+There are also special oracle functions, which can get data from outside of the smart contract. In the context of Aztec, oracles are often used to get user-provided inputs.
+
+## Learn more about functions
+
+- [How function visibility works in Aztec](./visibility.md)
+- How to write an [initializer function](../../../developers/guides/smart_contracts/writing_contracts/initializers.md)
+- [Oracles](../oracles/index.md) and how Aztec smart contracts might use them
+- [How functions work under the hood](./attributes.md)
+
+Find a function macros reference [here](../../../developers/reference/smart_contract_reference/macros.md)
diff --git a/docs/versioned_docs/version-v0.82.2-alpha-testnet.5/aztec/smart_contracts/functions/public_private_calls.md b/docs/versioned_docs/version-v0.82.2-alpha-testnet.5/aztec/smart_contracts/functions/public_private_calls.md
new file mode 100644
index 000000000000..0e4c5667b5c4
--- /dev/null
+++ b/docs/versioned_docs/version-v0.82.2-alpha-testnet.5/aztec/smart_contracts/functions/public_private_calls.md
@@ -0,0 +1,92 @@
+---
+title: Private <> Public Communication
+sidebar_position: 3
+tags: [functions]
+---
+
+
+import Image from "@theme/IdealImage";
+
+import Disclaimer from "@site/src/components/Disclaimers/\_wip_disclaimer.mdx";
+
+
+
+Aztec operates on a model of private and public functions that are able to work together. Private functions work by providing evidence of correct execution generated locally through kernel proofs. Public functions, on the other hand, are able to utilize the latest state to manage updates and perform alterations.
+
+On this page, you’ll learn:
+
+- How private and public functions work
+- The role of public functions in managing state alterations and updates
+- Communication and interactions between private and public functions
+- How the sequencer manages the order of operations of private functions
+
+### Objectives
+
+The goal for L2 communication is to setup the most simple mechanism that will support
+
+- _private_ and _public_ functions
+- _private_ functions that can call _private_ or _public_ functions
+- _public_ functions that can call _private_ or _public_ functions
+
+Before diving into the communication abstracts for Aztec, we need to understand some of our limitations. One being that public functions (as known from Ethereum) must operate on the current state to provide meaningful utility, e.g., at the tip.
+This works fine when there is only one builder (sequencer) executing it first, and then others verifying as the builder always knows the tip. On the left in the diagram below, we see a block where the transactions are applied one after another each building on the state before it. For example, if Tx 1 update storage `a = 5`, then in Tx 2 reading `a` will return `5`.
+
+This works perfectly well when everything is public and a single builder is aware of all changes. However, in a private setting, we require the user to present evidence of correct execution as part of their transaction in the form of a kernel proof (generated locally on user device ahead of time). This way, the builder doesn't need to have knowledge of everything happening in the transaction, only the results. If we were to build this proof on the latest state, we would encounter problems. How can two different users build proofs at the same time, given that they will be executed one after the other by the sequencer? The simple answer is that they cannot, as race conditions would arise where one of the proofs would be invalidated by the other due to a change in the state root (which would nullify Merkle paths).
+
+To avoid this issue, we permit the use of historical data as long as the data has not been nullified previously. Note, that because this must include nullifiers that were inserted after the proof generation, but before execution we need to nullify (and insert the data again) to prove that it was not nullified. Without emitting the nullifier we would need our proof to point to the current head of the nullifier tree to have the same effect, e.g., back to the race conditions we were trying to avoid.
+
+In this model, instead of informing the builder of our intentions, we construct the proof $\pi$ and then provide them with the transaction results (new note hashes and nullifiers, contract deployments and cross-chain messages) in addition to $\pi$. The builder will then be responsible for inserting these new note hashes and nullifiers into the state. They will be aware of the intermediates and can discard transactions that try to produce existing nullifiers (double spend), as doing so would invalidate the rollup proof.
+
+On the left-hand side of the diagram below, we see the fully public world where storage is shared, while on the right-hand side, we see the private world where all reads are historical.
+
+
+
+Given that Aztec will comprise both private and public functions, it is imperative that we determine the optimal ordering for these functions. From a logical standpoint, it is reasonable to execute the private functions first as they are executed on a state $S_i$, where $i \le n$, with $S_n$ representing the current state where the public functions always operate on the current state $S_n$. Prioritizing the private functions would also afford us the added convenience of enabling them to invoke the public functions, which is particularly advantageous when implementing a peer-to-pool architecture such as that employed by Uniswap.
+
+Transactions that involve both private and public functions will follow a specific order of execution, wherein the private functions will be executed first, followed by the public functions, and then moving on to the next transaction.
+
+It is important to note that the execution of private functions is prioritized before executing any public functions. This means that private functions cannot "wait" on the results of any of their calls to public functions. Stated differently, any calls made across domains are unilateral in nature, akin to shouting into the void with the hope that something will occur at a later time. The figure below illustrates the order of function calls on the left-hand side, while the right-hand side shows how the functions will be executed. Notably, the second private function call is independent of the output of the public function and merely occurs after its execution.
+
+
+
+Multiple of these transactions are then ordered into a L2 block by the sequencer, who will also be executing the public functions (as they require the current head). Example seen below.
+
+
+
+:::info
+Be mindful that if part of a transaction is reverting, say the public part of a call, it will revert the entire transaction. Similarly to Ethereum, it might be possible for the block builder to create a block such that your valid transaction reverts because of altered state, e.g., trade incurring too much slippage or the like.
+:::
+
+To summarize:
+
+- _Private_ function calls are fully "prepared" and proven by the user, which provides the kernel proof along with new note hashes and nullifiers to the sequencer.
+- _Public_ functions altering public state (updatable storage) must be executed at the current "head" of the chain, which only the sequencer can ensure, so these must be executed separately to the _private_ functions.
+- _Private_ and _public_ functions within an Aztec transaction are therefore ordered such that first _private_ functions are executed, and then _public_.
+
+A more comprehensive overview of the interplay between private and public functions and their ability to manipulate data is presented below. It is worth noting that all data reads performed by private functions are historical in nature, and that private functions are not capable of modifying public storage. Conversely, public functions have the capacity to manipulate private storage (e.g., inserting new note hashes, potentially as part of transferring funds from the public domain to the private domain).
+
+
+
+:::info
+You can think of private and public functions as being executed by two actors that can only communicate to each other by mailbox.
+:::
+
+So, with private functions being able to call public functions (unilaterally) we had a way to go from private to public, what about the other way? Recall that public functions CANNOT call private functions directly. Instead, you can use the append-only merkle tree to save messages from a public function call, that can later be executed by a private function. Note, only a transaction coming after the one including the message from a public function can consume it. In practice this means that unless you are the sequencer it will not be within the same rollup.
+
+Given that private functions have the capability of calling public functions unilaterally, it is feasible to transition from a private to public function within the same transaction. However, the converse is not possible. To achieve this, the append-only merkle tree can be employed to save messages from a public function call, which can then be executed by a private function at a later point in time. It is crucial to reiterate that this can only occur at a later stage and cannot take place within the same rollup because the proof cannot be generated by the user.
+
+:::info
+Theoretically the builder has all the state trees after the public function has inserted a message in the public tree, and is able to create a proof consuming those messages in the same block. But it requires pending UTXO's on a block-level.
+:::
+
+From the above, we should have a decent idea about what private and public functions can do inside the L2, and how they might interact.
+
+## A note on L2 access control
+
+Many applications rely on some form of access control to function well. USDC have a blacklist, where only parties not on the list should be able to transfer. And other systems such as Aave have limits such that only the pool contract is able to mint debt tokens and transfers held funds.
+
+Access control like this cannot easily be enforced in the private domain, as reading is also nullifying (to ensure data is up to date). However, as it is possible to read historical public state, one can combine private and public functions to get the desired effect.
+
+This concept is known as shared state, and relies on using delays when changing public data so that it can also be read in private with currentness guarantees. Since values cannot be immediately modified but instead require delays to elapse, it is possible to privately prove that an application is using the current value _as long as the transaction gets included before some time in the future_, which would be the earliest the value could possibly change.
+
+If the public state is only changed infrequently, and it is acceptable to have delays when doing so, then shared state is a good solution to this problem.
diff --git a/docs/versioned_docs/version-v0.82.2-alpha-testnet.5/aztec/smart_contracts/functions/visibility.md b/docs/versioned_docs/version-v0.82.2-alpha-testnet.5/aztec/smart_contracts/functions/visibility.md
new file mode 100644
index 000000000000..006891f75c30
--- /dev/null
+++ b/docs/versioned_docs/version-v0.82.2-alpha-testnet.5/aztec/smart_contracts/functions/visibility.md
@@ -0,0 +1,27 @@
+---
+title: Visibility
+sidebar_position: 0
+tags: [functions]
+---
+
+In Aztec there are multiple different types of visibility that can be applied to functions. Namely we have `data visibility` and `function visibility`. This page explains these types of visibility.
+
+For a practical guide of using multiple types of data and function visibility, follow the [NFT tutorial](../../../developers/tutorials/codealong/contract_tutorials/nft_contract.md).
+
+### Data Visibility
+
+Data visibility is used to describe whether the data (or state) used in a function is generally accessible (public) or on a need to know basis (private).
+
+### Function visibility
+
+This is the kind of visibility you are more used to seeing in Solidity and more traditional programming languages. It is used to describe whether a function is callable from other contracts, or only from within the same contract.
+
+By default, all functions are callable from other contracts, similarly to the Solidity `public` visibility. To make them only callable from the contract itself, you can mark them as `internal`. Contrary to solidity, we don't have the `external` nor `private` keywords. `external` since it is limited usage when we don't support inheritance, and `private` since we don't support inheritance and it would also be confusing with multiple types of `private`.
+
+A good place to use `internal` is when you want a private function to be able to alter public state. As mentioned above, private functions cannot do this directly. They are able to call public functions and by making these internal we can ensure that this state manipulating function is only callable from our private function.
+
+:::danger
+Note that non-internal functions could be used directly as an entry-point, which currently means that the `msg_sender` would be `0`, so for now, using address `0` as a burn address is not recommended. You can learn more about this in the [Accounts concept page](../../concepts/accounts/keys.md).
+:::
+
+To understand how visibility works under the hood, check out the [Inner Workings page](./attributes.md).
diff --git a/docs/versioned_docs/version-v0.82.2-alpha-testnet.5/aztec/smart_contracts/oracles/index.md b/docs/versioned_docs/version-v0.82.2-alpha-testnet.5/aztec/smart_contracts/oracles/index.md
new file mode 100644
index 000000000000..d6d560d7ad66
--- /dev/null
+++ b/docs/versioned_docs/version-v0.82.2-alpha-testnet.5/aztec/smart_contracts/oracles/index.md
@@ -0,0 +1,38 @@
+---
+title: Oracle Functions
+tags: [functions, oracles]
+---
+
+This page goes over what oracles are in Aztec and how they work.
+
+Looking for a hands-on guide? You can learn how to use oracles in a smart contract [here](../../../developers/guides/smart_contracts/writing_contracts/how_to_use_capsules.md).
+
+An oracle is something that allows us to get data from the outside world into our contracts. The most widely-known types of oracles in blockchain systems are probably Chainlink price feeds, which allow us to get the price of an asset in USD taking non-blockchain data into account.
+
+While this is one type of oracle, the more general oracle, allows us to get any data into the contract. In the context of oracle functions or oracle calls in Aztec, it can essentially be seen as user-provided arguments, that can be fetched at any point in the circuit, and don't need to be an input parameter.
+
+**Why is this useful? Why don't just pass them as input parameters?**
+In the world of EVM, you would just read the values directly from storage and call it a day. However, when we are working with circuits for private execution, this becomes more tricky as you cannot just read the storage directly from your state tree, because there are only commitments (e.g. hashes) there. The pre-images (content) of your commitments need to be provided to the function to prove that you actually allowed to modify them.
+
+If we fetch the notes using an oracle call, we can keep the function signature independent of the underlying data and make it easier to use. A similar idea, applied to the authentication mechanism is used for the Authentication Witnesses that allow us to have a single function signature for any wallet implementation, see [AuthWit](../../concepts/advanced/authwit.md) for more information on this.
+
+Oracles introduce **non-determinism** into a circuit, and thus are `unconstrained`. It is important that any information that is injected into a circuit through an oracle is later constrained for correctness. Otherwise, the circuit will be **under-constrained** and potentially insecure!
+
+`Aztec.nr` has a module dedicated to its oracles. If you are interested, you can view them by following the link below:
+```rust title="oracles-module" showLineNumbers
+/// Oracles module
+```
+> Source code: noir-projects/aztec-nr/aztec/src/oracle/mod.nr#L1-L3
+
+
+## Inbuilt oracles
+
+- [`debug_log`](https://github.com/AztecProtocol/aztec-packages/blob/master/noir-projects/aztec-nr/aztec/src/oracle/debug_log.nr) - Provides a couple of debug functions that can be used to log information to the console. Read more about debugging [here](../../../developers/reference/debugging/index.md).
+- [`auth_witness`](https://github.com/AztecProtocol/aztec-packages/blob/master/noir-projects/aztec-nr/authwit/src/auth_witness.nr) - Provides a way to fetch the authentication witness for a given address. This is useful when building account contracts to support approve-like functionality.
+- [`get_l1_to_l2_message`](https://github.com/AztecProtocol/aztec-packages/blob/master/noir-projects/aztec-nr/aztec/src/oracle/get_l1_to_l2_message.nr) - Useful for application that receive messages from L1 to be consumed on L2, such as token bridges or other cross-chain applications.
+- [`notes`](https://github.com/AztecProtocol/aztec-packages/blob/master/noir-projects/aztec-nr/aztec/src/oracle/notes.nr) - Provides a lot of functions related to notes, such as fetches notes from storage etc, used behind the scenes for value notes and other pre-build note implementations.
+- [`logs`](https://github.com/AztecProtocol/aztec-packages/blob/master/noir-projects/aztec-nr/aztec/src/oracle/logs.nr) - Provides the to log encrypted and unencrypted data.
+
+Find a full list [on GitHub](https://github.com/AztecProtocol/aztec-packages/tree/master/noir-projects/aztec-nr/aztec/src/oracle).
+
+Please note that it is **not** possible to write a custom oracle for your dapp. Oracles are implemented in the PXE, so all users of your dapp would have to use a PXE service with your custom oracle included. If you want to inject some arbitrary data that does not have a dedicated oracle, you can use [capsules](../../../developers/guides/smart_contracts/writing_contracts/how_to_use_capsules.md).
diff --git a/docs/versioned_docs/version-v0.82.2-alpha-testnet.5/aztec/smart_contracts_overview.md b/docs/versioned_docs/version-v0.82.2-alpha-testnet.5/aztec/smart_contracts_overview.md
new file mode 100644
index 000000000000..cd6ac1e5c391
--- /dev/null
+++ b/docs/versioned_docs/version-v0.82.2-alpha-testnet.5/aztec/smart_contracts_overview.md
@@ -0,0 +1,28 @@
+---
+title: Smart Contracts
+sidebar_position: 3
+tags: [contracts]
+---
+
+Smart contracts in Aztec are privacy-first, and can include both public and private elements. They are written in Noir framework called Aztec.nr, and allow high-level programs to be converted into ZK circuits.
+
+On this page, you’ll learn how Aztec executes smart contracts for privacy and efficiency:
+
+- Role and structure of smart contracts within Aztec
+- Intro into Noir programming language and how it converts to circuits
+- The Aztec Kernel
+- Transaction flow and confidentiality
+
+## Defining Aztec smart contracts
+
+A "smart contract" is defined as a set of public and private functions written as Noir circuits. These functions operate on public and private state stored by a contract. Each function is represented as a ZK SNARK verification key, where the contract is uniquely described by the set of its verification keys, and stored in the Aztec Contracts tree.
+
+[Noir](https://noir-lang.org) is a programming language designed for converting high-level programs into ZK circuits. Based on Rust, the goal is to present an idiomatic way of writing private smart contracts that is familiar to Ethereum developers. Noir is under active development adding features such as contracts, functions and storage variables.
+
+The end goal is a language that is intuitive to use for developers with no cryptographic knowledge and empowers developers to easily write programmable private smart contracts.
+
+There are no plans for EVM compatibility or to support Solidity in Aztec. The privacy-first nature of Aztec is fundamentally incompatible with the EVM architecture and Solidity's semantics. In addition, the heavy use of client-side proof construction makes this impractical.
+
+## Further reading
+
+Jump in and write your first smart contract [here](../developers/tutorials/codealong/contract_tutorials/counter_contract.md)
diff --git a/docs/versioned_docs/version-v0.82.2-alpha-testnet.5/aztec_connect_sunset.mdx b/docs/versioned_docs/version-v0.82.2-alpha-testnet.5/aztec_connect_sunset.mdx
new file mode 100644
index 000000000000..0861f5fcc721
--- /dev/null
+++ b/docs/versioned_docs/version-v0.82.2-alpha-testnet.5/aztec_connect_sunset.mdx
@@ -0,0 +1,93 @@
+---
+title: Aztec Connect Sunset
+---
+
+import Image from "@theme/IdealImage";
+
+:::danger Deprecated
+
+Aztec Connect is no longer being actively developed.
+
+:::
+
+The rollup instance operated by Aztec stopped accepting deposits on March 21st, 2023. Read the full announcement [here](https://medium.com/aztec-protocol/sunsetting-aztec-connect-a786edce5cae).
+
+We will continue to process transactions and withdrawals for funds that are already in the rollup until March 31st, 2024, at which point we will stop running the sequencer. Users should withdraw funds immediately. See the [zk.money](#zkmoney) section below for details on how to withdraw funds.
+
+## Run your own AC
+
+All of the infrastructure and associated code required to run and interact with the Aztec Connect rollup is open source, so anyone can publish blocks after we stop, or run their own instance of the rollup software.
+
+You can find the old documentation site that includes all of the pertinent information on the [`aztec-connect` branch](https://github.com/AztecProtocol/docs/tree/aztec-connect) of the docs repository.
+
+The code has been open sourced and you can find the relevant repositories linked below.
+
+### Source Code
+
+Follow the links for more information about each package.
+
+- [Running the rollup service](https://github.com/AztecProtocol/aztec-connect/blob/master/yarn-project/README.md)
+- [Sequencer](https://github.com/AztecProtocol/aztec-connect/tree/master/yarn-project/falafel)
+- [Contracts](https://github.com/AztecProtocol/aztec-connect/tree/master/contracts)
+- [SDK](https://github.com/AztecProtocol/aztec-connect/tree/master/yarn-project/sdk)
+- [Block Explorer](https://github.com/AztecProtocol/aztec-connect-explorer)
+- [Alpha SDK](https://github.com/AztecProtocol/aztec-connect/tree/master/yarn-project/alpha-sdk)
+- [Wallet UI](https://github.com/AztecProtocol/wallet-ui)
+
+## Zk.money
+
+### Exiting Defi Positions
+
+1. Navigate to your zk.money homepage and click “Wallet”.
+2. Scroll down to “Tokens” and “Earn Positions”.
+3. Click “Earn Positions”.
+4. Click “Claim & Exit” on the position you wish to exit.
+5. All exit transactions are free in “Batched Mode” proceed to step 6 to get a free transaction.
+6. Click “Max” to exit the full amount, and then select a speed for your transaction.
+7. Once you have done so, click “Next”.
+8. Review the amount you will receive is correct, tick the disclaimer, and click “Confirm Transaction”.
+9. After clicking confirm transaction, sign the signature request using your connected wallet (e.g. Metamask in this example).
+10. Wait until your transaction is confirmed.
+11. Navigate back to your wallet homepage and click “Earn Positions”.
+12. The status of your exit will be displayed here, as shown by “Exiting” (1 tick).
+13. To the left, click the transaction hash icon to be taken to the block explorer page to see the transaction status.
+14. Your funds will appear in your dashboard once the transaction has settled.
+
+### Exiting LUSD Borrowing
+
+Your LUSD debt is repaid using a flash loan. Part of your ETH collateral then repays the flash loan, and the remaining ETH is returned to your account. Your total TB-275 tokens represents the entirety of your share of the collateral. Spending all your TB-275 will release your entire share of the collateral (minus the market value of the debt to be repaid).
+
+Liquity: https://docs.liquity.org/
+
+1. Navigate to your zk.money homepage and click “Wallet”.
+2. Scroll down to “Tokens” and “Earn Positions”.
+3. Click “Earn Positions”.
+4. On your Liquity Trove position, click “Repay & Exit”.
+5. Click “Max” to exit the full amount, then select a speed for your transaction.
+6. Once you have done so, click “Next”.
+7. Review the amount you will receive is correct, tick the disclaimer, and click “Confirm Transaction”.
+8. After clicking confirm transaction, sign the signature request using your connected wallet (e.g. Metamask).
+9. Wait until your transaction is confirmed.
+10. Navigate to your zk.money wallet homepage and click “Earn Positions”.
+11. The status of your exit will be displayed here, as shown by “Exiting” (1 tick).
+12. Click the transaction hash icon to be taken to the block explorer page to see the transaction status.
+13. Your funds will appear in your dashboard once the transaction has settled.
+
+### Withdrawing Assets
+
+How to withdraw ETH, DAI and LUSD.
+
+1. Navigate to your zk.money homepage and click “Wallet”.
+2. Scroll down to “Tokens” and “Earn Positions”.
+3. Click “Tokens”.
+4. Click “Exit” on the desired token you would like to withdraw.
+5. Click “Withdraw to L1”.
+6. Enter your recipient address.
+7. Click “Max” to withdraw the full amount.
+8. Select a speed for your transaction (transactions are free in “Batched Mode”).
+9. Click “Next”.
+10. Review the amount you are withdrawing is correct, tick the disclaimer, and click “Confirm Transaction”.
+11. Sign the signature request using your connected wallet (e.g. Metamask).
+12. Wait until your transaction is confirmed.
+13. Navigate back to your wallet homepage, under Transaction History. Click the transaction hash to check the status of your transaction on the block explorer.
+14. Your funds will appear in your recipient wallet once the transaction has settled.
diff --git a/docs/versioned_docs/version-v0.82.2-alpha-testnet.5/building_in_public.md b/docs/versioned_docs/version-v0.82.2-alpha-testnet.5/building_in_public.md
new file mode 100644
index 000000000000..627e9d2b65ef
--- /dev/null
+++ b/docs/versioned_docs/version-v0.82.2-alpha-testnet.5/building_in_public.md
@@ -0,0 +1,49 @@
+---
+title: Building in Public
+sidebar_position: 0
+id: building_in_public
+---
+
+import Disclaimer from "@site/src/components/Disclaimers/\_wip_disclaimer.mdx";
+import ReactPlayer from "react-player/youtube";
+
+## How Aztec is being built
+
+Aztec will launch as a credibly neutral, decentralized network. The protocol is being developed as open source software by Aztec Labs and the community. Together we are designing, building and auditing much of the software that will be run by Aztec network stakeholders, such as infrastructure providers, wallets, and other core services.
+
+Contributors to Aztec uphold many of the values of the Ethereum community:
+
+- building in public
+- having a rigorous commitment to open source
+- believe in a permissionless, compliant, scalable and censorship-resistant system.
+
+## Our Cryptography
+
+Aztec is inspired by Ethereum. We believe in transparency for the protocol, but privacy for the user. This programmability is achieved through Smart Contracts, which are in fact Zero-Knowledge circuits.
+
+To allow for this, we focus on two main components:
+
+- **Noir** - We started developing Noir long before Aztec came into being. As an easy, open-source domain specific programming language for writing zero-knowledge circuits, it became the perfect language for writing [Aztec Smart Contracts](aztec/smart_contracts_overview.md). Read about standalone Noir in the [Noir Lang Documentation](https://noir-lang.org).
+- **Honk** - A collection of cutting-edge cryptography, from proving systems, to compilers, and other sidecars. These will support Aztec's rollup and allow for fast, private, client-side proving.
+
+## Media
+
+### Privacy Preserving Smart Contracts
+
+
+
+### Public-private Composability
+
+
+
+
diff --git a/docs/versioned_docs/version-v0.82.2-alpha-testnet.5/developers/getting_started.md b/docs/versioned_docs/version-v0.82.2-alpha-testnet.5/developers/getting_started.md
new file mode 100644
index 000000000000..60a45d9c11e2
--- /dev/null
+++ b/docs/versioned_docs/version-v0.82.2-alpha-testnet.5/developers/getting_started.md
@@ -0,0 +1,239 @@
+---
+title: Getting Started
+sidebar_position: 0
+tags: [sandbox]
+---
+
+This guide will teach you how to install the Aztec sandbox, run it using the Aztec CLI, and interact with contracts using the wallet CLI.
+
+The Sandbox is an Aztec network running fully on your machine, and interacting with a development Ethereum node. You can develop and deploy on it just like on a testnet or mainnet.
+
+## Prerequisites
+
+You need two global dependencies on your machine:
+
+- 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
+
+### Start Docker
+
+Docker needs to be running in order to install the sandbox. Find instructions on the [Docker website](https://docs.docker.com/get-started/).
+
+### Install the sandbox
+
+Run:
+
+```bash
+bash -i <(curl -s https://install.aztec.network)
+```
+
+This will install the following tools:
+
+- **aztec** - launches various infrastructure subsystems (full sandbox, sequencer, prover, pxe, etc) and provides utility commands to interact with the network
+- **aztec-nargo** - aztec's build of nargo, the noir compiler toolchain.
+- **aztec-up** - a tool to upgrade the aztec toolchain to the latest, or specific versions.
+- **aztec-wallet** - a tool for interacting with the aztec network
+
+### Start the sandbox
+
+Once these have been installed, to start the sandbox, run:
+
+```bash
+aztec start --sandbox
+```
+
+**Congratulations, you have just installed and run the Aztec Sandbox!**
+
+```bash
+ /\ | |
+ / \ ___| |_ ___ ___
+ / /\ \ |_ / __/ _ \/ __|
+ / ____ \ / /| || __/ (__
+ /_/___ \_\/___|\__\___|\___|
+
+```
+
+In the terminal, you will see some logs:
+
+1. Sandbox version
+2. Contract addresses of rollup contracts
+3. PXE (private execution environment) setup logs
+4. Initial accounts that are shipped with the sandbox and can be used in tests
+
+You'll know the sandbox is ready to go when you see something like this:
+
+```bash
+[INFO] Aztec Server listening on port 8080
+```
+
+## Using the sandbox test accounts
+
+import { CLI_Add_Test_Accounts } from '/components/snippets';
+
+
+
+
+To add the test accounts:
+
+```bash
+aztec-wallet import-test-accounts
+```
+
+We'll use the first test account, `test0`, throughout to pay for transactions.
+
+## Creating an account in the sandbox
+
+```bash
+aztec-wallet create-account -a my-wallet --payment method=fee_juice,feePayer=test0
+```
+
+This will create a new wallet with an account and give it the alias `my-wallet`. Accounts can be referenced with `accounts:`. You will see logs telling you the address, public key, secret key, and more.
+
+On successful depoyment of the account, you should see something like this:
+
+```bash
+New account:
+
+Address: 0x066108a2398e3e2ff53ec4b502e4c2e778c6de91bb889de103d5b4567530d99c
+Public key: 0x007343da506ea513e6c05ba4d5e92e3c682333d97447d45db357d05a28df0656181e47a6257e644c3277c0b11223b28f2b36c94f9b0a954523de61ac967b42662b60e402f55e3b7384ba61261335040fe4cd52cb0383f559a36eeea304daf67d1645b06c38ee6098f90858b21b90129e7e1fdc4666dd58d13ef8fab845b2211906656d11b257feee0e91a42cb28f46b80aabdc70baad50eaa6bb2c5a7acff4e30b5036e1eb8bdf96fad3c81e63836b8aa39759d11e1637bd71e3fc76e3119e500fbcc1a22e61df8f060004104c5a75b52a1b939d0f315ac29013e2f908ca6bc50529a5c4a2604c754d52c9e7e3dee158be21b7e8008e950991174e2765740f58
+Secret key: 0x1c94f8b19e91d23fd3ab6e15f7891fde7ba7cae01d3fa94e4c6afb4006ec0cfb
+Partial address: 0x2fd6b540a6bb129dd2c05ff91a9c981fb5aa2ac8beb4268f10b3aa5fb4a0fcd1
+Salt: 0x0000000000000000000000000000000000000000000000000000000000000000
+Init hash: 0x28df95b579a365e232e1c63316375c45a16f6a6191af86c5606c31a940262db2
+Deployer: 0x0000000000000000000000000000000000000000000000000000000000000000
+
+Waiting for account contract deployment...
+Deploy tx hash: 0a632ded6269bda38ad6b54cd49bef033078218b4484b902e326c30ce9dc6a36
+Deploy tx fee: 200013616
+Account stored in database with aliases last & my-wallet
+```
+
+You can double check by running `aztec-wallet get-alias accounts:my-wallet`.
+
+For simplicity we'll keep using the test account, let's deploy our own test token!
+
+## Deploying a contract
+
+The sandbox comes with some contracts that you can deploy and play with. One of these is an example token contract.
+
+Deploy it with this:
+
+```bash
+aztec-wallet deploy TokenContractArtifact --from accounts:test0 --args accounts:test0 TestToken TST 18 -a testtoken
+```
+
+This takes
+
+- the contract artifact as the argument, which is `TokenContractArtifact`
+- the deployer account, which we used `test0`
+- the args that the contract constructor takes, which is the `admin` (`accounts:test0`), `name` (`TestToken`), `symbol` (`TST`), and `decimals` (`18`).
+- an alias `testtoken` (`-a`) so we can easily reference it later with `contracts:testtoken`
+
+On successful deployment, you should see something like this:
+
+```bash
+aztec:wallet [INFO] Using wallet with address 0x066108a2398e3e2ff53ec4b502e4c2e778c6de91bb889de103d5b4567530d99c +0ms
+Contract deployed at 0x15ce68d4be65819fe9c335132f10643b725a9ebc7d86fb22871f6eb8bdbc3abd
+Contract partial address 0x25a91e546590d77108d7b184cb81b0a0999e8c0816da1a83a2fa6903480ea138
+Contract init hash 0x0abbaf0570bf684da355bd9a9a4b175548be6999625b9c8e0e9775d140c78506
+Deployment tx hash: 0a8ccd1f4e28092a8fa4d1cb85ef877f8533935c4e94b352a38af73eee17944f
+Deployment salt: 0x266295eb5da322aba96fbb24f9de10b2ba01575dde846b806f884f749d416707
+Deployment fee: 200943060
+Contract stored in database with aliases last & testtoken
+```
+
+In the next step, let's mint some tokens!
+
+## Minting public tokens
+
+Call the public mint function like this:
+
+```bash
+aztec-wallet send mint_to_public --from accounts:test0 --contract-address contracts:testtoken --args accounts:test0 100
+```
+
+This takes
+
+- the function name as the argument, which is `mint_to_public`
+- the `from` account (caller) which is `accounts:test0`
+- the contract address, which is aliased as `contracts:testtoken` (or simply `testtoken`)
+- the args that the function takes, which is the account to mint the tokens into (`test0`), and `amount` (`100`).
+
+This only works because we are using the secret key of the admin who has permissions to mint.
+
+A successful call should print something like this:
+
+```bash
+aztec:wallet [INFO] Using wallet with address 0x066108a2398e3e2ff53ec4b502e4c2e778c6de91bb889de103d5b4567530d99c +0ms
+Maximum total tx fee: 1161660
+Estimated total tx fee: 116166
+Estimated gas usage: da=1127,l2=115039,teardownDA=0,teardownL2=0
+
+Transaction hash: 2ac383e8e2b68216cda154b52e940207a905c1c38dadba7a103c81caacec403d
+Transaction has been mined
+ Tx fee: 200106180
+ Status: success
+ Block number: 17
+ Block hash: 1e27d200600bc45ab94d467c230490808d1e7d64f5ee6cee5e94a08ee9580809
+Transaction hash stored in database with aliases last & mint_to_public-9044
+```
+
+You can double-check by calling the function that checks your public account balance:
+
+```bash
+aztec-wallet simulate balance_of_public --from test0 --contract-address testtoken --args accounts:test0
+```
+
+This should print
+
+```bash
+Simulation result: 100n
+```
+
+## Playing with hybrid state and private functions
+
+In the following steps, we'll moving some tokens from public to private state, and check our private and public balance.
+
+```bash
+aztec-wallet send transfer_to_private --from accounts:test0 --contract-address testtoken --args accounts:test0 25
+```
+
+The arguments for `transfer_to_private` function are:
+
+- the account address to transfer to
+- the amount of tokens to send to private
+
+A successful call should print something similar to what you've seen before.
+
+Now when you call `balance_of_public` again you will see 75!
+
+```bash
+aztec-wallet simulate balance_of_public --from test0 --contract-address testtoken --args accounts:test0
+```
+
+This should print
+
+```bash
+Simulation result: 75n
+```
+
+And then call `balance_of_private` to check that you have your tokens!
+
+```bash
+aztec-wallet simulate balance_of_private --from test0 --contract-address testtoken --args accounts:test0
+```
+
+This should print
+
+```bash
+Simulation result: 25n
+```
+
+**Congratulations, you now know the fundamentals of working with the Aztec sandbox!** You are ready to move onto the more fun stuff.
+
+## What's next?
+
+Click the Next button below to continue on your journey and write your first Aztec smart contract.
diff --git a/docs/versioned_docs/version-v0.82.2-alpha-testnet.5/developers/guides/_category_.json b/docs/versioned_docs/version-v0.82.2-alpha-testnet.5/developers/guides/_category_.json
new file mode 100644
index 000000000000..3d8f3e3bf4c7
--- /dev/null
+++ b/docs/versioned_docs/version-v0.82.2-alpha-testnet.5/developers/guides/_category_.json
@@ -0,0 +1,4 @@
+{
+ "label": "Guides",
+ "link": { "type": "doc", "id": "guides/index" }
+}
diff --git a/docs/versioned_docs/version-v0.82.2-alpha-testnet.5/developers/guides/getting_started/_category_.json b/docs/versioned_docs/version-v0.82.2-alpha-testnet.5/developers/guides/getting_started/_category_.json
new file mode 100644
index 000000000000..4b7c1cbad3b2
--- /dev/null
+++ b/docs/versioned_docs/version-v0.82.2-alpha-testnet.5/developers/guides/getting_started/_category_.json
@@ -0,0 +1,6 @@
+{
+ "position": 1,
+ "collapsible": true,
+ "collapsed": false,
+ "label": "Getting Started"
+}
diff --git a/docs/versioned_docs/version-v0.82.2-alpha-testnet.5/developers/guides/getting_started/codespaces.md b/docs/versioned_docs/version-v0.82.2-alpha-testnet.5/developers/guides/getting_started/codespaces.md
new file mode 100644
index 000000000000..10658c856c2f
--- /dev/null
+++ b/docs/versioned_docs/version-v0.82.2-alpha-testnet.5/developers/guides/getting_started/codespaces.md
@@ -0,0 +1,25 @@
+---
+title: Codespaces
+sidebar_position: 1
+draft: true
+---
+
+If you do not want to run the sandbox locally, or if your machine is unsupported (eg Windows), it is possible to run it within a GitHub Codespace.
+
+[GitHub Codespaces](https://github.com/features/codespaces) are a quick way to develop: they provision a remote machine with all tooling you need for Aztec in just a few minutes. You can use some prebuilt images to make it easier and faster.
+
+Choose a boilerplate and click "create new codespace":
+
+[](https://codespaces.new/AztecProtocol/aztec-packages?devcontainer_path=.devcontainer%2Freact%2Fdevcontainer.json) [](https://codespaces.new/AztecProtocol/aztec-packages?devcontainer_path=.devcontainer%2Fvanilla%2Fdevcontainer.json) [](https://codespaces.new/AztecProtocol/aztec-packages?devcontainer_path=.devcontainer%2Ftoken%2Fdevcontainer.json)
+
+This creates a codespace with a prebuilt image containing one of the "Aztec Boxes" and a development network (sandbox).
+- You can develop directly on the codespace, push it to a repo, make yourself at home.
+- You can also just use the sandbox that comes with it. The URL will be logged, you just need to use it as your `PXE_URL`.
+
+You can then start, stop, or see the logs of your sandbox just by calling `sandbox` or `npx aztec-app sandbox`. Run `sandbox -h` for a list of commands.
+
+## More about codespaces
+
+Codespaces are way more powerful than you may initially think. For example, you can connect your local `vscode` to a remote codespace, for a fully contained development environment that doesn't use any of your computer resources!
+
+Visit the [codespaces documentation](https://docs.github.com/en/codespaces/overview) for more specific documentation around codespaces.
diff --git a/docs/versioned_docs/version-v0.82.2-alpha-testnet.5/developers/guides/js_apps/_category_.json b/docs/versioned_docs/version-v0.82.2-alpha-testnet.5/developers/guides/js_apps/_category_.json
new file mode 100644
index 000000000000..5e0931f01e5e
--- /dev/null
+++ b/docs/versioned_docs/version-v0.82.2-alpha-testnet.5/developers/guides/js_apps/_category_.json
@@ -0,0 +1,6 @@
+{
+ "position": 3,
+ "collapsible": true,
+ "collapsed": true,
+ "label": "Aztec.js"
+}
diff --git a/docs/versioned_docs/version-v0.82.2-alpha-testnet.5/developers/guides/js_apps/authwit.md b/docs/versioned_docs/version-v0.82.2-alpha-testnet.5/developers/guides/js_apps/authwit.md
new file mode 100644
index 000000000000..313f894af5b2
--- /dev/null
+++ b/docs/versioned_docs/version-v0.82.2-alpha-testnet.5/developers/guides/js_apps/authwit.md
@@ -0,0 +1,197 @@
+---
+title: How to use authentication witnesses (authwit)
+tags: [accounts, authwit]
+sidebar_position: 5
+---
+
+This page assumes you have authwit set up correctly in your contract. To learn how to do that, [go here](../smart_contracts/writing_contracts/authwit.md).
+
+For an introduction to authentication witnesses on Aztec, [read this explainer](../../../aztec/concepts/advanced/authwit.md).
+
+## Import libraries
+
+These are all the libraries you might need for using authwits in Aztec.js:
+
+```typescript
+import {
+ computeAuthWitMessageHash,
+ computeInnerAuthWitHash,
+} from "@aztec/aztec.js";
+```
+
+You may not need all of these.
+
+## Publicly deploy accounts
+
+:::note
+This is only required if you are using authwits in public
+:::
+
+If you are using public authwit (ie using `assert_current_call_valid_authwit_public` in your contract), you will need to deploy the following accounts publicly:
+
+1. The account that is giving permission to an account to act on behalf of it (authwit giver)
+2. The account that does the action (authwit receiver)
+
+Here is an example implementation:
+
+```typescript title="public_deploy_accounts" showLineNumbers
+export async function ensureAccountsPubliclyDeployed(sender: Wallet, accountsToDeploy: Wallet[]) {
+ // We have to check whether the accounts are already deployed. This can happen if the test runs against
+ // the sandbox and the test accounts exist
+ const accountsAndAddresses = await Promise.all(
+ accountsToDeploy.map(async account => {
+ const address = account.getAddress();
+ return {
+ address,
+ deployed: (await sender.getContractMetadata(address)).isContractPubliclyDeployed,
+ };
+ }),
+ );
+ const instances = (
+ await Promise.all(
+ accountsAndAddresses
+ .filter(({ deployed }) => !deployed)
+ .map(({ address }) => sender.getContractMetadata(address)),
+ )
+ ).map(contractMetadata => contractMetadata.contractInstance);
+ const contractClass = await getContractClassFromArtifact(SchnorrAccountContractArtifact);
+ if (!(await sender.getContractClassMetadata(contractClass.id, true)).isContractClassPubliclyRegistered) {
+ await (await registerContractClass(sender, SchnorrAccountContractArtifact)).send().wait();
+ }
+ const requests = await Promise.all(instances.map(async instance => await deployInstance(sender, instance!)));
+ const batch = new BatchCall(sender, requests);
+ await batch.send().wait();
+}
+```
+> Source code: yarn-project/end-to-end/src/fixtures/utils.ts#L634-L662
+
+
+You would then call this like so:
+
+```typescript title="public_deploy_accounts" showLineNumbers
+await ensureAccountsPubliclyDeployed(wallets[0], wallets.slice(0, 2));
+```
+> Source code: yarn-project/end-to-end/src/e2e_authwit.test.ts#L24-L26
+
+
+## Define the action
+
+When creating an authwit, you will need to pass the authwit giver, the authwit receiver (who will perform the action), and the action that is being authorized. The action can be a smart contract function call, or alternatively, arbitrary data.
+
+### When the action is a function call
+
+You can define the action like this:
+
+```typescript title="authwit_computeAuthWitMessageHash" showLineNumbers
+const action = asset
+ .withWallet(wallets[1])
+ .methods.transfer(wallets[0].getAddress(), wallets[1].getAddress(), amount, nonce);
+```
+> Source code: yarn-project/end-to-end/src/e2e_blacklist_token_contract/transfer_private.test.ts#L57-L61
+
+
+In this example,
+
+- `asset` refers to a token contract
+- `withWallet(wallets[1])` is specifying the authwit receiver (`wallets[1]`) will do this action
+- `.methods.transfer()` is specifying that the action is calling the `transfer` method on the token contract
+- `(wallets[0].getAddress(), wallets[1].getAddress(), amount, nonce);` are the args of this method - it will send the `amount` from `wallets[0]` to `wallets[1]`
+
+### Arbitrary message
+
+You can hash your own authwit message by creating an inner hash with the data, like this:
+
+```typescript title="compute_inner_authwit_hash" showLineNumbers
+const innerHash = await computeInnerAuthWitHash([Fr.fromHexString('0xdead')]);
+```
+> Source code: yarn-project/end-to-end/src/e2e_authwit.test.ts#L45-L47
+
+
+Then create the message hash by hashing the inner hash with the authwit receiver address, chainId, and version:
+
+```typescript title="compute_arbitrary_authwit_hash" showLineNumbers
+
+const intent = { consumer: auth.address, innerHash };
+```
+> Source code: yarn-project/end-to-end/src/e2e_authwit.test.ts#L48-L51
+
+
+## Create the authwit
+
+There are slightly different interfaces depending on whether your contract is checking the authwit in private or public.
+
+Public authwits are stored in the account contract and batched with the authwit action call, so a user must send a transaction to update their account contract, authorizing an action before the authorized contract's public call will succeed.
+
+Private execution uses oracles and are executed locally by the PXE, so the authwit needs to be created by the authwit giver and then added to the authwit receiver's PXE.
+
+### Private
+
+This is expected to be used alongside [private authwits in Aztec.nr contract](../smart_contracts/writing_contracts/authwit.md#private-functions).
+
+Create a private authwit like this:
+
+```typescript title="create_authwit" showLineNumbers
+const witness = await wallets[0].createAuthWit({ caller: wallets[1].getAddress(), action });
+```
+> Source code: yarn-project/end-to-end/src/e2e_blacklist_token_contract/transfer_private.test.ts#L62-L64
+
+
+In this example,
+
+- `wallets[0]` is the authwit giver
+- `wallets[1]` is the authwit receiver and caller of the function
+- `action` was [defined previously](#define-the-action)
+
+If you created an arbitrary message, you can create the authwit by replacing these params with the outer hash:
+
+```typescript title="compute_arbitrary_authwit_hash" showLineNumbers
+
+const intent = { consumer: auth.address, innerHash };
+```
+> Source code: yarn-project/end-to-end/src/e2e_authwit.test.ts#L48-L51
+
+
+Then add it to the wallet of the authwit receiver (the caller of the function):
+
+```typescript title="add_authwit" showLineNumbers
+await action.send({ authWitnesses: [witness] }).wait();
+```
+> Source code: yarn-project/end-to-end/src/e2e_blacklist_token_contract/transfer_private.test.ts#L68-L70
+
+
+### Public
+
+This is expected to be used alongside [public authwits in Aztec.nr contract](../smart_contracts/writing_contracts/authwit.md#public-functions).
+
+Set a public authwit like this:
+
+```typescript title="set_public_authwit" showLineNumbers
+const validateActionInteraction = await wallets[0].setPublicAuthWit(
+ { caller: wallets[1].getAddress(), action },
+ true,
+);
+await validateActionInteraction.send().wait();
+```
+> Source code: yarn-project/end-to-end/src/e2e_blacklist_token_contract/transfer_public.test.ts#L119-L125
+
+
+Remember it is a transaction and calls a method in the account contract. In this example,
+
+- `wallets[0]` is the authwit giver
+- `wallets[1]` is the authwit receiver and caller of the function
+- `action` was [defined previously](#define-the-action)
+- `true` sets the `authorized` boolean (`false` would revoke this authwit)
+
+If you created an arbitrary message, you would replace the first param struct with the outer hash:
+
+```typescript title="set_public_authwit" showLineNumbers
+const validateActionInteraction = await wallets[0].setPublicAuthWit(intent, true);
+await validateActionInteraction.send().wait();
+```
+> Source code: yarn-project/end-to-end/src/e2e_authwit.test.ts#L155-L158
+
+
+## Further reading
+
+- [An explainer of authentication witnesses](../../../aztec/concepts/advanced/authwit.md)
+- [Authwits in Aztec.nr](../smart_contracts/writing_contracts/authwit.md)
diff --git a/docs/versioned_docs/version-v0.82.2-alpha-testnet.5/developers/guides/js_apps/call_view_function.md b/docs/versioned_docs/version-v0.82.2-alpha-testnet.5/developers/guides/js_apps/call_view_function.md
new file mode 100644
index 000000000000..c1ede5af8a03
--- /dev/null
+++ b/docs/versioned_docs/version-v0.82.2-alpha-testnet.5/developers/guides/js_apps/call_view_function.md
@@ -0,0 +1,51 @@
+---
+title: How to Simulate a Function Call
+tags: [functions]
+sidebar_position: 2
+---
+
+This guide explains how to `simulate` a function call using Aztec.js.
+
+## Prerequisites
+
+You should have a wallet to act as the caller, and a contract that has been deployed.
+
+You can learn how to create wallets from [this guide](./create_account.md).
+
+You can learn how to deploy a contract [here](./deploy_contract.md).
+
+## Relevant imports
+
+You will need to import this from Aztec.js:
+
+```typescript title="import_contract" showLineNumbers
+import { Contract } from '@aztec/aztec.js';
+```
+> Source code: yarn-project/end-to-end/src/composed/docs_examples.test.ts#L7-L9
+
+
+## Define contract
+
+Get a previously deployed contract like this:
+
+```typescript title="get_contract" showLineNumbers
+const contract = await Contract.at(deployedContract.address, TokenContractArtifact, wallet);
+```
+> Source code: yarn-project/end-to-end/src/composed/docs_examples.test.ts#L45-L47
+
+
+## Simulating function calls
+
+Call the `simulate` function on the typescript contract wrapper like this:
+
+```typescript title="simulate_function" showLineNumbers
+const balance = await contract.methods.balance_of_public(newWallet.getAddress()).simulate();
+expect(balance).toEqual(1n);
+```
+> Source code: yarn-project/end-to-end/src/composed/docs_examples.test.ts#L54-L57
+
+
+:::info Note
+- If the simulated function is `unconstrained` you will get a properly typed value.
+- If the simulated function is `public` or `private` it will return a Field array of size 4.
+:::
diff --git a/docs/versioned_docs/version-v0.82.2-alpha-testnet.5/developers/guides/js_apps/create_account.md b/docs/versioned_docs/version-v0.82.2-alpha-testnet.5/developers/guides/js_apps/create_account.md
new file mode 100644
index 000000000000..9ce12e997101
--- /dev/null
+++ b/docs/versioned_docs/version-v0.82.2-alpha-testnet.5/developers/guides/js_apps/create_account.md
@@ -0,0 +1,44 @@
+---
+title: How to Create a New Account
+tags: [accounts]
+sidebar_position: 0
+---
+
+This guide explains how to create a new account using Aztec.js.
+
+## Relevant imports
+
+You will need to import these libraries:
+
+```typescript title="create_account_imports" showLineNumbers
+import { getSchnorrAccount } from '@aztec/accounts/schnorr';
+import { getDeployedTestAccountsWallets } from '@aztec/accounts/testing';
+import { Fr, GrumpkinScalar, createPXEClient } from '@aztec/aztec.js';
+```
+> Source code: yarn-project/end-to-end/src/composed/docs_examples.test.ts#L2-L6
+
+
+## Define arguments needed
+
+```typescript title="define_account_vars" showLineNumbers
+const PXE_URL = process.env.PXE_URL || 'http://localhost:8080';
+const pxe = createPXEClient(PXE_URL);
+const secretKey = Fr.random();
+const signingPrivateKey = GrumpkinScalar.random();
+```
+> Source code: yarn-project/end-to-end/src/composed/docs_examples.test.ts#L18-L23
+
+
+## Create the wallet with these args
+
+```typescript title="create_wallet" showLineNumbers
+// Use a pre-funded wallet to pay for the fees for the deployments.
+const wallet = (await getDeployedTestAccountsWallets(pxe))[0];
+const newAccount = await getSchnorrAccount(pxe, secretKey, signingPrivateKey);
+await newAccount.deploy({ deployWallet: wallet }).wait();
+const newWallet = await newAccount.getWallet();
+```
+> Source code: yarn-project/end-to-end/src/composed/docs_examples.test.ts#L25-L31
+
+
+Now you have a new wallet in your PXE! To learn how to use this wallet to deploy a contract, read [this guide](./deploy_contract.md).
diff --git a/docs/versioned_docs/version-v0.82.2-alpha-testnet.5/developers/guides/js_apps/deploy_contract.md b/docs/versioned_docs/version-v0.82.2-alpha-testnet.5/developers/guides/js_apps/deploy_contract.md
new file mode 100644
index 000000000000..02f0852d0529
--- /dev/null
+++ b/docs/versioned_docs/version-v0.82.2-alpha-testnet.5/developers/guides/js_apps/deploy_contract.md
@@ -0,0 +1,139 @@
+---
+title: How to Deploy a Contract
+tags: [contracts]
+sidebar_position: 1
+---
+
+Once you have [compiled](../smart_contracts/how_to_compile_contract.md) your contracts you can proceed to deploying them using Aztec.js.
+
+You can use this method to deploy your contracts to the sandbox or to a remote network.
+
+## Prerequisites
+
+- Contract artifacts ready (go to [How to Compile Contract](../smart_contracts/how_to_compile_contract.md) for instructions on how to compile contracts)
+- Aztec Sandbox running (go to [Getting Started](../../getting_started.md) for instructions on how to install and run the sandbox)
+
+## Deploy
+
+Contracts can be deployed using the `aztec.js` library.
+
+### Generate the typescript artifact
+
+Compile the contract:
+
+```bash
+aztec-nargo compile
+```
+
+Generate the typescript class:
+
+```bash
+aztec codegen ./aztec-nargo/output/target/path -o src/artifacts
+```
+
+This would create a typescript file like `Example.ts` in `./src/artifacts`.
+
+### Deploying
+
+Import the typescript artifact into your file.
+
+```typescript title="import_artifact" showLineNumbers
+import { TokenContractArtifact } from '@aztec/noir-contracts.js/Token';
+```
+> Source code: yarn-project/end-to-end/src/sample-dapp/deploy.mjs#L5-L7
+
+
+Then you can use the `Contract` class **or** the [generated contract class](#using-generated-class) to deploy the contract.
+
+To use the `Contract` class to deploy a contract:
+
+```typescript title="dapp-deploy" showLineNumbers
+const { PXE_URL = 'http://localhost:8080' } = process.env;
+
+async function main() {
+ const pxe = createPXEClient(PXE_URL);
+ await waitForPXE(pxe);
+
+ const [ownerWallet] = await getInitialTestAccountsWallets(pxe);
+ const ownerAddress = ownerWallet.getAddress();
+
+ const token = await Contract.deploy(ownerWallet, TokenContractArtifact, [ownerAddress, 'TokenName', 'TKN', 18])
+ .send()
+ .deployed();
+
+ console.log(`Token deployed at ${token.address.toString()}`);
+
+ const addresses = { token: token.address.toString() };
+ writeFileSync('addresses.json', JSON.stringify(addresses, null, 2));
+}
+```
+> Source code: yarn-project/end-to-end/src/sample-dapp/deploy.mjs#L13-L32
+
+
+#### Deploy Arguments
+
+There are several optional arguments that can be passed:
+
+The `deploy(...)` method is generated automatically with the typescript class representing your contract.
+
+Additionally the `.send()` method can have a few optional arguments too, which are specified in an optional object:
+
+```typescript title="deploy_options" showLineNumbers
+export type DeployOptions = {
+ /** An optional salt value used to deterministically calculate the contract address. */
+ contractAddressSalt?: Fr;
+ /** Set to true to *not* include the sender in the address computation. */
+ universalDeploy?: boolean;
+ /** Skip contract class registration. */
+ skipClassRegistration?: boolean;
+ /** Skip public deployment, instead just privately initialize the contract. */
+ skipPublicDeployment?: boolean;
+ /** Skip contract initialization. */
+ skipInitialization?: boolean;
+} & SendMethodOptions;
+```
+> Source code: yarn-project/aztec.js/src/contract/deploy_method.ts#L30-L43
+
+
+### Using generated contract class
+
+As a more complete example, here a `Token` contract deployment whose artifacts are included in the `@aztec/noir-contracts.js` package. You can use similar deployment syntax with your own contract by importing the TS artifact generated with `aztec codegen`. This example uses the generated `TokenContract` to deploy.
+
+```ts
+import { getSchnorrAccount } from '@aztec/accounts/schnorr';
+import { getDeployedTestAccountsWallets } from '@aztec/accounts/testing';
+import { Fr, GrumpkinScalar, createPXEClient } from '@aztec/aztec.js';
+import { Contract } from '@aztec/aztec.js';
+import { TokenContract, TokenContractArtifact } from '@aztec/noir-contracts.js/Token';
+
+async function main(){
+
+const PXE_URL = process.env.PXE_URL || 'http://localhost:8080';
+const pxe = createPXEClient(PXE_URL);
+const secretKey = Fr.random();
+const signingPrivateKey = GrumpkinScalar.random();
+
+// Use a pre-funded wallet to pay for the fees for the deployments.
+const wallet = (await getDeployedTestAccountsWallets(pxe))[0];
+const newAccount = await getSchnorrAccount(pxe, secretKey, signingPrivateKey);
+await newAccount.deploy({ deployWallet: wallet }).wait();
+const newWallet = await newAccount.getWallet();
+
+const deployedContract = await TokenContract.deploy(
+ wallet, // wallet instance
+ wallet.getAddress(), // account
+ 'TokenName', // constructor arg1
+ 'TokenSymbol', // constructor arg2
+ 18,
+)
+ .send()
+ .deployed();
+
+const contract = await Contract.at(deployedContract.address, TokenContractArtifact, wallet);
+
+}
+```
+
+:::note
+You can try running the deployment with the same salt the second time in which case the transaction will fail because the address has been already deployed to.
+:::
\ No newline at end of file
diff --git a/docs/versioned_docs/version-v0.82.2-alpha-testnet.5/developers/guides/js_apps/index.md b/docs/versioned_docs/version-v0.82.2-alpha-testnet.5/developers/guides/js_apps/index.md
new file mode 100644
index 000000000000..81693257eed5
--- /dev/null
+++ b/docs/versioned_docs/version-v0.82.2-alpha-testnet.5/developers/guides/js_apps/index.md
@@ -0,0 +1,34 @@
+---
+title: Aztec.js
+tags: [aztec.js, javascript, typescript]
+---
+
+import DocCardList from "@theme/DocCardList";
+
+Aztec.js is a library that provides APIs for managing accounts and interacting with contracts on the Aztec network. It communicates with the [Private eXecution Environment (PXE)](../../../aztec/concepts/pxe/index.md) through a `PXE` implementation, allowing developers to easily register new accounts, deploy contracts, view functions, and send transactions.
+
+## Installing
+
+```
+npm install @aztec/aztec.js
+```
+
+## Importing
+
+At the top of your JavaScript file, you can import what you need, eg:
+
+```typescript title="import_aztecjs" showLineNumbers
+import type { AztecNodeConfig } from '@aztec/aztec-node';
+import { type AztecNode, ContractDeployer, Fr, type Wallet, waitForProven } from '@aztec/aztec.js';
+```
+> Source code: yarn-project/end-to-end/src/e2e_simple.test.ts#L1-L4
+
+
+## Flow
+
+These are some of the important functions you'll need to use in your Aztec.js:
+
+- [Create an account with `@aztec/accounts`](./create_account.md)
+- [Deploy a contract](./deploy_contract.md)
+- [Simulate a function call](./call_view_function.md)
+- [Send a transaction](./send_transaction.md)
\ No newline at end of file
diff --git a/docs/versioned_docs/version-v0.82.2-alpha-testnet.5/developers/guides/js_apps/pay_fees.md b/docs/versioned_docs/version-v0.82.2-alpha-testnet.5/developers/guides/js_apps/pay_fees.md
new file mode 100644
index 000000000000..f94e4e5d4fcf
--- /dev/null
+++ b/docs/versioned_docs/version-v0.82.2-alpha-testnet.5/developers/guides/js_apps/pay_fees.md
@@ -0,0 +1,240 @@
+---
+title: How to Pay Fees
+tags: [fees, transactions, developers]
+sidebar_position: 3
+---
+
+There a several ways to pay for transaction fees, thanks to fee abstraction implemented in the Aztec protocol.
+
+This guide shows the various ways this can be done. For more of a background see [Fees on Aztec](../../../aztec/concepts/fees).
+
+## Methods to pay a tx fee
+
+### Natively via an existing balance of fee juice
+
+Either your own account or someone else's address has a balance of fee juice, and the transaction is paid for from this balance.
+
+### Natively via a balance of fee juice to be claimed
+
+Processing this transaction first claims bridged fee juice then is paid for from the balance, all in the same public/private tx.
+
+### Privately or publicly via a Fee Paying Contract
+
+A fee paying contract (FPC) is created and nominates a token that it accepts to then pay for txs in fee juice. So a user doesn't need to hold fee juice, they only need the token that the FPC accepts.
+
+### Sponsored Fee Paying Contract (SponsoredFPC)
+
+The most straightforward way to pay for a transaction is via the sponsored fee payment method, bootstrapping some transactions by skipping the need to bridge fee juice to the account. This method uses a type of fee paying contract configured to pay for a number of transactions without requiring payment.
+
+## Bridging fee-juice
+
+To first get fee juice into an account it needs to be bridged from L1. You can skip this section if you want to first make a transaction via the SponsoredFPC.
+
+:::note
+See here to [Bridge Fee Juice](../../../developers/reference/environment_reference/cli_wallet_reference#bridge-fee-juice) via the CLI wallet.
+
+:::
+
+One way of bridging of tokens is described fully [here](../../../developers/tutorials/codealong/contract_tutorials/token_bridge#deposit-to-aztec). Below summarises specifically bridging fee juice on the sandbox.
+
+First get the node info and create a public client pointing to the sandbox's anvil L1 node (from foundry):
+
+```javascript title="get_node_info_pub_client" showLineNumbers
+const info = await pxe.getNodeInfo();
+const publicClient = getPublicClient({
+ l1RpcUrls: ['http://localhost:8545'],
+ l1ChainId: foundry.id,
+});
+```
+> Source code: yarn-project/end-to-end/src/spartan/smoke.test.ts#L50-L56
+
+
+After importing:
+
+```ts
+import { L1FeeJuicePortalManager } from "@aztec/aztec.js";
+```
+
+Create a new fee juice portal manager and bridge fee juice publicly to Aztec:
+
+```javascript title="bridge_fee_juice" showLineNumbers
+const portal = await L1FeeJuicePortalManager.new(pxe, publicClient, walletClient, log);
+const claim = await portal.bridgeTokensPublic(recipient, amount, true /* mint */);
+```
+> Source code: yarn-project/end-to-end/src/spartan/setup_test_wallets.ts#L109-L112
+
+
+Bridging can also be done privately with the corresponding function:
+
+```javascript title="bridge_tokens_private" showLineNumbers
+/**
+ * Bridges tokens from L1 to L2 privately. Handles token approvals. Returns once the tx has been mined.
+ * @param to - Address to send the tokens to on L2.
+ * @param amount - Amount of tokens to send.
+ * @param mint - Whether to mint the tokens before sending (only during testing).
+ */
+public async bridgeTokensPrivate(
+ to: AztecAddress,
+ amount: bigint,
+ mint = false,
+): Promise {
+```
+> Source code: yarn-project/aztec.js/src/ethereum/portal_manager.ts#L312-L324
+
+
+For the mechanisms to complete bridging between L1 and Aztec, any two other transactions on the sandbox are made. After this, an already deployed account should have its fee juice ready to use in transactions.
+
+Alternatively, the resulting claim object can be used to create a payment method to claim and pay for a transaction in one, where the transaction is the contract's deployment.
+
+
+## Fee Options
+
+Functions pertaining to sending a transaction, such as `deploy` and `send`, each include a `fee` variable defined with the following (optional) parameters:
+
+```javascript title="user_fee_options" showLineNumbers
+/** Fee options as set by a user. */
+export type UserFeeOptions = {
+ /** The fee payment method to use */
+ paymentMethod?: FeePaymentMethod;
+ /** The gas settings */
+ gasSettings?: Partial>;
+ /** Percentage to pad the base fee by, if empty, defaults to 0.5 */
+ baseFeePadding?: number;
+ /** Whether to run an initial simulation of the tx with high gas limit to figure out actual gas settings. */
+ estimateGas?: boolean;
+ /** Percentage to pad the estimated gas limits by, if empty, defaults to 0.1. Only relevant if estimateGas is set. */
+ estimatedGasPadding?: number;
+};
+```
+> Source code: yarn-project/entrypoints/src/interfaces.ts#L79-L93
+
+
+
+### Fee Payment Method
+
+The `paymentMethod` is an object for the type of payment. Each of the implementations can be found [here](https://github.com/AztecProtocol/aztec-packages/blob/v0.82.2/yarn-project/aztec.js/src/fee). For example:
+
+```javascript title="fee_juice_method" showLineNumbers
+/**
+ * Pay fee directly in the Fee Juice.
+ */
+export class FeeJuicePaymentMethod implements FeePaymentMethod {
+```
+> Source code: yarn-project/aztec.js/src/fee/fee_juice_payment_method.ts#L6-L11
+
+
+### Gas Settings
+
+```javascript title="gas_settings_vars" showLineNumbers
+/** Gas usage and fees limits set by the transaction sender for different dimensions and phases. */
+export class GasSettings {
+ constructor(
+ public readonly gasLimits: Gas,
+ public readonly teardownGasLimits: Gas,
+ public readonly maxFeesPerGas: GasFees,
+ public readonly maxPriorityFeesPerGas: GasFees,
+ ) {}
+```
+> Source code: yarn-project/stdlib/src/gas/gas_settings.ts#L11-L20
+
+
+import { Gas_Settings_Components, Gas_Settings } from '/components/snippets';
+
+
+
+
+
+
+### Other params
+
+Fee and gas padding params can be left to their default values, and the estimateGas boolean can be used when simulating a tx to calculate gas.
+
+With the fee options explained, lets do a paid transaction.
+
+## Examples
+
+### Sponsored Fee Paying Contract
+
+Creating the SponsoredFPC is as simple as passing it the PXE:
+```ts
+const paymentMethod = await SponsoredFeePaymentMethod.new(pxe);
+```
+
+Then a transaction can specify this as the `paymentMethod` in the fee object.
+For example, a contract can be deployed with an fpc as follows:
+
+```ts
+const paymentMethod = await SponsoredFeePaymentMethod.new(pxe);
+myAccountManager.deploy({ fee: { paymentMethod } });
+```
+
+### Pay with FeeJuice
+
+To send a transaction from an already deployed account already holding fee juice:
+(Note: this example is a public token transfer call, but can equally be a private function call)
+
+```javascript title="pay_fee_juice_send" showLineNumbers
+const paymentMethod = new FeeJuicePaymentMethod(aliceAddress);
+const { transactionFee } = await bananaCoin.methods
+ .transfer_in_public(aliceAddress, bobAddress, 1n, 0n)
+ .send({ fee: { gasSettings, paymentMethod } })
+ .wait();
+```
+> Source code: yarn-project/end-to-end/src/e2e_fees/fee_juice_payments.test.ts#L86-L92
+
+
+**The equivalent to specify fees via CLI...**
+
+import { CLI_Fees } from '/components/snippets';
+
+
+
+### Claim and deploy
+
+Here we will use the `claim` object previously from the bridging section, and the corresponding `wallet`, to create the payment method. The payment method is then used to claim fee juice and pay for account contract deployment. Note the function used to bridge fee juice (private/public) should correspond to how the fee juice is claimed.
+
+```javascript title="claim_and_deploy" showLineNumbers
+const wallet = await account.getWallet();
+const paymentMethod = new FeeJuicePaymentMethodWithClaim(wallet, claim);
+const sentTx = account.deploy({ fee: { paymentMethod } });
+const txHash = await sentTx.getTxHash();
+```
+> Source code: yarn-project/bot/src/factory.ts#L121-L126
+
+
+#### Claim and Pay
+
+Calling a function, in this case checking the balance of the fee juice contract:
+
+```javascript title="claim_and_pay" showLineNumbers
+const paymentMethod = new FeeJuicePaymentMethodWithClaim(bobWallet, claim);
+const receipt = await feeJuiceContract
+ .withWallet(bobWallet)
+ .methods.check_balance(0n)
+ .send({ fee: { gasSettings, paymentMethod } })
+ .wait();
+```
+> Source code: yarn-project/end-to-end/src/e2e_fees/fee_juice_payments.test.ts#L67-L74
+
+
+### Fee Paying Contract
+
+Similarly with a fee paying contract, the fee payment method is created and used as follows:
+
+```javascript title="fpc" showLineNumbers
+const tx = await bananaCoin.methods
+ .transfer_in_public(aliceAddress, bobAddress, bananasToSendToBob, 0)
+ .send({
+ fee: {
+ gasSettings,
+ paymentMethod: new PublicFeePaymentMethod(bananaFPC.address, aliceWallet),
+ },
+ })
+ .wait();
+```
+> Source code: yarn-project/end-to-end/src/e2e_fees/public_payments.test.ts#L59-L69
+
+
+In this example, thanks to the FPC's `accepted_asset` being banana tokens, Alice only needs to hold this token and not fee juice. The function being called happens to also be a transfer of banana tokens to Bob.
+
+More on FPCs [here](https://github.com/AztecProtocol/aztec-packages/tree/v0.82.2/noir-projects/noir-contracts/contracts/fpc_contract/src/main.nr)
diff --git a/docs/versioned_docs/version-v0.82.2-alpha-testnet.5/developers/guides/js_apps/send_transaction.md b/docs/versioned_docs/version-v0.82.2-alpha-testnet.5/developers/guides/js_apps/send_transaction.md
new file mode 100644
index 000000000000..8fd19e868c75
--- /dev/null
+++ b/docs/versioned_docs/version-v0.82.2-alpha-testnet.5/developers/guides/js_apps/send_transaction.md
@@ -0,0 +1,44 @@
+---
+title: How to Send a Transaction
+sidebar_position: 4
+---
+
+This guide explains how to send a transaction using Aztec.js.
+
+## Prerequisites
+
+You should have a wallet to act as the transaction sender, a contract that has been deployed, and fee juice to pay for transactions.
+
+You can learn how to create wallets from [this guide](./create_account.md).
+
+You can learn how to deploy a contract [here](./deploy_contract.md).
+
+You can learn how to use fee juice [here](./pay_fees.md).
+
+## Relevant imports
+
+You will need to import this library:
+
+```typescript title="import_contract" showLineNumbers
+import { Contract } from '@aztec/aztec.js';
+```
+> Source code: yarn-project/end-to-end/src/composed/docs_examples.test.ts#L7-L9
+
+
+## Define contract
+
+Get a previously deployed contract like this:
+
+```typescript title="get_contract" showLineNumbers
+const contract = await Contract.at(deployedContract.address, TokenContractArtifact, wallet);
+```
+> Source code: yarn-project/end-to-end/src/composed/docs_examples.test.ts#L45-L47
+
+
+## Call method
+
+```typescript title="send_transaction" showLineNumbers
+const _tx = await contract.methods.mint_to_public(newWallet.getAddress(), 1).send().wait();
+```
+> Source code: yarn-project/end-to-end/src/composed/docs_examples.test.ts#L50-L52
+
diff --git a/docs/versioned_docs/version-v0.82.2-alpha-testnet.5/developers/guides/js_apps/test.md b/docs/versioned_docs/version-v0.82.2-alpha-testnet.5/developers/guides/js_apps/test.md
new file mode 100644
index 000000000000..06405c6f619f
--- /dev/null
+++ b/docs/versioned_docs/version-v0.82.2-alpha-testnet.5/developers/guides/js_apps/test.md
@@ -0,0 +1,258 @@
+---
+title: Testing Aztec.nr contracts with TypeScript
+tags: [contracts, tests]
+sidebar_position: 6
+---
+
+In this guide we will cover how to interact with your Aztec.nr smart contracts in a testing environment to write automated tests for your apps.
+
+## Prerequisites
+
+- A compiled contract with TS interface (read [how to compile](../smart_contracts/how_to_compile_contract.md))
+- Your sandbox running (read [getting started](../../getting_started.md))
+
+## Create TS file and install libraries
+
+Pick where you'd like your tests to live and create a Typescript project.
+
+You will need to install Aztec.js:
+
+```bash
+yarn add @aztec/aztecjs
+```
+
+You can use `aztec.js` to write assertions about transaction statuses, about chain state both public and private, and about logs.
+
+## Import relevant libraries
+
+Import `aztecjs`. This is an example of some functions and types you might need in your test:
+
+```typescript title="imports" showLineNumbers
+import { getDeployedTestAccountsWallets } from '@aztec/accounts/testing';
+import { type AccountWallet, Fr, type PXE, TxStatus, createPXEClient, waitForPXE } from '@aztec/aztec.js';
+import { CheatCodes } from '@aztec/aztec.js/testing';
+```
+> Source code: yarn-project/end-to-end/src/guides/dapp_testing.test.ts#L1-L5
+
+
+You should also import the [Typescript class you generated](../smart_contracts/how_to_compile_contract.md#typescript-interfaces):
+
+```typescript title="import_contract" showLineNumbers
+import { TestContract } from '@aztec/noir-contracts.js/Test';
+```
+> Source code: yarn-project/end-to-end/src/guides/dapp_testing.test.ts#L6-L8
+
+
+## Create a PXE client
+
+Currently, testing Aztec.nr smart contracts means testing them against the PXE that runs in the local sandbox. Create a PXE client:
+
+```typescript title="create_pxe_client" showLineNumbers
+const pxe = createPXEClient(PXE_URL);
+await waitForPXE(pxe);
+```
+> Source code: yarn-project/end-to-end/src/guides/dapp_testing.test.ts#L19-L22
+
+
+and use the accounts that are initialized with it:
+
+```typescript title="use-existing-wallets" showLineNumbers
+pxe = createPXEClient(PXE_URL);
+[owner, recipient] = await getDeployedTestAccountsWallets(pxe);
+token = await TokenContract.deploy(owner, owner.getCompleteAddress(), 'TokenName', 'TokenSymbol', 18)
+ .send()
+ .deployed();
+```
+> Source code: yarn-project/end-to-end/src/guides/dapp_testing.test.ts#L32-L38
+
+
+Alternatively, you can [create a new account.](./create_account.md).
+
+## Write tests
+
+### Calling and sending transactions
+
+You can send transactions within your tests with Aztec.js. Read how to do that in these guides:
+
+- [Call a view (unconstrained) function](./call_view_function.md)
+- [Send a transaction](./send_transaction.md)
+
+### Using debug options
+
+You can use the `debug` option in the `wait` method to get more information about the effects of the transaction. This includes information about new note hashes added to the note hash tree, new nullifiers, public data writes, new L2 to L1 messages, new contract information, and newly visible notes.
+
+This debug information will be populated in the transaction receipt. You can log it to the console or use it to make assertions about the transaction.
+
+```typescript title="debug" showLineNumbers
+const tx = await asset.methods.transfer(accounts[1].address, totalBalance).send().wait();
+const txEffects = await node.getTxEffect(tx.txHash);
+```
+> Source code: yarn-project/end-to-end/src/e2e_token_contract/private_transfer_recursion.test.ts#L38-L41
+
+
+You can also log directly from Aztec contracts. Read [this guide](../../reference/debugging/index.md#logging-in-aztecnr) for some more information.
+
+### Examples
+
+#### A private call fails
+
+We can check that a call to a private function would fail by simulating it locally and expecting a rejection. Remember that all private function calls are only executed locally in order to preserve privacy. As an example, we can try transferring more tokens than we have, which will fail an assertion with the `Balance too low` error message.
+
+```typescript title="local-tx-fails" showLineNumbers
+const call = token.methods.transfer(recipient.getAddress(), 200n);
+await expect(call.prove()).rejects.toThrow(/Balance too low/);
+```
+> Source code: yarn-project/end-to-end/src/guides/dapp_testing.test.ts#L123-L126
+
+
+Under the hood, the `send()` method executes a simulation, so we can just call the usual `send().wait()` to catch the same failure.
+
+```typescript title="local-tx-fails-send" showLineNumbers
+const call = token.methods.transfer(recipient.getAddress(), 200n);
+await expect(call.send().wait()).rejects.toThrow(/Balance too low/);
+```
+> Source code: yarn-project/end-to-end/src/guides/dapp_testing.test.ts#L130-L133
+
+
+#### A transaction is dropped
+
+We can have private transactions that work fine locally, but are dropped by the sequencer when tried to be included due to a double-spend. In this example, we simulate two different transfers that would succeed individually, but not when both are tried to be mined. Here we need to `send()` the transaction and `wait()` for it to be mined.
+
+```typescript title="tx-dropped" showLineNumbers
+const call1 = token.methods.transfer(recipient.getAddress(), 80n);
+const call2 = token.methods.transfer(recipient.getAddress(), 50n);
+
+const provenCall1 = await call1.prove();
+const provenCall2 = await call2.prove();
+
+await provenCall1.send().wait();
+await expect(provenCall2.send().wait()).rejects.toThrow(/dropped/);
+```
+> Source code: yarn-project/end-to-end/src/guides/dapp_testing.test.ts#L137-L146
+
+
+#### A public call fails locally
+
+Public function calls can be caught failing locally similar to how we catch private function calls. For this example, we use a [`TokenContract` (GitHub link)](https://github.com/AztecProtocol/aztec-packages/blob/master/noir-projects/noir-contracts/contracts/token_contract/src/main.nr) instead of a private one.
+
+```typescript title="local-pub-fails" showLineNumbers
+const call = token.methods.transfer_in_public(owner.getAddress(), recipient.getAddress(), 1000n, 0);
+await expect(call.prove()).rejects.toThrow(U128_UNDERFLOW_ERROR);
+```
+> Source code: yarn-project/end-to-end/src/guides/dapp_testing.test.ts#L150-L153
+
+
+#### A public call fails on the sequencer
+
+We can ignore a local simulation error for a public function via the `skipPublicSimulation`. This will submit a failing call to the sequencer, who will include the transaction, but without any side effects from our application logic. Requesting the receipt for the transaction will also show it has a reverted status.
+
+```typescript title="pub-reverted" showLineNumbers
+const call = token.methods.transfer_in_public(owner.getAddress(), recipient.getAddress(), 1000n, 0);
+const receipt = await call.send({ skipPublicSimulation: true }).wait({ dontThrowOnRevert: true });
+expect(receipt.status).toEqual(TxStatus.APP_LOGIC_REVERTED);
+const ownerPublicBalanceSlot = await cheats.aztec.computeSlotInMap(
+ TokenContract.storage.public_balances.slot,
+ owner.getAddress(),
+);
+const balance = await pxe.getPublicStorageAt(token.address, ownerPublicBalanceSlot);
+expect(balance.value).toEqual(100n);
+```
+> Source code: yarn-project/end-to-end/src/guides/dapp_testing.test.ts#L157-L167
+
+
+```
+WARN Error processing tx 06dc87c4d64462916ea58426ffcfaf20017880b353c9ec3e0f0ee5fab3ea923f: Assertion failed: Balance too low.
+```
+
+### Querying state
+
+We can check private or public state directly rather than going through view-only methods, as we did in the initial example by calling `token.methods.balance().simulate()`.
+
+To query storage directly, you'll need to know the slot you want to access. This can be checked in the [contract's `Storage` definition](../../reference/smart_contract_reference/storage/index.md) directly for most data types. However, when it comes to mapping types, as in most EVM languages, we'll need to calculate the slot for a given key. To do this, we'll use the [`CheatCodes`](../../reference/environment_reference/cheat_codes.md) utility class:
+
+```typescript title="calc-slot" showLineNumbers
+cheats = await CheatCodes.create(ETHEREUM_HOSTS.split(','), pxe);
+// The balances mapping is indexed by user address
+ownerSlot = await cheats.aztec.computeSlotInMap(TokenContract.storage.balances.slot, ownerAddress);
+```
+> Source code: yarn-project/end-to-end/src/guides/dapp_testing.test.ts#L74-L78
+
+
+#### Querying private state
+
+Private state in the Aztec is represented via sets of [private notes](../../../aztec/concepts/storage/state_model.md#private-state). We can query the Private Execution Environment (PXE) for all notes encrypted for a given user in a contract slot. For example, this gets all notes encrypted for the `owner` user that are stored on the token contract address and on the slot that was calculated earlier. To calculate the actual balance, it extracts the `value` of each note, which is the third element, and sums them up.
+
+```typescript title="private-storage" showLineNumbers
+await token.methods.sync_notes().simulate();
+const notes = await pxe.getNotes({
+ recipient: owner.getAddress(),
+ contractAddress: token.address,
+ storageSlot: ownerSlot,
+ scopes: [owner.getAddress()],
+});
+// TODO(#12694): Do not rely on the ordering of members in a struct / check notes manually
+const values = notes.map(note => note.note.items[2]);
+const balance = values.reduce((sum, current) => sum + current.toBigInt(), 0n);
+expect(balance).toEqual(100n);
+```
+> Source code: yarn-project/end-to-end/src/guides/dapp_testing.test.ts#L82-L94
+
+
+#### Querying public state
+
+Public state behaves as a key-value store, much like in the EVM. We can directly query the target slot and get the result back as a buffer. Note that we use the [`TokenContract` (GitHub link)](https://github.com/AztecProtocol/aztec-packages/blob/master/noir-projects/noir-contracts/contracts/token_contract/src/main.nr) in this example, which defines a mapping of public balances on slot 6.
+
+```typescript title="public-storage" showLineNumbers
+await token.methods.mint_to_public(owner.getAddress(), 100n).send().wait();
+const ownerPublicBalanceSlot = await cheats.aztec.computeSlotInMap(
+ TokenContract.storage.public_balances.slot,
+ owner.getAddress(),
+);
+const balance = await pxe.getPublicStorageAt(token.address, ownerPublicBalanceSlot);
+expect(balance.value).toEqual(100n);
+```
+> Source code: yarn-project/end-to-end/src/guides/dapp_testing.test.ts#L98-L106
+
+
+### Logs
+
+You can check the logs of events emitted by contracts. Contracts in Aztec can emit both encrypted and unencrypted events.
+
+#### Querying public logs
+
+We can query the PXE for the public logs emitted in the block where our transaction is mined.
+
+```typescript title="public-logs" showLineNumbers
+const value = Fr.fromHexString('ef'); // Only 1 bytes will make its way in there :( so no larger stuff
+const tx = await testContract.methods.emit_public(value).send().wait();
+const filter = {
+ fromBlock: tx.blockNumber!,
+ limit: 1, // 1 log expected
+};
+const logs = (await pxe.getPublicLogs(filter)).logs;
+expect(logs[0].log.log[0]).toEqual(value);
+```
+> Source code: yarn-project/end-to-end/src/guides/dapp_testing.test.ts#L110-L119
+
+
+## Cheats
+
+The [`CheatCodes`](../../reference/environment_reference/cheat_codes.md) class, which we used for [calculating the storage slot above](#querying-state), also includes a set of cheat methods for modifying the chain state that can be handy for testing.
+
+### Set next block timestamp
+
+Since the rollup time is dependent on what "slot" the block is included in, time can be progressed by progressing slots.
+The duration of a slot is available by calling `getSlotDuration()` on the Rollup (code in Rollup.sol).
+
+You can then use the `warp` function on the EthCheatCodes to progress the underlying chain.
+
+
+
+## Further reading
+
+- [How to call a view transactions in Aztec.js](./call_view_function.md)
+- [How to send a transactions in Aztec.js](./send_transaction.md)
+- [How to deploy a contract in Aztec.js](./deploy_contract.md)
+- [How to create an account in Aztec.js](./create_account.md)
+- [Cheat codes](../../reference/environment_reference/cheat_codes.md)
+- [How to compile a contract](../smart_contracts/how_to_compile_contract.md).
diff --git a/docs/versioned_docs/version-v0.82.2-alpha-testnet.5/developers/guides/local_env/_category_.json b/docs/versioned_docs/version-v0.82.2-alpha-testnet.5/developers/guides/local_env/_category_.json
new file mode 100644
index 000000000000..5c8df7e68a18
--- /dev/null
+++ b/docs/versioned_docs/version-v0.82.2-alpha-testnet.5/developers/guides/local_env/_category_.json
@@ -0,0 +1,6 @@
+{
+ "position": 2,
+ "collapsible": true,
+ "collapsed": true,
+ "label": "Development Environment"
+}
diff --git a/docs/versioned_docs/version-v0.82.2-alpha-testnet.5/developers/guides/local_env/cloning_a_box.md b/docs/versioned_docs/version-v0.82.2-alpha-testnet.5/developers/guides/local_env/cloning_a_box.md
new file mode 100644
index 000000000000..5d0d950e61ec
--- /dev/null
+++ b/docs/versioned_docs/version-v0.82.2-alpha-testnet.5/developers/guides/local_env/cloning_a_box.md
@@ -0,0 +1,10 @@
+---
+title: Cloning a box
+sidebar_position: 4
+tags: [accounts]
+---
+You can use the `npx aztec-app` command to clone a ready-to-go "aztec box" with a sample contract or frontend. Assuming you have [node](https://nodejs.org/en/) installed, run:
+
+```bash
+npx aztec-app
+```
\ No newline at end of file
diff --git a/docs/versioned_docs/version-v0.82.2-alpha-testnet.5/developers/guides/local_env/creating_schnorr_accounts.md b/docs/versioned_docs/version-v0.82.2-alpha-testnet.5/developers/guides/local_env/creating_schnorr_accounts.md
new file mode 100644
index 000000000000..9d95d3d15118
--- /dev/null
+++ b/docs/versioned_docs/version-v0.82.2-alpha-testnet.5/developers/guides/local_env/creating_schnorr_accounts.md
@@ -0,0 +1,138 @@
+---
+title: Creating Schnorr Accounts
+sidebar_position: 2
+draft: true
+tags: [accounts]
+---
+
+
+
+## Introduction
+
+This section shows how to create schnorr account wallets on the Aztec Sandbox.
+
+An in-depth explainer about accounts on aztec can be found [here](../../../aztec/concepts/accounts/index.md). But creating an account on the Sandbox does 2 things:
+
+1. Deploys an account contract -- representing you -- allowing you to perform actions on the network (deploy contracts, call functions etc).
+2. Adds your encryption keys to the Private eXecution Environment (PXE) allowing it to decrypt and manage your private state.
+
+## Pre-requisites
+
+Have a running Sandbox and a repository that interacts with it as explained [in the quickstart](../../getting_started.md).
+
+Let's assume you have a file `src/index.ts` from the example used in the Sandbox page.
+
+## Create accounts on the sandbox
+
+1. Import relevant modules:
+
+```typescript title="imports" showLineNumbers
+import { getSchnorrAccount } from '@aztec/accounts/schnorr';
+import { getDeployedTestAccountsWallets } from '@aztec/accounts/testing';
+import {
+ getDeployedBananaCoinAddress,
+ getDeployedBananaFPCAddress,
+ getDeployedSponsoredFPCAddress,
+} from '@aztec/aztec';
+import {
+ Fr,
+ GrumpkinScalar,
+ type PXE,
+ PrivateFeePaymentMethod,
+ createLogger,
+ createPXEClient,
+ getFeeJuiceBalance,
+ waitForPXE,
+} from '@aztec/aztec.js';
+import { SponsoredFeePaymentMethod } from '@aztec/aztec.js/fee/testing';
+import { timesParallel } from '@aztec/foundation/collection';
+import { TokenContract } from '@aztec/noir-contracts.js/Token';
+
+import { format } from 'util';
+```
+> Source code: yarn-project/end-to-end/src/composed/e2e_sandbox_example.test.ts#L54-L78
+
+
+2. Code to create an account. You must run this inside of a function:
+
+```typescript title="create_accounts" showLineNumbers
+////////////// CREATE SOME ACCOUNTS WITH SCHNORR SIGNERS //////////////
+
+// Use one of the pre-funded accounts to pay for the deployments.
+const [fundedWallet] = await getDeployedTestAccountsWallets(pxe);
+
+// Creates new accounts using an account contract that verifies schnorr signatures
+// Returns once the deployment transactions have settled
+const createSchnorrAccounts = async (numAccounts: number, pxe: PXE) => {
+ const accountManagers = await timesParallel(numAccounts, () =>
+ getSchnorrAccount(
+ pxe,
+ Fr.random(), // secret key
+ GrumpkinScalar.random(), // signing private key
+ ),
+ );
+
+ return await Promise.all(
+ accountManagers.map(async x => {
+ await x.deploy({ deployWallet: fundedWallet }).wait();
+ return x;
+ }),
+ );
+};
+
+// Create 2 accounts and wallets to go with each
+logger.info(`Creating accounts using schnorr signers...`);
+const accounts = await createSchnorrAccounts(2, pxe);
+const [aliceWallet, bobWallet] = await Promise.all(accounts.map(a => a.getWallet()));
+const [alice, bob] = (await Promise.all(accounts.map(a => a.getCompleteAddress()))).map(a => a.address);
+
+////////////// VERIFY THE ACCOUNTS WERE CREATED SUCCESSFULLY //////////////
+const registeredAccounts = (await pxe.getRegisteredAccounts()).map(x => x.address);
+for (const [account, name] of [
+ [alice, 'Alice'],
+ [bob, 'Bob'],
+] as const) {
+ if (registeredAccounts.find(acc => acc.equals(account))) {
+ logger.info(`Created ${name}'s account at ${account.toString()}`);
+ continue;
+ }
+ logger.info(`Failed to create account for ${name}!`);
+}
+```
+> Source code: yarn-project/end-to-end/src/composed/e2e_sandbox_example.test.ts#L197-L240
+
+
+3. Running `yarn start` should now output:
+
+```
+ token Aztec Sandbox Info {
+ version: 1,
+ chainId: 31337,
+ rollupAddress: EthAddress {
+ buffer:
+ },
+ client: 'pxe@0.1.0',
+ compatibleNargoVersion: '0.11.1-aztec.0'
+ }
+ token Creating accounts using schnorr signers... +3ms
+ token Created Alice's account at 0x1509b252...0027 +10s
+ token Created Bob's account at 0x031862e8...e7a3 +0ms
+```
+
+That might seem like a lot to digest but it can be broken down into the following steps:
+
+1. We create 2 `Account` objects in Typescript. This object heavily abstracts away the mechanics of configuring and deploying an account contract and setting up a 'wallet' for signing transactions. If you aren't interested in building new types of account contracts or wallets then you don't need to be too concerned with it. In this example we have constructed account contracts and corresponding wallets that sign/verify transactions using schnorr signatures.
+2. We wait for the deployment of the 2 account contracts to complete.
+3. We retrieve the expected account addresses from the `Account` objects and ensure that they are present in the set of account addresses registered on the Sandbox.
+
+Note, we use the `getRegisteredAccounts` API to verify that the addresses computed as part of the
+account contract deployment have been successfully added to the Sandbox.
+
+If you were looking at your terminal that is running the Sandbox you should have seen a lot of activity.
+This is because the Sandbox will have simulated the deployment of both contracts, executed the private kernel circuit for each account deployment and later on submitted the 2 transactions to the pool.
+The sequencer will have picked them up and inserted them into an L2 block and executed the recursive rollup circuits before publishing the L2 block on L1 (in our case Anvil).
+Once this has completed, the L2 block is retrieved and pulled down to the PXE so that any new account state can be decrypted.
+
+## Next Steps
+
+Check out our section on [Writing your own Account Contract](../../tutorials/codealong/contract_tutorials/write_accounts_contract.md) leveraging our account abstraction.
diff --git a/docs/versioned_docs/version-v0.82.2-alpha-testnet.5/developers/guides/local_env/installing_noir_lsp.md b/docs/versioned_docs/version-v0.82.2-alpha-testnet.5/developers/guides/local_env/installing_noir_lsp.md
new file mode 100644
index 000000000000..52bf1b28d18b
--- /dev/null
+++ b/docs/versioned_docs/version-v0.82.2-alpha-testnet.5/developers/guides/local_env/installing_noir_lsp.md
@@ -0,0 +1,17 @@
+---
+title: Installing the Noir LSP
+sidebar_position: 1
+tags: [sandbox]
+---
+
+Install the [Noir Language Support extension](https://marketplace.visualstudio.com/items?itemName=noir-lang.vscode-noir) to get syntax highlighting, syntax error detection and go-to definitions for your Aztec contracts.
+
+Once the extension is installed, check your nargo binary by hovering over Nargo in the status bar on the bottom right of the application window. Click to choose the path to aztec-nargo (or regular nargo, if you have that installed).
+
+You can print the path of your `aztec-nargo` executable by running:
+
+```bash
+which aztec-nargo
+```
+
+To specify a custom nargo executable, go to the VSCode settings and search for "noir", or click extension settings on the `noir-lang` LSP plugin. Update the `Noir: Nargo Path` field to point to your desired `aztec-nargo` executable.
\ No newline at end of file
diff --git a/docs/versioned_docs/version-v0.82.2-alpha-testnet.5/developers/guides/local_env/run_more_than_one_pxe_sandbox.md b/docs/versioned_docs/version-v0.82.2-alpha-testnet.5/developers/guides/local_env/run_more_than_one_pxe_sandbox.md
new file mode 100644
index 000000000000..be2d3bd0f419
--- /dev/null
+++ b/docs/versioned_docs/version-v0.82.2-alpha-testnet.5/developers/guides/local_env/run_more_than_one_pxe_sandbox.md
@@ -0,0 +1,39 @@
+---
+title: Running Multiple PXEs in the Sandbox
+sidebar_position: 3
+tags: [PXE]
+---
+
+When you run the sandbox, the Aztec node and PXE have their own http server. This makes it possible to run two PXEs on your local machine, which can be useful for testing that notes are accurately stored and remaining private in their respective PXEs.
+
+We are working on a better solution for this so expect an update soon, but currently you can follow this guide.
+
+## Run the sandbox in one terminal
+
+Rather than use the usual command, run:
+
+```bash
+NO_PXE=true aztec start --sandbox
+```
+
+This removes any other arguments, allowing you to ensure an isolated environment for the sandbox so it doesn't interfere with another PXE. By default, the sandbox will run on port `8080`.
+
+## Run PXE mode in another terminal
+
+In another terminal, run:
+
+```bash
+aztec start --port 8081 --pxe --pxe.nodeUrl=http://localhost:8080/
+```
+
+This command uses the default ports, so they might need to be changed depending on your configuration. It will run the PXE on port `8081`.
+
+You should see something like this:
+
+```bash
+[14:01:53.181] INFO: pxe:data:lmdb Starting data store with maxReaders 16
+[14:01:53.677] INFO: pxe:service Started PXE connected to chain 31337 version 1
+[14:01:53.681] INFO: cli Aztec Server listening on port 8081 {"l1ChainId":31337,"l2ChainVersion":1,"l2ProtocolContractsTreeRoot":"0x093cc9324e5a7b44883f515ac490e7294ef8cb1e6d2d8c503255b1b3a9409262","l2CircuitsVkTreeRoot":"0x007c3b32ae1b8b3ed235f158e554d92710b5f126a8b2ed38a0874f6294299b95"}
+```
+
+You can learn more about custom commands in the [sandbox reference](../../reference/environment_reference/sandbox-reference.md).
diff --git a/docs/versioned_docs/version-v0.82.2-alpha-testnet.5/developers/guides/local_env/sandbox_proving.md b/docs/versioned_docs/version-v0.82.2-alpha-testnet.5/developers/guides/local_env/sandbox_proving.md
new file mode 100644
index 000000000000..0084a5308b11
--- /dev/null
+++ b/docs/versioned_docs/version-v0.82.2-alpha-testnet.5/developers/guides/local_env/sandbox_proving.md
@@ -0,0 +1,51 @@
+---
+title: Sandbox PXE Proving
+tags: [sandbox, PXE]
+---
+
+The Sandbox does not have client-side proving in the PXE enabled by default. This reduces testing times and increases development speed by allowing for rapid iteration.
+
+You may want to enable client-side proving in the Sandbox to better understand how long it takes to execute Aztec transactions. There are 2 ways of doing this:
+
+1. Run the sandbox in proving mode (every transaction wil be proved) or
+2. Use `aztec-wallet` cli to prove a one-off transaction
+
+:::note
+Proving is much slower and should only be used sparingly to analyze real proving times of executing private functions of a contract.
+:::
+
+## Sandbox in Proving Mode
+
+Here every transaction, contract deployment will be proved. If you want to just prove a single transaction, follow [proving with aztec-wallet cli](#proving-with-aztec-wallet).
+
+### Usage
+
+To enable client-side proving:
+
+```bash
+PXE_PROVER_ENABLED=1 aztec start --sandbox
+```
+
+The sandbox will take much longer to start. The first time it starts, it will need to download a large crs file, which can take several minutes even on a fast internet connection. This is a one-time operation, you will not need to download it again until you update to a new Aztec version.
+
+The sandbox will also deploy 3 Schnorr account contracts on startup. The sandbox will need to generate transaction proofs for deployment, which will take additional time.
+
+Once everything has been set up, you will see that the PXE is listening on `localhost:8080` as you would see with the sandbox running in the default mode. At this point you can use the sandbox as you would without client-side proving enabled.
+
+## Proving with `aztec-wallet`
+
+You can enable proving on a per-transaction basis using the `aztec-wallet` CLI by setting the `PXE_PROVER_ENABLED` environment variable to `1`. This will use your local `bb` binary to prove the transaction.
+
+```bash
+PXE_PROVER_ENABLED=1 aztec-wallet create-account -a test
+```
+
+Check the [Quickstart](../../getting_started.md) for a refresher on how to send transactions using `aztec-wallet` or check the [reference here](../../reference/environment_reference/cli_wallet_reference.md)
+
+Note that you do not need to restart the sandbox in order to start sending proven transactions. You can optionally set this for one-off transactions.
+
+If this is the first time you are sending transactions with proving enabled, it will take a while to download a CRS file (which is several MBs) that is required for proving.
+
+:::note
+You can also profile your transactions to get gate count, if you don't want to prove your transactions but check how many constraints it is. Follow the [guide here](../../guides/smart_contracts/profiling_transactions.md)
+:::
diff --git a/docs/versioned_docs/version-v0.82.2-alpha-testnet.5/developers/guides/local_env/versions-updating.md b/docs/versioned_docs/version-v0.82.2-alpha-testnet.5/developers/guides/local_env/versions-updating.md
new file mode 100644
index 000000000000..ccb5ed5e2cde
--- /dev/null
+++ b/docs/versioned_docs/version-v0.82.2-alpha-testnet.5/developers/guides/local_env/versions-updating.md
@@ -0,0 +1,173 @@
+---
+title: Updating the Sandbox
+sidebar_position: 0
+tags: [sandbox]
+---
+
+- Current version: `v0.82.2`
+- Update with `aztec-up`
+
+On this page you will find
+
+- [Understanding versions](#versions)
+- [How to automatically update Aztec sandbox and aztec-nargo](#updating)
+- [How to update Aztec.nr packages](#updating-aztecnr-packages)
+- [How to update Aztec.js packages](#updating-aztecjs-packages)
+
+## Versions
+
+Aztec tools (sandbox, nargo), dependencies (Aztec.nr), and sample contracts are constantly being improved.
+When developing and referring to example .nr files/snippets, it is helpful to verify the versions of different components (below), and if required keep them in lock-step by [updating](#updating).
+
+### Checking tool versions
+
+:::note
+The `aztec-nargo` versions follow `nargo` versions, which is different to the Aztec tool versions.
+:::
+
+### Dependency versions
+
+Dependency versions in a contract's `Nargo.toml` file correspond to the `aztec-packages` repository tag `aztec-packages` (filter tags by `aztec`...)
+
+If you get an error like: `Cannot read file ~/nargo/github.com/AztecProtocol/aztec-packages/...`
+Check the `git=` github url, tag, and directory.
+
+### Example contract versions
+
+Example contracts serve as a helpful reference between versions of the Aztec.nr framework since they are strictly maintained with each release.
+
+Code referenced in the documentation is sourced from contracts within [this directory (GitHub link)](https://github.com/AztecProtocol/aztec-packages/tree/v0.82.2/noir-projects/noir-contracts/contracts).
+
+As in the previous section, the location of the noir contracts moved at version `0.24.0`, from `yarn-project/noir-contracts` before, to `noir-projects/noir-contracts`.
+
+:::tip
+Notice the difference between the sample Counter contract from `0.23.0` to `0.24.0` shows the `note_type_id` was added.
+
+```shell
+diff ~/nargo/github.com/AztecProtocol/v0.23.0/yarn-project/noir-contracts/contracts/counter_contract/src/main.nr ~/nargo/github.com/AztecProtocol/v0.24.0/noir-projects/noir-contracts/contracts/counter_contract/src/main.nr
+```
+
+```
+57a58
+> note_type_id: Field,
+```
+
+:::
+
+### Language server version (aztec-nargo)
+
+The [Noir LSP](../local_env/installing_noir_lsp.md) uses your local version of `aztec-nargo`, and thus also `aztec-nargo compile`.
+The path of the former (once installed) can be seen by hovering over "Nargo" in the bottom status bar of VS Code, and the latter via the `which aztec-nargo` command.
+
+:::caution
+For Aztec contract files, this should be `aztec-nargo` and for noir-only files this should be `nargo`. Mismatching tools and file types will generate misleading syntax and compiler errors.
+:::
+
+This can present confusion when opening older contracts (and dependencies) written in older version of noir, such as:
+
+- Logs filled with errors from the dependencies
+- Or the LSP fails (re-runs automatically then stops)
+ The second point requires a restart of the extension, which you can trigger with the command palette (Ctrl + Shift + P) and typing "Reload Window".
+
+## Updating
+
+### Steps to keep up to date
+
+1. Update the Aztec sandbox to the latest version (includes `aztec-nargo`, pxe, etc):
+
+```shell
+aztec-up
+```
+
+To set `VERSION` for a particular git tag, eg for [v**0.77.0**](https://github.com/AztecProtocol/aztec-packages/tree/v0.77.0)
+
+```shell
+VERSION=0.35.0 aztec-up
+```
+
+2. Update Aztec.nr and individual @aztec dependencies:
+
+Inside your project run:
+
+```shell
+cd your/aztec/project
+aztec update . --contract src/contract1 --contract src/contract2
+```
+
+The sandbox must be running for the update command to work. Make sure it is [installed and running](../../reference/environment_reference/sandbox-reference.md).
+
+Follow [updating Aztec.nr packages](#updating-aztecnr-packages) and [updating JavaScript packages](#updating-aztecjs-packages) guides.
+
+3. Refer to [Migration Notes](../../../migration_notes.md) on any breaking changes that might affect your dapp
+
+---
+
+There are four components whose versions need to be kept compatible:
+
+1. Aztec Sandbox
+2. aztec-nargo
+3. `Aztec.nr`, the Noir framework for writing Aztec contracts
+
+First three are packaged together in docker and are kept compatible by running `aztec-up`.
+But you need to update your Aztec.nr version manually or using `aztec update`.
+
+## Updating Aztec.nr packages
+
+### Automatic update
+
+You can update your Aztec.nr packages to the appropriate version with the `aztec update` command. Run this command from the root of your project and pass the paths to the folders containing the Nargo.toml files for your projects like so:
+
+```shell
+aztec update . --contract src/contract1 --contract src/contract2
+```
+
+### Manual update
+
+To update the aztec.nr packages manually, update the tags of the `aztec.nr` dependencies in the `Nargo.toml` file.
+
+```diff
+[dependencies]
+-aztec = { git="https://github.com/AztecProtocol/aztec-packages", tag="v0.7.5", directory="noir-projects/aztec-nr/aztec" }
++aztec = { git="https://github.com/AztecProtocol/aztec-packages", tag="v0.82.2", directory="noir-projects/aztec-nr/aztec" }
+-value_note = { git="https://github.com/AztecProtocol/aztec-packages", tag="v0.7.5", directory="noir-projects/aztec-nr/value-note" }
++value_note = { git="https://github.com/AztecProtocol/aztec-packages", tag="v0.82.2", directory="noir-projects/aztec-nr/value-note" }
+```
+
+Go to the contract directory and try compiling it with `aztec-nargo compile` to verify that the update was successful:
+
+```shell
+cd /your/contract/directory
+aztec-nargo compile
+```
+
+If the dependencies fail to resolve ensure that the tag matches a tag in the [aztec-packages repository (GitHub link)](https://github.com/AztecProtocol/aztec-packages/tags).
+
+## Updating Aztec.js packages
+
+To update Aztec.js packages, go to your `package.json` and replace the versions in the dependencies.
+
+```diff
+[dependencies]
+-"@aztec/accounts": "0.7.5",
++"@aztec/accounts": "0.82.2",
+-"@aztec/noir-contracts.js": "0.35.1",
++"@aztec/accounts": "0.82.2",
+```
+
+## Updating `aztec-nargo`
+
+As mentioned in the tl;dr, `aztec-nargo` is updated as part of updating the whole sandbox via:
+
+```bash
+aztec-up
+```
+
+The version of aztec-nargo that comes with a particular version of the Aztec sandbox can be seen in the monorepo. Eg tag: v0.35.0 contains aztec-nargo [v0.27.0 (GitHub link)](https://github.com/AztecProtocol/aztec-packages/blob/v0.35.0/noir/noir-repo/Cargo.toml#L44).
+
+Set VERSION to specify the desired Aztec sandbox version, eg monorepo tag suffix [0.35.0 (GitHub link)](https://github.com/AztecProtocol/aztec-packages/tree/v0.35.0) (to have `aztec-nargo` v0.27.0).
+
+```bash
+VERSION= aztec-up
+```
+
+Note: Being under highly active development it is NOT recommended to specify, `master`, due to the increased effort to align tooling, dependencies, and example code syntax.
diff --git a/docs/versioned_docs/version-v0.82.2-alpha-testnet.5/developers/guides/smart_contracts/_category_.json b/docs/versioned_docs/version-v0.82.2-alpha-testnet.5/developers/guides/smart_contracts/_category_.json
new file mode 100644
index 000000000000..d0bf29833011
--- /dev/null
+++ b/docs/versioned_docs/version-v0.82.2-alpha-testnet.5/developers/guides/smart_contracts/_category_.json
@@ -0,0 +1,6 @@
+{
+ "position": 4,
+ "collapsible": true,
+ "collapsed": true,
+ "label": "Aztec.nr"
+}
diff --git a/docs/versioned_docs/version-v0.82.2-alpha-testnet.5/developers/guides/smart_contracts/how_to_compile_contract.md b/docs/versioned_docs/version-v0.82.2-alpha-testnet.5/developers/guides/smart_contracts/how_to_compile_contract.md
new file mode 100644
index 000000000000..f29b645a0beb
--- /dev/null
+++ b/docs/versioned_docs/version-v0.82.2-alpha-testnet.5/developers/guides/smart_contracts/how_to_compile_contract.md
@@ -0,0 +1,482 @@
+---
+title: How to Compile a Contract
+sidebar_position: 3
+tags: [contracts]
+---
+
+Once you have written a contract in Aztec.nr, you will need to compile it into an artifact in order to use it.
+
+In this guide we will cover how to do so, both using the `aztec-nargo` command and programmatically.
+
+We'll also cover how to generate a helper [TypeScript interface](#typescript-interfaces) and an [Aztec.nr interface](#aztecnr-interfaces) for easily interacting with your contract from your typescript app and from other Aztec.nr contracts, respectively.
+
+## Compile using aztec-nargo
+
+To compile a contract using the Aztec's build of nargo.
+
+Run the `aztec-nargo compile` command within your contract project folder (the one that contains the `Nargo.toml` file):
+
+```bash
+aztec-nargo compile
+```
+
+This will output a JSON artifact for each contract in the project to a `target` folder containing the Noir ABI artifacts.
+
+:::note
+This command looks for `Nargo.toml` files by ascending up the parent directories, and will compile the top-most Nargo.toml file it finds.
+Eg: if you are in `/hobbies/cool-game/contracts/easter-egg/`, and both `cool-game` and `easter-egg` contain a Nargo.toml file, then `aztec-nargo compile` will be performed on `cool-game/Nargo.toml` and compile the project(s) specified within it. Eg
+
+```
+[workspace]
+members = [
+ "contracts/easter-egg",
+]
+```
+
+:::
+
+### Typescript Interfaces
+
+You can use the code generator to autogenerate type-safe typescript classes for each of your contracts. These classes define type-safe methods for deploying and interacting with your contract based on their artifact.
+
+```bash
+aztec codegen ./aztec-nargo/output/target/path -o src/artifacts
+```
+
+Below is typescript code generated from the example [Token contract (GitHub link)](https://github.com/AztecProtocol/aztec-packages/blob/master/noir-projects/noir-contracts/contracts/token_contract/src/main.nr) contract:
+
+```ts showLineNumbers
+export type Transfer = {
+ from: AztecAddressLike;
+ to: AztecAddressLike;
+ amount: FieldLike;
+};
+
+/**
+ * Type-safe interface for contract Token;
+ */
+export class TokenContract extends ContractBase {
+ private constructor(instance: ContractInstanceWithAddress, wallet: Wallet) {
+ super(instance, TokenContractArtifact, wallet);
+ }
+
+ /**
+ * Creates a contract instance.
+ * @param address - The deployed contract's address.
+ * @param wallet - The wallet to use when interacting with the contract.
+ * @returns A promise that resolves to a new Contract instance.
+ */
+ public static async at(address: AztecAddress, wallet: Wallet) {
+ return Contract.at(
+ address,
+ TokenContract.artifact,
+ wallet
+ ) as Promise;
+ }
+
+ /**
+ * Creates a tx to deploy a new instance of this contract.
+ */
+ public static deploy(
+ wallet: Wallet,
+ admin: AztecAddressLike,
+ name: string,
+ symbol: string,
+ decimals: bigint | number
+ ) {
+ return new DeployMethod(
+ PublicKeys.default(),
+ wallet,
+ TokenContractArtifact,
+ TokenContract.at,
+ Array.from(arguments).slice(1)
+ );
+ }
+
+ /**
+ * Creates a tx to deploy a new instance of this contract using the specified public keys hash to derive the address.
+ */
+ public static deployWithPublicKeys(
+ publicKeys: PublicKeys,
+ wallet: Wallet,
+ admin: AztecAddressLike,
+ name: string,
+ symbol: string,
+ decimals: bigint | number
+ ) {
+ return new DeployMethod(
+ publicKeys,
+ wallet,
+ TokenContractArtifact,
+ TokenContract.at,
+ Array.from(arguments).slice(2)
+ );
+ }
+
+ /**
+ * Creates a tx to deploy a new instance of this contract using the specified constructor method.
+ */
+ public static deployWithOpts(
+ opts: { publicKeys?: PublicKeys; method?: M; wallet: Wallet },
+ ...args: Parameters
+ ) {
+ return new DeployMethod(
+ opts.publicKeys ?? PublicKeys.default(),
+ opts.wallet,
+ TokenContractArtifact,
+ TokenContract.at,
+ Array.from(arguments).slice(1),
+ opts.method ?? "constructor"
+ );
+ }
+
+ /**
+ * Returns this contract's artifact.
+ */
+ public static get artifact(): ContractArtifact {
+ return TokenContractArtifact;
+ }
+
+ public static get storage(): ContractStorageLayout<
+ | "admin"
+ | "minters"
+ | "balances"
+ | "total_supply"
+ | "public_balances"
+ | "symbol"
+ | "name"
+ | "decimals"
+ > {
+ return {
+ admin: {
+ slot: new Fr(1n),
+ },
+ minters: {
+ slot: new Fr(2n),
+ },
+ balances: {
+ slot: new Fr(3n),
+ },
+ total_supply: {
+ slot: new Fr(4n),
+ },
+ public_balances: {
+ slot: new Fr(5n),
+ },
+ symbol: {
+ slot: new Fr(6n),
+ },
+ name: {
+ slot: new Fr(7n),
+ },
+ decimals: {
+ slot: new Fr(8n),
+ },
+ } as ContractStorageLayout<
+ | "admin"
+ | "minters"
+ | "balances"
+ | "total_supply"
+ | "public_balances"
+ | "symbol"
+ | "name"
+ | "decimals"
+ >;
+ }
+
+ public static get notes(): ContractNotes<"UintNote"> {
+ return {
+ UintNote: {
+ id: new NoteSelector(202136239),
+ },
+ } as ContractNotes<"UintNote">;
+ }
+
+ /** Type-safe wrappers for the public methods exposed by the contract. */
+ public declare methods: {
+ /** balance_of_private(owner: struct) */
+ balance_of_private: ((
+ owner: AztecAddressLike
+ ) => ContractFunctionInteraction) &
+ Pick;
+
+ /** balance_of_public(owner: struct) */
+ balance_of_public: ((
+ owner: AztecAddressLike
+ ) => ContractFunctionInteraction) &
+ Pick;
+
+ /** burn_private(from: struct, amount: field, nonce: field) */
+ burn_private: ((
+ from: AztecAddressLike,
+ amount: FieldLike,
+ nonce: FieldLike
+ ) => ContractFunctionInteraction) &
+ Pick;
+
+ /** burn_public(from: struct, amount: field, nonce: field) */
+ burn_public: ((
+ from: AztecAddressLike,
+ amount: FieldLike,
+ nonce: FieldLike
+ ) => ContractFunctionInteraction) &
+ Pick;
+
+ /** cancel_authwit(inner_hash: field) */
+ cancel_authwit: ((inner_hash: FieldLike) => ContractFunctionInteraction) &
+ Pick;
+
+ /** constructor(admin: struct, name: string, symbol: string, decimals: integer) */
+ constructor: ((
+ admin: AztecAddressLike,
+ name: string,
+ symbol: string,
+ decimals: bigint | number
+ ) => ContractFunctionInteraction) &
+ Pick;
+
+ /** finalize_mint_to_private(amount: field, hiding_point_slot: field) */
+ finalize_mint_to_private: ((
+ amount: FieldLike,
+ hiding_point_slot: FieldLike
+ ) => ContractFunctionInteraction) &
+ Pick;
+
+ /** finalize_transfer_to_private(amount: field, hiding_point_slot: field) */
+ finalize_transfer_to_private: ((
+ amount: FieldLike,
+ hiding_point_slot: FieldLike
+ ) => ContractFunctionInteraction) &
+ Pick;
+
+ /** get_admin() */
+ get_admin: (() => ContractFunctionInteraction) &
+ Pick;
+
+ /** is_minter(minter: struct) */
+ is_minter: ((minter: AztecAddressLike) => ContractFunctionInteraction) &
+ Pick;
+
+ /** mint_to_private(from: struct, to: struct, amount: field) */
+ mint_to_private: ((
+ from: AztecAddressLike,
+ to: AztecAddressLike,
+ amount: FieldLike
+ ) => ContractFunctionInteraction) &
+ Pick;
+
+ /** mint_to_public(to: struct, amount: field) */
+ mint_to_public: ((
+ to: AztecAddressLike,
+ amount: FieldLike
+ ) => ContractFunctionInteraction) &
+ Pick;
+
+ /** prepare_transfer_to_private(to: struct) */
+ prepare_transfer_to_private: ((
+ to: AztecAddressLike
+ ) => ContractFunctionInteraction) &
+ Pick;
+
+ /** private_get_decimals() */
+ private_get_decimals: (() => ContractFunctionInteraction) &
+ Pick;
+
+ /** private_get_name() */
+ private_get_name: (() => ContractFunctionInteraction) &
+ Pick;
+
+ /** private_get_symbol() */
+ private_get_symbol: (() => ContractFunctionInteraction) &
+ Pick;
+
+ /** public_dispatch(selector: field) */
+ public_dispatch: ((selector: FieldLike) => ContractFunctionInteraction) &
+ Pick;
+
+ /** public_get_decimals() */
+ public_get_decimals: (() => ContractFunctionInteraction) &
+ Pick;
+
+ /** public_get_name() */
+ public_get_name: (() => ContractFunctionInteraction) &
+ Pick;
+
+ /** public_get_symbol() */
+ public_get_symbol: (() => ContractFunctionInteraction) &
+ Pick;
+
+ /** set_admin(new_admin: struct) */
+ set_admin: ((new_admin: AztecAddressLike) => ContractFunctionInteraction) &
+ Pick;
+
+ /** set_minter(minter: struct, approve: boolean) */
+ set_minter: ((
+ minter: AztecAddressLike,
+ approve: boolean
+ ) => ContractFunctionInteraction) &
+ Pick;
+
+ /** setup_refund(fee_payer: struct, user: struct, funded_amount: field, nonce: field) */
+ setup_refund: ((
+ fee_payer: AztecAddressLike,
+ user: AztecAddressLike,
+ funded_amount: FieldLike,
+ nonce: FieldLike
+ ) => ContractFunctionInteraction) &
+ Pick;
+
+ /** total_supply() */
+ total_supply: (() => ContractFunctionInteraction) &
+ Pick;
+
+ /** transfer(to: struct, amount: field) */
+ transfer: ((
+ to: AztecAddressLike,
+ amount: FieldLike
+ ) => ContractFunctionInteraction) &
+ Pick;
+
+ /** transfer_in_private(from: struct, to: struct, amount: field, nonce: field) */
+ transfer_in_private: ((
+ from: AztecAddressLike,
+ to: AztecAddressLike,
+ amount: FieldLike,
+ nonce: FieldLike
+ ) => ContractFunctionInteraction) &
+ Pick;
+
+ /** transfer_in_public(from: struct, to: struct, amount: field, nonce: field) */
+ transfer_in_public: ((
+ from: AztecAddressLike,
+ to: AztecAddressLike,
+ amount: FieldLike,
+ nonce: FieldLike
+ ) => ContractFunctionInteraction) &
+ Pick;
+
+ /** transfer_to_private(to: struct, amount: field) */
+ transfer_to_private: ((
+ to: AztecAddressLike,
+ amount: FieldLike
+ ) => ContractFunctionInteraction) &
+ Pick;
+
+ /** transfer_to_public(from: struct, to: struct, amount: field, nonce: field) */
+ transfer_to_public: ((
+ from: AztecAddressLike,
+ to: AztecAddressLike,
+ amount: FieldLike,
+ nonce: FieldLike
+ ) => ContractFunctionInteraction) &
+ Pick;
+ };
+
+ public static get events(): {
+ Transfer: {
+ abiType: AbiType;
+ eventSelector: EventSelector;
+ fieldNames: string[];
+ };
+ } {
+ return {
+ Transfer: {
+ abiType: {
+ fields: [
+ {
+ name: "from",
+ type: {
+ fields: [
+ {
+ name: "inner",
+ type: {
+ kind: "field",
+ },
+ },
+ ],
+ kind: "struct",
+ path: "authwit::aztec::protocol_types::address::aztec_address::AztecAddress",
+ },
+ },
+ {
+ name: "to",
+ type: {
+ fields: [
+ {
+ name: "inner",
+ type: {
+ kind: "field",
+ },
+ },
+ ],
+ kind: "struct",
+ path: "authwit::aztec::protocol_types::address::aztec_address::AztecAddress",
+ },
+ },
+ {
+ name: "amount",
+ type: {
+ kind: "field",
+ },
+ },
+ ],
+ kind: "struct",
+ path: "Token::Transfer",
+ },
+ eventSelector: EventSelector.fromSignature(
+ "Transfer((Field),(Field),Field)"
+ ),
+ fieldNames: ["from", "to", "amount"],
+ },
+ };
+ }
+}
+```
+
+Read more about interacting with contracts using `aztec.js` [by following this tutorial](../../tutorials/codealong/js_tutorials/aztecjs-getting-started.md).
+
+### Aztec.nr interfaces
+
+An Aztec.nr contract can [call a function](./writing_contracts/call_contracts.md) in another contract via `context.call_private_function` or `context.call_public_function`. However, this requires manually assembling the function selector and manually serializing the arguments, which is not type-safe.
+
+To make this easier, the compiler automatically generates interface structs that expose a convenience method for each function listed in a given contract artifact. These structs are intended to be used from another contract project that calls into the current one.
+
+Below is an example of interface usage generated from the [Token (GitHub link)](https://github.com/AztecProtocol/aztec-packages/blob/master/noir-projects/noir-contracts/contracts/token_contract/src/main.nr) contract, used from the [FPC (GitHub link)](https://github.com/AztecProtocol/aztec-packages/blob/master/noir-projects/noir-contracts/contracts/fpc_contract/src/main.nr):
+
+```rust
+contract FPC {
+
+ ...
+
+ use dep::token::Token;
+
+ ...
+
+
+ #[private]
+ fn fee_entrypoint_private(amount: Field, asset: AztecAddress, secret_hash: Field, nonce: Field) {
+ assert(asset == storage.other_asset.read());
+ Token::at(asset).transfer_to_public(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);
+ }
+
+ #[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);
+ }
+
+ ...
+
+}
+```
+
+Read more about how to use the Aztec.nr interfaces [here](../../../aztec/smart_contracts/functions/index.md).
+
+:::info
+At the moment, the compiler generates these interfaces from already compiled ABIs, and not from source code. This means that you should not import a generated interface from within the same project as its source contract, or you risk circular references.
+:::
+
+## Next steps
+
+Once you have compiled your contracts, you can use the generated artifacts via the `Contract` class in the `aztec.js` package to deploy and interact with them, or rely on the type-safe typescript classes directly.
diff --git a/docs/versioned_docs/version-v0.82.2-alpha-testnet.5/developers/guides/smart_contracts/index.md b/docs/versioned_docs/version-v0.82.2-alpha-testnet.5/developers/guides/smart_contracts/index.md
new file mode 100644
index 000000000000..48fb4a66781e
--- /dev/null
+++ b/docs/versioned_docs/version-v0.82.2-alpha-testnet.5/developers/guides/smart_contracts/index.md
@@ -0,0 +1,39 @@
+---
+title: Aztec.nr
+tags: [aztec.nr]
+---
+
+import DocCardList from "@theme/DocCardList";
+
+Aztec.nr is the smart contract development framework for Aztec. It is a set of utilities that
+help you write Noir programs to deploy on the Aztec network.
+
+## Contract Development
+
+### Prerequisites
+
+- Install [Aztec Sandbox and tooling](../../getting_started.md)
+- Install the [Noir LSP](../local_env/installing_noir_lsp.md) for your editor.
+
+### Flow
+
+1. Write your contract and specify your contract dependencies. Every contract written for Aztec will have
+ aztec-nr as a dependency. Add it to your `Nargo.toml` with
+
+```toml
+# Nargo.toml
+[dependencies]
+aztec = { git="https://github.com/AztecProtocol/aztec-packages/", tag="v0.82.2", directory="noir-projects/aztec-nr/aztec" }
+```
+
+2. [Write your contracts](./writing_contracts/index.mdx).
+3. [Profile](./profiling_transactions.md) the private functions in your contract to get
+ a sense of how long generating client side proofs will take
+4. Write unit tests [using the TXE](testing.md) and end-to-end
+ tests [with typescript](../js_apps/test.md)
+5. [Compile](how_to_compile_contract.md) your contract
+6. [Deploy](../js_apps/deploy_contract.md) your contract with Aztec.js
+
+## Section Contents
+
+
diff --git a/docs/versioned_docs/version-v0.82.2-alpha-testnet.5/developers/guides/smart_contracts/profiling_transactions.md b/docs/versioned_docs/version-v0.82.2-alpha-testnet.5/developers/guides/smart_contracts/profiling_transactions.md
new file mode 100644
index 000000000000..27f7984d1332
--- /dev/null
+++ b/docs/versioned_docs/version-v0.82.2-alpha-testnet.5/developers/guides/smart_contracts/profiling_transactions.md
@@ -0,0 +1,95 @@
+---
+title: Profiling Transactions
+sidebar_position: 1
+tags: [contracts, profiling]
+---
+
+An Aztec transaction typically consists of a private and a public part. The private part is where the user executes contract logic within the PXE and generates a proof of execution, which is then sent to the sequencer.
+
+Since proof generation is an expensive operation that needs to be done on the client side, it is important to optimize the private contract logic. It is desirable to keep the gate count of circuits representing the private contract logic as low as possible.
+
+A private transaction can involve multiple function calls. It starts with an account `entrypoint()` which may call several private functions to execute the application logic, which in turn might call other functions. Moreover, every private function call has to go through a round of kernel circuits. Read more about the transaction lifecycle [here](../../../aztec/concepts/transactions.md).
+
+In this guide, we will look at how to profile the private execution of a transaction, allowing you to get the gate count of each private function within the transaction, including the kernel circuits.
+
+## Prerequisites
+
+- `aztec-nargo` installed (go to [Sandbox section](../../reference/environment_reference/sandbox-reference.md) for installation instructions)
+- `aztec-wallet` installed (installed as part of the Sandbox)
+
+## Profiling using aztec-wallet
+
+The profiling tool is integrated into the `aztec-wallet`.
+
+In this example, we will profile a simple "private token transfer" transaction which uses the [transfer](https://github.com/AztecProtocol/aztec-packages/blob/master/noir-projects/noir-contracts/contracts/token_contract/src/main.nr#L263) method in the token contract.
+Let us start by deploying the token contarct (included in the Sandbox) and minting some tokens to the test account.
+
+```bash
+# Import some test accounts included in cli-wallet
+aztec-wallet import-test-accounts
+
+# Deploy a token contract.
+aztec-wallet deploy TokenContractArtifact --from accounts:test0 --args accounts:test0 TestToken TST 18 -a token
+
+# Mint some tokens to the test0 account
+aztec-wallet send mint_to_private -ca token --args accounts:test0 accounts:test0 100 -f test0
+```
+
+Now, the `test0` account can transfer tokens by running:
+
+```bash
+# Send 40 tokens from test0 to test1
+aztec-wallet send transfer -ca token --args accounts:test1 40 -f accounts:test0
+```
+
+Instead of sending the above transaction, you can profile it by running the `profile` command with the same parameters.
+
+
+```bash
+aztec-wallet profile transfer -ca token --args accounts:test1 40 -f accounts:test0
+```
+
+This will print the following results after some time:
+
+```bash
+Gate count per circuit:
+ SchnorrAccount:entrypoint Gates: 21,724 Acc: 21,724
+ private_kernel_init Gates: 45,351 Acc: 67,075
+ Token:transfer Gates: 31,559 Acc: 98,634
+ private_kernel_inner Gates: 78,452 Acc: 177,086
+ private_kernel_reset Gates: 91,444 Acc: 268,530
+ private_kernel_tail Gates: 31,201 Acc: 299,731
+
+Total gates: 299,731
+```
+
+Here you can see the gate count of each private function call in the transaction along with the kernel circuits needed in between, and the total gate count.
+
+This will help you understand which parts of your transaction are bottlenecks and optimize the contract logic accordingly.
+
+
+## Flamegraph
+
+While the `aztec-wallet` provides a way to profile the gate count of each private function in a transaction, flamegraph tool lets you visualize the gate count of each operation within a private function.
+
+You can run the flamegraph tool by running the following command:
+
+```bash
+aztec flamegraph
+```
+
+For example, if you want to flamegraph the `cast_vote` function [aztec-starter](https://github.com/AztecProtocol/aztec-starter/blob/main/src/main.nr), you can do
+
+```bash
+aztec-nargo compile
+aztec flamegraph target/easy_private_voting_contract-EasyPrivateVoting.json cast_vote
+```
+
+This will generate a flamegraph of the `cast_vote` function and save the output svg to the `target` directory. You can open the svg file in your browser to visualize the flamegraph.
+
+You can also run the same command with `SERVE=1` to serve the flamegraph on a local server.
+
+```bash
+SERVE=1 aztec flamegraph target/easy_private_voting_contract-EasyPrivateVoting.json cast_vote
+```
+This will serve the flamegraph on `http://localhost:8000`.
diff --git a/docs/versioned_docs/version-v0.82.2-alpha-testnet.5/developers/guides/smart_contracts/testing.md b/docs/versioned_docs/version-v0.82.2-alpha-testnet.5/developers/guides/smart_contracts/testing.md
new file mode 100644
index 000000000000..60cfbd7dab77
--- /dev/null
+++ b/docs/versioned_docs/version-v0.82.2-alpha-testnet.5/developers/guides/smart_contracts/testing.md
@@ -0,0 +1,408 @@
+---
+title: Testing Contracts
+tags: [contracts, tests, testing, txe]
+keywords: [tests, testing, txe]
+sidebar_position: 2
+importance: 1
+---
+
+Aztec contracts can be tested in a variety of ways depending on the needs of a particular application and the complexity of the interactions they must support.
+
+To test individual contract functions, you can use the Testing eXecution Environment (TXE) described below. For more complex interactions that require checking that the protocol rules are enforced, you should [write end-to-end tests using TypeScript](../js_apps/test.md).
+
+## Pure Noir tests
+
+Noir supports the `#[test]` annotation which can be used to write simple logic tests on isolated utility functions. These tests only make assertions on algorithms and cannot interact with protocol-specific constructs such as `storage` or `context`, but are extremely fast and can be useful in certain scenarios.
+
+```rust title="pure_noir_testing" showLineNumbers
+#[test]
+fn test_to_from_field() {
+ let field = 1234567890;
+ let card = Card::from_field(field);
+ assert(card.to_field() == field);
+}
+```
+> Source code: noir-projects/noir-contracts/contracts/card_game_contract/src/cards.nr#L40-L47
+
+
+To learn more about Noir testing, please refer to [the Noir docs](https://Noir-lang.org/docs/tooling/testing/).
+
+## TXE (pronounced "trixie")
+
+In order to interact with the protocol, Aztec contracts leverage the power of oracles: functions that reach out to the outside world and are able to query and manipulate data outside of itself. The values returned by oracles are then constrained inside Noir and modifications to the blockchain state are later verified to adhere to the protocol rules by our kernel circuits.
+
+However, all of this is often not necessary to ensure the contract logic itself is sound. All that we need is an entity to provide values consistent with real execution. This is where our TXE (Testing eXecution Environment, pronounced "trixie") comes in!
+
+TXE is a JSON RPC server much like PXE, but provides an extra set of oracle functions called `cheatcodes` that allow developers to manipulate the state of the chain and simulate contract execution. Since TXE skips most of the checks, block building and other intricacies of the Aztec protocol, it is much faster to run than simulating everything in the sandbox.
+
+## TXE vs End-to-end tests
+
+End-to-end tests are written in typescripts and use compiled Aztec contracts and generated Typescript interfaces, a private execution environment (PXE) and a simulated execution environment to process transactions, create blocks and apply state updates. This allows for advanced checks on state updates like generation the of logs, cross-chain messages and checking transaction status and also enforce the rules of the protocol (e.g. checks in our rollup circuits). If you need the rules of the protocol to be enforced or require complex interactions (such as with L1 contracts), please refer to [Testing Aztec.nr contracts with Typescript](../js_apps/test.md).
+
+The TXE is a super fast framework in Noir to quickly test your smart contract code.
+
+So to summarize:
+
+- End-to-end tests are written in Typescript. TXE in Noir.
+- End-to-end tests are most similar to using mocha + ethers.js to test Solidity Contracts. TXE is like foundry (fast tests in solidity)
+
+### Running TXE
+
+If you have [the sandbox](../../getting_started.md) installed, you can run TXE tests using:
+
+`aztec test`
+
+The complete process for running tests:
+
+1. Compile contracts
+2. Start the sandbox
+3. Run `aztec test`
+
+In order to use the TXE, it must be running on a known address.
+
+:::warning
+Since TXE tests are written in Noir and executed with `aztec-nargo`, they all run in parallel. This also means every test creates their own isolated environment, so state modifications are local to each one of them.
+:::
+
+### Writing TXE tests
+
+`aztec-nr` provides an utility class called `TestEnvironment`, that should take care of the most common operations needed to setup contract testing. Setting up a new test environment with `TestEnvironment::new()` **will reset the current test's TXE state**.
+
+:::tip
+You can find all of the methods available in the `TestEnvironment` [here (Github link)](https://github.com/AztecProtocol/aztec-packages/blob/v0.82.2/noir-projects/aztec-nr/aztec/src/test/helpers/test_environment.nr).
+:::
+
+```rust title="txe_test_increment" showLineNumbers
+#[test]
+unconstrained fn test_increment() {
+ // Setup env, generate keys
+ let mut env = TestEnvironment::new();
+ let owner = env.create_account(1);
+ let sender = env.create_account(2);
+ let initial_value: Field = 5;
+ env.impersonate(owner);
+ // Deploy contract and initialize
+ let initializer = Counter::interface().initialize(initial_value as u64, owner);
+ let counter_contract = env.deploy_self("Counter").with_private_initializer(initializer);
+ let contract_address = counter_contract.to_address();
+ // Read the stored value in the note
+ env.impersonate(contract_address);
+ let counter_slot = Counter::storage_layout().counters.slot;
+ let owner_storage_slot = derive_storage_slot_in_map(counter_slot, owner);
+ let mut options = NoteViewerOptions::new();
+ let notes: BoundedVec =
+ view_notes(owner_storage_slot, options);
+ let initial_note_value = notes.get(0).value;
+ assert(
+ initial_note_value == initial_value,
+ f"Expected {initial_value} but got {initial_note_value}",
+ );
+ // Increment the counter
+ Counter::at(contract_address).increment(owner, sender).call(&mut env.private());
+ // get_counter is an unconstrained function, so we call it directly (we're in the same module)
+ let current_value_for_owner = get_counter(owner);
+ let expected_current_value = initial_value + 1;
+ assert(
+ expected_current_value == current_value_for_owner,
+ f"Expected {expected_current_value} but got {current_value_for_owner}",
+ );
+}
+```
+> Source code: noir-projects/noir-contracts/contracts/counter_contract/src/main.nr#L100-L137
+
+
+:::warning
+Tests run significantly faster as `unconstrained` functions. This means we generate bytecode (Brillig) and not circuits (ACIR), which _should_ yield exactly the same results. Any other behavior is considered a bug.
+:::
+
+### Imports
+
+Writing tests in contracts requires importing additional modules from Aztec.nr. Here are the modules that are needed for testing the increment function in the counter contract.
+
+```rust title="test_imports" showLineNumbers
+use crate::test;
+use dep::aztec::note::note_getter::{MAX_NOTES_PER_PAGE, view_notes};
+use dep::aztec::note::note_viewer_options::NoteViewerOptions;
+use dep::aztec::protocol_types::storage::map::derive_storage_slot_in_map;
+use dep::aztec::test::helpers::test_environment::TestEnvironment;
+```
+> Source code: noir-projects/noir-contracts/contracts/counter_contract/src/main.nr#L92-L99
+
+
+### Deploying contracts
+
+```rust
+
+// Deploy the contract we're currently on
+
+let deployer = env.deploy_self("ContractName");
+
+// Deploy a standalone contract in a path relative to the current one (always from the location of Nargo.toml)
+
+let deployer = env.deploy("path_to_contract_root_folder_where_nargo_toml_is", "ContractName");
+
+// Deploy a contract in a workspace
+
+let deployer = env.deploy("path_to_workspace_root_folder_where_main_nargo_toml_is@package_name", "ContractName");
+
+// Now one of these can be called, depending on the contract and their possible initialization options.
+// Remember a contract can only be initialized once.
+
+let my_private_initializer_call_interface = MyContract::interface().private_constructor(...);
+let my_contract_instance = deployer.with_private_initializer(my_private_initializer_call_interface);
+
+// or
+
+let my_public_initializer_call_interface = MyContract::interface().public_constructor(...);
+let my_contract_instance = deployer.with_public_initializer(my_public_initializer_call_interface);
+
+// or
+
+let my_contract_instance = deployer.without_initializer();
+```
+
+:::warning
+It is always necessary to deploy a contract in order to test it. **It is important to keep them up to date**, as TXE cannot recompile them on changes. Think of it as regenerating the bytecode and ABI so it becomes accessible externally.
+:::
+
+### Calling functions
+
+Our test environment is capable of utilizing the autogenerated contract interfaces to abstract calls, but without going through the usual external call flow (meaning much faster execution).
+
+#### Private
+
+For example, to call the private `transfer` function on the token contract:
+
+```rust title="txe_test_transfer_private" showLineNumbers
+// Transfer tokens
+let transfer_amount = 1000 as u128;
+Token::at(token_contract_address).transfer(recipient, transfer_amount).call(&mut env.private());
+```
+> Source code: noir-projects/noir-contracts/contracts/token_contract/src/test/transfer.nr#L11-L15
+
+
+#### Public
+
+To call the public `transfer_in_public` function:
+
+```rust title="call_public" showLineNumbers
+Token::at(token_contract_address).transfer_in_public(owner, owner, transfer_amount, 0).call(
+ &mut env.public(),
+);
+```
+> Source code: noir-projects/noir-contracts/contracts/token_contract/src/test/transfer_in_public.nr#L29-L33
+
+
+#### Unconstrained
+
+Unconstrained functions can be directly called from the contract interface. Notice that we need to set the contract address to the specific token contract that we are calling before making the call. This is to ensure that `view_notes` works properly.
+
+```rust title="txe_test_call_unconstrained" showLineNumbers
+pub unconstrained fn check_private_balance(
+ token_contract_address: AztecAddress,
+ address: AztecAddress,
+ address_amount: u128,
+) {
+ let current_contract_address = get_contract_address();
+ cheatcodes::set_contract_address(token_contract_address);
+ // Direct call to unconstrained
+ let balance_of_private = Token::balance_of_private(address);
+ assert(balance_of_private == address_amount, "Private balance is not correct");
+ cheatcodes::set_contract_address(current_contract_address);
+}
+```
+> Source code: noir-projects/noir-contracts/contracts/token_contract/src/test/utils.nr#L143-L156
+
+
+### Creating accounts
+
+The test environment provides two different ways of creating accounts, depending on the testing needs. For most cases, it is only necessary to obtain a valid `AztecAddress` that represents the user's account contract. For this, is is enough to do:
+
+```rust
+let mocked_account_address = env.create_account(secret);
+```
+
+These accounts also create the necessary keys to ensure notes can be created/nullified, etc.
+
+For more advanced flows, such as authwits, it is necessary to create a real `AccountContract`, with valid signing keys that gets actually deployed to TXE. For that you can use:
+
+```rust
+let real_account_address = env.create_account_contract(secret);
+```
+
+Besides deploying a complete `SchnorrAccountContract`, key derivation is performed so that authwits can be signed. It is slightly slower than the mocked version.
+
+Once accounts have been created, you can impersonate them in your test by calling:
+
+```rust
+env.impersonate(account_address);
+// or (these are equivalent)
+cheatcodes::set_contract_address(contract_address);
+```
+
+### Checking state
+
+It is possible to use the regular oracles in tests in order to retrieve public and private state and make assertions about them.
+
+:::warning
+Remember to switch to the current contract's address in order to be able to read it's siloed state!
+:::
+
+Reading public state:
+```rust title="txe_test_read_public" showLineNumbers
+pub unconstrained fn check_public_balance(
+ token_contract_address: AztecAddress,
+ address: AztecAddress,
+ address_amount: u128,
+) {
+ let current_contract_address = get_contract_address();
+ cheatcodes::set_contract_address(token_contract_address);
+ let block_number = get_block_number();
+
+ let balances_slot = Token::storage_layout().public_balances.slot;
+ let address_slot = derive_storage_slot_in_map(balances_slot, address);
+ let amount: u128 = storage_read(token_contract_address, address_slot, block_number);
+ assert(amount == address_amount, "Public balance is not correct");
+ cheatcodes::set_contract_address(current_contract_address);
+}
+```
+> Source code: noir-projects/noir-contracts/contracts/token_contract/src/test/utils.nr#L96-L112
+
+
+Reading notes:
+```rust title="txe_test_read_notes" showLineNumbers
+// Read the stored value in the note
+env.impersonate(contract_address);
+let counter_slot = Counter::storage_layout().counters.slot;
+let owner_storage_slot = derive_storage_slot_in_map(counter_slot, owner);
+let mut options = NoteViewerOptions::new();
+let notes: BoundedVec =
+ view_notes(owner_storage_slot, options);
+let initial_note_value = notes.get(0).value;
+assert(
+ initial_note_value == initial_value,
+ f"Expected {initial_value} but got {initial_note_value}",
+);
+```
+> Source code: noir-projects/noir-contracts/contracts/counter_contract/src/main.nr#L113-L126
+
+
+### Authwits
+
+#### Private
+
+You can add [authwits](writing_contracts/authwit.md) to the TXE. Here is an example of testing a private token transfer using authwits:
+
+```rust title="private_authwit" showLineNumbers
+let transfer_amount = 1000 as u128;
+let transfer_private_from_call_interface =
+ Token::at(token_contract_address).transfer_in_private(owner, recipient, transfer_amount, 1);
+authwit_cheatcodes::add_private_authwit_from_call_interface(
+ owner,
+ recipient,
+ transfer_private_from_call_interface,
+);
+// Impersonate recipient to perform the call
+env.impersonate(recipient);
+// Transfer tokens
+transfer_private_from_call_interface.call(&mut env.private());
+```
+> Source code: noir-projects/noir-contracts/contracts/token_contract/src/test/transfer_in_private.nr#L11-L24
+
+
+#### Public
+
+```rust title="public_authwit" showLineNumbers
+let public_transfer_in_private_call_interface =
+ Token::at(token_contract_address).transfer_in_public(owner, recipient, transfer_amount, 1);
+authwit_cheatcodes::add_public_authwit_from_call_interface(
+ owner,
+ recipient,
+ public_transfer_in_private_call_interface,
+);
+```
+> Source code: noir-projects/noir-contracts/contracts/token_contract/src/test/transfer_in_public.nr#L115-L123
+
+
+### Storing notes in cache
+
+Sometimes we have to tell TXE about notes that are not generated by ourselves, but someone else. This allows us to check if we are able to decrypt them:
+
+```rust title="txe_test_add_note" showLineNumbers
+let balances_owner_slot =
+ derive_storage_slot_in_map(Token::storage_layout().balances.slot, owner);
+
+env.add_note(
+ UintNote { value: amount, owner: owner, randomness: note_randomness },
+ balances_owner_slot,
+ token_contract_address,
+);
+```
+> Source code: noir-projects/noir-contracts/contracts/token_contract/src/test/utils.nr#L178-L187
+
+
+### Time traveling
+
+TXE can force the generation of "new blocks" very quickly using:
+
+```rust
+env.advance_block_by(n_blocks);
+```
+
+This will effectively consolidate state transitions into TXE's internal trees, allowing things such as reading "historical state" from private, generating inclusion proofs, etc.
+
+### Failing cases
+
+You can test functions that you expect to fail generically, with the `#[test(should_fail)]` annotation, or that it should fail with a specific message with `#[test(should_fail_with = "Failure message")]`.
+
+For example:
+
+```rust title="fail_with_message" showLineNumbers
+#[test(should_fail_with = "invalid nonce")]
+unconstrained fn transfer_private_failure_on_behalf_of_self_non_zero_nonce() {
+ // Setup without account contracts. We are not using authwits here, so dummy accounts are enough
+ let (env, token_contract_address, owner, recipient, _) =
+ utils::setup_and_mint_to_private(/* with_account_contracts */ false);
+ // Add authwit
+ let transfer_amount = 1000 as u128;
+ let transfer_private_from_call_interface =
+ Token::at(token_contract_address).transfer_in_private(owner, recipient, transfer_amount, 1);
+ authwit_cheatcodes::add_private_authwit_from_call_interface(
+ owner,
+ recipient,
+ transfer_private_from_call_interface,
+ );
+ // Transfer tokens
+ transfer_private_from_call_interface.call(&mut env.private());
+}
+```
+> Source code: noir-projects/noir-contracts/contracts/token_contract/src/test/transfer_in_private.nr#L30-L48
+
+
+You can also use the `assert_public_call_fails` or `assert_private_call_fails` methods on the `TestEnvironment` to check that a call fails.
+
+```rust title="assert_public_fail" showLineNumbers
+// Try to set ourselves as admin, fail miserably
+let set_admin_call_interface = Token::at(token_contract_address).set_admin(recipient);
+env.assert_public_call_fails(set_admin_call_interface);
+```
+> Source code: noir-projects/noir-contracts/contracts/token_contract/src/test/access_control.nr#L34-L38
+
+
+### Logging
+
+You can use `aztec.nr`'s oracles as usual for debug logging, as explained [here](../../reference/debugging/index.md)
+
+
+:::warning
+Remember to set the following environment variables to activate debug logging:
+
+```bash
+export LOG_LEVEL="debug"
+```
+
+:::
+
+### All Cheatcodes
+
+You can find the full list of cheatcodes available in the TXE [here](https://github.com/AztecProtocol/aztec-packages/blob/v0.82.2/noir-projects/aztec-nr/aztec/src/test/helpers/cheatcodes.nr)
diff --git a/docs/versioned_docs/version-v0.82.2-alpha-testnet.5/developers/guides/smart_contracts/writing_contracts/_category_.json b/docs/versioned_docs/version-v0.82.2-alpha-testnet.5/developers/guides/smart_contracts/writing_contracts/_category_.json
new file mode 100644
index 000000000000..7e21bf8e7ac4
--- /dev/null
+++ b/docs/versioned_docs/version-v0.82.2-alpha-testnet.5/developers/guides/smart_contracts/writing_contracts/_category_.json
@@ -0,0 +1,6 @@
+{
+ "position": 0,
+ "collapsible": true,
+ "collapsed": true,
+ "label": "Writing Contracts"
+}
diff --git a/docs/versioned_docs/version-v0.82.2-alpha-testnet.5/developers/guides/smart_contracts/writing_contracts/authwit.md b/docs/versioned_docs/version-v0.82.2-alpha-testnet.5/developers/guides/smart_contracts/writing_contracts/authwit.md
new file mode 100644
index 000000000000..5b37e443a417
--- /dev/null
+++ b/docs/versioned_docs/version-v0.82.2-alpha-testnet.5/developers/guides/smart_contracts/writing_contracts/authwit.md
@@ -0,0 +1,344 @@
+---
+title: Authentication Witness
+description: Developer Documentation to use Authentication Witness for authentication actions on Aztec.
+tags: [accounts, authwit]
+---
+
+This page introduces the authwit library and how you can use it in your Aztec.nr smart contracts. [Skip to the usage](#usage).
+
+For a guide on using authwit in Aztec.js, [read this](../../js_apps/authwit.md).
+
+## Prerequisite reading
+
+- [Authwit](../../../../aztec/concepts/advanced/authwit.md)
+
+## Introduction
+
+Authentication Witness (authwit) is a scheme for authentication actions on Aztec, so users can allow third-parties (eg other contracts) to execute an action on their behalf. Authwits can only authorize actions for contracts that your account is calling, they cannot be used to permit other users to take actions on your behalf.
+
+How it works logically is explained in the [concepts](../../../../aztec/concepts/advanced/authwit.md) but we will do a short recap here.
+
+An authentication witness is defined for a specific action, such as allowing a Defi protocol to transfer funds on behalf of the user. An action is here something that could be explained as `A is allowed to perform X operation on behalf of B` and we define it as a hash computed as such:
+
+```rust
+authentication_witness_action = H(
+ caller: AztecAddress,
+ contract: AztecAddress,
+ selector: Field,
+ argsHash: Field
+);
+
+// Example action that authenticates:
+// defi contract to transfer 1000 tokens to itself on behalf of alice_account
+authentication_witness_action = H(
+ defi,
+ token,
+ transfer_selector,
+ H(alice_account, defi, 1000)
+);
+```
+
+Given the action, the developer can ask the `on_behalf_of` account contract if the action is authenticated or not.
+
+```mermaid
+sequenceDiagram
+ actor Alice
+ participant AC as Alice Account
+ participant Token
+ Alice->>AC: Defi.deposit(Token, 1000);
+ activate AC
+ AC->>Defi: deposit(Token, 1000);
+ activate Defi
+ Defi->>Token: transfer(Alice, Defi, 1000);
+ activate Token
+ Token->>AC: Check if Defi may call transfer(Alice, Defi, 1000);
+ AC-->>Alice: Please give me AuthWit for DeFi calling transfer(Alice, Defi, 1000);
+ activate Alice
+ Alice-->>Alice: Produces Authentication witness
+ Alice-->>AC: AuthWit for transfer(Alice, Defi, 1000);
+ AC->>Token: AuthWit validity
+ deactivate Alice
+ Token->>Token: throw if invalid AuthWit
+ Token->>Token: transfer(Alice, Defi, 1000);
+ Token->>Defi: success
+ deactivate Token
+ Defi->>Defi: deposit(Token, 1000);
+ deactivate Defi
+ deactivate AC
+```
+
+:::info
+Note in particular that the request for a witness is done by the token contract, and the user will have to provide it to the contract before it can continue execution. Since the request is made all the way into the contract where it is to be used, we don't need to pass it along as an extra input to the functions before it which gives us a cleaner interface.
+:::
+
+As part of `AuthWit` we are assuming that the `on_behalf_of` implements the private function:
+
+```rust
+#[private]
+fn verify_private_authwit(inner_hash: Field) -> Field;
+```
+
+For public authwit, we have a shared registry that is used, there we are using a `consume` function.
+
+Both return the value `0xabf64ad4` (`IS_VALID` selector) for a successful authentication, and `0x00000000` for a failed authentication. You might be wondering why we are expecting the return value to be a selector instead of a boolean. This is mainly to account for a case of selector collisions where the same selector is used for different functions, and we don't want an account to mistakenly allow a different function to be called on its behalf - it is hard to return the selector by mistake, but you might have other functions returning a bool.
+
+## The `AuthWit` library.
+
+As part of 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 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.
+
+### General utilities
+
+The primary general utility is the `compute_authwit_message_hash_from_call` function which computes the action hash from its components. This is useful for when you need to generate a hash that is not for the current call, such as when you want to update a public approval state value that is later used for [authentication in public](#updating-approval-state-in-noir). You can view the implementation of this function [here (GitHub link)](https://github.com/AztecProtocol/aztec-packages/blob/master/noir-projects/aztec-nr/authwit/src/auth.nr).
+
+#### TypeScript utilities
+
+To make it convenient to compute the message hashes in TypeScript, the `aztec.js` package includes a `computeAuthWitMessageHash` function that you can use. Implementation [here (GitHub link)](https://github.com/AztecProtocol/aztec-packages/blob/master/yarn-project/aztec.js/src/utils/authwit.ts).
+
+### Utilities for private calls
+
+For private calls where we allow execution on behalf of others, we generally want to check if the current call is authenticated by `on_behalf_of`. To easily do so, we can use the `assert_current_call_valid_authwit` which fetches information from the current context without us needing to provide much beyond the `on_behalf_of`.
+
+This function will then make a call to `on_behalf_of` to execute the `verify_private_authwit` function which validates that the call is authenticated.
+The `on_behalf_of` should assert that we are indeed authenticated and then return the `IS_VALID` selector. If the return value is not as expected, we throw an error. This is to cover the case where the `on_behalf_of` might implemented some function with the same selector as the `verify_private_authwit` that could be used to authenticate unintentionally.
+
+#### Example
+
+```rust title="assert_current_call_valid_authwit" showLineNumbers
+if (!from.eq(context.msg_sender())) {
+ assert_current_call_valid_authwit(&mut context, from);
+} else {
+ assert(nonce == 0, "invalid nonce");
+}
+```
+> Source code: noir-projects/noir-contracts/contracts/token_contract/src/main.nr#L363-L369
+
+
+### Utilities for public calls
+
+Very similar to the above, we have variations that work in the public domain (`assert_current_call_valid_authwit_public`). These functions are wrapped to give a similar flow for both cases, but behind the scenes the logic is slightly different since the public goes to the auth registry, while the private flow calls the account contract.
+
+#### Example
+
+```rust title="assert_current_call_valid_authwit_public" showLineNumbers
+if (!from.eq(context.msg_sender())) {
+ assert_current_call_valid_authwit_public(&mut context, from);
+} else {
+ assert(nonce == 0, "invalid nonce");
+}
+```
+> Source code: noir-projects/noir-contracts/contracts/token_contract/src/main.nr#L226-L232
+
+
+## Usage
+
+Ok, enough talking, how do we use this?
+
+### Importing it
+
+To add it to your project, add the `authwit` library to your `Nargo.toml` file.
+
+```toml
+[dependencies]
+aztec = { git="https://github.com/AztecProtocol/aztec-packages/", tag="v0.82.2", directory="noir-projects/aztec-nr/aztec" }
+authwit = { git="https://github.com/AztecProtocol/aztec-packages/", tag="v0.82.2", directory="noir-projects/aztec-nr/authwit"}
+```
+
+Then you will be able to import it into your contracts as follows.
+
+```rust title="import_authwit" showLineNumbers
+use dep::authwit::auth::{
+ assert_current_call_valid_authwit, assert_current_call_valid_authwit_public,
+ compute_authwit_nullifier,
+};
+```
+> Source code: noir-projects/noir-contracts/contracts/token_contract/src/main.nr#L40-L45
+
+
+### Private Functions
+
+#### Checking if the current call is authenticated
+
+Based on the diagram earlier on this page let's take a look at how we can implement the `transfer` function such that it checks if the tokens are to be transferred `from` the caller or needs to be authenticated with an authentication witness.
+
+```rust title="transfer_in_private" showLineNumbers
+#[private]
+fn transfer_in_private(from: AztecAddress, to: AztecAddress, amount: u128, nonce: Field) {
+ if (!from.eq(context.msg_sender())) {
+ assert_current_call_valid_authwit(&mut context, from);
+ } else {
+ assert(nonce == 0, "invalid nonce");
+ }
+
+ storage.balances.at(from).sub(from, amount).emit(encode_and_encrypt_note(
+ &mut context,
+ from,
+ from,
+ ));
+ storage.balances.at(to).add(to, amount).emit(encode_and_encrypt_note(&mut context, to, from));
+}
+```
+> Source code: noir-projects/noir-contracts/contracts/token_contract/src/main.nr#L360-L382
+
+
+The first thing we see in the snippet above, is that if `from` is not the call we are calling the `assert_current_call_valid_authwit` function from [earlier](#private-functions). If the call is not throwing, we are all good and can continue with the transfer.
+
+In the snippet we are constraining the `else` case such that only `nonce = 0` is supported. This is not strictly necessary, but because I can't stand dangling useless values. By making it constrained, we can limit what people guess it does, I hope.
+
+#### Authenticating an action in TypeScript
+
+Cool, so we have a function that checks if the current call is authenticated, but how do we actually authenticate it? Well, assuming that we use a wallet that is following the spec, we import `computeAuthWitMessageHash` from `aztec.js` to help us compute the hash, and then we simply `addAuthWitness` to the wallet. Behind the scenes this will make the witness available to the oracle.
+
+```typescript title="authwit_transfer_example" showLineNumbers
+const action = asset
+ .withWallet(wallets[1])
+ .methods.transfer_in_private(accounts[0].address, accounts[1].address, amount, nonce);
+
+const witness = await wallets[0].createAuthWit({ caller: accounts[1].address, action });
+expect(
+ await wallets[0].lookupValidity(wallets[0].getAddress(), { caller: accounts[1].address, action }, witness),
+).toEqual({
+ isValidInPrivate: true,
+ isValidInPublic: false,
+});
+```
+> Source code: yarn-project/end-to-end/src/e2e_token_contract/transfer_in_private.test.ts#L32-L44
+
+
+Learn more about authwits in Aztec.js by [following this guide](../../js_apps/authwit.md).
+
+### Public Functions
+
+With private functions covered, how can we use this in a public function? Well, the answer is that we simply change one name of a function and then we are good to go :eyes: (almost).
+
+#### Checking if the current call is authenticated
+
+```rust title="transfer_in_public" showLineNumbers
+#[public]
+fn transfer_in_public(from: AztecAddress, to: AztecAddress, amount: u128, nonce: Field) {
+ if (!from.eq(context.msg_sender())) {
+ assert_current_call_valid_authwit_public(&mut context, from);
+ } else {
+ assert(nonce == 0, "invalid nonce");
+ }
+ let from_balance = storage.public_balances.at(from).read().sub(amount);
+ storage.public_balances.at(from).write(from_balance);
+ let to_balance = storage.public_balances.at(to).read().add(amount);
+ storage.public_balances.at(to).write(to_balance);
+}
+```
+> Source code: noir-projects/noir-contracts/contracts/token_contract/src/main.nr#L208-L221
+
+
+#### Authenticating an action in TypeScript
+
+Authenticating an action in the public domain is slightly different from the private domain, since we are executing a function on the auth registry contract to add the witness flag. As you might recall, this was to ensure that we don't need to call into the account contract from public, which is a potential DOS vector.
+
+In the snippet below, this is done as a separate contract call, but can also be done as part of a batch as mentioned in the [Accounts concepts](../../../../aztec/concepts/advanced/authwit.md#what-about-public).
+
+```typescript title="authwit_public_transfer_example" showLineNumbers
+const action = asset
+ .withWallet(wallets[1])
+ .methods.transfer_in_public(accounts[0].address, accounts[1].address, amount, nonce);
+
+const validateActionInteraction = await wallets[0].setPublicAuthWit({ caller: accounts[1].address, action }, true);
+await validateActionInteraction.send().wait();
+```
+> Source code: yarn-project/end-to-end/src/e2e_token_contract/transfer_in_public.test.ts#L69-L76
+
+
+#### Updating approval state in Noir
+
+We have cases where we need a non-wallet contract to approve an action to be executed by another contract. One of the cases could be when making more complex defi where funds are passed along. When doing so, we need the intermediate contracts to support approving of actions on their behalf.
+
+This is fairly straight forward to do using the `auth` library which includes logic for updating values in the public auth registry. Namely, you can prepare the `message_hash` using `compute_authwit_message_hash_from_call` and then simply feed it into the `set_authorized` function (both are in `auth` library) to update the value.
+
+When another contract later is consuming the authwit using `assert_current_call_valid_authwit_public` it will be calling the registry, and spend that authwit.
+
+An example of this would be our Uniswap example which performs a cross chain swap on L1. In here, we both do private and public auth witnesses, where the public is set by the uniswap L2 contract itself. In the below snippet, you can see that we compute the action hash and update the value in the registry. When we then call the `token_bridge` to execute afterwards, it reads this value, burns the tokens, and consumes the authentication.
+
+```rust title="authwit_uniswap_set" showLineNumbers
+// This helper method approves the bridge to burn this contract's funds and exits the input asset to L1
+// Assumes contract already has funds.
+// Assume `token` relates to `token_bridge` (ie token_bridge.token == token)
+// Note that private can't read public return values so created an internal public that handles everything
+// this method is used for both private and public swaps.
+#[public]
+#[internal]
+fn _approve_bridge_and_exit_input_asset_to_L1(
+ token: AztecAddress,
+ token_bridge: AztecAddress,
+ amount: u128,
+) {
+ // Since we will authorize and instantly spend the funds, all in public, we can use the same nonce
+ // every interaction. In practice, the authwit should be squashed, so this is also cheap!
+ let nonce = 0xdeadbeef;
+
+ let selector = FunctionSelector::from_signature("burn_public((Field),u128,Field)");
+ let message_hash = compute_authwit_message_hash_from_call(
+ token_bridge,
+ token,
+ context.chain_id(),
+ context.version(),
+ selector,
+ [context.this_address().to_field(), amount as Field, nonce],
+ );
+
+ // We need to make a call to update it.
+ set_authorized(&mut context, message_hash, true);
+
+ let this_portal_address = storage.portal_address.read();
+ // Exit to L1 Uniswap Portal !
+ TokenBridge::at(token_bridge)
+ .exit_to_l1_public(this_portal_address, amount, this_portal_address, nonce)
+ .call(&mut context)
+}
+```
+> Source code: noir-projects/noir-contracts/contracts/uniswap_contract/src/main.nr#L185-L221
+
+
+Outlining more of the `swap` flow: this simplified diagram shows how it will look for contracts that are not wallets but also need to support authentication witnesses.
+
+```mermaid
+sequenceDiagram
+ actor A as Alice
+ participant AC as Alice Account
+ participant CC as Crosschain Swap
+ participant TB as Token Bridge
+ participant T as Token
+
+ A->>AC: Swap 1000 token A to B on Uniswap L1
+ activate AC;
+ AC->>CC: Swap 1000 token A to B
+ activate CC;
+ CC->>T: Transfer to public 1000 tokens from Alice Account to CCS
+ activate T;
+ T->>AC: Have you approved this??
+ AC-->>A: Please give me an AuthWit
+ A-->>AC: Here is AuthWit
+ AC-->>AC: Validate AuthWit
+ AC->>T: Yes
+ deactivate T;
+ CC-->>CC: Setting flag to true
+ CC->>TB: Exit 1000 tokens to CCS
+ activate TB;
+ TB->>T: Burn 1000 tokens from CCS
+ activate T;
+ T->>CC: Have you approved this?
+ CC->>T: Yes
+ T-->>T: Burn
+ Token->>Defi: success
+ deactivate T;
+ TB-->>TB: Emit L2->L1 message
+ deactivate TB;
+ CC-->>CC: Emit L2->L1 message
+ deactivate CC;
+ deactivate AC;
+```
+
+:::info **TODO**
+Add a link to the blog-posts.
+:::
diff --git a/docs/versioned_docs/version-v0.82.2-alpha-testnet.5/developers/guides/smart_contracts/writing_contracts/call_contracts.md b/docs/versioned_docs/version-v0.82.2-alpha-testnet.5/developers/guides/smart_contracts/writing_contracts/call_contracts.md
new file mode 100644
index 000000000000..befdf7ea3fe7
--- /dev/null
+++ b/docs/versioned_docs/version-v0.82.2-alpha-testnet.5/developers/guides/smart_contracts/writing_contracts/call_contracts.md
@@ -0,0 +1,76 @@
+---
+title: Calling Other Contracts
+sidebar_position: 4
+tags: [functions, contracts]
+---
+
+A contract is a collection of persistent state variables and functions which may manipulate these variables.
+
+Functions and state variables within a contract's scope are said to belong to that contract. A contract can only access and modify its own state.
+
+If a contract wishes to access or modify another contract's state, it must make a call to an external function of the other contract. For anything to happen on the Aztec network, an external function of a contract needs to be called.
+
+### Add Contract as a Dependency
+
+Import the contract that you want to call into your `Nargo.toml` under `dependencies` like this:
+
+```toml
+token = { git="https://github.com/AztecProtocol/aztec-packages/", tag="v0.82.2", directory="noir-projects/noir-contracts/contracts/token_contract" }
+```
+
+### Import into your contract
+
+At the top of your contract, import the contract you want to call like this:
+
+```rust
+use token::Token;
+```
+
+### Call the function
+
+To call the function, you need to
+
+- Specify the address of the contract with `Contract::at(contract_address)`
+- Call the function name with `.function_name()`
+- Pass the parameters into the function call, like `.function_name(param1,param2)`
+- Specify the type of call you want to make and pass a mut reference to the context, like `.call(&mut context)`
+
+#### Private calls
+
+To call a private function, you can just use `call()` like this:
+
+```rust title="call_function" showLineNumbers
+Token::at(token).transfer(recipient, amount).call(&mut context);
+```
+> Source code: noir-projects/noir-contracts/contracts/escrow_contract/src/main.nr#L45-L47
+
+
+#### Public -> Public calls
+
+To call a public function from a public function, it is the same as above. You can just use `call()` like this:
+
+```rust title="public_to_public_call" showLineNumbers
+let _ = Token::at(collateral_asset)
+ .transfer_in_public(context.msg_sender(), context.this_address(), amount, nonce)
+ .call(&mut context);
+```
+> Source code: noir-projects/noir-contracts/contracts/lending_contract/src/main.nr#L133-L137
+
+
+#### Private -> Public calls
+
+To call a public function from private, you will need to enqueue it like this:
+
+```rust title="enqueue_public" showLineNumbers
+Lending::at(context.this_address())
+ ._deposit(AztecAddress::from_field(on_behalf_of), amount, collateral_asset)
+ .enqueue(&mut context);
+```
+> Source code: noir-projects/noir-contracts/contracts/lending_contract/src/main.nr#L119-L123
+
+
+Public functions are always executed after private execution. To learn why, read the [concepts overview](../../../../aztec/index.md).
+
+#### Other call types
+
+There are other call types, for example to ensure no state changes are made. You can learn more about them in the [call types glossary](../../../../aztec/glossary/call_types.md).
diff --git a/docs/versioned_docs/version-v0.82.2-alpha-testnet.5/developers/guides/smart_contracts/writing_contracts/call_functions.md b/docs/versioned_docs/version-v0.82.2-alpha-testnet.5/developers/guides/smart_contracts/writing_contracts/call_functions.md
new file mode 100644
index 000000000000..befdf7ea3fe7
--- /dev/null
+++ b/docs/versioned_docs/version-v0.82.2-alpha-testnet.5/developers/guides/smart_contracts/writing_contracts/call_functions.md
@@ -0,0 +1,76 @@
+---
+title: Calling Other Contracts
+sidebar_position: 4
+tags: [functions, contracts]
+---
+
+A contract is a collection of persistent state variables and functions which may manipulate these variables.
+
+Functions and state variables within a contract's scope are said to belong to that contract. A contract can only access and modify its own state.
+
+If a contract wishes to access or modify another contract's state, it must make a call to an external function of the other contract. For anything to happen on the Aztec network, an external function of a contract needs to be called.
+
+### Add Contract as a Dependency
+
+Import the contract that you want to call into your `Nargo.toml` under `dependencies` like this:
+
+```toml
+token = { git="https://github.com/AztecProtocol/aztec-packages/", tag="v0.82.2", directory="noir-projects/noir-contracts/contracts/token_contract" }
+```
+
+### Import into your contract
+
+At the top of your contract, import the contract you want to call like this:
+
+```rust
+use token::Token;
+```
+
+### Call the function
+
+To call the function, you need to
+
+- Specify the address of the contract with `Contract::at(contract_address)`
+- Call the function name with `.function_name()`
+- Pass the parameters into the function call, like `.function_name(param1,param2)`
+- Specify the type of call you want to make and pass a mut reference to the context, like `.call(&mut context)`
+
+#### Private calls
+
+To call a private function, you can just use `call()` like this:
+
+```rust title="call_function" showLineNumbers
+Token::at(token).transfer(recipient, amount).call(&mut context);
+```
+> Source code: noir-projects/noir-contracts/contracts/escrow_contract/src/main.nr#L45-L47
+
+
+#### Public -> Public calls
+
+To call a public function from a public function, it is the same as above. You can just use `call()` like this:
+
+```rust title="public_to_public_call" showLineNumbers
+let _ = Token::at(collateral_asset)
+ .transfer_in_public(context.msg_sender(), context.this_address(), amount, nonce)
+ .call(&mut context);
+```
+> Source code: noir-projects/noir-contracts/contracts/lending_contract/src/main.nr#L133-L137
+
+
+#### Private -> Public calls
+
+To call a public function from private, you will need to enqueue it like this:
+
+```rust title="enqueue_public" showLineNumbers
+Lending::at(context.this_address())
+ ._deposit(AztecAddress::from_field(on_behalf_of), amount, collateral_asset)
+ .enqueue(&mut context);
+```
+> Source code: noir-projects/noir-contracts/contracts/lending_contract/src/main.nr#L119-L123
+
+
+Public functions are always executed after private execution. To learn why, read the [concepts overview](../../../../aztec/index.md).
+
+#### Other call types
+
+There are other call types, for example to ensure no state changes are made. You can learn more about them in the [call types glossary](../../../../aztec/glossary/call_types.md).
diff --git a/docs/versioned_docs/version-v0.82.2-alpha-testnet.5/developers/guides/smart_contracts/writing_contracts/common_patterns/index.md b/docs/versioned_docs/version-v0.82.2-alpha-testnet.5/developers/guides/smart_contracts/writing_contracts/common_patterns/index.md
new file mode 100644
index 000000000000..993ed6a01e4e
--- /dev/null
+++ b/docs/versioned_docs/version-v0.82.2-alpha-testnet.5/developers/guides/smart_contracts/writing_contracts/common_patterns/index.md
@@ -0,0 +1,255 @@
+---
+title: Common Patterns
+sidebar_position: 7
+---
+
+There are many common patterns have been devised by the Aztec core engineering team and the work of the external community as we build Aztec.nr contracts internally (see some of them [here (GitHub link)](https://github.com/AztecProtocol/aztec-packages/tree/master/noir-projects/noir-contracts)).
+
+This doc aims to summarize some of them!
+
+Similarly we have discovered some anti-patterns too (like privacy leakage) that we will point out here!
+
+## Common Patterns
+
+### Approving another user/contract to execute an action on your behalf
+
+We call this the "authentication witness" pattern or authwit for short.
+
+- Approve someone in private domain:
+```typescript title="authwit_to_another_sc" showLineNumbers
+// 4. Give approval to bridge to burn owner's funds:
+const withdrawAmount = 9n;
+const nonce = Fr.random();
+const burnAuthwit = await user1Wallet.createAuthWit({
+ caller: l2Bridge.address,
+ action: l2Token.methods.burn_private(ownerAddress, withdrawAmount, nonce),
+});
+```
+> Source code: yarn-project/end-to-end/src/e2e_cross_chain_messaging/token_bridge_private.test.ts#L70-L78
+
+
+Here you approve a contract to burn funds on your behalf.
+
+- Approve in public domain:
+```typescript title="authwit_public_transfer_example" showLineNumbers
+const action = asset
+ .withWallet(wallets[1])
+ .methods.transfer_in_public(accounts[0].address, accounts[1].address, amount, nonce);
+
+const validateActionInteraction = await wallets[0].setPublicAuthWit({ caller: accounts[1].address, action }, true);
+await validateActionInteraction.send().wait();
+```
+> Source code: yarn-project/end-to-end/src/e2e_token_contract/transfer_in_public.test.ts#L69-L76
+
+
+Here you approve someone to transfer funds publicly on your behalf
+
+### Prevent the same user flow from happening twice using nullifiers
+
+E.g. you don't want a user to subscribe once they have subscribed already. Or you don't want them to vote twice once they have done that. How do you prevent this?
+
+Emit a nullifier in your function. By adding this nullifier into the tree, you prevent another nullifier from being added again. This is also why in authwit, we emit a nullifier, to prevent someone from reusing their approval.
+
+```rust title="verify_private_authwit" showLineNumbers
+pub fn verify_private_authwit(self, inner_hash: Field) -> Field {
+ // The `inner_hash` is "siloed" with the `msg_sender` to ensure that only it can
+ // consume the message.
+ // This ensures that contracts cannot consume messages that are not intended for them.
+ let message_hash = compute_authwit_message_hash(
+ self.context.msg_sender(),
+ self.context.chain_id(),
+ self.context.version(),
+ inner_hash,
+ );
+ let valid_fn = self.is_valid_impl;
+ assert(valid_fn(self.context, message_hash) == true, "Message not authorized by account");
+ IS_VALID_SELECTOR
+}
+```
+> Source code: noir-projects/aztec-nr/authwit/src/account.nr#L71-L86
+
+
+Note be careful to ensure that the nullifier is not deterministic and that no one could do a preimage analysis attack. More in [the anti pattern section on deterministic nullifiers](#deterministic-nullifiers)
+
+Note - you could also create a note and send it to the user. The problem is there is nothing stopping the user from not presenting this note when they next interact with the function.
+
+### Reading public storage in private
+
+You can read public storage in private domain by leveraging the private getters of `PublicImmutable` (for values that never change) and `SharedMutable` (for values that change infrequently, see [shared state](../../../../reference/smart_contract_reference/storage/shared_state.md) for details) state variables.
+Values that change frequently (`PublicMutable`) cannot be read in private as for those we need access to the tip of the chain and only a sequencer has access to that (and sequencer executes only public functions).
+
+E.g. when using `PublicImmutable`
+
+```rust
+#[storage]
+struct Storage {
+ config: PublicImmutable,
+}
+
+contract Bridge {
+
+ #[private]
+ fn burn_token_private(
+ token: AztecAddress, // pass token here since this is a private method but can't access public storage
+ amount: Field,
+ ) -> Field {
+ ...
+let config = storage.config.read();
+
+// Assert that user provided token address is same as seen in storage.
+assert_eq(config.token, token, "Token address is not the same as seen in storage");
+ }
+}
+```
+
+:::danger
+This leaks information about the private function being called and the data which has been read.
+:::
+
+### Writing public storage from private
+
+When calling a private function, you can update public state by calling a public function.
+
+In this situation, try to mark the public function as `internal`. This ensures your flow works as intended and that no one can call the public function without going through the private function first!
+
+### Moving public data into the private domain
+
+See [partial notes](../../../../../aztec/concepts/advanced/storage/partial_notes.md). Partial notes are how public balances are transferred to private [in the NFT contract](../../../../tutorials/codealong/contract_tutorials/nft_contract.md).
+
+### Discovering my notes
+
+When you send someone a note, the note hash gets added to the note hash tree. To spend the note, the receiver needs to get the note itself (the note hash preimage). There are two ways you can get a hold of your notes:
+
+1. When sending someone a note, emit the note log to the recipient (the function encrypts the log in such a way that only a recipient can decrypt it). PXE then tries to decrypt all the encrypted logs, and stores the successfully decrypted one. [More info here](../how_to_emit_event.md)
+2. Manually delivering it via a custom contract method, if you choose to not emit logs to save gas or when creating a note in the public domain and want to consume it in private domain (`encrypt_and_emit_note` shouldn't be called in the public domain because everything is public), like in the previous section where we created a note in public that doesn't have a designated owner.
+
+```typescript title="offchain_delivery" showLineNumbers
+const txEffects = await pxe.getTxEffect(txHash);
+await contract.methods
+ .deliver_transparent_note(
+ contract.address,
+ amount,
+ secretHash,
+ txHash.hash,
+ toBoundedVec(txEffects!.data.noteHashes, MAX_NOTE_HASHES_PER_TX),
+ txEffects!.data.nullifiers[0],
+ recipient,
+ )
+ .simulate();
+```
+> Source code: yarn-project/end-to-end/src/composed/e2e_persistence.test.ts#L364-L377
+
+
+Note that this requires your contract to have an unconstrained function that processes these notes and adds them to PXE.
+
+```rust title="deliver_note_contract_method" showLineNumbers
+unconstrained fn deliver_transparent_note(
+ contract_address: AztecAddress,
+ amount: u128,
+ secret_hash: Field,
+ tx_hash: Field,
+ unique_note_hashes_in_tx: BoundedVec,
+ first_nullifier_in_tx: Field,
+ recipient: AztecAddress,
+) {
+```
+> Source code: noir-projects/noir-contracts/contracts/token_blacklist_contract/src/main.nr#L301-L311
+
+
+### Revealing encrypted logs conditionally
+
+An encrypted log can contain any information for a recipient, typically in the form of a note. One could think this log is emitted as part of the transaction execution, so it wouldn't be revealed if the transaction fails.
+
+This is not true for Aztec, as the encrypted log is part of the transaction object broadcasted to the network. So if a transaction with an encrypted log and a note commitment is broadcasted, there could be a situation where the transaction is not mined or reorg'd out, so the commitment is never added to the note hash tree, but the recipient could still have read the encrypted log from the transaction in the mempool.
+
+Example:
+
+> Alice and Bob agree to a trade, where Alice sends Bob a passcode to collect funds from a web2 app, in exchange of on-chain tokens. Alice should only send Bob the passcode if the trade is successful. But just sending the passcode as an encrypted log doesn't work, since Bob could see the encrypted log from the transaction as soon as Alice broadcasts it, decrypt it to get the passcode, and withdraw his tokens from the trade to make the transaction fail.
+
+### Randomness in notes
+
+Notes are hashed and stored in the merkle tree. While notes do have a header with a `nonce` field that ensure two exact notes still can be added to the note hash tree (since hashes would be different), preimage analysis can be done to reverse-engineer the contents of the note.
+
+Hence, it's necessary to add a "randomness" field to your note to prevent such attacks.
+
+```rust title="address_note_def" showLineNumbers
+#[note]
+#[derive(Eq)]
+pub struct AddressNote {
+ address: AztecAddress,
+ owner: AztecAddress,
+ randomness: Field,
+}
+
+impl AddressNote {
+ pub fn new(address: AztecAddress, owner: AztecAddress) -> Self {
+ // Safety: we use the randomness to preserve the privacy of the note recipient by preventing brute-forcing, so a
+ // malicious sender could use non-random values to make the note less private. But they already know the full
+ // note pre-image anyway, and so the recipient already trusts them to not disclose this information. We can
+ // therefore assume that the sender will cooperate in the random value generation.
+ let randomness = unsafe { random() };
+ AddressNote { address, owner, randomness }
+ }
+}
+```
+> Source code: noir-projects/aztec-nr/address-note/src/address_note.nr#L5-L24
+
+
+### L1 -- L2 interactions
+
+Refer to [Token Portal codealong tutorial on bridging tokens between L1 and L2](../../../../tutorials/codealong/contract_tutorials/token_bridge.md) and/or [Uniswap smart contract example that shows how to swap on L1 using funds on L2](../../../../tutorials/codealong/contract_tutorials/uniswap/index.md). Both examples show how to:
+
+1. L1 -> L2 message flow
+2. L2 -> L1 message flow
+3. Cancelling messages from L1 -> L2.
+4. For both L1->L2 and L2->L1, how to operate in the private and public domain
+
+### Sending notes to a contract/Escrowing notes between several parties in a contract
+
+To send a note to someone, they need to have a key which we can encrypt the note with. But often contracts may not have a key. And even if they do, how does it make use of it autonomously?
+
+There are several patterns here:
+
+1. Give the contract a key and share it amongst all participants. This leaks privacy, as anyone can see all the notes in the contract.
+2. `transfer_to_public` funds into the contract - this is used in the [Uniswap smart contract example where a user sends private funds into a Uniswap Portal contract which eventually withdraws to L1 to swap on L1 Uniswap](../../../../tutorials/codealong/contract_tutorials/uniswap/index.md). This works like Ethereum - to achieve contract composability, you move funds into the public domain. This way the contract doesn't even need keys.
+
+There are several other designs we are discussing through [in this discourse post](https://discourse.aztec.network/t/how-to-handle-private-escrows-between-two-parties/2440) but they need some changes in the protocol or in our demo contract. If you are interested in this discussion, please participate in the discourse post!
+
+### Share Private Notes
+
+If you have private state that needs to be handled by more than a single user (but no more than a handful), you can add the note commitment to the note hash tree, and then encrypt the note once for each of the users that need to see it. And if any of those users should be able to consume the note, you can generate a random nullifier on creation and store it in the encrypted note, instead of relying on the user secret.
+
+## Anti Patterns
+
+There are mistakes one can make to reduce their privacy set and therefore make it trivial to do analysis and link addresses. Some of them are:
+
+### Passing along your address when calling a public function from private
+
+If you have a private function which calls a public function, remember that sequencer can see any parameters passed to the public function. So try to not pass any parameter that might leak privacy (e.g. `from` address)
+
+PS: when calling from private to public, `msg_sender` is the contract address which is calling the public function.
+
+### Deterministic nullifiers
+
+In the [Prevent the same user flow from happening twice using nullifier](#prevent-the-same-user-flow-from-happening-twice-using-nullifiers), we recommended using nullifiers. But what you put in the nullifier is also as important.
+
+E.g. for a voting contract, if your nullifier simply emits just the `user_address`, then privacy can easily be leaked via a preimage attack as nullifiers are deterministic (have no randomness), especially if there are few users of the contract. So you need some kind of randomness. You can add the user's secret key into the nullifier to add randomness. We call this "nullifier secrets" as explained [here](../../../../../aztec/concepts/accounts/keys.md#nullifier-keys).
+
+Here is an example from the voting contract:
+
+```rust title="cast_vote" showLineNumbers
+#[private]
+// annotation to mark function as private and expose private context
+fn cast_vote(candidate: Field) {
+ let msg_sender_npk_m_hash = get_public_keys(context.msg_sender()).npk_m.hash();
+
+ let secret = context.request_nsk_app(msg_sender_npk_m_hash); // get secret key of caller of function
+ let nullifier = std::hash::pedersen_hash([context.msg_sender().to_field(), secret]); // derive nullifier from sender and secret
+ context.push_nullifier(nullifier);
+ EasyPrivateVoting::at(context.this_address()).add_to_tally_public(candidate).enqueue(
+ &mut context,
+ );
+}
+```
+> Source code: noir-projects/noir-contracts/contracts/easy_private_voting_contract/src/main.nr#L38-L51
+
diff --git a/docs/versioned_docs/version-v0.82.2-alpha-testnet.5/developers/guides/smart_contracts/writing_contracts/how_to_emit_event.md b/docs/versioned_docs/version-v0.82.2-alpha-testnet.5/developers/guides/smart_contracts/writing_contracts/how_to_emit_event.md
new file mode 100644
index 000000000000..9fd1978f46be
--- /dev/null
+++ b/docs/versioned_docs/version-v0.82.2-alpha-testnet.5/developers/guides/smart_contracts/writing_contracts/how_to_emit_event.md
@@ -0,0 +1,91 @@
+---
+title: Emitting Events
+sidebar_position: 4
+tags: [contracts]
+---
+
+Events in Aztec work similarly to Ethereum events in the sense that they are a way for contracts to communicate with the outside world.
+They are emitted by contracts and stored inside each instance of an AztecNode.
+
+:::info
+Aztec events are currently represented as raw data and are not ABI encoded.
+ABI encoded events are a feature that will be added in the future.
+:::
+
+Unlike on Ethereum, there are 2 types of events supported by Aztec: [encrypted](#encrypted-events) and [unencrypted](#unencrypted-events).
+
+## Encrypted Events
+
+### Call emit
+
+To emit encrypted logs you can import the `encode_and_encrypt` or `encode_and_encrypt_with_keys` functions and pass them into the `emit` function after inserting a note. An example can be seen in the reference token contract's transfer function:
+
+```rust title="encrypted" showLineNumbers
+storage.balances.at(from).sub(from, amount).emit(encode_and_encrypt_note(
+ &mut context,
+ from,
+ from,
+));
+```
+> Source code: noir-projects/noir-contracts/contracts/token_contract/src/main.nr#L372-L378
+
+
+Furthermore, if not emitting the note, one should explicitly `discard` the value returned from the note creation.
+
+### Successfully process the encrypted event
+
+Contracts created using aztec-nr will try to discover newly created notes by searching for logs emitted for any of the accounts registered inside PXE, decrypting their contents and notifying PXE of any notes found. This process is automatic and occurs whenever a contract function is invoked.
+
+## Unencrypted Events
+
+Unencrypted events are events which can be read by anyone. They can be emitted **only** by public functions.
+
+### Call emit_public_log
+
+To emit public logs you don't need to import any library. You call the context method `emit_public_log`:
+
+```rust title="emit_public" showLineNumbers
+context.emit_public_log(/*message=*/ value);
+context.emit_public_log(/*message=*/ [10, 20, 30]);
+context.emit_public_log(/*message=*/ "Hello, world!");
+```
+> Source code: noir-projects/noir-contracts/contracts/test_contract/src/main.nr#L387-L391
+
+
+### Querying the unencrypted event
+
+Once emitted, unencrypted events are stored in AztecNode and can be queried by anyone:
+
+```typescript title="get_logs" showLineNumbers
+const fromBlock = await pxe.getBlockNumber();
+const logFilter = {
+ fromBlock,
+ toBlock: fromBlock + 1,
+};
+const publicLogs = (await pxe.getPublicLogs(logFilter)).logs;
+```
+> Source code: yarn-project/end-to-end/src/e2e_ordering.test.ts#L23-L30
+
+
+## Costs
+
+All event data is pushed to Ethereum as calldata by the sequencer and for this reason the cost of emitting an event is non-trivial.
+
+In the Sandbox, an encrypted note has a fixed overhead of 4 field elements (to broadcast an ephemeral public key, a contract address, and a storage slot); plus a variable number of field elements depending on the type of note being emitted.
+
+A `ValueNote`, for example, currently uses 3 fields elements (plus the fixed overhead of 4). That's roughly `7 * 32 = 224` bytes of information.
+
+```- title="value-note-def" showLineNumbers
+#[note]
+#[derive(Eq)]
+pub struct ValueNote {
+ value: Field,
+ owner: AztecAddress,
+ randomness: Field,
+}
+```
+> Source code: noir-projects/aztec-nr/value-note/src/value_note.nr#L3-L11
+
+
+- There are plans to compress encrypted note data further.
+- There are plans to adopt EIP-4844 blobs to reduce the cost of data submission further.
diff --git a/docs/versioned_docs/version-v0.82.2-alpha-testnet.5/developers/guides/smart_contracts/writing_contracts/how_to_prove_history.md b/docs/versioned_docs/version-v0.82.2-alpha-testnet.5/developers/guides/smart_contracts/writing_contracts/how_to_prove_history.md
new file mode 100644
index 000000000000..9e7c0e99d1ac
--- /dev/null
+++ b/docs/versioned_docs/version-v0.82.2-alpha-testnet.5/developers/guides/smart_contracts/writing_contracts/how_to_prove_history.md
@@ -0,0 +1,126 @@
+---
+title: Using the Archive Tree
+sidebar_position: 4
+tags: [contracts]
+---
+
+The Aztec Protocol uses an append-only Merkle tree to store hashes of the headers of all previous blocks in the chain as its leaves. This is known as the Archive tree.
+
+This page is a quick introductory guide to creating historical proofs proofs from the archive tree.
+
+For a reference, go [here](../../../reference/smart_contract_reference/aztec-nr/aztec/history/contract_inclusion.md).
+
+## Inclusion and non-inclusion proofs
+
+Inclusion and non-inclusion proofs refer to proving the inclusion (or absence) of a specific piece of information within a specific Aztec block with a block header. You can prove any of the following at a given block height before the current height:
+
+- Note inclusion
+- Nullifier inclusion
+- Note validity
+- Existence of public value
+- Contract inclusion
+
+Using this library, you can check that specific notes or nullifiers were part of Aztec network state at specific blocks. This can be useful for things such as:
+
+- Verifying a minimum timestamp from a private context
+- Checking eligibility based on historical events (e.g. for an airdrop by proving that you knew the nullifier key for a note)
+- Verifying historic ownership / relinquishing of assets
+- Proving existence of a value in public data tree at a given contract slot
+- Proving that a contract was deployed in a given block with some parameters
+
+**In this guide you will learn how to**
+
+- Prove a note was included in a specified block
+- Create a nullifier and prove it was not included in a specified block
+
+## Create a note to prove inclusion of
+
+In general you will likely have the note you want to prove inclusion of. But if you are just experimenting you can create a note with a function like below:
+
+```rust title="create_note" showLineNumbers
+#[private]
+fn call_create_note(
+ value: Field,
+ owner: AztecAddress,
+ sender: AztecAddress,
+ storage_slot: Field,
+) {
+ assert(
+ storage_slot
+ != aztec::state_vars::storage::Storage::get_storage_slot(storage.example_constant),
+ "this storage slot is reserved for example_constant",
+ );
+
+ let note = ValueNote::new(value, owner);
+ create_note(&mut context, storage_slot, note).emit(encode_and_encrypt_note(
+ &mut context,
+ owner,
+ sender,
+ ));
+}
+```
+> Source code: noir-projects/noir-contracts/contracts/test_contract/src/main.nr#L133-L154
+
+
+## Get the note from the PXE
+
+Retrieve the note from the user's PXE.
+
+```rust title="get_note_from_pxe" showLineNumbers
+let (retrieved_notes, _): (BoundedVec, MAX_NOTE_HASH_READ_REQUESTS_PER_CALL>, BoundedVec) =
+ get_notes(&mut context, storage_slot, options);
+```
+> Source code: noir-projects/noir-contracts/contracts/test_contract/src/main.nr#L169-L172
+
+
+In this example, we fetch notes located in the storage slot that we pass in from the function parameters. The notes also must match the criteria specified by the getter options that we declare and are able to customize.
+
+## Prove that a note was included in a specified block
+
+To prove that a note existed in a specified block, call `prove_note_inclusion` on the `header` as shown in this example:
+
+```rust title="prove_note_inclusion" showLineNumbers
+context.historical_header.prove_note_inclusion(retrieved_note, test::NOTE_STORAGE_SLOT);
+```
+> Source code: noir-projects/aztec-nr/aztec/src/history/note_inclusion/test.nr#L10-L12
+
+
+This will only prove the note existed at the specific block number, not whether or not the note has been nullified. You can prove that a note existed and had not been nullified in a specified block by using `prove_note_validity` on the block header which takes the following arguments:
+
+```rust title="prove_note_validity" showLineNumbers
+context.historical_header.prove_note_validity(retrieved_note, test::NOTE_STORAGE_SLOT, context);
+```
+> Source code: noir-projects/aztec-nr/aztec/src/history/note_validity/test.nr#L25-L27
+
+
+## Create a nullifier to prove inclusion of
+
+You can easily nullify a note like so:
+
+```rust title="nullify_note" showLineNumbers
+destroy_note_unsafe(&mut context, retrieved_note, note_hash);
+```
+> Source code: noir-projects/noir-contracts/contracts/test_contract/src/main.nr#L248-L250
+
+
+This function gets a note from the PXE and nullifies it with `remove()`.
+
+You can then compute this nullifier with `note.compute_nullifier(&mut context)`.
+
+## Prove that a nullifier was included in a specified block
+
+Call `prove_nullifier_inclusion` on a block header like so:
+
+```rust title="prove_nullifier_inclusion" showLineNumbers
+context.historical_header.prove_nullifier_inclusion(siloed_nullifier);
+```
+> Source code: noir-projects/aztec-nr/aztec/src/history/nullifier_inclusion/test.nr#L60-L62
+
+
+It takes the nullifier as an argument.
+
+You can also prove that a note was not nullified in a specified block by using `prove_note_not_nullified` which takes the note and a reference to the private context.
+
+## Prove contract inclusion, public value inclusion, and use current state in lookups
+
+To see what else you can do with historical proofs, check out the [reference](../../../reference/smart_contract_reference/aztec-nr/aztec/history/contract_inclusion.md)
diff --git a/docs/versioned_docs/version-v0.82.2-alpha-testnet.5/developers/guides/smart_contracts/writing_contracts/how_to_use_capsules.md b/docs/versioned_docs/version-v0.82.2-alpha-testnet.5/developers/guides/smart_contracts/writing_contracts/how_to_use_capsules.md
new file mode 100644
index 000000000000..79fcceb78f39
--- /dev/null
+++ b/docs/versioned_docs/version-v0.82.2-alpha-testnet.5/developers/guides/smart_contracts/writing_contracts/how_to_use_capsules.md
@@ -0,0 +1,68 @@
+---
+title: Using Capsules
+sidebar_position: 5
+tags: [functions, oracles]
+---
+
+Capsules are a per-contract non-volatile database.
+It can be used for storing arbitrary data that can be retrieved later.
+The data is stored locally in PXE and it is scoped per contract address, so external contracts cannot access it.
+The capsule (data stored under a storage slot in the capsules database) persists until explicitly deleted with `delete`.
+
+The capsules module provides these main functions:
+
+- `store` - Stores arbitrary data at a slot, overwriting any existing data
+- `load` - Retrieves previously stored data from a slot
+- `delete` - Deletes data at a slot
+- `copy` - Efficiently copies contiguous entries between slots
+
+### 1. Import capsules into your smart contract
+
+Import the capsules module:
+
+```rust title="import_capsules" showLineNumbers
+use dep::aztec::oracle::capsules;
+```
+> Source code: noir-projects/noir-contracts/contracts/contract_class_registerer_contract/src/main.nr#L38-L40
+
+
+### 2. Store and load data
+
+You can store any type that implements `Serialize` and `Deserialize`:
+
+```rust title="load_capsule" showLineNumbers
+let packed_public_bytecode: [Field; MAX_PACKED_PUBLIC_BYTECODE_SIZE_IN_FIELDS] = unsafe {
+ capsules::load(
+ context.this_address(),
+ REGISTERER_CONTRACT_BYTECODE_CAPSULE_SLOT,
+ )
+ .unwrap()
+};
+```
+> Source code: noir-projects/noir-contracts/contracts/contract_class_registerer_contract/src/main.nr#L50-L58
+
+
+The data is stored per contract address and slot. When loading, you'll get back an `Option` - `None` if no data exists at that slot.
+
+### 3. Copying data
+
+You can use `copy` to move contiguous entries between slots without repeated loads and stores.
+This supports overlapping source and destination regions.
+
+Note that all values are scoped per contract address, so external contracts cannot access them.
+
+### 4. Using CapsuleArray
+
+The `CapsuleArray` type provides a dynamically sized array backed by capsules.
+It handles the storage layout and management automatically.
+The array stores its length at a base slot, with elements stored in consecutive slots after it.
+
+Key functions:
+
+- `at(contract_address, base_slot)` - Creates/connects to an array at the given base slot
+- `len()` - Returns the number of elements in the array
+- `push(value)` - Appends a value to the end of the array
+- `get(index)` - Retrieves the value at the given index
+- `remove(index)` - Removes an element, shifting subsequent elements to maintain contiguous storage
+
+
\ No newline at end of file
diff --git a/docs/versioned_docs/version-v0.82.2-alpha-testnet.5/developers/guides/smart_contracts/writing_contracts/index.mdx b/docs/versioned_docs/version-v0.82.2-alpha-testnet.5/developers/guides/smart_contracts/writing_contracts/index.mdx
new file mode 100644
index 000000000000..5ee3b6efb6cb
--- /dev/null
+++ b/docs/versioned_docs/version-v0.82.2-alpha-testnet.5/developers/guides/smart_contracts/writing_contracts/index.mdx
@@ -0,0 +1,89 @@
+---
+title: Writing Contracts
+tags: [aztec.nr]
+---
+
+import DocCardList from "@theme/DocCardList";
+
+## Overview
+
+To write a contract:
+
+1. Import aztec.nr and declare your contract
+
+```rust
+mod test;
+use dep::aztec::macros::aztec;
+
+#[aztec]
+pub contract EasyPrivateVoting {
+```
+
+2. Define imports in your contract block
+
+```rust title="imports" showLineNumbers
+use dep::aztec::{
+ keys::getters::get_public_keys,
+ macros::{functions::{initializer, internal, private, public}, storage::storage},
+};
+use dep::aztec::prelude::{AztecAddress, Map, PublicImmutable, PublicMutable};
+use dep::aztec::protocol_types::traits::{Hash, ToField};
+```
+> Source code: noir-projects/noir-contracts/contracts/easy_private_voting_contract/src/main.nr#L8-L16
+
+
+3. Declare your contract storage below your imports
+
+```rust title="storage_struct" showLineNumbers
+#[storage]
+struct Storage {
+ admin: PublicMutable, // admin can end vote
+ tally: Map, Context>, // we will store candidate as key and number of votes as value
+ vote_ended: PublicMutable, // vote_ended is boolean
+ active_at_block: PublicImmutable, // when people can start voting
+}
+```
+> Source code: noir-projects/noir-contracts/contracts/easy_private_voting_contract/src/main.nr#L17-L25
+
+
+4. Declare a constructor with `#[initializer]`. Constructors can be private or public functions.
+
+```rust title="constructor" showLineNumbers
+#[public]
+#[initializer]
+// annotation to mark function as a constructor
+fn constructor(admin: AztecAddress) {
+ storage.admin.write(admin);
+ storage.vote_ended.write(false);
+ storage.active_at_block.initialize(context.block_number() as u32);
+}
+```
+> Source code: noir-projects/noir-contracts/contracts/easy_private_voting_contract/src/main.nr#L27-L36
+
+
+5. Declare your contract functions
+
+```rust title="cast_vote" showLineNumbers
+#[private]
+// annotation to mark function as private and expose private context
+fn cast_vote(candidate: Field) {
+ let msg_sender_npk_m_hash = get_public_keys(context.msg_sender()).npk_m.hash();
+
+ let secret = context.request_nsk_app(msg_sender_npk_m_hash); // get secret key of caller of function
+ let nullifier = std::hash::pedersen_hash([context.msg_sender().to_field(), secret]); // derive nullifier from sender and secret
+ context.push_nullifier(nullifier);
+ EasyPrivateVoting::at(context.this_address()).add_to_tally_public(candidate).enqueue(
+ &mut context,
+ );
+}
+```
+> Source code: noir-projects/noir-contracts/contracts/easy_private_voting_contract/src/main.nr#L38-L51
+
+
+There is a lot more detail and nuance to writing contracts, but this should give you a good starting point.
+Read contents of this section for more details about authorizing contract to act on your behalf (authenticaion witnesses),
+emitting events, calling functions on other contracts and other common patterns.
+
+## Section Contents
+
+
diff --git a/docs/versioned_docs/version-v0.82.2-alpha-testnet.5/developers/guides/smart_contracts/writing_contracts/initializers.md b/docs/versioned_docs/version-v0.82.2-alpha-testnet.5/developers/guides/smart_contracts/writing_contracts/initializers.md
new file mode 100644
index 000000000000..8d3d09b2269f
--- /dev/null
+++ b/docs/versioned_docs/version-v0.82.2-alpha-testnet.5/developers/guides/smart_contracts/writing_contracts/initializers.md
@@ -0,0 +1,61 @@
+---
+title: Defining Initializer Functions
+sidebar_position: 1
+tags: [functions, contracts]
+---
+
+This page explains how to write an initializer function, also known as a constructor.
+
+Initializers are regular functions that set an "initialized" flag (a nullifier) for the contract. A contract can only be initialized once, and contract functions can only be called after the contract has been initialized, much like a constructor. However, if a contract defines no initializers, it can be called at any time. Additionally, you can define as many initializer functions in a contract as you want, both private and public.
+
+## Annotate with `#[initializer]`
+
+Define your initializer like so:
+
+```rust
+#[initializer]
+fn constructor(){
+ // function logic here
+}
+```
+
+## Public or private
+
+Aztec supports both public and private initializers. Use the appropriate macro, for example for a private initializer:
+
+```rust
+#[private]
+#[initializer]
+fn constructor(){
+ // function logic here
+}
+```
+
+## Initializer with logic
+
+Initializers are commonly used to set an admin, such as this example:
+
+```rust title="constructor" showLineNumbers
+#[public]
+#[initializer]
+fn constructor(admin: AztecAddress, name: str<31>, symbol: str<31>, decimals: u8) {
+ assert(!admin.is_zero(), "invalid admin");
+ storage.admin.write(admin);
+ storage.minters.at(admin).write(true);
+ storage.name.initialize(FieldCompressedString::from_string(name));
+ storage.symbol.initialize(FieldCompressedString::from_string(symbol));
+ storage.decimals.initialize(decimals);
+}
+```
+> Source code: noir-projects/noir-contracts/contracts/token_contract/src/main.nr#L90-L103
+
+
+Here, the initializer is writing to storage. It can also call another function. Learn more about calling functions from functions [here](./call_contracts.md).
+
+## Multiple initializers
+
+You can set multiple functions as an initializer function simply by annotating each of them with `#[initializer]`. You can then decide which one to call when you are deploying the contract.
+
+Calling any one of the functions annotated with `#[initializer]` will mark the contract as initialized.
+
+To see an initializer in action, follow the [Counter codealong tutorial](../../../tutorials/codealong/contract_tutorials/counter_contract.md).
diff --git a/docs/versioned_docs/version-v0.82.2-alpha-testnet.5/developers/guides/smart_contracts/writing_contracts/notes/address_note.md b/docs/versioned_docs/version-v0.82.2-alpha-testnet.5/developers/guides/smart_contracts/writing_contracts/notes/address_note.md
new file mode 100644
index 000000000000..e0b7f03ea046
--- /dev/null
+++ b/docs/versioned_docs/version-v0.82.2-alpha-testnet.5/developers/guides/smart_contracts/writing_contracts/notes/address_note.md
@@ -0,0 +1,72 @@
+---
+title: Using Address Note in Aztec.nr
+tags: [contracts, notes]
+---
+
+Address notes hold one main property of the type `AztecAddress`. It also holds `owner` and `randomness`, similar to other note types.
+
+## AddressNote
+
+This is the AddressNote:
+
+```rust title="address_note_def" showLineNumbers
+#[note]
+#[derive(Eq)]
+pub struct AddressNote {
+ address: AztecAddress,
+ owner: AztecAddress,
+ randomness: Field,
+}
+
+impl AddressNote {
+ pub fn new(address: AztecAddress, owner: AztecAddress) -> Self {
+ // Safety: we use the randomness to preserve the privacy of the note recipient by preventing brute-forcing, so a
+ // malicious sender could use non-random values to make the note less private. But they already know the full
+ // note pre-image anyway, and so the recipient already trusts them to not disclose this information. We can
+ // therefore assume that the sender will cooperate in the random value generation.
+ let randomness = unsafe { random() };
+ AddressNote { address, owner, randomness }
+ }
+}
+```
+> Source code: noir-projects/aztec-nr/address-note/src/address_note.nr#L5-L24
+
+
+## Importing AddressNote
+
+### In Nargo.toml
+
+```toml
+address_note = { git="https://github.com/AztecProtocol/aztec-packages/", tag="v0.82.2", directory="noir-projects/aztec-nr/address-note" }
+```
+
+### In your contract
+
+```rust title="addressnote_import" showLineNumbers
+use dep::address_note::address_note::AddressNote;
+```
+> Source code: noir-projects/noir-contracts/contracts/escrow_contract/src/main.nr#L14-L16
+
+
+## Working with AddressNote
+
+### Creating a new note
+
+Creating a new `AddressNote` takes the following args:
+
+- `address` (`AztecAddress`): the address to store in the AddressNote
+- `owner` (`AztecAddress`): owner is the party whose nullifying key can be used to spend the note
+
+```rust title="addressnote_new" showLineNumbers
+let note = AddressNote::new(owner, owner);
+```
+> Source code: noir-projects/noir-contracts/contracts/escrow_contract/src/main.nr#L28-L30
+
+
+In this example, `owner` is the `address` and the `npk_m_hash` of the donor was computed earlier.
+
+## Learn more
+
+- [Keys, including nullifier keys and outgoing viewer](../../../../../aztec/concepts/accounts/keys.md)
+- [How to implement a note](./implementing_a_note.md)
+- [AddressNote reference](../../../../reference/smart_contract_reference/aztec-nr/address-note/address_note.md)
diff --git a/docs/versioned_docs/version-v0.82.2-alpha-testnet.5/developers/guides/smart_contracts/writing_contracts/notes/implementing_a_note.md b/docs/versioned_docs/version-v0.82.2-alpha-testnet.5/developers/guides/smart_contracts/writing_contracts/notes/implementing_a_note.md
new file mode 100644
index 000000000000..dac8f2b010ae
--- /dev/null
+++ b/docs/versioned_docs/version-v0.82.2-alpha-testnet.5/developers/guides/smart_contracts/writing_contracts/notes/implementing_a_note.md
@@ -0,0 +1,54 @@
+---
+title: Implementing a note in Aztec.nr
+tags: [contracts, notes]
+keywords: [implementing note, note]
+---
+
+You may want to create your own note type if you need to use a specific type of private data or struct that is not already implemented in Aztec.nr, or if you want to experiment with custom note hashing and nullifier schemes. For custom hashing and nullifier schemes, use the `#[custom_note]` macro instead of `#[note]`, as it does not automatically derive the `NoteHash` trait.
+
+For example, if you are developing a card game, you may want to store multiple pieces of data in each card. Rather than storing each piece of data in its own note, you can define a card note type that contains all the data, and then nullify (or exchange ownership of) the card when it has been used.
+
+If you want to work with values, addresses or integers, you can check out [ValueNote](./value_note.md), [AddressNote](./address_note.md) or `UintNote`.
+
+## Define a note type
+
+You will likely want to define your note in a new file and import it into your contract.
+
+A note type can be defined with the macro `#[note]` used on a struct:
+
+```rust title="state_vars-CardNote" showLineNumbers
+// We derive the Serialize trait because this struct is returned from a contract function. When returned,
+// the struct is serialized using the Serialize trait and added to a hasher via the `add_to_hasher` utility.
+// We use a hash rather than the serialized struct itself to keep circuit inputs constant.
+#[note]
+#[derive(Eq, Serialize)]
+pub struct CardNote {
+ points: u8,
+ randomness: Field,
+ owner: AztecAddress,
+}
+```
+> Source code: noir-projects/noir-contracts/contracts/docs_example_contract/src/types/card_note.nr#L3-L14
+
+
+In this example, we are implementing a card note that holds a number of `points` as `u8`.
+
+`randomness` is not enforced by the protocol and should be implemented by the application developer. If you do not include `randomness`, and the note preimage can be guessed by an attacker, it makes the note vulnerable to preimage attacks.
+
+`owner` is used when nullifying the note to obtain a nullifer secret key.
+It ensures that when a note is spent, only the owner can spend it and the note sender cannot figure out that the note has been spent!
+Providing the `owner` with improved privacy.
+
+Why is it delivering privacy from sender?
+
+Because a sender cannot derive a note nullifier.
+We could derive the nullifier based solely on the note itself (for example, by computing `hash([note.points, note.owner, note.randomness], NULLIFIER_SEPARATOR)`).
+This would work since the nullifier would be unique and only the note recipient could spend it (as contract logic typically only allows the note owner to obtain a note, e.g. from a `Map<...>`).
+However, if we did this, the sender could also derive the nullifier off-chain and monitor the nullifier tree for its inclusion, allowing them to determine when a note has been spent.
+This would leak privacy.
+
+## Further reading
+
+- [What is `#[note]` actually doing? + functions such as serialize() and deserialize()](../../../../../aztec/smart_contracts/functions/attributes.md#implementing-notes)
+- [Macros reference](../../../../reference/smart_contract_reference/macros.md)
+- [Keys, including npk_m_hash (nullifier public key master)](../../../../../aztec/concepts/accounts/keys.md)
diff --git a/docs/versioned_docs/version-v0.82.2-alpha-testnet.5/developers/guides/smart_contracts/writing_contracts/notes/index.md b/docs/versioned_docs/version-v0.82.2-alpha-testnet.5/developers/guides/smart_contracts/writing_contracts/notes/index.md
new file mode 100644
index 000000000000..c26dc38e0791
--- /dev/null
+++ b/docs/versioned_docs/version-v0.82.2-alpha-testnet.5/developers/guides/smart_contracts/writing_contracts/notes/index.md
@@ -0,0 +1,10 @@
+---
+title: Notes
+sidebar_position: 3
+tags: [contracts, notes]
+---
+
+Notes are the fundamental data structure in Aztec when working with private state. Using Aztec.nr, developers can define note types which allow flexibility in how notes are stored and nullified.
+
+In this section there are guides about how to work with `AddressNote`, `ValueNote` from Aztec.nr and how to implement your own notes.
+You can learn more about notes in the [concepts section](../../../../../aztec/concepts/storage/notes.md).
diff --git a/docs/versioned_docs/version-v0.82.2-alpha-testnet.5/developers/guides/smart_contracts/writing_contracts/notes/value_note.md b/docs/versioned_docs/version-v0.82.2-alpha-testnet.5/developers/guides/smart_contracts/writing_contracts/notes/value_note.md
new file mode 100644
index 000000000000..7857496368e9
--- /dev/null
+++ b/docs/versioned_docs/version-v0.82.2-alpha-testnet.5/developers/guides/smart_contracts/writing_contracts/notes/value_note.md
@@ -0,0 +1,95 @@
+---
+title: Using Value Notes in Aztec.nr
+tags: [contracts, notes]
+---
+
+ValueNotes hold one main property - a `value` - and have utils useful for manipulating this value, such as incrementing and decrementing it similarly to an integer.
+
+## ValueNote
+
+This is the ValueNote struct:
+
+```rust title="value-note-def" showLineNumbers
+#[note]
+#[derive(Eq)]
+pub struct ValueNote {
+ value: Field,
+ owner: AztecAddress,
+ randomness: Field,
+}
+```
+> Source code: noir-projects/aztec-nr/value-note/src/value_note.nr#L3-L11
+
+
+## Importing ValueNote
+
+### In Nargo.toml
+
+```toml
+value_note = { git="https://github.com/AztecProtocol/aztec-packages/", tag="v0.82.2", directory="noir-projects/aztec-nr/value-note" }
+```
+
+### In your contract
+
+```rust title="import_valuenote" showLineNumbers
+use dep::value_note::value_note::ValueNote;
+```
+> Source code: noir-projects/noir-contracts/contracts/child_contract/src/main.nr#L14-L16
+
+
+## Working with ValueNote
+
+### Creating a new note
+
+Creating a new `ValueNote` takes the following args:
+
+- `value` (`Field`): the value of the ValueNote
+- `owner` (`AztecAddress`): owner is the party whose nullifying key can be used to spend the note
+
+```rust title="valuenote_new" showLineNumbers
+let note = ValueNote::new(new_value, owner);
+```
+> Source code: noir-projects/noir-contracts/contracts/child_contract/src/main.nr#L60-L62
+
+
+### Getting a balance
+
+A user may have multiple notes in a set that all refer to the same content (e.g. a set of notes representing a single token balance). By using the `ValueNote` type to represent token balances, you do not have to manually add each of these notes and can instead use a helper function `get_balance()`.
+
+It takes one argument - the set of notes.
+
+```rust title="get_balance" showLineNumbers
+// Return the sum of all notes in the set.
+balance_utils::get_balance(owner_balance)
+```
+> Source code: noir-projects/noir-contracts/contracts/stateful_test_contract/src/main.nr#L104-L107
+
+
+This can only be used in an unconstrained function.
+
+### Incrementing and decrementing
+
+Both `increment` and `decrement` functions take the same args:
+
+```rust title="increment_args" showLineNumbers
+balance: PrivateSet,
+amount: Field,
+```
+> Source code: noir-projects/aztec-nr/value-note/src/utils.nr#L27-L30
+
+
+Note that this will create a new note in the set of notes passed as the first argument.
+For example:
+```rust title="increment_valuenote" showLineNumbers
+increment(storage.notes.at(owner), value, owner, sender);
+```
+> Source code: noir-projects/noir-contracts/contracts/benchmarking_contract/src/main.nr#L24-L26
+
+
+The `decrement` function works similarly except the `amount` is the number that the value will be decremented by, and it will fail if the sum of the selected notes is less than the amount.
+
+## Learn more
+
+- [Keys, including nullifier keys and outgoing viewer](../../../../../aztec/concepts/accounts/keys.md)
+- [How to implement a note](./implementing_a_note.md)
+- [ValueNote reference](../../../../reference/smart_contract_reference/aztec-nr/value-note/value_note.md)
diff --git a/docs/versioned_docs/version-v0.82.2-alpha-testnet.5/developers/guides/smart_contracts/writing_contracts/portals/communicate_with_portal.md b/docs/versioned_docs/version-v0.82.2-alpha-testnet.5/developers/guides/smart_contracts/writing_contracts/portals/communicate_with_portal.md
new file mode 100644
index 000000000000..5c6356344dfa
--- /dev/null
+++ b/docs/versioned_docs/version-v0.82.2-alpha-testnet.5/developers/guides/smart_contracts/writing_contracts/portals/communicate_with_portal.md
@@ -0,0 +1,381 @@
+---
+title: Communicating with L1
+tags: [contracts, portals]
+---
+
+Follow the [token bridge tutorial](../../../../../developers/tutorials/codealong/contract_tutorials/token_bridge.md) for hands-on experience writing and deploying a Portal contract.
+
+## Passing data to the rollup
+
+Whether it is tokens or other information being passed to the rollup, the portal should use the `Inbox` to do it.
+
+The `Inbox` can be seen as a mailbox to the rollup, portals put messages into the box, and the sequencer then consumes a batch of messages from the box and include it in their blocks.
+
+When sending messages, we need to specify quite a bit of information beyond just the content that we are sharing. Namely we need to specify:
+
+| Name | Type | Description |
+| ----------- | ------------------- | ------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- |
+| Recipient | `L2Actor` | The message recipient. This **MUST** match the rollup version and an Aztec contract that is **attached** to the contract making this call. If the recipient is not attached to the caller, the message cannot be consumed by it. |
+| Secret Hash | `field` (~254 bits) | A hash of a secret that is used when consuming the message on L2. Keep this preimage a secret to make the consumption private. To consume the message the caller must know the pre-image (the value that was hashed) - so make sure your app keeps track of the pre-images! Use `computeSecretHash` to compute it from a secret. |
+| Content | `field` (~254 bits) | The content of the message. This is the data that will be passed to the recipient. The content is limited to be a single field. If the content is small enough it can just be passed along, otherwise it should be hashed and the hash passed along (you can use our [`Hash` (GitHub link)](https://github.com/AztecProtocol/aztec-packages/blob/master/l1-contracts/src/core/libraries/Hash.sol) utilities with `sha256ToField` functions) |
+
+With all that information at hand, we can call the `sendL2Message` function on the Inbox. The function will return a `field` (inside `bytes32`) that is the hash of the message. This hash can be used as an identifier to spot when your message has been included in a rollup block.
+
+```solidity title="send_l1_to_l2_message" showLineNumbers
+/**
+ * @notice Inserts a new message into the Inbox
+ * @dev Emits `MessageSent` with data for easy access by the sequencer
+ * @param _recipient - The recipient of the message
+ * @param _content - The content of the message (application specific)
+ * @param _secretHash - The secret hash of the message (make it possible to hide when a specific message is consumed on L2)
+ * @return The key of the message in the set and its leaf index in the tree
+ */
+function sendL2Message(
+ DataStructures.L2Actor memory _recipient,
+ bytes32 _content,
+ bytes32 _secretHash
+) external returns (bytes32, uint256);
+```
+> Source code: l1-contracts/src/core/interfaces/messagebridge/IInbox.sol#L21-L35
+
+
+A sequencer will consume the message batch your message was included in and include it in their block.
+Upon inclusion, it is made available to be consumed on L2 via the L2 outbox.
+
+To consume the message, we can use the `consume_l1_to_l2_message` function within the `context` struct.
+
+- The `msg_key` is the hash of the message returned by the `sendL2Message` call and is used to help the RPC find the correct message.
+- The `content` is the content of the message, limited to one Field element. For content larger than one Field, we suggest using the `sha256` hash function truncated to a single Field element. `sha256` is suggested as it is cheap on L1 while still being manageable on L2.
+- The `secret` is the pre-image hashed using Pedersen to compute the `secretHash`.
+- If the `content` or `secret` does not match the entry at `msg_key` the message will not be consumed, and the transaction will revert.
+
+:::info
+Note that while the `secret` and the `content` are both hashed, they are actually hashed with different hash functions!
+:::
+
+```rust title="context_consume_l1_to_l2_message" showLineNumbers
+pub fn consume_l1_to_l2_message(
+ &mut self,
+ content: Field,
+ secret: Field,
+ sender: EthAddress,
+ leaf_index: Field,
+) {
+```
+> Source code: noir-projects/aztec-nr/aztec/src/context/private_context.nr#L300-L309
+
+
+### Token bridge example
+
+Computing the `content` must currently be done manually, as we are still adding a number of bytes utilities. A good example exists within the [Token bridge example (codealong tutorial)](../../../../../developers/tutorials/codealong/contract_tutorials/token_bridge.md).
+
+```rust title="claim_public" showLineNumbers
+// Consumes a L1->L2 message and calls the token contract to mint the appropriate amount publicly
+#[public]
+fn claim_public(to: AztecAddress, amount: u128, secret: Field, message_leaf_index: Field) {
+ let content_hash = get_mint_to_public_content_hash(to, amount);
+
+ let config = storage.config.read();
+
+ // Consume message and emit nullifier
+ context.consume_l1_to_l2_message(content_hash, secret, config.portal, message_leaf_index);
+
+ // Mint tokens
+ Token::at(config.token).mint_to_public(to, amount).call(&mut context);
+}
+```
+> Source code: noir-projects/noir-contracts/contracts/token_bridge_contract/src/main.nr#L57-L71
+
+
+:::info
+The `content_hash` is a sha256 truncated to a field element (~ 254 bits). In Aztec.nr, you can use our `sha256_to_field()` to do a sha256 hash which fits in one field element
+:::
+
+### Token portal hash library
+
+```rust title="mint_to_public_content_hash_nr" showLineNumbers
+use dep::aztec::prelude::{AztecAddress, EthAddress};
+use dep::aztec::protocol_types::{hash::sha256_to_field, traits::ToField};
+
+// Computes a content hash of a deposit/mint_to_public message.
+// Refer TokenPortal.sol for reference on L1.
+pub fn get_mint_to_public_content_hash(owner: AztecAddress, amount: u128) -> Field {
+ let mut hash_bytes = [0; 68];
+ let recipient_bytes: [u8; 32] = owner.to_field().to_be_bytes();
+ let amount_bytes: [u8; 32] = (amount as Field).to_be_bytes();
+
+ // The purpose of including the following selector is to make the message unique to that specific call. Note that
+ // it has nothing to do with calling the function.
+ let selector =
+ comptime { keccak256::keccak256("mint_to_public(bytes32,uint256)".as_bytes(), 31) };
+
+ for i in 0..4 {
+ hash_bytes[i] = selector[i];
+ }
+
+ for i in 0..32 {
+ hash_bytes[i + 4] = recipient_bytes[i];
+ hash_bytes[i + 36] = amount_bytes[i];
+ }
+
+ let content_hash = sha256_to_field(hash_bytes);
+ content_hash
+}
+```
+> Source code: noir-projects/noir-contracts/contracts/token_portal_content_hash_lib/src/lib.nr#L1-L29
+
+
+### Token Portal contract
+
+In Solidity, you can use our `Hash.sha256ToField()` method:
+
+```solidity title="content_hash_sol_import" showLineNumbers
+import {Hash} from "@aztec/core/libraries/crypto/Hash.sol";
+```
+> Source code: l1-contracts/test/portals/TokenPortal.sol#L12-L14
+
+
+```solidity title="deposit_public" showLineNumbers
+/**
+ * @notice Deposit funds into the portal and adds an L2 message which can only be consumed publicly on Aztec
+ * @param _to - The aztec address of the recipient
+ * @param _amount - The amount to deposit
+ * @param _secretHash - The hash of the secret consumable message. The hash should be 254 bits (so it can fit in a Field element)
+ * @return The key of the entry in the Inbox and its leaf index
+ */
+function depositToAztecPublic(bytes32 _to, uint256 _amount, bytes32 _secretHash)
+ external
+ returns (bytes32, uint256)
+```
+> Source code: l1-contracts/test/portals/TokenPortal.sol#L45-L56
+
+
+The `secret_hash` uses the pederson hash which fits in a field element. You can use the utility method `computeSecretHash()`in `@aztec/aztec.js` npm package to generate a secret and its corresponding hash.
+
+After the transaction has been mined, the message is consumed, a nullifier is emitted and the tokens have been minted on Aztec and are ready for claiming.
+
+Since the message consumption is emitting a nullifier, the same message cannot be consumed again. The index in the message tree is used as part of the nullifier computation, ensuring that the same content and secret being inserted will be distinct messages that can each be consumed. Without the index in the nullifier, it would be possible to perform a kind of attack known as `Faerie Gold` attacks where two seemingly good messages are inserted, but only one of them can be consumed later.
+
+## Passing data to L1
+
+To pass data to L1, we use the `Outbox`. The `Outbox` is the mailbox for L2 to L1 messages. This is the location on L1 where all the messages from L2 will live, and where they can be consumed from.
+
+:::danger
+
+Similarly to messages going to L2 from L1, a message can only be consumed by the specified recipient. But it is up to the portal contract to ensure that the sender is as expected! Any L2 contract can send a message to a portal contract on L1, but the portal contract should only consume messages from the expected sender.
+
+:::
+
+The portal must ensure that the sender is as expected. One flexible solution is to have an `initialize` function in the portal contract which can be used to set the address of the Aztec contract. In this model, the portal contract can check that the sender matches the value it has in storage.
+
+To send a message to L1 from your Aztec contract, you must use the `message_portal` function on the `context`. When messaging to L1, only the `content` is required (as a `Field`).
+
+```rust title="context_message_portal" showLineNumbers
+pub fn message_portal(&mut self, recipient: EthAddress, content: Field) {
+```
+> Source code: noir-projects/aztec-nr/aztec/src/context/private_context.nr#L293-L295
+
+
+When sending a message from L2 to L1 we don't need to pass in a secret.
+
+:::danger
+Access control on the L1 portal contract is essential to prevent consumption of messages sent from the wrong L2 contract.
+:::
+
+### Token bridge
+
+As earlier, we can use a token bridge as an example. In this case, we are burning tokens on L2 and sending a message to the portal to free them on L1.
+
+```rust title="exit_to_l1_private" showLineNumbers
+// Burns the appropriate amount of tokens and creates a L2 to L1 withdraw message privately
+// Requires `msg.sender` (caller of the method) to give approval to the bridge to burn tokens on their behalf using witness signatures
+#[private]
+fn exit_to_l1_private(
+ token: AztecAddress,
+ recipient: EthAddress, // ethereum address to withdraw to
+ amount: u128,
+ caller_on_l1: EthAddress, // ethereum address that can call this function on the L1 portal (0x0 if anyone can call)
+ nonce: Field, // nonce used in the approval message by `msg.sender` to let bridge burn their tokens on L2
+) {
+ let config = storage.config.read();
+
+ // Assert that user provided token address is same as seen in storage.
+ assert_eq(config.token, token, "Token address is not the same as seen in storage");
+
+ // Send an L2 to L1 message
+ let content = get_withdraw_content_hash(recipient, amount, caller_on_l1);
+ context.message_portal(config.portal, content);
+
+ // Burn tokens
+ Token::at(token).burn_private(context.msg_sender(), amount, nonce).call(&mut context);
+}
+```
+> Source code: noir-projects/noir-contracts/contracts/token_bridge_contract/src/main.nr#L125-L150
+
+
+When the transaction is included in a rollup block and published to Ethereum the message will be inserted into the `Outbox` on Ethereum, where the recipient portal can consume it from. When consuming, the `msg.sender` must match the `recipient` meaning that only portal can actually consume the message.
+
+```solidity title="l2_to_l1_msg" showLineNumbers
+/**
+ * @notice Struct containing a message from L2 to L1
+ * @param sender - The sender of the message
+ * @param recipient - The recipient of the message
+ * @param content - The content of the message (application specific) padded to bytes32 or hashed if larger.
+ * @dev Not to be confused with L2ToL1Message in Noir circuits
+ */
+struct L2ToL1Msg {
+ DataStructures.L2Actor sender;
+ DataStructures.L1Actor recipient;
+ bytes32 content;
+}
+```
+> Source code: l1-contracts/src/core/libraries/DataStructures.sol#L53-L66
+
+
+#### Outbox `consume`
+
+```solidity title="outbox_consume" showLineNumbers
+/**
+ * @notice Consumes an entry from the Outbox
+ * @dev Only useable by portals / recipients of messages
+ * @dev Emits `MessageConsumed` when consuming messages
+ * @param _message - The L2 to L1 message
+ * @param _l2BlockNumber - The block number specifying the block that contains the message we want to consume
+ * @param _leafIndex - The index inside the merkle tree where the message is located
+ * @param _path - The sibling path used to prove inclusion of the message, the _path length directly depends
+ * on the total amount of L2 to L1 messages in the block. i.e. the length of _path is equal to the depth of the
+ * L1 to L2 message tree.
+ */
+function consume(
+ DataStructures.L2ToL1Msg calldata _message,
+ uint256 _l2BlockNumber,
+ uint256 _leafIndex,
+ bytes32[] calldata _path
+) external;
+```
+> Source code: l1-contracts/src/core/interfaces/messagebridge/IOutbox.sol#L35-L53
+
+
+#### Withdraw
+
+As noted earlier, the portal contract should check that the sender is as expected. In the example below, we support only one sender contract (stored in `l2TokenAddress`) so we can just pass it as the sender, that way we will only be able to consume messages from that contract.
+
+It is possible to support multiple senders from L2. You could use a have `mapping(address => bool) allowed` and check that `allowed[msg.sender]` is `true`.
+
+```solidity title="token_portal_withdraw" showLineNumbers
+/**
+ * @notice Withdraw funds from the portal
+ * @dev Second part of withdraw, must be initiated from L2 first as it will consume a message from outbox
+ * @param _recipient - The address to send the funds to
+ * @param _amount - The amount to withdraw
+ * @param _withCaller - Flag to use `msg.sender` as caller, otherwise address(0)
+ * @param _l2BlockNumber - The address to send the funds to
+ * @param _leafIndex - The amount to withdraw
+ * @param _path - Flag to use `msg.sender` as caller, otherwise address(0)
+ * Must match the caller of the message (specified from L2) to consume it.
+ */
+function withdraw(
+ address _recipient,
+ uint256 _amount,
+ bool _withCaller,
+ uint256 _l2BlockNumber,
+ uint256 _leafIndex,
+ bytes32[] calldata _path
+) external {
+ // The purpose of including the function selector is to make the message unique to that specific call. Note that
+ // it has nothing to do with calling the function.
+ DataStructures.L2ToL1Msg memory message = DataStructures.L2ToL1Msg({
+ sender: DataStructures.L2Actor(l2Bridge, 1),
+ recipient: DataStructures.L1Actor(address(this), block.chainid),
+ content: Hash.sha256ToField(
+ abi.encodeWithSignature(
+ "withdraw(address,uint256,address)",
+ _recipient,
+ _amount,
+ _withCaller ? msg.sender : address(0)
+ )
+ )
+ });
+
+ IOutbox outbox = IRollup(registry.getRollup()).getOutbox();
+
+ outbox.consume(message, _l2BlockNumber, _leafIndex, _path);
+
+ underlying.transfer(_recipient, _amount);
+}
+```
+> Source code: l1-contracts/test/portals/TokenPortal.sol#L114-L155
+
+
+## Considerations
+
+### Structure of messages
+
+Application developers should consider creating messages that follow a function call structure e.g., using a function signature and arguments. This will make it easier to prevent producing messages that could be misinterpreted by the recipient.
+
+An example of a bad format would be using `amount, token_address, recipient_address` as the message for a withdraw function and `amount, token_address, on_behalf_of_address` for a deposit function. Any deposit could then also be mapped to a withdraw or vice versa.
+
+```solidity
+// Don't to this!
+bytes memory message = abi.encode(
+ _amount,
+ _token,
+ _to
+);
+
+// Do this!
+bytes memory message abi.encodeWithSignature(
+ "withdraw(uint256,address,address)",
+ _amount,
+ _token,
+ _to
+);
+```
+
+### Error Handling
+
+Handling error when moving cross chain can quickly get tricky. Since the L1 and L2 calls are async and independent of each other, the L1 part of a deposit might execute just fine, with the L2 part failing. If this is not handled well, the funds may be lost forever! Developers should consider ways their application can fail cross chain, and handle all cases explicitly.
+
+First, entries in the outboxes **SHOULD** only be consumed if the execution is successful. For an L2 -> L1 call, the L1 execution can revert the transaction completely if anything fails. As the tx is atomic, the failure also reverts consumption.
+
+If it is possible to enter a state where the second part of the execution fails forever, the application builder should consider including additional failure mechanisms (for token withdraws this could be depositing them again etc).
+
+Generally it is good practice to keep cross-chain calls simple to avoid too many edge cases and state reversions.
+
+:::info
+Error handling for cross chain messages is handled by the application contract and not the protocol. The protocol only delivers the messages, it does not ensure that they are executed successfully.
+:::
+
+### Designated caller
+
+Designating a caller grants the ability to specify who should be able to call a function that consumes a message. This is useful for ordering of batched messages.
+
+When performing multiple cross-chain calls in one action it is important to consider the order of the calls. Say for example, that you want to perform a uniswap trade on L1. You would withdraw funds from the rollup, swap them on L1, and then deposit the swapped funds back into the rollup. This is a straightforward process, but it requires that the calls are done in the correct order (e.g. if the swap is called before the funds are withdrawn, the swap will fail).
+
+The message boxes (Inbox and Outbox) will only allow the recipient portal to consume the message, and we can use this to ensure that the calls are done in the correct order. Say that we include a designated "caller" in the messages, and that the portal contract checks that the caller matches the designated caller or designated as `address(0)` (if anyone can call). When the messages are to be consumed on L1, it can compute the message as seen below:
+
+```solidity
+bytes memory message = abi.encodeWithSignature(
+ "withdraw(uint256,address,address)",
+ _amount,
+ _to,
+ _withCaller ? msg.sender : address(0)
+);
+```
+
+This way, the message can be consumed by the portal contract, but only if the caller is the specified caller. In the logic of the contract that is the designated caller, we can ensure that the calls are done in the correct order.
+
+For example, we could require that the Uniswap portal is the caller of the withdrawal, and ensure that the uniswap portal contract implementation is executing the withdrawal before the swap.
+The order of execution can be specified in the contract. Since all of the messages are emitted to L1 in the same transaction, we can leverage transaction atomicity to ensure success of failure of all messages.
+
+Note, that crossing the L1/L2 chasm is asynchronous, so there could be a situation where the user has burned their assets on L2 but the swap fails on L1! This could be due to major price movements for example. In such a case, the user could be stuck with funds on L1 that they cannot get back to L2 unless the portal contract implements a way to properly handle such errors.
+
+:::caution
+Designated callers are enforced at the contract level for contracts that are not the rollup itself, and should not be trusted to implement the contract correctly. The user should always be aware that it is possible for the developer to implement something that looks like designated caller without providing the abilities to the user.
+:::
+
+## Examples of portals
+
+- Token bridge (Portal contract built for L1 -> L2, i.e., a non-native L2 asset)
+ - [Portal contract (GitHub link)](https://github.com/AztecProtocol/aztec-packages/blob/v0.82.2/l1-contracts/test/portals/TokenPortal.sol)
+ - [Aztec contract (GitHub link)](https://github.com/AztecProtocol/aztec-packages/blob/v0.82.2/noir-projects/noir-contracts/contracts/token_bridge_contract/src/main.nr)
diff --git a/docs/versioned_docs/version-v0.82.2-alpha-testnet.5/developers/guides/smart_contracts/writing_contracts/portals/index.md b/docs/versioned_docs/version-v0.82.2-alpha-testnet.5/developers/guides/smart_contracts/writing_contracts/portals/index.md
new file mode 100644
index 000000000000..d9292f2848e8
--- /dev/null
+++ b/docs/versioned_docs/version-v0.82.2-alpha-testnet.5/developers/guides/smart_contracts/writing_contracts/portals/index.md
@@ -0,0 +1,6 @@
+---
+title: Portals
+sidebar_position: 7
+---
+
+A portal is a point of contact between L1 and a contract on Aztec. For applications such as token bridges, this is the point where the tokens are held on L1 while used in L2. Note, that a portal doesn't actually need to be a contract, it could be any address on L1.
diff --git a/docs/versioned_docs/version-v0.82.2-alpha-testnet.5/developers/guides/smart_contracts/writing_contracts/storage/index.md b/docs/versioned_docs/version-v0.82.2-alpha-testnet.5/developers/guides/smart_contracts/writing_contracts/storage/index.md
new file mode 100644
index 000000000000..622df9645037
--- /dev/null
+++ b/docs/versioned_docs/version-v0.82.2-alpha-testnet.5/developers/guides/smart_contracts/writing_contracts/storage/index.md
@@ -0,0 +1,21 @@
+---
+title: Declaring Storage
+sidebar_position: 2
+tags: [contracts, storage]
+---
+
+On this page, you will learn how to define storage in your smart contract.
+
+To learn more about how storage works in Aztec, read [the concepts](./storage_slots.md).
+
+[See the storage reference](../../../../reference/smart_contract_reference/storage/index.md).
+
+```rust
+#[storage]
+struct Storage {
+ // public state variables
+ // private state variables
+}
+```
+
+If you have defined a struct and annotated it as `#[storage]`, then it will be made available to you through the reserved `storage` keyword within your contract functions.
diff --git a/docs/versioned_docs/version-v0.82.2-alpha-testnet.5/developers/guides/smart_contracts/writing_contracts/storage/notes.md b/docs/versioned_docs/version-v0.82.2-alpha-testnet.5/developers/guides/smart_contracts/writing_contracts/storage/notes.md
new file mode 100644
index 000000000000..622c215463a2
--- /dev/null
+++ b/docs/versioned_docs/version-v0.82.2-alpha-testnet.5/developers/guides/smart_contracts/writing_contracts/storage/notes.md
@@ -0,0 +1,169 @@
+---
+title: Writing Notes
+description: Core knowledge of Notes and how they work
+useful-for: dev
+tags: [contracts, storage, notes]
+---
+
+Most prominent blockchain networks don't have privacy at the protocol level. Aztec contracts can define public and private functions, that can read/write public and private state.
+
+To be clear, "private" here is referring to the opposite of how things work on a public blockchain network, not the conventional syntax for visibility within code.
+
+For private state we need encryption and techniques to hide information about state changes. For private functions, we need local execution and proof of correct execution.
+
+### Some context
+
+- Public functions and storage work much like other blockchains in terms of having dedicated storage slots and being publicly visible
+- Private functions are executed locally with proofs generated for sound execution, and commitments to private variable updates are stored using append-only trees
+- "Note" types are part of Aztec.nr, a framework that facilitates use of Aztec's different storage trees to achieve things such as private variables
+
+This page will focus on how private variables are implemented with Notes and storage trees.
+
+#### Side-note about execution
+
+Under the hood, the Aztec protocol handles some important details around public and private function calls. Calls between them are asynchronous due to different execution contexts (local execution vs. node execution).
+A detailed explanation of the transaction lifecycle can be found [here](../../../../../aztec/concepts/transactions.md#simple-example-of-the-private-transaction-lifecycle).
+
+## Private state variables in Aztec
+
+State variables in an Aztec contract are defined inside a struct specifically named `Storage`, and must satisfy the [Note Interface (GitHub link)](https://github.com/AztecProtocol/aztec-packages/tree/v0.82.2/noir-projects/aztec-nr/aztec/src/note/note_interface.nr) and contain a [Note header (GitHub link)](https://github.com/AztecProtocol/aztec-packages/tree/v0.82.2/noir-projects/aztec-nr/aztec/src/note/note_header.nr).
+
+The Note header struct contains the contract address which the value is effectively siloed to, a nonce to ensure unique Note hashes, and a storage "slot" (or ID) to associate multiple notes.
+
+A couple of things to unpack here:
+
+#### Storage "slot"
+
+Storage slots are more literal for public storage, a place where a value is stored. For private storage, a storage slot is logical (more [here](../../../../../aztec/concepts/advanced/storage/storage_slots.md)).
+
+#### Silos
+
+The address of the contract is included in a Note's data to ensure that different contracts don't arrive at the same hash with an identical variable. This is handled in the protocol's execution.
+
+### Note types
+
+There is more than one Note type, such as the `PrivateSet` type is used for private variables. There are also `PrivateMutable` and `PrivateImmutable` types.
+
+Furthermore, notes can be completely custom types, storing any value or set of values that are desired by an application.
+
+### Initialization
+
+Private state variables are stored locally when the contract is created. Depending on the application, values may be privately shared by the creator with others via encrypted logs onchain.
+A hash of a note is stored in the append-only note hash tree on the network so as to prove existence of the current state of the note in a privacy preserving way.
+
+#### Note Hash Tree
+
+By virtue of being append only, notes are not edited. If two transactions amend a private value, multiple notes will be inserted into the tree to the note hash tree and the nullifier tree. The header will contain the same logical storage slot.
+
+### Reading Notes
+
+:::info
+
+Only those with appropriate keys/information will be able to successfully read private values that they have permission to. Notes can be read outside of a transaction or "off-chain" with no changes to data structures on-chain.
+
+:::
+
+When a note is read in a transaction, a subsequent read from another transaction of the same note would reveal a link between the two. So to preserve privacy, notes that are read in a transaction are said to be "consumed" (defined below), and new note(s) are then created with a unique hash.
+
+With type `PrviateSet`, a private variable's value is interpreted as the sum of values of notes with the same logical storage slot.
+
+Consuming, deleting, or otherwise "nullifying" a note is NOT done by deleting the Note hash; this would leak information. Rather a nullifier is created deterministically linked to the value. This nullifier is inserted into another the nullifier storage tree.
+
+When reading a value, the local private execution checks that its notes (of the corresponding storage slot/ID) have not been nullified.
+
+### Updating
+
+:::note
+Only those with appropriate keys/information will be able to successfully nullify a value that they have permission to.
+:::
+
+To update a value, its previous note hash(es) are nullified. The new note value is updated in the user's private execution environment (PXE), and the updated note hash inserted into the note hash tree.
+
+## Supplementary components
+
+Some optional background resources on notes can be found here:
+
+- [High level network architecture](../../../../../aztec/index.md), specifically the Private Execution Environment
+- [Transaction lifecycle (simple diagram)](../../../../../aztec/concepts/transactions.md#simple-example-of-the-private-transaction-lifecycle)
+- [Public and Private state](../../../../../aztec/concepts/storage/state_model.md)
+
+Notes touch several core components of the protocol, but we will focus on a the essentials first.
+
+### Some code context
+
+The way Aztec benefits from the Noir language is via three important components:
+
+- `Aztec.nr` - a Noir framework enabling contracts on Aztec, written in Noir. Includes useful Note implementations
+- `noir contracts` - example Aztec contracts
+- `noir-protocol-circuits` - a crate containing essential circuits for the protocol (public circuits and private wrappers)
+
+A lot of what we will look at will be in [aztec-nr/aztec/src/note (GitHub link)](https://github.com/AztecProtocol/aztec-packages/tree/v0.82.2/noir-projects/aztec-nr/aztec/src/note), specifically the lifecycle and note interface.
+
+Looking at the noir circuits in these components, you will see references to the distinction between public/private execution and state.
+
+### Lifecycle functions
+
+Inside the [lifecycle (GitHub link)](https://github.com/AztecProtocol/aztec-packages/tree/v0.82.2/noir-projects/aztec-nr/aztec/src/note/lifecycle.nr) circuits we see the functions to create and destroy a note, implemented as insertions of note hashes and nullifiers respectively. This is helpful for regular private variables.
+
+We also see a function to create a note hash from the public context, a way of creating a private variable from a public call (run in the sequencer). This could be used in application contracts to give private digital assets to users.
+
+### Note Interface functions
+
+To see a [note_interface (GitHub link)](https://github.com/AztecProtocol/aztec-packages/tree/v0.82.2/noir-projects/aztec-nr/aztec/src/note/note_interface.nr) implementation, we will look at a simple [ValueNote GitHub link](https://github.com/AztecProtocol/aztec-packages/tree/v0.82.2/noir-projects/aztec-nr/value-note/src/value_note.nr).
+
+The interface is required to work within an Aztec contract's storage, and a ValueNote is a specific type of note to hold a number (as a `Field`).
+
+#### Computing hashes and nullifiers
+
+A few key functions in the note interface are around computing the note hash and nullifier, with logic to get/use secret keys from the private context.
+
+In the ValueNote implementation you'll notice that it uses the `pedersen_hash` function. This is currently required by the protocol, but may be updated to another hashing function, like poseidon.
+
+As a convenience, the outer [note/utils.nr (GitHub link)](https://github.com/AztecProtocol/aztec-packages/tree/v0.82.2/noir-projects/aztec-nr/aztec/src/note/utils.nr) contains implementations of functions that may be needed in Aztec contracts, for example computing note hashes.
+
+#### Serialization and deserialization
+
+Serialization/deserialization of content is used to convert between the Note's variables and a generic array of Field elements. The Field type is understood and used by lower level crypographic libraries.
+This is analogous to the encoding/decoding between variables and bytes in solidity.
+
+For example in ValueNote, the `serialize_content` function simply returns: the value, nullifying public key hash (as a field) and the note randomness; as an array of Field elements.
+
+### Value as a sum of Notes
+
+We recall that multiple notes are associated with a "slot" (or ID), and so the value of a numerical note (like ValueNote) is the sum of each note's value.
+The helper function in [balance_utils (GitHub link)](https://github.com/AztecProtocol/aztec-packages/blob/#include_/noir-projects/aztec-nr/value-note/src/balance_utils.nr) implements this logic taking a `PrivateSet` of `ValueNotes`.
+
+A couple of things worth clarifying:
+
+- A `PrivateSet` takes a Generic type, specified here as `ValueNote`, but can be any `Note` type (for all notes in the set)
+- A `PrivateSet` of notes also specifies _the_ slot of all Notes that it holds
+
+### Example - Notes in action
+
+The Aztec.nr framework includes examples of high-level states [easy_private_uint (GitHub link)](https://github.com/AztecProtocol/aztec-packages/tree/v0.82.2/noir-projects/aztec-nr/easy-private-state/src/easy_private_uint.nr) for use in contracts.
+
+The struct (`EasyPrivateUint`) contains a Context, Set of ValueNotes, and storage_slot (used when setting the Set).
+
+Notice how the `add` function shows the simplicity of appending a new note to all existing ones. On the other hand, `sub` (subtraction), needs to first add up all existing values (consuming them in the process), and then insert a single new value of the difference between the sum and parameter.
+
+---
+
+### Apply
+
+Try the [NFT tutorial](../../../../tutorials/codealong/contract_tutorials/nft_contract.md) to see what notes can achieve. In this section you will also find other tutorials using notes in different ways.
+
+### Further reading
+
+- [Proof of prior notes](../how_to_prove_history.md) - public/private reading of public/private proof of state (public or private)
+
+If you're curious about any of the following related topics, search the documentation for...
+
+- Private and public contexts
+- Encryption keys and events
+- Oracle's role in using notes
+- Value Serialization/Deserialization
+
+### References
+
+- ["Stable" state variable (GitHub link)](https://github.com/AztecProtocol/aztec-packages/issues/4130)
+- [Code: Aztec-Patterns (GitHub link)](https://github.com/defi-wonderland/aztec-patterns)
diff --git a/docs/versioned_docs/version-v0.82.2-alpha-testnet.5/developers/guides/smart_contracts/writing_contracts/storage/storage_slots.md b/docs/versioned_docs/version-v0.82.2-alpha-testnet.5/developers/guides/smart_contracts/writing_contracts/storage/storage_slots.md
new file mode 100644
index 000000000000..194a5ef24a92
--- /dev/null
+++ b/docs/versioned_docs/version-v0.82.2-alpha-testnet.5/developers/guides/smart_contracts/writing_contracts/storage/storage_slots.md
@@ -0,0 +1,69 @@
+---
+title: Storage slots
+tags: [contracts, storage]
+---
+
+From the description of storage slots [in the Concepts](../../../../../aztec/concepts/advanced/storage/storage_slots.md) you will get an idea around the logic of storage slots. In this section we will go into more detail and walk through an entire example of how storage slots are computed for private state to improve our storage slot intuition. Recall, that storage slots in the private domain is just a logical construct, and are not "actually" used for lookups, but rather just as a value to constrain against.
+
+For the case of the example, we will look at what is inserted into the note hashes tree when adding a note in the Token contract. Specifically, we are looking at the last part of the `transfer` function:
+
+```rust title="increase_private_balance" showLineNumbers
+storage.balances.at(from).sub(from, amount).emit(encode_and_encrypt_note(
+ &mut context,
+ from,
+ from,
+));
+```
+> Source code: noir-projects/noir-contracts/contracts/token_contract/src/main.nr#L371-L379
+
+
+This function is creating a new note and inserting it into the balance set of the recipient `to`. Recall that to ensure privacy, only the note hash is really inserted into the note hashes tree. To share the contents of the note with `to` the contract can emit an encrypted log (which this one does), or it can require an out-of-band data transfer sharing the information. Below, we will walk through the steps of how the note hash is computed and inserted into the tree. For this, we don't care about the encrypted log, so we are going to ignore that part of the function call for now.
+
+Outlining it in more detail below as a sequence diagram, we can see how the calls make their way down the stack.
+In the end a siloed note hash is computed in the kernel.
+
+:::info
+Some of the syntax below is a little butchered to make it easier to follow variables without the full code.
+:::
+
+```mermaid
+sequenceDiagram
+ alt Call
+ Token->>BalanceMap: Map::new(map_slot);
+ Token->>Token: to_bal = storage.balances.at(to)
+ Token->>BalanceMap: BalanceMap.at(to)
+ BalanceMap->>BalanceMap: derived_slot = H(map_slot, to)
+ BalanceMap->>BalanceSet: BalanceSet::new(to, derived_slot)
+ Token->>BalanceSet: to_bal.add(amount)
+ BalanceSet->>BalanceSet: note = UintNote::new(amount, to)
+ BalanceSet->>Set: insert(note)
+ Set->>LifeCycle: create_note(derived_slot, note)
+ LifeCycle->>LifeCycle: note.header = NoteHeader { contract_address, storage_slot: derived_slot, nonce: 0, note_hash_counter }
+ Utils->>UintNote: note_hiding_point = note.compute_note_hiding_point()
+ UintNote->>Utils: note_hash = note_hiding_point.x
+ LifeCycle->>Context: push_note_hash(note_hash)
+ end
+ Context->>Kernel: unique_note_hash = H(nonce, note_hash)
+ Context->>Kernel: siloed_note_hash = H(contract_address, unique_note_hash)
+```
+
+Notice the `siloed_note_hash` at the very end. It's a hash that will be inserted into the note hashes tree. To clarify what this really is, we "unroll" the values to their simplest components. This gives us a better idea around what is actually inserted into the tree.
+
+```rust
+siloed_note_hash = H(contract_address, unique_note_hash)
+siloed_note_hash = H(contract_address, H(nonce, note_hash))
+siloed_note_hash = H(contract_address, H(H(tx_hash, note_index_in_tx), note_hash))
+siloed_note_hash = H(contract_address, H(H(tx_hash, note_index_in_tx), MSM([G_amt, G_to, G_rand, G_slot], [amount, to, randomness, derived_slot]).x))
+```
+
+MSM is a multi scalar multiplication on a grumpkin curve and G_* values are generators.
+
+And `to` is the actor who receives the note, `amount` of the note and `randomness` is the randomness used to make the note hiding. Without the `randomness` the note could just as well be plaintext (computational cost of a preimage attack would be trivial in such a case).
+
+:::info
+Beware that this hash computation is what the aztec.nr library is doing, and not strictly required by the network (only the kernel computation is).
+:::
+
+With this note structure, the contract can require that only notes sitting at specific storage slots can be used by specific operations, e.g., if transferring funds from `from` to `to`, the notes to destroy should be linked to `H(map_slot, from)` and the new notes (except the change-note) should be linked to `H(map_slot, to)`.
+
+That way, we can have logical storage slots, without them really existing. This means that knowing the storage slot for a note is not enough to actually figure out what is in there (whereas it would be for looking up public state).
diff --git a/docs/versioned_docs/version-v0.82.2-alpha-testnet.5/developers/index.md b/docs/versioned_docs/version-v0.82.2-alpha-testnet.5/developers/index.md
new file mode 100644
index 000000000000..aa692db11222
--- /dev/null
+++ b/docs/versioned_docs/version-v0.82.2-alpha-testnet.5/developers/index.md
@@ -0,0 +1,79 @@
+---
+id: index
+sidebar_position: 0
+title: Build
+---
+
+# Build
+
+## Get Started
+
+
+
+
+
Getting Started
+
+
+ Get started on Aztec by installing the sandbox and playing with it
+
+
+
+
+## Build applications
+
+
+
+
+
Contract Tutorials
+
+
+ Go from zero to hero by following these tutorials in order, starting with a counter contract
+
+
+
+
+
+
Full stack app on Aztec
+
+
+ Learn how everything works together by building an app in JavaScript that connects to a contract
+
+
+
+
+
+ Learn how everything works together by building an app in JavaScript that connects to a contract
+
+
+
+## Get inspired
+
+
+
+
+
What to build on Aztec
+
+
+ Find requests for applications, potential designs, and existing ecosystem projects
+
+
+
diff --git a/docs/versioned_docs/version-v0.82.2-alpha-testnet.5/developers/inspiration.md b/docs/versioned_docs/version-v0.82.2-alpha-testnet.5/developers/inspiration.md
new file mode 100644
index 000000000000..6f89bd191338
--- /dev/null
+++ b/docs/versioned_docs/version-v0.82.2-alpha-testnet.5/developers/inspiration.md
@@ -0,0 +1,98 @@
+---
+id: inspiration
+title: Inspiration and Ideas
+---
+
+This page covers requests for apps on Aztec, designs that some teams are exploring, existing contract examples, and open source ecosystem projects.
+
+## App ideas
+
+### Finance
+
+- Undercollateralized Lending
+- Private order matching
+- Hidden liquidity aggregation
+- Batch Clearing
+- Escrow Systems
+- Private Bill Splitting
+- Fee Payment Contracts (FPCs)
+- Private Auction Systems
+- Private Betting with Commit-Reveal Schemes
+- Stablecoins
+- Stablecoin Swap Portal
+- L1-L2 Lending Portal (supply L1, borrow L2)
+- Mint DAI on L2 via L1 ETH
+- Recurring Payments with Account Abstraction
+- Token Streaming
+
+### Identity & Access Management
+
+- Private Glassdoor
+- Private Yelp
+- Onchain Loyalty System
+- History-based Gating
+- NFT Verification
+- Multisig Implementation
+- Verifiable Random Functions (VRFs)
+- Bridge to connect Aztec with Other L2s
+- L1-L2 Activity Verification, eg prove L1 degeneracy score on L2
+- Storage proof libraries and tooling
+- Private Creator Payment Systems
+
+### Gaming & Governance
+
+- DAO Infrastructure
+- DAO Voting via Portals (threshold-triggered)
+- Private Voting Systems
+- Private Airdrop Systems
+
+### Infrastructure & Tooling
+
+- Privacy-Preserving Oracle Systems
+- Privacy-Preserving RPC Proxies
+
+There are countless other ideas. Join the [developer Discord](https://discord.com/invite/aztec) if you're interested in building any of these or more.
+
+## Design explorations
+
+Many of these are not official resources, may be outdated, or are works in progress.
+
+- [Blog: Can blockchains and zero-knowledge help humanity survive? 47 real-world use cases](https://aztec.network/blog/can-blockchains-and-zero-knowledge-help-humanity-survive-47-real-world-use-cases)
+- [Alpha Build: DEXes](https://docs.google.com/document/d/1J0i2ciIHFN2bJJxLRgEdJnI6hd7FxkedSd78qMC7ziM/edit?usp=sharing) - A Google doc with a deep dive of how various DEXes could work on Aztec
+
+## Contract examples
+
+Explore the [tutorials section](../developers/tutorials/codealong/contract_tutorials/counter_contract.md) for some contract and full-stack project examples.
+
+There is also a list of up-to-date contract examples in the [aztec-packages Github repo](https://github.com/AztecProtocol/aztec-packages/tree/master/noir-projects/noir-contracts/contracts).
+
+## Ecosystem projects
+
+- [ShieldSwap](https://app.shieldswap.org/?type=market)
+- [AztecScan](https://aztecscan.xyz/)
+- [Azguard](https://azguardwallet.io/terms)
+
+Explore the [Aztec Network ecosystem page](https://aztec.network/ecosystem) to discover more.
+
+### Proof of concepts
+
+Many of these are outdated.
+
+- [Ikegai](https://github.com/resurgencelabs/ikigai_backend)
+- [Aztec private oracle](https://github.com/defi-wonderland/aztec-private-oracle)
+- [Zybil](https://github.com/mach-34/zybil)
+- [Aztec poker](https://github.com/zobront/aztec-poker/)
+- [Alpha Build winners](https://aztec.network/blog/shaping-the-future-of-payments-meet-the-winners-of-alpha-build-one)
+
+### Noir
+
+This is a list of open source Noir projects, libraries, or primitives that can be integrated into Aztec projects.
+
+- [ZKEmail](https://github.com/zkemail/zkemail.nr/tree/main)
+- [ZKPassport](https://github.com/zkpassport)
+- [StealthNote](https://github.com/saleel/stealthnote)
+- [Anoncast](https://github.com/anondotworld/anonworld)
+
+## Independent projects with open issues
+
+Explore independent projects on [OnlyDust](https://app.onlydust.com/ecosystems/aztec).
diff --git a/docs/versioned_docs/version-v0.82.2-alpha-testnet.5/developers/reference/aztecjs/_category_.yml b/docs/versioned_docs/version-v0.82.2-alpha-testnet.5/developers/reference/aztecjs/_category_.yml
new file mode 100644
index 000000000000..57dc01ecdd54
--- /dev/null
+++ b/docs/versioned_docs/version-v0.82.2-alpha-testnet.5/developers/reference/aztecjs/_category_.yml
@@ -0,0 +1 @@
+label: "AztecJS"
diff --git a/docs/versioned_docs/version-v0.82.2-alpha-testnet.5/developers/reference/aztecjs/accounts/_category_.yml b/docs/versioned_docs/version-v0.82.2-alpha-testnet.5/developers/reference/aztecjs/accounts/_category_.yml
new file mode 100644
index 000000000000..08af16b98be8
--- /dev/null
+++ b/docs/versioned_docs/version-v0.82.2-alpha-testnet.5/developers/reference/aztecjs/accounts/_category_.yml
@@ -0,0 +1 @@
+label: "Accounts"
\ No newline at end of file
diff --git a/docs/versioned_docs/version-v0.82.2-alpha-testnet.5/developers/reference/aztecjs/accounts/classes/_category_.yml b/docs/versioned_docs/version-v0.82.2-alpha-testnet.5/developers/reference/aztecjs/accounts/classes/_category_.yml
new file mode 100644
index 000000000000..55c7980a4644
--- /dev/null
+++ b/docs/versioned_docs/version-v0.82.2-alpha-testnet.5/developers/reference/aztecjs/accounts/classes/_category_.yml
@@ -0,0 +1,2 @@
+label: "Classes"
+position: 3
\ No newline at end of file
diff --git a/docs/versioned_docs/version-v0.82.2-alpha-testnet.5/developers/reference/aztecjs/accounts/classes/defaults.DefaultAccountContract.md b/docs/versioned_docs/version-v0.82.2-alpha-testnet.5/developers/reference/aztecjs/accounts/classes/defaults.DefaultAccountContract.md
new file mode 100644
index 000000000000..11d775807e59
--- /dev/null
+++ b/docs/versioned_docs/version-v0.82.2-alpha-testnet.5/developers/reference/aztecjs/accounts/classes/defaults.DefaultAccountContract.md
@@ -0,0 +1,94 @@
+---
+id: "defaults.DefaultAccountContract"
+title: "Class: DefaultAccountContract"
+sidebar_label: "DefaultAccountContract"
+custom_edit_url: null
+---
+
+[defaults](../modules/defaults.md).DefaultAccountContract
+
+Base class for implementing an account contract. Requires that the account uses the
+default entrypoint method signature.
+
+## Implements
+
+- `AccountContract`
+
+## Constructors
+
+### constructor
+
+• **new DefaultAccountContract**(): [`DefaultAccountContract`](defaults.DefaultAccountContract.md)
+
+#### Returns
+
+[`DefaultAccountContract`](defaults.DefaultAccountContract.md)
+
+## Methods
+
+### getAuthWitnessProvider
+
+▸ **getAuthWitnessProvider**(`address`): `AuthWitnessProvider`
+
+#### Parameters
+
+| Name | Type |
+| :------ | :------ |
+| `address` | `CompleteAddress` |
+
+#### Returns
+
+`AuthWitnessProvider`
+
+#### Implementation of
+
+AccountContract.getAuthWitnessProvider
+
+___
+
+### getContractArtifact
+
+▸ **getContractArtifact**(): `Promise`\<`ContractArtifact`\>
+
+#### Returns
+
+`Promise`\<`ContractArtifact`\>
+
+#### Implementation of
+
+AccountContract.getContractArtifact
+
+___
+
+### getDeploymentFunctionAndArgs
+
+▸ **getDeploymentFunctionAndArgs**(): `Promise`\<`undefined` \| \{ `constructorArgs`: `any`[] ; `constructorName`: `string` }\>
+
+#### Returns
+
+`Promise`\<`undefined` \| \{ `constructorArgs`: `any`[] ; `constructorName`: `string` }\>
+
+#### Implementation of
+
+AccountContract.getDeploymentFunctionAndArgs
+
+___
+
+### getInterface
+
+▸ **getInterface**(`address`, `nodeInfo`): `AccountInterface`
+
+#### Parameters
+
+| Name | Type |
+| :------ | :------ |
+| `address` | `CompleteAddress` |
+| `nodeInfo` | `NodeInfo` |
+
+#### Returns
+
+`AccountInterface`
+
+#### Implementation of
+
+AccountContract.getInterface
diff --git a/docs/versioned_docs/version-v0.82.2-alpha-testnet.5/developers/reference/aztecjs/accounts/classes/defaults.DefaultAccountInterface.md b/docs/versioned_docs/version-v0.82.2-alpha-testnet.5/developers/reference/aztecjs/accounts/classes/defaults.DefaultAccountInterface.md
new file mode 100644
index 000000000000..c24b4aff13f5
--- /dev/null
+++ b/docs/versioned_docs/version-v0.82.2-alpha-testnet.5/developers/reference/aztecjs/accounts/classes/defaults.DefaultAccountInterface.md
@@ -0,0 +1,161 @@
+---
+id: "defaults.DefaultAccountInterface"
+title: "Class: DefaultAccountInterface"
+sidebar_label: "DefaultAccountInterface"
+custom_edit_url: null
+---
+
+[defaults](../modules/defaults.md).DefaultAccountInterface
+
+Default implementation for an account interface. Requires that the account uses the default
+entrypoint signature, which accept an AppPayload and a FeePayload as defined in noir-libs/aztec-noir/src/entrypoint module
+
+## Implements
+
+- `AccountInterface`
+
+## Constructors
+
+### constructor
+
+• **new DefaultAccountInterface**(`authWitnessProvider`, `address`, `nodeInfo`): [`DefaultAccountInterface`](defaults.DefaultAccountInterface.md)
+
+#### Parameters
+
+| Name | Type |
+| :------ | :------ |
+| `authWitnessProvider` | `AuthWitnessProvider` |
+| `address` | `CompleteAddress` |
+| `nodeInfo` | `Pick`\<`NodeInfo`, ``"l1ChainId"`` \| ``"protocolVersion"``\> |
+
+#### Returns
+
+[`DefaultAccountInterface`](defaults.DefaultAccountInterface.md)
+
+## Properties
+
+### address
+
+• `Private` **address**: `CompleteAddress`
+
+___
+
+### authWitnessProvider
+
+• `Private` **authWitnessProvider**: `AuthWitnessProvider`
+
+___
+
+### chainId
+
+• `Private` **chainId**: `Fr`
+
+___
+
+### entrypoint
+
+• `Protected` **entrypoint**: `EntrypointInterface`
+
+___
+
+### version
+
+• `Private` **version**: `Fr`
+
+## Methods
+
+### createAuthWit
+
+▸ **createAuthWit**(`messageHash`): `Promise`\<`AuthWitness`\>
+
+#### Parameters
+
+| Name | Type |
+| :------ | :------ |
+| `messageHash` | `Fr` |
+
+#### Returns
+
+`Promise`\<`AuthWitness`\>
+
+#### Implementation of
+
+AccountInterface.createAuthWit
+
+___
+
+### createTxExecutionRequest
+
+▸ **createTxExecutionRequest**(`exec`, `fee`, `options`): `Promise`\<`TxExecutionRequest`\>
+
+#### Parameters
+
+| Name | Type |
+| :------ | :------ |
+| `exec` | `ExecutionPayload` |
+| `fee` | `FeeOptions` |
+| `options` | `TxExecutionOptions` |
+
+#### Returns
+
+`Promise`\<`TxExecutionRequest`\>
+
+#### Implementation of
+
+AccountInterface.createTxExecutionRequest
+
+___
+
+### getAddress
+
+▸ **getAddress**(): `AztecAddress`
+
+#### Returns
+
+`AztecAddress`
+
+#### Implementation of
+
+AccountInterface.getAddress
+
+___
+
+### getChainId
+
+▸ **getChainId**(): `Fr`
+
+#### Returns
+
+`Fr`
+
+#### Implementation of
+
+AccountInterface.getChainId
+
+___
+
+### getCompleteAddress
+
+▸ **getCompleteAddress**(): `CompleteAddress`
+
+#### Returns
+
+`CompleteAddress`
+
+#### Implementation of
+
+AccountInterface.getCompleteAddress
+
+___
+
+### getVersion
+
+▸ **getVersion**(): `Fr`
+
+#### Returns
+
+`Fr`
+
+#### Implementation of
+
+AccountInterface.getVersion
diff --git a/docs/versioned_docs/version-v0.82.2-alpha-testnet.5/developers/reference/aztecjs/accounts/classes/ecdsa.EcdsaKAccountContract.md b/docs/versioned_docs/version-v0.82.2-alpha-testnet.5/developers/reference/aztecjs/accounts/classes/ecdsa.EcdsaKAccountContract.md
new file mode 100644
index 000000000000..3068a0c66294
--- /dev/null
+++ b/docs/versioned_docs/version-v0.82.2-alpha-testnet.5/developers/reference/aztecjs/accounts/classes/ecdsa.EcdsaKAccountContract.md
@@ -0,0 +1,107 @@
+---
+id: "ecdsa.EcdsaKAccountContract"
+title: "Class: EcdsaKAccountContract"
+sidebar_label: "EcdsaKAccountContract"
+custom_edit_url: null
+---
+
+[ecdsa](../modules/ecdsa.md).EcdsaKAccountContract
+
+Account contract that authenticates transactions using ECDSA signatures
+verified against a secp256k1 public key stored in an immutable encrypted note.
+Eagerly loads the contract artifact
+
+## Hierarchy
+
+- `EcdsaKBaseAccountContract`
+
+ ↳ **`EcdsaKAccountContract`**
+
+## Constructors
+
+### constructor
+
+• **new EcdsaKAccountContract**(`signingPrivateKey`): [`EcdsaKAccountContract`](ecdsa.EcdsaKAccountContract.md)
+
+#### Parameters
+
+| Name | Type |
+| :------ | :------ |
+| `signingPrivateKey` | `Buffer` |
+
+#### Returns
+
+[`EcdsaKAccountContract`](ecdsa.EcdsaKAccountContract.md)
+
+#### Overrides
+
+EcdsaKBaseAccountContract.constructor
+
+## Methods
+
+### getAuthWitnessProvider
+
+▸ **getAuthWitnessProvider**(`_address`): `AuthWitnessProvider`
+
+#### Parameters
+
+| Name | Type |
+| :------ | :------ |
+| `_address` | `CompleteAddress` |
+
+#### Returns
+
+`AuthWitnessProvider`
+
+#### Inherited from
+
+EcdsaKBaseAccountContract.getAuthWitnessProvider
+
+___
+
+### getContractArtifact
+
+▸ **getContractArtifact**(): `Promise`\<`ContractArtifact`\>
+
+#### Returns
+
+`Promise`\<`ContractArtifact`\>
+
+#### Overrides
+
+EcdsaKBaseAccountContract.getContractArtifact
+
+___
+
+### getDeploymentFunctionAndArgs
+
+▸ **getDeploymentFunctionAndArgs**(): `Promise`\<\{ `constructorArgs`: `Buffer`[] ; `constructorName`: `string` = 'constructor' }\>
+
+#### Returns
+
+`Promise`\<\{ `constructorArgs`: `Buffer`[] ; `constructorName`: `string` = 'constructor' }\>
+
+#### Inherited from
+
+EcdsaKBaseAccountContract.getDeploymentFunctionAndArgs
+
+___
+
+### getInterface
+
+▸ **getInterface**(`address`, `nodeInfo`): `AccountInterface`
+
+#### Parameters
+
+| Name | Type |
+| :------ | :------ |
+| `address` | `CompleteAddress` |
+| `nodeInfo` | `NodeInfo` |
+
+#### Returns
+
+`AccountInterface`
+
+#### Inherited from
+
+EcdsaKBaseAccountContract.getInterface
diff --git a/docs/versioned_docs/version-v0.82.2-alpha-testnet.5/developers/reference/aztecjs/accounts/classes/ecdsa.EcdsaRSSHAccountContract.md b/docs/versioned_docs/version-v0.82.2-alpha-testnet.5/developers/reference/aztecjs/accounts/classes/ecdsa.EcdsaRSSHAccountContract.md
new file mode 100644
index 000000000000..7c25ebb65998
--- /dev/null
+++ b/docs/versioned_docs/version-v0.82.2-alpha-testnet.5/developers/reference/aztecjs/accounts/classes/ecdsa.EcdsaRSSHAccountContract.md
@@ -0,0 +1,110 @@
+---
+id: "ecdsa.EcdsaRSSHAccountContract"
+title: "Class: EcdsaRSSHAccountContract"
+sidebar_label: "EcdsaRSSHAccountContract"
+custom_edit_url: null
+---
+
+[ecdsa](../modules/ecdsa.md).EcdsaRSSHAccountContract
+
+Account contract that authenticates transactions using ECDSA signatures
+verified against a secp256r1 public key stored in an immutable encrypted note.
+Since this implementation relays signatures to an SSH agent, we provide the
+public key here not for signature verification, but to identify actual identity
+that will be used to sign authwitnesses.
+Eagerly loads the contract artifact
+
+## Hierarchy
+
+- `EcdsaRSSHBaseAccountContract`
+
+ ↳ **`EcdsaRSSHAccountContract`**
+
+## Constructors
+
+### constructor
+
+• **new EcdsaRSSHAccountContract**(`signingPrivateKey`): [`EcdsaRSSHAccountContract`](ecdsa.EcdsaRSSHAccountContract.md)
+
+#### Parameters
+
+| Name | Type |
+| :------ | :------ |
+| `signingPrivateKey` | `Buffer` |
+
+#### Returns
+
+[`EcdsaRSSHAccountContract`](ecdsa.EcdsaRSSHAccountContract.md)
+
+#### Overrides
+
+EcdsaRSSHBaseAccountContract.constructor
+
+## Methods
+
+### getAuthWitnessProvider
+
+▸ **getAuthWitnessProvider**(`_address`): `AuthWitnessProvider`
+
+#### Parameters
+
+| Name | Type |
+| :------ | :------ |
+| `_address` | `CompleteAddress` |
+
+#### Returns
+
+`AuthWitnessProvider`
+
+#### Inherited from
+
+EcdsaRSSHBaseAccountContract.getAuthWitnessProvider
+
+___
+
+### getContractArtifact
+
+▸ **getContractArtifact**(): `Promise`\<`ContractArtifact`\>
+
+#### Returns
+
+`Promise`\<`ContractArtifact`\>
+
+#### Overrides
+
+EcdsaRSSHBaseAccountContract.getContractArtifact
+
+___
+
+### getDeploymentFunctionAndArgs
+
+▸ **getDeploymentFunctionAndArgs**(): `Promise`\<\{ `constructorArgs`: `Buffer`[] ; `constructorName`: `string` = 'constructor' }\>
+
+#### Returns
+
+`Promise`\<\{ `constructorArgs`: `Buffer`[] ; `constructorName`: `string` = 'constructor' }\>
+
+#### Inherited from
+
+EcdsaRSSHBaseAccountContract.getDeploymentFunctionAndArgs
+
+___
+
+### getInterface
+
+▸ **getInterface**(`address`, `nodeInfo`): `AccountInterface`
+
+#### Parameters
+
+| Name | Type |
+| :------ | :------ |
+| `address` | `CompleteAddress` |
+| `nodeInfo` | `NodeInfo` |
+
+#### Returns
+
+`AccountInterface`
+
+#### Inherited from
+
+EcdsaRSSHBaseAccountContract.getInterface
diff --git a/docs/versioned_docs/version-v0.82.2-alpha-testnet.5/developers/reference/aztecjs/accounts/classes/schnorr.SchnorrAccountContract.md b/docs/versioned_docs/version-v0.82.2-alpha-testnet.5/developers/reference/aztecjs/accounts/classes/schnorr.SchnorrAccountContract.md
new file mode 100644
index 000000000000..ba045b038046
--- /dev/null
+++ b/docs/versioned_docs/version-v0.82.2-alpha-testnet.5/developers/reference/aztecjs/accounts/classes/schnorr.SchnorrAccountContract.md
@@ -0,0 +1,107 @@
+---
+id: "schnorr.SchnorrAccountContract"
+title: "Class: SchnorrAccountContract"
+sidebar_label: "SchnorrAccountContract"
+custom_edit_url: null
+---
+
+[schnorr](../modules/schnorr.md).SchnorrAccountContract
+
+Account contract that authenticates transactions using Schnorr signatures
+verified against a Grumpkin public key stored in an immutable encrypted note.
+Eagerly loads the contract artifact
+
+## Hierarchy
+
+- `SchnorrBaseAccountContract`
+
+ ↳ **`SchnorrAccountContract`**
+
+## Constructors
+
+### constructor
+
+• **new SchnorrAccountContract**(`signingPrivateKey`): [`SchnorrAccountContract`](schnorr.SchnorrAccountContract.md)
+
+#### Parameters
+
+| Name | Type |
+| :------ | :------ |
+| `signingPrivateKey` | `Fq` |
+
+#### Returns
+
+[`SchnorrAccountContract`](schnorr.SchnorrAccountContract.md)
+
+#### Overrides
+
+SchnorrBaseAccountContract.constructor
+
+## Methods
+
+### getAuthWitnessProvider
+
+▸ **getAuthWitnessProvider**(`_address`): `AuthWitnessProvider`
+
+#### Parameters
+
+| Name | Type |
+| :------ | :------ |
+| `_address` | `CompleteAddress` |
+
+#### Returns
+
+`AuthWitnessProvider`
+
+#### Inherited from
+
+SchnorrBaseAccountContract.getAuthWitnessProvider
+
+___
+
+### getContractArtifact
+
+▸ **getContractArtifact**(): `Promise`\<`ContractArtifact`\>
+
+#### Returns
+
+`Promise`\<`ContractArtifact`\>
+
+#### Overrides
+
+SchnorrBaseAccountContract.getContractArtifact
+
+___
+
+### getDeploymentFunctionAndArgs
+
+▸ **getDeploymentFunctionAndArgs**(): `Promise`\<\{ `constructorArgs`: `Fr`[] ; `constructorName`: `string` = 'constructor' }\>
+
+#### Returns
+
+`Promise`\<\{ `constructorArgs`: `Fr`[] ; `constructorName`: `string` = 'constructor' }\>
+
+#### Inherited from
+
+SchnorrBaseAccountContract.getDeploymentFunctionAndArgs
+
+___
+
+### getInterface
+
+▸ **getInterface**(`address`, `nodeInfo`): `AccountInterface`
+
+#### Parameters
+
+| Name | Type |
+| :------ | :------ |
+| `address` | `CompleteAddress` |
+| `nodeInfo` | `NodeInfo` |
+
+#### Returns
+
+`AccountInterface`
+
+#### Inherited from
+
+SchnorrBaseAccountContract.getInterface
diff --git a/docs/versioned_docs/version-v0.82.2-alpha-testnet.5/developers/reference/aztecjs/accounts/classes/single_key.SingleKeyAccountContract.md b/docs/versioned_docs/version-v0.82.2-alpha-testnet.5/developers/reference/aztecjs/accounts/classes/single_key.SingleKeyAccountContract.md
new file mode 100644
index 000000000000..d9b230516512
--- /dev/null
+++ b/docs/versioned_docs/version-v0.82.2-alpha-testnet.5/developers/reference/aztecjs/accounts/classes/single_key.SingleKeyAccountContract.md
@@ -0,0 +1,107 @@
+---
+id: "single_key.SingleKeyAccountContract"
+title: "Class: SingleKeyAccountContract"
+sidebar_label: "SingleKeyAccountContract"
+custom_edit_url: null
+---
+
+[single\_key](../modules/single_key.md).SingleKeyAccountContract
+
+Account contract that authenticates transactions using Schnorr signatures verified against
+the note encryption key, relying on a single private key for both encryption and authentication.
+Eagerly loads the contract artifact
+
+## Hierarchy
+
+- `SingleKeyBaseAccountContract`
+
+ ↳ **`SingleKeyAccountContract`**
+
+## Constructors
+
+### constructor
+
+• **new SingleKeyAccountContract**(`signingPrivateKey`): [`SingleKeyAccountContract`](single_key.SingleKeyAccountContract.md)
+
+#### Parameters
+
+| Name | Type |
+| :------ | :------ |
+| `signingPrivateKey` | `Fq` |
+
+#### Returns
+
+[`SingleKeyAccountContract`](single_key.SingleKeyAccountContract.md)
+
+#### Overrides
+
+SingleKeyBaseAccountContract.constructor
+
+## Methods
+
+### getAuthWitnessProvider
+
+▸ **getAuthWitnessProvider**(`account`): `AuthWitnessProvider`
+
+#### Parameters
+
+| Name | Type |
+| :------ | :------ |
+| `account` | `CompleteAddress` |
+
+#### Returns
+
+`AuthWitnessProvider`
+
+#### Inherited from
+
+SingleKeyBaseAccountContract.getAuthWitnessProvider
+
+___
+
+### getContractArtifact
+
+▸ **getContractArtifact**(): `Promise`\<`ContractArtifact`\>
+
+#### Returns
+
+`Promise`\<`ContractArtifact`\>
+
+#### Overrides
+
+SingleKeyBaseAccountContract.getContractArtifact
+
+___
+
+### getDeploymentFunctionAndArgs
+
+▸ **getDeploymentFunctionAndArgs**(): `Promise`\<`undefined`\>
+
+#### Returns
+
+`Promise`\<`undefined`\>
+
+#### Inherited from
+
+SingleKeyBaseAccountContract.getDeploymentFunctionAndArgs
+
+___
+
+### getInterface
+
+▸ **getInterface**(`address`, `nodeInfo`): `AccountInterface`
+
+#### Parameters
+
+| Name | Type |
+| :------ | :------ |
+| `address` | `CompleteAddress` |
+| `nodeInfo` | `NodeInfo` |
+
+#### Returns
+
+`AccountInterface`
+
+#### Inherited from
+
+SingleKeyBaseAccountContract.getInterface
diff --git a/docs/versioned_docs/version-v0.82.2-alpha-testnet.5/developers/reference/aztecjs/accounts/index.md b/docs/versioned_docs/version-v0.82.2-alpha-testnet.5/developers/reference/aztecjs/accounts/index.md
new file mode 100644
index 000000000000..0c19cb267f7e
--- /dev/null
+++ b/docs/versioned_docs/version-v0.82.2-alpha-testnet.5/developers/reference/aztecjs/accounts/index.md
@@ -0,0 +1,16 @@
+---
+id: "index"
+title: "@aztec/accounts"
+sidebar_label: "Table of Contents"
+sidebar_position: 0.5
+hide_table_of_contents: true
+custom_edit_url: null
+---
+
+## Modules
+
+- [defaults](modules/defaults.md)
+- [ecdsa](modules/ecdsa.md)
+- [schnorr](modules/schnorr.md)
+- [single\_key](modules/single_key.md)
+- [testing](modules/testing.md)
diff --git a/docs/versioned_docs/version-v0.82.2-alpha-testnet.5/developers/reference/aztecjs/accounts/interfaces/_category_.yml b/docs/versioned_docs/version-v0.82.2-alpha-testnet.5/developers/reference/aztecjs/accounts/interfaces/_category_.yml
new file mode 100644
index 000000000000..43bec88cfa0a
--- /dev/null
+++ b/docs/versioned_docs/version-v0.82.2-alpha-testnet.5/developers/reference/aztecjs/accounts/interfaces/_category_.yml
@@ -0,0 +1,2 @@
+label: "Interfaces"
+position: 4
\ No newline at end of file
diff --git a/docs/versioned_docs/version-v0.82.2-alpha-testnet.5/developers/reference/aztecjs/accounts/interfaces/testing.InitialAccountData.md b/docs/versioned_docs/version-v0.82.2-alpha-testnet.5/developers/reference/aztecjs/accounts/interfaces/testing.InitialAccountData.md
new file mode 100644
index 000000000000..7b2757593317
--- /dev/null
+++ b/docs/versioned_docs/version-v0.82.2-alpha-testnet.5/developers/reference/aztecjs/accounts/interfaces/testing.InitialAccountData.md
@@ -0,0 +1,42 @@
+---
+id: "testing.InitialAccountData"
+title: "Interface: InitialAccountData"
+sidebar_label: "InitialAccountData"
+custom_edit_url: null
+---
+
+[testing](../modules/testing.md).InitialAccountData
+
+Data for generating an initial account.
+
+## Properties
+
+### address
+
+• **address**: `AztecAddress`
+
+Address of the schnorr account contract.
+
+___
+
+### salt
+
+• **salt**: `Fr`
+
+Contract address salt.
+
+___
+
+### secret
+
+• **secret**: `Fr`
+
+Secret to derive the keys for the account.
+
+___
+
+### signingKey
+
+• **signingKey**: `Fq`
+
+Signing key od the account.
diff --git a/docs/versioned_docs/version-v0.82.2-alpha-testnet.5/developers/reference/aztecjs/accounts/modules/_category_.yml b/docs/versioned_docs/version-v0.82.2-alpha-testnet.5/developers/reference/aztecjs/accounts/modules/_category_.yml
new file mode 100644
index 000000000000..63f9c4e40160
--- /dev/null
+++ b/docs/versioned_docs/version-v0.82.2-alpha-testnet.5/developers/reference/aztecjs/accounts/modules/_category_.yml
@@ -0,0 +1,2 @@
+label: "Modules"
+position: 1
\ No newline at end of file
diff --git a/docs/versioned_docs/version-v0.82.2-alpha-testnet.5/developers/reference/aztecjs/accounts/modules/defaults.md b/docs/versioned_docs/version-v0.82.2-alpha-testnet.5/developers/reference/aztecjs/accounts/modules/defaults.md
new file mode 100644
index 000000000000..9252b70f72ae
--- /dev/null
+++ b/docs/versioned_docs/version-v0.82.2-alpha-testnet.5/developers/reference/aztecjs/accounts/modules/defaults.md
@@ -0,0 +1,16 @@
+---
+id: "defaults"
+title: "Module: defaults"
+sidebar_label: "defaults"
+sidebar_position: 0
+custom_edit_url: null
+---
+
+The `@aztec/accounts/defaults` export provides the base class [DefaultAccountContract](../classes/defaults.DefaultAccountContract.md) for implementing account contracts that use the default entrypoint payload module.
+
+Read more in [Writing an account contract](https://docs.aztec.network/developers/tutorials/codealong/contract_tutorials/write_accounts_contract).
+
+## Classes
+
+- [DefaultAccountContract](../classes/defaults.DefaultAccountContract.md)
+- [DefaultAccountInterface](../classes/defaults.DefaultAccountInterface.md)
diff --git a/docs/versioned_docs/version-v0.82.2-alpha-testnet.5/developers/reference/aztecjs/accounts/modules/ecdsa.md b/docs/versioned_docs/version-v0.82.2-alpha-testnet.5/developers/reference/aztecjs/accounts/modules/ecdsa.md
new file mode 100644
index 000000000000..e6bd39fdf1ca
--- /dev/null
+++ b/docs/versioned_docs/version-v0.82.2-alpha-testnet.5/developers/reference/aztecjs/accounts/modules/ecdsa.md
@@ -0,0 +1,114 @@
+---
+id: "ecdsa"
+title: "Module: ecdsa"
+sidebar_label: "ecdsa"
+sidebar_position: 0
+custom_edit_url: null
+---
+
+## Classes
+
+- [EcdsaKAccountContract](../classes/ecdsa.EcdsaKAccountContract.md)
+- [EcdsaRSSHAccountContract](../classes/ecdsa.EcdsaRSSHAccountContract.md)
+
+## Variables
+
+### EcdsaKAccountContractArtifact
+
+• `Const` **EcdsaKAccountContractArtifact**: `ContractArtifact`
+
+___
+
+### EcdsaRAccountContractArtifact
+
+• `Const` **EcdsaRAccountContractArtifact**: `ContractArtifact`
+
+## Functions
+
+### getEcdsaKAccount
+
+▸ **getEcdsaKAccount**(`pxe`, `secretKey`, `signingPrivateKey`, `salt?`): `Promise`\<`AccountManager`\>
+
+Creates an Account that relies on an ECDSA signing key for authentication.
+
+#### Parameters
+
+| Name | Type | Description |
+| :------ | :------ | :------ |
+| `pxe` | `PXE` | An PXE server instance. |
+| `secretKey` | `Fr` | Secret key used to derive all the keystore keys. |
+| `signingPrivateKey` | `Buffer` | Secp256k1 key used for signing transactions. |
+| `salt?` | `Salt` | Deployment salt. |
+
+#### Returns
+
+`Promise`\<`AccountManager`\>
+
+An account manager initialized with the account contract and its deployment params
+
+___
+
+### getEcdsaKWallet
+
+▸ **getEcdsaKWallet**(`pxe`, `address`, `signingPrivateKey`): `Promise`\<`AccountWallet`\>
+
+Gets a wallet for an already registered account using ECDSA signatures.
+
+#### Parameters
+
+| Name | Type | Description |
+| :------ | :------ | :------ |
+| `pxe` | `PXE` | An PXE server instance. |
+| `address` | `AztecAddress` | Address for the account. |
+| `signingPrivateKey` | `Buffer` | ECDSA key used for signing transactions. |
+
+#### Returns
+
+`Promise`\<`AccountWallet`\>
+
+A wallet for this account that can be used to interact with a contract instance.
+
+___
+
+### getEcdsaRSSHAccount
+
+▸ **getEcdsaRSSHAccount**(`pxe`, `secretKey`, `signingPublicKey`, `salt?`): `Promise`\<`AccountManager`\>
+
+Creates an Account that relies on an ECDSA signing key for authentication.
+
+#### Parameters
+
+| Name | Type | Description |
+| :------ | :------ | :------ |
+| `pxe` | `PXE` | An PXE server instance. |
+| `secretKey` | `Fr` | Secret key used to derive all the keystore keys. |
+| `signingPublicKey` | `Buffer` | Secp2561 key used to identify its corresponding private key in the SSH Agent. |
+| `salt?` | `Salt` | Deployment salt. |
+
+#### Returns
+
+`Promise`\<`AccountManager`\>
+
+An account manager initialized with the account contract and its deployment params
+
+___
+
+### getEcdsaRSSHWallet
+
+▸ **getEcdsaRSSHWallet**(`pxe`, `address`, `signingPublicKey`): `Promise`\<`AccountWallet`\>
+
+Gets a wallet for an already registered account using ECDSA signatures.
+
+#### Parameters
+
+| Name | Type | Description |
+| :------ | :------ | :------ |
+| `pxe` | `PXE` | An PXE server instance. |
+| `address` | `AztecAddress` | Address for the account. |
+| `signingPublicKey` | `Buffer` | - |
+
+#### Returns
+
+`Promise`\<`AccountWallet`\>
+
+A wallet for this account that can be used to interact with a contract instance.
diff --git a/docs/versioned_docs/version-v0.82.2-alpha-testnet.5/developers/reference/aztecjs/accounts/modules/schnorr.md b/docs/versioned_docs/version-v0.82.2-alpha-testnet.5/developers/reference/aztecjs/accounts/modules/schnorr.md
new file mode 100644
index 000000000000..cbd6dcd7734e
--- /dev/null
+++ b/docs/versioned_docs/version-v0.82.2-alpha-testnet.5/developers/reference/aztecjs/accounts/modules/schnorr.md
@@ -0,0 +1,108 @@
+---
+id: "schnorr"
+title: "Module: schnorr"
+sidebar_label: "schnorr"
+sidebar_position: 0
+custom_edit_url: null
+---
+
+The `@aztec/accounts/schnorr` export provides an account contract implementation that uses Schnorr signatures with a Grumpkin key for authentication, and a separate Grumpkin key for encryption.
+This is the suggested account contract type for most use cases within Aztec.
+
+## Classes
+
+- [SchnorrAccountContract](../classes/schnorr.SchnorrAccountContract.md)
+
+## Variables
+
+### SchnorrAccountContractArtifact
+
+• `Const` **SchnorrAccountContractArtifact**: `ContractArtifact`
+
+## Functions
+
+### getSchnorrAccount
+
+▸ **getSchnorrAccount**(`pxe`, `secretKey`, `signingPrivateKey`, `salt?`): `Promise`\<`AccountManager`\>
+
+Creates an Account Manager that relies on a Grumpkin signing key for authentication.
+
+#### Parameters
+
+| Name | Type | Description |
+| :------ | :------ | :------ |
+| `pxe` | `PXE` | An PXE server instance. |
+| `secretKey` | `Fr` | Secret key used to derive all the keystore keys. |
+| `signingPrivateKey` | `Fq` | Grumpkin key used for signing transactions. |
+| `salt?` | `Salt` | Deployment salt. |
+
+#### Returns
+
+`Promise`\<`AccountManager`\>
+
+An account manager initialized with the account contract and its deployment params
+
+___
+
+### getSchnorrAccountContractAddress
+
+▸ **getSchnorrAccountContractAddress**(`secret`, `salt`, `signingPrivateKey?`): `Promise`\<`AztecAddress`\>
+
+Compute the address of a schnorr account contract.
+
+#### Parameters
+
+| Name | Type | Description |
+| :------ | :------ | :------ |
+| `secret` | `Fr` | A seed for deriving the signing key and public keys. |
+| `salt` | `Fr` | The contract address salt. |
+| `signingPrivateKey?` | `Fq` | A specific signing private key that's not derived from the secret. |
+
+#### Returns
+
+`Promise`\<`AztecAddress`\>
+
+___
+
+### getSchnorrWallet
+
+▸ **getSchnorrWallet**(`pxe`, `address`, `signingPrivateKey`): `Promise`\<`AccountWallet`\>
+
+Gets a wallet for an already registered account using Schnorr signatures.
+
+#### Parameters
+
+| Name | Type | Description |
+| :------ | :------ | :------ |
+| `pxe` | `PXE` | An PXE server instance. |
+| `address` | `AztecAddress` | Address for the account. |
+| `signingPrivateKey` | `Fq` | Grumpkin key used for signing transactions. |
+
+#### Returns
+
+`Promise`\<`AccountWallet`\>
+
+A wallet for this account that can be used to interact with a contract instance.
+
+___
+
+### getSchnorrWalletWithSecretKey
+
+▸ **getSchnorrWalletWithSecretKey**(`pxe`, `secretKey`, `signingPrivateKey`, `salt`): `Promise`\<`AccountWalletWithSecretKey`\>
+
+Gets a wallet for an already registered account using Schnorr signatures.
+
+#### Parameters
+
+| Name | Type | Description |
+| :------ | :------ | :------ |
+| `pxe` | `PXE` | An PXE server instance. |
+| `secretKey` | `Fr` | Secret key used to derive all the keystore keys. |
+| `signingPrivateKey` | `Fq` | Grumpkin key used for signing transactions. |
+| `salt` | `Salt` | Deployment salt. |
+
+#### Returns
+
+`Promise`\<`AccountWalletWithSecretKey`\>
+
+A wallet for this account that can be used to interact with a contract instance.
diff --git a/docs/versioned_docs/version-v0.82.2-alpha-testnet.5/developers/reference/aztecjs/accounts/modules/single_key.md b/docs/versioned_docs/version-v0.82.2-alpha-testnet.5/developers/reference/aztecjs/accounts/modules/single_key.md
new file mode 100644
index 000000000000..e376e50fbb03
--- /dev/null
+++ b/docs/versioned_docs/version-v0.82.2-alpha-testnet.5/developers/reference/aztecjs/accounts/modules/single_key.md
@@ -0,0 +1,64 @@
+---
+id: "single_key"
+title: "Module: single_key"
+sidebar_label: "single_key"
+sidebar_position: 0
+custom_edit_url: null
+---
+
+The `@aztec/accounts/single_key` export provides a testing account contract implementation that uses a single Grumpkin key for both authentication and encryption.
+It is not recommended to use this account type in production.
+
+## Classes
+
+- [SingleKeyAccountContract](../classes/single_key.SingleKeyAccountContract.md)
+
+## Variables
+
+### SchnorrSingleKeyAccountContractArtifact
+
+• `Const` **SchnorrSingleKeyAccountContractArtifact**: `ContractArtifact`
+
+## Functions
+
+### getUnsafeSchnorrAccount
+
+▸ **getUnsafeSchnorrAccount**(`pxe`, `secretKey`, `salt?`): `Promise`\<`AccountManager`\>
+
+Creates an Account that uses the same Grumpkin key for encryption and authentication.
+
+#### Parameters
+
+| Name | Type | Description |
+| :------ | :------ | :------ |
+| `pxe` | `PXE` | An PXE server instance. |
+| `secretKey` | `Fr` | Secret key used to derive all the keystore keys (in this case also used to get signing key). |
+| `salt?` | `Salt` | Deployment salt. |
+
+#### Returns
+
+`Promise`\<`AccountManager`\>
+
+An account manager initialized with the account contract and its deployment params
+
+___
+
+### getUnsafeSchnorrWallet
+
+▸ **getUnsafeSchnorrWallet**(`pxe`, `address`, `signingPrivateKey`): `Promise`\<`AccountWallet`\>
+
+Gets a wallet for an already registered account using Schnorr signatures with a single key for encryption and authentication.
+
+#### Parameters
+
+| Name | Type | Description |
+| :------ | :------ | :------ |
+| `pxe` | `PXE` | An PXE server instance. |
+| `address` | `AztecAddress` | Address for the account. |
+| `signingPrivateKey` | `Fq` | Grumpkin key used for note encryption and signing transactions. |
+
+#### Returns
+
+`Promise`\<`AccountWallet`\>
+
+A wallet for this account that can be used to interact with a contract instance.
diff --git a/docs/versioned_docs/version-v0.82.2-alpha-testnet.5/developers/reference/aztecjs/accounts/modules/testing.md b/docs/versioned_docs/version-v0.82.2-alpha-testnet.5/developers/reference/aztecjs/accounts/modules/testing.md
new file mode 100644
index 000000000000..7fd5dd4fe70f
--- /dev/null
+++ b/docs/versioned_docs/version-v0.82.2-alpha-testnet.5/developers/reference/aztecjs/accounts/modules/testing.md
@@ -0,0 +1,173 @@
+---
+id: "testing"
+title: "Module: testing"
+sidebar_label: "testing"
+sidebar_position: 0
+custom_edit_url: null
+---
+
+The `@aztec/accounts/testing` export provides utility methods for testing, in particular in a Sandbox environment.
+
+Use [getInitialTestAccountsWallets](testing.md#getinitialtestaccountswallets) to obtain a list of wallets for the Sandbox pre-seeded accounts.
+
+## Interfaces
+
+- [InitialAccountData](../interfaces/testing.InitialAccountData.md)
+
+## Variables
+
+### INITIAL\_TEST\_ACCOUNT\_SALTS
+
+• `Const` **INITIAL\_TEST\_ACCOUNT\_SALTS**: `Fr`[]
+
+___
+
+### INITIAL\_TEST\_ENCRYPTION\_KEYS
+
+• `Const` **INITIAL\_TEST\_ENCRYPTION\_KEYS**: `Fq`[]
+
+___
+
+### INITIAL\_TEST\_SECRET\_KEYS
+
+• `Const` **INITIAL\_TEST\_SECRET\_KEYS**: `Fr`[]
+
+___
+
+### INITIAL\_TEST\_SIGNING\_KEYS
+
+• `Const` **INITIAL\_TEST\_SIGNING\_KEYS**: `Fq`[] = `INITIAL_TEST_ENCRYPTION_KEYS`
+
+## Functions
+
+### deployFundedSchnorrAccount
+
+▸ **deployFundedSchnorrAccount**(`pxe`, `account`, `opts?`, `waitForProvenOptions?`): `Promise`\<`AccountManager`\>
+
+Deploy schnorr account contract.
+It will pay for the fee for the deployment itself. So it must be funded with the prefilled public data.
+
+#### Parameters
+
+| Name | Type |
+| :------ | :------ |
+| `pxe` | `PXE` |
+| `account` | `DeployAccountData` |
+| `opts` | `WaitOpts` & \{ `skipClassRegistration?`: `boolean` } |
+| `waitForProvenOptions?` | `WaitForProvenOpts` |
+
+#### Returns
+
+`Promise`\<`AccountManager`\>
+
+___
+
+### deployFundedSchnorrAccounts
+
+▸ **deployFundedSchnorrAccounts**(`pxe`, `accounts`, `opts?`, `waitForProvenOptions?`): `Promise`\<`AccountManager`[]\>
+
+Deploy schnorr account contracts.
+They will pay for the fees for the deployment themselves. So they must be funded with the prefilled public data.
+
+#### Parameters
+
+| Name | Type |
+| :------ | :------ |
+| `pxe` | `PXE` |
+| `accounts` | `DeployAccountData`[] |
+| `opts` | `WaitOpts` & \{ `skipClassRegistration?`: `boolean` } |
+| `waitForProvenOptions?` | `WaitForProvenOpts` |
+
+#### Returns
+
+`Promise`\<`AccountManager`[]\>
+
+___
+
+### generateSchnorrAccounts
+
+▸ **generateSchnorrAccounts**(`numberOfAccounts`): `Promise`\<\{ `address`: `AztecAddress` ; `salt`: `Fr` ; `secret`: `Fr` ; `signingKey`: `Fq` }[]\>
+
+Generate a fixed amount of random schnorr account contract instance.
+
+#### Parameters
+
+| Name | Type |
+| :------ | :------ |
+| `numberOfAccounts` | `number` |
+
+#### Returns
+
+`Promise`\<\{ `address`: `AztecAddress` ; `salt`: `Fr` ; `secret`: `Fr` ; `signingKey`: `Fq` }[]\>
+
+___
+
+### getDeployedTestAccounts
+
+▸ **getDeployedTestAccounts**(`pxe`): `Promise`\<[`InitialAccountData`](../interfaces/testing.InitialAccountData.md)[]\>
+
+Queries a PXE for it's registered accounts.
+
+#### Parameters
+
+| Name | Type | Description |
+| :------ | :------ | :------ |
+| `pxe` | `PXE` | PXE instance. |
+
+#### Returns
+
+`Promise`\<[`InitialAccountData`](../interfaces/testing.InitialAccountData.md)[]\>
+
+A set of key data for each of the initial accounts.
+
+___
+
+### getDeployedTestAccountsWallets
+
+▸ **getDeployedTestAccountsWallets**(`pxe`): `Promise`\<`AccountWalletWithSecretKey`[]\>
+
+Queries a PXE for it's registered accounts and returns wallets for those accounts using keys in the initial test accounts.
+
+#### Parameters
+
+| Name | Type | Description |
+| :------ | :------ | :------ |
+| `pxe` | `PXE` | PXE instance. |
+
+#### Returns
+
+`Promise`\<`AccountWalletWithSecretKey`[]\>
+
+A set of AccountWallet implementations for each of the initial accounts.
+
+___
+
+### getInitialTestAccounts
+
+▸ **getInitialTestAccounts**(): `Promise`\<[`InitialAccountData`](../interfaces/testing.InitialAccountData.md)[]\>
+
+Gets the basic information for initial test accounts.
+
+#### Returns
+
+`Promise`\<[`InitialAccountData`](../interfaces/testing.InitialAccountData.md)[]\>
+
+___
+
+### getInitialTestAccountsWallets
+
+▸ **getInitialTestAccountsWallets**(`pxe`): `Promise`\<`AccountWalletWithSecretKey`[]\>
+
+Gets a collection of wallets for the Aztec accounts that are initially stored in the test environment.
+
+#### Parameters
+
+| Name | Type | Description |
+| :------ | :------ | :------ |
+| `pxe` | `PXE` | PXE instance. |
+
+#### Returns
+
+`Promise`\<`AccountWalletWithSecretKey`[]\>
+
+A set of AccountWallet implementations for each of the initial accounts.
diff --git a/docs/versioned_docs/version-v0.82.2-alpha-testnet.5/developers/reference/aztecjs/aztec-js/_category_.yml b/docs/versioned_docs/version-v0.82.2-alpha-testnet.5/developers/reference/aztecjs/aztec-js/_category_.yml
new file mode 100644
index 000000000000..f5c77d17cdcf
--- /dev/null
+++ b/docs/versioned_docs/version-v0.82.2-alpha-testnet.5/developers/reference/aztecjs/aztec-js/_category_.yml
@@ -0,0 +1 @@
+label: "Aztec.js"
\ No newline at end of file
diff --git a/docs/versioned_docs/version-v0.82.2-alpha-testnet.5/developers/reference/aztecjs/aztec-js/index.md b/docs/versioned_docs/version-v0.82.2-alpha-testnet.5/developers/reference/aztecjs/aztec-js/index.md
new file mode 100644
index 000000000000..2961da2dd54c
--- /dev/null
+++ b/docs/versioned_docs/version-v0.82.2-alpha-testnet.5/developers/reference/aztecjs/aztec-js/index.md
@@ -0,0 +1,46 @@
+---
+id: "index"
+title: "@aztec/aztec.js"
+sidebar_label: "Table of Contents"
+sidebar_position: 0.5
+hide_table_of_contents: true
+custom_edit_url: null
+---
+
+The `account` module provides utilities for managing accounts. The AccountManager class
+allows to deploy and register a fresh account, or to obtain a `Wallet` instance out of an account
+already deployed. Use the `@aztec/accounts` package to load default account implementations that rely
+on ECDSA or Schnorr signatures.
+
+## Interfaces
+
+- [AccountContract](interfaces/AccountContract.md)
+- [AccountInterface](interfaces/AccountInterface.md)
+
+## Type Aliases
+
+### Salt
+
+Ƭ **Salt**: `Fr` \| `number` \| `bigint`
+
+A contract deployment salt.
+
+## Functions
+
+### getAccountContractAddress
+
+▸ **getAccountContractAddress**(`accountContract`, `secret`, `salt`): `Promise`\<`AztecAddress`\>
+
+Compute the address of an account contract from secret and salt.
+
+#### Parameters
+
+| Name | Type |
+| :------ | :------ |
+| `accountContract` | [`AccountContract`](interfaces/AccountContract.md) |
+| `secret` | `Fr` |
+| `salt` | `Fr` |
+
+#### Returns
+
+`Promise`\<`AztecAddress`\>
diff --git a/docs/versioned_docs/version-v0.82.2-alpha-testnet.5/developers/reference/aztecjs/aztec-js/interfaces/AccountContract.md b/docs/versioned_docs/version-v0.82.2-alpha-testnet.5/developers/reference/aztecjs/aztec-js/interfaces/AccountContract.md
new file mode 100644
index 000000000000..8e86c77e9efa
--- /dev/null
+++ b/docs/versioned_docs/version-v0.82.2-alpha-testnet.5/developers/reference/aztecjs/aztec-js/interfaces/AccountContract.md
@@ -0,0 +1,75 @@
+---
+id: "AccountContract"
+title: "Interface: AccountContract"
+sidebar_label: "AccountContract"
+sidebar_position: 0
+custom_edit_url: null
+---
+
+An account contract instance. Knows its artifact, deployment arguments, how to create
+transaction execution requests out of function calls, and how to authorize actions.
+
+## Methods
+
+### getAuthWitnessProvider
+
+▸ **getAuthWitnessProvider**(`address`): `AuthWitnessProvider`
+
+Returns the auth witness provider for the given address.
+
+#### Parameters
+
+| Name | Type | Description |
+| :------ | :------ | :------ |
+| `address` | `CompleteAddress` | Address for which to create auth witnesses. |
+
+#### Returns
+
+`AuthWitnessProvider`
+
+___
+
+### getContractArtifact
+
+▸ **getContractArtifact**(): `Promise`\<`ContractArtifact`\>
+
+Returns the artifact of this account contract.
+
+#### Returns
+
+`Promise`\<`ContractArtifact`\>
+
+___
+
+### getDeploymentFunctionAndArgs
+
+▸ **getDeploymentFunctionAndArgs**(): `Promise`\<`undefined` \| \{ `constructorArgs`: `any`[] ; `constructorName`: `string` }\>
+
+Returns the deployment function name and arguments for this instance, or undefined if this contract does not require deployment.
+
+#### Returns
+
+`Promise`\<`undefined` \| \{ `constructorArgs`: `any`[] ; `constructorName`: `string` }\>
+
+___
+
+### getInterface
+
+▸ **getInterface**(`address`, `nodeInfo`): [`AccountInterface`](AccountInterface.md)
+
+Returns the account interface for this account contract given a deployment at the provided address.
+The account interface is responsible for assembling tx requests given requested function calls, and
+for creating signed auth witnesses given action identifiers (message hashes).
+
+#### Parameters
+
+| Name | Type | Description |
+| :------ | :------ | :------ |
+| `address` | `CompleteAddress` | Address where this account contract is deployed. |
+| `nodeInfo` | `NodeInfo` | Info on the chain where it is deployed. |
+
+#### Returns
+
+[`AccountInterface`](AccountInterface.md)
+
+An account interface instance for creating tx requests and authorizing actions.
diff --git a/docs/versioned_docs/version-v0.82.2-alpha-testnet.5/developers/reference/aztecjs/aztec-js/interfaces/AccountInterface.md b/docs/versioned_docs/version-v0.82.2-alpha-testnet.5/developers/reference/aztecjs/aztec-js/interfaces/AccountInterface.md
new file mode 100644
index 000000000000..c2197f036a0f
--- /dev/null
+++ b/docs/versioned_docs/version-v0.82.2-alpha-testnet.5/developers/reference/aztecjs/aztec-js/interfaces/AccountInterface.md
@@ -0,0 +1,116 @@
+---
+id: "AccountInterface"
+title: "Interface: AccountInterface"
+sidebar_label: "AccountInterface"
+sidebar_position: 0
+custom_edit_url: null
+---
+
+Handler for interfacing with an account. Knows how to create transaction execution
+requests and authorize actions for its corresponding account.
+
+## Hierarchy
+
+- `EntrypointInterface`
+
+- `AuthWitnessProvider`
+
+ ↳ **`AccountInterface`**
+
+## Methods
+
+### createAuthWit
+
+▸ **createAuthWit**(`messageHash`): `Promise`\<`AuthWitness`\>
+
+Computes an authentication witness from either a message hash
+
+#### Parameters
+
+| Name | Type | Description |
+| :------ | :------ | :------ |
+| `messageHash` | `Fr` \| `Buffer` | The message hash to approve |
+
+#### Returns
+
+`Promise`\<`AuthWitness`\>
+
+The authentication witness
+
+#### Inherited from
+
+AuthWitnessProvider.createAuthWit
+
+___
+
+### createTxExecutionRequest
+
+▸ **createTxExecutionRequest**(`exec`, `fee`, `options`): `Promise`\<`TxExecutionRequest`\>
+
+Generates an execution request out of set of function calls.
+
+#### Parameters
+
+| Name | Type | Description |
+| :------ | :------ | :------ |
+| `exec` | `ExecutionPayload` | The execution intents to be run. |
+| `fee` | `FeeOptions` | The fee options for the transaction. |
+| `options` | `TxExecutionOptions` | Nonce and whether the transaction is cancellable. |
+
+#### Returns
+
+`Promise`\<`TxExecutionRequest`\>
+
+The authenticated transaction execution request.
+
+#### Inherited from
+
+EntrypointInterface.createTxExecutionRequest
+
+___
+
+### getAddress
+
+▸ **getAddress**(): `AztecAddress`
+
+Returns the address for this account.
+
+#### Returns
+
+`AztecAddress`
+
+___
+
+### getChainId
+
+▸ **getChainId**(): `Fr`
+
+Returns the chain id for this account
+
+#### Returns
+
+`Fr`
+
+___
+
+### getCompleteAddress
+
+▸ **getCompleteAddress**(): `CompleteAddress`
+
+Returns the complete address for this account.
+
+#### Returns
+
+`CompleteAddress`
+
+___
+
+### getVersion
+
+▸ **getVersion**(): `Fr`
+
+Returns the rollup version for this account
+
+#### Returns
+
+`Fr`
diff --git a/docs/versioned_docs/version-v0.82.2-alpha-testnet.5/developers/reference/aztecjs/aztec-js/interfaces/_category_.yml b/docs/versioned_docs/version-v0.82.2-alpha-testnet.5/developers/reference/aztecjs/aztec-js/interfaces/_category_.yml
new file mode 100644
index 000000000000..43bec88cfa0a
--- /dev/null
+++ b/docs/versioned_docs/version-v0.82.2-alpha-testnet.5/developers/reference/aztecjs/aztec-js/interfaces/_category_.yml
@@ -0,0 +1,2 @@
+label: "Interfaces"
+position: 4
\ No newline at end of file
diff --git a/docs/versioned_docs/version-v0.82.2-alpha-testnet.5/developers/reference/aztecjs/pxe/_category_.yml b/docs/versioned_docs/version-v0.82.2-alpha-testnet.5/developers/reference/aztecjs/pxe/_category_.yml
new file mode 100644
index 000000000000..3095e3e72ff8
--- /dev/null
+++ b/docs/versioned_docs/version-v0.82.2-alpha-testnet.5/developers/reference/aztecjs/pxe/_category_.yml
@@ -0,0 +1 @@
+label: "Private Execution Environment (PXE)"
\ No newline at end of file
diff --git a/docs/versioned_docs/version-v0.82.2-alpha-testnet.5/developers/reference/aztecjs/pxe/enums/EventType.md b/docs/versioned_docs/version-v0.82.2-alpha-testnet.5/developers/reference/aztecjs/pxe/enums/EventType.md
new file mode 100644
index 000000000000..338e46d1034e
--- /dev/null
+++ b/docs/versioned_docs/version-v0.82.2-alpha-testnet.5/developers/reference/aztecjs/pxe/enums/EventType.md
@@ -0,0 +1,21 @@
+---
+id: "EventType"
+title: "Enumeration: EventType"
+sidebar_label: "EventType"
+sidebar_position: 0
+custom_edit_url: null
+---
+
+This is used in getting events via the filter
+
+## Enumeration Members
+
+### Encrypted
+
+• **Encrypted** = ``"Encrypted"``
+
+___
+
+### Unencrypted
+
+• **Unencrypted** = ``"Unencrypted"``
diff --git a/docs/versioned_docs/version-v0.82.2-alpha-testnet.5/developers/reference/aztecjs/pxe/enums/_category_.yml b/docs/versioned_docs/version-v0.82.2-alpha-testnet.5/developers/reference/aztecjs/pxe/enums/_category_.yml
new file mode 100644
index 000000000000..1687a9e03fd7
--- /dev/null
+++ b/docs/versioned_docs/version-v0.82.2-alpha-testnet.5/developers/reference/aztecjs/pxe/enums/_category_.yml
@@ -0,0 +1,2 @@
+label: "Enumerations"
+position: 2
\ No newline at end of file
diff --git a/docs/versioned_docs/version-v0.82.2-alpha-testnet.5/developers/reference/aztecjs/pxe/index.md b/docs/versioned_docs/version-v0.82.2-alpha-testnet.5/developers/reference/aztecjs/pxe/index.md
new file mode 100644
index 000000000000..390faf79398f
--- /dev/null
+++ b/docs/versioned_docs/version-v0.82.2-alpha-testnet.5/developers/reference/aztecjs/pxe/index.md
@@ -0,0 +1,38 @@
+---
+id: "index"
+title: "@aztec/stdlib"
+sidebar_label: "Exports"
+sidebar_position: 0.5
+custom_edit_url: null
+---
+
+## Enumerations
+
+- [EventType](enums/EventType.md)
+
+## Interfaces
+
+- [ContractClassMetadata](interfaces/ContractClassMetadata.md)
+- [ContractMetadata](interfaces/ContractMetadata.md)
+- [PXE](interfaces/PXE.md)
+- [PXEInfo](interfaces/PXEInfo.md)
+
+## Type Aliases
+
+### EventMetadataDefinition
+
+Ƭ **EventMetadataDefinition**: `Object`
+
+#### Type declaration
+
+| Name | Type |
+| :------ | :------ |
+| `abiType` | `AbiType` |
+| `eventSelector` | `EventSelector` |
+| `fieldNames` | `string`[] |
+
+## Variables
+
+### PXESchema
+
+• `Const` **PXESchema**: `ApiSchemaFor`\<[`PXE`](interfaces/PXE.md)\>
diff --git a/docs/versioned_docs/version-v0.82.2-alpha-testnet.5/developers/reference/aztecjs/pxe/interfaces/ContractClassMetadata.md b/docs/versioned_docs/version-v0.82.2-alpha-testnet.5/developers/reference/aztecjs/pxe/interfaces/ContractClassMetadata.md
new file mode 100644
index 000000000000..4a152c2a34a9
--- /dev/null
+++ b/docs/versioned_docs/version-v0.82.2-alpha-testnet.5/developers/reference/aztecjs/pxe/interfaces/ContractClassMetadata.md
@@ -0,0 +1,25 @@
+---
+id: "ContractClassMetadata"
+title: "Interface: ContractClassMetadata"
+sidebar_label: "ContractClassMetadata"
+sidebar_position: 0
+custom_edit_url: null
+---
+
+## Properties
+
+### artifact
+
+• `Optional` **artifact**: `ContractArtifact`
+
+___
+
+### contractClass
+
+• `Optional` **contractClass**: `ContractClassWithId`
+
+___
+
+### isContractClassPubliclyRegistered
+
+• **isContractClassPubliclyRegistered**: `boolean`
diff --git a/docs/versioned_docs/version-v0.82.2-alpha-testnet.5/developers/reference/aztecjs/pxe/interfaces/ContractMetadata.md b/docs/versioned_docs/version-v0.82.2-alpha-testnet.5/developers/reference/aztecjs/pxe/interfaces/ContractMetadata.md
new file mode 100644
index 000000000000..7bd09ee675a8
--- /dev/null
+++ b/docs/versioned_docs/version-v0.82.2-alpha-testnet.5/developers/reference/aztecjs/pxe/interfaces/ContractMetadata.md
@@ -0,0 +1,25 @@
+---
+id: "ContractMetadata"
+title: "Interface: ContractMetadata"
+sidebar_label: "ContractMetadata"
+sidebar_position: 0
+custom_edit_url: null
+---
+
+## Properties
+
+### contractInstance
+
+• `Optional` **contractInstance**: `ContractInstanceWithAddress`
+
+___
+
+### isContractInitialized
+
+• **isContractInitialized**: `boolean`
+
+___
+
+### isContractPubliclyDeployed
+
+• **isContractPubliclyDeployed**: `boolean`
diff --git a/docs/versioned_docs/version-v0.82.2-alpha-testnet.5/developers/reference/aztecjs/pxe/interfaces/PXE.md b/docs/versioned_docs/version-v0.82.2-alpha-testnet.5/developers/reference/aztecjs/pxe/interfaces/PXE.md
new file mode 100644
index 000000000000..f3018f0b4047
--- /dev/null
+++ b/docs/versioned_docs/version-v0.82.2-alpha-testnet.5/developers/reference/aztecjs/pxe/interfaces/PXE.md
@@ -0,0 +1,724 @@
+---
+id: "PXE"
+title: "Interface: PXE"
+sidebar_label: "PXE"
+sidebar_position: 0
+custom_edit_url: null
+---
+
+Private eXecution Environment (PXE) runs locally for each user, providing functionality for all the operations
+needed to interact with the Aztec network, including account management, private data management,
+transaction local simulation, and access to an Aztec node. This interface, as part of a Wallet,
+is exposed to dapps for interacting with the network on behalf of the user.
+
+## Methods
+
+### getBlock
+
+▸ **getBlock**(`number`): `Promise`\<`undefined` \| `L2Block`\>
+
+Get the given block.
+
+#### Parameters
+
+| Name | Type | Description |
+| :------ | :------ | :------ |
+| `number` | `number` | The block number being requested. |
+
+#### Returns
+
+`Promise`\<`undefined` \| `L2Block`\>
+
+The blocks requested.
+
+___
+
+### getBlockNumber
+
+▸ **getBlockNumber**(): `Promise`\<`number`\>
+
+Fetches the current block number.
+
+#### Returns
+
+`Promise`\<`number`\>
+
+The block number.
+
+___
+
+### getContractClassLogs
+
+▸ **getContractClassLogs**(`filter`): `Promise`\<`GetContractClassLogsResponse`\>
+
+Gets contract class logs based on the provided filter.
+
+#### Parameters
+
+| Name | Type | Description |
+| :------ | :------ | :------ |
+| `filter` | `LogFilter` | The filter to apply to the logs. |
+
+#### Returns
+
+`Promise`\<`GetContractClassLogsResponse`\>
+
+The requested logs.
+
+___
+
+### getContractClassMetadata
+
+▸ **getContractClassMetadata**(`id`, `includeArtifact?`): `Promise`\<[`ContractClassMetadata`](ContractClassMetadata.md)\>
+
+Returns the contract class metadata given a contract class id.
+The metadata consists of its contract class, whether it has been publicly registered, and its artifact.
+
+#### Parameters
+
+| Name | Type | Description |
+| :------ | :------ | :------ |
+| `id` | `Fr` | Identifier of the class. |
+| `includeArtifact?` | `boolean` | Identifier of the class. |
+
+#### Returns
+
+`Promise`\<[`ContractClassMetadata`](ContractClassMetadata.md)\>
+
+- It returns the contract class metadata, with the artifact field being optional, and will only be returned if true is passed in
+for `includeArtifact`
+TODO(@spalladino): The PXE actually holds artifacts and not classes, what should we return? Also,
+should the pxe query the node for contract public info, and merge it with its own definitions?
+TODO(@spalladino): This method is strictly needed to decide whether to publicly register a class or not
+during a public deployment. We probably want a nicer and more general API for this, but it'll have to
+do for the time being.
+
+**`Remark`**
+
+- it queries the node to check whether the contract class with the given id has been publicly registered.
+
+___
+
+### getContractMetadata
+
+▸ **getContractMetadata**(`address`): `Promise`\<[`ContractMetadata`](ContractMetadata.md)\>
+
+Returns the contract metadata given an address.
+The metadata consists of its contract instance, which includes the contract class identifier,
+initialization hash, deployment salt, and public keys hash; whether the contract instance has been initialized;
+and whether the contract instance with the given address has been publicly deployed.
+
+#### Parameters
+
+| Name | Type | Description |
+| :------ | :------ | :------ |
+| `address` | `AztecAddress` | The address that the contract instance resides at. |
+
+#### Returns
+
+`Promise`\<[`ContractMetadata`](ContractMetadata.md)\>
+
+- It returns the contract metadata
+TODO(@spalladino): Should we return the public keys in plain as well here?
+
+**`Remark`**
+
+- it queries the node to check whether the contract instance has been initialized / publicly deployed through a node.
+This query is not dependent on the PXE.
+
+___
+
+### getContracts
+
+▸ **getContracts**(): `Promise`\<`AztecAddress`[]\>
+
+Retrieves the addresses of contracts added to this PXE Service.
+
+#### Returns
+
+`Promise`\<`AztecAddress`[]\>
+
+An array of contracts addresses registered on this PXE Service.
+
+___
+
+### getCurrentBaseFees
+
+▸ **getCurrentBaseFees**(): `Promise`\<`GasFees`\>
+
+Method to fetch the current base fees.
+
+#### Returns
+
+`Promise`\<`GasFees`\>
+
+The current base fees.
+
+___
+
+### getL1ToL2MembershipWitness
+
+▸ **getL1ToL2MembershipWitness**(`contractAddress`, `messageHash`, `secret`): `Promise`\<[`bigint`, `SiblingPath`\<``39``\>]\>
+
+Fetches an L1 to L2 message from the node.
+
+#### Parameters
+
+| Name | Type | Description |
+| :------ | :------ | :------ |
+| `contractAddress` | `AztecAddress` | Address of a contract by which the message was emitted. |
+| `messageHash` | `Fr` | Hash of the message. |
+| `secret` | `Fr` | Secret used to compute a nullifier. |
+
+#### Returns
+
+`Promise`\<[`bigint`, `SiblingPath`\<``39``\>]\>
+
+The l1 to l2 membership witness (index of message in the tree and sibling path).
+
+**`Dev`**
+
+Contract address and secret are only used to compute the nullifier to get non-nullified messages
+
+___
+
+### getL2ToL1MembershipWitness
+
+▸ **getL2ToL1MembershipWitness**(`blockNumber`, `l2Tol1Message`): `Promise`\<[`bigint`, `SiblingPath`\<`number`\>]\>
+
+Gets the membership witness for a message that was emitted at a particular block
+
+#### Parameters
+
+| Name | Type | Description |
+| :------ | :------ | :------ |
+| `blockNumber` | `number` | The block number in which to search for the message |
+| `l2Tol1Message` | `Fr` | The message to search for |
+
+#### Returns
+
+`Promise`\<[`bigint`, `SiblingPath`\<`number`\>]\>
+
+The membership witness for the message
+
+___
+
+### getNodeInfo
+
+▸ **getNodeInfo**(): `Promise`\<`NodeInfo`\>
+
+Returns the information about the server's node. Includes current Node version, compatible Noir version,
+L1 chain identifier, protocol version, and L1 address of the rollup contract.
+
+#### Returns
+
+`Promise`\<`NodeInfo`\>
+
+- The node information.
+
+___
+
+### getNotes
+
+▸ **getNotes**(`filter`): `Promise`\<`UniqueNote`[]\>
+
+Gets notes registered in this PXE based on the provided filter.
+
+#### Parameters
+
+| Name | Type | Description |
+| :------ | :------ | :------ |
+| `filter` | `NotesFilter` | The filter to apply to the notes. |
+
+#### Returns
+
+`Promise`\<`UniqueNote`[]\>
+
+The requested notes.
+
+___
+
+### getPXEInfo
+
+▸ **getPXEInfo**(): `Promise`\<[`PXEInfo`](PXEInfo.md)\>
+
+Returns information about this PXE.
+
+#### Returns
+
+`Promise`\<[`PXEInfo`](PXEInfo.md)\>
+
+___
+
+### getPrivateEvents
+
+▸ **getPrivateEvents**\<`T`\>(`eventMetadata`, `from`, `limit`, `vpks`): `Promise`\<`T`[]\>
+
+Returns the private events given search parameters.
+
+#### Type parameters
+
+| Name |
+| :------ |
+| `T` |
+
+#### Parameters
+
+| Name | Type | Description |
+| :------ | :------ | :------ |
+| `eventMetadata` | [`EventMetadataDefinition`](../#eventmetadatadefinition) | Metadata of the event. This should be the class generated from the contract. e.g. Contract.events.Event |
+| `from` | `number` | The block number to search from. |
+| `limit` | `number` | The amount of blocks to search. |
+| `vpks` | `Point`[] | The incoming viewing public keys that can decrypt the log. |
+
+#### Returns
+
+`Promise`\<`T`[]\>
+
+- The deserialized events.
+
+___
+
+### getProvenBlockNumber
+
+▸ **getProvenBlockNumber**(): `Promise`\<`number`\>
+
+Fetches the current proven block number.
+
+#### Returns
+
+`Promise`\<`number`\>
+
+The block number.
+
+___
+
+### getPublicEvents
+
+▸ **getPublicEvents**\<`T`\>(`eventMetadata`, `from`, `limit`): `Promise`\<`T`[]\>
+
+Returns the public events given search parameters.
+
+#### Type parameters
+
+| Name |
+| :------ |
+| `T` |
+
+#### Parameters
+
+| Name | Type | Description |
+| :------ | :------ | :------ |
+| `eventMetadata` | [`EventMetadataDefinition`](../#eventmetadatadefinition) | Metadata of the event. This should be the class generated from the contract. e.g. Contract.events.Event |
+| `from` | `number` | The block number to search from. |
+| `limit` | `number` | The amount of blocks to search. |
+
+#### Returns
+
+`Promise`\<`T`[]\>
+
+- The deserialized events.
+
+___
+
+### getPublicLogs
+
+▸ **getPublicLogs**(`filter`): `Promise`\<`GetPublicLogsResponse`\>
+
+Gets public logs based on the provided filter.
+
+#### Parameters
+
+| Name | Type | Description |
+| :------ | :------ | :------ |
+| `filter` | `LogFilter` | The filter to apply to the logs. |
+
+#### Returns
+
+`Promise`\<`GetPublicLogsResponse`\>
+
+The requested logs.
+
+___
+
+### getPublicStorageAt
+
+▸ **getPublicStorageAt**(`contract`, `slot`): `Promise`\<`Fr`\>
+
+Gets the storage value at the given contract storage slot.
+
+#### Parameters
+
+| Name | Type | Description |
+| :------ | :------ | :------ |
+| `contract` | `AztecAddress` | Address of the contract to query. |
+| `slot` | `Fr` | Slot to query. |
+
+#### Returns
+
+`Promise`\<`Fr`\>
+
+Storage value at the given contract slot.
+
+**`Remarks`**
+
+The storage slot here refers to the slot as it is defined in Noir not the index in the merkle tree.
+Aztec's version of `eth_getStorageAt`.
+
+**`Throws`**
+
+If the contract is not deployed.
+
+___
+
+### getRegisteredAccounts
+
+▸ **getRegisteredAccounts**(): `Promise`\<`CompleteAddress`[]\>
+
+Retrieves the user accounts registered on this PXE Service.
+
+#### Returns
+
+`Promise`\<`CompleteAddress`[]\>
+
+An array of the accounts registered on this PXE Service.
+
+___
+
+### getSenders
+
+▸ **getSenders**(): `Promise`\<`AztecAddress`[]\>
+
+Retrieves the addresses stored as senders on this PXE Service.
+
+#### Returns
+
+`Promise`\<`AztecAddress`[]\>
+
+An array of the senders on this PXE Service.
+
+___
+
+### getTxEffect
+
+▸ **getTxEffect**(`txHash`): `Promise`\<`undefined` \| `InBlock`\<`TxEffect`\>\>
+
+Get a tx effect.
+
+#### Parameters
+
+| Name | Type | Description |
+| :------ | :------ | :------ |
+| `txHash` | `TxHash` | The hash of a transaction which resulted in the returned tx effect. |
+
+#### Returns
+
+`Promise`\<`undefined` \| `InBlock`\<`TxEffect`\>\>
+
+The requested tx effect.
+
+___
+
+### getTxReceipt
+
+▸ **getTxReceipt**(`txHash`): `Promise`\<`TxReceipt`\>
+
+Fetches a transaction receipt for a given transaction hash. Returns a mined receipt if it was added
+to the chain, a pending receipt if it's still in the mempool of the connected Aztec node, or a dropped
+receipt if not found in the connected Aztec node.
+
+#### Parameters
+
+| Name | Type | Description |
+| :------ | :------ | :------ |
+| `txHash` | `TxHash` | The transaction hash. |
+
+#### Returns
+
+`Promise`\<`TxReceipt`\>
+
+A receipt of the transaction.
+
+___
+
+### isL1ToL2MessageSynced
+
+▸ **isL1ToL2MessageSynced**(`l1ToL2Message`): `Promise`\<`boolean`\>
+
+Returns whether an L1 to L2 message is synced by archiver and if it's ready to be included in a block.
+
+#### Parameters
+
+| Name | Type | Description |
+| :------ | :------ | :------ |
+| `l1ToL2Message` | `Fr` | The L1 to L2 message to check. |
+
+#### Returns
+
+`Promise`\<`boolean`\>
+
+Whether the message is synced and ready to be included in a block.
+
+___
+
+### profileTx
+
+▸ **profileTx**(`txRequest`, `profileMode`, `msgSender?`): `Promise`\<`TxProfileResult`\>
+
+Profiles a transaction, reporting gate counts (unless disabled) and returns an execution trace.
+
+#### Parameters
+
+| Name | Type | Description |
+| :------ | :------ | :------ |
+| `txRequest` | `TxExecutionRequest` | An authenticated tx request ready for simulation |
+| `profileMode` | ``"gates"`` \| ``"execution-steps"`` \| ``"full"`` | - |
+| `msgSender?` | `AztecAddress` | (Optional) The message sender to use for the simulation. |
+
+#### Returns
+
+`Promise`\<`TxProfileResult`\>
+
+A trace of the program execution with gate counts.
+
+**`Throws`**
+
+If the code for the functions executed in this transaction have not been made available via `addContracts`.
+
+___
+
+### proveTx
+
+▸ **proveTx**(`txRequest`, `privateExecutionResult`): `Promise`\<`TxProvingResult`\>
+
+Proves the private portion of a simulated transaction, ready to send to the network
+(where valiators prove the public portion).
+
+#### Parameters
+
+| Name | Type | Description |
+| :------ | :------ | :------ |
+| `txRequest` | `TxExecutionRequest` | An authenticated tx request ready for proving |
+| `privateExecutionResult` | `PrivateExecutionResult` | The result of the private execution of the transaction |
+
+#### Returns
+
+`Promise`\<`TxProvingResult`\>
+
+A result containing the proof and public inputs of the tail circuit.
+
+**`Throws`**
+
+If contract code not found, or public simulation reverts.
+Also throws if simulatePublic is true and public simulation reverts.
+
+___
+
+### registerAccount
+
+▸ **registerAccount**(`secretKey`, `partialAddress`): `Promise`\<`CompleteAddress`\>
+
+Registers a user account in PXE given its master encryption private key.
+Once a new account is registered, the PXE Service will trial-decrypt all published notes on
+the chain and store those that correspond to the registered account. Will do nothing if the
+account is already registered.
+
+#### Parameters
+
+| Name | Type | Description |
+| :------ | :------ | :------ |
+| `secretKey` | `Fr` | Secret key of the corresponding user master public key. |
+| `partialAddress` | `Fr` | The partial address of the account contract corresponding to the account being registered. |
+
+#### Returns
+
+`Promise`\<`CompleteAddress`\>
+
+The complete address of the account.
+
+___
+
+### registerContract
+
+▸ **registerContract**(`contract`): `Promise`\<`void`\>
+
+Adds deployed contracts to the PXE Service. Deployed contract information is used to access the
+contract code when simulating local transactions. This is automatically called by aztec.js when
+deploying a contract. Dapps that wish to interact with contracts already deployed should register
+these contracts in their users' PXE Service through this method.
+
+#### Parameters
+
+| Name | Type | Description |
+| :------ | :------ | :------ |
+| `contract` | `Object` | A contract instance to register, with an optional artifact which can be omitted if the contract class has already been registered. |
+| `contract.artifact?` | `ContractArtifact` | - |
+| `contract.instance` | `ContractInstanceWithAddress` | - |
+
+#### Returns
+
+`Promise`\<`void`\>
+
+___
+
+### registerContractClass
+
+▸ **registerContractClass**(`artifact`): `Promise`\<`void`\>
+
+Registers a contract class in the PXE without registering any associated contract instance with it.
+
+#### Parameters
+
+| Name | Type | Description |
+| :------ | :------ | :------ |
+| `artifact` | `ContractArtifact` | The build artifact for the contract class. |
+
+#### Returns
+
+`Promise`\<`void`\>
+
+___
+
+### registerSender
+
+▸ **registerSender**(`address`): `Promise`\<`AztecAddress`\>
+
+Registers a user contact in PXE.
+
+Once a new contact is registered, the PXE Service will be able to receive notes tagged from this contact.
+Will do nothing if the account is already registered.
+
+#### Parameters
+
+| Name | Type | Description |
+| :------ | :------ | :------ |
+| `address` | `AztecAddress` | Address of the user to add to the address book |
+
+#### Returns
+
+`Promise`\<`AztecAddress`\>
+
+The address address of the account.
+
+___
+
+### removeSender
+
+▸ **removeSender**(`address`): `Promise`\<`void`\>
+
+Removes a sender in the address book.
+
+#### Parameters
+
+| Name | Type |
+| :------ | :------ |
+| `address` | `AztecAddress` |
+
+#### Returns
+
+`Promise`\<`void`\>
+
+___
+
+### sendTx
+
+▸ **sendTx**(`tx`): `Promise`\<`TxHash`\>
+
+Sends a transaction to an Aztec node to be broadcasted to the network and mined.
+
+#### Parameters
+
+| Name | Type | Description |
+| :------ | :------ | :------ |
+| `tx` | `Tx` | The transaction as created via `proveTx`. |
+
+#### Returns
+
+`Promise`\<`TxHash`\>
+
+A hash of the transaction, used to identify it.
+
+___
+
+### simulateTx
+
+▸ **simulateTx**(`txRequest`, `simulatePublic`, `msgSender?`, `skipTxValidation?`, `skipFeeEnforcement?`, `scopes?`): `Promise`\<`TxSimulationResult`\>
+
+Simulates a transaction based on the provided preauthenticated execution request.
+This will run a local simulation of private execution (and optionally of public as well), run the
+kernel circuits to ensure adherence to protocol rules (without generating a proof), and return the
+simulation results .
+
+Note that this is used with `ContractFunctionInteraction::simulateTx` to bypass certain checks.
+In that case, the transaction returned is only potentially ready to be sent to the network for execution.
+
+#### Parameters
+
+| Name | Type | Description |
+| :------ | :------ | :------ |
+| `txRequest` | `TxExecutionRequest` | An authenticated tx request ready for simulation |
+| `simulatePublic` | `boolean` | Whether to simulate the public part of the transaction. |
+| `msgSender?` | `AztecAddress` | (Optional) The message sender to use for the simulation. |
+| `skipTxValidation?` | `boolean` | (Optional) If false, this function throws if the transaction is unable to be included in a block at the current state. |
+| `skipFeeEnforcement?` | `boolean` | (Optional) If false, fees are enforced. |
+| `scopes?` | `AztecAddress`[] | (Optional) The accounts whose notes we can access in this call. Currently optional and will default to all. |
+
+#### Returns
+
+`Promise`\<`TxSimulationResult`\>
+
+A simulated transaction result object that includes public and private return values.
+
+**`Throws`**
+
+If the code for the functions executed in this transaction have not been made available via `addContracts`.
+Also throws if simulatePublic is true and public simulation reverts.
+
+___
+
+### simulateUnconstrained
+
+▸ **simulateUnconstrained**(`functionName`, `args`, `to`, `authwits?`, `from?`, `scopes?`): `Promise`\<`AbiDecoded`\>
+
+Simulate the execution of an unconstrained function on a deployed contract without actually modifying state.
+This is useful to inspect contract state, for example fetching a variable value or calling a getter function.
+The function takes function name and arguments as parameters, along with the contract address
+and optionally the sender's address.
+
+#### Parameters
+
+| Name | Type | Description |
+| :------ | :------ | :------ |
+| `functionName` | `string` | The name of the function to be called in the contract. |
+| `args` | `any`[] | The arguments to be provided to the function. |
+| `to` | `AztecAddress` | The address of the contract to be called. |
+| `authwits?` | `AuthWitness`[] | - |
+| `from?` | `AztecAddress` | (Optional) The msg sender to set for the call. |
+| `scopes?` | `AztecAddress`[] | (Optional) The accounts whose notes we can access in this call. Currently optional and will default to all. |
+
+#### Returns
+
+`Promise`\<`AbiDecoded`\>
+
+The result of the view function call, structured based on the function ABI.
+
+___
+
+### updateContract
+
+▸ **updateContract**(`contractAddress`, `artifact`): `Promise`\<`void`\>
+
+Updates a deployed contract in the PXE Service. This is used to update the contract artifact when
+an update has happened, so the new code can be used in the simulation of local transactions.
+This is called by aztec.js when instantiating a contract in a given address with a mismatching artifact.
+
+#### Parameters
+
+| Name | Type | Description |
+| :------ | :------ | :------ |
+| `contractAddress` | `AztecAddress` | The address of the contract to update. |
+| `artifact` | `ContractArtifact` | The updated artifact for the contract. |
+
+#### Returns
+
+`Promise`\<`void`\>
diff --git a/docs/versioned_docs/version-v0.82.2-alpha-testnet.5/developers/reference/aztecjs/pxe/interfaces/PXEInfo.md b/docs/versioned_docs/version-v0.82.2-alpha-testnet.5/developers/reference/aztecjs/pxe/interfaces/PXEInfo.md
new file mode 100644
index 000000000000..b34b5866adef
--- /dev/null
+++ b/docs/versioned_docs/version-v0.82.2-alpha-testnet.5/developers/reference/aztecjs/pxe/interfaces/PXEInfo.md
@@ -0,0 +1,25 @@
+---
+id: "PXEInfo"
+title: "Interface: PXEInfo"
+sidebar_label: "PXEInfo"
+sidebar_position: 0
+custom_edit_url: null
+---
+
+Provides basic information about the running PXE.
+
+## Properties
+
+### protocolContractAddresses
+
+• **protocolContractAddresses**: `ProtocolContractAddresses`
+
+Protocol contract addresses
+
+___
+
+### pxeVersion
+
+• **pxeVersion**: `string`
+
+Version as tracked in the aztec-packages repository.
diff --git a/docs/versioned_docs/version-v0.82.2-alpha-testnet.5/developers/reference/aztecjs/pxe/interfaces/_category_.yml b/docs/versioned_docs/version-v0.82.2-alpha-testnet.5/developers/reference/aztecjs/pxe/interfaces/_category_.yml
new file mode 100644
index 000000000000..43bec88cfa0a
--- /dev/null
+++ b/docs/versioned_docs/version-v0.82.2-alpha-testnet.5/developers/reference/aztecjs/pxe/interfaces/_category_.yml
@@ -0,0 +1,2 @@
+label: "Interfaces"
+position: 4
\ No newline at end of file
diff --git a/docs/versioned_docs/version-v0.82.2-alpha-testnet.5/developers/reference/considerations/_category_.json b/docs/versioned_docs/version-v0.82.2-alpha-testnet.5/developers/reference/considerations/_category_.json
new file mode 100644
index 000000000000..3d16e4d09376
--- /dev/null
+++ b/docs/versioned_docs/version-v0.82.2-alpha-testnet.5/developers/reference/considerations/_category_.json
@@ -0,0 +1,6 @@
+{
+ "label": "Considerations and Limitations",
+ "position": 4,
+ "collapsible": true,
+ "collapsed": true
+}
diff --git a/docs/versioned_docs/version-v0.82.2-alpha-testnet.5/developers/reference/considerations/limitations.md b/docs/versioned_docs/version-v0.82.2-alpha-testnet.5/developers/reference/considerations/limitations.md
new file mode 100644
index 000000000000..5dbcc7346797
--- /dev/null
+++ b/docs/versioned_docs/version-v0.82.2-alpha-testnet.5/developers/reference/considerations/limitations.md
@@ -0,0 +1,328 @@
+---
+title: Limitations
+sidebar_position: 6
+tags: [sandbox]
+---
+
+The Aztec Sandbox and the Aztec Smart Contract Library are **prototypes**, and should be treated as such. They've been released early, to gather feedback on the capabilities of the protocol and user experiences.
+
+## What to expect?
+
+- Regular Breaking Changes;
+- Missing features;
+- Bugs;
+- An 'unpolished' UX;
+- Missing information.
+
+## Why participate?
+
+Front-run the future!
+
+Help shape and define:
+
+- Previously-impossible smart contracts and applications
+- Network tooling;
+- Network standards;
+- Smart contract syntax;
+- Educational content;
+- Core protocol improvements;
+
+## Limitations developers need to know about
+
+- It is a testing environment, it is insecure, unaudited and does not generate any proofs, its only for testing purposes;
+- Constructors can not call nor alter public state
+ - The constructor is executed exclusively in private domain, WITHOUT the ability to call public functions or alter public state. This means to set initial storage values, you need to follow a pattern similar to [proxies in Ethereum](https://blog.openzeppelin.com/proxy-patterns), where you `initialize` the contract with values after it have been deployed.
+ - Beware that what you think of as a `view` could alter state ATM! Notably the account could alter state or re-enter whenever the account contract's `is_valid` function is called.
+- `msg_sender` is currently leaking when doing private -> public calls
+ - The `msg_sender` will always be set, if you call a public function from the private world, the `msg_sender` will be set to the private caller's address.
+- The initial `msg_sender` is 0, which can be problematic for some contracts.
+- Unencrypted logs don't link to the contract that emitted it, so essentially just a `debug_log`` that you can match values against.
+- A note that is created and nullified in the same transaction will still emit an encrypted log.
+- A limited amount of new note hashes, nullifiers and calls that are supported by a transaction, see [circuit limitations](#circuit-limitations).
+
+## Limitations
+
+There are plans to resolve all of the below.
+
+### It is not audited
+
+None of the Sandbox code is audited. It's being iterated-on every day. It will not be audited for quite some time.
+
+### No Proofs
+
+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.
+
+#### What are the consequences?
+
+By the time mainnet comes around, zk-SNARKs will be needed in order to validate the correctness of every function that's executed on Aztec. In other words, in order for the execution of a function to be registered as part of the Aztec blockchain's history, a proof of correct execution will need to be furnished. Each proof will be an attestation that the rules of a particular function were followed correctly.
+
+But proofs are really only needed as a protection against malicious behavior. The Sandbox is an emulated ecosystem; entirely contained within your laptop, and it follows the network's rules out of the box. So as long as its inner workings aren't tampered-with, it will act 'honestly'. Since you'll be the only person interacting with the Sandbox on your own laptop, and with a healthy assumption that you should be honest with yourself, you won't need proofs when testing.
+
+### No Circuits!
+
+This is kind-of a repetition of ['No Proofs!'](#no-proofs) above, but for the sake of clarity, there aren't yet any arithmetic circuits in the Sandbox. We might refer to certain components of the core protocol as being 'circuits', and we might refer to user-defined smart contract functions as being compiled to 'circuits', but the Sandbox doesn't actually contain any circuits yet. Instead, there is code which emulates the logic of a circuit. This is intentional, to make execution of the Sandbox as fast as possible.
+
+Obviously, as development continues, the so-called 'circuits' will actually become proper circuits, and actual proofs will be generated.
+
+#### What are the consequences?
+
+The Sandbox will execute more quickly. The logic of all 'circuits' is still in place*. Smart contract logic will be executed, and core protocol logic will be executed*. So invalid transactions will be caught\* and rejected.
+
+\*Note: some core protocol circuit assertions and constraints still need to be written (see [GitHub](https://github.com/AztecProtocol/aztec-packages/issues)). This would be bad in an adversarial environment, but the Sandbox is not that. Naturally, proper circuits will need to be written.
+
+### No Fees!
+
+That's right, there are no L2 network fees yet!
+
+The Sandbox can currently be thought of as a bare-minimum execution layer. We'll be speccing and implementing gas metering and fees soon!
+
+> Note: there is still a notion of an L1 fee in the Sandbox, because it uses Anvil to emulate the Ethereum blockchain.
+
+#### What are the consequences?
+
+Apps won't yet be able to allow for any L2 fee logic. Once fees are introduced, this will cause breaking changes to in-progress apps, which will need to be updated to accommodate the notion of paying network fees for transactions. Clear documentation will be provided.
+
+### Basic Keys and Addresses!
+
+The way in which keypairs and addresses are currently derived and implemented (inside the Sandbox) is greatly over-simplified, relative to future plans.
+
+They're so over-simplified that they're known to be insecure. Other features have been prioritized so-far in Sandbox development.
+
+#### What are the consequences?
+
+This will impact the kinds of apps that you can build with the Sandbox, as it is today:
+
+- The management of keys when designing account contracts and wallets will be affected.
+- The keys used when generating nullifiers will be affected. (Although the machinery relating to nullifiers is mostly abstracted away from developers who use Aztec.nr.
+ - In particular the current, over-simplified key derivation scheme is known to be **insecure**:
+ - Currently, the same nullifier secret key is used by _every_ smart contract on the network. This would enable malicious apps to trivially emit a user's nullifier secret key to the world!
+ - In future, there are detailed plans to 'silo' a nullifier key per contract address (and per user), to fix this obvious vulnerability.
+- The keys used when encrypting and decrypting logs will be affected.
+ - In particular the current, over-simplified key derivation scheme is known to be **insecure**:
+ - Currently, a user's nullifier secret key is the same as their encryption secret key. And as stated above, this would enable malicious apps to trivially emit a user's secret key to the world!
+ - In future there are also plans to have incoming and outgoing viewing keys, inspired by [ZCash Sapling](https://electriccoin.co/blog/explaining-viewing-keys/).
+ - If developers wish to design apps which incorporate certain auditability patterns, the current over-simplification of keys might not be sufficient.
+
+Please open new discussions on [discourse](http://discourse.aztec.network) or open issues on [github](http://github.com/AztecProtocol/aztec-packages), if you have requirements that aren't-yet being met by the Sandbox's current key derivation scheme.
+
+### It's not-yet decentralized
+
+It's an emulated blockchain entirely contained within your own laptop! It's centralized by design!
+As for deploying this all to mainnet, a decentralized sequencer selection and prover selection protocols are still [being discussed](https://discourse.aztec.network/t/request-for-proposals-decentralized-sequencer-selection/350). There are plans for decentralized testnets in 2024.
+
+### You can't read mutable public state from a private function
+
+Private smart contract functions won't be able to read mutable public state yet. We have some [ideas](https://discourse.aztec.network/t/accessing-historic-public-state-from-private-functions/241/7?u=mike) for how to solve this, and will look to implement something very soon.
+
+#### What are the consequences?
+
+Reading public state from a private contract will be a common pattern. For example, it's needed if you want to maintain a public whitelist/blacklist, but prove you are/aren't on that blacklist privately. This will be a high priority, coming soon.
+
+### No delegatecalls
+
+A contract can't perform a delegatecall yet (if ever). Delegatecalls are quite a controversial feature of the EVM.
+
+### No privacy-preserving queries to nodes
+
+Ethereum has a notion of a 'full node' which keeps-up with the blockchain and stores the full chain state. Many users don't wish to run full nodes, so rely on 3rd-party 'full-node-as-a-service' infrastructure providers, who service blockchain queries from their users.
+
+This pattern is likely to develop in Aztec as well, except there's a problem: privacy. If a privacy-seeking user makes a query to a 3rd-party 'full node', that user might leak data about who they are, or about their historical network activity, or about their future intentions. One solution to this problem is "always run a full node", but pragmatically, not everyone will. To protect less-advanced users' privacy, research is underway to explore how a privacy-seeking user may request and receive data from a 3rd-party node without revealing what that data is, nor who is making the request.
+
+### No private data authentication
+
+Private data should not be returned to an app, unless the user authorizes such access to the app. An authorization layer is not-yet in place.
+
+#### What are the consequences?
+
+Any app can request and receive any private user data relating to any other private app. Obviously this sounds bad. But the Sandbox is a sandbox, and no meaningful value or credentials should be stored there; only test values and test credentials.
+
+An auth layer will be added in due course.
+
+### No bytecode validation
+
+Bytecode should not be executed, unless the Sandbox has validated that the user's intentions (the function signature and contract address) match the bytecode.
+
+#### What are the consequences?
+
+Without such 'bytecode validation', if the incorrect bytecode is executed, and that bytecode is malicious, it could read private data from some other contract and emit that private data to the world. Obviously this would be bad in production. But the Sandbox is a sandbox, and no meaningful value or credentials should be stored there; only test values and test credentials.
+
+There are plans to add bytecode validation soon.
+
+### Insecure hashes
+
+Currently, Pedersen hashes are being used pretty-much everywhere. To any cryptographers reading this, don't panic. A thorough review of which hashes to use in which part of the protocol will be conducted soon.
+
+Additionally, domain separation of hashes needs some review.
+
+#### What are the consequences?
+
+Collisions and other hash-related attacks might be possible in the Sandbox. Obviously that would be bad in production. But it's unlikely to cause problems at this early stage of testing.
+
+### `msg_sender` is leaked when making a private -> public call
+
+There are [ongoing discussions](https://discourse.aztec.network/t/who-is-msg-sender-when-making-private-public-function-calls/242) around how to address this.
+
+#### What are the consequences?
+
+When a private function makes a call to a public function, the `msg_sender` of the calling function will be given to the public world. Most critically, this includes if the `msg_sender` is an account contract.
+This will be patched in the near future, but unfortunately, app developers might need to 'overlook' this privacy leakage until then, with the assumption that it will be fixed. But note, one possible 'patch' might be to set `msg_sender` to `0` for all private -> public calls. This might cause breaking changes to your public functions, if they rely on reading `msg_sender`. There are patterns to work around this, but they wouldn't be pretty, and we won't go into details until a solution is chosen. Sorry about this, and thanks for your patience whilst we work this out :)
+
+### New Privacy Standards are required
+
+There are many [patterns](../../reference/considerations/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'](../../reference/considerations/privacy_considerations.md#function-fingerprints-and-tx-fingerprints) app developers might accidentally forfeit some function privacy.
+
+## Circuit limitations
+
+### Upper limits on function outputs and tx outputs
+
+Due to the rigidity of zk-SNARK circuits, there are upper bounds on the amount of computation a circuit can perform, and on the amount of data that can be passed into and out of a function.
+
+> Blockchain developers are no stranger to restrictive computational environments. Ethereum has gas limits, local variable stack limits, call stack limits, contract deployment size limits, log size limits, etc.
+
+Here are the current constants:
+
+```rust title="constants" showLineNumbers
+// "PER CALL" CONSTANTS
+pub global MAX_NOTE_HASHES_PER_CALL: u32 = 16;
+pub global MAX_NULLIFIERS_PER_CALL: u32 = 16;
+pub global MAX_PRIVATE_CALL_STACK_LENGTH_PER_CALL: u32 = 5;
+pub global MAX_ENQUEUED_CALLS_PER_CALL: u32 = 16;
+pub global MAX_L2_TO_L1_MSGS_PER_CALL: u32 = 2;
+pub global MAX_PUBLIC_DATA_UPDATE_REQUESTS_PER_CALL: u32 = 63;
+pub global MAX_PUBLIC_DATA_READS_PER_CALL: u32 = 64;
+pub global MAX_NOTE_HASH_READ_REQUESTS_PER_CALL: u32 = 16;
+pub global MAX_NULLIFIER_READ_REQUESTS_PER_CALL: u32 = 16;
+pub global MAX_NULLIFIER_NON_EXISTENT_READ_REQUESTS_PER_CALL: u32 = 16;
+pub global MAX_L1_TO_L2_MSG_READ_REQUESTS_PER_CALL: u32 = 16;
+pub global MAX_KEY_VALIDATION_REQUESTS_PER_CALL: u32 = 16;
+pub global MAX_PRIVATE_LOGS_PER_CALL: u32 = 16;
+pub global MAX_PUBLIC_LOGS_PER_CALL: u32 = 4;
+pub global MAX_CONTRACT_CLASS_LOGS_PER_CALL: u32 = 1;
+
+// TREES RELATED CONSTANTS
+pub global ARCHIVE_HEIGHT: u32 = 29;
+pub global VK_TREE_HEIGHT: u32 = 6;
+pub global PROTOCOL_CONTRACT_TREE_HEIGHT: u32 = 3;
+pub global FUNCTION_TREE_HEIGHT: u32 = 5;
+pub global NOTE_HASH_TREE_HEIGHT: u32 = 40;
+pub global PUBLIC_DATA_TREE_HEIGHT: u32 = 40;
+pub global NULLIFIER_TREE_HEIGHT: u32 = 40;
+pub global L1_TO_L2_MSG_TREE_HEIGHT: u32 = 39;
+pub global ARTIFACT_FUNCTION_TREE_MAX_HEIGHT: u32 = 5;
+pub global NULLIFIER_TREE_ID: Field = 0;
+pub global NOTE_HASH_TREE_ID: Field = 1;
+pub global PUBLIC_DATA_TREE_ID: Field = 2;
+pub global L1_TO_L2_MESSAGE_TREE_ID: Field = 3;
+pub global ARCHIVE_TREE_ID: Field = 4;
+
+// SUB-TREES RELATED CONSTANTS
+pub global NOTE_HASH_SUBTREE_HEIGHT: u32 = 6;
+pub global NULLIFIER_SUBTREE_HEIGHT: u32 = 6;
+// Deprecated: to be removed after removal of legacy ts trees
+pub global PUBLIC_DATA_SUBTREE_HEIGHT: u32 = 6;
+pub global L1_TO_L2_MSG_SUBTREE_HEIGHT: u32 = 4;
+pub global NOTE_HASH_SUBTREE_SIBLING_PATH_LENGTH: u32 =
+ NOTE_HASH_TREE_HEIGHT - NOTE_HASH_SUBTREE_HEIGHT;
+pub global NULLIFIER_SUBTREE_SIBLING_PATH_LENGTH: u32 =
+ NULLIFIER_TREE_HEIGHT - NULLIFIER_SUBTREE_HEIGHT;
+pub global L1_TO_L2_MSG_SUBTREE_SIBLING_PATH_LENGTH: u32 =
+ L1_TO_L2_MSG_TREE_HEIGHT - L1_TO_L2_MSG_SUBTREE_HEIGHT;
+
+// "PER TRANSACTION" CONSTANTS
+pub global MAX_NOTE_HASHES_PER_TX: u32 = (1 as u8 << NOTE_HASH_SUBTREE_HEIGHT as u8) as u32;
+pub global MAX_NULLIFIERS_PER_TX: u32 = (1 as u8 << NULLIFIER_SUBTREE_HEIGHT as u8) as u32;
+pub global MAX_PRIVATE_CALL_STACK_LENGTH_PER_TX: u32 = 8;
+pub global MAX_ENQUEUED_CALLS_PER_TX: u32 = 32;
+pub global PROTOCOL_PUBLIC_DATA_UPDATE_REQUESTS_PER_TX: u32 = 1;
+pub global MAX_TOTAL_PUBLIC_DATA_UPDATE_REQUESTS_PER_TX: u32 =
+ (1 as u8 << PUBLIC_DATA_SUBTREE_HEIGHT as u8) as u32;
+pub global MAX_PUBLIC_DATA_UPDATE_REQUESTS_PER_TX: u32 =
+ MAX_TOTAL_PUBLIC_DATA_UPDATE_REQUESTS_PER_TX - PROTOCOL_PUBLIC_DATA_UPDATE_REQUESTS_PER_TX;
+pub global MAX_PUBLIC_DATA_READS_PER_TX: u32 = 64;
+pub global MAX_L2_TO_L1_MSGS_PER_TX: u32 = 8;
+pub global MAX_NOTE_HASH_READ_REQUESTS_PER_TX: u32 = 64;
+pub global MAX_NULLIFIER_READ_REQUESTS_PER_TX: u32 = 64;
+pub global MAX_NULLIFIER_NON_EXISTENT_READ_REQUESTS_PER_TX: u32 = 64;
+pub global MAX_L1_TO_L2_MSG_READ_REQUESTS_PER_TX: u32 = 64;
+// TODO: for large multisends we might run out of key validation requests here but not dealing with this now as
+// databus will hopefully make the issue go away.
+pub global MAX_KEY_VALIDATION_REQUESTS_PER_TX: u32 = 64;
+pub global MAX_PRIVATE_LOGS_PER_TX: u32 = 32;
+pub global MAX_PUBLIC_LOGS_PER_TX: u32 = 8;
+pub global MAX_CONTRACT_CLASS_LOGS_PER_TX: u32 = 1;
+```
+> Source code: noir-projects/noir-protocol-circuits/crates/types/src/constants.nr#L28-L97
+
+
+#### What are the consequences?
+
+When you write an Aztec.nr function, there will be upper bounds on the following:
+
+- The number of public state reads and writes;
+- The number of note reads and nullifications;
+- The number of new notes that may be created;
+- The number of encrypted logs that may be emitted;
+- The number of unencrypted logs that may be emitted;
+- The number of L1->L2 messages that may be consumed;
+- The number of L2->L1 messages that may be submitted to L1;
+- The number of private function calls;
+- The number of public function calls that may be enqueued;
+
+Not only are there limits on a _per function_ basis, there are also limits on a _per transaction_ basis.
+
+**In particular, these _per-transaction_ limits will limit transaction call stack depths** in the Sandbox. That means if a function call results in a cascade of nested function calls, and each of those function calls outputs lots of state reads and writes, or logs (etc.), then all of that accumulated output data might exceed the per-transaction limits that we currently have. This would cause such transactions to fail.
+
+There are plans to relax all of this rigidity, by providing many 'sizes' of kernel circuit, and introducing a 'bus' to ferry varying lengths of data between kernel iterations. But that'll all take some time.
+
+> **In the mean time**, if you encounter a per-transaction limit when testing, and you're feeling adventurous, you could 'hack' the Sandbox to increase the limits. See here (TODO: link) for a guide. **However**, the limits cannot be increased indefinitely. So although we do anticipate that we'll be able to increase them a little bit, don't go mad and provide yourself with 1 million state transitions per transaction. That would be as unrealistic as artificially increasing Ethereum gas limits to 1 trillion.
+
+### Circuits Processing Order Differs from Execution Order
+
+Each function call is represented by a circuit with a dedicated zero-knowledge proof of its execution. The private kernel circuit is in charge of stitching all these proofs together to produce a zero-knowledge proof that the whole execution of all function calls within a transaction is correct. In doing so, the processing order differs from the execution order. Firstly, the private kernel has to handle one function call in its entirety at a time because a zk proof cannot be verified partially. This property alone makes it impossible for the ordering of kernel circuit validation to match the order in which the functions of the transaction were executed. Secondly, the private kernel processes function calls in a stack-based order, i.e., after having processed a function call, it processes all direct child function calls in an order which is the reverse of the execution order.
+
+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$ followed by $f_6$), and $f_4$.
+
+Call Dependency:
+
+> $f_1 \longrightarrow f_2$, $f_3$, $f_4$
+
+> $f_3 \longrightarrow f_5$, $f_6$
+
+Execution Order:
+
+> $f_1$, $f_2$, $f_3$, $f_5$, $f_6$, $f_4$
+
+Private Kernel Processing Order:
+
+> $f_1$, $f_4$, $f_3$, $f_6$, $f_5$, $f_2$
+
+#### What are the consequences?
+
+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 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 (GitHub link)](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 (GitHub link)](https://github.com/AztecProtocol/aztec-packages/issues/1641).
+
+### Note Terminology: Note Commitments and Note Hashes
+
+The notes or UTXOs in Aztec need to be compressed before they are added to the trees. To do so, we need to hash all the data inside a note using a collision-resistant hash function. Currently, we use Pedersen hash (using lookup tables) to compress note data. The compressed note data is referred to as "note commitments" in our architecture. However, note commitments are referred to as "note hashes" in aztec-noir code. Be mindful of that fact that note commitments and note hashes mean the same thing. Note that we only mean to talk about terminology here and in no way one should infer security/cryptographic properties (e.g., hiding, binding) based on the name. Namely, notes come with different flavours of security properties depending on the use case.
+
+## There's more
+
+See the [GitHub issues (GitHub link)](https://github.com/AztecProtocol/aztec-packages/issues) for all known bugs fixes and features currently being worked on.
diff --git a/docs/versioned_docs/version-v0.82.2-alpha-testnet.5/developers/reference/considerations/privacy_considerations.md b/docs/versioned_docs/version-v0.82.2-alpha-testnet.5/developers/reference/considerations/privacy_considerations.md
new file mode 100644
index 000000000000..7a44889e5669
--- /dev/null
+++ b/docs/versioned_docs/version-v0.82.2-alpha-testnet.5/developers/reference/considerations/privacy_considerations.md
@@ -0,0 +1,140 @@
+---
+title: Privacy Considerations
+sidebar_position: 5
+tags: [protocol, PXE]
+---
+
+Privacy is important.
+
+Keeping information private is difficult.
+
+Once information is leaked, it cannot be unleaked.
+
+---
+
+## What can Aztec keep private?
+
+Aztec provides a set of tools to enable developers to build private smart contracts. The following can be kept private:
+
+**Private persistent state**
+
+Store state variables in an encrypted form, so that no one can see what those variables are, except those with the decryption key.
+
+**Private events and messages**
+
+Emit encrypted events, or encrypted messages from a private smart contract function. Only those with the decryption key will learn the message.
+
+**Private function execution**
+
+Execute a private function without the world knowing which function you've executed.
+
+:::danger
+Privacy is not guaranteed without care.
+Although Aztec provides the tools for private smart contracts, information can still be leaked unless the dapp developer is careful.
+This page outlines some best practices to aid dapp developers.
+:::
+
+---
+
+## Leaky practices
+
+There are many caveats to the above. Since Aztec also enables interaction with the _public_ world (public L2 functions and L1 functions), private information can be accidentally leaked if developers aren't careful.
+
+### Crossing the private -> public boundary
+
+Any time a private function makes a call to a public function, information is leaked. Now, that might be perfectly fine in some use cases (it's up to the smart contract developer). Indeed, most interesting apps will require some public state. But let's have a look at some leaky patterns:
+
+- Calling a public function from a private function. The public function execution will be publicly visible.
+- Calling a public function from a private function, without revealing the `msg_sender` of that call. (Otherwise the `msg_sender` will be publicly visible).
+- Passing arguments to a public function from a private function. All of those arguments will be publicly visible.
+- Calling an internal public function from a private function. The fact that the call originated from a private function of that same contract will be trivially known.
+- Emitting unencrypted events from a private function. The unencrypted event name and arguments will be publicly visible.
+- Sending L2->L1 messages from a private function. The entire message, and the resulting L1 function execution will all be publicly visible.
+
+### Crossing the public -> private boundary
+
+If a public function sends a message to be consumed by a private function, the act of consuming that message might be leaked if not following recommended patterns.
+
+### Timing of transactions
+
+Information about the nature of a transaction can be leaked based on the timing of that transaction.
+
+If a transaction is executed at 8am GMT, it's much less likely to have been made by someone in the USA.
+
+If there's a spike in transactions on the last day of every month, those might be salaries.
+
+These minor details are information that can disclose much more information about a user than the user might otherwise expect.
+
+Suppose that every time Alice sends Bob a private token, 1 minute later a transaction is always submitted to the tx pool with the same kind of 'fingerprint'. Alice might deduce that these transactions are automated reactions by Bob. (Here, 'fingerprint' is an intentionally vague term. It could be a public function call, or a private tx proof with a particular number of nonzero public inputs, or some other discernible pattern that Alice sees).
+
+TL;DR: app developers should think about the _timing_ of user transactions, and how this might leak information.
+
+### 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 minimizing 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).
+ - This could be the address of the transactor themselves, if the calling contract is an account contract.
+ - All arguments which are passed to public functions.
+- All calls to L1 functions (in the form of L2 -> L1 messages).
+ - The contents of L2 -> L1 messages.
+- All public logs (topics and arguments).
+- The roots of all trees which have been read from.
+- The _number_ of ['side effects']():
+ - \# new note hashes
+ - \# new nullifiers
+ - \# bytes of encrypted logs
+ - \# public function calls
+ - \# L2->L1 messages
+ - \# nonzero roots[^1]
+
+> Note: many of these were mentioned in the ["Crossing the private -> public boundary"](#crossing-the-private---public-boundary) section.
+
+> Note: the transaction effects submitted to L1 is [encoded (GitHub link)](https://github.com/AztecProtocol/aztec-packages/blob/master/l1-contracts/src/core/libraries/Decoder.sol) but not garbled with other transactions: the distinct Tx Fingerprint of each tx can is publicly visible when a tx is submitted to the L2 tx pool.
+
+#### Standardizing Fingerprints
+
+If each private function were to have a unique Fingerprint, then all private functions would be distinguishable from each-other, and all of the efforts of the Aztec protocol to enable 'private function execution' would have been pointless. Standards need to be developed, to encourage smart contract developers to adhere to a restricted set of Tx Fingerprints. For example, a standard might propose that the number of new note hashes, nullifiers, logs, etc. must always be equal, and must always equal a power of two. Such a standard would effectively group private functions/txs into 'privacy sets', where all functions/txs in a particular 'privacy set' would look indistinguishable from each-other, when executed.
+
+### Data queries
+
+It's not just the broadcasting of transactions to the network that can leak data.
+
+Ethereum has a notion of a 'full node' which keeps-up with the blockchain and stores the full chain state. Many users don't wish to run full nodes, so rely on 3rd-party 'full-node-as-a-service' infrastructure providers, who service blockchain queries from their users.
+
+This pattern is likely to develop in Aztec as well, except there's a problem: privacy. If a privacy-seeking user makes a query to a 3rd-party 'full node', that user might leak data about who they are; about their historical network activity; or about their future intentions. One solution to this problem is "always run a full node", but pragmatically, not everyone will. To protect less-advanced users' privacy, research is underway to explore how a privacy-seeking user may request and receive data from a 3rd-party node without revealing what that data is, nor who is making the request.
+
+App developers should be aware of this avenue for private data leakage. **Whenever an app requests information from a node, the entity running that node is unlikely to be your user!**
+
+#### What kind of queries can be leaky?
+
+##### Querying for up-to-date note sibling paths
+
+To read a private state is to read a note from the note hash tree. To read a note is to prove existence of that note in the note hash tree. And to prove existence is to re-compute the root of the note hash tree using the leaf value, the leaf index, and the sibling path of that leaf. This computed root is then exposed to the world, as a way of saying "This note exists", or more precisely "This note has existed at least since this historical snapshot time".
+
+If an old historical snapshot is used, then that old historical root will be exposed, and this leaks some information about the nature of your transaction: it leaks that your note was created before the snapshot date. It shrinks the 'privacy set' of the transaction to a smaller window of time than the entire history of the network.
+
+So for maximal privacy, it's in a user's best interest to read from the very-latest snapshot of the data tree.
+
+Naturally, the note hash tree is continuously changing as new transactions take place and their new notes are appended. Most notably, the sibling path for every leaf in the tree changes every time a new leaf is appended.
+
+If a user runs their own node, there's no problem: they can query the latest sibling path for their note(s) from their own machine without leaking any information to the outside world.
+
+But if a user is not running their own node, they would need to query the very-latest sibling path of their note(s) from some 3rd-party node. In order to query the sibling path of a leaf, the leaf's index needs to be provided as an argument. Revealing the leaf's index to a 3rd-party trivially reveals exactly the note(s) you're about to read. And since those notes were created in some prior transaction, the 3rd-party will be able to link you with that prior transaction. Suppose then that the 3rd-party also serviced the creator of said prior transaction: the 3rd-party will slowly be able to link more and more transactions, and gain more and more insight into a network which is meant to be private!
+
+We're researching cryptographic ways to enable users to retrieve sibling paths from 3rd-parties without revealing leaf indices.
+
+> \* Note: due to the non-uniformity of Aztec transactions, the 'privacy set' of a transaction might not be the entire set of transactions that came before.
+
+##### Any query
+
+Any query to a node leaks information to that node.
+
+We're researching cryptographic ways to enable users to query any data privately.
+
+---
+
+Footnotes
+
+[^1]: All txs should set the kernel circuit public inputs for all roots to _valid_, _up-to-date_ nonzero values, so as to mask which trees have _actually_ been read from. The Sandbox will eventually automate this (see this [issue (GitHub link)](https://github.com/AztecProtocol/aztec-packages/issues/1676)).
diff --git a/docs/versioned_docs/version-v0.82.2-alpha-testnet.5/developers/reference/debugging/_category_.json b/docs/versioned_docs/version-v0.82.2-alpha-testnet.5/developers/reference/debugging/_category_.json
new file mode 100644
index 000000000000..99db708f09cb
--- /dev/null
+++ b/docs/versioned_docs/version-v0.82.2-alpha-testnet.5/developers/reference/debugging/_category_.json
@@ -0,0 +1,6 @@
+{
+ "label": "Debugging",
+ "position": 3,
+ "collapsible": true,
+ "collapsed": true
+}
diff --git a/docs/versioned_docs/version-v0.82.2-alpha-testnet.5/developers/reference/debugging/aztecnr-errors.md b/docs/versioned_docs/version-v0.82.2-alpha-testnet.5/developers/reference/debugging/aztecnr-errors.md
new file mode 100644
index 000000000000..84e1a1e286f7
--- /dev/null
+++ b/docs/versioned_docs/version-v0.82.2-alpha-testnet.5/developers/reference/debugging/aztecnr-errors.md
@@ -0,0 +1,75 @@
+---
+title: Aztec.nr Errors
+tags: [contracts]
+---
+
+This section contains some errors that you may encounter when writing and compiling contracts in Aztec.nr. If you run into an error that is not listed here, please [create an issue (GitHub link)](https://github.com/AztecProtocol/aztec-packages/issues/new).
+
+#### `Aztec dependency not found. Please add aztec as a dependency in your Nargo.toml`
+
+All smart contracts written in Aztec.nr need the `aztec` dependency. In your `Nargo.toml` under `[dependencies]`, add this:
+
+```toml
+aztec = { git="https://github.com/AztecProtocol/aztec-packages/", tag="v0.82.2", directory="noir-projects/aztec-nr/aztec" }
+```
+
+You can learn more about dependencies and their paths [here](../smart_contract_reference/dependencies.md).
+
+#### `backend has encountered an error`
+
+This is likely due to a version mismatch or bad install of barretenberg. Try [reinstalling nargo](../../guides/local_env/versions-updating.md) or uninstalling barretenberg:
+
+```bash
+nargo backend uninstall acvm-backend-barretenberg
+```
+
+It will then reinstall when you compile.
+
+#### `Oracle callback {} not found` & `Oracle callback pedersenHash not found`
+
+This can occasionally happen when there are breaking releases. Make sure that your dependencies in `Nargo.toml` are [updated to the latest release](../../guides/local_env/versions-updating.md#dependency-versions).
+
+#### `error: Failed constraint: 'Public state writes only supported in public functions`
+
+Reading and writing to public state from private functions is currently not supported.
+This is because public values may change before the private function execution is posted on-chain.
+
+This may change in future versions.
+
+#### `Simulation error: Assertion failed:...`
+
+This is an assertion error that is thrown when a condition is not met.
+
+To address the error. find the line in the contract that is throwing the error and investigate why the condition is not met.
+
+#### `Unknown contract 0x0: add it to PXE by calling server.addContracts(...)`
+
+This error occurs when you are trying to interact with a smart contract via an Private Execution Environment (PXE) that does not have the necessary information to execute a transaction.
+
+To execute a transaction, the PXE needs to know the complete address of a contract and contract artifacts.
+
+To address the error, add the contract to the PXE by calling [`pxe.addContracts(...)`](../../../aztec/concepts/pxe/index.md).
+
+#### `Simulation error: No public key registered for address 0x0. Register it by calling pxe.registerRecipient(...) or pxe.registerAccount(...)`
+
+This error occurs when your contract is trying to get a public key via the `get_public_key` oracle call, but the PXE does not have the Complete Address (Complete Address contains the public key).
+
+Your contract typically needs a note recipient's public key when it wants to send a note to because the public key is used to encrypt notes.
+
+:::info
+Manually adding the recipient to the PXE should not be required in case the recipient contract has already been deployed and the PXE is fully synced.
+This is because this information is submitted on-chain when the recipient contract is deployed.
+:::
+
+#### `Could not process note because of "Error: Unknown account.". Skipping note...`
+
+This error occurs when your contract is trying to get a secret via the `get_secret` oracle call, but the PXE does not have the secret for the public key.
+
+This error might occur when you register an account only as a recipient and not as an account.
+To address the error, register the account by calling `server.registerAccount(...)`.
+
+#### `Failed to solve brillig function 'self._is_some`
+
+You may encounter this error when trying to send a transaction that is using an invalid contract. The contract may compile without errors and you only encounter this when sending the transaction.
+
+This error may arise when function parameters are not properly formatted, when trying to "double-spend" a note, or it may indicate that there is a bug deeper in the stack (e.g. a bug in the Aztec.nr library or deeper). If you hit this error, double-check your contract implementation, but also consider [opening an issue (GitHub link)](https://github.com/AztecProtocol/aztec-packages/issues/new).
diff --git a/docs/versioned_docs/version-v0.82.2-alpha-testnet.5/developers/reference/debugging/index.md b/docs/versioned_docs/version-v0.82.2-alpha-testnet.5/developers/reference/debugging/index.md
new file mode 100644
index 000000000000..f020a71f846a
--- /dev/null
+++ b/docs/versioned_docs/version-v0.82.2-alpha-testnet.5/developers/reference/debugging/index.md
@@ -0,0 +1,67 @@
+---
+title: Debugging
+sidebar_position: 1
+---
+
+## Logging in Aztec.nr
+
+On this section you can learn how to debug your Aztec.nr smart contracts and common errors that you may run into.
+
+You can log statements from Aztec.nr contracts that will show ups in the Sandbox.
+
+:::info
+
+The Noir standard library `std::println` function will not work in Aztec contracts. You must use the `debug_log` and `debug_log_format` defined below.
+
+:::
+
+### Import `debug_log`
+
+Import the `debug_log` dependency from Aztec oracles:
+
+```rust
+use dep::aztec::oracle::debug_log::{ debug_log };
+```
+
+### Write log
+
+Write `debug_log()` in the appropriate place in your contract.
+
+```rust
+debug_log("here");
+```
+
+Other methods for logging include:
+
+`debug_log_format()`: for logging Field values along arbitrary strings.
+
+```rust
+debug_log_format("get_2(slot:{0}) =>\n\t0:{1}\n\t1:{2}", [storage_slot, note0_hash, note1_hash]);
+```
+
+`debug_log_field()`: for logging Fields.
+
+```rust
+debug_log_field(my_field);
+```
+
+`debug_log_array()`: for logging array types.
+
+```rust
+debug_log_array(my_array);
+```
+
+### Start Sandbox in debug mode
+
+Set `LOG_LEVEL` to `verbose` or `debug`:
+
+```bash
+# Options are 'fatal', 'error', 'warn', 'info', 'verbose', 'debug', 'trace'
+LOG_LEVEL=debug aztec start --sandbox
+```
+
+and start the sandbox normally.
+
+You can specify different log levels for different services.
+
+For example: `LOG_LEVEL="verbose;info:sequencer"` will use verbose logging for everything except the `sequencer` service, which will use the `info` level.
diff --git a/docs/versioned_docs/version-v0.82.2-alpha-testnet.5/developers/reference/debugging/sandbox-errors.md b/docs/versioned_docs/version-v0.82.2-alpha-testnet.5/developers/reference/debugging/sandbox-errors.md
new file mode 100644
index 000000000000..a43faed0196f
--- /dev/null
+++ b/docs/versioned_docs/version-v0.82.2-alpha-testnet.5/developers/reference/debugging/sandbox-errors.md
@@ -0,0 +1,200 @@
+---
+title: Aztec Sandbox Errors
+tags: [sandbox]
+---
+
+import Disclaimer from '@site/src/components/Disclaimers/\_wip_disclaimer.mdx';
+
+
+
+This section contains a list of errors you may encounter when using Aztec Sandbox and an explanation of each of them.
+
+## Circuit Errors
+
+**To prevent bloating this doc, here is a list of some of the common errors.**
+
+### Kernel Circuits
+
+We have several versions of public and private kernels as explained in [the circuits section in the concepts](../../../aztec/concepts/advanced/circuits/index.md). Certain things are only possible in certain versions of the circuits. So always ensure that the right version is being used for proof generation. For example, there is a specific version of the public kernel that only works if the previous kernel iteration was a private kernel. Similarly there is one that only works if the previous kernel was public.
+
+Remember that for each function call (i.e. each item in the call stack), there is a new kernel iteration that gets run.
+
+#### 2002 - PRIVATE_KERNEL\_\_INVALID_CONTRACT_ADDRESS
+
+Cannot call contract at address(0x0) privately.
+This error may also happen when you deploy a new contract and the contract data hash is inconsistent to the expected contract address.
+
+#### 2005 - PRIVATE_KERNEL\_\_NEW_NOTE_HASHES_PROHIBITED_IN_STATIC_CALL
+
+For static calls, new note hashes aren't allowed
+
+#### 2006 - PRIVATE_KERNEL\_\_NEW_NULLIFIERS_PROHIBITED_IN_STATIC_CALL
+
+For static calls, new nullifiers aren't allowed
+
+#### 2009 - PRIVATE_KERNEL\_\_NON_PRIVATE_FUNCTION_EXECUTED_WITH_PRIVATE_KERNEL
+
+You cannot execute a public Aztec.nr function in the private kernel
+
+#### 2011 - PRIVATE_KERNEL\_\_UNSUPPORTED_OP
+
+You are trying to do something that is currently unsupported in the private kernel. If this is a blocker feel free to open up an issue on our monorepo [aztec-packages (GitHub link)](https://github.com/AztecProtocol/aztec-packages/tree/master) or reach out to us on discord
+
+Note that certain operations are unsupported on certain versions of the private kernel. Eg static calls are allowed for all but the initial iteration of the private kernel (which initializes the kernel for subsequent function calls).
+
+#### 2012 - PRIVATE_KERNEL\_\_CONTRACT_ADDRESS_MISMATCH
+
+For the initial iteration of the private kernel, only the expected Aztec.nr contract should be the entrypoint. Static and delegate calls are not allowed in the initial iteration.
+
+#### 2013 - PRIVATE_KERNEL\_\_NON_PRIVATE_KERNEL_VERIFIED_WITH_PRIVATE_KERNEL
+
+The previous kernel iteration within the private kernel must also be private
+
+#### 2014 - PRIVATE_KERNEL\_\_CONSTRUCTOR_EXECUTED_IN_RECURSION
+
+A constructor must be executed as the first tx in the recursion i.e. a constructor call must be the first item in the call stack i.e. it can be executed in the first kernel iteration but not in subsequent ones. This also means you can't have a contract deploy another contract yet on Aztec.
+
+#### 2017 - PRIVATE_KERNEL\_\_USER_INTENT_MISMATCH_BETWEEN_TX_REQUEST_AND_CALL_STACK_ITEM
+
+Confirms that the TxRequest (user's intent) matches the private call being executed. This error may happen when:
+
+- origin address of tx_request doesn't match call_stack_item's contract_address
+- tx_request.function_data doesn't match call_stack_item.function_data
+- Aztec.nr function args passed to tx_request doesn't match args in the call_stack_item
+
+#### 2018 - PRIVATE_KERNEL\_\_READ_REQUEST_NOTE_HASH_TREE_ROOT_MISMATCH
+
+Given a read request and provided witness, we check that the merkle root obtained from the witness' sibling path and it's leaf is similar to the historical state root we want to read against. This is a sanity check to ensure we are reading from the right state.
+For a non transient read, we fetch the merkle root from the membership witnesses and the leaf index
+
+#### 2019 - PRIVATE_KERNEL\_\_TRANSIENT_READ_REQUEST_NO_MATCH
+
+A pending note hash is the one that is not yet added to note hash tree.
+A transient read is when we try to "read" a pending note hash.
+This error happens when you try to read a pending note hash that doesn't exist.
+
+#### 2021 - PRIVATE_KERNEL\_\_UNRESOLVED_NON_TRANSIENT_READ_REQUEST
+
+For a transient read request we skip merkle membership checks since pending note hashes aren't inserted into the note hash tree yet.
+But for non transient reads, we do a merkle membership check. Reads are done at the kernel circuit. So this checks that there are no already unresolved reads from a previous kernel iteration (other than non transient ones).
+
+#### 3001 - PUBLIC_KERNEL\_\_UNSUPPORTED_OP
+
+You are trying to do something that is currently unsupported in the public kernel. If this is a blocker feel free to open up an issue on our monorepo [aztec-packages (GitHub link)](https://github.com/AztecProtocol/aztec-packages/tree/master) or reach out to us on discord
+
+#### 3002 - PUBLIC_KERNEL\_\_PRIVATE_FUNCTION_NOT_ALLOWED
+
+Calling a private Aztec.nr function in a public kernel is not allowed.
+
+#### 3005 - PUBLIC_KERNEL\_\_NON_EMPTY_PRIVATE_CALL_STACK
+
+Public functions are executed after all the private functions are (see [private-public execution](../../../aztec/smart_contracts/functions/public_private_calls.md)). As such, private call stack must be empty when executing in the public kernel.
+
+#### 3011 - PUBLIC_KERNEL\_\_CALCULATED_PRIVATE_CALL_HASH_AND_PROVIDED_PRIVATE_CALL_HASH_MISMATCH
+
+When the hash stored at the top most of the call stack is different to the call stack item expected by the public kernel's inputs.
+
+#### 3012 - PUBLIC_KERNEL\_\_PUBLIC_CALL_STACK_MISMATCH
+
+Similar to above, except here we actually have the preimages to the call stack and hash to ensure they match.
+
+#### 3013 - PUBLIC_KERNEL\_\_CONTRACT_DEPLOYMENT_NOT_ALLOWED
+
+Public kernel doesn't allow contract deployments
+
+#### 3014 - PUBLIC_KERNEL\_\_CONSTRUCTOR_NOT_ALLOWED
+
+Aztec doesn't support public constructors.
+
+#### 3015 - PUBLIC_KERNEL\_\_CONTRACT_ADDRESS_INVALID
+
+Calling `address(0x0)` publicly is not permitted.
+
+#### 3016 - PUBLIC_KERNEL\_\_FUNCTION_SIGNATURE_INVALID
+
+Cannot call a contract with no function (i.e. function signature of 0) publicly.
+
+#### 3022 - PUBLIC_KERNEL\_\_PUBLIC_CALL_STACK_CONTRACT_STORAGE_UPDATES_PROHIBITED_FOR_STATIC_CALL
+
+For static calls, no contract storage change requests are allowed.
+
+#### 3024 - PUBLIC_KERNEL\_\_CALL_CONTEXT_CONTRACT_STORAGE_UPDATE_REQUESTS_PROHIBITED_FOR_STATIC_CALL
+
+Same as [3022](#3022---public_kernel__public_call_stack_contract_storage_updates_prohibited_for_static_call), no contract changes are allowed for static calls.
+
+#### 3026 - PUBLIC_KERNEL\_\_NOTE_HASHES_PROHIBITED_IN_STATIC_CALL
+
+For static calls, no new note hashes or nullifiers can be added to the state.
+
+#### 3027 - PUBLIC_KERNEL\_\_NEW_NULLIFIERS_PROHIBITED_IN_STATIC_CALL
+
+For static calls, no new note hashes or nullifiers can be added to the state.
+
+### Rollup circuit errors
+
+These are errors that occur when kernel proofs (transaction proofs) are sent to the rollup circuits to create an L2 block. See [rollup circuits](../../../aztec/concepts/advanced/circuits/rollup_circuits/index.md) for more information.
+
+#### 4007 - BASE\_\_INVALID_CHAIN_ID
+
+The L1 chain ID you used in your proof generation (for your private transaction) is different to what the rollup circuits expected. Double check against the global variables passed to noir and the config set in [Aztec's rollup contract (GitHub link)](https://github.com/AztecProtocol/aztec-packages/blob/master/l1-contracts/src/core/Rollup.sol) which are [read in by sequencer GitHub link](https://github.com/AztecProtocol/aztec-packages/blob/master/yarn-project/sequencer-client/src/global_variable_builder/global_builder.ts#L32) and subsequently passed in as inputs to the base rollup. When the sequencer submits the block to the rollup contracts, this is again sanity checked so ensure this is the same everywhere.
+
+#### 4008 - BASE\_\_INVALID_VERSION
+
+Same as [section 4007](#4007---base__invalid_chain_id) except the `version` refers to the version of the Aztec L2 instance.
+
+Some scary bugs like `4003 - BASE__INVALID_NULLIFIER_SUBTREE` and `4004 - BASE__INVALID_NULLIFIER_RANGE` which are to do malformed nullifier trees (see [Indexed Merkle Trees](../../../aztec/concepts/advanced/storage/indexed_merkle_tree.mdx)) etc may seem unrelated at a glance, but at a closer look may be because of some bug in an application's Aztec.nr code. Same is true for certain instances of `7008 - MEMBERSHIP_CHECK_FAILED`.
+
+### Generic circuit errors
+
+#### 7009 - ARRAY_OVERFLOW
+
+Circuits work by having a fixed size array. As such, we have limits on how many UTXOs can be created (aka "commitments") or destroyed/nullified (aka "nullifiers") in a transaction. Similarly we have limits on many reads or writes you can do, how many contracts you can create in a transaction. This error typically says that you have reached the current limits of what you can do in a transaction. Some examples when you may hit this error are:
+
+- too many new note hashes in one tx
+- too many new nullifiers in one tx
+ - Note: Nullifiers may be created even outside the context of your Aztec.nr code. Eg, when creating a contract, we add a nullifier for its address to prevent same address from ever occurring. Similarly, we add a nullifier for your transaction hash too.
+- too many private function calls in one tx (i.e. call stack size exceeded)
+- too many public function calls in one tx (i.e. call stack size exceeded)
+- too many new L2 to L1 messages in one tx
+- too many contracts created in one tx
+- too many public data update requests in one tx
+- too many public data reads in one tx
+- too many transient read requests in one tx
+- too many transient read request membership witnesses in one tx
+
+You can have a look at our current constants/limitations in [constants.nr (GitHub link)](https://github.com/AztecProtocol/aztec-packages/blob/master/noir-projects/noir-protocol-circuits/crates/types/src/constants.nr)
+
+#### 7008 - MEMBERSHIP_CHECK_FAILED
+
+Users may create a proof against a historical state in Aztec. The rollup circuits performs a merkle membership check to ensure this state existed at some point. If the historical state doesn't exist, you get this error. Some examples when you may hit this error are:
+
+- using invalid historical note hash tree state (aka historical commitments tree)
+- using invalid historical contracts data tree state
+- using invalid historical L1 to L2 message data tree state
+- inserting a subtree into the greater tree
+ - we make a smaller merkle tree of all the new note hashes/nullifiers etc that were created in a transaction or in a rollup and add it to the bigger state tree. Before inserting, we do a merkle membership check to ensure that the index to insert at is indeed an empty subtree (otherwise we would be overwriting state). This can happen when `next_available_leaf_index` in the state tree's snapshot is wrong (it is fetched by the sequencer from the archiver). The error message should reveal which tree is causing this issue
+ - nullifier tree related errors - The nullifier tree uses an [Indexed Merkle Tree](../../../aztec/concepts/advanced/storage/indexed_merkle_tree.mdx). It requires additional data from the archiver to know which is the nullifier in the tree that is just below the current nullifier before it can perform batch insertion. If the low nullifier is wrong, or the nullifier is in incorrect range, you may receive this error.
+
+---
+
+## Archiver Errors
+
+- "No non-nullified L1 to L2 message found for message hash \$\{messageHash.toString()\}"/"Tried to consume nonexistent L1-to-L2 message" - happens when the L1 to L2 message doesn't exist or is "pending", when the user has sent a message on L1 via the Inbox contract but it has yet to be included in an L2 block by the sequencer - the user has to wait for enough blocks to progress and for the archiver to sync the respective L2 block. You can get the sequencer to pick it up by doing 2 arbitrary transactions on L2 (eg. send DAI to yourself 2 times). This would give the sequencer a transaction to process and as a side effect it would consume 2 subtrees of new messages from the Inbox contract. 2 subtrees need to be consumed and not just 1 because there is a 1 block lag to prevent the subtree from changing when the sequencer is proving.
+
+- "Block number mismatch: expected \$\{l2BlockNum\} but got \$\{block.number\}" - The archiver keeps track of the next expected L2 block number. It throws this error if it got a different one when trying to sync with the rollup contract's events on L1.
+
+## Sequencer Errors
+
+- "\$\{treeName\} tree root mismatch" - The sequencer validates that the root of the tree matches the output of the circuit simulation. The tree name could be Public data tree, Note Hash Tree, Contract tree, Nullifier tree or the L1ToL2Message tree,
+
+- "\$\{treeName\} tree next available leaf index mismatch" - validating a tree's root is not enough. It also checks that the `next_available_leaf_index` is as expected. This is the next index we can insert new values into. Note that for the public data tree, this test is skipped since as it is a sparse tree unlike the others.
+
+- "Public call stack size exceeded" - In Aztec, the sequencer executes all enqueued public functions in a transaction (to prevent race conditions - see [private-public execution](../../../aztec/smart_contracts/functions/public_private_calls.md)). This error says there are too many public functions requested.
+
+- "Array size exceeds target length" - happens if you add more items than allowed by the constants set due to our circuit limitations (eg sending too many L2 to L1 messages or creating a function that exceeds the call stack length or returns more values than what Aztec.nr functions allow)
+
+- "Failed to publish block" - Happens when sequencer tries to submit its L2 block + proof to the rollup contract.
+
+## L1 Aztec Contract Errors
+
+Aztec's L1 contracts use custom errors in solidity. While it saves gas, it has a side effect of making it harder to decode when things go wrong. If you get an error when submitting an L2Block into our rollup contract or when interacting with our Inbox/Outbox contracts, you can use the [Errors.sol library (GitHub link)](https://github.com/AztecProtocol/aztec-packages/blob/master/l1-contracts/src/core/libraries/Errors.sol) to match the hex encoded error to the error name.
diff --git a/docs/versioned_docs/version-v0.82.2-alpha-testnet.5/developers/reference/environment_reference/_category_.json b/docs/versioned_docs/version-v0.82.2-alpha-testnet.5/developers/reference/environment_reference/_category_.json
new file mode 100644
index 000000000000..e51f342c74a7
--- /dev/null
+++ b/docs/versioned_docs/version-v0.82.2-alpha-testnet.5/developers/reference/environment_reference/_category_.json
@@ -0,0 +1,6 @@
+{
+ "label": "Developer Environment",
+ "position": 0,
+ "collapsible": true,
+ "collapsed": true
+}
diff --git a/docs/versioned_docs/version-v0.82.2-alpha-testnet.5/developers/reference/environment_reference/cheat_codes.md b/docs/versioned_docs/version-v0.82.2-alpha-testnet.5/developers/reference/environment_reference/cheat_codes.md
new file mode 100644
index 000000000000..6d5f5a539299
--- /dev/null
+++ b/docs/versioned_docs/version-v0.82.2-alpha-testnet.5/developers/reference/environment_reference/cheat_codes.md
@@ -0,0 +1,558 @@
+---
+title: Cheat Codes
+tags: [sandbox]
+sidebar_position: 4
+---
+
+import Disclaimer from "@site/src/components/Disclaimers/\_wip_disclaimer.mdx";
+
+## Introduction
+
+To help with testing, the sandbox is shipped with a set of cheatcodes.
+
+Cheatcodes allow you to change the time of the Aztec block, load certain state or more easily manipulate Ethereum instead of having to write dedicated RPC calls to anvil or hardhat.
+
+:::info Prerequisites
+If you aren't familiar with [Anvil (Foundry)](https://book.getfoundry.sh/anvil/), we recommend reading up on that since Aztec Sandbox uses Anvil as the local Ethereum instance.
+:::
+
+### Aims
+
+The guide will cover how to manipulate the state of the:
+
+- Ethereum blockchain;
+- Aztec network.
+
+### Dependencies
+
+For this guide, the following Aztec packages are used:
+
+- @aztec/aztec.js
+
+### Initialization
+
+```ts
+import { createPXEClient, CheatCodes } from "@aztec/aztec.js";
+const pxeRpcUrl = "http://localhost:8080";
+const ethRpcUrl = "http://localhost:8545";
+const pxe = createPXEClient(pxeRpcUrl);
+const cc = await CheatCodes.create(ethRpcUrl, pxe);
+```
+
+There are two properties of the CheatCodes class - `eth` and `aztec` for cheatcodes relating to the Ethereum blockchain (L1) and the Aztec network (L2) respectively.
+
+## Ethereum related cheatcodes
+
+These are cheatcodes exposed from anvil/hardhat conveniently wrapped for ease of use in the Sandbox.
+
+### Interface
+
+```ts
+// Fetch current block number of Ethereum
+public async blockNumber(): Promise
+
+// Fetch chain ID of the local Ethereum instance
+public async chainId(): Promise
+
+// Fetch current timestamp on Ethereum
+public async timestamp(): Promise
+
+// Mine a given number of blocks on Ethereum. Mines 1 block by default
+public async mine(numberOfBlocks = 1): Promise
+
+// Set the timestamp for the next block on Ethereum.
+public async setNextBlockTimestamp(timestamp: number): Promise
+
+// Dumps the current Ethereum chain state to a given file.
+public async dumpChainState(fileName: string): Promise
+
+// Loads the Ethereum chain state from a file. You may use `dumpChainState()` to save the state of the Ethereum chain to a file and later load it.
+public async loadChainState(fileName: string): Promise
+
+// Load the value at a storage slot of a contract address on Ethereum
+public async load(contract: EthAddress, slot: bigint): Promise
+
+// Set the value at a storage slot of a contract address on Ethereum (e.g. modify a storage variable on your portal contract or even the rollup contract).
+public async store(contract: EthAddress, slot: bigint, value: bigint): Promise
+
+// Computes the slot value for a given map and key on Ethereum. A convenient wrapper to find the appropriate storage slot to load or overwrite the state.
+public keccak256(baseSlot: bigint, key: bigint): bigint
+
+// Let you send transactions on Ethereum impersonating an externally owned or contract, without knowing the private key.
+public async startImpersonating(who: EthAddress): Promise
+
+// Stop impersonating an account on Ethereum that you are currently impersonating.
+public async stopImpersonating(who: EthAddress): Promise
+
+// Set the bytecode for a Ethereum contract
+public async etch(contract: EthAddress, bytecode: `0x${string}`): Promise
+
+// Get the bytecode for a Ethereum contract
+public async getBytecode(contract: EthAddress): Promise<`0x${string}`>
+```
+
+### blockNumber
+
+#### Function Signature
+
+```ts
+public async blockNumber(): Promise
+```
+
+#### Description
+
+Fetches the current Ethereum block number.
+
+#### Example
+
+```ts
+const blockNumber = await cc.eth.blockNumber();
+```
+
+### chainId
+
+#### Function Signature
+
+```ts
+public async chainId(): Promise
+```
+
+#### Description
+
+Fetches the Ethereum chain ID
+
+#### Example
+
+```ts
+const chainId = await cc.eth.chainId();
+```
+
+### timestamp
+
+#### Function Signature
+
+```ts
+public async timestamp(): Promise
+```
+
+#### Description
+
+Fetches the current Ethereum timestamp.
+
+#### Example
+
+```ts
+const timestamp = await cc.eth.timestamp();
+```
+
+### mine
+
+#### Function Signature
+
+```ts
+public async mine(numberOfBlocks = 1): Promise
+```
+
+#### Description
+
+Mines the specified number of blocks on Ethereum (default 1).
+
+#### Example
+
+```ts
+const blockNum = await cc.eth.blockNumber();
+await cc.eth.mine(10); // mines 10 blocks
+const newBlockNum = await cc.eth.blockNumber(); // = blockNum + 10.
+```
+
+### setNextBlockTimestamp
+
+#### Function Signature
+
+```ts
+public async setNextBlockTimestamp(timestamp: number): Promise
+```
+
+#### Description
+
+Sets the timestamp (unix format in seconds) for the next mined block on Ethereum.
+Time can only be set in the future.
+If you set the timestamp to a time in the past, this method will throw an error.
+
+#### Example
+
+```ts
+// // Set next block timestamp to 16 Aug 2023 10:54:30 GMT
+await cc.eth.setNextBlockTimestamp(1692183270);
+// next transaction you will do will have the timestamp as 1692183270
+```
+
+### dumpChainState
+
+#### Function Signature
+
+```ts
+public async dumpChainState(fileName: string): Promise
+```
+
+#### Description
+
+Dumps the current Ethereum chain state to a file.
+Stores a hex string representing the complete state of the chain in a file with the provided path. Can be re-imported into a fresh/restarted instance of Anvil to reattain the same state.
+When combined with `loadChainState()` cheatcode, it can be let you easily import the current state of mainnet into the Anvil instance of the sandbox.
+
+#### Example
+
+```ts
+await cc.eth.dumpChainState("chain-state.json");
+```
+
+### loadChainState
+
+#### Function Signature
+
+```ts
+public async loadChainState(fileName: string): Promise
+```
+
+#### Description
+
+Loads the Ethereum chain state from a file which contains a hex string representing an Ethereum state.
+When given a file previously written to by `cc.eth.dumpChainState()`, it merges the contents into the current chain state. Will overwrite any colliding accounts/storage slots.
+
+#### Example
+
+```ts
+await cc.eth.loadChainState("chain-state.json");
+```
+
+### load
+
+#### Function Signature
+
+```ts
+public async load(contract: EthAddress, slot: bigint): Promise
+```
+
+#### Description
+
+Loads the value at a storage slot of a Ethereum contract.
+
+#### Example
+
+```solidity
+contract LeetContract {
+ uint256 private leet = 1337; // slot 0
+}
+```
+
+```ts
+const leetContractAddress = EthAddress.fromString("0x1234...");
+const value = await cc.eth.load(leetContractAddress, BigInt(0));
+console.log(value); // 1337
+```
+
+### store
+
+#### Function Signature
+
+```ts
+public async store(contract: EthAddress, slot: bigint, value: bigint): Promise
+```
+
+#### Description
+
+Stores the value in storage slot on a Ethereum contract.
+
+#### Example
+
+```solidity
+contract LeetContract {
+ uint256 private leet = 1337; // slot 0
+}
+```
+
+```ts
+const leetContractAddress = EthAddress.fromString("0x1234...");
+await cc.eth.store(leetContractAddress, BigInt(0), BigInt(1000));
+const value = await cc.eth.load(leetContractAddress, BigInt(0));
+console.log(value); // 1000
+```
+
+### keccak256
+
+#### Function Signature
+
+```ts
+public keccak256(baseSlot: bigint, key: bigint): bigint
+```
+
+#### Description
+
+Computes the storage slot for a map key.
+
+#### Example
+
+```solidity
+contract LeetContract {
+ uint256 private leet = 1337; // slot 0
+ mapping(address => uint256) public balances; // base slot 1
+}
+```
+
+```ts
+// find the storage slot for key `0xdead` in the balance map.
+const address = BigInt("0x000000000000000000000000000000000000dead");
+const slot = cc.eth.keccak256(1n, address);
+// store balance of 0xdead as 100
+await cc.eth.store(contractAddress, slot, 100n);
+```
+
+### startImpersonating
+
+#### Function Signature
+
+```ts
+public async startImpersonating(who: EthAddress): Promise
+```
+
+#### Description
+
+Start impersonating an Ethereum account.
+This allows you to use this address as a sender.
+
+#### Example
+
+```ts
+await cc.eth.startImpersonating(EthAddress.fromString(address));
+```
+
+### stopImpersonating
+
+#### Function Signature
+
+```ts
+public async stopImpersonating(who: EthAddress): Promise
+```
+
+#### Description
+
+Stop impersonating an Ethereum account.
+Stops an active impersonation started by startImpersonating.
+
+#### Example
+
+```ts
+await cc.eth.stopImpersonating(EthAddress.fromString(address));
+```
+
+### getBytecode
+
+#### Function Signature
+
+```ts
+public async getBytecode(contract: EthAddress): Promise<`0x${string}`>
+```
+
+#### Description
+
+Get the bytecode for an Ethereum contract.
+
+#### Example
+
+```ts
+const bytecode = await cc.eth.getBytecode(contract); // 0x6080604052348015610010...
+```
+
+### etch
+
+#### Function Signature
+
+```ts
+public async etch(contract: EthAddress, bytecode: `0x${string}`): Promise
+```
+
+#### Description
+
+Set the bytecode for an Ethereum contract.
+
+#### Example
+
+```ts
+const bytecode = `0x6080604052348015610010...`;
+await cc.eth.etch(contract, bytecode);
+console.log(await cc.eth.getBytecode(contract)); // 0x6080604052348015610010...
+```
+
+## Aztec related cheatcodes
+
+These are cheatcodes specific to manipulating the state of Aztec rollup.
+
+### Interface
+
+```ts
+// Get the current aztec block number
+public async blockNumber(): Promise
+
+// Set time of the next execution on aztec. It also modifies time on Ethereum for next execution and stores this time as the last rollup block on the rollup contract.
+public async warp(to: number): Promise
+
+// Loads the value stored at the given slot in the public storage of the given contract.
+public async loadPublic(who: AztecAddress, slot: Fr | bigint): Promise
+
+// Loads the value stored at the given slot in the private storage of the given contract.
+public async loadPrivate(owner: AztecAddress, contract: AztecAddress, slot: Fr | bigint): Promise
+
+// Computes the slot value for a given map and key.
+public computeSlotInMap(baseSlot: Fr | bigint, key: Fr | bigint): Fr
+```
+
+### blockNumber
+
+#### Function Signature
+
+```ts
+public async blockNumber(): Promise
+```
+
+#### Description
+
+Get the current aztec block number.
+
+#### Example
+
+```ts
+const blockNumber = await cc.aztec.blockNumber();
+```
+
+### warp
+
+#### Function Signature
+
+```ts
+public async warp(to: number): Promise
+```
+
+#### Description
+
+Sets the time on Ethereum and the time of the next block on Aztec.
+Like with the corresponding Ethereum cheatcode, time can only be set in the future, not the past.
+Otherwise, it will throw an error.
+
+#### Example
+
+```ts
+const timestamp = await cc.eth.timestamp();
+const newTimestamp = timestamp + 100_000_000;
+await cc.aztec.warp(newTimestamp);
+// any Aztec.nr contract calls that make use of current timestamp
+// and is executed in the next rollup block will now read `newTimestamp`
+```
+
+### computeSlotInMap
+
+#### Function Signature
+
+```ts
+public computeSlotInMap(baseSlot: Fr | bigint, key: Fr | bigint): Fr
+```
+
+#### Description
+
+Compute storage slot for a map key.
+The baseSlot is specified in the Aztec.nr contract.
+
+#### Example
+
+```rust
+#[storage]
+struct Storage {
+ balances: Map>,
+}
+
+contract Token {
+ ...
+}
+```
+
+```ts
+const slot = cc.aztec.computeSlotInMap(1n, key);
+```
+
+### loadPublic
+
+#### Function Signature
+
+```ts
+public async loadPublic(who: AztecAddress, slot: Fr | bigint): Promise
+```
+
+#### Description
+
+Loads the value stored at the given slot in the public storage of the given contract.
+
+Note: One Field element occupies a storage slot. Hence, structs with multiple field elements will be spread over multiple sequential slots. Using loadPublic will only load a single field of the struct (depending on the size of the attributes within it).
+
+#### Example
+
+```rust
+#[storage]
+struct Storage {
+ balances: Map>,
+}
+
+contract Token {
+ ...
+}
+```
+
+```ts
+const address = AztecAddress.fromString("0x123...");
+const slot = cc.aztec.computeSlotInMap(1n, key);
+const value = await cc.aztec.loadPublic(address, slot);
+```
+
+### loadPrivate
+
+#### Function Signature
+
+```ts
+public async loadPrivate(owner: AztecAddress, contract: AztecAddress, slot: Fr | bigint): Promise
+```
+
+#### Description
+
+Loads the value stored at the given slot in the private storage of the given contract.
+
+Note: One Field element occupies a storage slot. Hence, structs with multiple field elements will be spread over multiple sequential slots. Using loadPublic will only load a single field of the struct (depending on the size of the attributes within it).
+
+#### Example
+
+```typescript title="load_private_cheatcode" showLineNumbers
+const mintAmount = 100n;
+
+await mintTokensToPrivate(token, wallet, admin, mintAmount);
+await token.methods.sync_notes().simulate();
+
+const balancesAdminSlot = await cc.aztec.computeSlotInMap(TokenContract.storage.balances.slot, admin);
+
+// check if note was added to pending shield:
+const notes = await cc.aztec.loadPrivate(admin, token.address, balancesAdminSlot);
+
+// @note If you get pain for dinner, this guys is the reason.
+// Assuming that it is still testing the token contract, you need to look at the balances,
+// and then the type of note, currently a `UintNote` which stores fields: [owner, randomness, amount]
+const values = notes.map(note => note.items[2]);
+const balance = values.reduce((sum, current) => sum + current.toBigInt(), 0n);
+expect(balance).toEqual(mintAmount);
+```
+> Source code: yarn-project/end-to-end/src/e2e_cheat_codes.test.ts#L182-L199
+
+
+## Participate
+
+Keep up with the latest discussion and join the conversation in the [Aztec forum](https://discourse.aztec.network).
+
+You can also use the above link to request more cheatcodes.
+
+
diff --git a/docs/versioned_docs/version-v0.82.2-alpha-testnet.5/developers/reference/environment_reference/cli_reference.md b/docs/versioned_docs/version-v0.82.2-alpha-testnet.5/developers/reference/environment_reference/cli_reference.md
new file mode 100644
index 000000000000..5b8ee8dca8c5
--- /dev/null
+++ b/docs/versioned_docs/version-v0.82.2-alpha-testnet.5/developers/reference/environment_reference/cli_reference.md
@@ -0,0 +1,375 @@
+---
+title: CLI Reference
+tags: [sandbox]
+sidebar_position: 2
+---
+
+:::warning
+
+`aztec-builder` and `aztec-sandbox` have been deprecated in favor of `aztec` CLI
+
+:::
+- [Start](#starting-and-testing)
+- [Accounts](#account-management)
+- [Contract deployments and interaction](#contract-deployment-and-interaction)
+- [Network and node info](#network-and-node-information)
+- [Querying](#transaction-and-block-querying)
+- [Logging](#logging-and-data-retrieval)
+- [Debugging](#development-and-debugging-tools)
+- [L1 contracts](#l1-contract-management)
+- [Utils](#utility-commands)
+
+## Starting and testing
+
+### start
+
+Initiates various Aztec modules. It can be used to start individual components or the entire Aztec Sandbox.
+
+```
+aztec start [options]
+```
+
+Options:
+- `-sb, --sandbox`: Starts the Aztec Sandbox.
+- `-p, --port `: Specifies the port to run Aztec on (default: 8080).
+- `-n, --node [options]`: Starts the Aztec Node with specified options.
+- `-px, --pxe [options]`: Starts the PXE (Private eXecution Environment) with specified options.
+- `-a, --archiver [options]`: Starts the Archiver with specified options.
+- `-s, --sequencer [options]`: Starts the Sequencer with specified options.
+- `-r, --prover [options]`: Starts the Prover Agent with specified options.
+- `-o, --prover-node [options]`: Starts the Prover Node with specified options.
+- `-p2p, --p2p-bootstrap [options]`: Starts the P2P Bootstrap node with specified options.
+- `-t, --txe [options]`: Starts the TXE (Transaction Execution Environment) with specified options.
+
+### test
+
+Runs tests written in contracts.
+
+```
+aztec test [options]
+```
+
+Options:
+- `--workdir `: Sets the working directory inside the container (default: current directory).
+- `-e, --env `: Set environment variables (can be used multiple times).
+- `--no-tty`: Run the container without a TTY.
+- `--rm`: Automatically remove the container when it exits.
+- `-i, --interactive`: Keep STDIN open even if not attached.
+- `-t, --tty`: Allocate a pseudo-TTY.
+
+## Account Management
+
+### create-account
+Creates an Aztec account for sending transactions.
+
+```
+aztec create-account [options]
+```
+
+Options:
+- `--skip-initialization`: Skip initializing the account contract.
+- `--public-deploy`: Publicly deploys the account and registers the class if needed.
+- `--private-key `: Private key for the account (uses random by default).
+- `--register-only`: Just register the account on the PXE without deploying.
+- `--no-wait`: Skip waiting for the contract deployment.
+
+### get-accounts
+Retrieves all Aztec accounts stored in the PXE.
+
+```
+aztec get-accounts [options]
+```
+
+Options:
+- `--json`: Emit output as JSON.
+
+### get-account
+Retrieves an account given its Aztec address.
+
+```
+aztec get-account [options]
+```
+
+### register-recipient
+Registers a recipient in the PXE.
+
+```
+aztec register-recipient [options]
+```
+
+Required options:
+- `-a, --address `: The account's Aztec address.
+- `-p, --public-key `: The account public key.
+- `-pa, --partial-address `: The partially computed address of the account contract.
+
+## Contract Deployment and Interaction
+
+### deploy
+Deploys a compiled Aztec.nr contract to Aztec.
+
+```
+aztec deploy [options]
+```
+
+Options:
+- `--init `: The contract initializer function to call (default: "constructor").
+- `--no-init`: Leave the contract uninitialized.
+- `-a, --args `: Contract constructor arguments.
+- `-k, --public-key `: Optional encryption public key for this address.
+- `-s, --salt `: Optional deployment salt for generating the deployment address.
+- `--universal`: Do not mix the sender address into the deployment.
+- `--json`: Emit output as JSON.
+- `--no-wait`: Skip waiting for the contract deployment.
+- `--no-class-registration`: Don't register this contract class.
+- `--no-public-deployment`: Don't emit this contract's public bytecode.
+
+### send
+Calls a function on an Aztec contract.
+
+```
+aztec send [options]
+```
+
+Options:
+- `-a, --args [functionArgs...]`: Function arguments.
+- `-c, --contract-artifact `: Compiled Aztec.nr contract's ABI.
+- `-ca, --contract-address `: Aztec address of the contract.
+- `--no-wait`: Print transaction hash without waiting for it to be mined.
+
+### call
+Simulates the execution of a view (read-only) function on a deployed contract.
+
+```
+aztec call [options]
+```
+
+Options:
+- `-a, --args [functionArgs...]`: Function arguments.
+- `-c, --contract-artifact `: Compiled Aztec.nr contract's ABI.
+- `-ca, --contract-address `: Aztec address of the contract.
+- `-f, --from `: Aztec address of the caller.
+
+### add-contract
+Adds an existing contract to the PXE.
+
+```
+aztec add-contract [options]
+```
+
+Required options:
+- `-c, --contract-artifact `: Compiled Aztec.nr contract's ABI.
+- `-ca, --contract-address `: Aztec address of the contract.
+- `--init-hash `: Initialization hash.
+
+Optional:
+- `--salt `: Optional deployment salt.
+- `-p, --public-key `: Optional public key for this contract.
+- `--portal-address `: Optional address to a portal contract on L1.
+- `--deployer-address `: Optional address of the contract deployer.
+
+## Network and Node Information
+
+### get-node-info
+Retrieves information about an Aztec node at a URL.
+
+```
+aztec get-node-info [options]
+```
+
+### get-pxe-info
+Retrieves information about a PXE at a URL.
+
+```
+aztec get-pxe-info [options]
+```
+
+### block-number
+Retrieves the current Aztec L2 block number.
+
+```
+aztec block-number [options]
+```
+
+## Transaction and Block Querying
+
+### get-tx
+Retrieves the receipt for a specified transaction hash.
+
+```
+aztec get-tx [options]
+```
+
+### get-block
+Retrieves information for a given block or the latest block.
+
+```
+aztec get-block [blockNumber] [options]
+```
+
+Options:
+- `-f, --follow`: Keep polling for new blocks.
+
+## Logging and Data Retrieval
+
+### get-logs
+Retrieves unencrypted logs based on filter parameters.
+
+```
+aztec get-logs [options]
+```
+
+Options:
+- `-tx, --tx-hash `: Transaction hash to get the receipt for.
+- `-fb, --from-block `: Initial block number for getting logs.
+- `-tb, --to-block `: Up to which block to fetch logs.
+- `-al --after-log `: ID of a log after which to fetch the logs.
+- `-ca, --contract-address `: Contract address to filter logs by.
+- `--follow`: Keep polling for new logs until interrupted.
+
+## Development and Debugging Tools
+
+### flamegraph
+Generates a flamegraph of the gate counts of a private function call.
+
+```
+[SERVE=1] aztec flamegraph
+```
+
+### codegen
+Validates and generates an Aztec Contract ABI from Noir ABI.
+
+```
+aztec codegen [options]
+```
+
+Options:
+- `-o, --outdir `: Output folder for the generated code.
+- `--force`: Force code generation even when the contract has not changed.
+
+### update
+Updates Nodejs and Noir dependencies.
+
+```
+aztec update [projectPath] [options]
+```
+
+Options:
+- `--contract [paths...]`: Paths to contracts to update dependencies.
+- `--aztec-version `: The version to update Aztec packages to (default: latest).
+
+### inspect-contract
+Shows a list of external callable functions for a contract.
+
+```
+aztec inspect-contract
+```
+
+### parse-parameter-struct
+Helper for parsing an encoded string into a contract's parameter struct.
+
+```
+aztec parse-parameter-struct [options]
+```
+
+Required options:
+- `-c, --contract-artifact `: Compiled Aztec.nr contract's ABI.
+- `-p, --parameter `: The name of the struct parameter to decode into.
+
+## L1 Contract Management
+
+### deploy-l1-contracts
+Deploys all necessary Ethereum contracts for Aztec.
+
+```
+aztec deploy-l1-contracts [options]
+```
+
+Required options:
+- `-u, --rpc-urls `: List of URLs of Ethereum nodes (comma separated).
+- `-pk, --private-key `: The private key to use for deployment.
+
+### deploy-l1-verifier
+Deploys the rollup verifier contract.
+
+```
+aztec deploy-l1-verifier [options]
+```
+
+Required options:
+- `--eth-rpc-urls `: List of URLs of Ethereum nodes (comma separated).
+- `-pk, --private-key `: The private key to use for deployment.
+- `--verifier `: Either 'mock' or 'real'.
+
+### bridge-fee-juice
+Bridges (and optionally mints) L1 Fee Juice and pushes them to L2.
+
+```
+aztec bridge-fee-juice [options]
+```
+
+Required option:
+- `--l1-rpc-urls `: List of URLs of Ethereum nodes (comma separated).
+
+### get-l1-balance
+Gets the balance of ETH or an ERC20 token on L1 for a given Ethereum address.
+
+```
+aztec get-l1-balance [options]
+```
+
+Required option:
+- `--l1-rpc-urls `: List of URLs of Ethereum nodes (comma separated).
+
+## Utility Commands
+
+### generate-keys
+Generates encryption and signing private keys.
+
+```
+aztec generate-keys [options]
+```
+
+Option:
+- `-m, --mnemonic`: Optional mnemonic string for private key generation.
+
+### generate-p2p-private-key
+Generates a LibP2P peer private key.
+
+```
+aztec generate-p2p-private-key
+```
+
+### example-contracts
+Lists the example contracts available to deploy from @aztec/noir-contracts.js.
+
+```
+aztec example-contracts
+```
+
+### compute-selector
+Computes a selector for a given function signature.
+
+```
+aztec compute-selector
+```
+
+### bootstrap
+Bootstraps the blockchain.
+
+```
+aztec bootstrap [options]
+```
+
+### sequencers
+Manages or queries registered sequencers on the L1 rollup contract.
+
+```
+aztec sequencers [who] [options]
+```
+
+Commands: list, add, remove, who-next
+
+Required option:
+- `--l1-rpc-urls `: List of URLs of Ethereum nodes (comma separated).
+
+Note: Most commands accept a `--rpc-url` option to specify the Aztec node URL, and many accept fee-related options for gas limit and price configuration.
diff --git a/docs/versioned_docs/version-v0.82.2-alpha-testnet.5/developers/reference/environment_reference/cli_wallet_reference.md b/docs/versioned_docs/version-v0.82.2-alpha-testnet.5/developers/reference/environment_reference/cli_wallet_reference.md
new file mode 100644
index 000000000000..10c4d4f97829
--- /dev/null
+++ b/docs/versioned_docs/version-v0.82.2-alpha-testnet.5/developers/reference/environment_reference/cli_wallet_reference.md
@@ -0,0 +1,160 @@
+---
+title: CLI Wallet
+tags: [sandbox, wallet, cli]
+keywords: [wallet, cli wallet]
+sidebar_position: 3
+---
+
+For development, it may be useful to deploy, transact, or create notes in a non-programmatic way. You can use Aztec's CLI Wallet for thing such as:
+
+- Deploying contracts
+- Sending transactions
+- Bridging L1 "Fee Juice" into Aztec
+- Pushing arbitrary [notes](../../guides/smart_contracts/writing_contracts/notes/index.md) to your PXE
+- Creating [authwits](../../guides/smart_contracts/writing_contracts/authwit.md)
+- Aliasing info and secrets for further usage
+- Proving your transactions and profile gate counts
+
+:::info
+
+At any time, you can get an updated version of the existing commands and subcommands by adding `-h`. For example:
+
+```bash
+aztec-wallet create-account -h
+```
+
+:::
+
+## Aliases
+
+The CLI wallet makes extensive use of aliases, that is, when an address, artifact, secret, or other information is given a name that can be later used to reference it.
+
+Aliases have different types like `address` or `artifact` or `contract`. You can see a list of these types by running the help command `aztec-wallet alias -h`. You can then specify a type with the `:` character whenever needed. For example `accounts:master_yoda` or `artifacts:light_saber`.
+
+:::tip
+
+The wallet writes to the `last` alias if it's likely that you use that same alias in the next command.
+
+It will also try to determine which type is expected. For example, if the alias `master_yoda` is an account, you don't need to prepend `account:` if, for example, you're deploying a contract.
+
+You can create arbitrary aliases with the `alias` command. For example `aztec-wallet alias accounts test_alias 0x2c37902cdade7710bd2355e5949416dc5e43a16e0b13a5560854d2451d92d289`.
+
+:::
+
+## Account Management
+
+The wallet comes with some options for account deployment and management. You can register and deploy accounts, or only register them, and pass different options to serve your workflow.
+
+### create-account
+
+Generates a secret key and deploys an account contract.
+
+#### Example
+
+```bash
+aztec-wallet create-account -a master_yoda
+```
+
+### Deploy account
+
+Deploy an account that is already registered (i.e. your PXE knows about it) but not deployed. Most times you should pass an alias or address registered in the PXE by passing the `-f` or `--from` flag.
+
+#### Example
+
+```bash
+$ aztec-wallet create-account --register-only -a master_yoda
+...
+$ aztec-wallet deploy-account -f master_yoda
+```
+
+### Deploy
+
+You can deploy a [compiled contract](../../guides/smart_contracts/how_to_compile_contract.md) to the network.
+
+You probably want to look at flags such as `--init` which allows you to specify the [initializer function](../../guides/smart_contracts/writing_contracts/initializers.md) to call, or `-k` for the [encryption public key](../../../aztec/concepts/accounts/keys.md#incoming-viewing-keys) if the contract is expected to have notes being encrypted to it.
+
+You can pass arguments with the `--arg` flag.
+
+#### Example
+
+This example compiles the Jedi Code and deploys it from Master Yoda's account, initializing it with the parameter "Grand Master" and aliasing it to `jedi_order`. Notice how we can simply pass `master_yoda` in the `--from` flag (because `--from` always expects an account):
+
+```bash
+aztec-nargo compile
+aztec-wallet deploy ./target/jedi_code.nr --arg accounts:master_yoda --from master_yoda --alias jedi_order
+```
+
+### Send
+
+This command sends a transaction to the network by calling a contract's function. Just calling `aztec-wallet send` gives you a list of options, but you probably want to pass `--from` as the sender, `--contract-address` for your target's address, and `--args` if it requires arguments.
+
+#### Example
+
+```bash
+aztec-wallet send --from master_yoda --contract-address jedi_order --args "luke skywalker" train_jedi
+```
+
+Again, notice how it's not necessary to pass `contracts:jedi_order` as the wallet already knows that the only available type for `--contract-address` is a contract.
+
+### Manage authwits
+
+You can use the CLI wallet to quickly generate [Authentication Witnesses](../../guides/smart_contracts/writing_contracts/authwit.md). These allow you to authorize the caller to execute an action on behalf of an account. They get aliased into the `authwits` type.
+
+### In private
+
+The authwit management in private is a two-step process: create and add. It's not too different from a `send` command, but providing the caller that can privately execute the action on behalf of the caller.
+
+#### Example
+
+An example for authorizing an operator (ex. a DeFi protocol) to call the transfer_in_private action (transfer on the user's behalf):
+
+```bash
+aztec-wallet create-authwit transfer_in_private accounts:coruscant_trader -ca contracts:token --args accounts:jedi_master accounts:coruscant_trader 20 secrets:auth_nonce -f accounts:jedi_master -a secret_trade
+
+aztec-wallet add-authwit authwits:secret_trade accounts:jedi_master -f accounts:coruscant_trader
+```
+
+### In public
+
+A similar call to the above, but in public:
+
+```bash
+aztec-wallet authorize-action transfer_in_public accounts:coruscant_trader -ca contracts:token --args accounts:jedi_master accounts:coruscant_trader 20 secrets:auth_nonce -f accounts:jedi_master
+```
+
+### Simulate
+
+Simulates a transaction instead of sending it. This allows you to obtain i.e. the return value before sending the transaction.
+
+#### Example
+
+```bash
+aztec-wallet simulate --from master_yoda --contract-address jedi_order --args "luke_skywalker" train_jedi
+```
+
+### Profile
+
+This allows you to get the gate count of each private function in the transaction. Read more about profiling [here](../../guides/smart_contracts/profiling_transactions.md).
+
+#### Example
+
+```bash
+aztec-wallet profile --from master_yoda --contract-address jedi_order --args "luke_skywalker" train_jedi
+```
+
+### Bridge Fee Juice
+
+The wallet provides an easy way to mint the fee-paying asset on L1 and bridging it to L2. Current placeholder-name "fee juice".
+
+Using the sandbox, there's already a Fee Juice contract that manages this enshrined asset. You can optionally mint more Juice before bridging it.
+
+#### Example
+
+This example mints and bridges 1000 units of fee juice and bridges it to the `master_yoda` recipient on L2.
+
+```bash
+aztec-wallet bridge-fee-juice --mint 1000 master_yoda
+```
+
+## Proving
+You can prove a transaction using the aztec-wallet with a running sandbox. Follow the guide [here](../../guides/local_env/sandbox_proving.md#proving-with-aztec-wallet)
diff --git a/docs/versioned_docs/version-v0.82.2-alpha-testnet.5/developers/reference/environment_reference/index.md b/docs/versioned_docs/version-v0.82.2-alpha-testnet.5/developers/reference/environment_reference/index.md
new file mode 100644
index 000000000000..669c0329faf6
--- /dev/null
+++ b/docs/versioned_docs/version-v0.82.2-alpha-testnet.5/developers/reference/environment_reference/index.md
@@ -0,0 +1,19 @@
+---
+title: Developer Environment
+tags: [sandbox]
+sidebar_position: 0
+---
+
+The Aztec Sandbox is an environment for local development on the Aztec Network. It's easy to get setup with just a single, simple command, and contains all the components needed to develop and test Aztec contracts and applications.
+
+## What's in the Sandbox?
+
+The sandbox contains a local Ethereum instance running [Anvil](https://book.getfoundry.sh/anvil/), a local instance of the Aztec rollup and an aztec private execution client for handling user transactions and state.
+
+These provide a self contained environment which deploys Aztec on a local (empty) Ethereum network, creates 3 smart contract wallet accounts on the rollup, and allows transactions to be processed on the local Aztec sequencer.
+
+The current sandbox does not generate or verify proofs, but provides a working end to end developer flow for writing and interacting with Aztec.nr smart contracts.
+
+## Command line tools
+
+Aztec-nargo and aztec CLI are command-line tool allowing you to compile smart contracts. See the [compiling contracts guide](../../guides/local_env/run_more_than_one_pxe_sandbox.md) for more information.
diff --git a/docs/versioned_docs/version-v0.82.2-alpha-testnet.5/developers/reference/environment_reference/sandbox-reference.md b/docs/versioned_docs/version-v0.82.2-alpha-testnet.5/developers/reference/environment_reference/sandbox-reference.md
new file mode 100644
index 000000000000..c0519fc0c6b1
--- /dev/null
+++ b/docs/versioned_docs/version-v0.82.2-alpha-testnet.5/developers/reference/environment_reference/sandbox-reference.md
@@ -0,0 +1,166 @@
+---
+title: Sandbox Reference
+tags: [sandbox]
+sidebar_position: 1
+---
+
+:::tip
+
+For a quick start, follow the [guide](../../getting_started.md) to install the sandbox.
+
+:::
+
+## Environment Variables
+
+There are various environment variables you can use when running the whole sandbox or when running on of the available modes.
+
+**Sandbox**
+
+```sh
+LOG_LEVEL=debug # Options are 'fatal', 'error', 'warn', 'info', 'verbose', 'debug', 'trace'
+HOST_WORKDIR='${PWD}' # The location to store log outputs. Will use ~/.aztec where the binaries are stored by default.
+ETHEREUM_HOSTS=http://127.0.0.1:8545 # List of Ethereum JSON RPC URLs. We use an anvil instance that runs in parallel to the sandbox on docker by default.
+ANVIL_PORT=8545 # The port that docker will forward to the anvil instance (default: 8545)
+L1_CHAIN_ID=31337 # The Chain ID that the Ethereum host is using.
+TEST_ACCOUNTS='true' # Option to deploy 3 test account when sandbox starts. (default: true)
+MODE='sandbox' # Option to start the sandbox or a standalone part of the system. (default: sandbox)
+PXE_PORT=8080 # The port that the PXE will be listening to (default: 8080)
+AZTEC_NODE_PORT=8080 # The port that Aztec Node will be listening to (default: 8080)
+
+## Polling intervals ##
+ARCHIVER_POLLING_INTERVAL_MS=50
+P2P_BLOCK_CHECK_INTERVAL_MS=50
+SEQ_TX_POLLING_INTERVAL_MS=50
+WS_BLOCK_CHECK_INTERVAL_MS=50
+ARCHIVER_VIEM_POLLING_INTERVAL_MS=500
+```
+
+**Aztec Node**
+
+Variables like `DEPLOY_AZTEC_CONTRACTS` & `AZTEC_NODE_PORT` are valid here as described above.
+`TEST_ACCOUNTS` cannot be used here because the Aztec node does not control an Aztec account to deploy contracts from.
+
+```sh
+# P2P config #
+# Configuration variables for connecting a Node to the Aztec Node P2P network. You'll need a running P2P-Bootstrap node to connect to.
+P2P_ENABLED='false' # A flag to enable P2P networking for this node. (default: false)
+P2P_BLOCK_CHECK_INTERVAL_MS=100 # The frequency in which to check for new L2 blocks.
+P2P_PEER_CHECK_INTERVAL_MS=1000 # The frequency in which to check for peers.
+P2P_L2_BLOCK_QUEUE_SIZE=1000 # Size of queue of L2 blocks to store.
+P2P_IP='' # Announce IP of the peer. Defaults to working it out using discV5, otherwise set P2P_QUERY_FOR_IP if you are behind a NAT
+P2P_LISTEN_ADDR=0.0.0.0 # The address on which the P2P service should listen for connections.(default: 0.0.0.0)
+P2P_PORT=40400 # The Port that will be used for sending & listening p2p messages (default: 40400)
+PEER_ID_PRIVATE_KEY='' # An optional peer id private key. If blank, will generate a random key.
+BOOTSTRAP_NODES='' # A list of bootstrap peers to connect to, separated by commas
+P2P_ANNOUNCE_PORT='' # Port to announce to the p2p network
+P2P_NAT_ENABLED='false' # Whether to enable NAT from libp2p
+P2P_MAX_PEERS=100 # The maximum number of peers (a peer count above this will cause the node to refuse connection attempts)
+
+## Aztec Contract Addresses ##
+# When running a standalone node, you need to have deployed Aztec contracts on your Ethereum host, then declare their addresses as env variables.
+REGISTRY_CONTRACT_ADDRESS=0x01234567890abcde01234567890abcde
+INBOX_CONTRACT_ADDRESS=0x01234567890abcde01234567890abcde
+OUTBOX_CONTRACT_ADDRESS=0x01234567890abcde01234567890abcde
+ROLLUP_CONTRACT_ADDRESS=0x01234567890abcde01234567890abcde
+
+## Sequencer variables ##
+SEQ_PUBLISHER_PRIVATE_KEY=0x01234567890abcde01234567890abcde # Private key of an ethereum account that will be used by the sequencer to publish blocks.
+SEQ_MAX_TX_PER_BLOCK=32 # Maximum txs to go on a block. (default: 32)
+SEQ_MIN_TX_PER_BLOCK=1 # Minimum txs to go on a block. (default: 1)
+
+## Validator variables ##
+VALIDATOR_PRIVATE_KEY=0x01234567890abcde01234567890abcde # Private key of the ethereum account that will be used to perform validator duties
+```
+
+**PXE**
+
+Variables like `TEST_ACCOUNTS` & `PXE_PORT` are valid here as described above.
+
+```sh
+AZTEC_NODE_URL='http://localhost:8079' # The address of an Aztec Node URL that the PXE will connect to (default: http://localhost:8079)
+PXE_PORT=8080 # The port that the PXE will be listening to (default: 8080)
+TEST_ACCOUNTS='true' # Option to deploy 3 test account when sandbox starts. (default: true)
+PXE_L2_STARTING_BLOCK=1 # L2 Block to start synching the PXE from (default: 1)
+```
+
+**P2P Bootstrap Node**
+
+The P2P Bootstrap node is a standalone app whose purpose is to assist new P2P network participants in acquiring peers.
+
+```sh
+PEER_ID_PRIVATE_KEY='' # The private key to be used by the peer for secure communications with other peers. This key will also be used to derive the Peer ID.
+P2P_IP='' # Announce IP of the peer. Defaults to working it out using discV5, otherwise set P2P_QUERY_FOR_IP if you are behind a NAT
+P2P_LISTEN_ADDR=0.0.0.0 # The address on which the P2P service should listen for connections.(default: 0.0.0.0)
+P2P_PORT=40400 # The Port that will be used for sending & listening p2p messages (default: 40400)
+```
+
+## Cheat Codes
+
+To help with testing, the sandbox is shipped with a set of cheatcodes.
+
+Cheatcodes allow you to change the time of the Aztec block, load certain state or more easily manipulate Ethereum instead of having to write dedicated RPC calls to anvil or hardhat.
+
+You can find the cheat code reference [here](./cheat_codes.md).
+
+## Contracts
+
+We have shipped a number of example contracts in the `@aztec/noir-contracts.js` [npm package](https://www.npmjs.com/package/@aztec/noir-contracts.js). This is included with the sandbox by default so you are able to use these contracts to test with.
+
+```bash
+AppSubscriptionContractArtifact
+AuthContractArtifact
+BenchmarkingContractArtifact
+CardGameContractArtifact
+ChildContractArtifact
+ClaimContractArtifact
+ContractClassRegistererContractArtifact
+ContractInstanceDeployerContractArtifact
+CounterContractArtifact
+CrowdfundingContractArtifact
+DocsExampleContractArtifact
+EasyPrivateTokenContractArtifact
+EasyPrivateVotingContractArtifact
+EcdsaAccountContractArtifact
+EscrowContractArtifact
+FPCContractArtifact
+FeeJuiceContractArtifact
+ImportTestContractArtifact
+LendingContractArtifact
+MultiCallEntrypointContractArtifact
+ParentContractArtifact
+PendingNoteHashesContractArtifact
+PriceFeedContractArtifact
+ReaderContractArtifact
+SchnorrAccountContractArtifact
+SchnorrHardcodedAccountContractArtifact
+SchnorrSingleKeyAccountContractArtifact
+SlowTreeContractArtifact
+StatefulTestContractArtifact
+TestContractArtifact
+TokenBlacklistContractArtifact
+TokenBridgeContractArtifact
+TokenContractArtifact
+UniswapContractArtifact
+```
+
+> Source code: /yarn-project/end-to-end/src/composed/cli_docs_sandbox.test.ts#L95-L118
+
+You can see all of our example contracts in the monorepo [here (GitHub link)](https://github.com/AztecProtocol/aztec-packages/tree/master/noir-projects/noir-contracts/contracts).
+
+## Running Aztec PXE / Node / P2P-Bootstrap node individually
+
+If you wish to run components of the Aztec network stack separately, you can use the `aztec start` command with various options for enabling components.
+
+```bash
+aztec start --node [nodeOptions] --pxe [pxeOptions] --archiver [archiverOptions] --sequencer [sequencerOptions] --prover [proverOptions] --p2p-bootstrap [p2pOptions]
+```
+
+Starting the aztec node alongside a PXE, sequencer or archiver, will attach the components to the node. Eg if you want to run a PXE separately to a node, you can [read this guide](../../guides/local_env/run_more_than_one_pxe_sandbox.md).
+
+## Update the sandbox
+
+To update the sandbox, run:
+
+```bash
+aztec-up
+```
diff --git a/docs/versioned_docs/version-v0.82.2-alpha-testnet.5/developers/reference/smart_contract_reference/_category_.json b/docs/versioned_docs/version-v0.82.2-alpha-testnet.5/developers/reference/smart_contract_reference/_category_.json
new file mode 100644
index 000000000000..968f9bcf0a6b
--- /dev/null
+++ b/docs/versioned_docs/version-v0.82.2-alpha-testnet.5/developers/reference/smart_contract_reference/_category_.json
@@ -0,0 +1,6 @@
+{
+ "label": "Smart Contract Reference",
+ "position": 1,
+ "collapsible": true,
+ "collapsed": true
+}
diff --git a/docs/versioned_docs/version-v0.82.2-alpha-testnet.5/developers/reference/smart_contract_reference/aztec-nr/address-note/address_note.md b/docs/versioned_docs/version-v0.82.2-alpha-testnet.5/developers/reference/smart_contract_reference/aztec-nr/address-note/address_note.md
new file mode 100644
index 000000000000..e16195153664
--- /dev/null
+++ b/docs/versioned_docs/version-v0.82.2-alpha-testnet.5/developers/reference/smart_contract_reference/aztec-nr/address-note/address_note.md
@@ -0,0 +1,23 @@
+# AddressNote
+
+## Fields
+| Field | Type |
+| --- | --- |
+| address | AztecAddress |
+| owner | AztecAddress |
+| randomness | Field |
+
+## Methods
+
+### new
+
+```rust
+AddressNote::new(address, owner);
+```
+
+#### Parameters
+| Name | Type |
+| --- | --- |
+| address | AztecAddress |
+| owner | AztecAddress |
+
diff --git a/docs/versioned_docs/version-v0.82.2-alpha-testnet.5/developers/reference/smart_contract_reference/aztec-nr/authwit/account.md b/docs/versioned_docs/version-v0.82.2-alpha-testnet.5/developers/reference/smart_contract_reference/aztec-nr/authwit/account.md
new file mode 100644
index 000000000000..0fcca4b241f4
--- /dev/null
+++ b/docs/versioned_docs/version-v0.82.2-alpha-testnet.5/developers/reference/smart_contract_reference/aztec-nr/authwit/account.md
@@ -0,0 +1,43 @@
+## Standalone Functions
+
+### init
+
+```rust
+init(context, is_valid_impl, Field);
+```
+
+#### Parameters
+| Name | Type |
+| --- | --- |
+| context | Context |
+| is_valid_impl | fn(&mut PrivateContext |
+| Field | |
+
+### entrypoint
+
+```rust
+entrypoint(self, app_payload, fee_payload, cancellable);
+```
+
+docs:start:entrypoint
+
+#### Parameters
+| Name | Type |
+| --- | --- |
+| self | |
+| app_payload | AppPayload |
+| fee_payload | FeePayload |
+| cancellable | bool |
+
+### verify_private_authwit
+
+```rust
+verify_private_authwit(self, inner_hash);
+```
+
+#### Parameters
+| Name | Type |
+| --- | --- |
+| self | |
+| inner_hash | Field |
+
diff --git a/docs/versioned_docs/version-v0.82.2-alpha-testnet.5/developers/reference/smart_contract_reference/aztec-nr/authwit/auth.md b/docs/versioned_docs/version-v0.82.2-alpha-testnet.5/developers/reference/smart_contract_reference/aztec-nr/authwit/auth.md
new file mode 100644
index 000000000000..468b57445dd2
--- /dev/null
+++ b/docs/versioned_docs/version-v0.82.2-alpha-testnet.5/developers/reference/smart_contract_reference/aztec-nr/authwit/auth.md
@@ -0,0 +1,138 @@
+## Standalone Functions
+
+### assert_current_call_valid_authwit
+
+```rust
+assert_current_call_valid_authwit(context, on_behalf_of);
+```
+
+docs:start:assert_current_call_valid_authwit
+
+#### Parameters
+| Name | Type |
+| --- | --- |
+| context | &mut PrivateContext |
+| on_behalf_of | AztecAddress |
+
+### assert_inner_hash_valid_authwit
+
+```rust
+assert_inner_hash_valid_authwit(context, on_behalf_of, inner_hash, );
+```
+
+#### Parameters
+| Name | Type |
+| --- | --- |
+| context | &mut PrivateContext |
+| on_behalf_of | AztecAddress |
+| inner_hash | Field |
+| | |
+
+### assert_current_call_valid_authwit_public
+
+```rust
+assert_current_call_valid_authwit_public(context, on_behalf_of, );
+```
+
+#### Parameters
+| Name | Type |
+| --- | --- |
+| context | &mut PublicContext |
+| on_behalf_of | AztecAddress |
+| | |
+
+### assert_inner_hash_valid_authwit_public
+
+```rust
+assert_inner_hash_valid_authwit_public(context, on_behalf_of, inner_hash, );
+```
+
+#### Parameters
+| Name | Type |
+| --- | --- |
+| context | &mut PublicContext |
+| on_behalf_of | AztecAddress |
+| inner_hash | Field |
+| | |
+
+### compute_authwit_message_hash_from_call
+
+```rust
+compute_authwit_message_hash_from_call(caller, consumer, chain_id, version, selector, args, );
+```
+
+#### Parameters
+| Name | Type |
+| --- | --- |
+| caller | AztecAddress |
+| consumer | AztecAddress |
+| chain_id | Field |
+| version | Field |
+| selector | FunctionSelector |
+| args | [Field; N] |
+| | |
+
+### compute_inner_authwit_hash
+
+```rust
+compute_inner_authwit_hash(args);
+```
+
+#### Parameters
+| Name | Type |
+| --- | --- |
+| args | [Field; N] |
+
+### compute_authwit_nullifier
+
+```rust
+compute_authwit_nullifier(on_behalf_of, inner_hash);
+```
+
+#### Parameters
+| Name | Type |
+| --- | --- |
+| on_behalf_of | AztecAddress |
+| inner_hash | Field |
+
+### compute_authwit_message_hash
+
+```rust
+compute_authwit_message_hash(consumer, chain_id, version, inner_hash, );
+```
+
+#### Parameters
+| Name | Type |
+| --- | --- |
+| consumer | AztecAddress |
+| chain_id | Field |
+| version | Field |
+| inner_hash | Field |
+| | |
+
+### set_authorized
+
+```rust
+set_authorized(context, message_hash, authorize, );
+```
+
+#### Parameters
+| Name | Type |
+| --- | --- |
+| context | &mut PublicContext |
+| message_hash | Field |
+| authorize | bool |
+| | |
+
+### set_reject_all
+
+```rust
+set_reject_all(context, reject);
+```
+
+#### Parameters
+| Name | Type |
+| --- | --- |
+| context | &mut PublicContext |
+| reject | bool |
+
diff --git a/docs/versioned_docs/version-v0.82.2-alpha-testnet.5/developers/reference/smart_contract_reference/aztec-nr/authwit/auth_witness.md b/docs/versioned_docs/version-v0.82.2-alpha-testnet.5/developers/reference/smart_contract_reference/aztec-nr/authwit/auth_witness.md
new file mode 100644
index 000000000000..11338206f5cd
--- /dev/null
+++ b/docs/versioned_docs/version-v0.82.2-alpha-testnet.5/developers/reference/smart_contract_reference/aztec-nr/authwit/auth_witness.md
@@ -0,0 +1,24 @@
+## Standalone Functions
+
+### get_auth_witness_oracle
+
+```rust
+get_auth_witness_oracle(_message_hash);
+```
+
+#### Parameters
+| Name | Type |
+| --- | --- |
+| _message_hash | Field |
+
+### get_auth_witness
+
+```rust
+get_auth_witness(message_hash);
+```
+
+#### Parameters
+| Name | Type |
+| --- | --- |
+| message_hash | Field |
+
diff --git a/docs/versioned_docs/version-v0.82.2-alpha-testnet.5/developers/reference/smart_contract_reference/aztec-nr/authwit/cheatcodes.md b/docs/versioned_docs/version-v0.82.2-alpha-testnet.5/developers/reference/smart_contract_reference/aztec-nr/authwit/cheatcodes.md
new file mode 100644
index 000000000000..5203a24f03fa
--- /dev/null
+++ b/docs/versioned_docs/version-v0.82.2-alpha-testnet.5/developers/reference/smart_contract_reference/aztec-nr/authwit/cheatcodes.md
@@ -0,0 +1,30 @@
+## Standalone Functions
+
+### add_private_authwit_from_call_interface
+
+```rust
+add_private_authwit_from_call_interface(on_behalf_of, caller, call_interface, );
+```
+
+#### Parameters
+| Name | Type |
+| --- | --- |
+| on_behalf_of | AztecAddress |
+| caller | AztecAddress |
+| call_interface | C |
+| | |
+
+### add_public_authwit_from_call_interface
+
+```rust
+add_public_authwit_from_call_interface(on_behalf_of, caller, call_interface, );
+```
+
+#### Parameters
+| Name | Type |
+| --- | --- |
+| on_behalf_of | AztecAddress |
+| caller | AztecAddress |
+| call_interface | C |
+| | |
+
diff --git a/docs/versioned_docs/version-v0.82.2-alpha-testnet.5/developers/reference/smart_contract_reference/aztec-nr/authwit/entrypoint/app.md b/docs/versioned_docs/version-v0.82.2-alpha-testnet.5/developers/reference/smart_contract_reference/aztec-nr/authwit/entrypoint/app.md
new file mode 100644
index 000000000000..2a7c2659fee5
--- /dev/null
+++ b/docs/versioned_docs/version-v0.82.2-alpha-testnet.5/developers/reference/smart_contract_reference/aztec-nr/authwit/entrypoint/app.md
@@ -0,0 +1,48 @@
+# AppPayload
+
+## Fields
+| Field | Type |
+| --- | --- |
+| function_calls | FunctionCall; ACCOUNT_MAX_CALLS] |
+| pub nonce | Field |
+
+## Methods
+
+### to_be_bytes
+
+Serializes the payload as an array of bytes. Useful for hashing with sha256.
+
+```rust
+AppPayload::to_be_bytes(self);
+```
+
+#### Parameters
+| Name | Type |
+| --- | --- |
+| self | |
+
+### execute_calls
+
+```rust
+AppPayload::execute_calls(self, context);
+```
+
+#### Parameters
+| Name | Type |
+| --- | --- |
+| self | |
+| context | &mut PrivateContext |
+
+## Standalone Functions
+
+### hash
+
+```rust
+hash(self);
+```
+
+#### Parameters
+| Name | Type |
+| --- | --- |
+| self | |
+
diff --git a/docs/versioned_docs/version-v0.82.2-alpha-testnet.5/developers/reference/smart_contract_reference/aztec-nr/authwit/entrypoint/fee.md b/docs/versioned_docs/version-v0.82.2-alpha-testnet.5/developers/reference/smart_contract_reference/aztec-nr/authwit/entrypoint/fee.md
new file mode 100644
index 000000000000..b72c0ab0ecb2
--- /dev/null
+++ b/docs/versioned_docs/version-v0.82.2-alpha-testnet.5/developers/reference/smart_contract_reference/aztec-nr/authwit/entrypoint/fee.md
@@ -0,0 +1,47 @@
+# FeePayload
+
+## Fields
+| Field | Type |
+| --- | --- |
+| function_calls | FunctionCall; MAX_FEE_FUNCTION_CALLS] |
+| nonce | Field |
+| is_fee_payer | bool |
+
+## Methods
+
+### to_be_bytes
+
+```rust
+FeePayload::to_be_bytes(self);
+```
+
+#### Parameters
+| Name | Type |
+| --- | --- |
+| self | |
+
+### execute_calls
+
+```rust
+FeePayload::execute_calls(self, context);
+```
+
+#### Parameters
+| Name | Type |
+| --- | --- |
+| self | |
+| context | &mut PrivateContext |
+
+## Standalone Functions
+
+### hash
+
+```rust
+hash(self);
+```
+
+#### Parameters
+| Name | Type |
+| --- | --- |
+| self | |
+
diff --git a/docs/versioned_docs/version-v0.82.2-alpha-testnet.5/developers/reference/smart_contract_reference/aztec-nr/authwit/entrypoint/function_call.md b/docs/versioned_docs/version-v0.82.2-alpha-testnet.5/developers/reference/smart_contract_reference/aztec-nr/authwit/entrypoint/function_call.md
new file mode 100644
index 000000000000..57848a06db89
--- /dev/null
+++ b/docs/versioned_docs/version-v0.82.2-alpha-testnet.5/developers/reference/smart_contract_reference/aztec-nr/authwit/entrypoint/function_call.md
@@ -0,0 +1,24 @@
+# FunctionCall
+
+## Fields
+| Field | Type |
+| --- | --- |
+| pub args_hash | Field, /* args_hash is calldata_hash if is_public is true */ |
+| pub function_selector | FunctionSelector |
+| pub target_address | AztecAddress |
+| pub is_public | bool |
+| pub is_static | bool |
+
+## Methods
+
+### to_be_bytes
+
+```rust
+FunctionCall::to_be_bytes(self);
+```
+
+#### Parameters
+| Name | Type |
+| --- | --- |
+| self | |
+
diff --git a/docs/versioned_docs/version-v0.82.2-alpha-testnet.5/developers/reference/smart_contract_reference/aztec-nr/aztec/capsules/mod.md b/docs/versioned_docs/version-v0.82.2-alpha-testnet.5/developers/reference/smart_contract_reference/aztec-nr/aztec/capsules/mod.md
new file mode 100644
index 000000000000..3ba9d4ad3c6f
--- /dev/null
+++ b/docs/versioned_docs/version-v0.82.2-alpha-testnet.5/developers/reference/smart_contract_reference/aztec-nr/aztec/capsules/mod.md
@@ -0,0 +1,137 @@
+## Standalone Functions
+
+### at
+
+```rust
+at(contract_address, base_slot);
+```
+
+#### Parameters
+| Name | Type |
+| --- | --- |
+| contract_address | AztecAddress |
+| base_slot | Field |
+
+### len
+
+```rust
+len(self);
+```
+
+#### Parameters
+| Name | Type |
+| --- | --- |
+| self | |
+
+### push
+
+```rust
+push(self, value);
+```
+
+#### Parameters
+| Name | Type |
+| --- | --- |
+| self | |
+| value | T |
+
+### get
+
+```rust
+get(self, index);
+```
+
+#### Parameters
+| Name | Type |
+| --- | --- |
+| self | |
+| index | u32 |
+
+### remove
+
+```rust
+remove(self, index);
+```
+
+#### Parameters
+| Name | Type |
+| --- | --- |
+| self | |
+| index | u32 |
+
+### slot_at
+
+```rust
+slot_at(self, index);
+```
+
+#### Parameters
+| Name | Type |
+| --- | --- |
+| self | |
+| index | u32 |
+
+### setup
+
+```rust
+setup();
+```
+
+Takes no parameters.
+
+### empty_array
+
+```rust
+empty_array();
+```
+
+Takes no parameters.
+
+### empty_array_read
+
+```rust
+empty_array_read();
+```
+
+Takes no parameters.
+
+### array_push
+
+```rust
+array_push();
+```
+
+Takes no parameters.
+
+### read_past_len
+
+```rust
+read_past_len();
+```
+
+Takes no parameters.
+
+### array_remove_last
+
+```rust
+array_remove_last();
+```
+
+Takes no parameters.
+
+### array_remove_some
+
+```rust
+array_remove_some();
+```
+
+Takes no parameters.
+
+### array_remove_all
+
+```rust
+array_remove_all();
+```
+
+Takes no parameters.
+
diff --git a/docs/versioned_docs/version-v0.82.2-alpha-testnet.5/developers/reference/smart_contract_reference/aztec-nr/aztec/context/call_interfaces.md b/docs/versioned_docs/version-v0.82.2-alpha-testnet.5/developers/reference/smart_contract_reference/aztec-nr/aztec/context/call_interfaces.md
new file mode 100644
index 000000000000..a0d2bd0f914c
--- /dev/null
+++ b/docs/versioned_docs/version-v0.82.2-alpha-testnet.5/developers/reference/smart_contract_reference/aztec-nr/aztec/context/call_interfaces.md
@@ -0,0 +1,897 @@
+## Standalone Functions
+
+### get_args
+
+```rust
+get_args(self);
+```
+
+#### Parameters
+| Name | Type |
+| --- | --- |
+| self | |
+
+### get_selector
+
+```rust
+get_selector(self);
+```
+
+#### Parameters
+| Name | Type |
+| --- | --- |
+| self | |
+
+### get_name
+
+```rust
+get_name(self);
+```
+
+#### Parameters
+| Name | Type |
+| --- | --- |
+| self | |
+
+### get_contract_address
+
+```rust
+get_contract_address(self);
+```
+
+#### Parameters
+| Name | Type |
+| --- | --- |
+| self | |
+
+### get_is_static
+
+```rust
+get_is_static(self);
+```
+
+#### Parameters
+| Name | Type |
+| --- | --- |
+| self | |
+
+### new
+
+```rust
+new(target_contract, selector, name, args, is_static, );
+```
+
+#### Parameters
+| Name | Type |
+| --- | --- |
+| target_contract | AztecAddress |
+| selector | FunctionSelector |
+| name | str<N> |
+| args | [Field] |
+| is_static | bool |
+| | |
+
+### call
+
+```rust
+call(self, context);
+```
+
+#### Parameters
+| Name | Type |
+| --- | --- |
+| self | |
+| context | &mut PrivateContext |
+
+### view
+
+```rust
+view(self, context);
+```
+
+#### Parameters
+| Name | Type |
+| --- | --- |
+| self | |
+| context | &mut PrivateContext |
+
+### get_args
+
+```rust
+get_args(self);
+```
+
+#### Parameters
+| Name | Type |
+| --- | --- |
+| self | |
+
+### get_selector
+
+```rust
+get_selector(self);
+```
+
+#### Parameters
+| Name | Type |
+| --- | --- |
+| self | |
+
+### get_name
+
+```rust
+get_name(self);
+```
+
+#### Parameters
+| Name | Type |
+| --- | --- |
+| self | |
+
+### get_contract_address
+
+```rust
+get_contract_address(self);
+```
+
+#### Parameters
+| Name | Type |
+| --- | --- |
+| self | |
+
+### get_is_static
+
+```rust
+get_is_static(self);
+```
+
+#### Parameters
+| Name | Type |
+| --- | --- |
+| self | |
+
+### new
+
+```rust
+new(target_contract, selector, name, args, is_static, );
+```
+
+#### Parameters
+| Name | Type |
+| --- | --- |
+| target_contract | AztecAddress |
+| selector | FunctionSelector |
+| name | str<N> |
+| args | [Field] |
+| is_static | bool |
+| | |
+
+### call
+
+```rust
+call(self, context);
+```
+
+#### Parameters
+| Name | Type |
+| --- | --- |
+| self | |
+| context | &mut PrivateContext |
+
+### view
+
+```rust
+view(self, context);
+```
+
+#### Parameters
+| Name | Type |
+| --- | --- |
+| self | |
+| context | &mut PrivateContext |
+
+### get_args
+
+```rust
+get_args(self);
+```
+
+#### Parameters
+| Name | Type |
+| --- | --- |
+| self | |
+
+### get_selector
+
+```rust
+get_selector(self);
+```
+
+#### Parameters
+| Name | Type |
+| --- | --- |
+| self | |
+
+### get_name
+
+```rust
+get_name(self);
+```
+
+#### Parameters
+| Name | Type |
+| --- | --- |
+| self | |
+
+### get_contract_address
+
+```rust
+get_contract_address(self);
+```
+
+#### Parameters
+| Name | Type |
+| --- | --- |
+| self | |
+
+### get_is_static
+
+```rust
+get_is_static(self);
+```
+
+#### Parameters
+| Name | Type |
+| --- | --- |
+| self | |
+
+### new
+
+```rust
+new(target_contract, selector, name, args, );
+```
+
+#### Parameters
+| Name | Type |
+| --- | --- |
+| target_contract | AztecAddress |
+| selector | FunctionSelector |
+| name | str<N> |
+| args | [Field] |
+| | |
+
+### view
+
+```rust
+view(self, context);
+```
+
+#### Parameters
+| Name | Type |
+| --- | --- |
+| self | |
+| context | &mut PrivateContext |
+
+### get_args
+
+```rust
+get_args(self);
+```
+
+#### Parameters
+| Name | Type |
+| --- | --- |
+| self | |
+
+### get_selector
+
+```rust
+get_selector(self);
+```
+
+#### Parameters
+| Name | Type |
+| --- | --- |
+| self | |
+
+### get_name
+
+```rust
+get_name(self);
+```
+
+#### Parameters
+| Name | Type |
+| --- | --- |
+| self | |
+
+### get_contract_address
+
+```rust
+get_contract_address(self);
+```
+
+#### Parameters
+| Name | Type |
+| --- | --- |
+| self | |
+
+### get_is_static
+
+```rust
+get_is_static(self);
+```
+
+#### Parameters
+| Name | Type |
+| --- | --- |
+| self | |
+
+### new
+
+```rust
+new(target_contract, selector, name, args, );
+```
+
+#### Parameters
+| Name | Type |
+| --- | --- |
+| target_contract | AztecAddress |
+| selector | FunctionSelector |
+| name | str<N> |
+| args | [Field] |
+| | |
+
+### view
+
+```rust
+view(self, context);
+```
+
+#### Parameters
+| Name | Type |
+| --- | --- |
+| self | |
+| context | &mut PrivateContext |
+
+### get_args
+
+```rust
+get_args(self);
+```
+
+#### Parameters
+| Name | Type |
+| --- | --- |
+| self | |
+
+### get_selector
+
+```rust
+get_selector(self);
+```
+
+#### Parameters
+| Name | Type |
+| --- | --- |
+| self | |
+
+### get_name
+
+```rust
+get_name(self);
+```
+
+#### Parameters
+| Name | Type |
+| --- | --- |
+| self | |
+
+### get_contract_address
+
+```rust
+get_contract_address(self);
+```
+
+#### Parameters
+| Name | Type |
+| --- | --- |
+| self | |
+
+### get_is_static
+
+```rust
+get_is_static(self);
+```
+
+#### Parameters
+| Name | Type |
+| --- | --- |
+| self | |
+
+### new
+
+```rust
+new(target_contract, selector, name, args, is_static, );
+```
+
+#### Parameters
+| Name | Type |
+| --- | --- |
+| target_contract | AztecAddress |
+| selector | FunctionSelector |
+| name | str<N> |
+| args | [Field] |
+| is_static | bool |
+| | |
+
+### with_gas
+
+```rust
+with_gas(self, gas_opts);
+```
+
+#### Parameters
+| Name | Type |
+| --- | --- |
+| self | &mut Self |
+| gas_opts | GasOpts |
+
+### call
+
+```rust
+call(self, context);
+```
+
+#### Parameters
+| Name | Type |
+| --- | --- |
+| self | |
+| context | &mut PublicContext |
+
+### view
+
+```rust
+view(self, context);
+```
+
+#### Parameters
+| Name | Type |
+| --- | --- |
+| self | |
+| context | &mut PublicContext |
+
+### enqueue
+
+```rust
+enqueue(self, context);
+```
+
+#### Parameters
+| Name | Type |
+| --- | --- |
+| self | |
+| context | &mut PrivateContext |
+
+### enqueue_view
+
+```rust
+enqueue_view(self, context);
+```
+
+#### Parameters
+| Name | Type |
+| --- | --- |
+| self | |
+| context | &mut PrivateContext |
+
+### get_args
+
+```rust
+get_args(self);
+```
+
+#### Parameters
+| Name | Type |
+| --- | --- |
+| self | |
+
+### get_selector
+
+```rust
+get_selector(self);
+```
+
+#### Parameters
+| Name | Type |
+| --- | --- |
+| self | |
+
+### get_name
+
+```rust
+get_name(self);
+```
+
+#### Parameters
+| Name | Type |
+| --- | --- |
+| self | |
+
+### get_contract_address
+
+```rust
+get_contract_address(self);
+```
+
+#### Parameters
+| Name | Type |
+| --- | --- |
+| self | |
+
+### get_is_static
+
+```rust
+get_is_static(self);
+```
+
+#### Parameters
+| Name | Type |
+| --- | --- |
+| self | |
+
+### new
+
+```rust
+new(target_contract, selector, name, args, is_static, );
+```
+
+#### Parameters
+| Name | Type |
+| --- | --- |
+| target_contract | AztecAddress |
+| selector | FunctionSelector |
+| name | str<N> |
+| args | [Field] |
+| is_static | bool |
+| | |
+
+### with_gas
+
+```rust
+with_gas(self, gas_opts);
+```
+
+#### Parameters
+| Name | Type |
+| --- | --- |
+| self | &mut Self |
+| gas_opts | GasOpts |
+
+### call
+
+```rust
+call(self, context);
+```
+
+#### Parameters
+| Name | Type |
+| --- | --- |
+| self | |
+| context | &mut PublicContext |
+
+### view
+
+```rust
+view(self, context);
+```
+
+#### Parameters
+| Name | Type |
+| --- | --- |
+| self | |
+| context | &mut PublicContext |
+
+### enqueue
+
+```rust
+enqueue(self, context);
+```
+
+#### Parameters
+| Name | Type |
+| --- | --- |
+| self | |
+| context | &mut PrivateContext |
+
+### enqueue_view
+
+```rust
+enqueue_view(self, context);
+```
+
+#### Parameters
+| Name | Type |
+| --- | --- |
+| self | |
+| context | &mut PrivateContext |
+
+### set_as_teardown
+
+```rust
+set_as_teardown(self, context);
+```
+
+#### Parameters
+| Name | Type |
+| --- | --- |
+| self | |
+| context | &mut PrivateContext |
+
+### get_args
+
+```rust
+get_args(self);
+```
+
+#### Parameters
+| Name | Type |
+| --- | --- |
+| self | |
+
+### get_selector
+
+```rust
+get_selector(self);
+```
+
+#### Parameters
+| Name | Type |
+| --- | --- |
+| self | |
+
+### get_name
+
+```rust
+get_name(self);
+```
+
+#### Parameters
+| Name | Type |
+| --- | --- |
+| self | |
+
+### get_contract_address
+
+```rust
+get_contract_address(self);
+```
+
+#### Parameters
+| Name | Type |
+| --- | --- |
+| self | |
+
+### get_is_static
+
+```rust
+get_is_static(self);
+```
+
+#### Parameters
+| Name | Type |
+| --- | --- |
+| self | |
+
+### new
+
+```rust
+new(target_contract, selector, name, args, );
+```
+
+#### Parameters
+| Name | Type |
+| --- | --- |
+| target_contract | AztecAddress |
+| selector | FunctionSelector |
+| name | str<N> |
+| args | [Field] |
+| | |
+
+### with_gas
+
+```rust
+with_gas(self, gas_opts);
+```
+
+#### Parameters
+| Name | Type |
+| --- | --- |
+| self | &mut Self |
+| gas_opts | GasOpts |
+
+### view
+
+```rust
+view(self, context);
+```
+
+#### Parameters
+| Name | Type |
+| --- | --- |
+| self | |
+| context | &mut PublicContext |
+
+### enqueue_view
+
+```rust
+enqueue_view(self, context);
+```
+
+#### Parameters
+| Name | Type |
+| --- | --- |
+| self | |
+| context | &mut PrivateContext |
+
+### get_args
+
+```rust
+get_args(self);
+```
+
+#### Parameters
+| Name | Type |
+| --- | --- |
+| self | |
+
+### get_selector
+
+```rust
+get_selector(self);
+```
+
+#### Parameters
+| Name | Type |
+| --- | --- |
+| self | |
+
+### get_name
+
+```rust
+get_name(self);
+```
+
+#### Parameters
+| Name | Type |
+| --- | --- |
+| self | |
+
+### get_contract_address
+
+```rust
+get_contract_address(self);
+```
+
+#### Parameters
+| Name | Type |
+| --- | --- |
+| self | |
+
+### get_is_static
+
+```rust
+get_is_static(self);
+```
+
+#### Parameters
+| Name | Type |
+| --- | --- |
+| self | |
+
+### new
+
+```rust
+new(target_contract, selector, name, args, );
+```
+
+#### Parameters
+| Name | Type |
+| --- | --- |
+| target_contract | AztecAddress |
+| selector | FunctionSelector |
+| name | str<N> |
+| args | [Field] |
+| | |
+
+### with_gas
+
+```rust
+with_gas(self, gas_opts);
+```
+
+#### Parameters
+| Name | Type |
+| --- | --- |
+| self | &mut Self |
+| gas_opts | GasOpts |
+
+### view
+
+```rust
+view(self, context);
+```
+
+#### Parameters
+| Name | Type |
+| --- | --- |
+| self | |
+| context | &mut PublicContext |
+
+### enqueue_view
+
+```rust
+enqueue_view(self, context);
+```
+
+#### Parameters
+| Name | Type |
+| --- | --- |
+| self | |
+| context | &mut PrivateContext |
+
+### get_args
+
+```rust
+get_args(self);
+```
+
+#### Parameters
+| Name | Type |
+| --- | --- |
+| self | |
+
+### get_selector
+
+```rust
+get_selector(self);
+```
+
+#### Parameters
+| Name | Type |
+| --- | --- |
+| self | |
+
+### get_name
+
+```rust
+get_name(self);
+```
+
+#### Parameters
+| Name | Type |
+| --- | --- |
+| self | |
+
+### get_contract_address
+
+```rust
+get_contract_address(self);
+```
+
+#### Parameters
+| Name | Type |
+| --- | --- |
+| self | |
+
+### get_is_static
+
+```rust
+get_is_static(self);
+```
+
+#### Parameters
+| Name | Type |
+| --- | --- |
+| self | |
+
diff --git a/docs/versioned_docs/version-v0.82.2-alpha-testnet.5/developers/reference/smart_contract_reference/aztec-nr/aztec/context/gas.md b/docs/versioned_docs/version-v0.82.2-alpha-testnet.5/developers/reference/smart_contract_reference/aztec-nr/aztec/context/gas.md
new file mode 100644
index 000000000000..cc183e086f42
--- /dev/null
+++ b/docs/versioned_docs/version-v0.82.2-alpha-testnet.5/developers/reference/smart_contract_reference/aztec-nr/aztec/context/gas.md
@@ -0,0 +1,30 @@
+# GasOpts
+
+## Fields
+| Field | Type |
+| --- | --- |
+| pub l2_gas | Option<Field> |
+| pub da_gas | Option<Field> |
+
+## Methods
+
+### default
+
+```rust
+GasOpts::default();
+```
+
+Takes no parameters.
+
+### new
+
+```rust
+GasOpts::new(l2_gas, da_gas);
+```
+
+#### Parameters
+| Name | Type |
+| --- | --- |
+| l2_gas | Field |
+| da_gas | Field |
+
diff --git a/docs/versioned_docs/version-v0.82.2-alpha-testnet.5/developers/reference/smart_contract_reference/aztec-nr/aztec/context/inputs/private_context_inputs.md b/docs/versioned_docs/version-v0.82.2-alpha-testnet.5/developers/reference/smart_contract_reference/aztec-nr/aztec/context/inputs/private_context_inputs.md
new file mode 100644
index 000000000000..b9c4f97350ad
--- /dev/null
+++ b/docs/versioned_docs/version-v0.82.2-alpha-testnet.5/developers/reference/smart_contract_reference/aztec-nr/aztec/context/inputs/private_context_inputs.md
@@ -0,0 +1,22 @@
+# PrivateContextInputs
+
+PrivateContextInputs are expected to be provided to each private function
+
+## Fields
+| Field | Type |
+| --- | --- |
+| pub call_context | CallContext |
+| pub historical_header | BlockHeader |
+| pub tx_context | TxContext |
+| pub start_side_effect_counter | u32 |
+
+## Standalone Functions
+
+### empty
+
+```rust
+empty();
+```
+
+Takes no parameters.
+
diff --git a/docs/versioned_docs/version-v0.82.2-alpha-testnet.5/developers/reference/smart_contract_reference/aztec-nr/aztec/context/private_context.md b/docs/versioned_docs/version-v0.82.2-alpha-testnet.5/developers/reference/smart_contract_reference/aztec-nr/aztec/context/private_context.md
new file mode 100644
index 000000000000..fc67b1569921
--- /dev/null
+++ b/docs/versioned_docs/version-v0.82.2-alpha-testnet.5/developers/reference/smart_contract_reference/aztec-nr/aztec/context/private_context.md
@@ -0,0 +1,554 @@
+# PrivateContext
+
+When finished, one can call .finish() to convert back to the abi
+
+## Fields
+| Field | Type |
+| --- | --- |
+| pub inputs | PrivateContextInputs |
+| pub side_effect_counter | u32 |
+| pub min_revertible_side_effect_counter | u32 |
+| pub is_fee_payer | bool |
+| pub args_hash | Field |
+| pub return_hash | Field |
+| pub max_block_number | MaxBlockNumber |
+| pub note_hash_read_requests | BoundedVec<ReadRequest, MAX_NOTE_HASH_READ_REQUESTS_PER_CALL> |
+| pub nullifier_read_requests | BoundedVec<ReadRequest, MAX_NULLIFIER_READ_REQUESTS_PER_CALL> |
+| key_validation_requests_and_generators | BoundedVec<KeyValidationRequestAndGenerator, MAX_KEY_VALIDATION_REQUESTS_PER_CALL> |
+| pub note_hashes | BoundedVec<NoteHash, MAX_NOTE_HASHES_PER_CALL> |
+| pub nullifiers | BoundedVec<Nullifier, MAX_NULLIFIERS_PER_CALL> |
+| pub private_call_requests | BoundedVec<PrivateCallRequest, MAX_PRIVATE_CALL_STACK_LENGTH_PER_CALL> |
+| pub public_call_requests | BoundedVec<Counted<PublicCallRequest>, MAX_ENQUEUED_CALLS_PER_CALL> |
+| pub public_teardown_call_request | PublicCallRequest |
+| pub l2_to_l1_msgs | BoundedVec<L2ToL1Message, MAX_L2_TO_L1_MSGS_PER_CALL> |
+| pub historical_header | BlockHeader |
+| pub private_logs | BoundedVec<PrivateLogData, MAX_PRIVATE_LOGS_PER_CALL> |
+| pub contract_class_logs_hashes | BoundedVec<LogHash, MAX_CONTRACT_CLASS_LOGS_PER_CALL> |
+| pub last_key_validation_requests | Option<KeyValidationRequest>; NUM_KEY_TYPES] |
+
+## Methods
+
+### new
+
+```rust
+PrivateContext::new(inputs, args_hash);
+```
+
+#### Parameters
+| Name | Type |
+| --- | --- |
+| inputs | PrivateContextInputs |
+| args_hash | Field |
+
+### msg_sender
+
+```rust
+PrivateContext::msg_sender(self);
+```
+
+#### Parameters
+| Name | Type |
+| --- | --- |
+| self | |
+
+### this_address
+
+```rust
+PrivateContext::this_address(self);
+```
+
+#### Parameters
+| Name | Type |
+| --- | --- |
+| self | |
+
+### chain_id
+
+```rust
+PrivateContext::chain_id(self);
+```
+
+#### Parameters
+| Name | Type |
+| --- | --- |
+| self | |
+
+### version
+
+```rust
+PrivateContext::version(self);
+```
+
+#### Parameters
+| Name | Type |
+| --- | --- |
+| self | |
+
+### gas_settings
+
+```rust
+PrivateContext::gas_settings(self);
+```
+
+#### Parameters
+| Name | Type |
+| --- | --- |
+| self | |
+
+### selector
+
+```rust
+PrivateContext::selector(self);
+```
+
+#### Parameters
+| Name | Type |
+| --- | --- |
+| self | |
+
+### get_args_hash
+
+```rust
+PrivateContext::get_args_hash(self);
+```
+
+#### Parameters
+| Name | Type |
+| --- | --- |
+| self | |
+
+### push_note_hash
+
+```rust
+PrivateContext::push_note_hash(&mut self, note_hash);
+```
+
+#### Parameters
+| Name | Type |
+| --- | --- |
+| &mut self | |
+| note_hash | Field |
+
+### push_nullifier
+
+```rust
+PrivateContext::push_nullifier(&mut self, nullifier);
+```
+
+#### Parameters
+| Name | Type |
+| --- | --- |
+| &mut self | |
+| nullifier | Field |
+
+### push_nullifier_for_note_hash
+
+```rust
+PrivateContext::push_nullifier_for_note_hash(&mut self, nullifier, nullified_note_hash);
+```
+
+#### Parameters
+| Name | Type |
+| --- | --- |
+| &mut self | |
+| nullifier | Field |
+| nullified_note_hash | Field |
+
+### get_block_header
+
+Returns the header of a block whose state is used during private execution (not the block the transaction is included in).
+
+```rust
+PrivateContext::get_block_header(self);
+```
+
+#### Parameters
+| Name | Type |
+| --- | --- |
+| self | |
+
+### get_block_header_at
+
+Returns the header of an arbitrary block whose block number is less than or equal to the block number of historical header.
+
+```rust
+PrivateContext::get_block_header_at(self, block_number);
+```
+
+#### Parameters
+| Name | Type |
+| --- | --- |
+| self | |
+| block_number | u32 |
+
+### set_return_hash
+
+```rust
+PrivateContext::set_return_hash(&mut self, returns_hasher);
+```
+
+#### Parameters
+| Name | Type |
+| --- | --- |
+| &mut self | |
+| returns_hasher | ArgsHasher |
+
+### finish
+
+```rust
+PrivateContext::finish(self);
+```
+
+#### Parameters
+| Name | Type |
+| --- | --- |
+| self | |
+
+### set_as_fee_payer
+
+```rust
+PrivateContext::set_as_fee_payer(&mut self);
+```
+
+#### Parameters
+| Name | Type |
+| --- | --- |
+| &mut self | |
+
+### end_setup
+
+```rust
+PrivateContext::end_setup(&mut self);
+```
+
+#### Parameters
+| Name | Type |
+| --- | --- |
+| &mut self | |
+
+### set_tx_max_block_number
+
+```rust
+PrivateContext::set_tx_max_block_number(&mut self, max_block_number);
+```
+
+#### Parameters
+| Name | Type |
+| --- | --- |
+| &mut self | |
+| max_block_number | u32 |
+
+### push_note_hash_read_request
+
+```rust
+PrivateContext::push_note_hash_read_request(&mut self, note_hash);
+```
+
+#### Parameters
+| Name | Type |
+| --- | --- |
+| &mut self | |
+| note_hash | Field |
+
+### push_nullifier_read_request
+
+```rust
+PrivateContext::push_nullifier_read_request(&mut self, nullifier);
+```
+
+#### Parameters
+| Name | Type |
+| --- | --- |
+| &mut self | |
+| nullifier | Field |
+
+### request_nsk_app
+
+```rust
+PrivateContext::request_nsk_app(&mut self, npk_m_hash);
+```
+
+#### Parameters
+| Name | Type |
+| --- | --- |
+| &mut self | |
+| npk_m_hash | Field |
+
+### request_ovsk_app
+
+```rust
+PrivateContext::request_ovsk_app(&mut self, ovpk_m_hash);
+```
+
+#### Parameters
+| Name | Type |
+| --- | --- |
+| &mut self | |
+| ovpk_m_hash | Field |
+
+### request_sk_app
+
+```rust
+PrivateContext::request_sk_app(&mut self, pk_m_hash, key_index);
+```
+
+#### Parameters
+| Name | Type |
+| --- | --- |
+| &mut self | |
+| pk_m_hash | Field |
+| key_index | Field |
+
+### message_portal
+
+```rust
+PrivateContext::message_portal(&mut self, recipient, content);
+```
+
+#### Parameters
+| Name | Type |
+| --- | --- |
+| &mut self | |
+| recipient | EthAddress |
+| content | Field |
+
+### consume_l1_to_l2_message
+
+```rust
+PrivateContext::consume_l1_to_l2_message(&mut self, content, secret, sender, leaf_index, );
+```
+
+#### Parameters
+| Name | Type |
+| --- | --- |
+| &mut self | |
+| content | Field |
+| secret | Field |
+| sender | EthAddress |
+| leaf_index | Field |
+| | |
+
+### emit_private_log
+
+```rust
+PrivateContext::emit_private_log(&mut self, log);
+```
+
+#### Parameters
+| Name | Type |
+| --- | --- |
+| &mut self | |
+| log | [Field; PRIVATE_LOG_SIZE_IN_FIELDS] |
+
+### emit_raw_note_log
+
+```rust
+PrivateContext::emit_raw_note_log(&mut self, log, note_hash_counter, );
+```
+
+#### Parameters
+| Name | Type |
+| --- | --- |
+| &mut self | |
+| log | [Field; PRIVATE_LOG_SIZE_IN_FIELDS] |
+| note_hash_counter | u32 |
+| | |
+
+### call_private_function
+
+```rust
+PrivateContext::call_private_function(&mut self, contract_address, function_selector, args, );
+```
+
+#### Parameters
+| Name | Type |
+| --- | --- |
+| &mut self | |
+| contract_address | AztecAddress |
+| function_selector | FunctionSelector |
+| args | [Field; ARGS_COUNT] |
+| | |
+
+### static_call_private_function
+
+```rust
+PrivateContext::static_call_private_function(&mut self, contract_address, function_selector, args, );
+```
+
+#### Parameters
+| Name | Type |
+| --- | --- |
+| &mut self | |
+| contract_address | AztecAddress |
+| function_selector | FunctionSelector |
+| args | [Field; ARGS_COUNT] |
+| | |
+
+### call_private_function_no_args
+
+```rust
+PrivateContext::call_private_function_no_args(&mut self, contract_address, function_selector, );
+```
+
+#### Parameters
+| Name | Type |
+| --- | --- |
+| &mut self | |
+| contract_address | AztecAddress |
+| function_selector | FunctionSelector |
+| | |
+
+### static_call_private_function_no_args
+
+```rust
+PrivateContext::static_call_private_function_no_args(&mut self, contract_address, function_selector, );
+```
+
+#### Parameters
+| Name | Type |
+| --- | --- |
+| &mut self | |
+| contract_address | AztecAddress |
+| function_selector | FunctionSelector |
+| | |
+
+### call_private_function_with_args_hash
+
+```rust
+PrivateContext::call_private_function_with_args_hash(&mut self, contract_address, function_selector, args_hash, is_static_call, );
+```
+
+#### Parameters
+| Name | Type |
+| --- | --- |
+| &mut self | |
+| contract_address | AztecAddress |
+| function_selector | FunctionSelector |
+| args_hash | Field |
+| is_static_call | bool |
+| | |
+
+### call_public_function
+
+```rust
+PrivateContext::call_public_function(&mut self, contract_address, function_selector, args, );
+```
+
+#### Parameters
+| Name | Type |
+| --- | --- |
+| &mut self | |
+| contract_address | AztecAddress |
+| function_selector | FunctionSelector |
+| args | [Field; ARGS_COUNT] |
+| | |
+
+### static_call_public_function
+
+```rust
+PrivateContext::static_call_public_function(&mut self, contract_address, function_selector, args, );
+```
+
+#### Parameters
+| Name | Type |
+| --- | --- |
+| &mut self | |
+| contract_address | AztecAddress |
+| function_selector | FunctionSelector |
+| args | [Field; ARGS_COUNT] |
+| | |
+
+### call_public_function_no_args
+
+```rust
+PrivateContext::call_public_function_no_args(&mut self, contract_address, function_selector, );
+```
+
+#### Parameters
+| Name | Type |
+| --- | --- |
+| &mut self | |
+| contract_address | AztecAddress |
+| function_selector | FunctionSelector |
+| | |
+
+### static_call_public_function_no_args
+
+```rust
+PrivateContext::static_call_public_function_no_args(&mut self, contract_address, function_selector, );
+```
+
+#### Parameters
+| Name | Type |
+| --- | --- |
+| &mut self | |
+| contract_address | AztecAddress |
+| function_selector | FunctionSelector |
+| | |
+
+### call_public_function_with_calldata_hash
+
+```rust
+PrivateContext::call_public_function_with_calldata_hash(&mut self, contract_address, calldata_hash, is_static_call, );
+```
+
+#### Parameters
+| Name | Type |
+| --- | --- |
+| &mut self | |
+| contract_address | AztecAddress |
+| calldata_hash | Field |
+| is_static_call | bool |
+| | |
+
+### set_public_teardown_function
+
+```rust
+PrivateContext::set_public_teardown_function(&mut self, contract_address, function_selector, args, );
+```
+
+#### Parameters
+| Name | Type |
+| --- | --- |
+| &mut self | |
+| contract_address | AztecAddress |
+| function_selector | FunctionSelector |
+| args | [Field; ARGS_COUNT] |
+| | |
+
+### set_public_teardown_function_with_calldata_hash
+
+```rust
+PrivateContext::set_public_teardown_function_with_calldata_hash(&mut self, contract_address, calldata_hash, is_static_call, );
+```
+
+#### Parameters
+| Name | Type |
+| --- | --- |
+| &mut self | |
+| contract_address | AztecAddress |
+| calldata_hash | Field |
+| is_static_call | bool |
+| | |
+
+### next_counter
+
+```rust
+PrivateContext::next_counter(&mut self);
+```
+
+#### Parameters
+| Name | Type |
+| --- | --- |
+| &mut self | |
+
+## Standalone Functions
+
+### empty
+
+```rust
+empty();
+```
+
+Takes no parameters.
+
diff --git a/docs/versioned_docs/version-v0.82.2-alpha-testnet.5/developers/reference/smart_contract_reference/aztec-nr/aztec/context/public_context.md b/docs/versioned_docs/version-v0.82.2-alpha-testnet.5/developers/reference/smart_contract_reference/aztec-nr/aztec/context/public_context.md
new file mode 100644
index 000000000000..e1704da2fb49
--- /dev/null
+++ b/docs/versioned_docs/version-v0.82.2-alpha-testnet.5/developers/reference/smart_contract_reference/aztec-nr/aztec/context/public_context.md
@@ -0,0 +1,818 @@
+# PublicContext
+
+## Fields
+| Field | Type |
+| --- | --- |
+| pub args_hash | Option<Field> |
+| pub compute_args_hash | fn() -> Field |
+
+## Methods
+
+### new
+
+```rust
+PublicContext::new(compute_args_hash);
+```
+
+#### Parameters
+| Name | Type |
+| --- | --- |
+| compute_args_hash | fn( |
+
+### emit_public_log
+
+```rust
+PublicContext::emit_public_log(_self, log);
+```
+
+#### Parameters
+| Name | Type |
+| --- | --- |
+| _self | &mut Self |
+| log | T |
+
+### note_hash_exists
+
+```rust
+PublicContext::note_hash_exists(_self, note_hash, leaf_index);
+```
+
+#### Parameters
+| Name | Type |
+| --- | --- |
+| _self | Self |
+| note_hash | Field |
+| leaf_index | Field |
+
+### l1_to_l2_msg_exists
+
+```rust
+PublicContext::l1_to_l2_msg_exists(_self, msg_hash, msg_leaf_index);
+```
+
+#### Parameters
+| Name | Type |
+| --- | --- |
+| _self | Self |
+| msg_hash | Field |
+| msg_leaf_index | Field |
+
+### nullifier_exists
+
+```rust
+PublicContext::nullifier_exists(_self, unsiloed_nullifier, address);
+```
+
+#### Parameters
+| Name | Type |
+| --- | --- |
+| _self | Self |
+| unsiloed_nullifier | Field |
+| address | AztecAddress |
+
+### consume_l1_to_l2_message
+
+```rust
+PublicContext::consume_l1_to_l2_message(&mut self, content, secret, sender, leaf_index, );
+```
+
+#### Parameters
+| Name | Type |
+| --- | --- |
+| &mut self | |
+| content | Field |
+| secret | Field |
+| sender | EthAddress |
+| leaf_index | Field |
+| | |
+
+### message_portal
+
+```rust
+PublicContext::message_portal(_self, recipient, content);
+```
+
+#### Parameters
+| Name | Type |
+| --- | --- |
+| _self | &mut Self |
+| recipient | EthAddress |
+| content | Field |
+
+### call_public_function
+
+```rust
+PublicContext::call_public_function(_self, contract_address, function_selector, args, gas_opts, );
+```
+
+#### Parameters
+| Name | Type |
+| --- | --- |
+| _self | &mut Self |
+| contract_address | AztecAddress |
+| function_selector | FunctionSelector |
+| args | [Field] |
+| gas_opts | GasOpts |
+| | |
+
+### static_call_public_function
+
+```rust
+PublicContext::static_call_public_function(_self, contract_address, function_selector, args, gas_opts, );
+```
+
+#### Parameters
+| Name | Type |
+| --- | --- |
+| _self | &mut Self |
+| contract_address | AztecAddress |
+| function_selector | FunctionSelector |
+| args | [Field] |
+| gas_opts | GasOpts |
+| | |
+
+### push_note_hash
+
+```rust
+PublicContext::push_note_hash(_self, note_hash);
+```
+
+#### Parameters
+| Name | Type |
+| --- | --- |
+| _self | &mut Self |
+| note_hash | Field |
+
+### push_nullifier
+
+```rust
+PublicContext::push_nullifier(_self, nullifier);
+```
+
+#### Parameters
+| Name | Type |
+| --- | --- |
+| _self | &mut Self |
+| nullifier | Field |
+
+### this_address
+
+```rust
+PublicContext::this_address(_self);
+```
+
+#### Parameters
+| Name | Type |
+| --- | --- |
+| _self | Self |
+
+### msg_sender
+
+```rust
+PublicContext::msg_sender(_self);
+```
+
+#### Parameters
+| Name | Type |
+| --- | --- |
+| _self | Self |
+
+### selector
+
+```rust
+PublicContext::selector(_self);
+```
+
+#### Parameters
+| Name | Type |
+| --- | --- |
+| _self | Self |
+
+### get_args_hash
+
+```rust
+PublicContext::get_args_hash(mut self);
+```
+
+#### Parameters
+| Name | Type |
+| --- | --- |
+| mut self | |
+
+### transaction_fee
+
+```rust
+PublicContext::transaction_fee(_self);
+```
+
+#### Parameters
+| Name | Type |
+| --- | --- |
+| _self | Self |
+
+### chain_id
+
+```rust
+PublicContext::chain_id(_self);
+```
+
+#### Parameters
+| Name | Type |
+| --- | --- |
+| _self | Self |
+
+### version
+
+```rust
+PublicContext::version(_self);
+```
+
+#### Parameters
+| Name | Type |
+| --- | --- |
+| _self | Self |
+
+### block_number
+
+```rust
+PublicContext::block_number(_self);
+```
+
+#### Parameters
+| Name | Type |
+| --- | --- |
+| _self | Self |
+
+### timestamp
+
+```rust
+PublicContext::timestamp(_self);
+```
+
+#### Parameters
+| Name | Type |
+| --- | --- |
+| _self | Self |
+
+### fee_per_l2_gas
+
+```rust
+PublicContext::fee_per_l2_gas(_self);
+```
+
+#### Parameters
+| Name | Type |
+| --- | --- |
+| _self | Self |
+
+### fee_per_da_gas
+
+```rust
+PublicContext::fee_per_da_gas(_self);
+```
+
+#### Parameters
+| Name | Type |
+| --- | --- |
+| _self | Self |
+
+### l2_gas_left
+
+```rust
+PublicContext::l2_gas_left(_self);
+```
+
+#### Parameters
+| Name | Type |
+| --- | --- |
+| _self | Self |
+
+### da_gas_left
+
+```rust
+PublicContext::da_gas_left(_self);
+```
+
+#### Parameters
+| Name | Type |
+| --- | --- |
+| _self | Self |
+
+### is_static_call
+
+```rust
+PublicContext::is_static_call(_self);
+```
+
+#### Parameters
+| Name | Type |
+| --- | --- |
+| _self | Self |
+
+### raw_storage_read
+
+```rust
+PublicContext::raw_storage_read(_self, storage_slot);
+```
+
+#### Parameters
+| Name | Type |
+| --- | --- |
+| _self | Self |
+| storage_slot | Field |
+
+### storage_read
+
+```rust
+PublicContext::storage_read(self, storage_slot);
+```
+
+#### Parameters
+| Name | Type |
+| --- | --- |
+| self | |
+| storage_slot | Field |
+
+### raw_storage_write
+
+```rust
+PublicContext::raw_storage_write(_self, storage_slot, values);
+```
+
+#### Parameters
+| Name | Type |
+| --- | --- |
+| _self | Self |
+| storage_slot | Field |
+| values | [Field; N] |
+
+### storage_write
+
+```rust
+PublicContext::storage_write(self, storage_slot, value);
+```
+
+#### Parameters
+| Name | Type |
+| --- | --- |
+| self | |
+| storage_slot | Field |
+| value | T |
+
+## Standalone Functions
+
+### gas_for_call
+
+```rust
+gas_for_call(user_gas);
+```
+
+Helper functions
+
+#### Parameters
+| Name | Type |
+| --- | --- |
+| user_gas | GasOpts |
+
+### address
+
+```rust
+address();
+```
+
+Takes no parameters.
+
+### sender
+
+```rust
+sender();
+```
+
+Takes no parameters.
+
+### emit_note_hash
+
+```rust
+emit_note_hash(note_hash);
+```
+
+#### Parameters
+| Name | Type |
+| --- | --- |
+| note_hash | Field |
+
+### emit_nullifier
+
+```rust
+emit_nullifier(nullifier);
+```
+
+#### Parameters
+| Name | Type |
+| --- | --- |
+| nullifier | Field |
+
+### send_l2_to_l1_msg
+
+```rust
+send_l2_to_l1_msg(recipient, content);
+```
+
+#### Parameters
+| Name | Type |
+| --- | --- |
+| recipient | EthAddress |
+| content | Field |
+
+### call
+
+```rust
+call(gas, address, args);
+```
+
+#### Parameters
+| Name | Type |
+| --- | --- |
+| gas | [Field; 2] |
+| address | AztecAddress |
+| args | [Field] |
+
+### call_static
+
+```rust
+call_static(gas, address, args);
+```
+
+#### Parameters
+| Name | Type |
+| --- | --- |
+| gas | [Field; 2] |
+| address | AztecAddress |
+| args | [Field] |
+
+### calldata_copy
+
+```rust
+calldata_copy(cdoffset, copy_size);
+```
+
+#### Parameters
+| Name | Type |
+| --- | --- |
+| cdoffset | u32 |
+| copy_size | u32 |
+
+### success_copy
+
+```rust
+success_copy();
+```
+
+Takes no parameters.
+
+### returndata_size
+
+```rust
+returndata_size();
+```
+
+Takes no parameters.
+
+### returndata_copy
+
+```rust
+returndata_copy(rdoffset, copy_size);
+```
+
+#### Parameters
+| Name | Type |
+| --- | --- |
+| rdoffset | u32 |
+| copy_size | u32 |
+
+### avm_return
+
+```rust
+avm_return(returndata);
+```
+
+#### Parameters
+| Name | Type |
+| --- | --- |
+| returndata | [Field] |
+
+### avm_revert
+
+```rust
+avm_revert(revertdata);
+```
+
+#### Parameters
+| Name | Type |
+| --- | --- |
+| revertdata | [Field] |
+
+### empty
+
+```rust
+empty();
+```
+
+Takes no parameters.
+
+### address_opcode
+
+```rust
+address_opcode();
+```
+
+Takes no parameters.
+
+### sender_opcode
+
+```rust
+sender_opcode();
+```
+
+Takes no parameters.
+
+### transaction_fee_opcode
+
+```rust
+transaction_fee_opcode();
+```
+
+Takes no parameters.
+
+### chain_id_opcode
+
+```rust
+chain_id_opcode();
+```
+
+Takes no parameters.
+
+### version_opcode
+
+```rust
+version_opcode();
+```
+
+Takes no parameters.
+
+### block_number_opcode
+
+```rust
+block_number_opcode();
+```
+
+Takes no parameters.
+
+### timestamp_opcode
+
+```rust
+timestamp_opcode();
+```
+
+Takes no parameters.
+
+### fee_per_l2_gas_opcode
+
+```rust
+fee_per_l2_gas_opcode();
+```
+
+Takes no parameters.
+
+### fee_per_da_gas_opcode
+
+```rust
+fee_per_da_gas_opcode();
+```
+
+Takes no parameters.
+
+### l2_gas_left_opcode
+
+```rust
+l2_gas_left_opcode();
+```
+
+Takes no parameters.
+
+### da_gas_left_opcode
+
+```rust
+da_gas_left_opcode();
+```
+
+Takes no parameters.
+
+### is_static_call_opcode
+
+```rust
+is_static_call_opcode();
+```
+
+Takes no parameters.
+
+### note_hash_exists_opcode
+
+```rust
+note_hash_exists_opcode(note_hash, leaf_index);
+```
+
+#### Parameters
+| Name | Type |
+| --- | --- |
+| note_hash | Field |
+| leaf_index | Field |
+
+### emit_note_hash_opcode
+
+```rust
+emit_note_hash_opcode(note_hash);
+```
+
+#### Parameters
+| Name | Type |
+| --- | --- |
+| note_hash | Field |
+
+### nullifier_exists_opcode
+
+```rust
+nullifier_exists_opcode(nullifier, address);
+```
+
+#### Parameters
+| Name | Type |
+| --- | --- |
+| nullifier | Field |
+| address | Field |
+
+### emit_nullifier_opcode
+
+```rust
+emit_nullifier_opcode(nullifier);
+```
+
+#### Parameters
+| Name | Type |
+| --- | --- |
+| nullifier | Field |
+
+### emit_public_log_opcode
+
+```rust
+emit_public_log_opcode(message);
+```
+
+#### Parameters
+| Name | Type |
+| --- | --- |
+| message | [Field] |
+
+### l1_to_l2_msg_exists_opcode
+
+```rust
+l1_to_l2_msg_exists_opcode(msg_hash, msg_leaf_index);
+```
+
+#### Parameters
+| Name | Type |
+| --- | --- |
+| msg_hash | Field |
+| msg_leaf_index | Field |
+
+### send_l2_to_l1_msg_opcode
+
+```rust
+send_l2_to_l1_msg_opcode(recipient, content);
+```
+
+#### Parameters
+| Name | Type |
+| --- | --- |
+| recipient | EthAddress |
+| content | Field |
+
+### calldata_copy_opcode
+
+```rust
+calldata_copy_opcode(cdoffset, copy_size);
+```
+
+#### Parameters
+| Name | Type |
+| --- | --- |
+| cdoffset | u32 |
+| copy_size | u32 |
+
+### returndata_size_opcode
+
+```rust
+returndata_size_opcode();
+```
+
+Takes no parameters.
+
+### returndata_copy_opcode
+
+```rust
+returndata_copy_opcode(rdoffset, copy_size);
+```
+
+#### Parameters
+| Name | Type |
+| --- | --- |
+| rdoffset | u32 |
+| copy_size | u32 |
+
+### return_opcode
+
+```rust
+return_opcode(returndata);
+```
+
+#### Parameters
+| Name | Type |
+| --- | --- |
+| returndata | [Field] |
+
+### revert_opcode
+
+```rust
+revert_opcode(revertdata);
+```
+
+#### Parameters
+| Name | Type |
+| --- | --- |
+| revertdata | [Field] |
+
+### call_opcode
+
+```rust
+call_opcode(gas, // gas allocation, da_gas]
+ address, args, );
+```
+
+#### Parameters
+| Name | Type |
+| --- | --- |
+| gas | [Field; 2] |
+| // gas allocation | [l2_gas |
+| da_gas]
+ address | AztecAddress |
+| args | [Field] |
+| | |
+
+### call_static_opcode
+
+```rust
+call_static_opcode(gas, // gas allocation, da_gas]
+ address, args, );
+```
+
+#### Parameters
+| Name | Type |
+| --- | --- |
+| gas | [Field; 2] |
+| // gas allocation | [l2_gas |
+| da_gas]
+ address | AztecAddress |
+| args | [Field] |
+| | |
+
+### success_copy_opcode
+
+```rust
+success_copy_opcode();
+```
+
+Takes no parameters.
+
+### storage_read_opcode
+
+```rust
+storage_read_opcode(storage_slot);
+```
+
+#### Parameters
+| Name | Type |
+| --- | --- |
+| storage_slot | Field |
+
+### storage_write_opcode
+
+```rust
+storage_write_opcode(storage_slot, value);
+```
+
+#### Parameters
+| Name | Type |
+| --- | --- |
+| storage_slot | Field |
+| value | Field |
+
diff --git a/docs/versioned_docs/version-v0.82.2-alpha-testnet.5/developers/reference/smart_contract_reference/aztec-nr/aztec/context/returns_hash.md b/docs/versioned_docs/version-v0.82.2-alpha-testnet.5/developers/reference/smart_contract_reference/aztec-nr/aztec/context/returns_hash.md
new file mode 100644
index 000000000000..e63203400cc9
--- /dev/null
+++ b/docs/versioned_docs/version-v0.82.2-alpha-testnet.5/developers/reference/smart_contract_reference/aztec-nr/aztec/context/returns_hash.md
@@ -0,0 +1,55 @@
+# ReturnsHash
+
+## Fields
+| Field | Type |
+| --- | --- |
+| hash | Field |
+
+## Methods
+
+### new
+
+```rust
+ReturnsHash::new(hash);
+```
+
+#### Parameters
+| Name | Type |
+| --- | --- |
+| hash | Field |
+
+### assert_empty
+
+```rust
+ReturnsHash::assert_empty(self);
+```
+
+#### Parameters
+| Name | Type |
+| --- | --- |
+| self | |
+
+### raw
+
+```rust
+ReturnsHash::raw(self);
+```
+
+#### Parameters
+| Name | Type |
+| --- | --- |
+| self | |
+
+### get_preimage
+
+/ This is only used during private execution, since in public it is the VM itself that keeps track of return / values.
+
+```rust
+ReturnsHash::get_preimage(self);
+```
+
+#### Parameters
+| Name | Type |
+| --- | --- |
+| self | |
+
diff --git a/docs/versioned_docs/version-v0.82.2-alpha-testnet.5/developers/reference/smart_contract_reference/aztec-nr/aztec/context/unconstrained_context.md b/docs/versioned_docs/version-v0.82.2-alpha-testnet.5/developers/reference/smart_contract_reference/aztec-nr/aztec/context/unconstrained_context.md
new file mode 100644
index 000000000000..76606c164b35
--- /dev/null
+++ b/docs/versioned_docs/version-v0.82.2-alpha-testnet.5/developers/reference/smart_contract_reference/aztec-nr/aztec/context/unconstrained_context.md
@@ -0,0 +1,112 @@
+# UnconstrainedContext
+
+## Fields
+| Field | Type |
+| --- | --- |
+| block_number | u32 |
+| contract_address | AztecAddress |
+| version | Field |
+| chain_id | Field |
+
+## Methods
+
+### new
+
+```rust
+UnconstrainedContext::new();
+```
+
+Takes no parameters.
+
+### at
+
+```rust
+UnconstrainedContext::at(contract_address);
+```
+
+#### Parameters
+| Name | Type |
+| --- | --- |
+| contract_address | AztecAddress |
+
+### at_historical
+
+```rust
+UnconstrainedContext::at_historical(contract_address, block_number);
+```
+
+#### Parameters
+| Name | Type |
+| --- | --- |
+| contract_address | AztecAddress |
+| block_number | u32 |
+
+### block_number
+
+```rust
+UnconstrainedContext::block_number(self);
+```
+
+#### Parameters
+| Name | Type |
+| --- | --- |
+| self | |
+
+### this_address
+
+```rust
+UnconstrainedContext::this_address(self);
+```
+
+#### Parameters
+| Name | Type |
+| --- | --- |
+| self | |
+
+### version
+
+```rust
+UnconstrainedContext::version(self);
+```
+
+#### Parameters
+| Name | Type |
+| --- | --- |
+| self | |
+
+### chain_id
+
+```rust
+UnconstrainedContext::chain_id(self);
+```
+
+#### Parameters
+| Name | Type |
+| --- | --- |
+| self | |
+
+### raw_storage_read
+
+```rust
+UnconstrainedContext::raw_storage_read(self, storage_slot, );
+```
+
+#### Parameters
+| Name | Type |
+| --- | --- |
+| self | Self |
+| storage_slot | Field |
+| | |
+
+### storage_read
+
+```rust
+UnconstrainedContext::storage_read(self, storage_slot);
+```
+
+#### Parameters
+| Name | Type |
+| --- | --- |
+| self | |
+| storage_slot | Field |
+
diff --git a/docs/versioned_docs/version-v0.82.2-alpha-testnet.5/developers/reference/smart_contract_reference/aztec-nr/aztec/deploy.md b/docs/versioned_docs/version-v0.82.2-alpha-testnet.5/developers/reference/smart_contract_reference/aztec-nr/aztec/deploy.md
new file mode 100644
index 000000000000..b250ece82dd1
--- /dev/null
+++ b/docs/versioned_docs/version-v0.82.2-alpha-testnet.5/developers/reference/smart_contract_reference/aztec-nr/aztec/deploy.md
@@ -0,0 +1,16 @@
+## Standalone Functions
+
+### deploy_contract
+
+```rust
+deploy_contract(context, target);
+```
+
+Calls `deploy` on the deployer contract to deploy a new instance.
+
+#### Parameters
+| Name | Type |
+| --- | --- |
+| context | &mut PrivateContext |
+| target | AztecAddress |
+
diff --git a/docs/versioned_docs/version-v0.82.2-alpha-testnet.5/developers/reference/smart_contract_reference/aztec-nr/aztec/discovery/mod.md b/docs/versioned_docs/version-v0.82.2-alpha-testnet.5/developers/reference/smart_contract_reference/aztec-nr/aztec/discovery/mod.md
new file mode 100644
index 000000000000..44476bc58c20
--- /dev/null
+++ b/docs/versioned_docs/version-v0.82.2-alpha-testnet.5/developers/reference/smart_contract_reference/aztec-nr/aztec/discovery/mod.md
@@ -0,0 +1,23 @@
+# NoteHashAndNullifier
+
+## Fields
+| Field | Type |
+| --- | --- |
+| pub note_hash | Field |
+| pub inner_nullifier | Field |
+
+## Standalone Functions
+
+### discover_new_messages
+
+```rust
+discover_new_messages(contract_address, compute_note_hash_and_nullifier, );
+```
+
+#### Parameters
+| Name | Type |
+| --- | --- |
+| contract_address | AztecAddress |
+| compute_note_hash_and_nullifier | ComputeNoteHashAndNullifier<Env> |
+| | |
+
diff --git a/docs/versioned_docs/version-v0.82.2-alpha-testnet.5/developers/reference/smart_contract_reference/aztec-nr/aztec/discovery/nonce_discovery.md b/docs/versioned_docs/version-v0.82.2-alpha-testnet.5/developers/reference/smart_contract_reference/aztec-nr/aztec/discovery/nonce_discovery.md
new file mode 100644
index 000000000000..953255258568
--- /dev/null
+++ b/docs/versioned_docs/version-v0.82.2-alpha-testnet.5/developers/reference/smart_contract_reference/aztec-nr/aztec/discovery/nonce_discovery.md
@@ -0,0 +1,33 @@
+# DiscoveredNoteInfo
+
+/ A struct with the discovered information of a complete note, required for delivery to PXE. Note that this is *not* / the complete note information, since it does not include content, storage slot, etc.
+
+## Fields
+| Field | Type |
+| --- | --- |
+| pub nonce | Field |
+| pub note_hash | Field |
+| pub inner_nullifier | Field |
+
+## Standalone Functions
+
+### attempt_note_nonce_discovery
+
+```rust
+attempt_note_nonce_discovery(unique_note_hashes_in_tx, MAX_NOTE_HASHES_PER_TX>, first_nullifier_in_tx, compute_note_hash_and_nullifier, contract_address, storage_slot, note_type_id, packed_note, MAX_NOTE_PACKED_LEN>, );
+```
+
+#### Parameters
+| Name | Type |
+| --- | --- |
+| unique_note_hashes_in_tx | BoundedVec<Field |
+| MAX_NOTE_HASHES_PER_TX> | |
+| first_nullifier_in_tx | Field |
+| compute_note_hash_and_nullifier | ComputeNoteHashAndNullifier<Env> |
+| contract_address | AztecAddress |
+| storage_slot | Field |
+| note_type_id | Field |
+| packed_note | BoundedVec<Field |
+| MAX_NOTE_PACKED_LEN> | |
+| | |
+
diff --git a/docs/versioned_docs/version-v0.82.2-alpha-testnet.5/developers/reference/smart_contract_reference/aztec-nr/aztec/discovery/partial_notes.md b/docs/versioned_docs/version-v0.82.2-alpha-testnet.5/developers/reference/smart_contract_reference/aztec-nr/aztec/discovery/partial_notes.md
new file mode 100644
index 000000000000..6d4f177f87d0
--- /dev/null
+++ b/docs/versioned_docs/version-v0.82.2-alpha-testnet.5/developers/reference/smart_contract_reference/aztec-nr/aztec/discovery/partial_notes.md
@@ -0,0 +1,56 @@
+# DeliveredPendingPartialNote
+
+## Fields
+| Field | Type |
+| --- | --- |
+| pub(crate) note_completion_log_tag | Field |
+| pub(crate) storage_slot | Field |
+| pub(crate) note_type_id | Field |
+| pub(crate) packed_private_note_content | BoundedVec<Field, MAX_PARTIAL_NOTE_PRIVATE_PACKED_LEN> |
+| pub(crate) recipient | AztecAddress |
+
+## Standalone Functions
+
+### process_partial_note_private_log
+
+```rust
+process_partial_note_private_log(contract_address, recipient, log_metadata, log_content, MAX_LOG_CONTENT_LEN>, );
+```
+
+#### Parameters
+| Name | Type |
+| --- | --- |
+| contract_address | AztecAddress |
+| recipient | AztecAddress |
+| log_metadata | u64 |
+| log_content | BoundedVec<Field |
+| MAX_LOG_CONTENT_LEN> | |
+| | |
+
+### fetch_and_process_public_partial_note_completion_logs
+
+```rust
+fetch_and_process_public_partial_note_completion_logs(contract_address, compute_note_hash_and_nullifier, );
+```
+
+#### Parameters
+| Name | Type |
+| --- | --- |
+| contract_address | AztecAddress |
+| compute_note_hash_and_nullifier | ComputeNoteHashAndNullifier<Env> |
+| | |
+
+### decode_partial_note_private_log
+
+```rust
+decode_partial_note_private_log(log_metadata, log_content, MAX_LOG_CONTENT_LEN>, );
+```
+
+#### Parameters
+| Name | Type |
+| --- | --- |
+| log_metadata | u64 |
+| log_content | BoundedVec<Field |
+| MAX_LOG_CONTENT_LEN> | |
+| | |
+
diff --git a/docs/versioned_docs/version-v0.82.2-alpha-testnet.5/developers/reference/smart_contract_reference/aztec-nr/aztec/discovery/private_logs.md b/docs/versioned_docs/version-v0.82.2-alpha-testnet.5/developers/reference/smart_contract_reference/aztec-nr/aztec/discovery/private_logs.md
new file mode 100644
index 000000000000..3ccf6c5bb033
--- /dev/null
+++ b/docs/versioned_docs/version-v0.82.2-alpha-testnet.5/developers/reference/smart_contract_reference/aztec-nr/aztec/discovery/private_logs.md
@@ -0,0 +1,48 @@
+## Standalone Functions
+
+### fetch_and_process_private_tagged_logs
+
+```rust
+fetch_and_process_private_tagged_logs(_contract_address, _compute_note_hash_and_nullifier, );
+```
+
+#### Parameters
+| Name | Type |
+| --- | --- |
+| _contract_address | AztecAddress |
+| _compute_note_hash_and_nullifier | ComputeNoteHashAndNullifier<Env> |
+| | |
+
+### do_process_log
+
+```rust
+do_process_log(contract_address, log, PRIVATE_LOG_SIZE_IN_FIELDS>, tx_hash, unique_note_hashes_in_tx, MAX_NOTE_HASHES_PER_TX>, first_nullifier_in_tx, recipient, compute_note_hash_and_nullifier, );
+```
+
+#### Parameters
+| Name | Type |
+| --- | --- |
+| contract_address | AztecAddress |
+| log | BoundedVec<Field |
+| PRIVATE_LOG_SIZE_IN_FIELDS> | |
+| tx_hash | Field |
+| unique_note_hashes_in_tx | BoundedVec<Field |
+| MAX_NOTE_HASHES_PER_TX> | |
+| first_nullifier_in_tx | Field |
+| recipient | AztecAddress |
+| compute_note_hash_and_nullifier | ComputeNoteHashAndNullifier<Env> |
+| | |
+
+### decode_log_plaintext
+
+```rust
+decode_log_plaintext(log_plaintext, PRIVATE_LOG_PLAINTEXT_SIZE_IN_FIELDS>, );
+```
+
+#### Parameters
+| Name | Type |
+| --- | --- |
+| log_plaintext | BoundedVec<Field |
+| PRIVATE_LOG_PLAINTEXT_SIZE_IN_FIELDS> | |
+| | |
+
diff --git a/docs/versioned_docs/version-v0.82.2-alpha-testnet.5/developers/reference/smart_contract_reference/aztec-nr/aztec/discovery/private_notes.md b/docs/versioned_docs/version-v0.82.2-alpha-testnet.5/developers/reference/smart_contract_reference/aztec-nr/aztec/discovery/private_notes.md
new file mode 100644
index 000000000000..f39fae67cd73
--- /dev/null
+++ b/docs/versioned_docs/version-v0.82.2-alpha-testnet.5/developers/reference/smart_contract_reference/aztec-nr/aztec/discovery/private_notes.md
@@ -0,0 +1,59 @@
+## Standalone Functions
+
+### process_private_note_log
+
+```rust
+process_private_note_log(contract_address, tx_hash, unique_note_hashes_in_tx, MAX_NOTE_HASHES_PER_TX>, first_nullifier_in_tx, recipient, compute_note_hash_and_nullifier, log_metadata, log_content, MAX_LOG_CONTENT_LEN>, );
+```
+
+#### Parameters
+| Name | Type |
+| --- | --- |
+| contract_address | AztecAddress |
+| tx_hash | Field |
+| unique_note_hashes_in_tx | BoundedVec<Field |
+| MAX_NOTE_HASHES_PER_TX> | |
+| first_nullifier_in_tx | Field |
+| recipient | AztecAddress |
+| compute_note_hash_and_nullifier | ComputeNoteHashAndNullifier<Env> |
+| log_metadata | u64 |
+| log_content | BoundedVec<Field |
+| MAX_LOG_CONTENT_LEN> | |
+| | |
+
+### attempt_note_discovery
+
+```rust
+attempt_note_discovery(contract_address, tx_hash, unique_note_hashes_in_tx, MAX_NOTE_HASHES_PER_TX>, first_nullifier_in_tx, recipient, compute_note_hash_and_nullifier, storage_slot, note_type_id, packed_note, MAX_NOTE_PACKED_LEN>, );
+```
+
+#### Parameters
+| Name | Type |
+| --- | --- |
+| contract_address | AztecAddress |
+| tx_hash | Field |
+| unique_note_hashes_in_tx | BoundedVec<Field |
+| MAX_NOTE_HASHES_PER_TX> | |
+| first_nullifier_in_tx | Field |
+| recipient | AztecAddress |
+| compute_note_hash_and_nullifier | ComputeNoteHashAndNullifier<Env> |
+| storage_slot | Field |
+| note_type_id | Field |
+| packed_note | BoundedVec<Field |
+| MAX_NOTE_PACKED_LEN> | |
+| | |
+
+### decode_private_note_log
+
+```rust
+decode_private_note_log(log_metadata, log_content, MAX_LOG_CONTENT_LEN>, );
+```
+
+#### Parameters
+| Name | Type |
+| --- | --- |
+| log_metadata | u64 |
+| log_content | BoundedVec<Field |
+| MAX_LOG_CONTENT_LEN> | |
+| | |
+
diff --git a/docs/versioned_docs/version-v0.82.2-alpha-testnet.5/developers/reference/smart_contract_reference/aztec-nr/aztec/encrypted_logs/encrypt/aes128.md b/docs/versioned_docs/version-v0.82.2-alpha-testnet.5/developers/reference/smart_contract_reference/aztec-nr/aztec/encrypted_logs/encrypt/aes128.md
new file mode 100644
index 000000000000..83d8b610e717
--- /dev/null
+++ b/docs/versioned_docs/version-v0.82.2-alpha-testnet.5/developers/reference/smart_contract_reference/aztec-nr/aztec/encrypted_logs/encrypt/aes128.md
@@ -0,0 +1,68 @@
+## Standalone Functions
+
+### extract_close_to_uniformly_random_256_bits_from_ecdh_shared_secret_using_poseidon2
+
+```rust
+extract_close_to_uniformly_random_256_bits_from_ecdh_shared_secret_using_poseidon2(shared_secret, );
+```
+
+#### Parameters
+| Name | Type |
+| --- | --- |
+| shared_secret | Point |
+| | |
+
+### extract_close_to_uniformly_random_256_bits_from_ecdh_shared_secret_using_sha256
+
+```rust
+extract_close_to_uniformly_random_256_bits_from_ecdh_shared_secret_using_sha256(shared_secret, );
+```
+
+TODO(#10537): Consider nuking this function.
+
+#### Parameters
+| Name | Type |
+| --- | --- |
+| shared_secret | Point |
+| | |
+
+### derive_aes_symmetric_key_and_iv_from_ecdh_shared_secret
+
+```rust
+derive_aes_symmetric_key_and_iv_from_ecdh_shared_secret(shared_secret, randomness_extraction_fn);
+```
+
+#### Parameters
+| Name | Type |
+| --- | --- |
+| shared_secret | Point |
+| randomness_extraction_fn | fn(Point |
+
+### derive_aes_symmetric_key_and_iv_from_ecdh_shared_secret_using_sha256
+
+```rust
+derive_aes_symmetric_key_and_iv_from_ecdh_shared_secret_using_sha256(shared_secret, );
+```
+
+TODO(#10537): Consider nuking this function.
+
+#### Parameters
+| Name | Type |
+| --- | --- |
+| shared_secret | Point |
+| | |
+
+### derive_aes_symmetric_key_and_iv_from_ecdh_shared_secret_using_poseidon2
+
+```rust
+derive_aes_symmetric_key_and_iv_from_ecdh_shared_secret_using_poseidon2(shared_secret, );
+```
+
+TODO(#10537): This function is currently unused. Consider using it instead of the sha256 one.
+
+#### Parameters
+| Name | Type |
+| --- | --- |
+| shared_secret | Point |
+| | |
+
diff --git a/docs/versioned_docs/version-v0.82.2-alpha-testnet.5/developers/reference/smart_contract_reference/aztec-nr/aztec/encrypted_logs/encrypt/poseidon2.md b/docs/versioned_docs/version-v0.82.2-alpha-testnet.5/developers/reference/smart_contract_reference/aztec-nr/aztec/encrypted_logs/encrypt/poseidon2.md
new file mode 100644
index 000000000000..94a18d6cf067
--- /dev/null
+++ b/docs/versioned_docs/version-v0.82.2-alpha-testnet.5/developers/reference/smart_contract_reference/aztec-nr/aztec/encrypted_logs/encrypt/poseidon2.md
@@ -0,0 +1,87 @@
+## Standalone Functions
+
+### poseidon2_encrypt
+
+```rust
+poseidon2_encrypt(msg, shared_secret, nonce, );
+```
+
+/// @param nonce is only needed if your use case needs to protect against replay attacks.
+
+#### Parameters
+| Name | Type |
+| --- | --- |
+| msg | [Field; L] |
+| shared_secret | Point |
+| nonce | Field |
+| | |
+
+### poseidon2_decrypt
+
+```rust
+poseidon2_decrypt(ciphertext);
+```
+
+#### Parameters
+| Name | Type |
+| --- | --- |
+| ciphertext | [Field; ((L + 3 - 1 |
+
+### encrypt_then_decrypt
+
+```rust
+encrypt_then_decrypt(msg);
+```
+
+Helper function that allows us to test encryption, then decryption, for various sizes of message.
+
+#### Parameters
+| Name | Type |
+| --- | --- |
+| msg | [Field; N] |
+
+### poseidon2_encryption
+
+```rust
+poseidon2_encryption();
+```
+
+Takes no parameters.
+
+### test_poseidon2_decryption_with_bad_secret_fails
+
+```rust
+test_poseidon2_decryption_with_bad_secret_fails();
+```
+
+Takes no parameters.
+
+### encrypt_and_return_ct_length
+
+```rust
+encrypt_and_return_ct_length(msg);
+```
+
+Helper function with encryption boilerplate
+
+#### Parameters
+| Name | Type |
+| --- | --- |
+| msg | [Field; N] |
+
+### test_ciphertext_lengths
+
+```rust
+test_ciphertext_lengths();
+```
+
+Takes no parameters.
+
+### test_2_pow_128
+
+```rust
+test_2_pow_128();
+```
+
+Takes no parameters.
+
diff --git a/docs/versioned_docs/version-v0.82.2-alpha-testnet.5/developers/reference/smart_contract_reference/aztec-nr/aztec/encrypted_logs/log_assembly_strategies/default_aes128/arithmetic_generics_utils.md b/docs/versioned_docs/version-v0.82.2-alpha-testnet.5/developers/reference/smart_contract_reference/aztec-nr/aztec/encrypted_logs/log_assembly_strategies/default_aes128/arithmetic_generics_utils.md
new file mode 100644
index 000000000000..90cd3f129c6d
--- /dev/null
+++ b/docs/versioned_docs/version-v0.82.2-alpha-testnet.5/developers/reference/smart_contract_reference/aztec-nr/aztec/encrypted_logs/log_assembly_strategies/default_aes128/arithmetic_generics_utils.md
@@ -0,0 +1,99 @@
+## Standalone Functions
+
+### get_arr_of_size__full_plaintext
+
+```rust
+get_arr_of_size__full_plaintext();
+```
+
+|full_pt| = |pt| = (N * 32) + 64
+
+Takes no parameters.
+
+### get_arr_of_size__plaintext_aes_padding
+
+```rust
+get_arr_of_size__plaintext_aes_padding(_full_pt, );
+```
+
+|pt_aes_padding| = 16 - (|full_pt| % 16)
+
+#### Parameters
+| Name | Type |
+| --- | --- |
+| _full_pt | [u8; FULL_PT] |
+| | |
+
+### get_arr_of_size__ciphertext
+
+```rust
+get_arr_of_size__ciphertext(_full_pt, _pt_aes_padding, );
+```
+
+|ct| = |full_pt| + |pt_aes_padding|
+
+#### Parameters
+| Name | Type |
+| --- | --- |
+| _full_pt | [u8; FULL_PT] |
+| _pt_aes_padding | [u8; PT_AES_PADDING] |
+| | |
+
+### get_arr_of_size__log_bytes_without_padding
+
+```rust
+get_arr_of_size__log_bytes_without_padding(_ct);
+```
+
+Let lbwop = 1 + 48 + |ct| // aka log bytes without padding
+
+#### Parameters
+| Name | Type |
+| --- | --- |
+| _ct | [u8; CT] |
+
+### get_arr_of_size__log_bytes_padding
+
+```rust
+get_arr_of_size__log_bytes_padding(_lbwop, );
+```
+
+(because ceil(x / y) = (x + y - 1) // y ).
+
+#### Parameters
+| Name | Type |
+| --- | --- |
+| _lbwop | [u8; LBWOP] |
+| | |
+
+### get_arr_of_size__log_bytes
+
+```rust
+get_arr_of_size__log_bytes(_lbwop, _p, );
+```
+
+p is the padding
+
+#### Parameters
+| Name | Type |
+| --- | --- |
+| _lbwop | [u8; LBWOP] |
+| _p | [u8; P] |
+| | |
+
+### get_arr_of_size__log_bytes_padding__from_PT
+
+```rust
+get_arr_of_size__log_bytes_padding__from_PT();
+```
+
+Takes no parameters.
+
+### get_arr_of_size__log_bytes__from_PT
+
+```rust
+get_arr_of_size__log_bytes__from_PT();
+```
+
+Takes no parameters.
+
diff --git a/docs/versioned_docs/version-v0.82.2-alpha-testnet.5/developers/reference/smart_contract_reference/aztec-nr/aztec/encrypted_logs/log_assembly_strategies/default_aes128/event.md b/docs/versioned_docs/version-v0.82.2-alpha-testnet.5/developers/reference/smart_contract_reference/aztec-nr/aztec/encrypted_logs/log_assembly_strategies/default_aes128/event.md
new file mode 100644
index 000000000000..b1ce72d59ebc
--- /dev/null
+++ b/docs/versioned_docs/version-v0.82.2-alpha-testnet.5/developers/reference/smart_contract_reference/aztec-nr/aztec/encrypted_logs/log_assembly_strategies/default_aes128/event.md
@@ -0,0 +1,79 @@
+## Standalone Functions
+
+### compute_event_plaintext_for_this_strategy
+
+```rust
+compute_event_plaintext_for_this_strategy(event);
+```
+
+/ NB: The extra `+ 1` is for the event_type_id:
+
+#### Parameters
+| Name | Type |
+| --- | --- |
+| event | Event |
+
+### compute_log
+
+```rust
+compute_log(context, event, recipient, sender, );
+```
+
+we perform some note-specific log length assertions.
+
+#### Parameters
+| Name | Type |
+| --- | --- |
+| context | PrivateContext |
+| event | Event |
+| recipient | AztecAddress |
+| sender | AztecAddress |
+| | |
+
+### compute_log_unconstrained
+
+```rust
+compute_log_unconstrained(context, event, recipient, sender, );
+```
+
+#### Parameters
+| Name | Type |
+| --- | --- |
+| context | PrivateContext |
+| event | Event |
+| recipient | AztecAddress |
+| sender | AztecAddress |
+| | |
+
+### encode_and_encrypt_event
+
+```rust
+encode_and_encrypt_event(context, recipient, sender, );
+```
+
+/ private logs.
+
+#### Parameters
+| Name | Type |
+| --- | --- |
+| context | &mut PrivateContext |
+| recipient | AztecAddress |
+| sender | AztecAddress |
+| | |
+
+### encode_and_encrypt_event_unconstrained
+
+```rust
+encode_and_encrypt_event_unconstrained(context, recipient, sender, );
+```
+
+/// Only use this function in scenarios where the recipient not receiving the event is an acceptable outcome.
+
+#### Parameters
+| Name | Type |
+| --- | --- |
+| context | &mut PrivateContext |
+| recipient | AztecAddress |
+| sender | AztecAddress |
+| | |
+
diff --git a/docs/versioned_docs/version-v0.82.2-alpha-testnet.5/developers/reference/smart_contract_reference/aztec-nr/aztec/encrypted_logs/log_assembly_strategies/default_aes128/note/encryption.md b/docs/versioned_docs/version-v0.82.2-alpha-testnet.5/developers/reference/smart_contract_reference/aztec-nr/aztec/encrypted_logs/log_assembly_strategies/default_aes128/note/encryption.md
new file mode 100644
index 000000000000..9bc540e83070
--- /dev/null
+++ b/docs/versioned_docs/version-v0.82.2-alpha-testnet.5/developers/reference/smart_contract_reference/aztec-nr/aztec/encrypted_logs/log_assembly_strategies/default_aes128/note/encryption.md
@@ -0,0 +1,41 @@
+## Standalone Functions
+
+### encrypt_log
+
+```rust
+encrypt_log(contract_address, plaintext, recipient, sender, );
+```
+
+/ 4. Format into final log structure with padding
+
+#### Parameters
+| Name | Type |
+| --- | --- |
+| contract_address | AztecAddress |
+| plaintext | [Field; PT] |
+| recipient | AztecAddress |
+| sender | AztecAddress |
+| | |
+
+### decrypt_log
+
+```rust
+decrypt_log(log, PRIVATE_LOG_SIZE_IN_FIELDS>, recipient, );
+```
+
+#### Parameters
+| Name | Type |
+| --- | --- |
+| log | BoundedVec<Field |
+| PRIVATE_LOG_SIZE_IN_FIELDS> | |
+| recipient | AztecAddress |
+| | |
+
+### encrypt_decrypt_log
+
+```rust
+encrypt_decrypt_log();
+```
+
+Takes no parameters.
+
diff --git a/docs/versioned_docs/version-v0.82.2-alpha-testnet.5/developers/reference/smart_contract_reference/aztec-nr/aztec/encrypted_logs/log_assembly_strategies/default_aes128/note/note.md b/docs/versioned_docs/version-v0.82.2-alpha-testnet.5/developers/reference/smart_contract_reference/aztec-nr/aztec/encrypted_logs/log_assembly_strategies/default_aes128/note/note.md
new file mode 100644
index 000000000000..0d6477b97196
--- /dev/null
+++ b/docs/versioned_docs/version-v0.82.2-alpha-testnet.5/developers/reference/smart_contract_reference/aztec-nr/aztec/encrypted_logs/log_assembly_strategies/default_aes128/note/note.md
@@ -0,0 +1,97 @@
+## Standalone Functions
+
+### assert_note_exists
+
+```rust
+assert_note_exists(context, note_hash_counter);
+```
+
+TODO: it feels like this existence check is in the wrong place. In fact, why is it needed at all? Under what circumstances have we found a non-existent note being emitted accidentally?
+
+#### Parameters
+| Name | Type |
+| --- | --- |
+| context | PrivateContext |
+| note_hash_counter | u32 |
+
+### compute_note_plaintext_for_this_strategy
+
+```rust
+compute_note_plaintext_for_this_strategy(note, storage_slot, );
+```
+
+/ NB: The "2" in "N + 2" is for the note_id and the storage_slot of the note:
+
+#### Parameters
+| Name | Type |
+| --- | --- |
+| note | Note |
+| storage_slot | Field |
+| | |
+
+### compute_log
+
+```rust
+compute_log(context, note, storage_slot, recipient, sender, );
+```
+
+#### Parameters
+| Name | Type |
+| --- | --- |
+| context | PrivateContext |
+| note | Note |
+| storage_slot | Field |
+| recipient | AztecAddress |
+| sender | AztecAddress |
+| | |
+
+### compute_log_unconstrained
+
+```rust
+compute_log_unconstrained(context, note, storage_slot, recipient, sender, );
+```
+
+#### Parameters
+| Name | Type |
+| --- | --- |
+| context | PrivateContext |
+| note | Note |
+| storage_slot | Field |
+| recipient | AztecAddress |
+| sender | AztecAddress |
+| | |
+
+### encode_and_encrypt_note
+
+```rust
+encode_and_encrypt_note(context, recipient, // We need this because to compute a tagging secret, we require a sender, );
+```
+
+/ private logs.
+
+#### Parameters
+| Name | Type |
+| --- | --- |
+| context | &mut PrivateContext |
+| recipient | AztecAddress |
+| // We need this because to compute a tagging secret | |
+| we require a sender | sender |
+| | |
+
+### encode_and_encrypt_note_unconstrained
+
+```rust
+encode_and_encrypt_note_unconstrained(context, recipient, // We need this because to compute a tagging secret, we require a sender, );
+```
+
+/// Only use this function in scenarios where the recipient not receiving the note is an acceptable outcome.
+
+#### Parameters
+| Name | Type |
+| --- | --- |
+| context | &mut PrivateContext |
+| recipient | AztecAddress |
+| // We need this because to compute a tagging secret | |
+| we require a sender | sender |
+| | |
+
diff --git a/docs/versioned_docs/version-v0.82.2-alpha-testnet.5/developers/reference/smart_contract_reference/aztec-nr/aztec/event/event_interface.md b/docs/versioned_docs/version-v0.82.2-alpha-testnet.5/developers/reference/smart_contract_reference/aztec-nr/aztec/event/event_interface.md
new file mode 100644
index 000000000000..c38c957c39b2
--- /dev/null
+++ b/docs/versioned_docs/version-v0.82.2-alpha-testnet.5/developers/reference/smart_contract_reference/aztec-nr/aztec/event/event_interface.md
@@ -0,0 +1,22 @@
+## Standalone Functions
+
+### get_event_type_id
+
+```rust
+get_event_type_id();
+```
+
+Takes no parameters.
+
+### emit
+
+```rust
+emit(self, emit);
+```
+
+#### Parameters
+| Name | Type |
+| --- | --- |
+| self | |
+| emit | fn[Env](Self |
+
diff --git a/docs/versioned_docs/version-v0.82.2-alpha-testnet.5/developers/reference/smart_contract_reference/aztec-nr/aztec/hash.md b/docs/versioned_docs/version-v0.82.2-alpha-testnet.5/developers/reference/smart_contract_reference/aztec-nr/aztec/hash.md
new file mode 100644
index 000000000000..c91a9008d6eb
--- /dev/null
+++ b/docs/versioned_docs/version-v0.82.2-alpha-testnet.5/developers/reference/smart_contract_reference/aztec-nr/aztec/hash.md
@@ -0,0 +1,169 @@
+# ArgsHasher
+
+## Fields
+| Field | Type |
+| --- | --- |
+| pub fields | Field] |
+
+## Methods
+
+### new
+
+```rust
+ArgsHasher::new();
+```
+
+Takes no parameters.
+
+### add
+
+```rust
+ArgsHasher::add(&mut self, field);
+```
+
+#### Parameters
+| Name | Type |
+| --- | --- |
+| &mut self | |
+| field | Field |
+
+### add_multiple
+
+```rust
+ArgsHasher::add_multiple(&mut self, fields);
+```
+
+#### Parameters
+| Name | Type |
+| --- | --- |
+| &mut self | |
+| fields | [Field; N] |
+
+## Standalone Functions
+
+### pedersen_commitment
+
+```rust
+pedersen_commitment(inputs, hash_index);
+```
+
+#### Parameters
+| Name | Type |
+| --- | --- |
+| inputs | [Field; N] |
+| hash_index | u32 |
+
+### compute_secret_hash
+
+```rust
+compute_secret_hash(secret);
+```
+
+#### Parameters
+| Name | Type |
+| --- | --- |
+| secret | Field |
+
+### compute_l1_to_l2_message_hash
+
+```rust
+compute_l1_to_l2_message_hash(sender, chain_id, recipient, version, content, secret_hash, leaf_index, );
+```
+
+#### Parameters
+| Name | Type |
+| --- | --- |
+| sender | EthAddress |
+| chain_id | Field |
+| recipient | AztecAddress |
+| version | Field |
+| content | Field |
+| secret_hash | Field |
+| leaf_index | Field |
+| | |
+
+### compute_l1_to_l2_message_nullifier
+
+```rust
+compute_l1_to_l2_message_nullifier(message_hash, secret);
+```
+
+The nullifier of a l1 to l2 message is the hash of the message salted with the secret
+
+#### Parameters
+| Name | Type |
+| --- | --- |
+| message_hash | Field |
+| secret | Field |
+
+### hash
+
+```rust
+hash(self);
+```
+
+#### Parameters
+| Name | Type |
+| --- | --- |
+| self | |
+
+### hash_args_array
+
+```rust
+hash_args_array(args);
+```
+
+Computes the hash of input arguments or return values for private functions, or for authwit creation.
+
+#### Parameters
+| Name | Type |
+| --- | --- |
+| args | [Field; N] |
+
+### hash_args
+
+```rust
+hash_args(args);
+```
+
+Same as `hash_args_array`, but takes a slice instead of an array.
+
+#### Parameters
+| Name | Type |
+| --- | --- |
+| args | [Field] |
+
+### hash_calldata_array
+
+```rust
+hash_calldata_array(calldata);
+```
+
+Computes the hash of calldata for public functions.
+
+#### Parameters
+| Name | Type |
+| --- | --- |
+| calldata | [Field; N] |
+
+### hash_calldata
+
+```rust
+hash_calldata(calldata);
+```
+
+Same as `hash_calldata_array`, but takes a slice instead of an array.
+
+#### Parameters
+| Name | Type |
+| --- | --- |
+| calldata | [Field] |
+
+### compute_var_args_hash
+
+```rust
+compute_var_args_hash();
+```
+
+Takes no parameters.
+
diff --git a/docs/versioned_docs/version-v0.82.2-alpha-testnet.5/developers/reference/smart_contract_reference/aztec-nr/aztec/history/contract_inclusion.md b/docs/versioned_docs/version-v0.82.2-alpha-testnet.5/developers/reference/smart_contract_reference/aztec-nr/aztec/history/contract_inclusion.md
new file mode 100644
index 000000000000..99fad72c761e
--- /dev/null
+++ b/docs/versioned_docs/version-v0.82.2-alpha-testnet.5/developers/reference/smart_contract_reference/aztec-nr/aztec/history/contract_inclusion.md
@@ -0,0 +1,98 @@
+## Standalone Functions
+
+### prove_contract_deployment
+
+```rust
+prove_contract_deployment(header, contract_address);
+```
+
+#### Parameters
+| Name | Type |
+| --- | --- |
+| header | BlockHeader |
+| contract_address | AztecAddress |
+
+### prove_contract_deployment
+
+```rust
+prove_contract_deployment(self, contract_address);
+```
+
+#### Parameters
+| Name | Type |
+| --- | --- |
+| self | |
+| contract_address | AztecAddress |
+
+### prove_contract_non_deployment
+
+```rust
+prove_contract_non_deployment(header, contract_address);
+```
+
+#### Parameters
+| Name | Type |
+| --- | --- |
+| header | BlockHeader |
+| contract_address | AztecAddress |
+
+### prove_contract_non_deployment
+
+```rust
+prove_contract_non_deployment(self, contract_address);
+```
+
+#### Parameters
+| Name | Type |
+| --- | --- |
+| self | |
+| contract_address | AztecAddress |
+
+### prove_contract_initialization
+
+```rust
+prove_contract_initialization(header, contract_address);
+```
+
+#### Parameters
+| Name | Type |
+| --- | --- |
+| header | BlockHeader |
+| contract_address | AztecAddress |
+
+### prove_contract_initialization
+
+```rust
+prove_contract_initialization(self, contract_address);
+```
+
+#### Parameters
+| Name | Type |
+| --- | --- |
+| self | |
+| contract_address | AztecAddress |
+
+### prove_contract_non_initialization
+
+```rust
+prove_contract_non_initialization(header, contract_address);
+```
+
+#### Parameters
+| Name | Type |
+| --- | --- |
+| header | BlockHeader |
+| contract_address | AztecAddress |
+
+### prove_contract_non_initialization
+
+```rust
+prove_contract_non_initialization(self, contract_address);
+```
+
+#### Parameters
+| Name | Type |
+| --- | --- |
+| self | |
+| contract_address | AztecAddress |
+
diff --git a/docs/versioned_docs/version-v0.82.2-alpha-testnet.5/developers/reference/smart_contract_reference/aztec-nr/aztec/history/note_inclusion.md b/docs/versioned_docs/version-v0.82.2-alpha-testnet.5/developers/reference/smart_contract_reference/aztec-nr/aztec/history/note_inclusion.md
new file mode 100644
index 000000000000..17ae76551001
--- /dev/null
+++ b/docs/versioned_docs/version-v0.82.2-alpha-testnet.5/developers/reference/smart_contract_reference/aztec-nr/aztec/history/note_inclusion.md
@@ -0,0 +1,29 @@
+## Standalone Functions
+
+### prove_note_inclusion
+
+```rust
+prove_note_inclusion(header, retrieved_note, storage_slot, );
+```
+
+#### Parameters
+| Name | Type |
+| --- | --- |
+| header | BlockHeader |
+| retrieved_note | RetrievedNote<Note> |
+| storage_slot | Field |
+| | |
+
+### prove_note_inclusion
+
+```rust
+prove_note_inclusion(self, retrieved_note, storage_slot);
+```
+
+#### Parameters
+| Name | Type |
+| --- | --- |
+| self | |
+| retrieved_note | RetrievedNote<Note> |
+| storage_slot | Field |
+
diff --git a/docs/versioned_docs/version-v0.82.2-alpha-testnet.5/developers/reference/smart_contract_reference/aztec-nr/aztec/history/note_inclusion/test.md b/docs/versioned_docs/version-v0.82.2-alpha-testnet.5/developers/reference/smart_contract_reference/aztec-nr/aztec/history/note_inclusion/test.md
new file mode 100644
index 000000000000..d2cd51877bd0
--- /dev/null
+++ b/docs/versioned_docs/version-v0.82.2-alpha-testnet.5/developers/reference/smart_contract_reference/aztec-nr/aztec/history/note_inclusion/test.md
@@ -0,0 +1,18 @@
+## Standalone Functions
+
+### note_inclusion
+
+```rust
+note_inclusion();
+```
+
+Takes no parameters.
+
+### note_inclusion_fails
+
+```rust
+note_inclusion_fails();
+```
+
+Takes no parameters.
+
diff --git a/docs/versioned_docs/version-v0.82.2-alpha-testnet.5/developers/reference/smart_contract_reference/aztec-nr/aztec/history/note_validity.md b/docs/versioned_docs/version-v0.82.2-alpha-testnet.5/developers/reference/smart_contract_reference/aztec-nr/aztec/history/note_validity.md
new file mode 100644
index 000000000000..77e745b3d35b
--- /dev/null
+++ b/docs/versioned_docs/version-v0.82.2-alpha-testnet.5/developers/reference/smart_contract_reference/aztec-nr/aztec/history/note_validity.md
@@ -0,0 +1,32 @@
+## Standalone Functions
+
+### prove_note_validity
+
+```rust
+prove_note_validity(header, retrieved_note, storage_slot, context, );
+```
+
+#### Parameters
+| Name | Type |
+| --- | --- |
+| header | BlockHeader |
+| retrieved_note | RetrievedNote<Note> |
+| storage_slot | Field |
+| context | &mut PrivateContext |
+| | |
+
+### prove_note_validity
+
+```rust
+prove_note_validity(self, retrieved_note, storage_slot, context, );
+```
+
+#### Parameters
+| Name | Type |
+| --- | --- |
+| self | |
+| retrieved_note | RetrievedNote<Note> |
+| storage_slot | Field |
+| context | &mut PrivateContext |
+| | |
+
diff --git a/docs/versioned_docs/version-v0.82.2-alpha-testnet.5/developers/reference/smart_contract_reference/aztec-nr/aztec/history/note_validity/test.md b/docs/versioned_docs/version-v0.82.2-alpha-testnet.5/developers/reference/smart_contract_reference/aztec-nr/aztec/history/note_validity/test.md
new file mode 100644
index 000000000000..5048efe761e7
--- /dev/null
+++ b/docs/versioned_docs/version-v0.82.2-alpha-testnet.5/developers/reference/smart_contract_reference/aztec-nr/aztec/history/note_validity/test.md
@@ -0,0 +1,26 @@
+## Standalone Functions
+
+### note_not_valid_due_to_non_inclusion
+
+```rust
+note_not_valid_due_to_non_inclusion();
+```
+
+Takes no parameters.
+
+### note_is_valid
+
+```rust
+note_is_valid();
+```
+
+Takes no parameters.
+
+### note_not_valid_due_to_nullification
+
+```rust
+note_not_valid_due_to_nullification();
+```
+
+Takes no parameters.
+
diff --git a/docs/versioned_docs/version-v0.82.2-alpha-testnet.5/developers/reference/smart_contract_reference/aztec-nr/aztec/history/nullifier_inclusion.md b/docs/versioned_docs/version-v0.82.2-alpha-testnet.5/developers/reference/smart_contract_reference/aztec-nr/aztec/history/nullifier_inclusion.md
new file mode 100644
index 000000000000..12767f6427d0
--- /dev/null
+++ b/docs/versioned_docs/version-v0.82.2-alpha-testnet.5/developers/reference/smart_contract_reference/aztec-nr/aztec/history/nullifier_inclusion.md
@@ -0,0 +1,58 @@
+## Standalone Functions
+
+### prove_nullifier_inclusion
+
+```rust
+prove_nullifier_inclusion(header, nullifier);
+```
+
+#### Parameters
+| Name | Type |
+| --- | --- |
+| header | BlockHeader |
+| nullifier | Field |
+
+### prove_nullifier_inclusion
+
+```rust
+prove_nullifier_inclusion(self, nullifier);
+```
+
+#### Parameters
+| Name | Type |
+| --- | --- |
+| self | |
+| nullifier | Field |
+
+### prove_note_is_nullified
+
+```rust
+prove_note_is_nullified(header, retrieved_note, storage_slot, context, );
+```
+
+#### Parameters
+| Name | Type |
+| --- | --- |
+| header | BlockHeader |
+| retrieved_note | RetrievedNote<Note> |
+| storage_slot | Field |
+| context | &mut PrivateContext |
+| | |
+
+### prove_note_is_nullified
+
+```rust
+prove_note_is_nullified(self, retrieved_note, storage_slot, context, );
+```
+
+docs:start:prove_note_is_nullified
+
+#### Parameters
+| Name | Type |
+| --- | --- |
+| self | |
+| retrieved_note | RetrievedNote<Note> |
+| storage_slot | Field |
+| context | &mut PrivateContext |
+| | |
+
diff --git a/docs/versioned_docs/version-v0.82.2-alpha-testnet.5/developers/reference/smart_contract_reference/aztec-nr/aztec/history/nullifier_inclusion/test.md b/docs/versioned_docs/version-v0.82.2-alpha-testnet.5/developers/reference/smart_contract_reference/aztec-nr/aztec/history/nullifier_inclusion/test.md
new file mode 100644
index 000000000000..eb17eb928337
--- /dev/null
+++ b/docs/versioned_docs/version-v0.82.2-alpha-testnet.5/developers/reference/smart_contract_reference/aztec-nr/aztec/history/nullifier_inclusion/test.md
@@ -0,0 +1,34 @@
+## Standalone Functions
+
+### note_is_nullified
+
+```rust
+note_is_nullified();
+```
+
+Takes no parameters.
+
+### note_is_not_nullified
+
+```rust
+note_is_not_nullified();
+```
+
+Takes no parameters.
+
+### nullifier_inclusion
+
+```rust
+nullifier_inclusion();
+```
+
+Takes no parameters.
+
+### nullifier_inclusion_fails
+
+```rust
+nullifier_inclusion_fails();
+```
+
+Takes no parameters.
+
diff --git a/docs/versioned_docs/version-v0.82.2-alpha-testnet.5/developers/reference/smart_contract_reference/aztec-nr/aztec/history/nullifier_non_inclusion.md b/docs/versioned_docs/version-v0.82.2-alpha-testnet.5/developers/reference/smart_contract_reference/aztec-nr/aztec/history/nullifier_non_inclusion.md
new file mode 100644
index 000000000000..003fe67433aa
--- /dev/null
+++ b/docs/versioned_docs/version-v0.82.2-alpha-testnet.5/developers/reference/smart_contract_reference/aztec-nr/aztec/history/nullifier_non_inclusion.md
@@ -0,0 +1,58 @@
+## Standalone Functions
+
+### prove_nullifier_non_inclusion
+
+```rust
+prove_nullifier_non_inclusion(header, nullifier);
+```
+
+#### Parameters
+| Name | Type |
+| --- | --- |
+| header | BlockHeader |
+| nullifier | Field |
+
+### prove_nullifier_non_inclusion
+
+```rust
+prove_nullifier_non_inclusion(self, nullifier);
+```
+
+#### Parameters
+| Name | Type |
+| --- | --- |
+| self | |
+| nullifier | Field |
+
+### prove_note_not_nullified
+
+```rust
+prove_note_not_nullified(header, retrieved_note, storage_slot, context, );
+```
+
+#### Parameters
+| Name | Type |
+| --- | --- |
+| header | BlockHeader |
+| retrieved_note | RetrievedNote<Note> |
+| storage_slot | Field |
+| context | &mut PrivateContext |
+| | |
+
+### prove_note_not_nullified
+
+```rust
+prove_note_not_nullified(self, retrieved_note, storage_slot, context, );
+```
+
+docs:start:prove_note_not_nullified
+
+#### Parameters
+| Name | Type |
+| --- | --- |
+| self | |
+| retrieved_note | RetrievedNote<Note> |
+| storage_slot | Field |
+| context | &mut PrivateContext |
+| | |
+
diff --git a/docs/versioned_docs/version-v0.82.2-alpha-testnet.5/developers/reference/smart_contract_reference/aztec-nr/aztec/history/nullifier_non_inclusion/test.md b/docs/versioned_docs/version-v0.82.2-alpha-testnet.5/developers/reference/smart_contract_reference/aztec-nr/aztec/history/nullifier_non_inclusion/test.md
new file mode 100644
index 000000000000..1049861dcd79
--- /dev/null
+++ b/docs/versioned_docs/version-v0.82.2-alpha-testnet.5/developers/reference/smart_contract_reference/aztec-nr/aztec/history/nullifier_non_inclusion/test.md
@@ -0,0 +1,34 @@
+## Standalone Functions
+
+### note_not_nullified
+
+```rust
+note_not_nullified();
+```
+
+Takes no parameters.
+
+### note_not_nullified_fails
+
+```rust
+note_not_nullified_fails();
+```
+
+Takes no parameters.
+
+### nullifier_non_inclusion
+
+```rust
+nullifier_non_inclusion();
+```
+
+Takes no parameters.
+
+### nullifier_non_inclusion_fails
+
+```rust
+nullifier_non_inclusion_fails();
+```
+
+Takes no parameters.
+
diff --git a/docs/versioned_docs/version-v0.82.2-alpha-testnet.5/developers/reference/smart_contract_reference/aztec-nr/aztec/history/public_storage.md b/docs/versioned_docs/version-v0.82.2-alpha-testnet.5/developers/reference/smart_contract_reference/aztec-nr/aztec/history/public_storage.md
new file mode 100644
index 000000000000..f7cd599a8f70
--- /dev/null
+++ b/docs/versioned_docs/version-v0.82.2-alpha-testnet.5/developers/reference/smart_contract_reference/aztec-nr/aztec/history/public_storage.md
@@ -0,0 +1,30 @@
+## Standalone Functions
+
+### public_storage_historical_read
+
+```rust
+public_storage_historical_read(header, storage_slot, contract_address, );
+```
+
+#### Parameters
+| Name | Type |
+| --- | --- |
+| header | BlockHeader |
+| storage_slot | Field |
+| contract_address | AztecAddress |
+| | |
+
+### public_storage_historical_read
+
+```rust
+public_storage_historical_read(self, storage_slot, contract_address, );
+```
+
+#### Parameters
+| Name | Type |
+| --- | --- |
+| self | |
+| storage_slot | Field |
+| contract_address | AztecAddress |
+| | |
+
diff --git a/docs/versioned_docs/version-v0.82.2-alpha-testnet.5/developers/reference/smart_contract_reference/aztec-nr/aztec/history/public_storage/test.md b/docs/versioned_docs/version-v0.82.2-alpha-testnet.5/developers/reference/smart_contract_reference/aztec-nr/aztec/history/public_storage/test.md
new file mode 100644
index 000000000000..84a551e9f2c1
--- /dev/null
+++ b/docs/versioned_docs/version-v0.82.2-alpha-testnet.5/developers/reference/smart_contract_reference/aztec-nr/aztec/history/public_storage/test.md
@@ -0,0 +1,26 @@
+## Standalone Functions
+
+### setup
+
+```rust
+setup();
+```
+
+Takes no parameters.
+
+### public_storage_read
+
+```rust
+public_storage_read();
+```
+
+Takes no parameters.
+
+### public_storage_read_empty
+
+```rust
+public_storage_read_empty();
+```
+
+Takes no parameters.
+
diff --git a/docs/versioned_docs/version-v0.82.2-alpha-testnet.5/developers/reference/smart_contract_reference/aztec-nr/aztec/history/test.md b/docs/versioned_docs/version-v0.82.2-alpha-testnet.5/developers/reference/smart_contract_reference/aztec-nr/aztec/history/test.md
new file mode 100644
index 000000000000..a60a191e3bd8
--- /dev/null
+++ b/docs/versioned_docs/version-v0.82.2-alpha-testnet.5/developers/reference/smart_contract_reference/aztec-nr/aztec/history/test.md
@@ -0,0 +1,18 @@
+## Standalone Functions
+
+### create_note
+
+```rust
+create_note();
+```
+
+Takes no parameters.
+
+### create_note_and_nullify_it
+
+```rust
+create_note_and_nullify_it();
+```
+
+Takes no parameters.
+
diff --git a/docs/versioned_docs/version-v0.82.2-alpha-testnet.5/developers/reference/smart_contract_reference/aztec-nr/aztec/keys/ecdh_shared_secret.md b/docs/versioned_docs/version-v0.82.2-alpha-testnet.5/developers/reference/smart_contract_reference/aztec-nr/aztec/keys/ecdh_shared_secret.md
new file mode 100644
index 000000000000..6208b7f6505a
--- /dev/null
+++ b/docs/versioned_docs/version-v0.82.2-alpha-testnet.5/developers/reference/smart_contract_reference/aztec-nr/aztec/keys/ecdh_shared_secret.md
@@ -0,0 +1,55 @@
+## Standalone Functions
+
+### derive_ecdh_shared_secret
+
+```rust
+derive_ecdh_shared_secret(secret, public_key);
+```
+
+See also: https://en.wikipedia.org/wiki/Elliptic-curve_Diffie%E2%80%93Hellman
+
+#### Parameters
+| Name | Type |
+| --- | --- |
+| secret | Scalar |
+| public_key | Point |
+
+### derive_ecdh_shared_secret_using_aztec_address
+
+```rust
+derive_ecdh_shared_secret_using_aztec_address(ephemeral_secret, recipient_address, );
+```
+
+/ given the address of their intended recipient.
+
+#### Parameters
+| Name | Type |
+| --- | --- |
+| ephemeral_secret | Scalar |
+| recipient_address | AztecAddress |
+| | |
+
+### test_consistency_with_typescript
+
+```rust
+test_consistency_with_typescript();
+```
+
+Takes no parameters.
+
+### test_shared_secret_computation_in_both_directions
+
+```rust
+test_shared_secret_computation_in_both_directions();
+```
+
+Takes no parameters.
+
+### test_shared_secret_computation_from_address_in_both_directions
+
+```rust
+test_shared_secret_computation_from_address_in_both_directions();
+```
+
+Takes no parameters.
+
diff --git a/docs/versioned_docs/version-v0.82.2-alpha-testnet.5/developers/reference/smart_contract_reference/aztec-nr/aztec/keys/ephemeral.md b/docs/versioned_docs/version-v0.82.2-alpha-testnet.5/developers/reference/smart_contract_reference/aztec-nr/aztec/keys/ephemeral.md
new file mode 100644
index 000000000000..e1c05843a2da
--- /dev/null
+++ b/docs/versioned_docs/version-v0.82.2-alpha-testnet.5/developers/reference/smart_contract_reference/aztec-nr/aztec/keys/ephemeral.md
@@ -0,0 +1,10 @@
+## Standalone Functions
+
+### generate_ephemeral_key_pair
+
+```rust
+generate_ephemeral_key_pair();
+```
+
+Takes no parameters.
+
diff --git a/docs/versioned_docs/version-v0.82.2-alpha-testnet.5/developers/reference/smart_contract_reference/aztec-nr/aztec/keys/getters/mod.md b/docs/versioned_docs/version-v0.82.2-alpha-testnet.5/developers/reference/smart_contract_reference/aztec-nr/aztec/keys/getters/mod.md
new file mode 100644
index 000000000000..9bf0f20e23a2
--- /dev/null
+++ b/docs/versioned_docs/version-v0.82.2-alpha-testnet.5/developers/reference/smart_contract_reference/aztec-nr/aztec/keys/getters/mod.md
@@ -0,0 +1,37 @@
+## Standalone Functions
+
+### get_nsk_app
+
+```rust
+get_nsk_app(npk_m_hash);
+```
+
+#### Parameters
+| Name | Type |
+| --- | --- |
+| npk_m_hash | Field |
+
+### get_ovsk_app
+
+```rust
+get_ovsk_app(ovpk_m_hash);
+```
+
+#### Parameters
+| Name | Type |
+| --- | --- |
+| ovpk_m_hash | Field |
+
+### get_public_keys
+
+```rust
+get_public_keys(account);
+```
+
+read keys that are not required by the caller can simply be discarded.
+
+#### Parameters
+| Name | Type |
+| --- | --- |
+| account | AztecAddress |
+
diff --git a/docs/versioned_docs/version-v0.82.2-alpha-testnet.5/developers/reference/smart_contract_reference/aztec-nr/aztec/keys/getters/test.md b/docs/versioned_docs/version-v0.82.2-alpha-testnet.5/developers/reference/smart_contract_reference/aztec-nr/aztec/keys/getters/test.md
new file mode 100644
index 000000000000..35208cbe0faa
--- /dev/null
+++ b/docs/versioned_docs/version-v0.82.2-alpha-testnet.5/developers/reference/smart_contract_reference/aztec-nr/aztec/keys/getters/test.md
@@ -0,0 +1,26 @@
+## Standalone Functions
+
+### setup
+
+```rust
+setup();
+```
+
+Takes no parameters.
+
+### test_get_public_keys_unknown
+
+```rust
+test_get_public_keys_unknown();
+```
+
+Takes no parameters.
+
+### test_get_public_keys_known
+
+```rust
+test_get_public_keys_known();
+```
+
+Takes no parameters.
+
diff --git a/docs/versioned_docs/version-v0.82.2-alpha-testnet.5/developers/reference/smart_contract_reference/aztec-nr/aztec/macros/aztec.md b/docs/versioned_docs/version-v0.82.2-alpha-testnet.5/developers/reference/smart_contract_reference/aztec-nr/aztec/macros/aztec.md
new file mode 100644
index 000000000000..0d69ebad4e9e
--- /dev/null
+++ b/docs/versioned_docs/version-v0.82.2-alpha-testnet.5/developers/reference/smart_contract_reference/aztec-nr/aztec/macros/aztec.md
@@ -0,0 +1,180 @@
+## Standalone Functions
+
+### aztec
+
+```rust
+aztec(m);
+```
+
+#### Parameters
+| Name | Type |
+| --- | --- |
+| m | Module |
+
+### generate_contract_interface
+
+```rust
+generate_contract_interface(m);
+```
+
+#### Parameters
+| Name | Type |
+| --- | --- |
+| m | Module |
+
+### storage_layout
+
+```rust
+storage_layout();
+```
+
+Takes no parameters.
+
+### at
+
+```rust
+at(addr);
+```
+
+#### Parameters
+| Name | Type |
+| --- | --- |
+| addr | aztec |
+
+### interface
+
+```rust
+interface();
+```
+
+Takes no parameters.
+
+### at
+
+```rust
+at(addr);
+```
+
+#### Parameters
+| Name | Type |
+| --- | --- |
+| addr | aztec |
+
+### interface
+
+```rust
+interface();
+```
+
+Takes no parameters.
+
+### generate_contract_library_method_compute_note_hash_and_nullifier
+
+```rust
+generate_contract_library_method_compute_note_hash_and_nullifier();
+```
+
+Takes no parameters.
+
+### _compute_note_hash_and_nullifier
+
+```rust
+_compute_note_hash_and_nullifier(packed_note, aztec, storage_slot, note_type_id, contract_address, nonce, );
+```
+
+#### Parameters
+| Name | Type |
+| --- | --- |
+| packed_note | BoundedVec<Field |
+| aztec | |
+| storage_slot | Field |
+| note_type_id | Field |
+| contract_address | aztec |
+| nonce | Field |
+| | |
+
+### _compute_note_hash_and_nullifier
+
+```rust
+_compute_note_hash_and_nullifier(_packed_note, aztec, _storage_slot, _note_type_id, _contract_address, _nonce, );
+```
+
+#### Parameters
+| Name | Type |
+| --- | --- |
+| _packed_note | BoundedVec<Field |
+| aztec | |
+| _storage_slot | Field |
+| _note_type_id | Field |
+| _contract_address | aztec |
+| _nonce | Field |
+| | |
+
+### generate_process_log
+
+```rust
+generate_process_log();
+```
+
+Takes no parameters.
+
+### process_log
+
+```rust
+process_log(log_ciphertext, dep, tx_hash, unique_note_hashes_in_tx, dep, first_nullifier_in_tx, recipient, );
+```
+
+#### Parameters
+| Name | Type |
+| --- | --- |
+| log_ciphertext | BoundedVec<Field |
+| dep | |
+| tx_hash | Field |
+| unique_note_hashes_in_tx | BoundedVec<Field |
+| dep | |
+| first_nullifier_in_tx | Field |
+| recipient | aztec |
+| | |
+
+### process_log
+
+```rust
+process_log(_log_ciphertext, dep, _tx_hash, _unique_note_hashes_in_tx, dep, _first_nullifier_in_tx, _recipient, );
+```
+
+#### Parameters
+| Name | Type |
+| --- | --- |
+| _log_ciphertext | BoundedVec<Field |
+| dep | |
+| _tx_hash | Field |
+| _unique_note_hashes_in_tx | BoundedVec<Field |
+| dep | |
+| _first_nullifier_in_tx | Field |
+| _recipient | aztec |
+| | |
+
+### generate_note_exports
+
+```rust
+generate_note_exports();
+```
+
+Takes no parameters.
+
+### generate_sync_notes
+
+```rust
+generate_sync_notes();
+```
+
+Takes no parameters.
+
+### sync_notes
+
+```rust
+sync_notes();
+```
+
+Takes no parameters.
+
diff --git a/docs/versioned_docs/version-v0.82.2-alpha-testnet.5/developers/reference/smart_contract_reference/aztec-nr/aztec/macros/dispatch.md b/docs/versioned_docs/version-v0.82.2-alpha-testnet.5/developers/reference/smart_contract_reference/aztec-nr/aztec/macros/dispatch.md
new file mode 100644
index 000000000000..d080c5d1f26a
--- /dev/null
+++ b/docs/versioned_docs/version-v0.82.2-alpha-testnet.5/developers/reference/smart_contract_reference/aztec-nr/aztec/macros/dispatch.md
@@ -0,0 +1,142 @@
+## Standalone Functions
+
+### public_dispatch
+
+```rust
+public_dispatch(.);
+```
+
+#### Parameters
+| Name | Type |
+| --- | --- |
+| . | |
+
+### generate_public_dispatch
+
+```rust
+generate_public_dispatch(m);
+```
+
+#### Parameters
+| Name | Type |
+| --- | --- |
+| m | Module |
+
+### public_dispatch
+
+```rust
+public_dispatch(selector);
+```
+
+#### Parameters
+| Name | Type |
+| --- | --- |
+| selector | Field |
+
+### size_in_fields
+
+```rust
+size_in_fields(typ);
+```
+
+#### Parameters
+| Name | Type |
+| --- | --- |
+| typ | Type |
+
+### array_size_in_fields
+
+```rust
+array_size_in_fields(typ);
+```
+
+#### Parameters
+| Name | Type |
+| --- | --- |
+| typ | Type |
+
+### bool_size_in_fields
+
+```rust
+bool_size_in_fields(typ);
+```
+
+#### Parameters
+| Name | Type |
+| --- | --- |
+| typ | Type |
+
+### field_size_in_fields
+
+```rust
+field_size_in_fields(typ);
+```
+
+#### Parameters
+| Name | Type |
+| --- | --- |
+| typ | Type |
+
+### int_size_in_fields
+
+```rust
+int_size_in_fields(typ);
+```
+
+#### Parameters
+| Name | Type |
+| --- | --- |
+| typ | Type |
+
+### constant_size_in_fields
+
+```rust
+constant_size_in_fields(typ);
+```
+
+#### Parameters
+| Name | Type |
+| --- | --- |
+| typ | Type |
+
+### str_size_in_fields
+
+```rust
+str_size_in_fields(typ);
+```
+
+#### Parameters
+| Name | Type |
+| --- | --- |
+| typ | Type |
+
+### struct_size_in_fields
+
+```rust
+struct_size_in_fields(typ);
+```
+
+#### Parameters
+| Name | Type |
+| --- | --- |
+| typ | Type |
+
+### tuple_size_in_fields
+
+```rust
+tuple_size_in_fields(typ);
+```
+
+#### Parameters
+| Name | Type |
+| --- | --- |
+| typ | Type |
+
+### get_type
+
+```rust
+get_type();
+```
+
+Takes no parameters.
+
diff --git a/docs/versioned_docs/version-v0.82.2-alpha-testnet.5/developers/reference/smart_contract_reference/aztec-nr/aztec/macros/events.md b/docs/versioned_docs/version-v0.82.2-alpha-testnet.5/developers/reference/smart_contract_reference/aztec-nr/aztec/macros/events.md
new file mode 100644
index 000000000000..745884c771c4
--- /dev/null
+++ b/docs/versioned_docs/version-v0.82.2-alpha-testnet.5/developers/reference/smart_contract_reference/aztec-nr/aztec/macros/events.md
@@ -0,0 +1,44 @@
+## Standalone Functions
+
+### generate_event_interface
+
+```rust
+generate_event_interface(s);
+```
+
+#### Parameters
+| Name | Type |
+| --- | --- |
+| s | TypeDefinition |
+
+### get_event_type_id
+
+```rust
+get_event_type_id();
+```
+
+Takes no parameters.
+
+### emit
+
+```rust
+emit(self, _emit);
+```
+
+#### Parameters
+| Name | Type |
+| --- | --- |
+| self | |
+| _emit | fn[Env](Self |
+
+### event
+
+```rust
+event(s);
+```
+
+#### Parameters
+| Name | Type |
+| --- | --- |
+| s | TypeDefinition |
+
diff --git a/docs/versioned_docs/version-v0.82.2-alpha-testnet.5/developers/reference/smart_contract_reference/aztec-nr/aztec/macros/functions/abi_export.md b/docs/versioned_docs/version-v0.82.2-alpha-testnet.5/developers/reference/smart_contract_reference/aztec-nr/aztec/macros/functions/abi_export.md
new file mode 100644
index 000000000000..b559bf7092be
--- /dev/null
+++ b/docs/versioned_docs/version-v0.82.2-alpha-testnet.5/developers/reference/smart_contract_reference/aztec-nr/aztec/macros/functions/abi_export.md
@@ -0,0 +1,13 @@
+## Standalone Functions
+
+### create_fn_abi_export
+
+```rust
+create_fn_abi_export(f);
+```
+
+#### Parameters
+| Name | Type |
+| --- | --- |
+| f | FunctionDefinition |
+
diff --git a/docs/versioned_docs/version-v0.82.2-alpha-testnet.5/developers/reference/smart_contract_reference/aztec-nr/aztec/macros/functions/call_interface_stubs.md b/docs/versioned_docs/version-v0.82.2-alpha-testnet.5/developers/reference/smart_contract_reference/aztec-nr/aztec/macros/functions/call_interface_stubs.md
new file mode 100644
index 000000000000..36ef2917c2a6
--- /dev/null
+++ b/docs/versioned_docs/version-v0.82.2-alpha-testnet.5/developers/reference/smart_contract_reference/aztec-nr/aztec/macros/functions/call_interface_stubs.md
@@ -0,0 +1,113 @@
+## Standalone Functions
+
+### stub_fn
+
+```rust
+stub_fn(f);
+```
+
+#### Parameters
+| Name | Type |
+| --- | --- |
+| f | FunctionDefinition |
+
+### create_stub_base
+
+```rust
+create_stub_base(f, );
+```
+
+#### Parameters
+| Name | Type |
+| --- | --- |
+| f | FunctionDefinition |
+| | |
+
+### create_private_stub
+
+```rust
+create_private_stub(f);
+```
+
+#### Parameters
+| Name | Type |
+| --- | --- |
+| f | FunctionDefinition |
+
+### create_private_static_stub
+
+```rust
+create_private_static_stub(f);
+```
+
+#### Parameters
+| Name | Type |
+| --- | --- |
+| f | FunctionDefinition |
+
+### create_private_void_stub
+
+```rust
+create_private_void_stub(f);
+```
+
+#### Parameters
+| Name | Type |
+| --- | --- |
+| f | FunctionDefinition |
+
+### create_private_static_void_stub
+
+```rust
+create_private_static_void_stub(f);
+```
+
+#### Parameters
+| Name | Type |
+| --- | --- |
+| f | FunctionDefinition |
+
+### create_public_stub
+
+```rust
+create_public_stub(f);
+```
+
+#### Parameters
+| Name | Type |
+| --- | --- |
+| f | FunctionDefinition |
+
+### create_public_static_stub
+
+```rust
+create_public_static_stub(f);
+```
+
+#### Parameters
+| Name | Type |
+| --- | --- |
+| f | FunctionDefinition |
+
+### create_public_void_stub
+
+```rust
+create_public_void_stub(f);
+```
+
+#### Parameters
+| Name | Type |
+| --- | --- |
+| f | FunctionDefinition |
+
+### create_public_static_void_stub
+
+```rust
+create_public_static_void_stub(f);
+```
+
+#### Parameters
+| Name | Type |
+| --- | --- |
+| f | FunctionDefinition |
+
diff --git a/docs/versioned_docs/version-v0.82.2-alpha-testnet.5/developers/reference/smart_contract_reference/aztec-nr/aztec/macros/functions/initialization_utils.md b/docs/versioned_docs/version-v0.82.2-alpha-testnet.5/developers/reference/smart_contract_reference/aztec-nr/aztec/macros/functions/initialization_utils.md
new file mode 100644
index 000000000000..c3a8e5393fd3
--- /dev/null
+++ b/docs/versioned_docs/version-v0.82.2-alpha-testnet.5/developers/reference/smart_contract_reference/aztec-nr/aztec/macros/functions/initialization_utils.md
@@ -0,0 +1,94 @@
+## Standalone Functions
+
+### mark_as_initialized_public
+
+```rust
+mark_as_initialized_public(context);
+```
+
+#### Parameters
+| Name | Type |
+| --- | --- |
+| context | &mut PublicContext |
+
+### mark_as_initialized_private
+
+```rust
+mark_as_initialized_private(context);
+```
+
+#### Parameters
+| Name | Type |
+| --- | --- |
+| context | &mut PrivateContext |
+
+### assert_is_initialized_public
+
+```rust
+assert_is_initialized_public(context);
+```
+
+#### Parameters
+| Name | Type |
+| --- | --- |
+| context | &mut PublicContext |
+
+### assert_is_initialized_private
+
+```rust
+assert_is_initialized_private(context);
+```
+
+#### Parameters
+| Name | Type |
+| --- | --- |
+| context | &mut PrivateContext |
+
+### compute_unsiloed_contract_initialization_nullifier
+
+```rust
+compute_unsiloed_contract_initialization_nullifier(address);
+```
+
+#### Parameters
+| Name | Type |
+| --- | --- |
+| address | AztecAddress |
+
+### assert_initialization_matches_address_preimage_public
+
+```rust
+assert_initialization_matches_address_preimage_public(context);
+```
+
+#### Parameters
+| Name | Type |
+| --- | --- |
+| context | PublicContext |
+
+### assert_initialization_matches_address_preimage_private
+
+```rust
+assert_initialization_matches_address_preimage_private(context);
+```
+
+#### Parameters
+| Name | Type |
+| --- | --- |
+| context | PrivateContext |
+
+### compute_initialization_hash
+
+```rust
+compute_initialization_hash(init_selector, init_args_hash, );
+```
+
+/ initialized with the correct constructor arguments. Don't hide this unless you implement factory functionality.
+
+#### Parameters
+| Name | Type |
+| --- | --- |
+| init_selector | FunctionSelector |
+| init_args_hash | Field |
+| | |
+
diff --git a/docs/versioned_docs/version-v0.82.2-alpha-testnet.5/developers/reference/smart_contract_reference/aztec-nr/aztec/macros/functions/mod.md b/docs/versioned_docs/version-v0.82.2-alpha-testnet.5/developers/reference/smart_contract_reference/aztec-nr/aztec/macros/functions/mod.md
new file mode 100644
index 000000000000..2ceb029cffeb
--- /dev/null
+++ b/docs/versioned_docs/version-v0.82.2-alpha-testnet.5/developers/reference/smart_contract_reference/aztec-nr/aztec/macros/functions/mod.md
@@ -0,0 +1,68 @@
+## Standalone Functions
+
+### initializer
+
+```rust
+initializer(_f);
+```
+
+#### Parameters
+| Name | Type |
+| --- | --- |
+| _f | FunctionDefinition |
+
+### noinitcheck
+
+```rust
+noinitcheck(_f);
+```
+
+#### Parameters
+| Name | Type |
+| --- | --- |
+| _f | FunctionDefinition |
+
+### internal
+
+```rust
+internal(_f);
+```
+
+#### Parameters
+| Name | Type |
+| --- | --- |
+| _f | FunctionDefinition |
+
+### view
+
+```rust
+view(_f);
+```
+
+#### Parameters
+| Name | Type |
+| --- | --- |
+| _f | FunctionDefinition |
+
+### private
+
+```rust
+private(f);
+```
+
+#### Parameters
+| Name | Type |
+| --- | --- |
+| f | FunctionDefinition |
+
+### public
+
+```rust
+public(f);
+```
+
+#### Parameters
+| Name | Type |
+| --- | --- |
+| f | FunctionDefinition |
+
diff --git a/docs/versioned_docs/version-v0.82.2-alpha-testnet.5/developers/reference/smart_contract_reference/aztec-nr/aztec/macros/functions/stub_registry.md b/docs/versioned_docs/version-v0.82.2-alpha-testnet.5/developers/reference/smart_contract_reference/aztec-nr/aztec/macros/functions/stub_registry.md
new file mode 100644
index 000000000000..b8d43a524603
--- /dev/null
+++ b/docs/versioned_docs/version-v0.82.2-alpha-testnet.5/developers/reference/smart_contract_reference/aztec-nr/aztec/macros/functions/stub_registry.md
@@ -0,0 +1,25 @@
+## Standalone Functions
+
+### register
+
+```rust
+register(m, stub);
+```
+
+#### Parameters
+| Name | Type |
+| --- | --- |
+| m | Module |
+| stub | Quoted |
+
+### get
+
+```rust
+get(m);
+```
+
+#### Parameters
+| Name | Type |
+| --- | --- |
+| m | Module |
+
diff --git a/docs/versioned_docs/version-v0.82.2-alpha-testnet.5/developers/reference/smart_contract_reference/aztec-nr/aztec/macros/functions/utils.md b/docs/versioned_docs/version-v0.82.2-alpha-testnet.5/developers/reference/smart_contract_reference/aztec-nr/aztec/macros/functions/utils.md
new file mode 100644
index 000000000000..08934e173332
--- /dev/null
+++ b/docs/versioned_docs/version-v0.82.2-alpha-testnet.5/developers/reference/smart_contract_reference/aztec-nr/aztec/macros/functions/utils.md
@@ -0,0 +1,109 @@
+## Standalone Functions
+
+### transform_private
+
+```rust
+transform_private(f);
+```
+
+#### Parameters
+| Name | Type |
+| --- | --- |
+| f | FunctionDefinition |
+
+### transform_public
+
+```rust
+transform_public(f);
+```
+
+#### Parameters
+| Name | Type |
+| --- | --- |
+| f | FunctionDefinition |
+
+### find_and_transform_top_level_unconstrained_fns
+
+```rust
+find_and_transform_top_level_unconstrained_fns(m);
+```
+
+#### Parameters
+| Name | Type |
+| --- | --- |
+| m | Module |
+
+### transform_top_level_unconstrained
+
+```rust
+transform_top_level_unconstrained(f);
+```
+
+#### Parameters
+| Name | Type |
+| --- | --- |
+| f | FunctionDefinition |
+
+### create_internal_check
+
+```rust
+create_internal_check(f);
+```
+
+#### Parameters
+| Name | Type |
+| --- | --- |
+| f | FunctionDefinition |
+
+### create_view_check
+
+```rust
+create_view_check(f);
+```
+
+#### Parameters
+| Name | Type |
+| --- | --- |
+| f | FunctionDefinition |
+
+### create_assert_correct_initializer_args
+
+```rust
+create_assert_correct_initializer_args(f);
+```
+
+#### Parameters
+| Name | Type |
+| --- | --- |
+| f | FunctionDefinition |
+
+### create_mark_as_initialized
+
+```rust
+create_mark_as_initialized(f);
+```
+
+#### Parameters
+| Name | Type |
+| --- | --- |
+| f | FunctionDefinition |
+
+### create_init_check
+
+```rust
+create_init_check(f);
+```
+
+#### Parameters
+| Name | Type |
+| --- | --- |
+| f | FunctionDefinition |
+
+### create_message_discovery_call
+
+```rust
+create_message_discovery_call();
+```
+
+Takes no parameters.
+
diff --git a/docs/versioned_docs/version-v0.82.2-alpha-testnet.5/developers/reference/smart_contract_reference/aztec-nr/aztec/macros/notes.md b/docs/versioned_docs/version-v0.82.2-alpha-testnet.5/developers/reference/smart_contract_reference/aztec-nr/aztec/macros/notes.md
new file mode 100644
index 000000000000..18cc24210af5
--- /dev/null
+++ b/docs/versioned_docs/version-v0.82.2-alpha-testnet.5/developers/reference/smart_contract_reference/aztec-nr/aztec/macros/notes.md
@@ -0,0 +1,284 @@
+# TokenNoteProperties
+
+/ Generates note properties struct for a given note struct `s`. / / Example: / ```
+
+# TokenNoteFields_5695262104
+
+/ Generates note export for a given note struct `s`. The export is a global variable that contains note type id, / note name and information about note fields (field name, index and whether the field is nullable or not). / / Example: / ```
+
+# CustomNote
+
+/ Generates code for a custom note implementation that requires specialized note hash or nullifier computation. / / # Generated Code / - NoteTypeProperties: Defines the structure and properties of note fields / - NoteType trait implementation: Provides the note type ID / - Packable implementation: Enables serialization/deserialization of the note / / # Registration / Registers the note in the global `NOTES` map with: / - Note type ID / - Packed length / - Field indices and nullability / / # Use Cases / Use this macro when implementing a note that needs custom: / - Note hash computation logic / - Nullifier computation logic / / The macro omits generating default NoteHash trait implementation, allowing you to provide your own. / / # Example / ``` / #[custom_note]
+
+## Standalone Functions
+
+### get_next_note_type_id
+
+```rust
+get_next_note_type_id();
+```
+
+Takes no parameters.
+
+### derive_packable_if_not_implemented_and_get_len
+
+```rust
+derive_packable_if_not_implemented_and_get_len(s);
+```
+
+#### Parameters
+| Name | Type |
+| --- | --- |
+| s | TypeDefinition |
+
+### get_id
+
+```rust
+get_id();
+```
+
+Takes no parameters.
+
+### generate_note_interface
+
+```rust
+generate_note_interface(s, note_type_id);
+```
+
+#### Parameters
+| Name | Type |
+| --- | --- |
+| s | TypeDefinition |
+| note_type_id | Field |
+
+### get_id
+
+```rust
+get_id();
+```
+
+Takes no parameters.
+
+### compute_note_hash
+
+```rust
+compute_note_hash(self, storage_slot);
+```
+
+#### Parameters
+| Name | Type |
+| --- | --- |
+| self | |
+| storage_slot | Field |
+
+### compute_nullifier
+
+```rust
+compute_nullifier(self, context, note_hash_for_nullify);
+```
+
+#### Parameters
+| Name | Type |
+| --- | --- |
+| self | |
+| context | &mut PrivateContext |
+| note_hash_for_nullify | Field |
+
+### compute_nullifier_unconstrained
+
+```rust
+compute_nullifier_unconstrained(note_hash_for_nullify);
+```
+
+#### Parameters
+| Name | Type |
+| --- | --- |
+| note_hash_for_nullify | Field |
+
+### generate_note_hash_trait_impl
+
+```rust
+generate_note_hash_trait_impl(s);
+```
+
+#### Parameters
+| Name | Type |
+| --- | --- |
+| s | TypeDefinition |
+
+### compute_note_hash
+
+```rust
+compute_note_hash(self, storage_slot);
+```
+
+#### Parameters
+| Name | Type |
+| --- | --- |
+| self | |
+| storage_slot | Field |
+
+### compute_nullifier
+
+```rust
+compute_nullifier(self, context, note_hash_for_nullify, );
+```
+
+#### Parameters
+| Name | Type |
+| --- | --- |
+| self | |
+| context | &mut aztec |
+| note_hash_for_nullify | Field |
+| | |
+
+### compute_nullifier_unconstrained
+
+```rust
+compute_nullifier_unconstrained(self, note_hash_for_nullify, );
+```
+
+#### Parameters
+| Name | Type |
+| --- | --- |
+| self | |
+| note_hash_for_nullify | Field |
+| | |
+
+### properties
+
+```rust
+properties();
+```
+
+Takes no parameters.
+
+### generate_note_properties
+
+```rust
+generate_note_properties(s);
+```
+
+#### Parameters
+| Name | Type |
+| --- | --- |
+| s | TypeDefinition |
+
+### properties
+
+```rust
+properties();
+```
+
+Takes no parameters.
+
+### generate_note_export
+
+```rust
+generate_note_export(s, note_type_id, fields, u32, bool);
+```
+
+#### Parameters
+| Name | Type |
+| --- | --- |
+| s | TypeDefinition |
+| note_type_id | Field |
+| fields | [(Quoted |
+| u32 | |
+| bool | |
+
+### register_note
+
+```rust
+register_note(note, note_packed_len, note_type_id, fixed_fields, Type, u32);
+```
+
+#### Parameters
+| Name | Type |
+| --- | --- |
+| note | TypeDefinition |
+| note_packed_len | u32 |
+| note_type_id | Field |
+| fixed_fields | [(Quoted |
+| Type | |
+| u32 | |
+
+### index_note_fields
+
+```rust
+index_note_fields(s, nullable_fields, );
+```
+
+#### Parameters
+| Name | Type |
+| --- | --- |
+| s | TypeDefinition |
+| nullable_fields | [Quoted] |
+| | |
+
+### note
+
+```rust
+note(s);
+```
+
+#### Parameters
+| Name | Type |
+| --- | --- |
+| s | TypeDefinition |
+
+### compute_note_hash
+
+```rust
+compute_note_hash(.);
+```
+
+#### Parameters
+| Name | Type |
+| --- | --- |
+| . | |
+
+### compute_nullifier
+
+```rust
+compute_nullifier(.);
+```
+
+#### Parameters
+| Name | Type |
+| --- | --- |
+| . | |
+
+### compute_nullifier_unconstrained
+
+```rust
+compute_nullifier_unconstrained(.);
+```
+
+#### Parameters
+| Name | Type |
+| --- | --- |
+| . | |
+
+### custom_note
+
+```rust
+custom_note(s);
+```
+
+#### Parameters
+| Name | Type |
+| --- | --- |
+| s | TypeDefinition |
+
+### assert_has_owner
+
+```rust
+assert_has_owner(note);
+```
+
+#### Parameters
+| Name | Type |
+| --- | --- |
+| note | TypeDefinition |
+
diff --git a/docs/versioned_docs/version-v0.82.2-alpha-testnet.5/developers/reference/smart_contract_reference/aztec-nr/aztec/macros/storage.md b/docs/versioned_docs/version-v0.82.2-alpha-testnet.5/developers/reference/smart_contract_reference/aztec-nr/aztec/macros/storage.md
new file mode 100644
index 000000000000..ba8e0747cbc0
--- /dev/null
+++ b/docs/versioned_docs/version-v0.82.2-alpha-testnet.5/developers/reference/smart_contract_reference/aztec-nr/aztec/macros/storage.md
@@ -0,0 +1,97 @@
+# StorageLayoutFields
+
+## Standalone Functions
+
+### storage
+
+```rust
+storage(s);
+```
+
+#### Parameters
+| Name | Type |
+| --- | --- |
+| s | TypeDefinition |
+
+### init
+
+```rust
+init(context);
+```
+
+#### Parameters
+| Name | Type |
+| --- | --- |
+| context | Context |
+
+### init
+
+```rust
+init(context);
+```
+
+#### Parameters
+| Name | Type |
+| --- | --- |
+| context | Context |
+
+### storage_no_init
+
+```rust
+storage_no_init(_s);
+```
+
+#### Parameters
+| Name | Type |
+| --- | --- |
+| _s | TypeDefinition |
+
+### generate_storage_field_constructor
+
+```rust
+generate_storage_field_constructor(typ, slot, parent_is_map, );
+```
+
+#### Parameters
+| Name | Type |
+| --- | --- |
+| typ | Type |
+| slot | Quoted |
+| parent_is_map | bool |
+| | |
+
+### new
+
+```rust
+new(context, slot);
+```
+
+#### Parameters
+| Name | Type |
+| --- | --- |
+| context | Context |
+| slot | Field |
+
+### is_storage_map
+
+```rust
+is_storage_map(typ);
+```
+
+#### Parameters
+| Name | Type |
+| --- | --- |
+| typ | Type |
+
+### add_context_generic
+
+```rust
+add_context_generic(typ, context_generic);
+```
+
+#### Parameters
+| Name | Type |
+| --- | --- |
+| typ | Type |
+| context_generic | Type |
+
diff --git a/docs/versioned_docs/version-v0.82.2-alpha-testnet.5/developers/reference/smart_contract_reference/aztec-nr/aztec/macros/utils.md b/docs/versioned_docs/version-v0.82.2-alpha-testnet.5/developers/reference/smart_contract_reference/aztec-nr/aztec/macros/utils.md
new file mode 100644
index 000000000000..9072bc32edd8
--- /dev/null
+++ b/docs/versioned_docs/version-v0.82.2-alpha-testnet.5/developers/reference/smart_contract_reference/aztec-nr/aztec/macros/utils.md
@@ -0,0 +1,247 @@
+# Foo
+
+The event selector is computed from the type signature of the struct in the event, similar to how one might type the constructor function. For example, given:
+
+## Standalone Functions
+
+### get_fn_visibility
+
+```rust
+get_fn_visibility(f);
+```
+
+#### Parameters
+| Name | Type |
+| --- | --- |
+| f | FunctionDefinition |
+
+### is_fn_private
+
+```rust
+is_fn_private(f);
+```
+
+#### Parameters
+| Name | Type |
+| --- | --- |
+| f | FunctionDefinition |
+
+### is_fn_public
+
+```rust
+is_fn_public(f);
+```
+
+#### Parameters
+| Name | Type |
+| --- | --- |
+| f | FunctionDefinition |
+
+### is_fn_view
+
+```rust
+is_fn_view(f);
+```
+
+#### Parameters
+| Name | Type |
+| --- | --- |
+| f | FunctionDefinition |
+
+### is_fn_internal
+
+```rust
+is_fn_internal(f);
+```
+
+#### Parameters
+| Name | Type |
+| --- | --- |
+| f | FunctionDefinition |
+
+### is_fn_initializer
+
+```rust
+is_fn_initializer(f);
+```
+
+#### Parameters
+| Name | Type |
+| --- | --- |
+| f | FunctionDefinition |
+
+### fn_has_noinitcheck
+
+```rust
+fn_has_noinitcheck(f);
+```
+
+#### Parameters
+| Name | Type |
+| --- | --- |
+| f | FunctionDefinition |
+
+### modify_fn_body
+
+```rust
+modify_fn_body(body, prepend, append);
+```
+
+#### Parameters
+| Name | Type |
+| --- | --- |
+| body | [Expr] |
+| prepend | Quoted |
+| append | Quoted |
+
+### add_to_field_slice
+
+```rust
+add_to_field_slice(slice_name, name, typ);
+```
+
+#### Parameters
+| Name | Type |
+| --- | --- |
+| slice_name | Quoted |
+| name | Quoted |
+| typ | Type |
+
+### add_to_hasher
+
+```rust
+add_to_hasher(hasher_name, name, typ);
+```
+
+#### Parameters
+| Name | Type |
+| --- | --- |
+| hasher_name | Quoted |
+| name | Quoted |
+| typ | Type |
+
+### signature_of_type
+
+```rust
+signature_of_type(typ);
+```
+
+#### Parameters
+| Name | Type |
+| --- | --- |
+| typ | Type |
+
+### as_str_quote
+
+```rust
+as_str_quote(self);
+```
+
+#### Parameters
+| Name | Type |
+| --- | --- |
+| self | |
+
+### as_str_quote
+
+```rust
+as_str_quote(self);
+```
+
+#### Parameters
+| Name | Type |
+| --- | --- |
+| self | |
+
+### compute_fn_selector
+
+```rust
+compute_fn_selector(f);
+```
+
+#### Parameters
+| Name | Type |
+| --- | --- |
+| f | FunctionDefinition |
+
+### foo
+
+```rust
+foo(a, b);
+```
+
+#### Parameters
+| Name | Type |
+| --- | --- |
+| a | Field |
+| b | AztecAddress |
+
+### compute_event_selector
+
+```rust
+compute_event_selector(s);
+```
+
+#### Parameters
+| Name | Type |
+| --- | --- |
+| s | TypeDefinition |
+
+### get_storage_size
+
+```rust
+get_storage_size(typ);
+```
+
+#### Parameters
+| Name | Type |
+| --- | --- |
+| typ | Type |
+
+### module_has_storage
+
+```rust
+module_has_storage(m);
+```
+
+#### Parameters
+| Name | Type |
+| --- | --- |
+| m | Module |
+
+### module_has_initializer
+
+```rust
+module_has_initializer(m);
+```
+
+#### Parameters
+| Name | Type |
+| --- | --- |
+| m | Module |
+
+### is_note
+
+```rust
+is_note(typ);
+```
+
+#### Parameters
+| Name | Type |
+| --- | --- |
+| typ | Type |
+
+### get_trait_impl_method
+
+```rust
+get_trait_impl_method(typ, target_trait, target_method, );
+```
+
+#### Parameters
+| Name | Type |
+| --- | --- |
+| typ | Type |
+| target_trait | Quoted |
+| target_method | Quoted |
+| | |
+
diff --git a/docs/versioned_docs/version-v0.82.2-alpha-testnet.5/developers/reference/smart_contract_reference/aztec-nr/aztec/messaging.md b/docs/versioned_docs/version-v0.82.2-alpha-testnet.5/developers/reference/smart_contract_reference/aztec-nr/aztec/messaging.md
new file mode 100644
index 000000000000..0e616e73807b
--- /dev/null
+++ b/docs/versioned_docs/version-v0.82.2-alpha-testnet.5/developers/reference/smart_contract_reference/aztec-nr/aztec/messaging.md
@@ -0,0 +1,21 @@
+## Standalone Functions
+
+### process_l1_to_l2_message
+
+```rust
+process_l1_to_l2_message(l1_to_l2_root, contract_address, portal_contract_address, chain_id, version, content, secret, leaf_index, );
+```
+
+#### Parameters
+| Name | Type |
+| --- | --- |
+| l1_to_l2_root | Field |
+| contract_address | AztecAddress |
+| portal_contract_address | EthAddress |
+| chain_id | Field |
+| version | Field |
+| content | Field |
+| secret | Field |
+| leaf_index | Field |
+| | |
+
diff --git a/docs/versioned_docs/version-v0.82.2-alpha-testnet.5/developers/reference/smart_contract_reference/aztec-nr/aztec/note/lifecycle.md b/docs/versioned_docs/version-v0.82.2-alpha-testnet.5/developers/reference/smart_contract_reference/aztec-nr/aztec/note/lifecycle.md
new file mode 100644
index 000000000000..33c1f7e97622
--- /dev/null
+++ b/docs/versioned_docs/version-v0.82.2-alpha-testnet.5/developers/reference/smart_contract_reference/aztec-nr/aztec/note/lifecycle.md
@@ -0,0 +1,46 @@
+## Standalone Functions
+
+### create_note
+
+```rust
+create_note(context, storage_slot, note, );
+```
+
+#### Parameters
+| Name | Type |
+| --- | --- |
+| context | &mut PrivateContext |
+| storage_slot | Field |
+| note | Note |
+| | |
+
+### destroy_note
+
+```rust
+destroy_note(context, retrieved_note, storage_slot, );
+```
+
+Note: This function is currently totally unused.
+
+#### Parameters
+| Name | Type |
+| --- | --- |
+| context | &mut PrivateContext |
+| retrieved_note | RetrievedNote<Note> |
+| storage_slot | Field |
+| | |
+
+### destroy_note_unsafe
+
+```rust
+destroy_note_unsafe(context, retrieved_note, note_hash_for_read_request, );
+```
+
+#### Parameters
+| Name | Type |
+| --- | --- |
+| context | &mut PrivateContext |
+| retrieved_note | RetrievedNote<Note> |
+| note_hash_for_read_request | Field |
+| | |
+
diff --git a/docs/versioned_docs/version-v0.82.2-alpha-testnet.5/developers/reference/smart_contract_reference/aztec-nr/aztec/note/note_emission.md b/docs/versioned_docs/version-v0.82.2-alpha-testnet.5/developers/reference/smart_contract_reference/aztec-nr/aztec/note/note_emission.md
new file mode 100644
index 000000000000..8cd2242b4175
--- /dev/null
+++ b/docs/versioned_docs/version-v0.82.2-alpha-testnet.5/developers/reference/smart_contract_reference/aztec-nr/aztec/note/note_emission.md
@@ -0,0 +1,72 @@
+## Standalone Functions
+
+### new
+
+```rust
+new(note, storage_slot, note_hash_counter);
+```
+
+#### Parameters
+| Name | Type |
+| --- | --- |
+| note | Note |
+| storage_slot | Field |
+| note_hash_counter | u32 |
+
+### emit
+
+```rust
+emit(self, _emit);
+```
+
+#### Parameters
+| Name | Type |
+| --- | --- |
+| self | |
+| _emit | fn[Env](Self |
+
+### discard
+
+```rust
+discard(_self);
+```
+
+#### Parameters
+| Name | Type |
+| --- | --- |
+| _self | Self |
+
+### new
+
+```rust
+new(emission);
+```
+
+#### Parameters
+| Name | Type |
+| --- | --- |
+| emission | Option<NoteEmission<Note>> |
+
+### emit
+
+```rust
+emit(self, _emit);
+```
+
+#### Parameters
+| Name | Type |
+| --- | --- |
+| self | |
+| _emit | fn[Env](NoteEmission<Note> |
+
+### discard
+
+```rust
+discard(_self);
+```
+
+#### Parameters
+| Name | Type |
+| --- | --- |
+| _self | Self |
+
diff --git a/docs/versioned_docs/version-v0.82.2-alpha-testnet.5/developers/reference/smart_contract_reference/aztec-nr/aztec/note/note_field.md b/docs/versioned_docs/version-v0.82.2-alpha-testnet.5/developers/reference/smart_contract_reference/aztec-nr/aztec/note/note_field.md
new file mode 100644
index 000000000000..742217a673e3
--- /dev/null
+++ b/docs/versioned_docs/version-v0.82.2-alpha-testnet.5/developers/reference/smart_contract_reference/aztec-nr/aztec/note/note_field.md
@@ -0,0 +1,10 @@
+# NoteField
+
+Used by macros when generating note export.
+
+## Fields
+| Field | Type |
+| --- | --- |
+| pub index | u32 |
+| pub nullable | bool |
+
diff --git a/docs/versioned_docs/version-v0.82.2-alpha-testnet.5/developers/reference/smart_contract_reference/aztec-nr/aztec/note/note_getter.md b/docs/versioned_docs/version-v0.82.2-alpha-testnet.5/developers/reference/smart_contract_reference/aztec-nr/aztec/note/note_getter.md
new file mode 100644
index 000000000000..d20a71e3d8cf
--- /dev/null
+++ b/docs/versioned_docs/version-v0.82.2-alpha-testnet.5/developers/reference/smart_contract_reference/aztec-nr/aztec/note/note_getter.md
@@ -0,0 +1,162 @@
+## Standalone Functions
+
+### extract_property_value_from_selector
+
+```rust
+extract_property_value_from_selector(packed_note, selector, );
+```
+
+#### Parameters
+| Name | Type |
+| --- | --- |
+| packed_note | [Field; N] |
+| selector | PropertySelector |
+| | |
+
+### check_packed_note
+
+```rust
+check_packed_note(packed_note, selects, N>);
+```
+
+#### Parameters
+| Name | Type |
+| --- | --- |
+| packed_note | [Field; N] |
+| selects | BoundedVec<Option<Select> |
+| N> | |
+
+### check_notes_order
+
+```rust
+check_notes_order(fields_0, fields_1, sorts, N>, );
+```
+
+#### Parameters
+| Name | Type |
+| --- | --- |
+| fields_0 | [Field; N] |
+| fields_1 | [Field; N] |
+| sorts | BoundedVec<Option<Sort> |
+| N> | |
+| | |
+
+### get_note
+
+```rust
+get_note(context, storage_slot, );
+```
+
+#### Parameters
+| Name | Type |
+| --- | --- |
+| context | &mut PrivateContext |
+| storage_slot | Field |
+| | |
+
+### get_notes
+
+```rust
+get_notes(context, storage_slot, options, N, PREPROCESSOR_ARGS, FILTER_ARGS>, );
+```
+
+/ abstractions such as aztec-nr's state variables should be used instead.
+
+#### Parameters
+| Name | Type |
+| --- | --- |
+| context | &mut PrivateContext |
+| storage_slot | Field |
+| options | NoteGetterOptions<Note |
+| N | |
+| PREPROCESSOR_ARGS | |
+| FILTER_ARGS> | |
+| | |
+
+### apply_preprocessor
+
+```rust
+apply_preprocessor(notes, preprocessor, PREPROCESSOR_ARGS);
+```
+
+#### Parameters
+| Name | Type |
+| --- | --- |
+| notes | [Option<Note>; MAX_NOTE_HASH_READ_REQUESTS_PER_CALL] |
+| preprocessor | fn([Option<Note>; MAX_NOTE_HASH_READ_REQUESTS_PER_CALL] |
+| PREPROCESSOR_ARGS | |
+
+### constrain_get_notes_internal
+
+```rust
+constrain_get_notes_internal(context, storage_slot, opt_notes, options, N, PREPROCESSOR_ARGS, FILTER_ARGS>, );
+```
+
+#### Parameters
+| Name | Type |
+| --- | --- |
+| context | &mut PrivateContext |
+| storage_slot | Field |
+| opt_notes | [Option<RetrievedNote<Note>>; MAX_NOTE_HASH_READ_REQUESTS_PER_CALL] |
+| options | NoteGetterOptions<Note |
+| N | |
+| PREPROCESSOR_ARGS | |
+| FILTER_ARGS> | |
+| | |
+
+### get_note_internal
+
+```rust
+get_note_internal(storage_slot);
+```
+
+#### Parameters
+| Name | Type |
+| --- | --- |
+| storage_slot | Field |
+
+### get_notes_internal
+
+```rust
+get_notes_internal(storage_slot, options, N, PREPROCESSOR_ARGS, FILTER_ARGS>, );
+```
+
+#### Parameters
+| Name | Type |
+| --- | --- |
+| storage_slot | Field |
+| options | NoteGetterOptions<Note |
+| N | |
+| PREPROCESSOR_ARGS | |
+| FILTER_ARGS> | |
+| | |
+
+### view_notes
+
+```rust
+view_notes(storage_slot, options, N>, );
+```
+
+#### Parameters
+| Name | Type |
+| --- | --- |
+| storage_slot | Field |
+| options | NoteViewerOptions<Note |
+| N> | |
+| | |
+
+### flatten_options
+
+```rust
+flatten_options(selects, N>, sorts, N>, );
+```
+
+#### Parameters
+| Name | Type |
+| --- | --- |
+| selects | BoundedVec<Option<Select> |
+| N> | |
+| sorts | BoundedVec<Option<Sort> |
+| N> | |
+| | |
+
diff --git a/docs/versioned_docs/version-v0.82.2-alpha-testnet.5/developers/reference/smart_contract_reference/aztec-nr/aztec/note/note_getter/test.md b/docs/versioned_docs/version-v0.82.2-alpha-testnet.5/developers/reference/smart_contract_reference/aztec-nr/aztec/note/note_getter/test.md
new file mode 100644
index 000000000000..71318a2a7526
--- /dev/null
+++ b/docs/versioned_docs/version-v0.82.2-alpha-testnet.5/developers/reference/smart_contract_reference/aztec-nr/aztec/note/note_getter/test.md
@@ -0,0 +1,115 @@
+## Standalone Functions
+
+### setup
+
+```rust
+setup();
+```
+
+Takes no parameters.
+
+### build_valid_retrieved_note
+
+```rust
+build_valid_retrieved_note(value);
+```
+
+#### Parameters
+| Name | Type |
+| --- | --- |
+| value | Field |
+
+### assert_equivalent_vec_and_array
+
+```rust
+assert_equivalent_vec_and_array(vec, N>, arr, );
+```
+
+#### Parameters
+| Name | Type |
+| --- | --- |
+| vec | BoundedVec<T |
+| N> | |
+| arr | [Option<T>; N] |
+| | |
+
+### processes_single_note
+
+```rust
+processes_single_note();
+```
+
+Takes no parameters.
+
+### processes_many_notes
+
+```rust
+processes_many_notes();
+```
+
+Takes no parameters.
+
+### collapses_notes_at_the_beginning_of_the_array
+
+```rust
+collapses_notes_at_the_beginning_of_the_array();
+```
+
+Takes no parameters.
+
+### can_return_zero_notes
+
+```rust
+can_return_zero_notes();
+```
+
+Takes no parameters.
+
+### rejects_mote_notes_than_limit
+
+```rust
+rejects_mote_notes_than_limit();
+```
+
+Takes no parameters.
+
+### applies_filter_before_constraining
+
+```rust
+applies_filter_before_constraining();
+```
+
+Takes no parameters.
+
+### rejects_mismatched_address
+
+```rust
+rejects_mismatched_address();
+```
+
+Takes no parameters.
+
+### rejects_mismatched_selector
+
+```rust
+rejects_mismatched_selector();
+```
+
+Takes no parameters.
+
+### rejects_mismatched_desc_sort_order
+
+```rust
+rejects_mismatched_desc_sort_order();
+```
+
+Takes no parameters.
+
+### rejects_mismatched_asc_sort_order
+
+```rust
+rejects_mismatched_asc_sort_order();
+```
+
+Takes no parameters.
+
diff --git a/docs/versioned_docs/version-v0.82.2-alpha-testnet.5/developers/reference/smart_contract_reference/aztec-nr/aztec/note/note_getter_options.md b/docs/versioned_docs/version-v0.82.2-alpha-testnet.5/developers/reference/smart_contract_reference/aztec-nr/aztec/note/note_getter_options.md
new file mode 100644
index 000000000000..312d395739fb
--- /dev/null
+++ b/docs/versioned_docs/version-v0.82.2-alpha-testnet.5/developers/reference/smart_contract_reference/aztec-nr/aztec/note/note_getter_options.md
@@ -0,0 +1,178 @@
+# PropertySelector
+
+## Fields
+| Field | Type |
+| --- | --- |
+| pub index | u8, // index of the field in the serialized note array |
+| pub offset | u8, // offset in the byte representation of the field (selected with index above) from which to reading |
+| pub length | u8, // number of bytes to read after the offset |
+
+# Select
+
+## Fields
+| Field | Type |
+| --- | --- |
+| pub(crate) property_selector | PropertySelector |
+| pub(crate) comparator | u8 |
+| pub(crate) value | Field |
+
+## Methods
+
+### new
+
+The selected property will be the left hand side and value the right hand side of the operation, so e.g. the object created by new(property, Comparator.GT, value) represents 'property > value'.
+
+```rust
+Select::new(property_selector, comparator, value);
+```
+
+#### Parameters
+| Name | Type |
+| --- | --- |
+| property_selector | PropertySelector |
+| comparator | u8 |
+| value | Field |
+
+# SortOrderEnum
+
+## Fields
+| Field | Type |
+| --- | --- |
+| pub DESC | u8 |
+| pub ASC | u8 |
+
+# Sort
+
+## Fields
+| Field | Type |
+| --- | --- |
+| pub(crate) property_selector | PropertySelector |
+| pub(crate) order | u8 |
+
+## Methods
+
+### new
+
+```rust
+Sort::new(property_selector, order);
+```
+
+#### Parameters
+| Name | Type |
+| --- | --- |
+| property_selector | PropertySelector |
+| order | u8 |
+
+# NoteStatusEnum
+
+## Fields
+| Field | Type |
+| --- | --- |
+| pub ACTIVE | u8 |
+| pub ACTIVE_OR_NULLIFIED | u8 |
+
+## Standalone Functions
+
+### return_all_notes
+
+```rust
+return_all_notes(notes, _p, );
+```
+
+This is the default filter and preprocessor, which does nothing
+
+#### Parameters
+| Name | Type |
+| --- | --- |
+| notes | [Option<RetrievedNote<Note>>; MAX_NOTE_HASH_READ_REQUESTS_PER_CALL] |
+| _p | Field |
+| | |
+
+### select
+
+```rust
+select(&mut self, property_selector, comparator, value, );
+```
+
+#### Parameters
+| Name | Type |
+| --- | --- |
+| &mut self | |
+| property_selector | PropertySelector |
+| comparator | u8 |
+| value | T |
+| | |
+
+### sort
+
+```rust
+sort(&mut self, property_selector, order);
+```
+
+#### Parameters
+| Name | Type |
+| --- | --- |
+| &mut self | |
+| property_selector | PropertySelector |
+| order | u8 |
+
+### set_limit
+
+```rust
+set_limit(&mut self, limit);
+```
+
+#### Parameters
+| Name | Type |
+| --- | --- |
+| &mut self | |
+| limit | u32 |
+
+### set_offset
+
+```rust
+set_offset(&mut self, offset);
+```
+
+#### Parameters
+| Name | Type |
+| --- | --- |
+| &mut self | |
+| offset | u32 |
+
+### set_status
+
+```rust
+set_status(&mut self, status);
+```
+
+#### Parameters
+| Name | Type |
+| --- | --- |
+| &mut self | |
+| status | u8 |
+
+### with_preprocessor
+
+```rust
+with_preprocessor(preprocessor, PREPROCESSOR_ARGS);
+```
+
+#### Parameters
+| Name | Type |
+| --- | --- |
+| preprocessor | fn([Option<RetrievedNote<Note>>; MAX_NOTE_HASH_READ_REQUESTS_PER_CALL] |
+| PREPROCESSOR_ARGS | |
+
+### with_filter
+
+```rust
+with_filter(filter, FILTER_ARGS);
+```
+
+#### Parameters
+| Name | Type |
+| --- | --- |
+| filter | fn([Option<RetrievedNote<Note>>; MAX_NOTE_HASH_READ_REQUESTS_PER_CALL] |
+| FILTER_ARGS | |
+
diff --git a/docs/versioned_docs/version-v0.82.2-alpha-testnet.5/developers/reference/smart_contract_reference/aztec-nr/aztec/note/note_interface.md b/docs/versioned_docs/version-v0.82.2-alpha-testnet.5/developers/reference/smart_contract_reference/aztec-nr/aztec/note/note_interface.md
new file mode 100644
index 000000000000..e504c595eb76
--- /dev/null
+++ b/docs/versioned_docs/version-v0.82.2-alpha-testnet.5/developers/reference/smart_contract_reference/aztec-nr/aztec/note/note_interface.md
@@ -0,0 +1,71 @@
+## Standalone Functions
+
+### get_id
+
+```rust
+get_id();
+```
+
+Takes no parameters.
+
+### compute_note_hash
+
+```rust
+compute_note_hash(self, storage_slot);
+```
+
+#### Parameters
+| Name | Type |
+| --- | --- |
+| self | |
+| storage_slot | Field |
+
+### compute_nullifier
+
+```rust
+compute_nullifier(self, context, note_hash_for_nullify);
+```
+
+#### Parameters
+| Name | Type |
+| --- | --- |
+| self | |
+| context | &mut PrivateContext |
+| note_hash_for_nullify | Field |
+
+### compute_nullifier_unconstrained
+
+```rust
+compute_nullifier_unconstrained(self, note_hash_for_nullify);
+```
+
+#### Parameters
+| Name | Type |
+| --- | --- |
+| self | |
+| note_hash_for_nullify | Field |
+
+### properties
+
+```rust
+properties();
+```
+
+Takes no parameters.
+
+### setup_payload
+
+```rust
+setup_payload();
+```
+
+Takes no parameters.
+
+### finalization_payload
+
+```rust
+finalization_payload();
+```
+
+Takes no parameters.
+
diff --git a/docs/versioned_docs/version-v0.82.2-alpha-testnet.5/developers/reference/smart_contract_reference/aztec-nr/aztec/note/note_metadata.md b/docs/versioned_docs/version-v0.82.2-alpha-testnet.5/developers/reference/smart_contract_reference/aztec-nr/aztec/note/note_metadata.md
new file mode 100644
index 000000000000..b718301b1bbf
--- /dev/null
+++ b/docs/versioned_docs/version-v0.82.2-alpha-testnet.5/developers/reference/smart_contract_reference/aztec-nr/aztec/note/note_metadata.md
@@ -0,0 +1,226 @@
+# NoteStageEnum
+
+## Fields
+| Field | Type |
+| --- | --- |
+| PENDING_SAME_PHASE | u8 |
+| PENDING_PREVIOUS_PHASE | u8 |
+| SETTLED | u8 |
+
+# NoteMetadata
+
+## Fields
+| Field | Type |
+| --- | --- |
+| stage | u8 |
+| maybe_nonce | Field |
+
+## Methods
+
+### from_raw_data
+
+/ Constructs a `NoteMetadata` object from optional note hash counter and nonce. Both a zero note hash counter and / a zero nonce are invalid, so those are used to signal non-existent values.
+
+```rust
+NoteMetadata::from_raw_data(nonzero_note_hash_counter, maybe_nonce);
+```
+
+#### Parameters
+| Name | Type |
+| --- | --- |
+| nonzero_note_hash_counter | bool |
+| maybe_nonce | Field |
+
+### is_pending_same_phase
+
+/ Returns true if the note is pending **and** from the same phase, i.e. if it's been created in the current / transaction during the current execution phase (either non-revertible or revertible).
+
+```rust
+NoteMetadata::is_pending_same_phase(self);
+```
+
+#### Parameters
+| Name | Type |
+| --- | --- |
+| self | |
+
+### is_pending_previous_phase
+
+/ Returns true if the note is pending **and** from the previous phase, i.e. if it's been created in the current / transaction during an execution phase prior to the current one. Because private execution only has two phases / with strict ordering, this implies that the note was created in the non-revertible phase, and that the current / phase is the revertible phase.
+
+```rust
+NoteMetadata::is_pending_previous_phase(self);
+```
+
+#### Parameters
+| Name | Type |
+| --- | --- |
+| self | |
+
+### is_settled
+
+/ Returns true if the note is settled, i.e. if it's been created in a prior transaction and is therefore already / in the note hash tree.
+
+```rust
+NoteMetadata::is_settled(self);
+```
+
+#### Parameters
+| Name | Type |
+| --- | --- |
+| self | |
+
+### to_pending_same_phase
+
+/ Asserts that the metadata is that of a pending note from the same phase and converts it accordingly.
+
+```rust
+NoteMetadata::to_pending_same_phase(self);
+```
+
+#### Parameters
+| Name | Type |
+| --- | --- |
+| self | |
+
+### to_pending_previous_phase
+
+/ Asserts that the metadata is that of a pending note from a previous phase and converts it accordingly.
+
+```rust
+NoteMetadata::to_pending_previous_phase(self);
+```
+
+#### Parameters
+| Name | Type |
+| --- | --- |
+| self | |
+
+### to_settled
+
+/ Asserts that the metadata is that of a settled note and converts it accordingly.
+
+```rust
+NoteMetadata::to_settled(self);
+```
+
+#### Parameters
+| Name | Type |
+| --- | --- |
+| self | |
+
+# PendingSamePhaseNoteMetadata
+
+/ The metadata required to both prove a note's existence and destroy it, by computing the correct note hash for kernel / read requests, as well as the correct nullifier to avoid double-spends. / / This represents a pending same phase note, i.e. a note that was created in the transaction that is currently being / executed during the current execution phase (either non-revertible or revertible).
+
+## Methods
+
+### new
+
+```rust
+PendingSamePhaseNoteMetadata::new();
+```
+
+Takes no parameters.
+
+# PendingPreviousPhaseNoteMetadata
+
+/ The metadata required to both prove a note's existence and destroy it, by computing the correct note hash for kernel / read requests, as well as the correct nullifier to avoid double-spends. / / This represents a pending previous phase note, i.e. a note that was created in the transaction that is currently / being executed, during the previous execution phase. Because there are only two phases and their order is always the / same (first non-revertible and then revertible) this implies that the note was created in the non-revertible phase, / and that the current phase is the revertible phase.
+
+## Fields
+| Field | Type |
+| --- | --- |
+| nonce | Field |
+
+## Methods
+
+### new
+
+```rust
+PendingPreviousPhaseNoteMetadata::new(nonce);
+```
+
+#### Parameters
+| Name | Type |
+| --- | --- |
+| nonce | Field |
+
+### nonce
+
+```rust
+PendingPreviousPhaseNoteMetadata::nonce(self);
+```
+
+#### Parameters
+| Name | Type |
+| --- | --- |
+| self | |
+
+# SettledNoteMetadata
+
+/ The metadata required to both prove a note's existence and destroy it, by computing the correct note hash for kernel / read requests, as well as the correct nullifier to avoid double-spends. / / This represents a settled note, i.e. a note that was created in a prior transaction and is therefore already in the / note hash tree.
+
+## Fields
+| Field | Type |
+| --- | --- |
+| nonce | Field |
+
+## Methods
+
+### new
+
+```rust
+SettledNoteMetadata::new(nonce);
+```
+
+#### Parameters
+| Name | Type |
+| --- | --- |
+| nonce | Field |
+
+### nonce
+
+```rust
+SettledNoteMetadata::nonce(self);
+```
+
+#### Parameters
+| Name | Type |
+| --- | --- |
+| self | |
+
+## Standalone Functions
+
+### from
+
+```rust
+from(_value);
+```
+
+#### Parameters
+| Name | Type |
+| --- | --- |
+| _value | PendingSamePhaseNoteMetadata |
+
+### from
+
+```rust
+from(value);
+```
+
+#### Parameters
+| Name | Type |
+| --- | --- |
+| value | PendingPreviousPhaseNoteMetadata |
+
+### from
+
+```rust
+from(value);
+```
+
+#### Parameters
+| Name | Type |
+| --- | --- |
+| value | SettledNoteMetadata |
+
diff --git a/docs/versioned_docs/version-v0.82.2-alpha-testnet.5/developers/reference/smart_contract_reference/aztec-nr/aztec/note/note_viewer_options.md b/docs/versioned_docs/version-v0.82.2-alpha-testnet.5/developers/reference/smart_contract_reference/aztec-nr/aztec/note/note_viewer_options.md
new file mode 100644
index 000000000000..ca361ad5b74c
--- /dev/null
+++ b/docs/versioned_docs/version-v0.82.2-alpha-testnet.5/developers/reference/smart_contract_reference/aztec-nr/aztec/note/note_viewer_options.md
@@ -0,0 +1,74 @@
+## Standalone Functions
+
+### new
+
+```rust
+new();
+```
+
+Takes no parameters.
+
+### select
+
+```rust
+select(&mut self, property_selector, comparator, value, );
+```
+
+#### Parameters
+| Name | Type |
+| --- | --- |
+| &mut self | |
+| property_selector | PropertySelector |
+| comparator | u8 |
+| value | T |
+| | |
+
+### sort
+
+```rust
+sort(&mut self, property_selector, order);
+```
+
+#### Parameters
+| Name | Type |
+| --- | --- |
+| &mut self | |
+| property_selector | PropertySelector |
+| order | u8 |
+
+### set_limit
+
+```rust
+set_limit(&mut self, limit);
+```
+
+#### Parameters
+| Name | Type |
+| --- | --- |
+| &mut self | |
+| limit | u32 |
+
+### set_offset
+
+```rust
+set_offset(&mut self, offset);
+```
+
+#### Parameters
+| Name | Type |
+| --- | --- |
+| &mut self | |
+| offset | u32 |
+
+### set_status
+
+```rust
+set_status(&mut self, status);
+```
+
+#### Parameters
+| Name | Type |
+| --- | --- |
+| &mut self | |
+| status | u8 |
+
diff --git a/docs/versioned_docs/version-v0.82.2-alpha-testnet.5/developers/reference/smart_contract_reference/aztec-nr/aztec/note/retrieved_note.md b/docs/versioned_docs/version-v0.82.2-alpha-testnet.5/developers/reference/smart_contract_reference/aztec-nr/aztec/note/retrieved_note.md
new file mode 100644
index 000000000000..5bdb3c70e14e
--- /dev/null
+++ b/docs/versioned_docs/version-v0.82.2-alpha-testnet.5/developers/reference/smart_contract_reference/aztec-nr/aztec/note/retrieved_note.md
@@ -0,0 +1,13 @@
+## Standalone Functions
+
+### serialize
+
+```rust
+serialize(self);
+```
+
+#### Parameters
+| Name | Type |
+| --- | --- |
+| self | |
+
diff --git a/docs/versioned_docs/version-v0.82.2-alpha-testnet.5/developers/reference/smart_contract_reference/aztec-nr/aztec/note/utils.md b/docs/versioned_docs/version-v0.82.2-alpha-testnet.5/developers/reference/smart_contract_reference/aztec-nr/aztec/note/utils.md
new file mode 100644
index 000000000000..845eb9ed08d8
--- /dev/null
+++ b/docs/versioned_docs/version-v0.82.2-alpha-testnet.5/developers/reference/smart_contract_reference/aztec-nr/aztec/note/utils.md
@@ -0,0 +1,63 @@
+## Standalone Functions
+
+### compute_note_hash_for_read_request
+
+```rust
+compute_note_hash_for_read_request(retrieved_note, storage_slot, );
+```
+
+/ Returns the note hash that must be used to issue a private kernel read request for a note.
+
+#### Parameters
+| Name | Type |
+| --- | --- |
+| retrieved_note | RetrievedNote<Note> |
+| storage_slot | Field |
+| | |
+
+### compute_note_hash_for_nullify
+
+```rust
+compute_note_hash_for_nullify(retrieved_note, storage_slot, );
+```
+
+/ `NoteHash::compute_nullifier_unconstrained`.
+
+#### Parameters
+| Name | Type |
+| --- | --- |
+| retrieved_note | RetrievedNote<Note> |
+| storage_slot | Field |
+| | |
+
+### compute_note_hash_for_nullify_from_read_request
+
+```rust
+compute_note_hash_for_nullify_from_read_request(retrieved_note, note_hash_for_read_request, );
+```
+
+/ computed to reduce constraints by reusing this value.
+
+#### Parameters
+| Name | Type |
+| --- | --- |
+| retrieved_note | RetrievedNote<Note> |
+| note_hash_for_read_request | Field |
+| | |
+
+### compute_siloed_note_nullifier
+
+```rust
+compute_siloed_note_nullifier(retrieved_note, storage_slot, context, );
+```
+
+/ Computes a note's siloed nullifier, i.e. the one that will be inserted into the nullifier tree.
+
+#### Parameters
+| Name | Type |
+| --- | --- |
+| retrieved_note | RetrievedNote<Note> |
+| storage_slot | Field |
+| context | &mut PrivateContext |
+| | |
+
diff --git a/docs/versioned_docs/version-v0.82.2-alpha-testnet.5/developers/reference/smart_contract_reference/aztec-nr/aztec/oracle/aes128_decrypt.md b/docs/versioned_docs/version-v0.82.2-alpha-testnet.5/developers/reference/smart_contract_reference/aztec-nr/aztec/oracle/aes128_decrypt.md
new file mode 100644
index 000000000000..f10540e4696a
--- /dev/null
+++ b/docs/versioned_docs/version-v0.82.2-alpha-testnet.5/developers/reference/smart_contract_reference/aztec-nr/aztec/oracle/aes128_decrypt.md
@@ -0,0 +1,33 @@
+## Standalone Functions
+
+### aes128_decrypt_oracle
+
+```rust
+aes128_decrypt_oracle(ciphertext, N>, iv, sym_key, );
+```
+
+#### Parameters
+| Name | Type |
+| --- | --- |
+| ciphertext | BoundedVec<u8 |
+| N> | |
+| iv | [u8; 16] |
+| sym_key | [u8; 16] |
+| | |
+
+### aes_encrypt_then_decrypt
+
+```rust
+aes_encrypt_then_decrypt();
+```
+
+Takes no parameters.
+
+### aes_encrypt_then_decrypt_with_bad_sym_key_is_caught
+
+```rust
+aes_encrypt_then_decrypt_with_bad_sym_key_is_caught();
+```
+
+Takes no parameters.
+
diff --git a/docs/versioned_docs/version-v0.82.2-alpha-testnet.5/developers/reference/smart_contract_reference/aztec-nr/aztec/oracle/block_header.md b/docs/versioned_docs/version-v0.82.2-alpha-testnet.5/developers/reference/smart_contract_reference/aztec-nr/aztec/oracle/block_header.md
new file mode 100644
index 000000000000..1998a8e9c487
--- /dev/null
+++ b/docs/versioned_docs/version-v0.82.2-alpha-testnet.5/developers/reference/smart_contract_reference/aztec-nr/aztec/oracle/block_header.md
@@ -0,0 +1,59 @@
+## Standalone Functions
+
+### get_block_header_at_oracle
+
+```rust
+get_block_header_at_oracle(_block_number);
+```
+
+#### Parameters
+| Name | Type |
+| --- | --- |
+| _block_number | u32 |
+
+### get_block_header_at_internal
+
+```rust
+get_block_header_at_internal(block_number);
+```
+
+#### Parameters
+| Name | Type |
+| --- | --- |
+| block_number | u32 |
+
+### get_block_header_at
+
+```rust
+get_block_header_at(block_number, context);
+```
+
+#### Parameters
+| Name | Type |
+| --- | --- |
+| block_number | u32 |
+| context | PrivateContext |
+
+### constrain_get_block_header_at_internal
+
+```rust
+constrain_get_block_header_at_internal(header_hint, block_number, last_archive_block_number, last_archive_root, );
+```
+
+#### Parameters
+| Name | Type |
+| --- | --- |
+| header_hint | BlockHeader |
+| block_number | u32 |
+| last_archive_block_number | u32 |
+| last_archive_root | Field |
+| | |
+
+### fetching_a_valid_but_different_header_should_fail
+
+```rust
+fetching_a_valid_but_different_header_should_fail();
+```
+
+Takes no parameters.
+
diff --git a/docs/versioned_docs/version-v0.82.2-alpha-testnet.5/developers/reference/smart_contract_reference/aztec-nr/aztec/oracle/call_private_function.md b/docs/versioned_docs/version-v0.82.2-alpha-testnet.5/developers/reference/smart_contract_reference/aztec-nr/aztec/oracle/call_private_function.md
new file mode 100644
index 000000000000..c6b7fff67fbe
--- /dev/null
+++ b/docs/versioned_docs/version-v0.82.2-alpha-testnet.5/developers/reference/smart_contract_reference/aztec-nr/aztec/oracle/call_private_function.md
@@ -0,0 +1,34 @@
+## Standalone Functions
+
+### call_private_function_oracle
+
+```rust
+call_private_function_oracle(_contract_address, _function_selector, _args_hash, _start_side_effect_counter, _is_static_call, );
+```
+
+#### Parameters
+| Name | Type |
+| --- | --- |
+| _contract_address | AztecAddress |
+| _function_selector | FunctionSelector |
+| _args_hash | Field |
+| _start_side_effect_counter | u32 |
+| _is_static_call | bool |
+| | |
+
+### call_private_function_internal
+
+```rust
+call_private_function_internal(contract_address, function_selector, args_hash, start_side_effect_counter, is_static_call, );
+```
+
+#### Parameters
+| Name | Type |
+| --- | --- |
+| contract_address | AztecAddress |
+| function_selector | FunctionSelector |
+| args_hash | Field |
+| start_side_effect_counter | u32 |
+| is_static_call | bool |
+| | |
+
diff --git a/docs/versioned_docs/version-v0.82.2-alpha-testnet.5/developers/reference/smart_contract_reference/aztec-nr/aztec/oracle/capsules.md b/docs/versioned_docs/version-v0.82.2-alpha-testnet.5/developers/reference/smart_contract_reference/aztec-nr/aztec/oracle/capsules.md
new file mode 100644
index 000000000000..e786b2c4ea10
--- /dev/null
+++ b/docs/versioned_docs/version-v0.82.2-alpha-testnet.5/developers/reference/smart_contract_reference/aztec-nr/aztec/oracle/capsules.md
@@ -0,0 +1,221 @@
+## Standalone Functions
+
+### store
+
+```rust
+store(contract_address, slot, value);
+```
+
+#### Parameters
+| Name | Type |
+| --- | --- |
+| contract_address | AztecAddress |
+| slot | Field |
+| value | T |
+
+### load
+
+```rust
+load(contract_address, slot);
+```
+
+#### Parameters
+| Name | Type |
+| --- | --- |
+| contract_address | AztecAddress |
+| slot | Field |
+
+### delete
+
+```rust
+delete(contract_address, slot);
+```
+
+#### Parameters
+| Name | Type |
+| --- | --- |
+| contract_address | AztecAddress |
+| slot | Field |
+
+### copy
+
+```rust
+copy(contract_address, src_slot, dst_slot, num_entries, );
+```
+
+#### Parameters
+| Name | Type |
+| --- | --- |
+| contract_address | AztecAddress |
+| src_slot | Field |
+| dst_slot | Field |
+| num_entries | u32 |
+| | |
+
+### store_oracle
+
+```rust
+store_oracle(contract_address, slot, values, );
+```
+
+#### Parameters
+| Name | Type |
+| --- | --- |
+| contract_address | AztecAddress |
+| slot | Field |
+| values | [Field; N] |
+| | |
+
+### load_oracle
+
+```rust
+load_oracle(contract_address, slot, array_len, );
+```
+
+#### Parameters
+| Name | Type |
+| --- | --- |
+| contract_address | AztecAddress |
+| slot | Field |
+| array_len | u32 |
+| | |
+
+### delete_oracle
+
+```rust
+delete_oracle(contract_address, slot);
+```
+
+#### Parameters
+| Name | Type |
+| --- | --- |
+| contract_address | AztecAddress |
+| slot | Field |
+
+### copy_oracle
+
+```rust
+copy_oracle(contract_address, src_slot, dst_slot, num_entries, );
+```
+
+#### Parameters
+| Name | Type |
+| --- | --- |
+| contract_address | AztecAddress |
+| src_slot | Field |
+| dst_slot | Field |
+| num_entries | u32 |
+| | |
+
+### setup
+
+```rust
+setup();
+```
+
+Takes no parameters.
+
+### stores_and_loads
+
+```rust
+stores_and_loads();
+```
+
+Takes no parameters.
+
+### store_overwrites
+
+```rust
+store_overwrites();
+```
+
+Takes no parameters.
+
+### loads_empty_slot
+
+```rust
+loads_empty_slot();
+```
+
+Takes no parameters.
+
+### deletes_stored_value
+
+```rust
+deletes_stored_value();
+```
+
+Takes no parameters.
+
+### deletes_empty_slot
+
+```rust
+deletes_empty_slot();
+```
+
+Takes no parameters.
+
+### copies_non_overlapping_values
+
+```rust
+copies_non_overlapping_values();
+```
+
+Takes no parameters.
+
+### copies_overlapping_values_with_src_ahead
+
+```rust
+copies_overlapping_values_with_src_ahead();
+```
+
+Takes no parameters.
+
+### copies_overlapping_values_with_dst_ahead
+
+```rust
+copies_overlapping_values_with_dst_ahead();
+```
+
+Takes no parameters.
+
+### cannot_copy_empty_values
+
+```rust
+cannot_copy_empty_values();
+```
+
+Takes no parameters.
+
+### cannot_store_other_contract
+
+```rust
+cannot_store_other_contract();
+```
+
+Takes no parameters.
+
+### cannot_load_other_contract
+
+```rust
+cannot_load_other_contract();
+```
+
+Takes no parameters.
+
+### cannot_delete_other_contract
+
+```rust
+cannot_delete_other_contract();
+```
+
+Takes no parameters.
+
+### cannot_copy_other_contract
+
+```rust
+cannot_copy_other_contract();
+```
+
+Takes no parameters.
+
diff --git a/docs/versioned_docs/version-v0.82.2-alpha-testnet.5/developers/reference/smart_contract_reference/aztec-nr/aztec/oracle/enqueue_public_function_call.md b/docs/versioned_docs/version-v0.82.2-alpha-testnet.5/developers/reference/smart_contract_reference/aztec-nr/aztec/oracle/enqueue_public_function_call.md
new file mode 100644
index 000000000000..422c1ec7bb92
--- /dev/null
+++ b/docs/versioned_docs/version-v0.82.2-alpha-testnet.5/developers/reference/smart_contract_reference/aztec-nr/aztec/oracle/enqueue_public_function_call.md
@@ -0,0 +1,125 @@
+## Standalone Functions
+
+### notify_enqueued_public_function_call_oracle
+
+```rust
+notify_enqueued_public_function_call_oracle(_contract_address, _calldata_hash, _side_effect_counter, _is_static_call, );
+```
+
+#### Parameters
+| Name | Type |
+| --- | --- |
+| _contract_address | AztecAddress |
+| _calldata_hash | Field |
+| _side_effect_counter | u32 |
+| _is_static_call | bool |
+| | |
+
+### notify_enqueued_public_function_call_wrapper
+
+```rust
+notify_enqueued_public_function_call_wrapper(contract_address, calldata_hash, side_effect_counter, is_static_call, );
+```
+
+#### Parameters
+| Name | Type |
+| --- | --- |
+| contract_address | AztecAddress |
+| calldata_hash | Field |
+| side_effect_counter | u32 |
+| is_static_call | bool |
+| | |
+
+### notify_enqueued_public_function_call
+
+```rust
+notify_enqueued_public_function_call(contract_address, calldata_hash, side_effect_counter, is_static_call, );
+```
+
+#### Parameters
+| Name | Type |
+| --- | --- |
+| contract_address | AztecAddress |
+| calldata_hash | Field |
+| side_effect_counter | u32 |
+| is_static_call | bool |
+| | |
+
+### notify_set_public_teardown_function_call_oracle
+
+```rust
+notify_set_public_teardown_function_call_oracle(_contract_address, _calldata_hash, _side_effect_counter, _is_static_call, );
+```
+
+#### Parameters
+| Name | Type |
+| --- | --- |
+| _contract_address | AztecAddress |
+| _calldata_hash | Field |
+| _side_effect_counter | u32 |
+| _is_static_call | bool |
+| | |
+
+### notify_set_public_teardown_function_call_wrapper
+
+```rust
+notify_set_public_teardown_function_call_wrapper(contract_address, calldata_hash, side_effect_counter, is_static_call, );
+```
+
+#### Parameters
+| Name | Type |
+| --- | --- |
+| contract_address | AztecAddress |
+| calldata_hash | Field |
+| side_effect_counter | u32 |
+| is_static_call | bool |
+| | |
+
+### notify_set_public_teardown_function_call
+
+```rust
+notify_set_public_teardown_function_call(contract_address, calldata_hash, side_effect_counter, is_static_call, );
+```
+
+#### Parameters
+| Name | Type |
+| --- | --- |
+| contract_address | AztecAddress |
+| calldata_hash | Field |
+| side_effect_counter | u32 |
+| is_static_call | bool |
+| | |
+
+### notify_set_min_revertible_side_effect_counter
+
+```rust
+notify_set_min_revertible_side_effect_counter(counter);
+```
+
+#### Parameters
+| Name | Type |
+| --- | --- |
+| counter | u32 |
+
+### notify_set_min_revertible_side_effect_counter_oracle_wrapper
+
+```rust
+notify_set_min_revertible_side_effect_counter_oracle_wrapper(counter);
+```
+
+#### Parameters
+| Name | Type |
+| --- | --- |
+| counter | u32 |
+
+### notify_set_min_revertible_side_effect_counter_oracle
+
+```rust
+notify_set_min_revertible_side_effect_counter_oracle(_counter);
+```
+
+#### Parameters
+| Name | Type |
+| --- | --- |
+| _counter | u32 |
+
diff --git a/docs/versioned_docs/version-v0.82.2-alpha-testnet.5/developers/reference/smart_contract_reference/aztec-nr/aztec/oracle/execution.md b/docs/versioned_docs/version-v0.82.2-alpha-testnet.5/developers/reference/smart_contract_reference/aztec-nr/aztec/oracle/execution.md
new file mode 100644
index 000000000000..bf8e1bfd579c
--- /dev/null
+++ b/docs/versioned_docs/version-v0.82.2-alpha-testnet.5/developers/reference/smart_contract_reference/aztec-nr/aztec/oracle/execution.md
@@ -0,0 +1,66 @@
+## Standalone Functions
+
+### get_contract_address_oracle
+
+```rust
+get_contract_address_oracle();
+```
+
+Takes no parameters.
+
+### get_block_number_oracle
+
+```rust
+get_block_number_oracle();
+```
+
+Takes no parameters.
+
+### get_chain_id_oracle
+
+```rust
+get_chain_id_oracle();
+```
+
+Takes no parameters.
+
+### get_version_oracle
+
+```rust
+get_version_oracle();
+```
+
+Takes no parameters.
+
+### get_contract_address
+
+```rust
+get_contract_address();
+```
+
+Takes no parameters.
+
+### get_block_number
+
+```rust
+get_block_number();
+```
+
+Takes no parameters.
+
+### get_chain_id
+
+```rust
+get_chain_id();
+```
+
+Takes no parameters.
+
+### get_version
+
+```rust
+get_version();
+```
+
+Takes no parameters.
+
diff --git a/docs/versioned_docs/version-v0.82.2-alpha-testnet.5/developers/reference/smart_contract_reference/aztec-nr/aztec/oracle/execution_cache.md b/docs/versioned_docs/version-v0.82.2-alpha-testnet.5/developers/reference/smart_contract_reference/aztec-nr/aztec/oracle/execution_cache.md
new file mode 100644
index 000000000000..83aed7fd746d
--- /dev/null
+++ b/docs/versioned_docs/version-v0.82.2-alpha-testnet.5/developers/reference/smart_contract_reference/aztec-nr/aztec/oracle/execution_cache.md
@@ -0,0 +1,62 @@
+## Standalone Functions
+
+### store
+
+```rust
+store(values, hash);
+```
+
+/ Stores values represented as slice in execution cache to be later obtained by its hash.
+
+#### Parameters
+| Name | Type |
+| --- | --- |
+| values | [Field] |
+| hash | Field |
+
+### store_in_execution_cache_oracle_wrapper
+
+```rust
+store_in_execution_cache_oracle_wrapper(values, hash);
+```
+
+#### Parameters
+| Name | Type |
+| --- | --- |
+| values | [Field] |
+| hash | Field |
+
+### load
+
+```rust
+load(hash);
+```
+
+#### Parameters
+| Name | Type |
+| --- | --- |
+| hash | Field |
+
+### store_in_execution_cache_oracle
+
+```rust
+store_in_execution_cache_oracle(_values, _hash);
+```
+
+#### Parameters
+| Name | Type |
+| --- | --- |
+| _values | [Field] |
+| _hash | Field |
+
+### load_from_execution_cache_oracle
+
+```rust
+load_from_execution_cache_oracle(_hash);
+```
+
+#### Parameters
+| Name | Type |
+| --- | --- |
+| _hash | Field |
+
diff --git a/docs/versioned_docs/version-v0.82.2-alpha-testnet.5/developers/reference/smart_contract_reference/aztec-nr/aztec/oracle/get_contract_instance.md b/docs/versioned_docs/version-v0.82.2-alpha-testnet.5/developers/reference/smart_contract_reference/aztec-nr/aztec/oracle/get_contract_instance.md
new file mode 100644
index 000000000000..45500bebc27b
--- /dev/null
+++ b/docs/versioned_docs/version-v0.82.2-alpha-testnet.5/developers/reference/smart_contract_reference/aztec-nr/aztec/oracle/get_contract_instance.md
@@ -0,0 +1,142 @@
+## Standalone Functions
+
+### get_contract_instance_oracle
+
+```rust
+get_contract_instance_oracle(_address);
+```
+
+#### Parameters
+| Name | Type |
+| --- | --- |
+| _address | AztecAddress |
+
+### get_contract_instance_internal
+
+```rust
+get_contract_instance_internal(address);
+```
+
+#### Parameters
+| Name | Type |
+| --- | --- |
+| address | AztecAddress |
+
+### get_contract_instance
+
+```rust
+get_contract_instance(address);
+```
+
+NOTE: this is for use in private only
+
+#### Parameters
+| Name | Type |
+| --- | --- |
+| address | AztecAddress |
+
+### get_contract_instance_deployer_oracle_avm
+
+```rust
+get_contract_instance_deployer_oracle_avm(_address, );
+```
+
+#### Parameters
+| Name | Type |
+| --- | --- |
+| _address | AztecAddress |
+| | |
+
+### get_contract_instance_class_id_oracle_avm
+
+```rust
+get_contract_instance_class_id_oracle_avm(_address, );
+```
+
+#### Parameters
+| Name | Type |
+| --- | --- |
+| _address | AztecAddress |
+| | |
+
+### get_contract_instance_initialization_hash_oracle_avm
+
+```rust
+get_contract_instance_initialization_hash_oracle_avm(_address, );
+```
+
+#### Parameters
+| Name | Type |
+| --- | --- |
+| _address | AztecAddress |
+| | |
+
+### get_contract_instance_deployer_internal_avm
+
+```rust
+get_contract_instance_deployer_internal_avm(address, );
+```
+
+#### Parameters
+| Name | Type |
+| --- | --- |
+| address | AztecAddress |
+| | |
+
+### get_contract_instance_class_id_internal_avm
+
+```rust
+get_contract_instance_class_id_internal_avm(address, );
+```
+
+#### Parameters
+| Name | Type |
+| --- | --- |
+| address | AztecAddress |
+| | |
+
+### get_contract_instance_initialization_hash_internal_avm
+
+```rust
+get_contract_instance_initialization_hash_internal_avm(address, );
+```
+
+#### Parameters
+| Name | Type |
+| --- | --- |
+| address | AztecAddress |
+| | |
+
+### get_contract_instance_deployer_avm
+
+```rust
+get_contract_instance_deployer_avm(address);
+```
+
+#### Parameters
+| Name | Type |
+| --- | --- |
+| address | AztecAddress |
+
+### get_contract_instance_class_id_avm
+
+```rust
+get_contract_instance_class_id_avm(address);
+```
+
+#### Parameters
+| Name | Type |
+| --- | --- |
+| address | AztecAddress |
+
+### get_contract_instance_initialization_hash_avm
+
+```rust
+get_contract_instance_initialization_hash_avm(address);
+```
+
+#### Parameters
+| Name | Type |
+| --- | --- |
+| address | AztecAddress |
+
diff --git a/docs/versioned_docs/version-v0.82.2-alpha-testnet.5/developers/reference/smart_contract_reference/aztec-nr/aztec/oracle/get_l1_to_l2_membership_witness.md b/docs/versioned_docs/version-v0.82.2-alpha-testnet.5/developers/reference/smart_contract_reference/aztec-nr/aztec/oracle/get_l1_to_l2_membership_witness.md
new file mode 100644
index 000000000000..b4fec4a6095c
--- /dev/null
+++ b/docs/versioned_docs/version-v0.82.2-alpha-testnet.5/developers/reference/smart_contract_reference/aztec-nr/aztec/oracle/get_l1_to_l2_membership_witness.md
@@ -0,0 +1,30 @@
+## Standalone Functions
+
+### get_l1_to_l2_membership_witness
+
+```rust
+get_l1_to_l2_membership_witness(contract_address, message_hash, secret, );
+```
+
+#### Parameters
+| Name | Type |
+| --- | --- |
+| contract_address | AztecAddress |
+| message_hash | Field |
+| secret | Field |
+| | |
+
+### get_l1_to_l2_membership_witness_oracle
+
+```rust
+get_l1_to_l2_membership_witness_oracle(_contract_address, _message_hash, _secret, );
+```
+
+#### Parameters
+| Name | Type |
+| --- | --- |
+| _contract_address | AztecAddress |
+| _message_hash | Field |
+| _secret | Field |
+| | |
+
diff --git a/docs/versioned_docs/version-v0.82.2-alpha-testnet.5/developers/reference/smart_contract_reference/aztec-nr/aztec/oracle/get_membership_witness.md b/docs/versioned_docs/version-v0.82.2-alpha-testnet.5/developers/reference/smart_contract_reference/aztec-nr/aztec/oracle/get_membership_witness.md
new file mode 100644
index 000000000000..a27411385a60
--- /dev/null
+++ b/docs/versioned_docs/version-v0.82.2-alpha-testnet.5/developers/reference/smart_contract_reference/aztec-nr/aztec/oracle/get_membership_witness.md
@@ -0,0 +1,42 @@
+## Standalone Functions
+
+### get_membership_witness
+
+```rust
+get_membership_witness(_block_number, _tree_id, _leaf_value, );
+```
+
+#### Parameters
+| Name | Type |
+| --- | --- |
+| _block_number | u32 |
+| _tree_id | Field |
+| _leaf_value | Field |
+| | |
+
+### get_note_hash_membership_witness
+
+```rust
+get_note_hash_membership_witness(block_number, leaf_value, );
+```
+
+#### Parameters
+| Name | Type |
+| --- | --- |
+| block_number | u32 |
+| leaf_value | Field |
+| | |
+
+### get_archive_membership_witness
+
+```rust
+get_archive_membership_witness(block_number, leaf_value, );
+```
+
+#### Parameters
+| Name | Type |
+| --- | --- |
+| block_number | u32 |
+| leaf_value | Field |
+| | |
+
diff --git a/docs/versioned_docs/version-v0.82.2-alpha-testnet.5/developers/reference/smart_contract_reference/aztec-nr/aztec/oracle/get_nullifier_membership_witness.md b/docs/versioned_docs/version-v0.82.2-alpha-testnet.5/developers/reference/smart_contract_reference/aztec-nr/aztec/oracle/get_nullifier_membership_witness.md
new file mode 100644
index 000000000000..b75e60b13bf9
--- /dev/null
+++ b/docs/versioned_docs/version-v0.82.2-alpha-testnet.5/developers/reference/smart_contract_reference/aztec-nr/aztec/oracle/get_nullifier_membership_witness.md
@@ -0,0 +1,76 @@
+# NullifierMembershipWitness
+
+## Fields
+| Field | Type |
+| --- | --- |
+| pub index | Field |
+| pub leaf_preimage | NullifierLeafPreimage |
+| pub path | Field; NULLIFIER_TREE_HEIGHT] |
+
+## Methods
+
+### deserialize
+
+```rust
+NullifierMembershipWitness::deserialize(fields);
+```
+
+#### Parameters
+| Name | Type |
+| --- | --- |
+| fields | [Field; NULLIFIER_MEMBERSHIP_WITNESS] |
+
+## Standalone Functions
+
+### get_low_nullifier_membership_witness_oracle
+
+```rust
+get_low_nullifier_membership_witness_oracle(_block_number, _nullifier, );
+```
+
+#### Parameters
+| Name | Type |
+| --- | --- |
+| _block_number | u32 |
+| _nullifier | Field |
+| | |
+
+### get_low_nullifier_membership_witness
+
+```rust
+get_low_nullifier_membership_witness(block_number, nullifier, );
+```
+
+#### Parameters
+| Name | Type |
+| --- | --- |
+| block_number | u32 |
+| nullifier | Field |
+| | |
+
+### get_nullifier_membership_witness_oracle
+
+```rust
+get_nullifier_membership_witness_oracle(_block_number, _nullifier, );
+```
+
+#### Parameters
+| Name | Type |
+| --- | --- |
+| _block_number | u32 |
+| _nullifier | Field |
+| | |
+
+### get_nullifier_membership_witness
+
+```rust
+get_nullifier_membership_witness(block_number, nullifier, );
+```
+
+#### Parameters
+| Name | Type |
+| --- | --- |
+| block_number | u32 |
+| nullifier | Field |
+| | |
+
diff --git a/docs/versioned_docs/version-v0.82.2-alpha-testnet.5/developers/reference/smart_contract_reference/aztec-nr/aztec/oracle/get_public_data_witness.md b/docs/versioned_docs/version-v0.82.2-alpha-testnet.5/developers/reference/smart_contract_reference/aztec-nr/aztec/oracle/get_public_data_witness.md
new file mode 100644
index 000000000000..87e6d269adc7
--- /dev/null
+++ b/docs/versioned_docs/version-v0.82.2-alpha-testnet.5/developers/reference/smart_contract_reference/aztec-nr/aztec/oracle/get_public_data_witness.md
@@ -0,0 +1,37 @@
+# PublicDataWitness
+
+## Fields
+| Field | Type |
+| --- | --- |
+| pub index | Field |
+| pub leaf_preimage | PublicDataTreeLeafPreimage |
+| pub path | Field; PUBLIC_DATA_TREE_HEIGHT] |
+
+## Standalone Functions
+
+### get_public_data_witness_oracle
+
+```rust
+get_public_data_witness_oracle(_block_number, _public_data_tree_index, );
+```
+
+#### Parameters
+| Name | Type |
+| --- | --- |
+| _block_number | u32 |
+| _public_data_tree_index | Field |
+| | |
+
+### get_public_data_witness
+
+```rust
+get_public_data_witness(block_number, public_data_tree_index, );
+```
+
+#### Parameters
+| Name | Type |
+| --- | --- |
+| block_number | u32 |
+| public_data_tree_index | Field |
+| | |
+
diff --git a/docs/versioned_docs/version-v0.82.2-alpha-testnet.5/developers/reference/smart_contract_reference/aztec-nr/aztec/oracle/key_validation_request.md b/docs/versioned_docs/version-v0.82.2-alpha-testnet.5/developers/reference/smart_contract_reference/aztec-nr/aztec/oracle/key_validation_request.md
new file mode 100644
index 000000000000..692ba8ccb0a9
--- /dev/null
+++ b/docs/versioned_docs/version-v0.82.2-alpha-testnet.5/developers/reference/smart_contract_reference/aztec-nr/aztec/oracle/key_validation_request.md
@@ -0,0 +1,28 @@
+## Standalone Functions
+
+### get_key_validation_request_oracle
+
+```rust
+get_key_validation_request_oracle(_pk_m_hash, _key_index, );
+```
+
+#### Parameters
+| Name | Type |
+| --- | --- |
+| _pk_m_hash | Field |
+| _key_index | Field |
+| | |
+
+### get_key_validation_request
+
+```rust
+get_key_validation_request(pk_m_hash, key_index, );
+```
+
+#### Parameters
+| Name | Type |
+| --- | --- |
+| pk_m_hash | Field |
+| key_index | Field |
+| | |
+
diff --git a/docs/versioned_docs/version-v0.82.2-alpha-testnet.5/developers/reference/smart_contract_reference/aztec-nr/aztec/oracle/keys.md b/docs/versioned_docs/version-v0.82.2-alpha-testnet.5/developers/reference/smart_contract_reference/aztec-nr/aztec/oracle/keys.md
new file mode 100644
index 000000000000..0425c51f9d5c
--- /dev/null
+++ b/docs/versioned_docs/version-v0.82.2-alpha-testnet.5/developers/reference/smart_contract_reference/aztec-nr/aztec/oracle/keys.md
@@ -0,0 +1,25 @@
+## Standalone Functions
+
+### get_public_keys_and_partial_address_oracle
+
+```rust
+get_public_keys_and_partial_address_oracle(_address);
+```
+
+#### Parameters
+| Name | Type |
+| --- | --- |
+| _address | AztecAddress |
+
+### get_public_keys_and_partial_address
+
+```rust
+get_public_keys_and_partial_address(address, );
+```
+
+#### Parameters
+| Name | Type |
+| --- | --- |
+| address | AztecAddress |
+| | |
+
diff --git a/docs/versioned_docs/version-v0.82.2-alpha-testnet.5/developers/reference/smart_contract_reference/aztec-nr/aztec/oracle/logs.md b/docs/versioned_docs/version-v0.82.2-alpha-testnet.5/developers/reference/smart_contract_reference/aztec-nr/aztec/oracle/logs.md
new file mode 100644
index 000000000000..2e538601dd16
--- /dev/null
+++ b/docs/versioned_docs/version-v0.82.2-alpha-testnet.5/developers/reference/smart_contract_reference/aztec-nr/aztec/oracle/logs.md
@@ -0,0 +1,30 @@
+## Standalone Functions
+
+### notify_created_contract_class_log
+
+```rust
+notify_created_contract_class_log(contract_address, message, counter, );
+```
+
+#### Parameters
+| Name | Type |
+| --- | --- |
+| contract_address | AztecAddress |
+| message | [Field; N] |
+| counter | u32 |
+| | |
+
+### notify_created_contract_class_log_private_oracle
+
+```rust
+notify_created_contract_class_log_private_oracle(contract_address, message, counter, );
+```
+
+#### Parameters
+| Name | Type |
+| --- | --- |
+| contract_address | AztecAddress |
+| message | [Field; N] |
+| counter | u32 |
+| | |
+
diff --git a/docs/versioned_docs/version-v0.82.2-alpha-testnet.5/developers/reference/smart_contract_reference/aztec-nr/aztec/oracle/message_discovery.md b/docs/versioned_docs/version-v0.82.2-alpha-testnet.5/developers/reference/smart_contract_reference/aztec-nr/aztec/oracle/message_discovery.md
new file mode 100644
index 000000000000..6c65d7b52d4b
--- /dev/null
+++ b/docs/versioned_docs/version-v0.82.2-alpha-testnet.5/developers/reference/smart_contract_reference/aztec-nr/aztec/oracle/message_discovery.md
@@ -0,0 +1,92 @@
+# LogWithTxData
+
+/ The contents of a public log, plus contextual information about the transaction in which the log was emitted. This / is the data required in order to discover notes that are being delivered in a log. TODO(#11639): this could also be used to fetch private logs, but the `BoundedVec` maximum length is that of a public log.
+
+## Fields
+| Field | Type |
+| --- | --- |
+| pub log_content | BoundedVec<Field, PUBLIC_LOG_DATA_SIZE_IN_FIELDS> |
+| pub tx_hash | Field |
+| pub unique_note_hashes_in_tx | BoundedVec<Field, MAX_NOTE_HASHES_PER_TX> |
+| pub first_nullifier_in_tx | Field |
+
+## Standalone Functions
+
+### sync_notes
+
+```rust
+sync_notes();
+```
+
+Takes no parameters.
+
+### sync_notes_oracle
+
+```rust
+sync_notes_oracle();
+```
+
+Takes no parameters.
+
+### deliver_note
+
+```rust
+deliver_note(contract_address, storage_slot, nonce, packed_note, MAX_NOTE_PACKED_LEN>, note_hash, nullifier, tx_hash, recipient, );
+```
+
+#### Parameters
+| Name | Type |
+| --- | --- |
+| contract_address | AztecAddress |
+| storage_slot | Field |
+| nonce | Field |
+| packed_note | BoundedVec<Field |
+| MAX_NOTE_PACKED_LEN> | |
+| note_hash | Field |
+| nullifier | Field |
+| tx_hash | Field |
+| recipient | AztecAddress |
+| | |
+
+### get_log_by_tag
+
+```rust
+get_log_by_tag(tag);
+```
+
+#### Parameters
+| Name | Type |
+| --- | --- |
+| tag | Field |
+
+### deliver_note_oracle
+
+```rust
+deliver_note_oracle(contract_address, storage_slot, nonce, packed_note, MAX_NOTE_PACKED_LEN>, note_hash, nullifier, tx_hash, recipient, );
+```
+
+#### Parameters
+| Name | Type |
+| --- | --- |
+| contract_address | AztecAddress |
+| storage_slot | Field |
+| nonce | Field |
+| packed_note | BoundedVec<Field |
+| MAX_NOTE_PACKED_LEN> | |
+| note_hash | Field |
+| nullifier | Field |
+| tx_hash | Field |
+| recipient | AztecAddress |
+| | |
+
+### get_log_by_tag_oracle
+
+```rust
+get_log_by_tag_oracle(tag);
+```
+
+#### Parameters
+| Name | Type |
+| --- | --- |
+| tag | Field |
+
diff --git a/docs/versioned_docs/version-v0.82.2-alpha-testnet.5/developers/reference/smart_contract_reference/aztec-nr/aztec/oracle/notes.md b/docs/versioned_docs/version-v0.82.2-alpha-testnet.5/developers/reference/smart_contract_reference/aztec-nr/aztec/oracle/notes.md
new file mode 100644
index 000000000000..24250f5a7a5a
--- /dev/null
+++ b/docs/versioned_docs/version-v0.82.2-alpha-testnet.5/developers/reference/smart_contract_reference/aztec-nr/aztec/oracle/notes.md
@@ -0,0 +1,306 @@
+## Standalone Functions
+
+### notify_created_note
+
+```rust
+notify_created_note(storage_slot, note_type_id, packed_note, note_hash, counter, );
+```
+
+/ transaction. This note should only be added to the non-volatile database if found in an actual block.
+
+#### Parameters
+| Name | Type |
+| --- | --- |
+| storage_slot | Field |
+| note_type_id | Field |
+| packed_note | [Field; N] |
+| note_hash | Field |
+| counter | u32 |
+| | |
+
+### notify_nullified_note
+
+```rust
+notify_nullified_note(nullifier, note_hash, counter);
+```
+
+/ actual block.
+
+#### Parameters
+| Name | Type |
+| --- | --- |
+| nullifier | Field |
+| note_hash | Field |
+| counter | u32 |
+
+### notify_created_nullifier
+
+```rust
+notify_created_nullifier(nullifier);
+```
+
+/ Notifies the simulator that a non-note nullifier has been created, so that it can be used for note nonces.
+
+#### Parameters
+| Name | Type |
+| --- | --- |
+| nullifier | Field |
+
+### notify_created_note_oracle_wrapper
+
+```rust
+notify_created_note_oracle_wrapper(storage_slot, note_type_id, packed_note, note_hash, counter, );
+```
+
+#### Parameters
+| Name | Type |
+| --- | --- |
+| storage_slot | Field |
+| note_type_id | Field |
+| packed_note | [Field; N] |
+| note_hash | Field |
+| counter | u32 |
+| | |
+
+### notify_created_note_oracle
+
+```rust
+notify_created_note_oracle(_storage_slot, _note_type_id, _packed_note, _note_hash, _counter, );
+```
+
+#### Parameters
+| Name | Type |
+| --- | --- |
+| _storage_slot | Field |
+| _note_type_id | Field |
+| _packed_note | [Field; N] |
+| _note_hash | Field |
+| _counter | u32 |
+| | |
+
+### notify_nullified_note_oracle_wrapper
+
+```rust
+notify_nullified_note_oracle_wrapper(nullifier, note_hash, counter, );
+```
+
+#### Parameters
+| Name | Type |
+| --- | --- |
+| nullifier | Field |
+| note_hash | Field |
+| counter | u32 |
+| | |
+
+### notify_nullified_note_oracle
+
+```rust
+notify_nullified_note_oracle(_nullifier, _note_hash, _counter);
+```
+
+#### Parameters
+| Name | Type |
+| --- | --- |
+| _nullifier | Field |
+| _note_hash | Field |
+| _counter | u32 |
+
+### notify_created_nullifier_oracle_wrapper
+
+```rust
+notify_created_nullifier_oracle_wrapper(nullifier);
+```
+
+#### Parameters
+| Name | Type |
+| --- | --- |
+| nullifier | Field |
+
+### notify_created_nullifier_oracle
+
+```rust
+notify_created_nullifier_oracle(_nullifier);
+```
+
+#### Parameters
+| Name | Type |
+| --- | --- |
+| _nullifier | Field |
+
+### get_notes_oracle
+
+```rust
+get_notes_oracle(_storage_slot, _num_selects, _select_by_indexes, _select_by_offsets, _select_by_lengths, _select_values, _select_comparators, _sort_by_indexes, _sort_by_offsets, _sort_by_lengths, _sort_order, _limit, _offset, _status, _return_size, );
+```
+
+#### Parameters
+| Name | Type |
+| --- | --- |
+| _storage_slot | Field |
+| _num_selects | u8 |
+| _select_by_indexes | [u8; N] |
+| _select_by_offsets | [u8; N] |
+| _select_by_lengths | [u8; N] |
+| _select_values | [Field; N] |
+| _select_comparators | [u8; N] |
+| _sort_by_indexes | [u8; N] |
+| _sort_by_offsets | [u8; N] |
+| _sort_by_lengths | [u8; N] |
+| _sort_order | [u8; N] |
+| _limit | u32 |
+| _offset | u32 |
+| _status | u8 |
+| _return_size | u32 |
+| | |
+
+### get_notes_oracle_wrapper
+
+```rust
+get_notes_oracle_wrapper(storage_slot, num_selects, select_by_indexes, select_by_offsets, select_by_lengths, select_values, select_comparators, sort_by_indexes, sort_by_offsets, sort_by_lengths, sort_order, limit, offset, status, );
+```
+
+#### Parameters
+| Name | Type |
+| --- | --- |
+| storage_slot | Field |
+| num_selects | u8 |
+| select_by_indexes | [u8; N] |
+| select_by_offsets | [u8; N] |
+| select_by_lengths | [u8; N] |
+| select_values | [Field; N] |
+| select_comparators | [u8; N] |
+| sort_by_indexes | [u8; N] |
+| sort_by_offsets | [u8; N] |
+| sort_by_lengths | [u8; N] |
+| sort_order | [u8; N] |
+| limit | u32 |
+| offset | u32 |
+| status | u8 |
+| | |
+
+### get_notes
+
+```rust
+get_notes(storage_slot, num_selects, select_by_indexes, select_by_offsets, select_by_lengths, select_values, select_comparators, sort_by_indexes, sort_by_offsets, sort_by_lengths, sort_order, limit, offset, status, _placeholder_fields, // TODO);
+```
+
+#### Parameters
+| Name | Type |
+| --- | --- |
+| storage_slot | Field |
+| num_selects | u8 |
+| select_by_indexes | [u8; M] |
+| select_by_offsets | [u8; M] |
+| select_by_lengths | [u8; M] |
+| select_values | [Field; M] |
+| select_comparators | [u8; M] |
+| sort_by_indexes | [u8; M] |
+| sort_by_offsets | [u8; M] |
+| sort_by_lengths | [u8; M] |
+| sort_order | [u8; M] |
+| limit | u32 |
+| offset | u32 |
+| status | u8 |
+| _placeholder_fields | [Field; ORACLE_RETURN_FIELD_LENGTH] |
+| // TODO | Compute this value automatically from MAX_NOTES |
+
+### check_nullifier_exists
+
+```rust
+check_nullifier_exists(inner_nullifier);
+```
+
+#### Parameters
+| Name | Type |
+| --- | --- |
+| inner_nullifier | Field |
+
+### check_nullifier_exists_oracle
+
+```rust
+check_nullifier_exists_oracle(_inner_nullifier);
+```
+
+#### Parameters
+| Name | Type |
+| --- | --- |
+| _inner_nullifier | Field |
+
+### get_app_tag_as_sender
+
+```rust
+get_app_tag_as_sender(sender, recipient);
+```
+
+#### Parameters
+| Name | Type |
+| --- | --- |
+| sender | AztecAddress |
+| recipient | AztecAddress |
+
+### get_indexed_tagging_secret_as_sender
+
+```rust
+get_indexed_tagging_secret_as_sender(sender, recipient, );
+```
+
+#### Parameters
+| Name | Type |
+| --- | --- |
+| sender | AztecAddress |
+| recipient | AztecAddress |
+| | |
+
+### get_indexed_tagging_secret_as_sender_oracle
+
+```rust
+get_indexed_tagging_secret_as_sender_oracle(_sender, _recipient, );
+```
+
+#### Parameters
+| Name | Type |
+| --- | --- |
+| _sender | AztecAddress |
+| _recipient | AztecAddress |
+| | |
+
+### increment_app_tagging_secret_index_as_sender
+
+```rust
+increment_app_tagging_secret_index_as_sender(sender, recipient);
+```
+
+/ that are not found by the recipient.
+
+#### Parameters
+| Name | Type |
+| --- | --- |
+| sender | AztecAddress |
+| recipient | AztecAddress |
+
+### increment_app_tagging_secret_index_as_sender_wrapper
+
+```rust
+increment_app_tagging_secret_index_as_sender_wrapper(sender, recipient, );
+```
+
+#### Parameters
+| Name | Type |
+| --- | --- |
+| sender | AztecAddress |
+| recipient | AztecAddress |
+| | |
+
+### increment_app_tagging_secret_index_as_sender_oracle
+
+```rust
+increment_app_tagging_secret_index_as_sender_oracle(_sender, _recipient, );
+```
+
+#### Parameters
+| Name | Type |
+| --- | --- |
+| _sender | AztecAddress |
+| _recipient | AztecAddress |
+| | |
+
diff --git a/docs/versioned_docs/version-v0.82.2-alpha-testnet.5/developers/reference/smart_contract_reference/aztec-nr/aztec/oracle/random.md b/docs/versioned_docs/version-v0.82.2-alpha-testnet.5/developers/reference/smart_contract_reference/aztec-nr/aztec/oracle/random.md
new file mode 100644
index 000000000000..93e89332780f
--- /dev/null
+++ b/docs/versioned_docs/version-v0.82.2-alpha-testnet.5/developers/reference/smart_contract_reference/aztec-nr/aztec/oracle/random.md
@@ -0,0 +1,18 @@
+## Standalone Functions
+
+### random
+
+```rust
+random();
+```
+
+Takes no parameters.
+
+### rand_oracle
+
+```rust
+rand_oracle();
+```
+
+Takes no parameters.
+
diff --git a/docs/versioned_docs/version-v0.82.2-alpha-testnet.5/developers/reference/smart_contract_reference/aztec-nr/aztec/oracle/shared_secret.md b/docs/versioned_docs/version-v0.82.2-alpha-testnet.5/developers/reference/smart_contract_reference/aztec-nr/aztec/oracle/shared_secret.md
new file mode 100644
index 000000000000..a7c2273cf25d
--- /dev/null
+++ b/docs/versioned_docs/version-v0.82.2-alpha-testnet.5/developers/reference/smart_contract_reference/aztec-nr/aztec/oracle/shared_secret.md
@@ -0,0 +1,26 @@
+## Standalone Functions
+
+### get_shared_secret_oracle
+
+```rust
+get_shared_secret_oracle(address, ephPk);
+```
+
+#### Parameters
+| Name | Type |
+| --- | --- |
+| address | AztecAddress |
+| ephPk | Point |
+
+### get_shared_secret
+
+```rust
+get_shared_secret(address, ephPk);
+```
+
+#### Parameters
+| Name | Type |
+| --- | --- |
+| address | AztecAddress |
+| ephPk | Point |
+
diff --git a/docs/versioned_docs/version-v0.82.2-alpha-testnet.5/developers/reference/smart_contract_reference/aztec-nr/aztec/oracle/storage.md b/docs/versioned_docs/version-v0.82.2-alpha-testnet.5/developers/reference/smart_contract_reference/aztec-nr/aztec/oracle/storage.md
new file mode 100644
index 000000000000..c01b908f0052
--- /dev/null
+++ b/docs/versioned_docs/version-v0.82.2-alpha-testnet.5/developers/reference/smart_contract_reference/aztec-nr/aztec/oracle/storage.md
@@ -0,0 +1,61 @@
+## Standalone Functions
+
+### storage_read_oracle
+
+```rust
+storage_read_oracle(address, storage_slot, block_number, length, );
+```
+
+#### Parameters
+| Name | Type |
+| --- | --- |
+| address | Field |
+| storage_slot | Field |
+| block_number | Field |
+| length | Field |
+| | |
+
+### raw_storage_read
+
+```rust
+raw_storage_read(address, storage_slot, block_number, );
+```
+
+#### Parameters
+| Name | Type |
+| --- | --- |
+| address | AztecAddress |
+| storage_slot | Field |
+| block_number | u32 |
+| | |
+
+### storage_read
+
+```rust
+storage_read(address, storage_slot, block_number, );
+```
+
+#### Parameters
+| Name | Type |
+| --- | --- |
+| address | AztecAddress |
+| storage_slot | Field |
+| block_number | u32 |
+| | |
+
+### test_raw_storage_read
+
+```rust
+test_raw_storage_read();
+```
+
+Takes no parameters.
+
+### test_storage_read
+
+```rust
+test_storage_read();
+```
+
+Takes no parameters.
+
diff --git a/docs/versioned_docs/version-v0.82.2-alpha-testnet.5/developers/reference/smart_contract_reference/aztec-nr/aztec/state_vars/map.md b/docs/versioned_docs/version-v0.82.2-alpha-testnet.5/developers/reference/smart_contract_reference/aztec-nr/aztec/state_vars/map.md
new file mode 100644
index 000000000000..1bea61829427
--- /dev/null
+++ b/docs/versioned_docs/version-v0.82.2-alpha-testnet.5/developers/reference/smart_contract_reference/aztec-nr/aztec/state_vars/map.md
@@ -0,0 +1,39 @@
+## Standalone Functions
+
+### get_storage_slot
+
+```rust
+get_storage_slot(self);
+```
+
+#### Parameters
+| Name | Type |
+| --- | --- |
+| self | |
+
+### new
+
+```rust
+new(context, storage_slot, state_var_constructor, Field);
+```
+
+#### Parameters
+| Name | Type |
+| --- | --- |
+| context | Context |
+| storage_slot | Field |
+| state_var_constructor | fn(Context |
+| Field | |
+
+### at
+
+```rust
+at(self, key);
+```
+
+#### Parameters
+| Name | Type |
+| --- | --- |
+| self | |
+| key | K |
+
diff --git a/docs/versioned_docs/version-v0.82.2-alpha-testnet.5/developers/reference/smart_contract_reference/aztec-nr/aztec/state_vars/private_immutable.md b/docs/versioned_docs/version-v0.82.2-alpha-testnet.5/developers/reference/smart_contract_reference/aztec-nr/aztec/state_vars/private_immutable.md
new file mode 100644
index 000000000000..0891934dae61
--- /dev/null
+++ b/docs/versioned_docs/version-v0.82.2-alpha-testnet.5/developers/reference/smart_contract_reference/aztec-nr/aztec/state_vars/private_immutable.md
@@ -0,0 +1,81 @@
+## Standalone Functions
+
+### get_storage_slot
+
+```rust
+get_storage_slot(self);
+```
+
+#### Parameters
+| Name | Type |
+| --- | --- |
+| self | |
+
+### new
+
+```rust
+new(context, storage_slot);
+```
+
+#### Parameters
+| Name | Type |
+| --- | --- |
+| context | Context |
+| storage_slot | Field |
+
+### compute_initialization_nullifier
+
+```rust
+compute_initialization_nullifier(self);
+```
+
+#### Parameters
+| Name | Type |
+| --- | --- |
+| self | |
+
+### initialize
+
+```rust
+initialize(self, note);
+```
+
+#### Parameters
+| Name | Type |
+| --- | --- |
+| self | |
+| note | Note |
+
+### get_note
+
+```rust
+get_note(self);
+```
+
+#### Parameters
+| Name | Type |
+| --- | --- |
+| self | |
+
+### is_initialized
+
+```rust
+is_initialized(self);
+```
+
+#### Parameters
+| Name | Type |
+| --- | --- |
+| self | |
+
+### view_note
+
+```rust
+view_note(self);
+```
+
+#### Parameters
+| Name | Type |
+| --- | --- |
+| self | |
+
diff --git a/docs/versioned_docs/version-v0.82.2-alpha-testnet.5/developers/reference/smart_contract_reference/aztec-nr/aztec/state_vars/private_mutable.md b/docs/versioned_docs/version-v0.82.2-alpha-testnet.5/developers/reference/smart_contract_reference/aztec-nr/aztec/state_vars/private_mutable.md
new file mode 100644
index 000000000000..ceacadf858f7
--- /dev/null
+++ b/docs/versioned_docs/version-v0.82.2-alpha-testnet.5/developers/reference/smart_contract_reference/aztec-nr/aztec/state_vars/private_mutable.md
@@ -0,0 +1,105 @@
+## Standalone Functions
+
+### get_storage_slot
+
+```rust
+get_storage_slot(self);
+```
+
+#### Parameters
+| Name | Type |
+| --- | --- |
+| self | |
+
+### new
+
+```rust
+new(context, storage_slot);
+```
+
+#### Parameters
+| Name | Type |
+| --- | --- |
+| context | Context |
+| storage_slot | Field |
+
+### compute_initialization_nullifier
+
+```rust
+compute_initialization_nullifier(self);
+```
+
+#### Parameters
+| Name | Type |
+| --- | --- |
+| self | |
+
+### initialize
+
+```rust
+initialize(self, note);
+```
+
+#### Parameters
+| Name | Type |
+| --- | --- |
+| self | |
+| note | Note |
+
+### replace
+
+```rust
+replace(self, new_note);
+```
+
+#### Parameters
+| Name | Type |
+| --- | --- |
+| self | |
+| new_note | Note |
+
+### initialize_or_replace
+
+```rust
+initialize_or_replace(self, note);
+```
+
+#### Parameters
+| Name | Type |
+| --- | --- |
+| self | |
+| note | Note |
+
+### get_note
+
+```rust
+get_note(self);
+```
+
+#### Parameters
+| Name | Type |
+| --- | --- |
+| self | |
+
+### is_initialized
+
+```rust
+is_initialized(self);
+```
+
+#### Parameters
+| Name | Type |
+| --- | --- |
+| self | |
+
+### view_note
+
+```rust
+view_note(self);
+```
+
+#### Parameters
+| Name | Type |
+| --- | --- |
+| self | |
+
diff --git a/docs/versioned_docs/version-v0.82.2-alpha-testnet.5/developers/reference/smart_contract_reference/aztec-nr/aztec/state_vars/private_mutable/test.md b/docs/versioned_docs/version-v0.82.2-alpha-testnet.5/developers/reference/smart_contract_reference/aztec-nr/aztec/state_vars/private_mutable/test.md
new file mode 100644
index 000000000000..ac54d649bf66
--- /dev/null
+++ b/docs/versioned_docs/version-v0.82.2-alpha-testnet.5/developers/reference/smart_contract_reference/aztec-nr/aztec/state_vars/private_mutable/test.md
@@ -0,0 +1,38 @@
+## Standalone Functions
+
+### setup
+
+```rust
+setup();
+```
+
+Takes no parameters.
+
+### in_private
+
+```rust
+in_private(env, );
+```
+
+#### Parameters
+| Name | Type |
+| --- | --- |
+| env | &mut TestEnvironment |
+| | |
+
+### test_initialize_or_replace_without_nullifier
+
+```rust
+test_initialize_or_replace_without_nullifier();
+```
+
+Takes no parameters.
+
+### test_initialize_or_replace_with_nullifier
+
+```rust
+test_initialize_or_replace_with_nullifier();
+```
+
+Takes no parameters.
+
diff --git a/docs/versioned_docs/version-v0.82.2-alpha-testnet.5/developers/reference/smart_contract_reference/aztec-nr/aztec/state_vars/private_set.md b/docs/versioned_docs/version-v0.82.2-alpha-testnet.5/developers/reference/smart_contract_reference/aztec-nr/aztec/state_vars/private_set.md
new file mode 100644
index 000000000000..2deb70102a4e
--- /dev/null
+++ b/docs/versioned_docs/version-v0.82.2-alpha-testnet.5/developers/reference/smart_contract_reference/aztec-nr/aztec/state_vars/private_set.md
@@ -0,0 +1,95 @@
+## Standalone Functions
+
+### get_storage_slot
+
+```rust
+get_storage_slot(self);
+```
+
+#### Parameters
+| Name | Type |
+| --- | --- |
+| self | |
+
+### new
+
+```rust
+new(context, storage_slot);
+```
+
+#### Parameters
+| Name | Type |
+| --- | --- |
+| context | Context |
+| storage_slot | Field |
+
+### insert
+
+```rust
+insert(self, note);
+```
+
+#### Parameters
+| Name | Type |
+| --- | --- |
+| self | |
+| note | Note |
+
+### pop_notes
+
+```rust
+pop_notes(self, options, N, PREPROCESSOR_ARGS, FILTER_ARGS>, );
+```
+
+#### Parameters
+| Name | Type |
+| --- | --- |
+| self | |
+| options | NoteGetterOptions<Note |
+| N | |
+| PREPROCESSOR_ARGS | |
+| FILTER_ARGS> | |
+| | |
+
+### remove
+
+```rust
+remove(self, retrieved_note);
+```
+
+#### Parameters
+| Name | Type |
+| --- | --- |
+| self | |
+| retrieved_note | RetrievedNote<Note> |
+
+### get_notes
+
+```rust
+get_notes(self, options, N, PREPROCESSOR_ARGS, FILTER_ARGS>, );
+```
+
+#### Parameters
+| Name | Type |
+| --- | --- |
+| self | |
+| options | NoteGetterOptions<Note |
+| N | |
+| PREPROCESSOR_ARGS | |
+| FILTER_ARGS> | |
+| | |
+
+### view_notes
+
+```rust
+view_notes(self, options, N>, );
+```
+
+#### Parameters
+| Name | Type |
+| --- | --- |
+| self | |
+| options | NoteViewerOptions<Note |
+| N> | |
+| | |
+
diff --git a/docs/versioned_docs/version-v0.82.2-alpha-testnet.5/developers/reference/smart_contract_reference/aztec-nr/aztec/state_vars/public_immutable.md b/docs/versioned_docs/version-v0.82.2-alpha-testnet.5/developers/reference/smart_contract_reference/aztec-nr/aztec/state_vars/public_immutable.md
new file mode 100644
index 000000000000..29191e7f2db0
--- /dev/null
+++ b/docs/versioned_docs/version-v0.82.2-alpha-testnet.5/developers/reference/smart_contract_reference/aztec-nr/aztec/state_vars/public_immutable.md
@@ -0,0 +1,69 @@
+## Standalone Functions
+
+### get_storage_slot
+
+```rust
+get_storage_slot(self);
+```
+
+#### Parameters
+| Name | Type |
+| --- | --- |
+| self | |
+
+### new
+
+```rust
+new(// Note);
+```
+
+#### Parameters
+| Name | Type |
+| --- | --- |
+| // Note | Passing the contexts to new(.. |
+
+### initialize
+
+```rust
+initialize(self, value);
+```
+
+#### Parameters
+| Name | Type |
+| --- | --- |
+| self | |
+| value | T |
+
+### read
+
+```rust
+read(self);
+```
+
+#### Parameters
+| Name | Type |
+| --- | --- |
+| self | |
+
+### read
+
+```rust
+read(self);
+```
+
+#### Parameters
+| Name | Type |
+| --- | --- |
+| self | |
+
+### read
+
+```rust
+read(self);
+```
+
+#### Parameters
+| Name | Type |
+| --- | --- |
+| self | |
+
diff --git a/docs/versioned_docs/version-v0.82.2-alpha-testnet.5/developers/reference/smart_contract_reference/aztec-nr/aztec/state_vars/public_immutable/test.md b/docs/versioned_docs/version-v0.82.2-alpha-testnet.5/developers/reference/smart_contract_reference/aztec-nr/aztec/state_vars/public_immutable/test.md
new file mode 100644
index 000000000000..16d7b2df228d
--- /dev/null
+++ b/docs/versioned_docs/version-v0.82.2-alpha-testnet.5/developers/reference/smart_contract_reference/aztec-nr/aztec/state_vars/public_immutable/test.md
@@ -0,0 +1,53 @@
+## Standalone Functions
+
+### setup
+
+```rust
+setup();
+```
+
+Takes no parameters.
+
+### in_public
+
+```rust
+in_public(env);
+```
+
+#### Parameters
+| Name | Type |
+| --- | --- |
+| env | TestEnvironment |
+
+### test_uninitialized_by_default
+
+```rust
+test_uninitialized_by_default();
+```
+
+Takes no parameters.
+
+### test_initialize_uninitialized
+
+```rust
+test_initialize_uninitialized();
+```
+
+Takes no parameters.
+
+### test_initialize_already_initialized
+
+```rust
+test_initialize_already_initialized();
+```
+
+Takes no parameters.
+
+### test_read_uninitialized
+
+```rust
+test_read_uninitialized();
+```
+
+Takes no parameters.
+
diff --git a/docs/versioned_docs/version-v0.82.2-alpha-testnet.5/developers/reference/smart_contract_reference/aztec-nr/aztec/state_vars/public_mutable.md b/docs/versioned_docs/version-v0.82.2-alpha-testnet.5/developers/reference/smart_contract_reference/aztec-nr/aztec/state_vars/public_mutable.md
new file mode 100644
index 000000000000..582851052aad
--- /dev/null
+++ b/docs/versioned_docs/version-v0.82.2-alpha-testnet.5/developers/reference/smart_contract_reference/aztec-nr/aztec/state_vars/public_mutable.md
@@ -0,0 +1,58 @@
+## Standalone Functions
+
+### get_storage_slot
+
+```rust
+get_storage_slot(self);
+```
+
+#### Parameters
+| Name | Type |
+| --- | --- |
+| self | |
+
+### new
+
+```rust
+new(// Note);
+```
+
+#### Parameters
+| Name | Type |
+| --- | --- |
+| // Note | Passing the contexts to new(.. |
+
+### read
+
+```rust
+read(self);
+```
+
+#### Parameters
+| Name | Type |
+| --- | --- |
+| self | |
+
+### write
+
+```rust
+write(self, value);
+```
+
+#### Parameters
+| Name | Type |
+| --- | --- |
+| self | |
+| value | T |
+
+### read
+
+```rust
+read(self);
+```
+
+#### Parameters
+| Name | Type |
+| --- | --- |
+| self | |
+
diff --git a/docs/versioned_docs/version-v0.82.2-alpha-testnet.5/developers/reference/smart_contract_reference/aztec-nr/aztec/state_vars/shared_mutable.md b/docs/versioned_docs/version-v0.82.2-alpha-testnet.5/developers/reference/smart_contract_reference/aztec-nr/aztec/state_vars/shared_mutable.md
new file mode 100644
index 000000000000..9c77c51ce65a
--- /dev/null
+++ b/docs/versioned_docs/version-v0.82.2-alpha-testnet.5/developers/reference/smart_contract_reference/aztec-nr/aztec/state_vars/shared_mutable.md
@@ -0,0 +1,175 @@
+## Standalone Functions
+
+### get_storage_slot
+
+```rust
+get_storage_slot(self);
+```
+
+#### Parameters
+| Name | Type |
+| --- | --- |
+| self | |
+
+### new
+
+```rust
+new(context, storage_slot);
+```
+
+#### Parameters
+| Name | Type |
+| --- | --- |
+| context | Context |
+| storage_slot | Field |
+
+### schedule_value_change
+
+```rust
+schedule_value_change(self, new_value);
+```
+
+#### Parameters
+| Name | Type |
+| --- | --- |
+| self | |
+| new_value | T |
+
+### schedule_and_return_value_change
+
+```rust
+schedule_and_return_value_change(self, new_value);
+```
+
+#### Parameters
+| Name | Type |
+| --- | --- |
+| self | |
+| new_value | T |
+
+### schedule_delay_change
+
+```rust
+schedule_delay_change(self, new_delay);
+```
+
+#### Parameters
+| Name | Type |
+| --- | --- |
+| self | |
+| new_delay | u32 |
+
+### get_current_value
+
+```rust
+get_current_value(self);
+```
+
+#### Parameters
+| Name | Type |
+| --- | --- |
+| self | |
+
+### get_current_delay
+
+```rust
+get_current_delay(self);
+```
+
+#### Parameters
+| Name | Type |
+| --- | --- |
+| self | |
+
+### get_scheduled_value
+
+```rust
+get_scheduled_value(self);
+```
+
+#### Parameters
+| Name | Type |
+| --- | --- |
+| self | |
+
+### get_scheduled_delay
+
+```rust
+get_scheduled_delay(self);
+```
+
+#### Parameters
+| Name | Type |
+| --- | --- |
+| self | |
+
+### read_value_change
+
+```rust
+read_value_change(self);
+```
+
+#### Parameters
+| Name | Type |
+| --- | --- |
+| self | |
+
+### read_delay_change
+
+```rust
+read_delay_change(self);
+```
+
+#### Parameters
+| Name | Type |
+| --- | --- |
+| self | |
+
+### write
+
+```rust
+write(self, value_change, delay_change, );
+```
+
+#### Parameters
+| Name | Type |
+| --- | --- |
+| self | |
+| value_change | ScheduledValueChange<T> |
+| delay_change | ScheduledDelayChange<INITIAL_DELAY> |
+| | |
+
+### get_current_value
+
+```rust
+get_current_value(self);
+```
+
+#### Parameters
+| Name | Type |
+| --- | --- |
+| self | |
+
+### historical_read_from_public_storage
+
+```rust
+historical_read_from_public_storage(self, );
+```
+
+#### Parameters
+| Name | Type |
+| --- | --- |
+| self | |
+| | |
+
+### get_current_value
+
+```rust
+get_current_value(self);
+```
+
+#### Parameters
+| Name | Type |
+| --- | --- |
+| self | |
+
diff --git a/docs/versioned_docs/version-v0.82.2-alpha-testnet.5/developers/reference/smart_contract_reference/aztec-nr/aztec/state_vars/shared_mutable/test.md b/docs/versioned_docs/version-v0.82.2-alpha-testnet.5/developers/reference/smart_contract_reference/aztec-nr/aztec/state_vars/shared_mutable/test.md
new file mode 100644
index 000000000000..60cbc6181075
--- /dev/null
+++ b/docs/versioned_docs/version-v0.82.2-alpha-testnet.5/developers/reference/smart_contract_reference/aztec-nr/aztec/state_vars/shared_mutable/test.md
@@ -0,0 +1,207 @@
+## Standalone Functions
+
+### setup
+
+```rust
+setup();
+```
+
+Takes no parameters.
+
+### in_public
+
+```rust
+in_public(env, );
+```
+
+#### Parameters
+| Name | Type |
+| --- | --- |
+| env | TestEnvironment |
+| | |
+
+### in_private
+
+```rust
+in_private(env, historical_block_number, );
+```
+
+#### Parameters
+| Name | Type |
+| --- | --- |
+| env | &mut TestEnvironment |
+| historical_block_number | u32 |
+| | |
+
+### in_unconstrained
+
+```rust
+in_unconstrained(env, );
+```
+
+#### Parameters
+| Name | Type |
+| --- | --- |
+| env | TestEnvironment |
+| | |
+
+### test_get_current_value_in_public_initial
+
+```rust
+test_get_current_value_in_public_initial();
+```
+
+Takes no parameters.
+
+### test_get_scheduled_value_in_public
+
+```rust
+test_get_scheduled_value_in_public();
+```
+
+Takes no parameters.
+
+### test_get_current_value_in_public_before_scheduled_change
+
+```rust
+test_get_current_value_in_public_before_scheduled_change();
+```
+
+Takes no parameters.
+
+### test_get_current_value_in_public_at_scheduled_change
+
+```rust
+test_get_current_value_in_public_at_scheduled_change();
+```
+
+Takes no parameters.
+
+### test_get_current_value_in_public_after_scheduled_change
+
+```rust
+test_get_current_value_in_public_after_scheduled_change();
+```
+
+Takes no parameters.
+
+### test_get_current_delay_in_public_initial
+
+```rust
+test_get_current_delay_in_public_initial();
+```
+
+Takes no parameters.
+
+### test_get_scheduled_delay_in_public
+
+```rust
+test_get_scheduled_delay_in_public();
+```
+
+Takes no parameters.
+
+### test_get_current_delay_in_public_before_scheduled_change
+
+```rust
+test_get_current_delay_in_public_before_scheduled_change();
+```
+
+Takes no parameters.
+
+### test_get_current_delay_in_public_at_scheduled_change
+
+```rust
+test_get_current_delay_in_public_at_scheduled_change();
+```
+
+Takes no parameters.
+
+### test_get_current_delay_in_public_after_scheduled_change
+
+```rust
+test_get_current_delay_in_public_after_scheduled_change();
+```
+
+Takes no parameters.
+
+### test_get_current_value_in_private_initial
+
+```rust
+test_get_current_value_in_private_initial();
+```
+
+Takes no parameters.
+
+### test_get_current_value_in_private_before_change
+
+```rust
+test_get_current_value_in_private_before_change();
+```
+
+Takes no parameters.
+
+### test_get_current_value_in_private_immediately_before_change
+
+```rust
+test_get_current_value_in_private_immediately_before_change();
+```
+
+Takes no parameters.
+
+### test_get_current_value_in_private_at_change
+
+```rust
+test_get_current_value_in_private_at_change();
+```
+
+Takes no parameters.
+
+### test_get_current_value_in_private_after_change
+
+```rust
+test_get_current_value_in_private_after_change();
+```
+
+Takes no parameters.
+
+### test_get_current_value_in_private_with_non_initial_delay
+
+```rust
+test_get_current_value_in_private_with_non_initial_delay();
+```
+
+Takes no parameters.
+
+### test_get_current_value_in_unconstrained_initial
+
+```rust
+test_get_current_value_in_unconstrained_initial();
+```
+
+Takes no parameters.
+
+### test_get_current_value_in_unconstrained_before_scheduled_change
+
+```rust
+test_get_current_value_in_unconstrained_before_scheduled_change();
+```
+
+Takes no parameters.
+
+### test_get_current_value_in_unconstrained_at_scheduled_change
+
+```rust
+test_get_current_value_in_unconstrained_at_scheduled_change();
+```
+
+Takes no parameters.
+
+### test_get_current_value_in_unconstrained_after_scheduled_change
+
+```rust
+test_get_current_value_in_unconstrained_after_scheduled_change();
+```
+
+Takes no parameters.
+
diff --git a/docs/versioned_docs/version-v0.82.2-alpha-testnet.5/developers/reference/smart_contract_reference/aztec-nr/aztec/state_vars/storage.md b/docs/versioned_docs/version-v0.82.2-alpha-testnet.5/developers/reference/smart_contract_reference/aztec-nr/aztec/state_vars/storage.md
new file mode 100644
index 000000000000..4ba439af50c8
--- /dev/null
+++ b/docs/versioned_docs/version-v0.82.2-alpha-testnet.5/developers/reference/smart_contract_reference/aztec-nr/aztec/state_vars/storage.md
@@ -0,0 +1,22 @@
+# Storable
+
+Struct representing an exportable storage variable in the contract Every entry in the storage struct will be exported in the compilation artifact as a Storable entity, containing the storage slot
+
+## Fields
+| Field | Type |
+| --- | --- |
+| pub slot | Field |
+
+## Standalone Functions
+
+### get_storage_slot
+
+```rust
+get_storage_slot(self);
+```
+
+#### Parameters
+| Name | Type |
+| --- | --- |
+| self | |
+
diff --git a/docs/versioned_docs/version-v0.82.2-alpha-testnet.5/developers/reference/smart_contract_reference/aztec-nr/aztec/test/helpers/cheatcodes.md b/docs/versioned_docs/version-v0.82.2-alpha-testnet.5/developers/reference/smart_contract_reference/aztec-nr/aztec/test/helpers/cheatcodes.md
new file mode 100644
index 000000000000..297d88157f14
--- /dev/null
+++ b/docs/versioned_docs/version-v0.82.2-alpha-testnet.5/developers/reference/smart_contract_reference/aztec-nr/aztec/test/helpers/cheatcodes.md
@@ -0,0 +1,312 @@
+## Standalone Functions
+
+### reset
+
+```rust
+reset();
+```
+
+Takes no parameters.
+
+### get_side_effects_counter
+
+```rust
+get_side_effects_counter();
+```
+
+Takes no parameters.
+
+### set_contract_address
+
+```rust
+set_contract_address(address);
+```
+
+#### Parameters
+| Name | Type |
+| --- | --- |
+| address | AztecAddress |
+
+### advance_blocks_by
+
+```rust
+advance_blocks_by(blocks);
+```
+
+#### Parameters
+| Name | Type |
+| --- | --- |
+| blocks | u32 |
+
+### get_private_context_inputs
+
+```rust
+get_private_context_inputs(historical_block_number, );
+```
+
+#### Parameters
+| Name | Type |
+| --- | --- |
+| historical_block_number | u32 |
+| | |
+
+### deploy
+
+```rust
+deploy(path, name, initializer, args, secret, );
+```
+
+#### Parameters
+| Name | Type |
+| --- | --- |
+| path | str<N> |
+| name | str<M> |
+| initializer | str<P> |
+| args | [Field] |
+| secret | Field |
+| | |
+
+### direct_storage_write
+
+```rust
+direct_storage_write(contract_address, storage_slot, fields, );
+```
+
+#### Parameters
+| Name | Type |
+| --- | --- |
+| contract_address | AztecAddress |
+| storage_slot | Field |
+| fields | [Field; N] |
+| | |
+
+### create_account
+
+```rust
+create_account(secret);
+```
+
+#### Parameters
+| Name | Type |
+| --- | --- |
+| secret | Field |
+
+### add_account
+
+```rust
+add_account(secret);
+```
+
+#### Parameters
+| Name | Type |
+| --- | --- |
+| secret | Field |
+
+### derive_keys
+
+```rust
+derive_keys(secret);
+```
+
+#### Parameters
+| Name | Type |
+| --- | --- |
+| secret | Field |
+
+### add_authwit
+
+```rust
+add_authwit(address, message_hash);
+```
+
+#### Parameters
+| Name | Type |
+| --- | --- |
+| address | AztecAddress |
+| message_hash | Field |
+
+### assert_public_call_fails
+
+```rust
+assert_public_call_fails(target_address, function_selector, args, );
+```
+
+#### Parameters
+| Name | Type |
+| --- | --- |
+| target_address | AztecAddress |
+| function_selector | FunctionSelector |
+| args | [Field] |
+| | |
+
+### assert_private_call_fails
+
+```rust
+assert_private_call_fails(target_address, function_selector, argsHash, sideEffectsCounter, isStaticCall, );
+```
+
+#### Parameters
+| Name | Type |
+| --- | --- |
+| target_address | AztecAddress |
+| function_selector | FunctionSelector |
+| argsHash | Field |
+| sideEffectsCounter | Field |
+| isStaticCall | bool |
+| | |
+
+### oracle_reset
+
+```rust
+oracle_reset();
+```
+
+Takes no parameters.
+
+### oracle_set_contract_address
+
+```rust
+oracle_set_contract_address(address);
+```
+
+#### Parameters
+| Name | Type |
+| --- | --- |
+| address | AztecAddress |
+
+### oracle_get_side_effects_counter
+
+```rust
+oracle_get_side_effects_counter();
+```
+
+Takes no parameters.
+
+### oracle_advance_blocks_by
+
+```rust
+oracle_advance_blocks_by(blocks);
+```
+
+#### Parameters
+| Name | Type |
+| --- | --- |
+| blocks | u32 |
+
+### oracle_get_private_context_inputs
+
+```rust
+oracle_get_private_context_inputs(historical_block_number, );
+```
+
+#### Parameters
+| Name | Type |
+| --- | --- |
+| historical_block_number | u32 |
+| | |
+
+### oracle_deploy
+
+```rust
+oracle_deploy(path, name, initializer, args, secret, );
+```
+
+#### Parameters
+| Name | Type |
+| --- | --- |
+| path | str<N> |
+| name | str<M> |
+| initializer | str<P> |
+| args | [Field] |
+| secret | Field |
+| | |
+
+### direct_storage_write_oracle
+
+```rust
+direct_storage_write_oracle(_contract_address, _storage_slot, _values, );
+```
+
+#### Parameters
+| Name | Type |
+| --- | --- |
+| _contract_address | AztecAddress |
+| _storage_slot | Field |
+| _values | [Field; N] |
+| | |
+
+### oracle_create_account
+
+```rust
+oracle_create_account(secret);
+```
+
+#### Parameters
+| Name | Type |
+| --- | --- |
+| secret | Field |
+
+### oracle_add_account
+
+```rust
+oracle_add_account(secret);
+```
+
+#### Parameters
+| Name | Type |
+| --- | --- |
+| secret | Field |
+
+### oracle_derive_keys
+
+```rust
+oracle_derive_keys(secret);
+```
+
+#### Parameters
+| Name | Type |
+| --- | --- |
+| secret | Field |
+
+### oracle_add_authwit
+
+```rust
+oracle_add_authwit(address, message_hash);
+```
+
+#### Parameters
+| Name | Type |
+| --- | --- |
+| address | AztecAddress |
+| message_hash | Field |
+
+### oracle_assert_public_call_fails
+
+```rust
+oracle_assert_public_call_fails(target_address, function_selector, args, );
+```
+
+#### Parameters
+| Name | Type |
+| --- | --- |
+| target_address | AztecAddress |
+| function_selector | FunctionSelector |
+| args | [Field] |
+| | |
+
+### oracle_assert_private_call_fails
+
+```rust
+oracle_assert_private_call_fails(target_address, function_selector, argsHash, sideEffectsCounter, isStaticCall, );
+```
+
+#### Parameters
+| Name | Type |
+| --- | --- |
+| target_address | AztecAddress |
+| function_selector | FunctionSelector |
+| argsHash | Field |
+| sideEffectsCounter | Field |
+| isStaticCall | bool |
+| | |
+
diff --git a/docs/versioned_docs/version-v0.82.2-alpha-testnet.5/developers/reference/smart_contract_reference/aztec-nr/aztec/test/helpers/test_environment.md b/docs/versioned_docs/version-v0.82.2-alpha-testnet.5/developers/reference/smart_contract_reference/aztec-nr/aztec/test/helpers/test_environment.md
new file mode 100644
index 000000000000..1577c224609d
--- /dev/null
+++ b/docs/versioned_docs/version-v0.82.2-alpha-testnet.5/developers/reference/smart_contract_reference/aztec-nr/aztec/test/helpers/test_environment.md
@@ -0,0 +1,267 @@
+# TestEnvironment
+
+## Methods
+
+### new
+
+```rust
+TestEnvironment::new();
+```
+
+Takes no parameters.
+
+### pending_block_number
+
+```rust
+TestEnvironment::pending_block_number(_self);
+```
+
+#### Parameters
+| Name | Type |
+| --- | --- |
+| _self | Self |
+
+### block_number
+
+```rust
+TestEnvironment::block_number(self);
+```
+
+#### Parameters
+| Name | Type |
+| --- | --- |
+| self | Self |
+
+### committed_block_number
+
+```rust
+TestEnvironment::committed_block_number(self);
+```
+
+#### Parameters
+| Name | Type |
+| --- | --- |
+| self | Self |
+
+### contract_address
+
+```rust
+TestEnvironment::contract_address(_self);
+```
+
+#### Parameters
+| Name | Type |
+| --- | --- |
+| _self | Self |
+
+### impersonate
+
+```rust
+TestEnvironment::impersonate(_self, address);
+```
+
+#### Parameters
+| Name | Type |
+| --- | --- |
+| _self | Self |
+| address | AztecAddress |
+
+### advance_block_to
+
+```rust
+TestEnvironment::advance_block_to(&mut self, block_number);
+```
+
+#### Parameters
+| Name | Type |
+| --- | --- |
+| &mut self | |
+| block_number | u32 |
+
+### advance_block_by
+
+```rust
+TestEnvironment::advance_block_by(_self, blocks);
+```
+
+#### Parameters
+| Name | Type |
+| --- | --- |
+| _self | &mut Self |
+| blocks | u32 |
+
+### public
+
+```rust
+TestEnvironment::public(_self);
+```
+
+#### Parameters
+| Name | Type |
+| --- | --- |
+| _self | Self |
+
+### public_with_args_hash
+
+```rust
+TestEnvironment::public_with_args_hash(_self, args);
+```
+
+#### Parameters
+| Name | Type |
+| --- | --- |
+| _self | Self |
+| args | [Field] |
+
+### private
+
+```rust
+TestEnvironment::private(&mut self);
+```
+
+#### Parameters
+| Name | Type |
+| --- | --- |
+| &mut self | |
+
+### unkonstrained
+
+```rust
+TestEnvironment::unkonstrained(_self);
+```
+
+#### Parameters
+| Name | Type |
+| --- | --- |
+| _self | Self |
+
+### private_at
+
+```rust
+TestEnvironment::private_at(&mut self, historical_block_number);
+```
+
+#### Parameters
+| Name | Type |
+| --- | --- |
+| &mut self | |
+| historical_block_number | u32 |
+
+### create_account
+
+```rust
+TestEnvironment::create_account(_self, secret);
+```
+
+#### Parameters
+| Name | Type |
+| --- | --- |
+| _self | Self |
+| secret | Field |
+
+### create_account_contract
+
+```rust
+TestEnvironment::create_account_contract(&mut self, secret);
+```
+
+#### Parameters
+| Name | Type |
+| --- | --- |
+| &mut self | |
+| secret | Field |
+
+### deploy
+
+```rust
+TestEnvironment::deploy(_self, path, name, );
+```
+
+#### Parameters
+| Name | Type |
+| --- | --- |
+| _self | Self |
+| path | str<N> |
+| name | str<M> |
+| | |
+
+### deploy_self
+
+```rust
+TestEnvironment::deploy_self(_self, name);
+```
+
+#### Parameters
+| Name | Type |
+| --- | --- |
+| _self | Self |
+| name | str<M> |
+
+### deploy_with_public_keys
+
+```rust
+TestEnvironment::deploy_with_public_keys(_self, path, name, secret, );
+```
+
+#### Parameters
+| Name | Type |
+| --- | --- |
+| _self | Self |
+| path | str<N> |
+| name | str<M> |
+| secret | Field |
+| | |
+
+### deploy_self_with_public_keys
+
+```rust
+TestEnvironment::deploy_self_with_public_keys(_self, name, secret, );
+```
+
+#### Parameters
+| Name | Type |
+| --- | --- |
+| _self | Self |
+| name | str<M> |
+| secret | Field |
+| | |
+
+### assert_public_call_fails
+
+```rust
+TestEnvironment::assert_public_call_fails(_self, call_interface);
+```
+
+#### Parameters
+| Name | Type |
+| --- | --- |
+| _self | Self |
+| call_interface | C |
+
+### assert_private_call_fails
+
+```rust
+TestEnvironment::assert_private_call_fails(_self, call_interface);
+```
+
+#### Parameters
+| Name | Type |
+| --- | --- |
+| _self | Self |
+| call_interface | C |
+
+### add_note
+
+```rust
+TestEnvironment::add_note(_self, note, storage_slot, contract_address, );
+```
+
+#### Parameters
+| Name | Type |
+| --- | --- |
+| _self | Self |
+| note | Note |
+| storage_slot | Field |
+| contract_address | AztecAddress |
+| | |
+
diff --git a/docs/versioned_docs/version-v0.82.2-alpha-testnet.5/developers/reference/smart_contract_reference/aztec-nr/aztec/test/helpers/utils.md b/docs/versioned_docs/version-v0.82.2-alpha-testnet.5/developers/reference/smart_contract_reference/aztec-nr/aztec/test/helpers/utils.md
new file mode 100644
index 000000000000..f3a6beb500cb
--- /dev/null
+++ b/docs/versioned_docs/version-v0.82.2-alpha-testnet.5/developers/reference/smart_contract_reference/aztec-nr/aztec/test/helpers/utils.md
@@ -0,0 +1,60 @@
+# TestAccount
+
+## Fields
+| Field | Type |
+| --- | --- |
+| pub address | AztecAddress |
+| pub keys | PublicKeys |
+
+## Standalone Functions
+
+### with_private_initializer
+
+```rust
+with_private_initializer(self, call_interface, );
+```
+
+#### Parameters
+| Name | Type |
+| --- | --- |
+| self | |
+| call_interface | C |
+| | |
+
+### with_public_void_initializer
+
+```rust
+with_public_void_initializer(self, call_interface, );
+```
+
+#### Parameters
+| Name | Type |
+| --- | --- |
+| self | |
+| call_interface | C |
+| | |
+
+### with_public_initializer
+
+```rust
+with_public_initializer(self, call_interface, );
+```
+
+#### Parameters
+| Name | Type |
+| --- | --- |
+| self | |
+| call_interface | C |
+| | |
+
+### without_initializer
+
+```rust
+without_initializer(self);
+```
+
+#### Parameters
+| Name | Type |
+| --- | --- |
+| self | |
+
diff --git a/docs/versioned_docs/version-v0.82.2-alpha-testnet.5/developers/reference/smart_contract_reference/aztec-nr/aztec/test/mocks/mock_note.md b/docs/versioned_docs/version-v0.82.2-alpha-testnet.5/developers/reference/smart_contract_reference/aztec-nr/aztec/test/mocks/mock_note.md
new file mode 100644
index 000000000000..7210aa8d8cce
--- /dev/null
+++ b/docs/versioned_docs/version-v0.82.2-alpha-testnet.5/developers/reference/smart_contract_reference/aztec-nr/aztec/test/mocks/mock_note.md
@@ -0,0 +1,136 @@
+# MockNote
+
+## Fields
+| Field | Type |
+| --- | --- |
+| pub(crate) value | Field |
+
+## Methods
+
+### new
+
+```rust
+MockNote::new(value);
+```
+
+#### Parameters
+| Name | Type |
+| --- | --- |
+| value | Field |
+
+# MockNoteBuilder
+
+## Fields
+| Field | Type |
+| --- | --- |
+| value | Field |
+| contract_address | Option<AztecAddress> |
+| note_metadata | Option<NoteMetadata> |
+
+## Methods
+
+### new
+
+```rust
+MockNoteBuilder::new(value);
+```
+
+#### Parameters
+| Name | Type |
+| --- | --- |
+| value | Field |
+
+### contract_address
+
+```rust
+MockNoteBuilder::contract_address(&mut self, contract_address);
+```
+
+#### Parameters
+| Name | Type |
+| --- | --- |
+| &mut self | |
+| contract_address | AztecAddress |
+
+### note_metadata
+
+```rust
+MockNoteBuilder::note_metadata(&mut self, note_metadata);
+```
+
+#### Parameters
+| Name | Type |
+| --- | --- |
+| &mut self | |
+| note_metadata | NoteMetadata |
+
+### build_note
+
+```rust
+MockNoteBuilder::build_note(self);
+```
+
+#### Parameters
+| Name | Type |
+| --- | --- |
+| self | |
+
+### build_retrieved_note
+
+```rust
+MockNoteBuilder::build_retrieved_note(self);
+```
+
+#### Parameters
+| Name | Type |
+| --- | --- |
+| self | |
+
+## Standalone Functions
+
+### get_id
+
+```rust
+get_id();
+```
+
+Takes no parameters.
+
+### compute_note_hash
+
+```rust
+compute_note_hash(self, storage_slot);
+```
+
+#### Parameters
+| Name | Type |
+| --- | --- |
+| self | Self |
+| storage_slot | Field |
+
+### compute_nullifier
+
+```rust
+compute_nullifier(_self, _context, note_hash_for_nullify, );
+```
+
+#### Parameters
+| Name | Type |
+| --- | --- |
+| _self | Self |
+| _context | &mut PrivateContext |
+| note_hash_for_nullify | Field |
+| | |
+
+### compute_nullifier_unconstrained
+
+```rust
+compute_nullifier_unconstrained(self, note_hash_for_nullify);
+```
+
+#### Parameters
+| Name | Type |
+| --- | --- |
+| self | |
+| note_hash_for_nullify | Field |
+
diff --git a/docs/versioned_docs/version-v0.82.2-alpha-testnet.5/developers/reference/smart_contract_reference/aztec-nr/aztec/test/mocks/mock_struct.md b/docs/versioned_docs/version-v0.82.2-alpha-testnet.5/developers/reference/smart_contract_reference/aztec-nr/aztec/test/mocks/mock_struct.md
new file mode 100644
index 000000000000..3536ea15d81d
--- /dev/null
+++ b/docs/versioned_docs/version-v0.82.2-alpha-testnet.5/developers/reference/smart_contract_reference/aztec-nr/aztec/test/mocks/mock_struct.md
@@ -0,0 +1,104 @@
+# MockStruct
+
+## Fields
+| Field | Type |
+| --- | --- |
+| pub a | Field |
+| pub b | Field |
+
+## Methods
+
+### new
+
+```rust
+MockStruct::new(a, b);
+```
+
+#### Parameters
+| Name | Type |
+| --- | --- |
+| a | Field |
+| b | Field |
+
+## Standalone Functions
+
+### eq
+
+```rust
+eq(self, other);
+```
+
+#### Parameters
+| Name | Type |
+| --- | --- |
+| self | |
+| other | Self |
+
+### empty
+
+```rust
+empty();
+```
+
+Takes no parameters.
+
+### serialize
+
+```rust
+serialize(self);
+```
+
+#### Parameters
+| Name | Type |
+| --- | --- |
+| self | |
+
+### deserialize
+
+```rust
+deserialize(fields);
+```
+
+#### Parameters
+| Name | Type |
+| --- | --- |
+| fields | [Field; 2] |
+
+### pack
+
+```rust
+pack(self);
+```
+
+#### Parameters
+| Name | Type |
+| --- | --- |
+| self | |
+
+### unpack
+
+```rust
+unpack(fields);
+```
+
+#### Parameters
+| Name | Type |
+| --- | --- |
+| fields | [Field; 2] |
+
+### test_serde
+
+```rust
+test_serde();
+```
+
+Takes no parameters.
+
+### test_packable
+
+```rust
+test_packable();
+```
+
+Takes no parameters.
+
diff --git a/docs/versioned_docs/version-v0.82.2-alpha-testnet.5/developers/reference/smart_contract_reference/aztec-nr/aztec/unencrypted_logs/unencrypted_event_emission.md b/docs/versioned_docs/version-v0.82.2-alpha-testnet.5/developers/reference/smart_contract_reference/aztec-nr/aztec/unencrypted_logs/unencrypted_event_emission.md
new file mode 100644
index 000000000000..d3f602b1a9cf
--- /dev/null
+++ b/docs/versioned_docs/version-v0.82.2-alpha-testnet.5/developers/reference/smart_contract_reference/aztec-nr/aztec/unencrypted_logs/unencrypted_event_emission.md
@@ -0,0 +1,26 @@
+## Standalone Functions
+
+### emit
+
+```rust
+emit(context, event);
+```
+
+#### Parameters
+| Name | Type |
+| --- | --- |
+| context | &mut PublicContext |
+| event | Event |
+
+### encode_event
+
+```rust
+encode_event(context, );
+```
+
+#### Parameters
+| Name | Type |
+| --- | --- |
+| context | &mut PublicContext |
+| | |
+
diff --git a/docs/versioned_docs/version-v0.82.2-alpha-testnet.5/developers/reference/smart_contract_reference/aztec-nr/aztec/utils/array/append.md b/docs/versioned_docs/version-v0.82.2-alpha-testnet.5/developers/reference/smart_contract_reference/aztec-nr/aztec/utils/array/append.md
new file mode 100644
index 000000000000..cee6e53dddb4
--- /dev/null
+++ b/docs/versioned_docs/version-v0.82.2-alpha-testnet.5/developers/reference/smart_contract_reference/aztec-nr/aztec/utils/array/append.md
@@ -0,0 +1,43 @@
+## Standalone Functions
+
+### append
+
+```rust
+append(a, A_LEN>, b, B_LEN>, );
+```
+
+/ large enough to fit all of the elements of both the first and second vectors.
+
+#### Parameters
+| Name | Type |
+| --- | --- |
+| a | BoundedVec<T |
+| A_LEN> | |
+| b | BoundedVec<T |
+| B_LEN> | |
+| | |
+
+### append_empty_vecs
+
+```rust
+append_empty_vecs();
+```
+
+Takes no parameters.
+
+### append_non_empty_vecs
+
+```rust
+append_non_empty_vecs();
+```
+
+Takes no parameters.
+
+### append_non_empty_vecs_insufficient_max_len
+
+```rust
+append_non_empty_vecs_insufficient_max_len();
+```
+
+Takes no parameters.
+
diff --git a/docs/versioned_docs/version-v0.82.2-alpha-testnet.5/developers/reference/smart_contract_reference/aztec-nr/aztec/utils/array/collapse.md b/docs/versioned_docs/version-v0.82.2-alpha-testnet.5/developers/reference/smart_contract_reference/aztec-nr/aztec/utils/array/collapse.md
new file mode 100644
index 000000000000..4aadedd2a54a
--- /dev/null
+++ b/docs/versioned_docs/version-v0.82.2-alpha-testnet.5/developers/reference/smart_contract_reference/aztec-nr/aztec/utils/array/collapse.md
@@ -0,0 +1,147 @@
+## Standalone Functions
+
+### collapse
+
+```rust
+collapse(input);
+```
+
+/ `collapsed: [3, 1]`
+
+#### Parameters
+| Name | Type |
+| --- | --- |
+| input | [Option<T>; N] |
+
+### verify_collapse_hints
+
+```rust
+verify_collapse_hints(input, collapsed, N>, collapsed_to_input_index_mapping, N>, );
+```
+
+#### Parameters
+| Name | Type |
+| --- | --- |
+| input | [Option<T>; N] |
+| collapsed | BoundedVec<T |
+| N> | |
+| collapsed_to_input_index_mapping | BoundedVec<u32 |
+| N> | |
+| | |
+
+### get_collapse_hints
+
+```rust
+get_collapse_hints(input, );
+```
+
+#### Parameters
+| Name | Type |
+| --- | --- |
+| input | [Option<T>; N] |
+| | |
+
+### collapse_empty_array
+
+```rust
+collapse_empty_array();
+```
+
+Takes no parameters.
+
+### collapse_non_sparse_array
+
+```rust
+collapse_non_sparse_array();
+```
+
+Takes no parameters.
+
+### collapse_sparse_array
+
+```rust
+collapse_sparse_array();
+```
+
+Takes no parameters.
+
+### collapse_front_padding
+
+```rust
+collapse_front_padding();
+```
+
+Takes no parameters.
+
+### collapse_back_padding
+
+```rust
+collapse_back_padding();
+```
+
+Takes no parameters.
+
+### verify_collapse_hints_good_hints
+
+```rust
+verify_collapse_hints_good_hints();
+```
+
+Takes no parameters.
+
+### verify_collapse_hints_wrong_length
+
+```rust
+verify_collapse_hints_wrong_length();
+```
+
+Takes no parameters.
+
+### verify_collapse_hints_hint_length_mismatch
+
+```rust
+verify_collapse_hints_hint_length_mismatch();
+```
+
+Takes no parameters.
+
+### verify_collapse_hints_out_of_bounds_index_hint
+
+```rust
+verify_collapse_hints_out_of_bounds_index_hint();
+```
+
+Takes no parameters.
+
+### verify_collapse_hints_hint_to_none
+
+```rust
+verify_collapse_hints_hint_to_none();
+```
+
+Takes no parameters.
+
+### verify_collapse_hints_wrong_vec_content
+
+```rust
+verify_collapse_hints_wrong_vec_content();
+```
+
+Takes no parameters.
+
+### verify_collapse_hints_wrong_vec_order
+
+```rust
+verify_collapse_hints_wrong_vec_order();
+```
+
+Takes no parameters.
+
+### verify_collapse_hints_dirty_storage
+
+```rust
+verify_collapse_hints_dirty_storage();
+```
+
+Takes no parameters.
+
diff --git a/docs/versioned_docs/version-v0.82.2-alpha-testnet.5/developers/reference/smart_contract_reference/aztec-nr/aztec/utils/array/mod.md b/docs/versioned_docs/version-v0.82.2-alpha-testnet.5/developers/reference/smart_contract_reference/aztec-nr/aztec/utils/array/mod.md
new file mode 100644
index 000000000000..8fcb48b36a3e
--- /dev/null
+++ b/docs/versioned_docs/version-v0.82.2-alpha-testnet.5/developers/reference/smart_contract_reference/aztec-nr/aztec/utils/array/mod.md
@@ -0,0 +1,16 @@
+## Standalone Functions
+
+### for_each_in_bounded_vec
+
+```rust
+for_each_in_bounded_vec(vec, MaxLen>, f, u32);
+```
+
+#### Parameters
+| Name | Type |
+| --- | --- |
+| vec | BoundedVec<T |
+| MaxLen> | |
+| f | fn[Env](T |
+| u32 | |
+
diff --git a/docs/versioned_docs/version-v0.82.2-alpha-testnet.5/developers/reference/smart_contract_reference/aztec-nr/aztec/utils/array/subarray.md b/docs/versioned_docs/version-v0.82.2-alpha-testnet.5/developers/reference/smart_contract_reference/aztec-nr/aztec/utils/array/subarray.md
new file mode 100644
index 000000000000..ae6406eead89
--- /dev/null
+++ b/docs/versioned_docs/version-v0.82.2-alpha-testnet.5/developers/reference/smart_contract_reference/aztec-nr/aztec/utils/array/subarray.md
@@ -0,0 +1,57 @@
+## Standalone Functions
+
+### subarray
+
+```rust
+subarray(src, offset, );
+```
+
+/ ```
+
+#### Parameters
+| Name | Type |
+| --- | --- |
+| src | [T; SRC_LEN] |
+| offset | u32 |
+| | |
+
+### subarray_into_empty
+
+```rust
+subarray_into_empty();
+```
+
+Takes no parameters.
+
+### subarray_complete
+
+```rust
+subarray_complete();
+```
+
+Takes no parameters.
+
+### subarray_different_end_sizes
+
+```rust
+subarray_different_end_sizes();
+```
+
+Takes no parameters.
+
+### subarray_offset_too_large
+
+```rust
+subarray_offset_too_large();
+```
+
+Takes no parameters.
+
+### subarray_bad_return_value
+
+```rust
+subarray_bad_return_value();
+```
+
+Takes no parameters.
+
diff --git a/docs/versioned_docs/version-v0.82.2-alpha-testnet.5/developers/reference/smart_contract_reference/aztec-nr/aztec/utils/array/subbvec.md b/docs/versioned_docs/version-v0.82.2-alpha-testnet.5/developers/reference/smart_contract_reference/aztec-nr/aztec/utils/array/subbvec.md
new file mode 100644
index 000000000000..645350dd2f10
--- /dev/null
+++ b/docs/versioned_docs/version-v0.82.2-alpha-testnet.5/developers/reference/smart_contract_reference/aztec-nr/aztec/utils/array/subbvec.md
@@ -0,0 +1,82 @@
+## Standalone Functions
+
+### subbvec
+
+```rust
+subbvec(bvec, SRC_MAX_LEN>, offset, );
+```
+
+/ ```
+
+#### Parameters
+| Name | Type |
+| --- | --- |
+| bvec | BoundedVec<T |
+| SRC_MAX_LEN> | |
+| offset | u32 |
+| | |
+
+### subbvec_empty
+
+```rust
+subbvec_empty();
+```
+
+Takes no parameters.
+
+### subbvec_complete
+
+```rust
+subbvec_complete();
+```
+
+Takes no parameters.
+
+### subbvec_partial
+
+```rust
+subbvec_partial();
+```
+
+Takes no parameters.
+
+### subbvec_into_empty
+
+```rust
+subbvec_into_empty();
+```
+
+Takes no parameters.
+
+### subbvec_offset_past_len
+
+```rust
+subbvec_offset_past_len();
+```
+
+Takes no parameters.
+
+### subbvec_insufficient_dst_len
+
+```rust
+subbvec_insufficient_dst_len();
+```
+
+Takes no parameters.
+
+### subbvec_dst_len_causes_enlarge
+
+```rust
+subbvec_dst_len_causes_enlarge();
+```
+
+Takes no parameters.
+
+### subbvec_dst_len_too_large_for_offset
+
+```rust
+subbvec_dst_len_too_large_for_offset();
+```
+
+Takes no parameters.
+
diff --git a/docs/versioned_docs/version-v0.82.2-alpha-testnet.5/developers/reference/smart_contract_reference/aztec-nr/aztec/utils/comparison.md b/docs/versioned_docs/version-v0.82.2-alpha-testnet.5/developers/reference/smart_contract_reference/aztec-nr/aztec/utils/comparison.md
new file mode 100644
index 000000000000..2755f026ba81
--- /dev/null
+++ b/docs/versioned_docs/version-v0.82.2-alpha-testnet.5/developers/reference/smart_contract_reference/aztec-nr/aztec/utils/comparison.md
@@ -0,0 +1,35 @@
+# ComparatorEnum
+
+## Fields
+| Field | Type |
+| --- | --- |
+| pub EQ | u8 |
+| pub NEQ | u8 |
+| pub LT | u8 |
+| pub LTE | u8 |
+| pub GT | u8 |
+| pub GTE | u8 |
+
+## Standalone Functions
+
+### compare
+
+```rust
+compare(lhs, operation, rhs);
+```
+
+#### Parameters
+| Name | Type |
+| --- | --- |
+| lhs | Field |
+| operation | u8 |
+| rhs | Field |
+
+### test_compare
+
+```rust
+test_compare();
+```
+
+Takes no parameters.
+
diff --git a/docs/versioned_docs/version-v0.82.2-alpha-testnet.5/developers/reference/smart_contract_reference/aztec-nr/aztec/utils/conversion/bytes_to_fields.md b/docs/versioned_docs/version-v0.82.2-alpha-testnet.5/developers/reference/smart_contract_reference/aztec-nr/aztec/utils/conversion/bytes_to_fields.md
new file mode 100644
index 000000000000..f7a08f0e9953
--- /dev/null
+++ b/docs/versioned_docs/version-v0.82.2-alpha-testnet.5/developers/reference/smart_contract_reference/aztec-nr/aztec/utils/conversion/bytes_to_fields.md
@@ -0,0 +1,48 @@
+## Standalone Functions
+
+### bytes_to_fields
+
+```rust
+bytes_to_fields(bytes);
+```
+
+/ Note: N must be a multiple of 31 bytes
+
+#### Parameters
+| Name | Type |
+| --- | --- |
+| bytes | [u8; N] |
+
+### bytes_from_fields
+
+```rust
+bytes_from_fields(fields, N>);
+```
+
+/ back together in the order of the original fields.
+
+#### Parameters
+| Name | Type |
+| --- | --- |
+| fields | BoundedVec<Field |
+| N> | |
+
+### random_bytes_to_fields_and_back
+
+```rust
+random_bytes_to_fields_and_back(input);
+```
+
+#### Parameters
+| Name | Type |
+| --- | --- |
+| input | [u8; 93] |
+
+### bytes_to_fields_input_length_not_multiple_of_31
+
+```rust
+bytes_to_fields_input_length_not_multiple_of_31();
+```
+
+Takes no parameters.
+
diff --git a/docs/versioned_docs/version-v0.82.2-alpha-testnet.5/developers/reference/smart_contract_reference/aztec-nr/aztec/utils/conversion/fields_to_bytes.md b/docs/versioned_docs/version-v0.82.2-alpha-testnet.5/developers/reference/smart_contract_reference/aztec-nr/aztec/utils/conversion/fields_to_bytes.md
new file mode 100644
index 000000000000..8d68f95f9ddc
--- /dev/null
+++ b/docs/versioned_docs/version-v0.82.2-alpha-testnet.5/developers/reference/smart_contract_reference/aztec-nr/aztec/utils/conversion/fields_to_bytes.md
@@ -0,0 +1,67 @@
+## Standalone Functions
+
+### fields_to_bytes
+
+```rust
+fields_to_bytes(fields);
+```
+
+/ indistinguishable from random bytes.
+
+#### Parameters
+| Name | Type |
+| --- | --- |
+| fields | [Field; N] |
+
+### fields_from_bytes
+
+```rust
+fields_from_bytes(bytes, N>);
+```
+
+/ Note 2: The max value check code was taken from std::field::to_be_bytes function.
+
+#### Parameters
+| Name | Type |
+| --- | --- |
+| bytes | BoundedVec<u8 |
+| N> | |
+
+### random_fields_to_bytes_and_back
+
+```rust
+random_fields_to_bytes_and_back(input);
+```
+
+#### Parameters
+| Name | Type |
+| --- | --- |
+| input | [Field; 3] |
+
+### to_fields_assert
+
+```rust
+to_fields_assert();
+```
+
+Takes no parameters.
+
+### fields_from_bytes_max_value
+
+```rust
+fields_from_bytes_max_value();
+```
+
+Takes no parameters.
+
+### fields_from_bytes_overflow
+
+```rust
+fields_from_bytes_overflow(random_value);
+```
+
+#### Parameters
+| Name | Type |
+| --- | --- |
+| random_value | u8 |
+
diff --git a/docs/versioned_docs/version-v0.82.2-alpha-testnet.5/developers/reference/smart_contract_reference/aztec-nr/aztec/utils/field.md b/docs/versioned_docs/version-v0.82.2-alpha-testnet.5/developers/reference/smart_contract_reference/aztec-nr/aztec/utils/field.md
new file mode 100644
index 000000000000..28beaf1b4a45
--- /dev/null
+++ b/docs/versioned_docs/version-v0.82.2-alpha-testnet.5/developers/reference/smart_contract_reference/aztec-nr/aztec/utils/field.md
@@ -0,0 +1,166 @@
+## Standalone Functions
+
+### pow
+
+```rust
+pow(x, y);
+```
+
+Adapted from std::field::pow_32.
+
+#### Parameters
+| Name | Type |
+| --- | --- |
+| x | Field |
+| y | Field |
+
+### is_square
+
+```rust
+is_square(x);
+```
+
+#### Parameters
+| Name | Type |
+| --- | --- |
+| x | Field |
+
+### tonelli_shanks_sqrt
+
+```rust
+tonelli_shanks_sqrt(x);
+```
+
+#### Parameters
+| Name | Type |
+| --- | --- |
+| x | Field |
+
+### __sqrt
+
+```rust
+__sqrt(x);
+```
+
+#### Parameters
+| Name | Type |
+| --- | --- |
+| x | Field |
+
+### sqrt
+
+```rust
+sqrt(x);
+```
+
+Returns (true, sqrt) if there is a square root.
+
+#### Parameters
+| Name | Type |
+| --- | --- |
+| x | Field |
+
+### validate_sqrt_hint
+
+```rust
+validate_sqrt_hint(x, hint);
+```
+
+#### Parameters
+| Name | Type |
+| --- | --- |
+| x | Field |
+| hint | Field |
+
+### validate_not_sqrt_hint
+
+```rust
+validate_not_sqrt_hint(x, hint);
+```
+
+#### Parameters
+| Name | Type |
+| --- | --- |
+| x | Field |
+| hint | Field |
+
+### test_sqrt
+
+```rust
+test_sqrt();
+```
+
+Takes no parameters.
+
+### test_non_square
+
+```rust
+test_non_square();
+```
+
+Takes no parameters.
+
+### test_known_non_residue_is_actually_a_non_residue_in_the_field
+
+```rust
+test_known_non_residue_is_actually_a_non_residue_in_the_field();
+```
+
+Takes no parameters.
+
+### test_sqrt_0
+
+```rust
+test_sqrt_0();
+```
+
+Takes no parameters.
+
+### test_sqrt_1
+
+```rust
+test_sqrt_1();
+```
+
+Takes no parameters.
+
+### test_bad_sqrt_hint_fails
+
+```rust
+test_bad_sqrt_hint_fails();
+```
+
+Takes no parameters.
+
+### test_bad_not_sqrt_hint_fails
+
+```rust
+test_bad_not_sqrt_hint_fails();
+```
+
+Takes no parameters.
+
+### test_0_not_sqrt_hint_fails
+
+```rust
+test_0_not_sqrt_hint_fails();
+```
+
+Takes no parameters.
+
+### test_is_square
+
+```rust
+test_is_square();
+```
+
+Takes no parameters.
+
+### test_is_not_square
+
+```rust
+test_is_not_square();
+```
+
+Takes no parameters.
+
diff --git a/docs/versioned_docs/version-v0.82.2-alpha-testnet.5/developers/reference/smart_contract_reference/aztec-nr/aztec/utils/point.md b/docs/versioned_docs/version-v0.82.2-alpha-testnet.5/developers/reference/smart_contract_reference/aztec-nr/aztec/utils/point.md
new file mode 100644
index 000000000000..2c25553784d2
--- /dev/null
+++ b/docs/versioned_docs/version-v0.82.2-alpha-testnet.5/developers/reference/smart_contract_reference/aztec-nr/aztec/utils/point.md
@@ -0,0 +1,75 @@
+## Standalone Functions
+
+### point_to_bytes
+
+```rust
+point_to_bytes(p);
+```
+
+/ to waste the extra byte (encrypted log).
+
+#### Parameters
+| Name | Type |
+| --- | --- |
+| p | Point |
+
+### get_sign_of_point
+
+```rust
+get_sign_of_point(p);
+```
+
+#### Parameters
+| Name | Type |
+| --- | --- |
+| p | Point |
+
+### point_from_x_coord
+
+```rust
+point_from_x_coord(x);
+```
+
+#### Parameters
+| Name | Type |
+| --- | --- |
+| x | Field |
+
+### point_from_x_coord_and_sign
+
+```rust
+point_from_x_coord_and_sign(x, sign);
+```
+
+/ @param sign - The "sign" of the y coordinate - determines whether y <= (Fr.MODULUS - 1) / 2
+
+#### Parameters
+| Name | Type |
+| --- | --- |
+| x | Field |
+| sign | bool |
+
+### test_point_to_bytes_positive_sign
+
+```rust
+test_point_to_bytes_positive_sign();
+```
+
+Takes no parameters.
+
+### test_point_to_bytes_negative_sign
+
+```rust
+test_point_to_bytes_negative_sign();
+```
+
+Takes no parameters.
+
+### test_point_from_x_coord_and_sign
+
+```rust
+test_point_from_x_coord_and_sign();
+```
+
+Takes no parameters.
+
diff --git a/docs/versioned_docs/version-v0.82.2-alpha-testnet.5/developers/reference/smart_contract_reference/aztec-nr/aztec/utils/random.md b/docs/versioned_docs/version-v0.82.2-alpha-testnet.5/developers/reference/smart_contract_reference/aztec-nr/aztec/utils/random.md
new file mode 100644
index 000000000000..f9c8315ce4fe
--- /dev/null
+++ b/docs/versioned_docs/version-v0.82.2-alpha-testnet.5/developers/reference/smart_contract_reference/aztec-nr/aztec/utils/random.md
@@ -0,0 +1,10 @@
+## Standalone Functions
+
+### get_random_bytes
+
+```rust
+get_random_bytes();
+```
+
+Takes no parameters.
+
diff --git a/docs/versioned_docs/version-v0.82.2-alpha-testnet.5/developers/reference/smart_contract_reference/aztec-nr/aztec/utils/secrets.md b/docs/versioned_docs/version-v0.82.2-alpha-testnet.5/developers/reference/smart_contract_reference/aztec-nr/aztec/utils/secrets.md
new file mode 100644
index 000000000000..9cc5d82705d7
--- /dev/null
+++ b/docs/versioned_docs/version-v0.82.2-alpha-testnet.5/developers/reference/smart_contract_reference/aztec-nr/aztec/utils/secrets.md
@@ -0,0 +1,18 @@
+# SecretAndHash
+
+## Fields
+| Field | Type |
+| --- | --- |
+| secret | Field |
+| hash | Field |
+
+## Methods
+
+### random
+
+```rust
+SecretAndHash::random();
+```
+
+Takes no parameters.
+
diff --git a/docs/versioned_docs/version-v0.82.2-alpha-testnet.5/developers/reference/smart_contract_reference/aztec-nr/aztec/utils/to_bytes.md b/docs/versioned_docs/version-v0.82.2-alpha-testnet.5/developers/reference/smart_contract_reference/aztec-nr/aztec/utils/to_bytes.md
new file mode 100644
index 000000000000..215eb5c7d159
--- /dev/null
+++ b/docs/versioned_docs/version-v0.82.2-alpha-testnet.5/developers/reference/smart_contract_reference/aztec-nr/aztec/utils/to_bytes.md
@@ -0,0 +1,26 @@
+## Standalone Functions
+
+### arr_to_be_bytes_arr
+
+```rust
+arr_to_be_bytes_arr(fields);
+```
+
+#### Parameters
+| Name | Type |
+| --- | --- |
+| fields | [Field; L] |
+
+### str_to_be_bytes_arr
+
+```rust
+str_to_be_bytes_arr(string);
+```
+
+then an ACVM field via the oracle => we recreate here
+
+#### Parameters
+| Name | Type |
+| --- | --- |
+| string | str<L> |
+
diff --git a/docs/versioned_docs/version-v0.82.2-alpha-testnet.5/developers/reference/smart_contract_reference/aztec-nr/aztec/utils/with_hash.md b/docs/versioned_docs/version-v0.82.2-alpha-testnet.5/developers/reference/smart_contract_reference/aztec-nr/aztec/utils/with_hash.md
new file mode 100644
index 000000000000..4ed8cb274b1c
--- /dev/null
+++ b/docs/versioned_docs/version-v0.82.2-alpha-testnet.5/developers/reference/smart_contract_reference/aztec-nr/aztec/utils/with_hash.md
@@ -0,0 +1,136 @@
+## Standalone Functions
+
+### new
+
+```rust
+new(value);
+```
+
+#### Parameters
+| Name | Type |
+| --- | --- |
+| value | T |
+
+### get_value
+
+```rust
+get_value(self);
+```
+
+#### Parameters
+| Name | Type |
+| --- | --- |
+| self | |
+
+### get_hash
+
+```rust
+get_hash(self);
+```
+
+#### Parameters
+| Name | Type |
+| --- | --- |
+| self | |
+
+### public_storage_read
+
+```rust
+public_storage_read(context, storage_slot);
+```
+
+#### Parameters
+| Name | Type |
+| --- | --- |
+| context | PublicContext |
+| storage_slot | Field |
+
+### unconstrained_public_storage_read
+
+```rust
+unconstrained_public_storage_read(context, storage_slot, );
+```
+
+#### Parameters
+| Name | Type |
+| --- | --- |
+| context | UnconstrainedContext |
+| storage_slot | Field |
+| | |
+
+### historical_public_storage_read
+
+```rust
+historical_public_storage_read(header, address, storage_slot, );
+```
+
+#### Parameters
+| Name | Type |
+| --- | --- |
+| header | BlockHeader |
+| address | AztecAddress |
+| storage_slot | Field |
+| | |
+
+### pack
+
+```rust
+pack(self);
+```
+
+#### Parameters
+| Name | Type |
+| --- | --- |
+| self | |
+
+### unpack
+
+```rust
+unpack(packed);
+```
+
+#### Parameters
+| Name | Type |
+| --- | --- |
+| packed | [Field; N + 1] |
+
+### create_and_recover
+
+```rust
+create_and_recover();
+```
+
+Takes no parameters.
+
+### read_uninitialized_value
+
+```rust
+read_uninitialized_value();
+```
+
+Takes no parameters.
+
+### read_initialized_value
+
+```rust
+read_initialized_value();
+```
+
+Takes no parameters.
+
+### test_bad_hint_uninitialized_value
+
+```rust
+test_bad_hint_uninitialized_value();
+```
+
+Takes no parameters.
+
+### test_bad_hint_initialized_value
+
+```rust
+test_bad_hint_initialized_value();
+```
+
+Takes no parameters.
+
diff --git a/docs/versioned_docs/version-v0.82.2-alpha-testnet.5/developers/reference/smart_contract_reference/aztec-nr/compressed-string/compressed_string.md b/docs/versioned_docs/version-v0.82.2-alpha-testnet.5/developers/reference/smart_contract_reference/aztec-nr/compressed-string/compressed_string.md
new file mode 100644
index 000000000000..d4716b947670
--- /dev/null
+++ b/docs/versioned_docs/version-v0.82.2-alpha-testnet.5/developers/reference/smart_contract_reference/aztec-nr/compressed-string/compressed_string.md
@@ -0,0 +1,99 @@
+## Standalone Functions
+
+### from_string
+
+```rust
+from_string(input_string);
+```
+
+#### Parameters
+| Name | Type |
+| --- | --- |
+| input_string | str<M> |
+
+### to_bytes
+
+```rust
+to_bytes(self);
+```
+
+#### Parameters
+| Name | Type |
+| --- | --- |
+| self | |
+
+### eq
+
+```rust
+eq(self, other, M>);
+```
+
+#### Parameters
+| Name | Type |
+| --- | --- |
+| self | |
+| other | CompressedString<N |
+| M> | |
+
+### serialize
+
+```rust
+serialize(self);
+```
+
+#### Parameters
+| Name | Type |
+| --- | --- |
+| self | |
+
+### deserialize
+
+```rust
+deserialize(input);
+```
+
+#### Parameters
+| Name | Type |
+| --- | --- |
+| input | [Field; N] |
+
+### test_short_string
+
+```rust
+test_short_string();
+```
+
+Takes no parameters.
+
+### test_long_string
+
+```rust
+test_long_string();
+```
+
+Takes no parameters.
+
+### test_long_string_work_with_too_many_fields
+
+```rust
+test_long_string_work_with_too_many_fields();
+```
+
+Takes no parameters.
+
+### test_serde
+
+```rust
+test_serde();
+```
+
+Takes no parameters.
+
+### test_long_string_fail_with_too_few_fields
+
+```rust
+test_long_string_fail_with_too_few_fields();
+```
+
+Takes no parameters.
+
diff --git a/docs/versioned_docs/version-v0.82.2-alpha-testnet.5/developers/reference/smart_contract_reference/aztec-nr/compressed-string/field_compressed_string.md b/docs/versioned_docs/version-v0.82.2-alpha-testnet.5/developers/reference/smart_contract_reference/aztec-nr/compressed-string/field_compressed_string.md
new file mode 100644
index 000000000000..5d30c34e5eaf
--- /dev/null
+++ b/docs/versioned_docs/version-v0.82.2-alpha-testnet.5/developers/reference/smart_contract_reference/aztec-nr/compressed-string/field_compressed_string.md
@@ -0,0 +1,54 @@
+# FieldCompressedString
+
+## Fields
+| Field | Type |
+| --- | --- |
+| value | Field |
+
+## Methods
+
+### is_eq
+
+```rust
+FieldCompressedString::is_eq(self, other);
+```
+
+#### Parameters
+| Name | Type |
+| --- | --- |
+| self | |
+| other | FieldCompressedString |
+
+### from_field
+
+```rust
+FieldCompressedString::from_field(input_field);
+```
+
+#### Parameters
+| Name | Type |
+| --- | --- |
+| input_field | Field |
+
+### from_string
+
+```rust
+FieldCompressedString::from_string(input_string);
+```
+
+#### Parameters
+| Name | Type |
+| --- | --- |
+| input_string | str<31> |
+
+### to_bytes
+
+```rust
+FieldCompressedString::to_bytes(self);
+```
+
+#### Parameters
+| Name | Type |
+| --- | --- |
+| self | |
+
diff --git a/docs/versioned_docs/version-v0.82.2-alpha-testnet.5/developers/reference/smart_contract_reference/aztec-nr/easy-private-state/easy_private_uint.md b/docs/versioned_docs/version-v0.82.2-alpha-testnet.5/developers/reference/smart_contract_reference/aztec-nr/easy-private-state/easy_private_uint.md
new file mode 100644
index 000000000000..2bcaf4e848ad
--- /dev/null
+++ b/docs/versioned_docs/version-v0.82.2-alpha-testnet.5/developers/reference/smart_contract_reference/aztec-nr/easy-private-state/easy_private_uint.md
@@ -0,0 +1,44 @@
+## Standalone Functions
+
+### new
+
+```rust
+new(context, storage_slot);
+```
+
+#### Parameters
+| Name | Type |
+| --- | --- |
+| context | Context |
+| storage_slot | Field |
+
+### add
+
+```rust
+add(self, addend, owner, sender);
+```
+
+Very similar to `value_note::utils::increment`.
+
+#### Parameters
+| Name | Type |
+| --- | --- |
+| self | |
+| addend | u64 |
+| owner | AztecAddress |
+| sender | AztecAddress |
+
+### sub
+
+```rust
+sub(self, subtrahend, owner, sender);
+```
+
+#### Parameters
+| Name | Type |
+| --- | --- |
+| self | |
+| subtrahend | u64 |
+| owner | AztecAddress |
+| sender | AztecAddress |
+
diff --git a/docs/versioned_docs/version-v0.82.2-alpha-testnet.5/developers/reference/smart_contract_reference/aztec-nr/macro_compilation_failure_tests/failure_contracts/marked_private_unconstrained/main.md b/docs/versioned_docs/version-v0.82.2-alpha-testnet.5/developers/reference/smart_contract_reference/aztec-nr/macro_compilation_failure_tests/failure_contracts/marked_private_unconstrained/main.md
new file mode 100644
index 000000000000..df0bdc4a3ba5
--- /dev/null
+++ b/docs/versioned_docs/version-v0.82.2-alpha-testnet.5/developers/reference/smart_contract_reference/aztec-nr/macro_compilation_failure_tests/failure_contracts/marked_private_unconstrained/main.md
@@ -0,0 +1,10 @@
+## Standalone Functions
+
+### unconstrained_private_function
+
+```rust
+unconstrained_private_function();
+```
+
+Takes no parameters.
+
diff --git a/docs/versioned_docs/version-v0.82.2-alpha-testnet.5/developers/reference/smart_contract_reference/aztec-nr/macro_compilation_failure_tests/failure_contracts/marked_public_unconstrained/main.md b/docs/versioned_docs/version-v0.82.2-alpha-testnet.5/developers/reference/smart_contract_reference/aztec-nr/macro_compilation_failure_tests/failure_contracts/marked_public_unconstrained/main.md
new file mode 100644
index 000000000000..8b5844a94f17
--- /dev/null
+++ b/docs/versioned_docs/version-v0.82.2-alpha-testnet.5/developers/reference/smart_contract_reference/aztec-nr/macro_compilation_failure_tests/failure_contracts/marked_public_unconstrained/main.md
@@ -0,0 +1,10 @@
+## Standalone Functions
+
+### unconstrained_public_function
+
+```rust
+unconstrained_public_function();
+```
+
+Takes no parameters.
+
diff --git a/docs/versioned_docs/version-v0.82.2-alpha-testnet.5/developers/reference/smart_contract_reference/aztec-nr/uint-note/uint_note.md b/docs/versioned_docs/version-v0.82.2-alpha-testnet.5/developers/reference/smart_contract_reference/aztec-nr/uint-note/uint_note.md
new file mode 100644
index 000000000000..117879825cdf
--- /dev/null
+++ b/docs/versioned_docs/version-v0.82.2-alpha-testnet.5/developers/reference/smart_contract_reference/aztec-nr/uint-note/uint_note.md
@@ -0,0 +1,208 @@
+# UintNote
+
+## Fields
+| Field | Type |
+| --- | --- |
+| owner | AztecAddress |
+| randomness | Field |
+| value | u128 |
+
+## Methods
+
+### new
+
+```rust
+UintNote::new(value, owner);
+```
+
+#### Parameters
+| Name | Type |
+| --- | --- |
+| value | u128 |
+| owner | AztecAddress |
+
+### get_value
+
+```rust
+UintNote::get_value(self);
+```
+
+#### Parameters
+| Name | Type |
+| --- | --- |
+| self | |
+
+### partial
+
+/ Creates a partial note that will hide the owner and storage slot but not the value, since the note will be later / completed in public. This is a powerful technique for scenarios in which the value cannot be known in private / (e.g. because it depends on some public state, such as a DEX). /// The returned `PartialUintNote` value must be sent to public execution via a secure channel, since it is not / possible to verify the integrity of its contents due to it hiding information. The recommended ways to do this / are to retrieve it from public storage, or to receive it in an internal public function call. /// Each partial note should only be used once, since otherwise multiple notes would be linked together and known to / belong to the same owner. /// As part of the partial note creation process, a log will be sent to `recipient` from `sender` so that they can / discover the note. `recipient` will typically be the same as `owner`.
+
+```rust
+UintNote::partial(owner, storage_slot, context, recipient, sender, );
+```
+
+#### Parameters
+| Name | Type |
+| --- | --- |
+| owner | AztecAddress |
+| storage_slot | Field |
+| context | &mut PrivateContext |
+| recipient | AztecAddress |
+| sender | AztecAddress |
+| | |
+
+# UintPartialNotePrivateContent
+
+## Fields
+| Field | Type |
+| --- | --- |
+| owner | AztecAddress |
+| randomness | Field |
+
+## Methods
+
+### compute_partial_commitment
+
+```rust
+UintPartialNotePrivateContent::compute_partial_commitment(self, storage_slot);
+```
+
+#### Parameters
+| Name | Type |
+| --- | --- |
+| self | |
+| storage_slot | Field |
+
+# PrivateUintPartialNotePrivateLogContent
+
+## Fields
+| Field | Type |
+| --- | --- |
+| public_log_tag | Field |
+| owner | AztecAddress |
+| randomness | Field |
+
+# PartialUintNote
+
+## Fields
+| Field | Type |
+| --- | --- |
+| commitment | Field |
+
+## Methods
+
+### commitment
+
+```rust
+PartialUintNote::commitment(self);
+```
+
+#### Parameters
+| Name | Type |
+| --- | --- |
+| self | |
+
+### complete
+
+/ Completes the partial note, creating a new note that can be used like any other UintNote.
+
+```rust
+PartialUintNote::complete(self, value, context);
+```
+
+#### Parameters
+| Name | Type |
+| --- | --- |
+| self | |
+| value | u128 |
+| context | &mut PublicContext |
+
+### compute_note_completion_log
+
+```rust
+PartialUintNote::compute_note_completion_log(self, value);
+```
+
+#### Parameters
+| Name | Type |
+| --- | --- |
+| self | |
+| value | u128 |
+
+### compute_complete_note_hash
+
+```rust
+PartialUintNote::compute_complete_note_hash(self, value);
+```
+
+#### Parameters
+| Name | Type |
+| --- | --- |
+| self | |
+| value | u128 |
+
+## Standalone Functions
+
+### compute_note_hash
+
+```rust
+compute_note_hash(self, storage_slot);
+```
+
+#### Parameters
+| Name | Type |
+| --- | --- |
+| self | |
+| storage_slot | Field |
+
+### compute_nullifier
+
+```rust
+compute_nullifier(self, context, note_hash_for_nullify, );
+```
+
+#[note] macro.
+
+#### Parameters
+| Name | Type |
+| --- | --- |
+| self | |
+| context | &mut PrivateContext |
+| note_hash_for_nullify | Field |
+| | |
+
+### compute_nullifier_unconstrained
+
+```rust
+compute_nullifier_unconstrained(self, note_hash_for_nullify);
+```
+
+#### Parameters
+| Name | Type |
+| --- | --- |
+| self | |
+| note_hash_for_nullify | Field |
+
+### get_id
+
+```rust
+get_id();
+```
+
+Takes no parameters.
+
+### note_hash_matches_completed_partial_note_hash
+
+```rust
+note_hash_matches_completed_partial_note_hash();
+```
+
+Takes no parameters.
+
+### unpack_from_partial_note_encoding
+
+```rust
+unpack_from_partial_note_encoding();
+```
+
+Takes no parameters.
+
diff --git a/docs/versioned_docs/version-v0.82.2-alpha-testnet.5/developers/reference/smart_contract_reference/aztec-nr/value-note/balance_utils.md b/docs/versioned_docs/version-v0.82.2-alpha-testnet.5/developers/reference/smart_contract_reference/aztec-nr/value-note/balance_utils.md
new file mode 100644
index 000000000000..92d907a67802
--- /dev/null
+++ b/docs/versioned_docs/version-v0.82.2-alpha-testnet.5/developers/reference/smart_contract_reference/aztec-nr/value-note/balance_utils.md
@@ -0,0 +1,28 @@
+## Standalone Functions
+
+### get_balance
+
+```rust
+get_balance(set, UnconstrainedContext>);
+```
+
+#### Parameters
+| Name | Type |
+| --- | --- |
+| set | PrivateSet<ValueNote |
+| UnconstrainedContext> | |
+
+### get_balance_with_offset
+
+```rust
+get_balance_with_offset(set, UnconstrainedContext>, offset, );
+```
+
+#### Parameters
+| Name | Type |
+| --- | --- |
+| set | PrivateSet<ValueNote |
+| UnconstrainedContext> | |
+| offset | u32 |
+| | |
+
diff --git a/docs/versioned_docs/version-v0.82.2-alpha-testnet.5/developers/reference/smart_contract_reference/aztec-nr/value-note/filter.md b/docs/versioned_docs/version-v0.82.2-alpha-testnet.5/developers/reference/smart_contract_reference/aztec-nr/value-note/filter.md
new file mode 100644
index 000000000000..8302a1a0be48
--- /dev/null
+++ b/docs/versioned_docs/version-v0.82.2-alpha-testnet.5/developers/reference/smart_contract_reference/aztec-nr/value-note/filter.md
@@ -0,0 +1,15 @@
+## Standalone Functions
+
+### filter_notes_min_sum
+
+```rust
+filter_notes_min_sum(notes, min_sum, );
+```
+
+#### Parameters
+| Name | Type |
+| --- | --- |
+| notes | [Option<RetrievedNote<ValueNote>>; MAX_NOTE_HASH_READ_REQUESTS_PER_CALL] |
+| min_sum | Field |
+| | |
+
diff --git a/docs/versioned_docs/version-v0.82.2-alpha-testnet.5/developers/reference/smart_contract_reference/aztec-nr/value-note/utils.md b/docs/versioned_docs/version-v0.82.2-alpha-testnet.5/developers/reference/smart_contract_reference/aztec-nr/value-note/utils.md
new file mode 100644
index 000000000000..7c3c3db432bc
--- /dev/null
+++ b/docs/versioned_docs/version-v0.82.2-alpha-testnet.5/developers/reference/smart_contract_reference/aztec-nr/value-note/utils.md
@@ -0,0 +1,66 @@
+## Standalone Functions
+
+### create_note_getter_options_for_decreasing_balance
+
+```rust
+create_note_getter_options_for_decreasing_balance(amount, );
+```
+
+Pick the fewest notes whose sum is equal to or greater than `amount`.
+
+#### Parameters
+| Name | Type |
+| --- | --- |
+| amount | Field |
+| | |
+
+### increment
+
+```rust
+increment(// docs, &mut PrivateContext>, amount, recipient, // docs, );
+```
+
+Inserts it to the recipient's set of notes.
+
+#### Parameters
+| Name | Type |
+| --- | --- |
+| // docs | start |
+| &mut PrivateContext> | |
+| amount | Field |
+| recipient | AztecAddress |
+| // docs | end |
+| | |
+
+### decrement
+
+```rust
+decrement(balance, &mut PrivateContext>, amount, owner, sender, );
+```
+
+#### Parameters
+| Name | Type |
+| --- | --- |
+| balance | PrivateSet<ValueNote |
+| &mut PrivateContext> | |
+| amount | Field |
+| owner | AztecAddress |
+| sender | AztecAddress |
+| | |
+
+### decrement_by_at_most
+
+```rust
+decrement_by_at_most(balance, &mut PrivateContext>, max_amount, owner, sender, );
+```
+
+#### Parameters
+| Name | Type |
+| --- | --- |
+| balance | PrivateSet<ValueNote |
+| &mut PrivateContext> | |
+| max_amount | Field |
+| owner | AztecAddress |
+| sender | AztecAddress |
+| | |
+
diff --git a/docs/versioned_docs/version-v0.82.2-alpha-testnet.5/developers/reference/smart_contract_reference/aztec-nr/value-note/value_note.md b/docs/versioned_docs/version-v0.82.2-alpha-testnet.5/developers/reference/smart_contract_reference/aztec-nr/value-note/value_note.md
new file mode 100644
index 000000000000..b6166af3bf68
--- /dev/null
+++ b/docs/versioned_docs/version-v0.82.2-alpha-testnet.5/developers/reference/smart_contract_reference/aztec-nr/value-note/value_note.md
@@ -0,0 +1,34 @@
+# ValueNote
+
+## Fields
+| Field | Type |
+| --- | --- |
+| value | Field |
+| owner | AztecAddress |
+| randomness | Field |
+
+## Methods
+
+### new
+
+```rust
+ValueNote::new(value, owner);
+```
+
+#### Parameters
+| Name | Type |
+| --- | --- |
+| value | Field |
+| owner | AztecAddress |
+
+### value
+
+```rust
+ValueNote::value(self);
+```
+
+#### Parameters
+| Name | Type |
+| --- | --- |
+| self | |
+
diff --git a/docs/versioned_docs/version-v0.82.2-alpha-testnet.5/developers/reference/smart_contract_reference/contract_artifact.md b/docs/versioned_docs/version-v0.82.2-alpha-testnet.5/developers/reference/smart_contract_reference/contract_artifact.md
new file mode 100644
index 000000000000..9c9fbbce73c0
--- /dev/null
+++ b/docs/versioned_docs/version-v0.82.2-alpha-testnet.5/developers/reference/smart_contract_reference/contract_artifact.md
@@ -0,0 +1,110 @@
+---
+title: "Contract Artifact Reference"
+tags: [contracts]
+---
+
+After compiling a contract you'll get a Contract Artifact file, that contains the data needed to interact with a specific contract, including its name, functions that can be executed, and the interface and code of those functions. Since private functions are not published in the Aztec network, you'll need this artifact file to be able to call private functions of contracts.
+
+The artifact file can be used with `aztec.js` to instantiate contract objects and interact with them.
+
+## Contract Artifact Structure
+
+The structure of a contract artifact is as follows:
+```json
+{
+ "name": "CardGame",
+ "functions": [
+ {
+ "name": "constructor",
+ "functionType": "private",
+ "isInternal": false,
+ "parameters": [],
+ "returnTypes": [],
+ "bytecode": "...",
+ "verificationKey": "..."
+ },
+ {
+ "name": "on_card_played",
+ "functionType": "public",
+ "isInternal": true,
+ "parameters": [
+ {
+ "name": "game",
+ "type": {
+ "kind": "integer",
+ "sign": "unsigned",
+ "width": 32
+ },
+ "visibility": "private"
+ },
+ {
+ "name": "player",
+ "type": {
+ "kind": "field"
+ },
+ "visibility": "private"
+ },
+ {
+ "name": "card_as_field",
+ "type": {
+ "kind": "field"
+ },
+ "visibility": "private"
+ }
+ ],
+ "returnTypes": [
+ ...
+ ],
+ "bytecode": "...",
+ "verificationKey": "..."
+ },
+ ...
+ ]
+}
+
+```
+
+### `name`
+It is a simple string that matches the name that the contract developer used for this contract in noir. It's used for logs and errors.
+
+### `functions`
+A contract is a collection of several functions that can be called. Each function has the following properties:
+
+#### `function.name`
+A simple string that matches the name that the contract developer used for this function in noir. For logging and debugging purposes.
+
+#### `function.functionType`
+The function type can have one of the following values:
+
+- Private: The function is ran and proved locally by the clients, and its bytecode not published to the network.
+- Public: The function is ran and proved by the sequencer, and its bytecode is published to the network.
+- Unconstrained: The function is ran locally by the clients to generate digested information useful for the user. It's not meant to be transacted against.
+
+#### `function.isInternal`
+The is internal property is a boolean that indicates whether the function is internal to the contract and cannot be called from outside.
+
+#### `function.parameters`
+Each function can have multiple parameters that are arguments to execute the function. Parameters have a name, and type (like integers, strings, or complex types like arrays and structures).
+
+#### `function.returnTypes`
+The return types property defines the types of values that the function returns after execution.
+
+#### `function.bytecode`
+The bytecode is a string representing the compiled ACIR of the function, ready for execution on the network.
+
+#### `function.verificationKey`
+The verification key is an optional property that contains the verification key of the function. This key is used to verify the proof of the function execution.
+
+### `debug` (Optional)
+Although not significant for non-developer users, it is worth mentioning that there is a debug section in the contract artifact which helps contract developers to debug and test their contracts. This section mainly contains debug symbols and file maps that link back to the original source code.
+
+## Understanding Parameter and Return Types
+To make the most of the functions, it's essential to understand the types of parameters and return values. Here are some common types you might encounter:
+
+ - `field`: A basic type representing a field element in the finite field of the curve used in the Aztec protocol.
+ - `boolean`: A simple true/false value.
+ - `integer`: Represents whole numbers. It has attributes defining its sign (positive or negative) and width (the number of bits representing the integer).
+ - `array`: Represents a collection of elements, all of the same type. It has attributes defining its length and the type of elements it holds.
+ - `string`: Represents a sequence of characters with a specified length.
+ - `struct`: A complex type representing a structure with various fields, each having a specific type and name.
+
diff --git a/docs/versioned_docs/version-v0.82.2-alpha-testnet.5/developers/reference/smart_contract_reference/dependencies.md b/docs/versioned_docs/version-v0.82.2-alpha-testnet.5/developers/reference/smart_contract_reference/dependencies.md
new file mode 100644
index 000000000000..0ec28c2686b9
--- /dev/null
+++ b/docs/versioned_docs/version-v0.82.2-alpha-testnet.5/developers/reference/smart_contract_reference/dependencies.md
@@ -0,0 +1,55 @@
+---
+title: Importing Aztec.nr
+tags: [contracts]
+sidebar_position: 5
+---
+
+On this page you will find information about Aztec.nr libraries and up-to-date paths for use in your `Nargo.toml`.
+
+## Aztec
+
+```toml
+aztec = { git="https://github.com/AztecProtocol/aztec-packages/", tag="v0.82.2", directory="noir-projects/aztec-nr/aztec" }
+```
+
+This is the core Aztec library that is required for every Aztec.nr smart contract.
+
+## Authwit
+
+```toml
+authwit = { git="https://github.com/AztecProtocol/aztec-packages/", tag="v0.82.2", directory="noir-projects/aztec-nr/authwit"}
+```
+
+This allows you to use authentication witnesses in your contract. Read a guide of how to use it [here](../../guides/smart_contracts/writing_contracts/authwit.md).
+
+## Address note
+
+```toml
+address_note = { git="https://github.com/AztecProtocol/aztec-packages/", tag="v0.82.2", directory="noir-projects/aztec-nr/address-note" }
+```
+
+This is a library for utilizing notes that hold addresses. Find it on [GitHub](https://github.com/AztecProtocol/aztec-packages/tree/master/noir-projects/aztec-nr/address-note/src).
+
+## Easy private state
+
+```toml
+easy_private_state = { git="https://github.com/AztecProtocol/aztec-packages/", tag="v0.82.2", directory="noir-projects/aztec-nr/easy-private-state" }
+```
+
+This is an abstraction library for using private variables like [`EasyPrivateUint` (GitHub link)](https://github.com/AztecProtocol/aztec-packages/blob/6c20b45993ee9cbd319ab8351e2722e0c912f427/noir-projects/aztec-nr/easy-private-state/src/easy_private_state.nr#L17).
+
+## Protocol Types
+
+```toml
+protocol_types = { git="https://github.com/AztecProtocol/aztec-packages/", tag="v0.82.2", directory="noir-projects/noir-protocol-circuits/crates/types"}
+```
+
+This library contains types that are used in the Aztec protocol. Find it on [GitHub](https://github.com/AztecProtocol/aztec-packages/tree/master/noir-projects/noir-protocol-circuits/crates/types/src).
+
+## Value note
+
+```toml
+value_note = { git="https://github.com/AztecProtocol/aztec-packages/", tag="v0.82.2", directory="noir-projects/aztec-nr/value-note" }
+```
+
+This is a library for a note that stores one arbitrary value. You can see an example of how it might be used in the [crowdfunding contract codealong tutorial](../../tutorials/codealong/contract_tutorials/crowdfunding_contract.md).
diff --git a/docs/versioned_docs/version-v0.82.2-alpha-testnet.5/developers/reference/smart_contract_reference/globals.md b/docs/versioned_docs/version-v0.82.2-alpha-testnet.5/developers/reference/smart_contract_reference/globals.md
new file mode 100644
index 000000000000..88580df40866
--- /dev/null
+++ b/docs/versioned_docs/version-v0.82.2-alpha-testnet.5/developers/reference/smart_contract_reference/globals.md
@@ -0,0 +1,86 @@
+---
+title: Global Variables
+description: Documentation of Aztec's Global Variables in the Public and Private Contexts
+sidebar_position: 2
+---
+
+# Global Variables
+
+For developers coming from solidity, this concept will be similar to how the global `block` variable exposes a series of block values. The idea is the same in Aztec. Developers can access a namespace of values made available in each function.
+
+`Aztec` has two execution environments, Private and Public. Each execution environment contains a different global variables object.
+
+## Private Global Variables
+
+```rust title="tx-context" showLineNumbers
+pub struct TxContext {
+ pub chain_id: Field,
+ pub version: Field,
+ pub gas_settings: GasSettings,
+}
+```
+> Source code: noir-projects/noir-protocol-circuits/crates/types/src/transaction/tx_context.nr#L8-L14
+
+
+The private global variables are equal to the transaction context and contain:
+
+### Chain Id
+
+The chain id differs depending on which Aztec instance you are on ( NOT the Ethereum hardfork that the rollup is settling to ). On original deployment of the network, this value will be 1.
+
+```rust
+context.chain_id();
+```
+
+### Version
+
+The version number indicates which Aztec hardfork you are on. The Genesis block of the network will have the version number 1.
+
+```rust
+context.version();
+```
+
+### Gas Settings
+
+The gas limits set by the user for the transaction, the max fee per gas, and the inclusion fee.
+
+## Public Global Variables
+
+```rust title="global-variables" showLineNumbers
+pub struct GlobalVariables {
+ pub chain_id: Field,
+ pub version: Field,
+ pub block_number: Field,
+ pub slot_number: Field,
+ pub timestamp: u64,
+ pub coinbase: EthAddress,
+ pub fee_recipient: AztecAddress,
+ pub gas_fees: GasFees,
+}
+```
+> Source code: noir-projects/noir-protocol-circuits/crates/types/src/abis/global_variables.nr#L9-L20
+
+
+The public global variables contain the values present in the `private global variables` described above, with the addition of:
+
+### Timestamp
+
+The timestamp is the unix timestamp in which the block has been executed. The value is provided by the block's proposer (therefore can have variance). This value will always increase.
+
+```rust
+context.timestamp();
+```
+
+### Block Number
+
+The block number is a sequential identifier that labels each individual block of the network. This value will be the block number of the block the accessing transaction is included in.
+The block number of the genesis block will be 1, with the number increasing by 1 for every block after.
+
+```rust
+context.block_number();
+```
+
+:::info _Why do the available global variables differ per execution environment?_
+The global variables are constrained by the proving environment. In the case of public functions, they are executed on a sequencer that will know the timestamp and number of the next block ( as they are the block producer ).
+In the case of private functions, we cannot be sure which block our transaction will be included in, hence we can not guarantee values for the timestamp or block number.
+:::
diff --git a/docs/versioned_docs/version-v0.82.2-alpha-testnet.5/developers/reference/smart_contract_reference/macros.md b/docs/versioned_docs/version-v0.82.2-alpha-testnet.5/developers/reference/smart_contract_reference/macros.md
new file mode 100644
index 000000000000..cabe9000e99c
--- /dev/null
+++ b/docs/versioned_docs/version-v0.82.2-alpha-testnet.5/developers/reference/smart_contract_reference/macros.md
@@ -0,0 +1,22 @@
+---
+title: Aztec macros
+sidebar_position: 6
+tags: [contracts, functions]
+---
+
+## All Aztec macros
+
+In addition to the function macros in Noir, Aztec also has its own macros for specific functions. An Aztec contract function can be annotated with more than 1 macro.
+It is also worth mentioning Noir's `unconstrained` function type [here (Noir docs page)](https://noir-lang.org/docs/noir/concepts/unconstrained/).
+
+- `#[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-initializer functions
+- `#[noinitcheck]` - The function is able to be called before an initializer (if one exists)
+- `#[view]` - Makes calls to the function static
+- `#[internal]` - Function can only be called from within the contract
+- `#[note]` - Creates a custom note
+- `#[storage]` - Defines contract storage
+
+## Further reading
+[How do Aztec macros work?](../../../aztec/smart_contracts/functions/function_transforms.md)
diff --git a/docs/versioned_docs/version-v0.82.2-alpha-testnet.5/developers/reference/smart_contract_reference/portals/_category_.json b/docs/versioned_docs/version-v0.82.2-alpha-testnet.5/developers/reference/smart_contract_reference/portals/_category_.json
new file mode 100644
index 000000000000..3a04a4bcda85
--- /dev/null
+++ b/docs/versioned_docs/version-v0.82.2-alpha-testnet.5/developers/reference/smart_contract_reference/portals/_category_.json
@@ -0,0 +1,6 @@
+{
+ "label": "Portals",
+ "position": 4,
+ "collapsible": true,
+ "collapsed": true
+}
diff --git a/docs/versioned_docs/version-v0.82.2-alpha-testnet.5/developers/reference/smart_contract_reference/portals/data_structures.md b/docs/versioned_docs/version-v0.82.2-alpha-testnet.5/developers/reference/smart_contract_reference/portals/data_structures.md
new file mode 100644
index 000000000000..fbb8e874ca00
--- /dev/null
+++ b/docs/versioned_docs/version-v0.82.2-alpha-testnet.5/developers/reference/smart_contract_reference/portals/data_structures.md
@@ -0,0 +1,139 @@
+---
+title: Data Structures
+---
+
+The `DataStructures` are structs that we are using throughout the message infrastructure and registry.
+
+**Links**: [Implementation (GitHub link)](https://github.com/AztecProtocol/aztec-packages/blob/master/l1-contracts/src/core/libraries/DataStructures.sol).
+
+## `L1Actor`
+
+An entity on L1, specifying the address and the chainId for the entity. Used when specifying sender/recipient with an entity that is on L1.
+
+```solidity title="l1_actor" showLineNumbers
+/**
+ * @notice Actor on L1.
+ * @param actor - The address of the actor
+ * @param chainId - The chainId of the actor
+ */
+struct L1Actor {
+ address actor;
+ uint256 chainId;
+}
+```
+> Source code: l1-contracts/src/core/libraries/DataStructures.sol#L11-L21
+
+
+| Name | Type | Description |
+| -------------- | ------- | ----------- |
+| `actor` | `address` | The L1 address of the actor |
+| `chainId` | `uint256` | The chainId of the actor. Defines the blockchain that the actor lives on. |
+
+
+## `L2Actor`
+
+An entity on L2, specifying the address and the version for the entity. Used when specifying sender/recipient with an entity that is on L2.
+
+```solidity title="l2_actor" showLineNumbers
+/**
+ * @notice Actor on L2.
+ * @param actor - The aztec address of the actor
+ * @param version - Ahe Aztec instance the actor is on
+ */
+struct L2Actor {
+ bytes32 actor;
+ uint256 version;
+}
+```
+> Source code: l1-contracts/src/core/libraries/DataStructures.sol#L23-L33
+
+
+| Name | Type | Description |
+| -------------- | ------- | ----------- |
+| `actor` | `bytes32` | The aztec address of the actor. |
+| `version` | `uint256` | The version of Aztec that the actor lives on. |
+
+## `L1ToL2Message`
+
+A message that is sent from L1 to L2.
+
+```solidity title="l1_to_l2_msg" showLineNumbers
+/**
+ * @notice Struct containing a message from L1 to L2
+ * @param sender - The sender of the message
+ * @param recipient - The recipient of the message
+ * @param content - The content of the message (application specific) padded to bytes32 or hashed if larger.
+ * @param secretHash - The secret hash of the message (make it possible to hide when a specific message is consumed on L2).
+ * @param index - Global leaf index on the L1 to L2 messages tree.
+ */
+struct L1ToL2Msg {
+ L1Actor sender;
+ L2Actor recipient;
+ bytes32 content;
+ bytes32 secretHash;
+ uint256 index;
+}
+```
+> Source code: l1-contracts/src/core/libraries/DataStructures.sol#L35-L51
+
+
+| Name | Type | Description |
+| -------------- | ------- | ----------- |
+| `sender` | `L1Actor` | The actor on L1 that is sending the message. |
+| `recipient` | `L2Actor` | The actor on L2 that is to receive the message. |
+| `content` | `field (~254 bits)` | The field element containing the content to be sent to L2. |
+| `secretHash` | `field (~254 bits)` | The hash of a secret pre-image that must be known to consume the message on L2. Use [`computeSecretHash` (GitHub link)](https://github.com/AztecProtocol/aztec-packages/blob/master/yarn-project/aztec.js/src/utils/secrets.ts) to compute it from a secret. |
+
+## `L2ToL1Message`
+
+A message that is sent from L2 to L1.
+
+```solidity title="l2_to_l1_msg" showLineNumbers
+/**
+ * @notice Struct containing a message from L2 to L1
+ * @param sender - The sender of the message
+ * @param recipient - The recipient of the message
+ * @param content - The content of the message (application specific) padded to bytes32 or hashed if larger.
+ * @dev Not to be confused with L2ToL1Message in Noir circuits
+ */
+struct L2ToL1Msg {
+ DataStructures.L2Actor sender;
+ DataStructures.L1Actor recipient;
+ bytes32 content;
+}
+```
+> Source code: l1-contracts/src/core/libraries/DataStructures.sol#L53-L66
+
+
+| Name | Type | Description |
+| -------------- | ------- | ----------- |
+| `sender` | `L2Actor` | The actor on L2 that is sending the message. |
+| `recipient` | `L1Actor` | The actor on L1 that is to receive the message. |
+| `content` | `field (~254 bits)` | The field element containing the content to be consumed by the portal on L1. |
+
+## `RegistrySnapshot`
+
+A snapshot of the registry values.
+
+```solidity title="registry_snapshot" showLineNumbers
+/**
+ * @notice Struct for storing address of cross communication components and the block number when it was updated
+ * @param rollup - The address of the rollup contract
+ * @param blockNumber - The block number of the snapshot
+ */
+struct RegistrySnapshot {
+ address rollup;
+ uint256 blockNumber;
+}
+```
+> Source code: l1-contracts/src/governance/libraries/DataStructures.sol#L14-L24
+
+
+| Name | Type | Description |
+| -------------- | ------- | ----------- |
+| `rollup` | `address` | The address of the rollup contract for the snapshot. |
+| `blockNumber` | `uint256` | The block number at which the snapshot was created. |
+
+
+
+
diff --git a/docs/versioned_docs/version-v0.82.2-alpha-testnet.5/developers/reference/smart_contract_reference/portals/inbox.md b/docs/versioned_docs/version-v0.82.2-alpha-testnet.5/developers/reference/smart_contract_reference/portals/inbox.md
new file mode 100644
index 000000000000..79d840a2d3d6
--- /dev/null
+++ b/docs/versioned_docs/version-v0.82.2-alpha-testnet.5/developers/reference/smart_contract_reference/portals/inbox.md
@@ -0,0 +1,72 @@
+---
+title: Inbox
+tags: [portals, contracts]
+---
+
+The `Inbox` is a contract deployed on L1 that handles message passing from L1 to the rollup (L2)
+
+**Links**: [Interface (GitHub link)](https://github.com/AztecProtocol/aztec-packages/blob/master/l1-contracts/src/core/interfaces/messagebridge/IInbox.sol), [Implementation (GitHub link)](https://github.com/AztecProtocol/aztec-packages/blob/master/l1-contracts/src/core/messagebridge/Inbox.sol).
+
+## `sendL2Message()`
+
+Sends a message from L1 to L2.
+
+```solidity title="send_l1_to_l2_message" showLineNumbers
+/**
+ * @notice Inserts a new message into the Inbox
+ * @dev Emits `MessageSent` with data for easy access by the sequencer
+ * @param _recipient - The recipient of the message
+ * @param _content - The content of the message (application specific)
+ * @param _secretHash - The secret hash of the message (make it possible to hide when a specific message is consumed on L2)
+ * @return The key of the message in the set and its leaf index in the tree
+ */
+function sendL2Message(
+ DataStructures.L2Actor memory _recipient,
+ bytes32 _content,
+ bytes32 _secretHash
+) external returns (bytes32, uint256);
+```
+> Source code: l1-contracts/src/core/interfaces/messagebridge/IInbox.sol#L21-L35
+
+
+
+| Name | Type | Description |
+| -------------- | ------- | ----------- |
+| Recipient | `L2Actor` | The recipient of the message. This **MUST** match the rollup version and an Aztec contract that is **attached** to the contract making this call. If the recipient is not attached to the caller, the message cannot be consumed by it. |
+| Content | `field` (~254 bits) | The content of the message. This is the data that will be passed to the recipient. The content is limited to be a single field for rollup purposes. If the content is small enough it can just be passed along, otherwise it should be hashed and the hash passed along (you can use our [`Hash` (GitHub link)](https://github.com/AztecProtocol/aztec-packages/blob/master/l1-contracts/src/core/libraries/Hash.sol) utilities with `sha256ToField` functions) |
+| Secret Hash | `field` (~254 bits) | A hash of a secret that is used when consuming the message on L2. Keep this preimage a secret to make the consumption private. To consume the message the caller must know the pre-image (the value that was hashed) - so make sure your app keeps track of the pre-images! Use [`computeSecretHash` (GitHub link)](https://github.com/AztecProtocol/aztec-packages/blob/master/yarn-project/aztec.js/src/utils/secrets.ts) to compute it from a secret. |
+| ReturnValue | `bytes32` | The message hash, used as an identifier |
+
+#### Edge cases
+
+- Will revert with `Inbox__ActorTooLarge(bytes32 actor)` if the recipient is larger than the field size (~254 bits).
+- Will revert with `Inbox__ContentTooLarge(bytes32 content)` if the content is larger than the field size (~254 bits).
+- Will revert with `Inbox__SecretHashTooLarge(bytes32 secretHash)` if the secret hash is larger than the field size (~254 bits).
+
+## `consume()`
+
+Allows the `Rollup` to consume multiple messages in a single transaction.
+
+```solidity title="consume" showLineNumbers
+/**
+ * @notice Consumes the current tree, and starts a new one if needed
+ * @dev Only callable by the rollup contract
+ * @dev In the first iteration we return empty tree root because first block's messages tree is always
+ * empty because there has to be a 1 block lag to prevent sequencer DOS attacks
+ *
+ * @param _toConsume - The block number to consume
+ *
+ * @return The root of the consumed tree
+ */
+function consume(uint256 _toConsume) external returns (bytes32);
+```
+> Source code: l1-contracts/src/core/interfaces/messagebridge/IInbox.sol#L37-L49
+
+
+| Name | Type | Description |
+| -------------- | ----------- | -------------------------- |
+| ReturnValue | `bytes32` | Root of the consumed tree. |
+
+#### Edge cases
+
+- Will revert with `Inbox__Unauthorized()` if `msg.sender != ROLLUP` (rollup contract is sometimes referred to as state transitioner in the docs).
diff --git a/docs/versioned_docs/version-v0.82.2-alpha-testnet.5/developers/reference/smart_contract_reference/portals/outbox.md b/docs/versioned_docs/version-v0.82.2-alpha-testnet.5/developers/reference/smart_contract_reference/portals/outbox.md
new file mode 100644
index 000000000000..a4ef4b7f9d97
--- /dev/null
+++ b/docs/versioned_docs/version-v0.82.2-alpha-testnet.5/developers/reference/smart_contract_reference/portals/outbox.md
@@ -0,0 +1,113 @@
+---
+title: Outbox
+tags: [portals, contracts]
+---
+
+The `Outbox` is a contract deployed on L1 that handles message passing from the rollup and to L1.
+
+**Links**: [Interface (GitHub link)](https://github.com/AztecProtocol/aztec-packages/blob/master/l1-contracts/src/core/interfaces/messagebridge/IOutbox.sol), [Implementation (GitHub link)](https://github.com/AztecProtocol/aztec-packages/blob/master/l1-contracts/src/core/messagebridge/Outbox.sol).
+
+## `insert()`
+
+Inserts the root of a merkle tree containing all of the L2 to L1 messages in a block specified by _l2BlockNumber.
+
+```solidity title="outbox_insert" showLineNumbers
+/**
+ * @notice Inserts the root of a merkle tree containing all of the L2 to L1 messages in
+ * a block specified by _l2BlockNumber.
+ * @dev Only callable by the rollup contract
+ * @dev Emits `RootAdded` upon inserting the root successfully
+ * @param _l2BlockNumber - The L2 Block Number in which the L2 to L1 messages reside
+ * @param _root - The merkle root of the tree where all the L2 to L1 messages are leaves
+ * @param _minHeight - The min height of the merkle tree that the root corresponds to
+ */
+function insert(uint256 _l2BlockNumber, bytes32 _root, uint256 _minHeight) external;
+```
+> Source code: l1-contracts/src/core/interfaces/messagebridge/IOutbox.sol#L22-L33
+
+
+
+| Name | Type | Description |
+| -------------- | ------- | ----------- |
+| `_l2BlockNumber` | `uint256` | The L2 Block Number in which the L2 to L1 messages reside |
+| `_root` | `bytes32` | The merkle root of the tree where all the L2 to L1 messages are leaves |
+| `_minHeight` | `uint256` | The minimum height of the merkle tree that the root corresponds to |
+
+#### Edge cases
+
+- Will revert with `Outbox__Unauthorized()` if `msg.sender != ROLLUP_CONTRACT`.
+- Will revert with `Errors.Outbox__RootAlreadySetAtBlock(uint256 l2BlockNumber)` if the root for the specific block has already been set.
+- Will revert with `Errors.Outbox__InsertingInvalidRoot()` if the rollup is trying to insert bytes32(0) as the root.
+
+## `consume()`
+
+Allows a recipient to consume a message from the `Outbox`.
+
+```solidity title="outbox_consume" showLineNumbers
+/**
+ * @notice Consumes an entry from the Outbox
+ * @dev Only useable by portals / recipients of messages
+ * @dev Emits `MessageConsumed` when consuming messages
+ * @param _message - The L2 to L1 message
+ * @param _l2BlockNumber - The block number specifying the block that contains the message we want to consume
+ * @param _leafIndex - The index inside the merkle tree where the message is located
+ * @param _path - The sibling path used to prove inclusion of the message, the _path length directly depends
+ * on the total amount of L2 to L1 messages in the block. i.e. the length of _path is equal to the depth of the
+ * L1 to L2 message tree.
+ */
+function consume(
+ DataStructures.L2ToL1Msg calldata _message,
+ uint256 _l2BlockNumber,
+ uint256 _leafIndex,
+ bytes32[] calldata _path
+) external;
+```
+> Source code: l1-contracts/src/core/interfaces/messagebridge/IOutbox.sol#L35-L53
+
+
+
+| Name | Type | Description |
+| -------------- | ------- | ----------- |
+| `_message` | `L2ToL1Msg` | The L2 to L1 message we want to consume |
+| `_l2BlockNumber` | `uint256` | The block number specifying the block that contains the message we want to consume |
+| `_leafIndex` | `uint256` | The index inside the merkle tree where the message is located |
+| `_path` | `bytes32[]` | The sibling path used to prove inclusion of the message, the _path length directly depends |
+
+#### Edge cases
+
+- Will revert with `Outbox__InvalidRecipient(address expected, address actual);` if `msg.sender != _message.recipient.actor`.
+- Will revert with `Outbox__InvalidChainId()` if `block.chainid != _message.recipient.chainId`.
+- Will revert with `Outbox__NothingToConsumeAtBlock(uint256 l2BlockNumber)` if the root for the block has not been set yet.
+- Will revert with `Outbox__AlreadyNullified(uint256 l2BlockNumber, uint256 leafIndex)` if the message at leafIndex for the block has already been consumed.
+- Will revert with `Outbox__InvalidPathLength(uint256 expected, uint256 actual)` if the supplied height is less than the existing minimum height of the L2 to L1 message tree, or the supplied height is greater than the maximum (minimum height + log2(maximum messages)).
+- Will revert with `MerkleLib__InvalidRoot(bytes32 expected, bytes32 actual, bytes32 leaf, uint256 leafIndex)` if unable to verify the message existence in the tree. It returns the message as a leaf, as well as the index of the leaf to expose more info about the error.
+
+
+## `hasMessageBeenConsumedAtBlockAndIndex()`
+
+Checks to see if an index of the L2 to L1 message tree for a specific block has been consumed.
+
+```solidity title="outbox_has_message_been_consumed_at_block_and_index" showLineNumbers
+/**
+ * @notice Checks to see if an index of the L2 to L1 message tree for a specific block has been consumed
+ * @dev - This function does not throw. Out-of-bounds access is considered valid, but will always return false
+ * @param _l2BlockNumber - The block number specifying the block that contains the index of the message we want to check
+ * @param _leafIndex - The index of the message inside the merkle tree
+ */
+function hasMessageBeenConsumedAtBlockAndIndex(uint256 _l2BlockNumber, uint256 _leafIndex)
+ external
+ view
+ returns (bool);
+```
+> Source code: l1-contracts/src/core/interfaces/messagebridge/IOutbox.sol#L55-L66
+
+
+
+| Name | Type | Description |
+| -------------- | ------- | ----------- |
+| `_l2BlockNumber` | `uint256` | The block number specifying the block that contains the index of the message we want to check |
+| `_leafIndex` | `uint256` | The index of the message inside the merkle tree |
+
+#### Edge cases
+
+- This function does not throw. Out-of-bounds access is considered valid, but will always return false.
diff --git a/docs/versioned_docs/version-v0.82.2-alpha-testnet.5/developers/reference/smart_contract_reference/portals/registry.md b/docs/versioned_docs/version-v0.82.2-alpha-testnet.5/developers/reference/smart_contract_reference/portals/registry.md
new file mode 100644
index 000000000000..5cebf42a17ad
--- /dev/null
+++ b/docs/versioned_docs/version-v0.82.2-alpha-testnet.5/developers/reference/smart_contract_reference/portals/registry.md
@@ -0,0 +1,102 @@
+---
+title: Registry
+tags: [portals, contracts]
+---
+
+The registry is a contract deployed on L1, that contains addresses for the `Rollup`. It also keeps track of the different versions that have been deployed and let you query prior deployments easily.
+
+**Links**: [Interface (GitHub link)](https://github.com/AztecProtocol/aztec-packages/blob/master/l1-contracts/src/governance/interfaces/IRegistry.sol), [Implementation (GitHub link)](https://github.com/AztecProtocol/aztec-packages/blob/master/l1-contracts/src/governance/Registry.sol).
+
+## `numberOfVersions()`
+
+Retrieves the number of versions that have been deployed.
+
+```solidity title="registry_number_of_versions" showLineNumbers
+function numberOfVersions() external view returns (uint256);
+```
+> Source code: l1-contracts/src/governance/interfaces/IRegistry.sol#L32-L34
+
+
+| Name | Description |
+| -------------- | ----------- |
+| ReturnValue | The number of versions that have been deployed |
+
+## `getRollup()`
+Retrieves the current rollup contract.
+
+```solidity title="registry_get_rollup" showLineNumbers
+function getRollup() external view returns (address);
+```
+> Source code: l1-contracts/src/governance/interfaces/IRegistry.sol#L13-L15
+
+
+| Name | Description |
+| -------------- | ----------- |
+| ReturnValue | The current rollup |
+
+## `getVersionFor(address _rollup)`
+
+Retrieve the version of a specific rollup contract.
+
+```solidity title="registry_get_version_for" showLineNumbers
+function getVersionFor(address _rollup) external view returns (uint256);
+```
+> Source code: l1-contracts/src/governance/interfaces/IRegistry.sol#L17-L19
+
+
+| Name | Description |
+| -------------- | ----------- |
+| `_rollup` | The address of the rollup to lookup |
+| ReturnValue | The version number of `_rollup` |
+
+#### Edge cases
+Will revert with `Registry__RollupNotRegistered(_rollup)` if the rollup have not been registered.
+
+## `getSnapshot(uint256 _version)`
+
+Retrieve the snapshot of a specific version.
+
+```solidity title="registry_snapshot" showLineNumbers
+/**
+ * @notice Struct for storing address of cross communication components and the block number when it was updated
+ * @param rollup - The address of the rollup contract
+ * @param blockNumber - The block number of the snapshot
+ */
+struct RegistrySnapshot {
+ address rollup;
+ uint256 blockNumber;
+}
+```
+> Source code: l1-contracts/src/governance/libraries/DataStructures.sol#L14-L24
+
+```solidity title="registry_get_snapshot" showLineNumbers
+function getSnapshot(uint256 _version)
+ external
+ view
+ returns (DataStructures.RegistrySnapshot memory);
+```
+> Source code: l1-contracts/src/governance/interfaces/IRegistry.sol#L21-L26
+
+
+| Name | Description |
+| -------------- | ----------- |
+| `_version` | The version number to fetch data for |
+| ReturnValue.rollup | The address of the `rollup` for the `_version` |
+| ReturnValue.blockNumber | The block number of the snapshot creation |
+
+
+## `getCurrentSnapshot()`
+
+Retrieves the snapshot for the current version.
+
+```solidity title="registry_get_current_snapshot" showLineNumbers
+function getCurrentSnapshot() external view returns (DataStructures.RegistrySnapshot memory);
+```
+> Source code: l1-contracts/src/governance/interfaces/IRegistry.sol#L28-L30
+
+
+| Name | Description |
+| -------------- | ----------- |
+| ReturnValue.rollup | The address of the `rollup` for the current `_version` |
+| ReturnValue.blockNumber | The block number of the snapshot creation |
+
diff --git a/docs/versioned_docs/version-v0.82.2-alpha-testnet.5/developers/reference/smart_contract_reference/storage/_category_.json b/docs/versioned_docs/version-v0.82.2-alpha-testnet.5/developers/reference/smart_contract_reference/storage/_category_.json
new file mode 100644
index 000000000000..25edf7aa1c2e
--- /dev/null
+++ b/docs/versioned_docs/version-v0.82.2-alpha-testnet.5/developers/reference/smart_contract_reference/storage/_category_.json
@@ -0,0 +1,6 @@
+{
+ "position": 1,
+ "collapsible": true,
+ "collapsed": true,
+ "label": "Storage"
+}
diff --git a/docs/versioned_docs/version-v0.82.2-alpha-testnet.5/developers/reference/smart_contract_reference/storage/index.md b/docs/versioned_docs/version-v0.82.2-alpha-testnet.5/developers/reference/smart_contract_reference/storage/index.md
new file mode 100644
index 000000000000..95e6f2a11039
--- /dev/null
+++ b/docs/versioned_docs/version-v0.82.2-alpha-testnet.5/developers/reference/smart_contract_reference/storage/index.md
@@ -0,0 +1,114 @@
+---
+title: Storage
+---
+
+Smart contracts rely on storage, acting as the persistent memory on the blockchain. In Aztec, because of its hybrid, privacy-first architecture, the management of this storage is more complex than other blockchains like Ethereum.
+
+To learn how to define a storage struct, read [this guide](../../../guides/smart_contracts/writing_contracts/storage/index.md).
+To learn more about storage slots, read [this explainer in the Concepts section](../../../../aztec/concepts/storage/index.md).
+
+You control this storage in Aztec using a struct annotated with `#[storage]`. This struct serves as the housing unit for all your smart contract's state variables - the data it needs to keep track of and maintain.
+
+These state variables come in two forms: [public](./public_state.md) and [private](./private_state.md). Public variables are visible to anyone, and private variables remain hidden within the contract. A state variable with both public and private components is said to be [shared](./shared_state.md).
+
+Aztec.nr has a few abstractions to help define the type of data your contract holds. These include PrivateMutable, PrivateImmutable, PublicMutable, PublicImmutable, PrivateSet, and SharedMutable.
+
+On this and the following pages in this section, you’ll learn:
+
+- How to manage a smart contract's storage structure
+- The distinctions and applications of public and private state variables
+- How to use PrivateMutable, PrivateImmutable, PrivateSet, PublicMutable, SharedMutable and Map
+- An overview of 'notes' and the UTXO model
+- Practical implications of Storage in real smart contracts
+ In an Aztec.nr contract, storage is to be defined as a single struct, that contains both public and private state variables.
+
+## The `Context` parameter
+
+Aztec contracts have three different modes of execution: private, public, and top-level unconstrained. How storage is accessed depends on the execution mode: for example, `PublicImmutable` can be read in all execution modes but only initialized in public, while `PrivateMutable` is entirely unavailable in public.
+
+Aztec.nr prevents developers from calling functions unavailable in the current execution mode via the `context` variable that is injected into all contract functions. Its type indicates the current execution mode:
+
+- `&mut PrivateContext` for private execution
+- `&mut PublicContext` for public execution
+- `UncontrainedContext` for top-level unconstrained execution
+
+All state variables are generic over this `Context` type, and expose different methods in each execution mode. In the example above, `PublicImmutable`'s `initialize` function is only available with a public execution context, and so the following code results in a compilation error:
+
+```rust
+#[storage]
+struct Storage {
+ variable: PublicImmutable,
+}
+
+#[private]
+fn some_private_function() {
+ storage.variable.initialize(0);
+ // ^ ERROR: Expected type PublicImmutable<_, &mut PublicContext>, found type PublicImmutable
+}
+```
+
+The `Context` generic type parameter is not visible in the code above as it is automatically injected by the `#[storage]` macro, in order to reduce boilerplate. Similarly, all state variables in that struct (e.g. `PublicImmutable`) similarly have that same type parameter automatically passed to them.
+
+## Map
+
+A `map` is a state variable that "maps" a key to a value. It can be used with private or public storage variables.
+
+:::info
+In Aztec.nr, keys are always `Field`s, or types that can be serialized as Fields, and values can be any type - even other maps. `Field`s are finite field elements, but you can think of them as integers.
+:::
+
+It includes a `Context` to specify the private or public domain, a `storage_slot` to specify where in storage the map is stored, and a `start_var_constructor` which tells the map how it should operate on the underlying type. This includes how to serialize and deserialize the type, as well as how commitments and nullifiers are computed for the type if it's private.
+
+You can view the implementation in the Aztec.nr library [here (GitHub link)](https://github.com/AztecProtocol/aztec-packages/tree/master/noir-projects/aztec-nr).
+
+You can have multiple `map`s in your contract that each have a different underlying note type, due to note type IDs. These are identifiers for each note type that are unique within a contract.
+
+#### As private storage
+
+When declaring a mapping in private storage, we have to specify which type of Note to use. In the example below, we are specifying that we want to use the `PrivateMutable` note which will hold `ValueNote` types.
+
+In the Storage struct:
+
+```rust
+numbers: Map>,
+```
+
+#### Public Example
+
+When declaring a public mapping in Storage, we have to specify that the type is public by declaring it as `PublicState` instead of specifying a note type like with private storage above.
+
+```rust title="storage_minters" showLineNumbers
+minters: Map, Context>,
+```
+> Source code: noir-projects/noir-contracts/contracts/token_contract/src/main.nr#L74-L76
+
+
+### `at`
+
+When dealing with a Map, we can access the value at a given key using the `::at` method. This takes the key as an argument and returns the value at that key.
+
+This function behaves similarly for both private and public maps. An example could be if we have a map with `minters`, which is mapping addresses to a flag for whether they are allowed to mint tokens or not.
+
+```rust title="read_minter" showLineNumbers
+assert(storage.minters.at(context.msg_sender()).read(), "caller is not minter");
+```
+> Source code: noir-projects/noir-contracts/contracts/token_contract/src/main.nr#L198-L200
+
+
+Above, we are specifying that we want to get the storage in the Map `at` the `msg_sender()`, read the value stored and check that `msg_sender()` is indeed a minter. Doing a similar operation in Solidity code would look like:
+
+```solidity
+require(minters[msg.sender], "caller is not minter");
+```
+
+## Further Reading
+
+- [Public State](./public_state.md)
+- [Private State](./private_state.md)
+- [Shared State](./shared_state.md)
+
+## Concepts mentioned
+
+- [State Model](../../../../aztec/concepts/storage/state_model.md)
+- [Public-private execution](../../../../aztec/smart_contracts/functions/public_private_calls.md)
+- [Function Contexts](../../../../aztec/smart_contracts/functions/context.md)
diff --git a/docs/versioned_docs/version-v0.82.2-alpha-testnet.5/developers/reference/smart_contract_reference/storage/private_state.md b/docs/versioned_docs/version-v0.82.2-alpha-testnet.5/developers/reference/smart_contract_reference/storage/private_state.md
new file mode 100644
index 000000000000..170572b8ae0d
--- /dev/null
+++ b/docs/versioned_docs/version-v0.82.2-alpha-testnet.5/developers/reference/smart_contract_reference/storage/private_state.md
@@ -0,0 +1,572 @@
+---
+title: Private State
+---
+
+On this page we will look at how to manage private state in Aztec contracts. We will look at how to declare private state, how to read and write to it, and how to use it in your contracts.
+
+For a higher level overview of the state model in Aztec, see the [hybrid state model](../../../../aztec/concepts/storage/state_model.md) page.
+
+## Overview
+
+In contrast to public state, private state is persistent state that is **not** visible to the whole world. Depending on the logic of the smart contract, a private state variable's current value will only be known to one entity, or a closed group of entities.
+
+The value of a private state variable can either be shared via an encrypted log, or offchain via web2, or completely offline: it's up to the app developer.
+
+Aztec private state follows a [UTXO](https://en.wikipedia.org/wiki/Unspent_transaction_output)-based model. That is, a private state's current value is represented as one or many notes.
+
+To greatly simplify the experience of writing private state, Aztec.nr provides three different types of private state variable:
+
+- [PrivateMutable\](#privatemutablenotetype)
+- [PrivateImmutable\](#privateimmutablenotetype)
+- [PrivateSet\](#privatesetnotetype)
+
+These three structs abstract-away many of Aztec's protocol complexities, by providing intuitive methods to modify notes in the utxo tree in a privacy-preserving way.
+
+:::info
+An app can also choose to emit data via unencrypted log, or to define a note whose data is easy to figure out, then the information is technically not private and could be visible to anyone.
+:::
+
+### Notes
+
+Unlike public state variables, which can be arbitrary types, private state variables operate on `NoteType`.
+
+Notes are the fundamental elements in the private world.
+
+A note has to implement the following traits:
+
+```rust title="note_interfaces" showLineNumbers
+pub trait NoteType {
+ /// Returns the unique identifier for the note type. This is typically used when processing note logs.
+ fn get_id() -> Field;
+}
+
+pub trait NoteHash {
+ /// Returns the non-siloed note hash, i.e. the inner hash computed by the contract during private execution. Note
+ /// hashes are later siloed by contract address and nonce by the kernels before being committed to the state tree.
+ ///
+ /// This should be a commitment to the packed note, including the storage slot (for indexing) and some random
+ /// value (to prevent brute force trial-hashing attacks).
+ fn compute_note_hash(self, storage_slot: Field) -> Field;
+
+ /// Returns the non-siloed nullifier (also called inner-nullifier), which will be later siloed by contract address
+ /// by the kernels before being committed to the state tree.
+ ///
+ /// This function MUST be called with the correct note hash for consumption! It will otherwise silently fail and
+ /// compute an incorrect value. The reason why we receive this as an argument instead of computing it ourselves
+ /// directly is because the caller will typically already have computed this note hash, and we can reuse that value
+ /// to reduce the total gate count of the circuit.
+ ///
+ /// This function receives the context since nullifier computation typically involves proving nullifying keys, and
+ /// we require the kernel's assistance to do this in order to prevent having to reveal private keys to application
+ /// circuits.
+ fn compute_nullifier(self, context: &mut PrivateContext, note_hash_for_nullify: Field) -> Field;
+
+ /// Like `compute_nullifier`, except this variant is unconstrained: there are no guarantees on the returned value
+ /// being correct. Because of that it doesn't need to take a context (since it won't perform any kernel key
+ /// validation requests).
+ unconstrained fn compute_nullifier_unconstrained(self, note_hash_for_nullify: Field) -> Field;
+}
+```
+> Source code: noir-projects/aztec-nr/aztec/src/note/note_interface.nr#L5-L37
+
+
+The interplay between a private state variable and its notes can be confusing. Here's a summary to aid intuition:
+
+A private state variable (of type `PrivateMutable`, `PrivateImmutable` or `PrivateSet`) may be declared in storage and the purpose of private state variables is to manage notes (inserting their note hashes into the note hash tree, obtaining the notes, grouping the notes together using the storage slot etc.).
+
+:::info
+Note that storage slots in private state are not real.
+They do not point to a specific leaf in a merkle tree (as is the case in public).
+Instead, in the case of notes they can be understood only as a tag that is used to associate notes with a private state variable.
+The state variable storage slot can commonly represent an owner, as is the case when using the `at(...)` function of a `Map<>` with an `AztecAddress` as the key.
+:::
+
+A private state variable points to one or many notes (depending on the type). The note(s) are all valid private state if the note(s) haven't yet been nullified.
+
+An `PrivateImmutable` will point to _one_ note over the lifetime of the contract. This note is a struct of information that is persisted forever.
+
+A `PrivateMutable` may point to _one_ note at a time. But since it's not "immutable", the note that it points to may be [replaced](#replace) by functions of the contract. The current value of a `PrivateMutable` is interpreted as the one note which has not-yet been nullified. The act of replacing a PrivateMutable's note is how a `PrivateMutable` state may be modified by functions.
+
+`PrivateMutable` is a useful type when declaring a private state variable which may only ever be modified by those who are privy to the current value of that state.
+
+A `PrivateSet` may point to _multiple_ notes at a time. The "current value" of a private state variable of type `PrivateSet` is some accumulation of all not-yet nullified notes which belong to the `PrivateSet`.
+
+:::note
+The term "some accumulation" is intentionally vague. The interpretation of the "current value" of a `PrivateSet` must be expressed by the smart contract developer. A common use case for a `PrivateSet` is to represent the sum of a collection of values (in which case 'accumulation' is 'summation').
+
+Think of a ZCash balance (or even a Bitcoin balance). The "current value" of a user's ZCash balance is the sum of all unspent (not-yet nullified) notes belonging to that user. To modify the "current value" of a `PrivateSet` state variable, is to [`insert`](#insert) new notes into the `PrivateSet`, or [`remove`](#remove) notes from that set.
+:::
+
+Interestingly, if a developer requires a private state to be modifiable by users who _aren't_ privy to the value of that state, a `PrivateSet` is a very useful type. The `insert` method allows new notes to be added to the `PrivateSet` without knowing any of the other notes in the set! (Like posting an envelope into a post box, you don't know what else is in there!).
+
+## `PrivateMutable`
+
+PrivateMutable (formerly known as `Singleton`) is a private state variable that is unique in a way. When a PrivateMutable is initialized, a note is created to represent its value. And the way to update the value is to destroy the current note, and create a new one with the updated value.
+
+Like for public state, we define the struct to have context and a storage slot. You can view the implementation [here (GitHub link)](https://github.com/AztecProtocol/aztec-packages/blob/master/noir-projects/aztec-nr/aztec/src/state_vars/private_mutable.nr).
+
+An example of `PrivateMutable` usage in the account contracts is keeping track of public keys. The `PrivateMutable` is added to the `Storage` struct as follows:
+
+```rust title="storage-private-mutable-declaration" showLineNumbers
+legendary_card: PrivateMutable,
+```
+> Source code: noir-projects/noir-contracts/contracts/docs_example_contract/src/main.nr#L39-L41
+
+
+### `new`
+
+As part of the initialization of the `Storage` struct, the `PrivateMutable` is created as follows at the specified storage slot.
+
+```rust title="start_vars_private_mutable" showLineNumbers
+legendary_card: PrivateMutable::new(context, 3),
+```
+> Source code: noir-projects/noir-contracts/contracts/docs_example_contract/src/main.nr#L66-L68
+
+
+### `initialize`
+
+As mentioned, the PrivateMutable is initialized to create the first note and value.
+
+When this function is called, a nullifier of the storage slot is created, preventing this PrivateMutable from being initialized again.
+
+:::danger Privacy-Leak
+Beware that because this nullifier is created only from the storage slot without randomness it leaks privacy. This means that it is possible for an external observer to determine when the note is nullified.
+
+For example, if the storage slot depends on the an address then it is possible to link the nullifier to the address. If the PrivateMutable is part of a `map` with an `AztecAddress` as the key then the nullifier will be linked to the address.
+:::
+
+Unlike public states, which have a default initial value of `0` (or many zeros, in the case of a struct, array or map), a private state (of type `PrivateMutable`, `PrivateImmutable` or `PrivateSet`) does not have a default initial value. The `initialize` method (or `insert`, in the case of a `PrivateSet`) must be called.
+
+:::info
+Extend on what happens if you try to use non-initialized state.
+:::
+
+### `is_initialized`
+
+An unconstrained method to check whether the PrivateMutable has been initialized or not. It takes an optional owner and returns a boolean. You can view the implementation [here (GitHub link)](https://github.com/AztecProtocol/aztec-packages/blob/v0.82.2/noir-projects/aztec-nr/aztec/src/state_vars/private_mutable.nr).
+
+```rust title="private_mutable_is_initialized" showLineNumbers
+unconstrained fn is_legendary_initialized() -> bool {
+ storage.legendary_card.is_initialized()
+}
+```
+> Source code: noir-projects/noir-contracts/contracts/docs_example_contract/src/main.nr#L287-L291
+
+
+### `replace`
+
+To update the value of a `PrivateMutable`, we can use the `replace` method. The method takes a new note as input, and replaces the current note with the new one. It emits a nullifier for the old value, and inserts the new note into the data tree.
+
+An example of this is seen in a example card game, where we create a new note (a `CardNote`) containing some new data, and replace the current note with it:
+
+```rust title="state_vars-PrivateMutableReplace" showLineNumbers
+storage.legendary_card.replace(new_card).emit(encode_and_encrypt_note(
+ &mut context,
+ context.msg_sender(),
+ context.msg_sender(),
+));
+```
+> Source code: noir-projects/noir-contracts/contracts/docs_example_contract/src/main.nr#L243-L249
+
+
+If two people are trying to modify the PrivateMutable at the same time, only one will succeed as we don't allow duplicate nullifiers! Developers should put in place appropriate access controls to avoid race conditions (unless a race is intended!).
+
+### `get_note`
+
+This function allows us to get the note of a PrivateMutable, essentially reading the value.
+
+```rust title="state_vars-PrivateMutableGet" showLineNumbers
+let card = storage.legendary_card.get_note().note;
+```
+> Source code: noir-projects/noir-contracts/contracts/docs_example_contract/src/main.nr#L237-L239
+
+
+#### Nullifying Note reads
+
+To ensure that a user's private execution always uses the latest value of a PrivateMutable, the `get_note` function will nullify the note that it is reading. This means that if two people are trying to use this function with the same note, only one will succeed (no duplicate nullifiers allowed).
+
+This also makes read operations indistinguishable from write operations and allows the sequencer to verifying correct execution without learning anything about the value of the note.
+
+### `view_note`
+
+Functionally similar to [`get_note`](#get_note), but executed in unconstrained functions and can be used by the wallet to fetch notes for use by front-ends etc.
+
+## `PrivateImmutable`
+
+`PrivateImmutable` (formerly known as `ImmutableSingleton`) represents a unique private state variable that, as the name suggests, is immutable. Once initialized, its value cannot be altered. You can view the implementation [here (GitHub link)](https://github.com/AztecProtocol/aztec-packages/blob/v0.82.2/noir-projects/aztec-nr/aztec/src/state_vars/private_immutable.nr).
+
+### `new`
+
+As part of the initialization of the `Storage` struct, the `PrivateMutable` is created as follows, here at storage slot 1.
+
+```rust title="storage-private-immutable-declaration" showLineNumbers
+private_immutable: PrivateImmutable,
+```
+> Source code: noir-projects/noir-contracts/contracts/docs_example_contract/src/main.nr#L47-L49
+
+
+### `initialize`
+
+When this function is invoked, it creates a nullifier for the storage slot, ensuring that the PrivateImmutable cannot be initialized again.
+
+:::danger Privacy-Leak
+Beware that because this nullifier is created only from the storage slot without randomness it leaks privacy. This means that it is possible for an external observer to determine when the note is nullified.
+
+For example, if the storage slot depends on the an address then it is possible to link the nullifier to the address. If the PrivateImmutable is part of a `map` with an `AztecAddress` as the key then the nullifier will be linked to the address.
+:::
+
+Set the value of an PrivateImmutable by calling the `initialize` method:
+
+```rust title="initialize-private-mutable" showLineNumbers
+#[private]
+fn initialize_private_immutable(randomness: Field, points: u8) {
+ let new_card = CardNote::new(points, randomness, context.msg_sender());
+
+ storage.private_immutable.initialize(new_card).emit(encode_and_encrypt_note(
+ &mut context,
+ context.msg_sender(),
+ context.msg_sender(),
+ ));
+}
+```
+> Source code: noir-projects/noir-contracts/contracts/docs_example_contract/src/main.nr#L167-L178
+
+
+Once initialized, an PrivateImmutable's value remains unchangeable. This method can only be called once.
+
+### `is_initialized`
+
+An unconstrained method to check if the PrivateImmutable has been initialized. Takes an optional owner and returns a boolean. You can find the implementation [here (GitHub link)](https://github.com/AztecProtocol/aztec-packages/blob/v0.82.2/noir-projects/aztec-nr/aztec/src/state_vars/private_immutable.nr).
+
+### `get_note`
+
+Similar to the `PrivateMutable`, we can use the `get_note` method to read the value of an PrivateImmutable.
+
+Use this method to retrieve the value of an initialized PrivateImmutable.
+
+```rust title="get_note-private-immutable" showLineNumbers
+#[private]
+fn get_imm_card() -> CardNote {
+ storage.private_immutable.get_note()
+}
+```
+> Source code: noir-projects/noir-contracts/contracts/docs_example_contract/src/main.nr#L292-L297
+
+
+Unlike a `PrivateMutable`, the `get_note` function for an PrivateImmutable doesn't nullify the current note in the background. This means that multiple accounts can concurrently call this function to read the value.
+
+This function will throw if the `PrivateImmutable` hasn't been initialized.
+
+### `view_note`
+
+Functionally similar to `get_note`, but executed unconstrained and can be used by the wallet to fetch notes for use by front-ends etc.
+
+## `PrivateSet`
+
+`PrivateSet` is used for managing a collection of notes. All notes in a `PrivateSet` are of the same `NoteType`. But whether these notes all belong to one entity, or are accessible and editable by different entities, is up to the developer. The set is a collection of notes inserted into the data-tree, but notes are never removed from the tree itself, they are only nullified.
+
+You can view the implementation [here (GitHub link)](https://github.com/AztecProtocol/aztec-packages/blob/v0.82.2/noir-projects/aztec-nr/aztec/src/state_vars/private_set.nr).
+
+And can be added to the `Storage` struct as follows. Here adding a set for a custom note.
+
+```rust title="storage-set-declaration" showLineNumbers
+set: PrivateSet,
+```
+> Source code: noir-projects/noir-contracts/contracts/docs_example_contract/src/main.nr#L44-L46
+
+
+### `new`
+
+The `new` method tells the contract how to operate on the underlying storage.
+
+We can initialize the set as follows:
+
+```rust title="storage-set-init" showLineNumbers
+set: PrivateSet::new(context, 5),
+```
+> Source code: noir-projects/noir-contracts/contracts/docs_example_contract/src/main.nr#L77-L79
+
+
+### `insert`
+
+Allows us to modify the storage by inserting a note into the `PrivateSet`.
+
+A hash of the note will be generated, and inserted into the note hash tree, allowing us to later use in contract interactions. Recall that the content of the note should be shared with the owner to allow them to use it, as mentioned this can be done via an encrypted log or offchain via web2, or completely offline.
+
+```rust title="insert" showLineNumbers
+self.set.insert(addend_note).emit(encode_and_encrypt_note(self.context, owner, sender));
+```
+> Source code: noir-projects/aztec-nr/easy-private-state/src/easy_private_uint.nr#L31-L33
+
+
+### `insert_from_public`
+
+The `insert_from_public` allow public function to insert notes into private storage. This is very useful when we want to support private function calls that have been initiated in public.
+
+The usage is similar to using the `insert` method with the difference that this one is called in public functions.
+
+### `pop_notes`
+
+This function pops (gets, removes and returns) the notes the account has access to based on the provided filter.
+
+The kernel circuits are constrained to a maximum number of notes this function can return at a time. Check [here (GitHub link)](https://github.com/AztecProtocol/aztec-packages/blob/v0.82.2/noir-projects/noir-protocol-circuits/crates/types/src/constants.nr) and look for `MAX_NOTE_HASH_READ_REQUESTS_PER_CALL` for the up-to-date number.
+
+Because of this limit, we should always consider using the second argument `NoteGetterOptions` to limit the number of notes we need to read and constrain in our programs. This is quite important as every extra call increases the time used to prove the program and we don't want to spend more time than necessary.
+
+An example of such options is using the [filter_notes_min_sum (GitHub link)](https://github.com/AztecProtocol/aztec-packages/blob/v0.82.2/noir-projects/aztec-nr/value-note/src/filter.nr) to get "enough" notes to cover a given value. Essentially, this function will return just enough notes to cover the amount specified such that we don't need to read all our notes. For users with a lot of notes, this becomes increasingly important.
+
+```rust title="pop_notes" showLineNumbers
+let options = NoteGetterOptions::with_filter(filter_notes_min_sum, subtrahend as Field);
+let notes = self.set.pop_notes(options);
+```
+> Source code: noir-projects/aztec-nr/easy-private-state/src/easy_private_uint.nr#L38-L41
+
+
+### `get_notes`
+
+This function has the same behavior as `pop_notes` above but it does not delete the notes.
+
+### `remove`
+
+Will remove a note from the `PrivateSet` if it previously has been read from storage, e.g. you have fetched it through a `get_notes` call. This is useful when you want to remove a note that you have previously read from storage and do not have to read it again.
+
+Note that if you obtained the note you are about to remove via `get_notes` it's much better to use `pop_notes` as `pop_notes` results in significantly fewer constraints since it doesn't need to check that the note has been previously read, as it reads and deletes at once.
+
+### `view_notes`
+
+Functionally similar to [`get_notes`](#get_notes), but executed unconstrained and can be used by the wallet to fetch notes for use by front-ends etc.
+
+```rust title="view_notes" showLineNumbers
+let mut options = NoteViewerOptions::new();
+let notes = set.view_notes(options.set_offset(offset));
+```
+> Source code: noir-projects/aztec-nr/value-note/src/balance_utils.nr#L16-L19
+
+
+There's also a limit on the maximum number of notes that can be returned in one go. To find the current limit, refer to [this file (GitHub link)](https://github.com/AztecProtocol/aztec-packages/blob/v0.82.2/noir-projects/aztec-nr/aztec/src/note/constants.nr) and look for `MAX_NOTES_PER_PAGE`.
+
+The key distinction is that this method is unconstrained. It does not perform a check to verify if the notes actually exist, which is something the [`get_notes`](#get_notes) method does under the hood. Therefore, it should only be used in an unconstrained contract function.
+
+This function requires a `NoteViewerOptions`. The `NoteViewerOptions` is essentially similar to the [`NoteGetterOptions`](#notegetteroptions), except that it doesn't take a custom filter.
+
+## `NoteGetterOptions`
+
+`NoteGetterOptions` encapsulates a set of configurable options for filtering and retrieving a selection of notes from a data oracle. Developers can design instances of `NoteGetterOptions`, to determine how notes should be filtered and returned to the functions of their smart contracts.
+
+You can view the implementation [here (GitHub link)](https://github.com/AztecProtocol/aztec-packages/blob/v0.82.2/noir-projects/aztec-nr/aztec/src/note/note_getter_options.nr).
+
+### `selects: BoundedVec