+
+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.86.0/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.86.0/noir-projects/noir-contracts/contracts/account/ecdsa_k_account_contract/src/main.nr#L56-L57), generated [in JS](https://github.com/AztecProtocol/aztec-packages/blob/v0.86.0/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.86.0/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 override async create(options: SendMethodOptions = {}): Promise
+
+
+
+
+ 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:
+
+Developer Getting Started Guide
+
+
+
+
+
+
+ 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
+
+
+
+
+
+
+
+ The Private Execution Environment (or PXE) is a client-side library for the execution of private operations
+
+
+
+
+
+
+
+ Aztec has a hybrid public/private state model
+
+
+
+
+
+
+
+ In Aztec, private data and public data are stored in two trees: a public data tree and a note hashes tree
+
+
+
+
+
+
+
+ Wallets expose to dapps an interface that allows them to act on behalf of the user, such as querying private state or sending transactions
+
+
+
+
+
+
+
+ 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.86.0/aztec/network/_category_.json b/docs/versioned_docs/version-v0.86.0/aztec/network/_category_.json
new file mode 100644
index 000000000000..ea3bb9ef6617
--- /dev/null
+++ b/docs/versioned_docs/version-v0.86.0/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.86.0/aztec/network/sequencer/index.md b/docs/versioned_docs/version-v0.86.0/aztec/network/sequencer/index.md
new file mode 100644
index 000000000000..e541d1fdd544
--- /dev/null
+++ b/docs/versioned_docs/version-v0.86.0/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.86.0/aztec/network/sequencer/sequencer_selection.md b/docs/versioned_docs/version-v0.86.0/aztec/network/sequencer/sequencer_selection.md
new file mode 100644
index 000000000000..4fb9ad736644
--- /dev/null
+++ b/docs/versioned_docs/version-v0.86.0/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.86.0/aztec/network_overview.md b/docs/versioned_docs/version-v0.86.0/aztec/network_overview.md
new file mode 100644
index 000000000000..787a59d2a96a
--- /dev/null
+++ b/docs/versioned_docs/version-v0.86.0/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.86.0/aztec/roadmap/_category_.json b/docs/versioned_docs/version-v0.86.0/aztec/roadmap/_category_.json
new file mode 100644
index 000000000000..231aa372f13e
--- /dev/null
+++ b/docs/versioned_docs/version-v0.86.0/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.86.0/aztec/roadmap/features_initial_ldt.md b/docs/versioned_docs/version-v0.86.0/aztec/roadmap/features_initial_ldt.md
new file mode 100644
index 000000000000..2ccd80366216
--- /dev/null
+++ b/docs/versioned_docs/version-v0.86.0/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.86.0/aztec/smart_contracts/contract_creation.md b/docs/versioned_docs/version-v0.86.0/aztec/smart_contracts/contract_creation.md
new file mode 100644
index 000000000000..eaeebaf2b37d
--- /dev/null
+++ b/docs/versioned_docs/version-v0.86.0/aztec/smart_contracts/contract_creation.md
@@ -0,0 +1,86 @@
+---
+title: Contract Deployment
+sidebar_position: 1
+tags: [contracts, protocol]
+---
+
+In the Aztec protocol, contracts are deployed as _instances_ of contract _classes_. The deployment process consists of two main steps: first registering the contract _class_ (if not already registered), and then creating a contract _instance_ that references this class.
+
+## Contract Classes
+
+A contract class is a collection of state variable declarations, and related private, public and utility functions. Contract classes don't have state, they just define code (storage structure and function logic). A contract class cannot be called; only a contract instance can be called.
+
+### Key Benefits of Contract Classes
+
+Contract classes simplify code reuse by making implementations a first-class citizen in the protocol. With a single class registration, multiple contract instances can be deployed that reference it, reducing deployment costs. Classes also facilitate upgradability by decoupling state from code, making it easier for an instance to switch to different code while retaining its state.
+
+### Structure of a Contract Class
+
+A contract class includes:
+
+- `artifact_hash`: Hash of the contract artifact
+- `private_functions`: List of individual private functions, including constructors
+- `packed_public_bytecode`: Packed bytecode representation of the AVM bytecode for all public functions
+
+The specification of the artifact hash is not enforced by the protocol. It should include commitments to utility functions code and compilation metadata. It is intended to be used by clients to verify that an off-chain fetched artifact matches a registered class.
+
+### Contract Class Registration
+
+A contract class is registered by calling a private `register` function in a canonical `ContractClassRegisterer` contract, which emits a Registration Nullifier. This process guarantees that the public bytecode for a contract class is publicly available, which is required for deploying contract instances.
+
+Contract class registration can be skipped if there are no public functions in the contract class, and the contract will still be usable privately. However, the contract class must be registered if it contains public functions, as these functions need to be publicly verifiable.
+
+If you have a contract with public functions, you must either register the contract class to deploy or a contract, or skip the public deployment step, in which case only the private functions will be callable.
+
+## Contract Instances
+
+A deployed contract is effectively an instance of a contract class. It always references a contract class, which determines what code it executes when called. A contract instance has both private and public state, as well as an address that serves as its identifier.
+
+### Structure of a Contract Instance
+
+A contract instance includes:
+
+- `version`: Version identifier, initially one
+- `salt`: User-generated pseudorandom value for uniqueness
+- `deployer`: Optional address of the contract deployer. Zero for universal deployment
+- `contract_class_id`: Identifier of the contract class for this instance
+- `initialization_hash`: Hash of the selector and arguments to the constructor
+- `public_keys_hash`: Optional hash of public keys used for encryption and nullifying
+
+### Instance Address
+
+The address of a contract instance is computed as the hash of the elements in its structure. This computation is deterministic, allowing users to precompute the expected deployment address of their contract, including account contracts.
+
+### Contract Initialization vs. Public Deployment
+
+Aztec makes an important distinction between initialization and public deployment:
+
+1. **Initialization**: A contract instance is considered Initialized once it emits an initialization nullifier, meaning it can only be initialized once. The default state for any address is to be uninitialized. A user who knows the preimage of the address can still issue a private call into a function in the contract, as long as that function doesn't assert that the contract has been initialized.
+2. **Public Deployment**: A Contract Instance is considered to be publicly deployed when it has been broadcast to the network via a canonical `ContractInstanceDeployer` contract, which also emits a deployment nullifier. All public function calls to an undeployed address must fail, since the contract class for it is not known to the network.
+
+### Initialization
+
+Contract constructors are not enshrined in the protocol, but handled at the application circuit level. Constructors are methods used for initializing a contract, either private or public, and contract classes may declare more than a single constructor. They can be declared by the `#[initializer]` macro. You can read more about how to use them on the [Defining Initializer Functions](../../developers/guides/smart_contracts/writing_contracts/initializers.md) page.
+
+A contract must ensure:
+
+- It is initialized at most once
+- It is initialized using the method and arguments defined in its address preimage
+- It is initialized by its deployer (if non-zero)
+- Functions dependent on initialization cannot be invoked until the contract is initialized
+
+Functions in a contract may skip the initialization check.
+
+## Verification of Executed Code
+
+The protocol circuits, both private and public, are responsible for verifying that the code loaded for a given function execution matches the expected one. This includes checking that the `contract_class_id` of the called address is the expected one and that the function selector being executed is part of the `contract_class_id`.
+
+## Genesis Contracts
+
+The `ContractInstanceDeployer` and `ContractClassRegisterer` contracts exist from the genesis of the Aztec Network, as they are necessary for deploying other contracts to the network. Their nullifiers are pre-inserted into the genesis nullifier tree.
+
+This modular approach to contract deployment creates a flexible system that supports diverse use cases, from public applications to private contract interactions, while maintaining the security and integrity of the Aztec protocol.
+
+## 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.86.0/aztec/smart_contracts/contract_structure.md b/docs/versioned_docs/version-v0.86.0/aztec/smart_contracts/contract_structure.md
new file mode 100644
index 000000000000..cb792aff1956
--- /dev/null
+++ b/docs/versioned_docs/version-v0.86.0/aztec/smart_contracts/contract_structure.md
@@ -0,0 +1,41 @@
+---
+title: Contract Structure
+sidebar_position: 0
+tags: [contracts]
+---
+
+A contract is a collection of persistent state variables 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.86.0/aztec/smart_contracts/contract_upgrades.md b/docs/versioned_docs/version-v0.86.0/aztec/smart_contracts/contract_upgrades.md
new file mode 100644
index 000000000000..9aed952bff4d
--- /dev/null
+++ b/docs/versioned_docs/version-v0.86.0/aztec/smart_contracts/contract_upgrades.md
@@ -0,0 +1,185 @@
+---
+title: Contract Upgrades
+sidebar_position: 2
+tags: [contracts]
+---
+
+For familiarity we've used terminology like "deploying a contract instance of a contract class". When considering how it works with contract upgrades it helps to be more specific.
+
+Each deployed contract holds its state, and refers to a class id for its code. Upgrading a contracts implementation is achieved by updating its "current class id" to the new class id, whilst retaining the "original class id" for reasons explained below.
+
+## Original class id
+
+A contract keeps track of the original contract class that it was deployed with, which is the "original" class id. It is this original class that is used when calculating and verifying the contract's [address](contract_creation#instance-address).
+This variable remains unchanged even if a contract is upgraded.
+
+## Current class id
+
+When a contract is first deployed, its current class ID is set equal to its original class ID. The current class ID determines which code implementation the contract actually executes.
+
+During an upgrade:
+
+- The original class ID remains unchanged
+- The current class ID is updated to refer to the new implementation
+- All contract state/data is preserved
+
+## How to upgrade
+
+Contract upgrades in Aztec have to be performed by the contract that wishes to be upgraded calling the Contract instance deployer:
+
+```rust
+use dep::aztec::protocol_types::contract_class_id::ContractClassId;
+use contract_instance_deployer::ContractInstanceDeployer;
+
+#[private]
+fn update_to(new_class_id: ContractClassId) {
+ ContractInstanceDeployer::at(DEPLOYER_CONTRACT_ADDRESS)
+ .update(new_class_id)
+ .enqueue(&mut context);
+}
+```
+
+The update function in the deployer is a public function, so you can enqueue it from a private function like the example or call it from a public function directly.
+
+:::note
+Recall that `#[private]` means calling this function preserves privacy, and it still CAN be called externally by anyone.
+So the `update_to` function above allows anyone to update the contract that implements it. A more complete implementation should have a proper authorization systems to secure contracts from malicious upgrades.
+:::
+
+Contract upgrades are implemented using a SharedMutable storage variable in the deployer protocol contract, since the upgrade applies to both public and private functions.
+This means that they have a delay before entering into effect. The default delay is `3600` blocks but can be configured by the contract:
+
+```rust
+use dep::aztec::protocol_types::contract_class_id::ContractClassId;
+use contract_instance_deployer::ContractInstanceDeployer;
+
+#[private]
+fn set_update_delay(new_delay: u32) {
+ ContractInstanceDeployer::at(DEPLOYER_CONTRACT_ADDRESS)
+ .set_update_delay(new_delay)
+ .enqueue(&mut context);
+}
+```
+
+Where `new_delay` is denominated in blocks. However, take into account that changing the update delay also has as its delay that is the previous delay. So the first delay change will take 3600 blocks to take into effect.
+
+:::info
+The update delay cannot be set lower than `25` blocks
+:::
+
+When sending a transaction, the max_block_number of your TX will be the current block number you're simulating with + the minimum of the update delays that you're interacting with.
+If your TX interacts with a contract that can be upgraded in 30 blocks and another one that can be upgraded in 300 blocks, the max_block_number will be current block + 30.
+Note that this can be even lower if there is an upgrade pending in one of the contracts you're interacting with.
+If the contract you interacted with will upgrade in 2 blocks, the max block number of your tx will be current + 1 blocks.
+Other SharedMutable storage variables read in your tx might reduce this max_block_number further.
+
+:::note
+Only deployed contract instances can upgrade or change its upgrade delay currently. This restriction might be lifted in the future.
+:::
+
+### Upgrade Process
+
+1. **Register New Implementation**
+
+ - First, register the new contract class if it contains public functions
+ - The new implementation must maintain state variable compatibility with the original contract
+
+2. **Perform Upgrade**
+
+ - Call the update function with the new contract class ID
+ - The contract's original class ID remains unchanged
+ - The current class ID is updated to the new implementation
+ - All contract state and data are preserved
+
+3. **Verify Upgrade**
+ - After upgrade, the contract will execute functions from the new implementation
+ - The contract's address remains the same since it's based on the original class ID
+ - Existing state variables and their values are preserved
+
+### How to interact with an upgraded contract
+
+The PXE stores the contract instances and classes in a local database. When a contract is updated, in order to interact with it we need to pass the new artifact to the PXE, since the protocol doesn't publish artifacts.
+Consider this contract as an example:
+
+```rust
+#[aztec]
+contract Updatable {
+...
+
+ #[private]
+ fn update_to(new_class_id: ContractClassId) {
+ ContractInstanceDeployer::at(DEPLOYER_CONTRACT_ADDRESS).update(new_class_id).enqueue(
+ &mut context,
+ );
+ }
+...
+```
+
+You'd upgrade it in aztec.js doing something similar to this:
+
+```typescript
+const contract = await UpdatableContract.deploy(wallet, ...args)
+ .send()
+ .deployed();
+const updatedContractClassId = (
+ await getContractClassFromArtifact(UpdatedContractArtifact)
+).id;
+await contract.methods.update_to(updatedContractClassId).send().wait();
+```
+
+Now, when the update has happened, calling `at` with the new contract artifact will automatically update the contract instance in the PXE if it's outdated:
+
+```typescript
+// 'at' will call PXE updateContract if outdated
+const updatedContract = await UpdatedContract.at(address, wallet);
+```
+
+If you try to call `at` with a different contract that is not the current version, it'll fail
+
+```typescript
+// throws when trying to update the PXE instance to RandomContract
+// since the current one is UpdatedContract
+await RandomContract.at(address, wallet);
+```
+
+### Security Considerations
+
+1. **Access Control**
+
+ - Implement proper access controls for upgrade functions
+ - Consider customizing the upgrades delay for your needs using `set_update_delay`
+
+2. **State Compatibility**
+
+ - Ensure new implementation is compatible with existing state
+ - Maintain the same storage layout to prevent data corruption
+
+3. **Testing**
+
+ - Test upgrades thoroughly in a development environment
+ - Verify all existing functionality works with the new implementation
+
+### Example
+
+```rust
+contract Updatable {
+ #[private]
+ fn update_to(new_class_id: ContractClassId) {
+ // TODO: Add access control
+ assert(context.msg_sender() == owner, "Unauthorized");
+
+ // Perform the upgrade
+ ContractInstanceDeployer::at(DEPLOYER_CONTRACT_ADDRESS)
+ .update(new_class_id)
+ .enqueue(&mut context);
+ }
+
+ #[private]
+ fn set_update_delay(new_delay: u32) {
+ // TODO: Add access control
+ ContractInstanceDeployer::at(DEPLOYER_CONTRACT_ADDRESS)
+ .set_update_delay(new_delay)
+ .enqueue(&mut context);
+ }
+}
+```
diff --git a/docs/versioned_docs/version-v0.86.0/aztec/smart_contracts/functions/attributes.md b/docs/versioned_docs/version-v0.86.0/aztec/smart_contracts/functions/attributes.md
new file mode 100644
index 000000000000..05b767638c90
--- /dev/null
+++ b/docs/versioned_docs/version-v0.86.0/aztec/smart_contracts/functions/attributes.md
@@ -0,0 +1,482 @@
+---
+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/docs_example_contract/src/main.nr#L156-L161
+
+
+#### 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!
+) -> 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/docs_example_contract/src/main.nr#L167-L212
+
+
+#### 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/docs_example_contract/src/main.nr#L171-L173
+
+
+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
+) -> PrivateCircuitPublicInputs {
+```
+> Source code: noir-projects/noir-contracts/contracts/docs/docs_example_contract/src/main.nr#L179-L181
+
+
+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/docs_example_contract/src/main.nr#L184-L188
+
+
+_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/docs_example_contract/src/main.nr#L190-L192
+
+
+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/docs_example_contract/src/main.nr#L201-L205
+
+
+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/docs_example_contract/src/main.nr#L193-L195
+
+
+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/docs_example_contract/src/main.nr#L207-L209
+
+
+This function takes the application context, and converts it into the `PrivateCircuitPublicInputs` structure. This structure is then passed to the kernel circuit.
+
+## Utility functions #[utility]
+
+Contract functions marked with `#[utility]` are used to perform state queries from an off-chain client (from both private and public state!) or to modify local contract-related PXE state (e.g. when processing logs in Aztec.nr), 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](https://noir-lang.org/docs/explainers/explainer-oracle).
+
+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. Utility functions exist as Noir contract code because they let developers utilize the rest of the contract code directly by being part of the same Noir crate, 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. Unlike `view` functions however, `utility` functions can modify local off-chain PXE state via oracle calls - this can be leveraged for example to process messages delivered off-chain and then notify PXE of newly discovered notes.
+
+When a utility 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 block header from the [PXE database](../../concepts/pxe/index.md#database) and passes it along with the contract address to `UtilityExecutionOracle`. This creates a context that simulates the state of the blockchain at a specific block, allowing the utility 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, `runUtility` function is invoked on the simulator:
+
+```typescript title="execute_utility_function" showLineNumbers
+/**
+ * Runs a utility function.
+ * @param call - The function call to execute.
+ * @param authwits - Authentication witnesses required for the function call.
+ * @param scopes - Optional array of account addresses whose notes can be accessed in this call. Defaults to all
+ * accounts if not specified.
+ * @returns A decoded ABI value containing the function's return data.
+ */
+public async runUtility(call: FunctionCall, authwits: AuthWitness[], scopes?: AztecAddress[]): PromiseAccounts
+PXE (pronounced 'pixie')
+State model
+Storage
+Wallets
+Protocol Circuits
+
+
+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\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/app/token_contract/src/main.nr#L366-L372 + + +### 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/app/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.86.0", directory="noir-projects/aztec-nr/aztec" } +authwit = { git="https://github.com/AztecProtocol/aztec-packages/", tag="v0.86.0", 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/app/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/app/token_contract/src/main.nr#L363-L383 + + +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/app/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/app/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.86.0/developers/guides/smart_contracts/writing_contracts/call_contracts.md b/docs/versioned_docs/version-v0.86.0/developers/guides/smart_contracts/writing_contracts/call_contracts.md new file mode 100644 index 000000000000..3b601464eb3b --- /dev/null +++ b/docs/versioned_docs/version-v0.86.0/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.86.0", directory="noir-projects/noir-contracts/contracts/app/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/app/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/app/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/app/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/concepts/call_types.md). diff --git a/docs/versioned_docs/version-v0.86.0/developers/guides/smart_contracts/writing_contracts/call_functions.md b/docs/versioned_docs/version-v0.86.0/developers/guides/smart_contracts/writing_contracts/call_functions.md new file mode 100644 index 000000000000..3b601464eb3b --- /dev/null +++ b/docs/versioned_docs/version-v0.86.0/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.86.0", directory="noir-projects/noir-contracts/contracts/app/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/app/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/app/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/app/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/concepts/call_types.md). diff --git a/docs/versioned_docs/version-v0.86.0/developers/guides/smart_contracts/writing_contracts/common_patterns/index.md b/docs/versioned_docs/version-v0.86.0/developers/guides/smart_contracts/writing_contracts/common_patterns/index.md new file mode 100644 index 000000000000..626f121f31b5 --- /dev/null +++ b/docs/versioned_docs/version-v0.86.0/developers/guides/smart_contracts/writing_contracts/common_patterns/index.md @@ -0,0 +1,256 @@ +--- +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
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.86.0/developers/index.md b/docs/versioned_docs/version-v0.86.0/developers/index.md new file mode 100644 index 000000000000..aa692db11222 --- /dev/null +++ b/docs/versioned_docs/version-v0.86.0/developers/index.md @@ -0,0 +1,79 @@ +--- +id: index +sidebar_position: 0 +title: Build +--- + +# Build + +## Get Started + +
+
+
+
+
+ Get started on Aztec by installing the sandbox and playing with it
+
+
+
+
+## Build applications
+
+Getting Started
+
+
+
+
+
+ Go from zero to hero by following these tutorials in order, starting with a counter contract
+
+
+
+
+
+
+
+ Learn how everything works together by building an app in JavaScript that connects to a contract
+
+
+
+
+## Clone a repo
+
+Contract Tutorials
+Full stack app on Aztec
+
+
+ Full stack app on Aztec
+
+
+
+
+
+ Find requests for applications, potential designs, and existing ecosystem projects
+
+
+
diff --git a/docs/versioned_docs/version-v0.86.0/developers/inspiration.md b/docs/versioned_docs/version-v0.86.0/developers/inspiration.md
new file mode 100644
index 000000000000..6f89bd191338
--- /dev/null
+++ b/docs/versioned_docs/version-v0.86.0/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.86.0/developers/reference/aztecjs/_category_.yml b/docs/versioned_docs/version-v0.86.0/developers/reference/aztecjs/_category_.yml
new file mode 100644
index 000000000000..57dc01ecdd54
--- /dev/null
+++ b/docs/versioned_docs/version-v0.86.0/developers/reference/aztecjs/_category_.yml
@@ -0,0 +1 @@
+label: "AztecJS"
diff --git a/docs/versioned_docs/version-v0.86.0/developers/reference/aztecjs/accounts/_category_.yml b/docs/versioned_docs/version-v0.86.0/developers/reference/aztecjs/accounts/_category_.yml
new file mode 100644
index 000000000000..08af16b98be8
--- /dev/null
+++ b/docs/versioned_docs/version-v0.86.0/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.86.0/developers/reference/aztecjs/accounts/classes/_category_.yml b/docs/versioned_docs/version-v0.86.0/developers/reference/aztecjs/accounts/classes/_category_.yml
new file mode 100644
index 000000000000..55c7980a4644
--- /dev/null
+++ b/docs/versioned_docs/version-v0.86.0/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.86.0/developers/reference/aztecjs/accounts/classes/defaults.DefaultAccountContract.md b/docs/versioned_docs/version-v0.86.0/developers/reference/aztecjs/accounts/classes/defaults.DefaultAccountContract.md
new file mode 100644
index 000000000000..11d775807e59
--- /dev/null
+++ b/docs/versioned_docs/version-v0.86.0/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.86.0/developers/reference/aztecjs/accounts/classes/defaults.DefaultAccountInterface.md b/docs/versioned_docs/version-v0.86.0/developers/reference/aztecjs/accounts/classes/defaults.DefaultAccountInterface.md
new file mode 100644
index 000000000000..b55ab89a094d
--- /dev/null
+++ b/docs/versioned_docs/version-v0.86.0/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"`` \| ``"rollupVersion"``\> |
+
+#### 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.86.0/developers/reference/aztecjs/accounts/classes/ecdsa.EcdsaKAccountContract.md b/docs/versioned_docs/version-v0.86.0/developers/reference/aztecjs/accounts/classes/ecdsa.EcdsaKAccountContract.md
new file mode 100644
index 000000000000..3068a0c66294
--- /dev/null
+++ b/docs/versioned_docs/version-v0.86.0/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.86.0/developers/reference/aztecjs/accounts/classes/ecdsa.EcdsaRAccountContract.md b/docs/versioned_docs/version-v0.86.0/developers/reference/aztecjs/accounts/classes/ecdsa.EcdsaRAccountContract.md
new file mode 100644
index 000000000000..5f0396ddf80d
--- /dev/null
+++ b/docs/versioned_docs/version-v0.86.0/developers/reference/aztecjs/accounts/classes/ecdsa.EcdsaRAccountContract.md
@@ -0,0 +1,107 @@
+---
+id: "ecdsa.EcdsaRAccountContract"
+title: "Class: EcdsaRAccountContract"
+sidebar_label: "EcdsaRAccountContract"
+custom_edit_url: null
+---
+
+[ecdsa](../modules/ecdsa.md).EcdsaRAccountContract
+
+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
+
+- `EcdsaRBaseAccountContract`
+
+ ↳ **`EcdsaRAccountContract`**
+
+## Constructors
+
+### constructor
+
+• **new EcdsaRAccountContract**(`signingPrivateKey`): [`EcdsaRAccountContract`](ecdsa.EcdsaRAccountContract.md)
+
+#### Parameters
+
+| Name | Type |
+| :------ | :------ |
+| `signingPrivateKey` | `Buffer` |
+
+#### Returns
+
+[`EcdsaRAccountContract`](ecdsa.EcdsaRAccountContract.md)
+
+#### Overrides
+
+EcdsaRBaseAccountContract.constructor
+
+## Methods
+
+### getAuthWitnessProvider
+
+▸ **getAuthWitnessProvider**(`_address`): `AuthWitnessProvider`
+
+#### Parameters
+
+| Name | Type |
+| :------ | :------ |
+| `_address` | `CompleteAddress` |
+
+#### Returns
+
+`AuthWitnessProvider`
+
+#### Inherited from
+
+EcdsaRBaseAccountContract.getAuthWitnessProvider
+
+___
+
+### getContractArtifact
+
+▸ **getContractArtifact**(): `Promise`\<`ContractArtifact`\>
+
+#### Returns
+
+`Promise`\<`ContractArtifact`\>
+
+#### Overrides
+
+EcdsaRBaseAccountContract.getContractArtifact
+
+___
+
+### getDeploymentFunctionAndArgs
+
+▸ **getDeploymentFunctionAndArgs**(): `Promise`\<\{ `constructorArgs`: `Buffer`[] ; `constructorName`: `string` = 'constructor' }\>
+
+#### Returns
+
+`Promise`\<\{ `constructorArgs`: `Buffer`[] ; `constructorName`: `string` = 'constructor' }\>
+
+#### Inherited from
+
+EcdsaRBaseAccountContract.getDeploymentFunctionAndArgs
+
+___
+
+### getInterface
+
+▸ **getInterface**(`address`, `nodeInfo`): `AccountInterface`
+
+#### Parameters
+
+| Name | Type |
+| :------ | :------ |
+| `address` | `CompleteAddress` |
+| `nodeInfo` | `NodeInfo` |
+
+#### Returns
+
+`AccountInterface`
+
+#### Inherited from
+
+EcdsaRBaseAccountContract.getInterface
diff --git a/docs/versioned_docs/version-v0.86.0/developers/reference/aztecjs/accounts/classes/ecdsa.EcdsaRSSHAccountContract.md b/docs/versioned_docs/version-v0.86.0/developers/reference/aztecjs/accounts/classes/ecdsa.EcdsaRSSHAccountContract.md
new file mode 100644
index 000000000000..7c25ebb65998
--- /dev/null
+++ b/docs/versioned_docs/version-v0.86.0/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.86.0/developers/reference/aztecjs/accounts/classes/schnorr.SchnorrAccountContract.md b/docs/versioned_docs/version-v0.86.0/developers/reference/aztecjs/accounts/classes/schnorr.SchnorrAccountContract.md
new file mode 100644
index 000000000000..ba045b038046
--- /dev/null
+++ b/docs/versioned_docs/version-v0.86.0/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.86.0/developers/reference/aztecjs/accounts/classes/single_key.SingleKeyAccountContract.md b/docs/versioned_docs/version-v0.86.0/developers/reference/aztecjs/accounts/classes/single_key.SingleKeyAccountContract.md
new file mode 100644
index 000000000000..d9b230516512
--- /dev/null
+++ b/docs/versioned_docs/version-v0.86.0/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.86.0/developers/reference/aztecjs/accounts/index.md b/docs/versioned_docs/version-v0.86.0/developers/reference/aztecjs/accounts/index.md
new file mode 100644
index 000000000000..0c19cb267f7e
--- /dev/null
+++ b/docs/versioned_docs/version-v0.86.0/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.86.0/developers/reference/aztecjs/accounts/interfaces/_category_.yml b/docs/versioned_docs/version-v0.86.0/developers/reference/aztecjs/accounts/interfaces/_category_.yml
new file mode 100644
index 000000000000..43bec88cfa0a
--- /dev/null
+++ b/docs/versioned_docs/version-v0.86.0/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.86.0/developers/reference/aztecjs/accounts/interfaces/testing.InitialAccountData.md b/docs/versioned_docs/version-v0.86.0/developers/reference/aztecjs/accounts/interfaces/testing.InitialAccountData.md
new file mode 100644
index 000000000000..7b2757593317
--- /dev/null
+++ b/docs/versioned_docs/version-v0.86.0/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.86.0/developers/reference/aztecjs/accounts/modules/_category_.yml b/docs/versioned_docs/version-v0.86.0/developers/reference/aztecjs/accounts/modules/_category_.yml
new file mode 100644
index 000000000000..63f9c4e40160
--- /dev/null
+++ b/docs/versioned_docs/version-v0.86.0/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.86.0/developers/reference/aztecjs/accounts/modules/defaults.md b/docs/versioned_docs/version-v0.86.0/developers/reference/aztecjs/accounts/modules/defaults.md
new file mode 100644
index 000000000000..9252b70f72ae
--- /dev/null
+++ b/docs/versioned_docs/version-v0.86.0/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.86.0/developers/reference/aztecjs/accounts/modules/ecdsa.md b/docs/versioned_docs/version-v0.86.0/developers/reference/aztecjs/accounts/modules/ecdsa.md
new file mode 100644
index 000000000000..f73fe5ca2770
--- /dev/null
+++ b/docs/versioned_docs/version-v0.86.0/developers/reference/aztecjs/accounts/modules/ecdsa.md
@@ -0,0 +1,160 @@
+---
+id: "ecdsa"
+title: "Module: ecdsa"
+sidebar_label: "ecdsa"
+sidebar_position: 0
+custom_edit_url: null
+---
+
+## Classes
+
+- [EcdsaKAccountContract](../classes/ecdsa.EcdsaKAccountContract.md)
+- [EcdsaRAccountContract](../classes/ecdsa.EcdsaRAccountContract.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.
+
+___
+
+### getEcdsaRAccount
+
+▸ **getEcdsaRAccount**(`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
+
+___
+
+### 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.
+
+___
+
+### getEcdsaRWallet
+
+▸ **getEcdsaRWallet**(`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.
diff --git a/docs/versioned_docs/version-v0.86.0/developers/reference/aztecjs/accounts/modules/schnorr.md b/docs/versioned_docs/version-v0.86.0/developers/reference/aztecjs/accounts/modules/schnorr.md
new file mode 100644
index 000000000000..cbd6dcd7734e
--- /dev/null
+++ b/docs/versioned_docs/version-v0.86.0/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.86.0/developers/reference/aztecjs/accounts/modules/single_key.md b/docs/versioned_docs/version-v0.86.0/developers/reference/aztecjs/accounts/modules/single_key.md
new file mode 100644
index 000000000000..e376e50fbb03
--- /dev/null
+++ b/docs/versioned_docs/version-v0.86.0/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.86.0/developers/reference/aztecjs/accounts/modules/testing.md b/docs/versioned_docs/version-v0.86.0/developers/reference/aztecjs/accounts/modules/testing.md
new file mode 100644
index 000000000000..604fc19f388f
--- /dev/null
+++ b/docs/versioned_docs/version-v0.86.0/developers/reference/aztecjs/accounts/modules/testing.md
@@ -0,0 +1,193 @@
+---
+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)[]\>
+
+___
+
+### getInitialTestAccountsManagers
+
+▸ **getInitialTestAccountsManagers**(`pxe`): `Promise`\<`AccountManager`[]\>
+
+Gets a collection of account managers for the Aztec accounts that are initially stored in the test environment.
+
+#### Parameters
+
+| Name | Type | Description |
+| :------ | :------ | :------ |
+| `pxe` | `PXE` | PXE instance. |
+
+#### Returns
+
+`Promise`\<`AccountManager`[]\>
+
+A set of AccountManager implementations for each of the initial accounts.
+
+___
+
+### 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.86.0/developers/reference/aztecjs/aztec-js/_category_.yml b/docs/versioned_docs/version-v0.86.0/developers/reference/aztecjs/aztec-js/_category_.yml
new file mode 100644
index 000000000000..f5c77d17cdcf
--- /dev/null
+++ b/docs/versioned_docs/version-v0.86.0/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.86.0/developers/reference/aztecjs/aztec-js/index.md b/docs/versioned_docs/version-v0.86.0/developers/reference/aztecjs/aztec-js/index.md
new file mode 100644
index 000000000000..2961da2dd54c
--- /dev/null
+++ b/docs/versioned_docs/version-v0.86.0/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.86.0/developers/reference/aztecjs/aztec-js/interfaces/AccountContract.md b/docs/versioned_docs/version-v0.86.0/developers/reference/aztecjs/aztec-js/interfaces/AccountContract.md
new file mode 100644
index 000000000000..8e86c77e9efa
--- /dev/null
+++ b/docs/versioned_docs/version-v0.86.0/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.86.0/developers/reference/aztecjs/aztec-js/interfaces/AccountInterface.md b/docs/versioned_docs/version-v0.86.0/developers/reference/aztecjs/aztec-js/interfaces/AccountInterface.md
new file mode 100644
index 000000000000..c2197f036a0f
--- /dev/null
+++ b/docs/versioned_docs/version-v0.86.0/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.86.0/developers/reference/aztecjs/aztec-js/interfaces/_category_.yml b/docs/versioned_docs/version-v0.86.0/developers/reference/aztecjs/aztec-js/interfaces/_category_.yml
new file mode 100644
index 000000000000..43bec88cfa0a
--- /dev/null
+++ b/docs/versioned_docs/version-v0.86.0/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.86.0/developers/reference/aztecjs/pxe/_category_.yml b/docs/versioned_docs/version-v0.86.0/developers/reference/aztecjs/pxe/_category_.yml
new file mode 100644
index 000000000000..3095e3e72ff8
--- /dev/null
+++ b/docs/versioned_docs/version-v0.86.0/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.86.0/developers/reference/aztecjs/pxe/enums/EventType.md b/docs/versioned_docs/version-v0.86.0/developers/reference/aztecjs/pxe/enums/EventType.md
new file mode 100644
index 000000000000..338e46d1034e
--- /dev/null
+++ b/docs/versioned_docs/version-v0.86.0/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.86.0/developers/reference/aztecjs/pxe/enums/_category_.yml b/docs/versioned_docs/version-v0.86.0/developers/reference/aztecjs/pxe/enums/_category_.yml
new file mode 100644
index 000000000000..1687a9e03fd7
--- /dev/null
+++ b/docs/versioned_docs/version-v0.86.0/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.86.0/developers/reference/aztecjs/pxe/index.md b/docs/versioned_docs/version-v0.86.0/developers/reference/aztecjs/pxe/index.md
new file mode 100644
index 000000000000..390faf79398f
--- /dev/null
+++ b/docs/versioned_docs/version-v0.86.0/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.86.0/developers/reference/aztecjs/pxe/interfaces/ContractClassMetadata.md b/docs/versioned_docs/version-v0.86.0/developers/reference/aztecjs/pxe/interfaces/ContractClassMetadata.md
new file mode 100644
index 000000000000..4a152c2a34a9
--- /dev/null
+++ b/docs/versioned_docs/version-v0.86.0/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.86.0/developers/reference/aztecjs/pxe/interfaces/ContractMetadata.md b/docs/versioned_docs/version-v0.86.0/developers/reference/aztecjs/pxe/interfaces/ContractMetadata.md
new file mode 100644
index 000000000000..7bd09ee675a8
--- /dev/null
+++ b/docs/versioned_docs/version-v0.86.0/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.86.0/developers/reference/aztecjs/pxe/interfaces/PXE.md b/docs/versioned_docs/version-v0.86.0/developers/reference/aztecjs/pxe/interfaces/PXE.md
new file mode 100644
index 000000000000..477ff63c5175
--- /dev/null
+++ b/docs/versioned_docs/version-v0.86.0/developers/reference/aztecjs/pxe/interfaces/PXE.md
@@ -0,0 +1,722 @@
+---
+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, rollup 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`\>(`contractAddress`, `eventMetadata`, `from`, `numBlocks`, `recipients`): `Promise`\<`T`[]\>
+
+Returns the private events given search parameters.
+
+#### Type parameters
+
+| Name |
+| :------ |
+| `T` |
+
+#### Parameters
+
+| Name | Type | Description |
+| :------ | :------ | :------ |
+| `contractAddress` | `AztecAddress` | The address of the contract to get events from. |
+| `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. |
+| `numBlocks` | `number` | The amount of blocks to search. |
+| `recipients` | `AztecAddress`[] | The addresses that decrypted the logs. |
+
+#### 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` \| `IndexedTxEffect`\>
+
+Gets a tx effect.
+
+#### Parameters
+
+| Name | Type | Description |
+| :------ | :------ | :------ |
+| `txHash` | `TxHash` | The hash of the tx corresponding to the tx effect. |
+
+#### Returns
+
+`Promise`\<`undefined` \| `IndexedTxEffect`\>
+
+The requested tx effect with block info (or undefined if not found).
+
+___
+
+### 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 validators 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.
+
+___
+
+### simulateUtility
+
+▸ **simulateUtility**(`functionName`, `args`, `to`, `authwits?`, `from?`, `scopes?`): `Promise`\<`AbiDecoded`\>
+
+Simulate the execution of a contract utility function.
+
+#### Parameters
+
+| Name | Type | Description |
+| :------ | :------ | :------ |
+| `functionName` | `string` | The name of the utility contract function to be called. |
+| `args` | `any`[] | The arguments to be provided to the function. |
+| `to` | `AztecAddress` | The address of the contract to be called. |
+| `authwits?` | `AuthWitness`[] | (Optional) The authentication witnesses required for the function call. |
+| `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 utility 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.86.0/developers/reference/aztecjs/pxe/interfaces/PXEInfo.md b/docs/versioned_docs/version-v0.86.0/developers/reference/aztecjs/pxe/interfaces/PXEInfo.md
new file mode 100644
index 000000000000..b34b5866adef
--- /dev/null
+++ b/docs/versioned_docs/version-v0.86.0/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.86.0/developers/reference/aztecjs/pxe/interfaces/_category_.yml b/docs/versioned_docs/version-v0.86.0/developers/reference/aztecjs/pxe/interfaces/_category_.yml
new file mode 100644
index 000000000000..43bec88cfa0a
--- /dev/null
+++ b/docs/versioned_docs/version-v0.86.0/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.86.0/developers/reference/considerations/_category_.json b/docs/versioned_docs/version-v0.86.0/developers/reference/considerations/_category_.json
new file mode 100644
index 000000000000..3d16e4d09376
--- /dev/null
+++ b/docs/versioned_docs/version-v0.86.0/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.86.0/developers/reference/considerations/limitations.md b/docs/versioned_docs/version-v0.86.0/developers/reference/considerations/limitations.md
new file mode 100644
index 000000000000..79703d48749c
--- /dev/null
+++ b/docs/versioned_docs/version-v0.86.0/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.86.0/developers/reference/considerations/privacy_considerations.md b/docs/versioned_docs/version-v0.86.0/developers/reference/considerations/privacy_considerations.md
new file mode 100644
index 000000000000..7a44889e5669
--- /dev/null
+++ b/docs/versioned_docs/version-v0.86.0/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'](