diff --git a/docs/docs/about_aztec/history/differences_to_aztec_connect.md b/docs/docs/about_aztec/history/differences_to_aztec_connect.md
deleted file mode 100644
index e94c8d1f551..00000000000
--- a/docs/docs/about_aztec/history/differences_to_aztec_connect.md
+++ /dev/null
@@ -1,15 +0,0 @@
-## Heuristics that differ from 'Aztec Connect' (a.k.a. 'Connect')
-
-**A contract cannot manipulate another contract's state**
-
-In Connect, we had multiple circuits that could each create/destroy a unified set of value notes. This was acceptable because all Connect circuits had a single author (us!).
-
-In Aztec our architecture must process arbitrary circuits written by potentially dishonest actors. Contract state must therefore be siloed at the architecture level similar to Ethereum. Fortunately, this does not require splitting up the privacy set.
-
-**Privacy set must be shared across all contracts**
-
-In Connect observers knew when different note types were being created (value note, account note etc). This cannot be the case in Aztec, as we want to provide strong privacy guarantees to all private contracts even if they have few transactions interacting with their contract.
-
-**Support for call semantics**
-
-If a contract can only modify its own state, we need a way for a contract to "call" another contract to request state modifications.
diff --git a/docs/docs/concepts/advanced/circuits/kernels/main.md b/docs/docs/concepts/advanced/circuits/kernels/main.md
deleted file mode 100644
index 66491cc446c..00000000000
--- a/docs/docs/concepts/advanced/circuits/kernels/main.md
+++ /dev/null
@@ -1,5 +0,0 @@
-import DocCardList from '@theme/DocCardList';
-
-# Kernel Circuits
-
-<DocCardList />
diff --git a/docs/docs/concepts/advanced/data_structures/main.md b/docs/docs/concepts/advanced/data_structures/main.md
deleted file mode 100644
index 43c378b2ec7..00000000000
--- a/docs/docs/concepts/advanced/data_structures/main.md
+++ /dev/null
@@ -1,5 +0,0 @@
-import DocCardList from '@theme/DocCardList';
-
-# Data Structures
-
-<DocCardList />
diff --git a/docs/docs/concepts/advanced/main.md b/docs/docs/concepts/advanced/main.md
deleted file mode 100644
index a1234235739..00000000000
--- a/docs/docs/concepts/advanced/main.md
+++ /dev/null
@@ -1,5 +0,0 @@
-import DocCardList from '@theme/DocCardList';
-
-# Advanced Concepts
-
-<DocCardList />
diff --git a/docs/docs/dev_docs/getting_started/core-concepts.md b/docs/docs/dev_docs/getting_started/core-concepts.md
deleted file mode 100644
index e4549fb9731..00000000000
--- a/docs/docs/dev_docs/getting_started/core-concepts.md
+++ /dev/null
@@ -1,88 +0,0 @@
----
-title: Core Concepts
----
-
-import Image from '@theme/IdealImage';
-
-This page outlines Aztec concepts that are essential for developers to understand. Understanding these concepts will help you as you start to dive deeper into smart contracts.
-
-A little bit of time here can save a lot down the road.
-
-## Aztec Overview
-
-<Image img={require('/img/aztec_high_level_network_architecture.svg')} />
-
-To sum this up:
-
-1. A user interacts with Aztec through Aztec.js (like web3js or ethersjs) or Aztec CLI
-2. Private functions are executed in the PXE, which is client-side
-3. They are rolled up and sent to the Public VM (running on an Aztec node)
-4. Public functions are executed in the Public VM
-5. The Public VM rolls up the private & public transaction rollups
-6. These rollups are submitted to Ethereum
-
-## Composability between private and public state
-
-The PXE is unaware of the Public VM. And the Public VM is unaware of the PXE. They are completely separate execution environments. This means:
-
-- The PXE and the Public VM cannot directly communicate with each other
-- Private transactions in the PXE are executed first, followed by public transactions
-
-You can call a public function from a private function by using `context.call_public_function`, like this:
-
-#include_code call_public_function yarn-project/noir-contracts/contracts/card_game_contract/src/main.nr rust
-
-You cannot call a private function from a public function, but you can use a [slow updates tree](../contracts/syntax/slow_updates_tree.md) to read historical public state and stage writes to public state from a private function.
-
-### Data types
-
-Private state works with UTXOs, or what we call notes. To keep things private, everything is stored in an [append-only UTXO tree](../../concepts/advanced/data_structures/trees.md#note-hash-tree), and a nullifier is created when notes are invalidated.
-
-Public state works similarly to other chains like Ethereum, behaving like a public ledger.
-
-Working with private state is like creating commitments and nullifiers to state, whereas working with public state is like directly updating state.
-
-We have abstractions for working with private state so you don't have to worry about these commitments and nullifiers. However, it is important to understand that the types and libraries you use will be different when working with private state and public state.
-
-For example, let's say you're trying to work with an integer. We have a library called `EasyPrivateUint` that acts like an integer but in the background is actually updating notes in private state. For the public side, we instead have something called `SafeU120`. You cannot use EasyPrivateUint in a public environment, and you cannot use SafeU120 in a private environment.
-
-## Storage
-
-Currently, when writing Aztec.nr smart contracts, you will need to define two things when initiating storage:
-
-1. The storage struct, ie what you are storing and their types
-2. A storage `impl` block with `init` function that will be called when you use the storage in a function
-
-The `init` function must declare the storage struct with an instantiation defining how variables are accessed and manipulated. Each variable must be given a storage slot, which can be anything except 0.
-
-The impl block is likely to be abstracted away at a later date.
-
-Learn more about how to use storage [here](../contracts/syntax/storage/main.md).
-
-## Portals
-
-Aztec allows you to interact with Ethereum privately - ie no-one knows where the transaction is coming from, just that it is coming from somewhere on Aztec.
-
-This is achieved through portals - these are smart contracts written in Solidity that are related to the Ethereum smart contract you want to interact with.
-
-A portal can be associated with multiple Aztec contracts, but an Aztec contract can only be associated with one portal.
-
-Learn more about how to work with portals [here](../contracts/portals/main.md).
-
-## Accounts
-
-Every account in Aztec is a smart contract (account abstraction). This allows implementing different schemes for transaction signing, nonce management, and fee payments.
-
-You can write your own account contract to define the rules by which user transactions are authorized and paid for, as well as how user keys are managed.
-
-Learn more about account contracts [here](../../concepts/foundation/accounts/main.md).
-
-## Noir Language
-
-Aztec smart contracts are written in a framework on top of Noir, the zero-knowledge domain-specific language developed specifically for Aztec. Its syntax is similar to Rust. Outside of Aztec, Noir is used for writing circuits that can be verified in Solidity.
-
-A cursory understanding of Noir is sufficient for writing Aztec contracts. The [Noir docs](https://noir-lang.org) will be a helpful reference when you start writing more advanced contracts.
-
-## Next steps
-
-Continue through the getting started section by reviewing how to write a smart contract contract in [Getting started with Aztec.nr](./aztecnr-getting-started.md).
diff --git a/docs/docs/developers/apis/accounts/_category_.yml b/docs/docs/developers/apis/accounts/_category_.yml
new file mode 100644
index 00000000000..24a46026174
--- /dev/null
+++ b/docs/docs/developers/apis/accounts/_category_.yml
@@ -0,0 +1 @@
+label: "API"
\ No newline at end of file
diff --git a/docs/docs/developers/apis/accounts/classes/_category_.yml b/docs/docs/developers/apis/accounts/classes/_category_.yml
new file mode 100644
index 00000000000..55c7980a464
--- /dev/null
+++ b/docs/docs/developers/apis/accounts/classes/_category_.yml
@@ -0,0 +1,2 @@
+label: "Classes"
+position: 3
\ No newline at end of file
diff --git a/docs/docs/developers/apis/accounts/classes/defaults.DefaultAccountContract.md b/docs/docs/developers/apis/accounts/classes/defaults.DefaultAccountContract.md
new file mode 100644
index 00000000000..3e9090fbdbf
--- /dev/null
+++ b/docs/docs/developers/apis/accounts/classes/defaults.DefaultAccountContract.md
@@ -0,0 +1,112 @@
+---
+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.
+
+## Hierarchy
+
+- **`DefaultAccountContract`**
+
+  ↳ [`EcdsaAccountContract`](ecdsa.EcdsaAccountContract.md)
+
+  ↳ [`SchnorrAccountContract`](schnorr.SchnorrAccountContract.md)
+
+  ↳ [`SingleKeyAccountContract`](single_key.SingleKeyAccountContract.md)
+
+## Implements
+
+- `AccountContract`
+
+## Constructors
+
+### constructor
+
+• **new DefaultAccountContract**(`artifact`): [`DefaultAccountContract`](defaults.DefaultAccountContract.md)
+
+#### Parameters
+
+| Name | Type |
+| :------ | :------ |
+| `artifact` | `ContractArtifact` |
+
+#### Returns
+
+[`DefaultAccountContract`](defaults.DefaultAccountContract.md)
+
+## Properties
+
+### artifact
+
+• `Private` **artifact**: `ContractArtifact`
+
+## Methods
+
+### getAuthWitnessProvider
+
+▸ **getAuthWitnessProvider**(`address`): `AuthWitnessProvider`
+
+#### Parameters
+
+| Name | Type |
+| :------ | :------ |
+| `address` | `CompleteAddress` |
+
+#### Returns
+
+`AuthWitnessProvider`
+
+___
+
+### getContractArtifact
+
+▸ **getContractArtifact**(): `ContractArtifact`
+
+#### Returns
+
+`ContractArtifact`
+
+#### Implementation of
+
+AccountContract.getContractArtifact
+
+___
+
+### getDeploymentArgs
+
+▸ **getDeploymentArgs**(): `any`[]
+
+#### Returns
+
+`any`[]
+
+#### Implementation of
+
+AccountContract.getDeploymentArgs
+
+___
+
+### getInterface
+
+▸ **getInterface**(`address`, `nodeInfo`): `AccountInterface`
+
+#### Parameters
+
+| Name | Type |
+| :------ | :------ |
+| `address` | `CompleteAddress` |
+| `nodeInfo` | `NodeInfo` |
+
+#### Returns
+
+`AccountInterface`
+
+#### Implementation of
+
+AccountContract.getInterface
diff --git a/docs/docs/developers/apis/accounts/classes/defaults.DefaultAccountEntrypoint.md b/docs/docs/developers/apis/accounts/classes/defaults.DefaultAccountEntrypoint.md
new file mode 100644
index 00000000000..9829fd098b0
--- /dev/null
+++ b/docs/docs/developers/apis/accounts/classes/defaults.DefaultAccountEntrypoint.md
@@ -0,0 +1,88 @@
+---
+id: "defaults.DefaultAccountEntrypoint"
+title: "Class: DefaultAccountEntrypoint"
+sidebar_label: "DefaultAccountEntrypoint"
+custom_edit_url: null
+---
+
+[defaults](../modules/defaults.md).DefaultAccountEntrypoint
+
+Implementation for an entrypoint interface that follows the default entrypoint signature
+for an account, which accepts an EntrypointPayload as defined in noir-libs/aztec-noir/src/entrypoint.nr.
+
+## Implements
+
+- `EntrypointInterface`
+
+## Constructors
+
+### constructor
+
+• **new DefaultAccountEntrypoint**(`address`, `auth`, `chainId?`, `version?`): [`DefaultAccountEntrypoint`](defaults.DefaultAccountEntrypoint.md)
+
+#### Parameters
+
+| Name | Type | Default value |
+| :------ | :------ | :------ |
+| `address` | `AztecAddress` | `undefined` |
+| `auth` | `AuthWitnessProvider` | `undefined` |
+| `chainId` | `number` | `DEFAULT_CHAIN_ID` |
+| `version` | `number` | `DEFAULT_VERSION` |
+
+#### Returns
+
+[`DefaultAccountEntrypoint`](defaults.DefaultAccountEntrypoint.md)
+
+## Properties
+
+### address
+
+• `Private` **address**: `AztecAddress`
+
+___
+
+### auth
+
+• `Private` **auth**: `AuthWitnessProvider`
+
+___
+
+### chainId
+
+• `Private` **chainId**: `number` = `DEFAULT_CHAIN_ID`
+
+___
+
+### version
+
+• `Private` **version**: `number` = `DEFAULT_VERSION`
+
+## Methods
+
+### createTxExecutionRequest
+
+▸ **createTxExecutionRequest**(`executions`): `Promise`\<`TxExecutionRequest`\>
+
+#### Parameters
+
+| Name | Type |
+| :------ | :------ |
+| `executions` | `FunctionCall`[] |
+
+#### Returns
+
+`Promise`\<`TxExecutionRequest`\>
+
+#### Implementation of
+
+EntrypointInterface.createTxExecutionRequest
+
+___
+
+### getEntrypointAbi
+
+▸ **getEntrypointAbi**(): `FunctionAbi`
+
+#### Returns
+
+`FunctionAbi`
diff --git a/docs/docs/developers/apis/accounts/classes/defaults.DefaultAccountInterface.md b/docs/docs/developers/apis/accounts/classes/defaults.DefaultAccountInterface.md
new file mode 100644
index 00000000000..3da53df033e
--- /dev/null
+++ b/docs/docs/developers/apis/accounts/classes/defaults.DefaultAccountInterface.md
@@ -0,0 +1,105 @@
+---
+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 accepts an EntrypointPayload as defined in noir-libs/aztec-noir/src/entrypoint.nr.
+
+## Implements
+
+- `AccountInterface`
+
+## Constructors
+
+### constructor
+
+• **new DefaultAccountInterface**(`authWitnessProvider`, `address`, `nodeInfo`): [`DefaultAccountInterface`](defaults.DefaultAccountInterface.md)
+
+#### Parameters
+
+| Name | Type |
+| :------ | :------ |
+| `authWitnessProvider` | `AuthWitnessProvider` |
+| `address` | `CompleteAddress` |
+| `nodeInfo` | `Pick`\<`NodeInfo`, ``"chainId"`` \| ``"protocolVersion"``\> |
+
+#### Returns
+
+[`DefaultAccountInterface`](defaults.DefaultAccountInterface.md)
+
+## Properties
+
+### address
+
+• `Private` **address**: `CompleteAddress`
+
+___
+
+### authWitnessProvider
+
+• `Private` **authWitnessProvider**: `AuthWitnessProvider`
+
+___
+
+### entrypoint
+
+• `Private` **entrypoint**: `EntrypointInterface`
+
+## Methods
+
+### createAuthWitness
+
+▸ **createAuthWitness**(`message`): `Promise`\<`AuthWitness`\>
+
+#### Parameters
+
+| Name | Type |
+| :------ | :------ |
+| `message` | `Fr` |
+
+#### Returns
+
+`Promise`\<`AuthWitness`\>
+
+#### Implementation of
+
+AccountInterface.createAuthWitness
+
+___
+
+### createTxExecutionRequest
+
+▸ **createTxExecutionRequest**(`executions`): `Promise`\<`TxExecutionRequest`\>
+
+#### Parameters
+
+| Name | Type |
+| :------ | :------ |
+| `executions` | `FunctionCall`[] |
+
+#### Returns
+
+`Promise`\<`TxExecutionRequest`\>
+
+#### Implementation of
+
+AccountInterface.createTxExecutionRequest
+
+___
+
+### getCompleteAddress
+
+▸ **getCompleteAddress**(): `CompleteAddress`
+
+#### Returns
+
+`CompleteAddress`
+
+#### Implementation of
+
+AccountInterface.getCompleteAddress
diff --git a/docs/docs/developers/apis/accounts/classes/ecdsa.EcdsaAccountContract.md b/docs/docs/developers/apis/accounts/classes/ecdsa.EcdsaAccountContract.md
new file mode 100644
index 00000000000..18ef35288d9
--- /dev/null
+++ b/docs/docs/developers/apis/accounts/classes/ecdsa.EcdsaAccountContract.md
@@ -0,0 +1,112 @@
+---
+id: "ecdsa.EcdsaAccountContract"
+title: "Class: EcdsaAccountContract"
+sidebar_label: "EcdsaAccountContract"
+custom_edit_url: null
+---
+
+[ecdsa](../modules/ecdsa.md).EcdsaAccountContract
+
+Account contract that authenticates transactions using ECDSA signatures
+verified against a secp256k1 public key stored in an immutable encrypted note.
+
+## Hierarchy
+
+- [`DefaultAccountContract`](defaults.DefaultAccountContract.md)
+
+  ↳ **`EcdsaAccountContract`**
+
+## Constructors
+
+### constructor
+
+• **new EcdsaAccountContract**(`signingPrivateKey`): [`EcdsaAccountContract`](ecdsa.EcdsaAccountContract.md)
+
+#### Parameters
+
+| Name | Type |
+| :------ | :------ |
+| `signingPrivateKey` | `Buffer` |
+
+#### Returns
+
+[`EcdsaAccountContract`](ecdsa.EcdsaAccountContract.md)
+
+#### Overrides
+
+[DefaultAccountContract](defaults.DefaultAccountContract.md).[constructor](defaults.DefaultAccountContract.md#constructor)
+
+## Properties
+
+### signingPrivateKey
+
+• `Private` **signingPrivateKey**: `Buffer`
+
+## Methods
+
+### getAuthWitnessProvider
+
+▸ **getAuthWitnessProvider**(`_address`): `AuthWitnessProvider`
+
+#### Parameters
+
+| Name | Type |
+| :------ | :------ |
+| `_address` | `CompleteAddress` |
+
+#### Returns
+
+`AuthWitnessProvider`
+
+#### Overrides
+
+[DefaultAccountContract](defaults.DefaultAccountContract.md).[getAuthWitnessProvider](defaults.DefaultAccountContract.md#getauthwitnessprovider)
+
+___
+
+### getContractArtifact
+
+▸ **getContractArtifact**(): `ContractArtifact`
+
+#### Returns
+
+`ContractArtifact`
+
+#### Inherited from
+
+[DefaultAccountContract](defaults.DefaultAccountContract.md).[getContractArtifact](defaults.DefaultAccountContract.md#getcontractartifact)
+
+___
+
+### getDeploymentArgs
+
+▸ **getDeploymentArgs**(): `Buffer`[]
+
+#### Returns
+
+`Buffer`[]
+
+#### Overrides
+
+[DefaultAccountContract](defaults.DefaultAccountContract.md).[getDeploymentArgs](defaults.DefaultAccountContract.md#getdeploymentargs)
+
+___
+
+### getInterface
+
+▸ **getInterface**(`address`, `nodeInfo`): `AccountInterface`
+
+#### Parameters
+
+| Name | Type |
+| :------ | :------ |
+| `address` | `CompleteAddress` |
+| `nodeInfo` | `NodeInfo` |
+
+#### Returns
+
+`AccountInterface`
+
+#### Inherited from
+
+[DefaultAccountContract](defaults.DefaultAccountContract.md).[getInterface](defaults.DefaultAccountContract.md#getinterface)
diff --git a/docs/docs/developers/apis/accounts/classes/schnorr.SchnorrAccountContract.md b/docs/docs/developers/apis/accounts/classes/schnorr.SchnorrAccountContract.md
new file mode 100644
index 00000000000..94b5837367d
--- /dev/null
+++ b/docs/docs/developers/apis/accounts/classes/schnorr.SchnorrAccountContract.md
@@ -0,0 +1,112 @@
+---
+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.
+
+## Hierarchy
+
+- [`DefaultAccountContract`](defaults.DefaultAccountContract.md)
+
+  ↳ **`SchnorrAccountContract`**
+
+## Constructors
+
+### constructor
+
+• **new SchnorrAccountContract**(`signingPrivateKey`): [`SchnorrAccountContract`](schnorr.SchnorrAccountContract.md)
+
+#### Parameters
+
+| Name | Type |
+| :------ | :------ |
+| `signingPrivateKey` | `Fq` |
+
+#### Returns
+
+[`SchnorrAccountContract`](schnorr.SchnorrAccountContract.md)
+
+#### Overrides
+
+[DefaultAccountContract](defaults.DefaultAccountContract.md).[constructor](defaults.DefaultAccountContract.md#constructor)
+
+## Properties
+
+### signingPrivateKey
+
+• `Private` **signingPrivateKey**: `Fq`
+
+## Methods
+
+### getAuthWitnessProvider
+
+▸ **getAuthWitnessProvider**(`_address`): `AuthWitnessProvider`
+
+#### Parameters
+
+| Name | Type |
+| :------ | :------ |
+| `_address` | `CompleteAddress` |
+
+#### Returns
+
+`AuthWitnessProvider`
+
+#### Overrides
+
+[DefaultAccountContract](defaults.DefaultAccountContract.md).[getAuthWitnessProvider](defaults.DefaultAccountContract.md#getauthwitnessprovider)
+
+___
+
+### getContractArtifact
+
+▸ **getContractArtifact**(): `ContractArtifact`
+
+#### Returns
+
+`ContractArtifact`
+
+#### Inherited from
+
+[DefaultAccountContract](defaults.DefaultAccountContract.md).[getContractArtifact](defaults.DefaultAccountContract.md#getcontractartifact)
+
+___
+
+### getDeploymentArgs
+
+▸ **getDeploymentArgs**(): `Fr`[]
+
+#### Returns
+
+`Fr`[]
+
+#### Overrides
+
+[DefaultAccountContract](defaults.DefaultAccountContract.md).[getDeploymentArgs](defaults.DefaultAccountContract.md#getdeploymentargs)
+
+___
+
+### getInterface
+
+▸ **getInterface**(`address`, `nodeInfo`): `AccountInterface`
+
+#### Parameters
+
+| Name | Type |
+| :------ | :------ |
+| `address` | `CompleteAddress` |
+| `nodeInfo` | `NodeInfo` |
+
+#### Returns
+
+`AccountInterface`
+
+#### Inherited from
+
+[DefaultAccountContract](defaults.DefaultAccountContract.md).[getInterface](defaults.DefaultAccountContract.md#getinterface)
diff --git a/docs/docs/developers/apis/accounts/classes/single_key.SingleKeyAccountContract.md b/docs/docs/developers/apis/accounts/classes/single_key.SingleKeyAccountContract.md
new file mode 100644
index 00000000000..992c29757e3
--- /dev/null
+++ b/docs/docs/developers/apis/accounts/classes/single_key.SingleKeyAccountContract.md
@@ -0,0 +1,112 @@
+---
+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.
+
+## Hierarchy
+
+- [`DefaultAccountContract`](defaults.DefaultAccountContract.md)
+
+  ↳ **`SingleKeyAccountContract`**
+
+## Constructors
+
+### constructor
+
+• **new SingleKeyAccountContract**(`encryptionPrivateKey`): [`SingleKeyAccountContract`](single_key.SingleKeyAccountContract.md)
+
+#### Parameters
+
+| Name | Type |
+| :------ | :------ |
+| `encryptionPrivateKey` | `Fq` |
+
+#### Returns
+
+[`SingleKeyAccountContract`](single_key.SingleKeyAccountContract.md)
+
+#### Overrides
+
+[DefaultAccountContract](defaults.DefaultAccountContract.md).[constructor](defaults.DefaultAccountContract.md#constructor)
+
+## Properties
+
+### encryptionPrivateKey
+
+• `Private` **encryptionPrivateKey**: `Fq`
+
+## Methods
+
+### getAuthWitnessProvider
+
+▸ **getAuthWitnessProvider**(`«destructured»`): `AuthWitnessProvider`
+
+#### Parameters
+
+| Name | Type |
+| :------ | :------ |
+| `«destructured»` | `CompleteAddress` |
+
+#### Returns
+
+`AuthWitnessProvider`
+
+#### Overrides
+
+[DefaultAccountContract](defaults.DefaultAccountContract.md).[getAuthWitnessProvider](defaults.DefaultAccountContract.md#getauthwitnessprovider)
+
+___
+
+### getContractArtifact
+
+▸ **getContractArtifact**(): `ContractArtifact`
+
+#### Returns
+
+`ContractArtifact`
+
+#### Inherited from
+
+[DefaultAccountContract](defaults.DefaultAccountContract.md).[getContractArtifact](defaults.DefaultAccountContract.md#getcontractartifact)
+
+___
+
+### getDeploymentArgs
+
+▸ **getDeploymentArgs**(): `any`[]
+
+#### Returns
+
+`any`[]
+
+#### Overrides
+
+[DefaultAccountContract](defaults.DefaultAccountContract.md).[getDeploymentArgs](defaults.DefaultAccountContract.md#getdeploymentargs)
+
+___
+
+### getInterface
+
+▸ **getInterface**(`address`, `nodeInfo`): `AccountInterface`
+
+#### Parameters
+
+| Name | Type |
+| :------ | :------ |
+| `address` | `CompleteAddress` |
+| `nodeInfo` | `NodeInfo` |
+
+#### Returns
+
+`AccountInterface`
+
+#### Inherited from
+
+[DefaultAccountContract](defaults.DefaultAccountContract.md).[getInterface](defaults.DefaultAccountContract.md#getinterface)
diff --git a/docs/docs/developers/apis/accounts/index.md b/docs/docs/developers/apis/accounts/index.md
new file mode 100644
index 00000000000..6f9aaa9d9f8
--- /dev/null
+++ b/docs/docs/developers/apis/accounts/index.md
@@ -0,0 +1,46 @@
+---
+id: "index"
+title: "@aztec/accounts"
+sidebar_label: "Readme"
+sidebar_position: 0
+custom_edit_url: null
+---
+
+# Accounts
+
+Accounts is a client library that provides implementations for some common account flavors. Use it to acquire a `Wallet` object that corresponds to an account, and use that together with `@aztec/aztec.js` to interact with the network.
+
+## Installing
+
+```
+npm install @aztec/accounts
+```
+
+## Account types
+
+- **Schnorr**: Uses an Grumpkin private key with Schnorr signatures for authentication, and a separate Grumpkin private key for encryption. Recommended for most use cases.
+- **ECDSA**: Uses an ECDSA private key for authentication, and a Grumpkin private key for encryption. Recommended for building integrations with Ethereum wallets.
+- **SingleKey**: Uses a single Grumpkin private key for both authentication and encryption. Recommended for testing purposes only.
+
+## Usage
+
+### Deploy a new account
+
+```typescript
+import { getSchnorrAccount } from '@aztec/accounts/schnorr';
+import { GrumpkinPrivateKey } from '@aztec/circuit-types';
+
+const encryptionPrivateKey = GrumpkinPrivateKey.random();
+const signingPrivateKey = GrumpkinPrivateKey.random();
+const wallet = getSchnorrAccount(pxe, encryptionPrivateKey, signingPrivateKey).waitDeploy();
+console.log(`New account deployed at ${wallet.getAddress()}`);
+```
+
+### Create a wallet object from an already deployed account
+
+```typescript
+import { getSchnorrAccount } from '@aztec/accounts/schnorr';
+
+const wallet = getSchnorrWallet(pxe, encryptionPrivateKey);
+console.log(`Wallet for ${wallet.getAddress()} ready`);
+```
diff --git a/docs/docs/developers/apis/accounts/modules.md b/docs/docs/developers/apis/accounts/modules.md
new file mode 100644
index 00000000000..4bdc3605574
--- /dev/null
+++ b/docs/docs/developers/apis/accounts/modules.md
@@ -0,0 +1,16 @@
+---
+id: "modules"
+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/docs/developers/apis/accounts/modules/_category_.yml b/docs/docs/developers/apis/accounts/modules/_category_.yml
new file mode 100644
index 00000000000..63f9c4e4016
--- /dev/null
+++ b/docs/docs/developers/apis/accounts/modules/_category_.yml
@@ -0,0 +1,2 @@
+label: "Modules"
+position: 1
\ No newline at end of file
diff --git a/docs/docs/developers/apis/accounts/modules/defaults.md b/docs/docs/developers/apis/accounts/modules/defaults.md
new file mode 100644
index 00000000000..aca98bc5d4c
--- /dev/null
+++ b/docs/docs/developers/apis/accounts/modules/defaults.md
@@ -0,0 +1,89 @@
+---
+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/wallets/writing_an_account_contract).
+
+## Classes
+
+- [DefaultAccountContract](../classes/defaults.DefaultAccountContract.md)
+- [DefaultAccountEntrypoint](../classes/defaults.DefaultAccountEntrypoint.md)
+- [DefaultAccountInterface](../classes/defaults.DefaultAccountInterface.md)
+
+## Type Aliases
+
+### EntrypointPayload
+
+Ƭ **EntrypointPayload**: `Object`
+
+Encoded payload for the account contract entrypoint
+
+#### Type declaration
+
+| Name | Type | Description |
+| :------ | :------ | :------ |
+| `function_calls` | `EntrypointFunctionCall`[] | Encoded function calls to execute |
+| `nonce` | `Fr` | A nonce for replay protection |
+
+## Variables
+
+### DEFAULT\_CHAIN\_ID
+
+• `Const` **DEFAULT\_CHAIN\_ID**: ``31337``
+
+Default L1 chain ID to use when constructing txs (matches hardhat and anvil's default).
+
+___
+
+### DEFAULT\_VERSION
+
+• `Const` **DEFAULT\_VERSION**: ``1``
+
+Default protocol version to use.
+
+## Functions
+
+### buildPayload
+
+▸ **buildPayload**(`calls`): `Object`
+
+Assembles an entrypoint payload from a set of private and public function calls
+
+#### Parameters
+
+| Name | Type |
+| :------ | :------ |
+| `calls` | `FunctionCall`[] |
+
+#### Returns
+
+`Object`
+
+| Name | Type | Description |
+| :------ | :------ | :------ |
+| `packedArguments` | `PackedArguments`[] | The packed arguments of functions called |
+| `payload` | [`EntrypointPayload`](defaults.md#entrypointpayload) | The payload for the entrypoint function |
+
+___
+
+### hashPayload
+
+▸ **hashPayload**(`payload`): `Buffer`
+
+Hashes an entrypoint payload to a 32-byte buffer (useful for signing)
+
+#### Parameters
+
+| Name | Type |
+| :------ | :------ |
+| `payload` | [`EntrypointPayload`](defaults.md#entrypointpayload) |
+
+#### Returns
+
+`Buffer`
diff --git a/docs/docs/developers/apis/accounts/modules/ecdsa.md b/docs/docs/developers/apis/accounts/modules/ecdsa.md
new file mode 100644
index 00000000000..1ae21355e8e
--- /dev/null
+++ b/docs/docs/developers/apis/accounts/modules/ecdsa.md
@@ -0,0 +1,63 @@
+---
+id: "ecdsa"
+title: "Module: ecdsa"
+sidebar_label: "ecdsa"
+sidebar_position: 0
+custom_edit_url: null
+---
+
+The `@aztec/accounts/ecdsa` export provides an ECDSA account contract implementation, that uses an ECDSA private key for authentication, and a Grumpkin key for encryption.
+Consider using this account type when working with integrations with Ethereum wallets.
+
+## Classes
+
+- [EcdsaAccountContract](../classes/ecdsa.EcdsaAccountContract.md)
+
+## Variables
+
+### EcdsaAccountContractArtifact
+
+• `Const` **EcdsaAccountContractArtifact**: `ContractArtifact`
+
+## Functions
+
+### getEcdsaAccount
+
+▸ **getEcdsaAccount**(`pxe`, `encryptionPrivateKey`, `signingPrivateKey`, `saltOrAddress?`): `AccountManager`
+
+Creates an Account that relies on an ECDSA signing key for authentication.
+
+#### Parameters
+
+| Name | Type | Description |
+| :------ | :------ | :------ |
+| `pxe` | `PXE` | An PXE server instance. |
+| `encryptionPrivateKey` | `Fq` | Grumpkin key used for note encryption. |
+| `signingPrivateKey` | `Buffer` | Secp256k1 key used for signing transactions. |
+| `saltOrAddress?` | `CompleteAddress` \| `Salt` | Deployment salt or complete address if account contract is already deployed. |
+
+#### Returns
+
+`AccountManager`
+
+___
+
+### getEcdsaWallet
+
+▸ **getEcdsaWallet**(`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/docs/developers/apis/accounts/modules/schnorr.md b/docs/docs/developers/apis/accounts/modules/schnorr.md
new file mode 100644
index 00000000000..e9a101daaf1
--- /dev/null
+++ b/docs/docs/developers/apis/accounts/modules/schnorr.md
@@ -0,0 +1,63 @@
+---
+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`, `encryptionPrivateKey`, `signingPrivateKey`, `saltOrAddress?`): `AccountManager`
+
+Creates an Account Manager that relies on a Grumpkin signing key for authentication.
+
+#### Parameters
+
+| Name | Type | Description |
+| :------ | :------ | :------ |
+| `pxe` | `PXE` | An PXE server instance. |
+| `encryptionPrivateKey` | `Fq` | Grumpkin key used for note encryption. |
+| `signingPrivateKey` | `Fq` | Grumpkin key used for signing transactions. |
+| `saltOrAddress?` | `CompleteAddress` \| `Salt` | Deployment salt or complete address if account contract is already deployed. |
+
+#### Returns
+
+`AccountManager`
+
+___
+
+### 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.
diff --git a/docs/docs/developers/apis/accounts/modules/single_key.md b/docs/docs/developers/apis/accounts/modules/single_key.md
new file mode 100644
index 00000000000..64978494f18
--- /dev/null
+++ b/docs/docs/developers/apis/accounts/modules/single_key.md
@@ -0,0 +1,74 @@
+---
+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)
+
+## References
+
+### getUnsafeSchnorrAccount
+
+Renames and re-exports [getSingleKeyAccount](single_key.md#getsinglekeyaccount)
+
+___
+
+### getUnsafeSchnorrWallet
+
+Renames and re-exports [getSingleKeyWallet](single_key.md#getsinglekeywallet)
+
+## Variables
+
+### SingleKeyAccountContractArtifact
+
+• `Const` **SingleKeyAccountContractArtifact**: `ContractArtifact`
+
+## Functions
+
+### getSingleKeyAccount
+
+▸ **getSingleKeyAccount**(`pxe`, `encryptionAndSigningPrivateKey`, `saltOrAddress?`): `AccountManager`
+
+Creates an Account that uses the same Grumpkin key for encryption and authentication.
+
+#### Parameters
+
+| Name | Type | Description |
+| :------ | :------ | :------ |
+| `pxe` | `PXE` | An PXE server instance. |
+| `encryptionAndSigningPrivateKey` | `Fq` | Grumpkin key used for note encryption and signing transactions. |
+| `saltOrAddress?` | `CompleteAddress` \| `Salt` | Deployment salt or complete address if account contract is already deployed. |
+
+#### Returns
+
+`AccountManager`
+
+___
+
+### getSingleKeyWallet
+
+▸ **getSingleKeyWallet**(`pxe`, `address`, `signingKey`): `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. |
+| `signingKey` | `Fq` | - |
+
+#### Returns
+
+`Promise`\<`AccountWallet`\>
+
+A wallet for this account that can be used to interact with a contract instance.
diff --git a/docs/docs/developers/apis/accounts/modules/testing.md b/docs/docs/developers/apis/accounts/modules/testing.md
new file mode 100644
index 00000000000..517df21339c
--- /dev/null
+++ b/docs/docs/developers/apis/accounts/modules/testing.md
@@ -0,0 +1,131 @@
+---
+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 the [createAccount](testing.md#createaccount) and [createAccounts](testing.md#createaccounts) methods to create new sample accounts for testing,
+or use [getInitialTestAccountsWallets](testing.md#getinitialtestaccountswallets) to obtain a list of wallets for the Sandbox pre-seeded accounts.
+
+## Variables
+
+### INITIAL\_TEST\_ACCOUNT\_SALTS
+
+• `Const` **INITIAL\_TEST\_ACCOUNT\_SALTS**: `Fr`[]
+
+___
+
+### INITIAL\_TEST\_ENCRYPTION\_KEYS
+
+• `Const` **INITIAL\_TEST\_ENCRYPTION\_KEYS**: `Fq`[]
+
+___
+
+### INITIAL\_TEST\_SIGNING\_KEYS
+
+• `Const` **INITIAL\_TEST\_SIGNING\_KEYS**: `Fq`[] = `INITIAL_TEST_ENCRYPTION_KEYS`
+
+## Functions
+
+### createAccount
+
+▸ **createAccount**(`pxe`): `Promise`\<`AccountWalletWithPrivateKey`\>
+
+Deploys and registers a new account using random private keys and returns the associated Schnorr account wallet. Useful for testing.
+
+#### Parameters
+
+| Name | Type | Description |
+| :------ | :------ | :------ |
+| `pxe` | `PXE` | PXE. |
+
+#### Returns
+
+`Promise`\<`AccountWalletWithPrivateKey`\>
+
+- A wallet for a fresh account.
+
+___
+
+### createAccounts
+
+▸ **createAccounts**(`pxe`, `numberOfAccounts?`): `Promise`\<`AccountWalletWithPrivateKey`[]\>
+
+Creates a given number of random accounts using the Schnorr account wallet.
+
+#### Parameters
+
+| Name | Type | Default value | Description |
+| :------ | :------ | :------ | :------ |
+| `pxe` | `PXE` | `undefined` | PXE. |
+| `numberOfAccounts` | `number` | `1` | How many accounts to create. |
+
+#### Returns
+
+`Promise`\<`AccountWalletWithPrivateKey`[]\>
+
+The created account wallets.
+
+___
+
+### deployInitialTestAccounts
+
+▸ **deployInitialTestAccounts**(`pxe`): `Promise`\<\{ `account`: `AccountManager` ; `privateKey`: `Fq`  }[]\>
+
+Deploys the initial set of schnorr signature accounts to the test environment
+
+#### Parameters
+
+| Name | Type | Description |
+| :------ | :------ | :------ |
+| `pxe` | `PXE` | PXE instance. |
+
+#### Returns
+
+`Promise`\<\{ `account`: `AccountManager` ; `privateKey`: `Fq`  }[]\>
+
+The set of deployed Account objects and associated private encryption keys
+
+___
+
+### getDeployedTestAccountsWallets
+
+▸ **getDeployedTestAccountsWallets**(`pxe`): `Promise`\<`AccountWalletWithPrivateKey`[]\>
+
+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`\<`AccountWalletWithPrivateKey`[]\>
+
+A set of AccountWallet implementations for each of the initial accounts.
+
+___
+
+### getInitialTestAccountsWallets
+
+▸ **getInitialTestAccountsWallets**(`pxe`): `Promise`\<`AccountWalletWithPrivateKey`[]\>
+
+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`\<`AccountWalletWithPrivateKey`[]\>
+
+A set of AccountWallet implementations for each of the initial accounts.
diff --git a/docs/docs/developers/apis/aztec-js/_category_.yml b/docs/docs/developers/apis/aztec-js/_category_.yml
new file mode 100644
index 00000000000..24a46026174
--- /dev/null
+++ b/docs/docs/developers/apis/aztec-js/_category_.yml
@@ -0,0 +1 @@
+label: "API"
\ No newline at end of file
diff --git a/docs/docs/developers/apis/aztec-js/classes/_category_.yml b/docs/docs/developers/apis/aztec-js/classes/_category_.yml
new file mode 100644
index 00000000000..55c7980a464
--- /dev/null
+++ b/docs/docs/developers/apis/aztec-js/classes/_category_.yml
@@ -0,0 +1,2 @@
+label: "Classes"
+position: 3
\ No newline at end of file
diff --git a/docs/docs/developers/apis/aztec-js/classes/contract.BatchCall.md b/docs/docs/developers/apis/aztec-js/classes/contract.BatchCall.md
new file mode 100644
index 00000000000..be9fb269a3c
--- /dev/null
+++ b/docs/docs/developers/apis/aztec-js/classes/contract.BatchCall.md
@@ -0,0 +1,149 @@
+---
+id: "contract.BatchCall"
+title: "Class: BatchCall"
+sidebar_label: "BatchCall"
+custom_edit_url: null
+---
+
+[contract](../modules/contract.md).BatchCall
+
+A batch of function calls to be sent as a single transaction through a wallet.
+
+## Hierarchy
+
+- `BaseContractInteraction`
+
+  ↳ **`BatchCall`**
+
+## Constructors
+
+### constructor
+
+• **new BatchCall**(`wallet`, `calls`): [`BatchCall`](contract.BatchCall.md)
+
+#### Parameters
+
+| Name | Type |
+| :------ | :------ |
+| `wallet` | [`Wallet`](../modules/account.md#wallet) |
+| `calls` | `FunctionCall`[] |
+
+#### Returns
+
+[`BatchCall`](contract.BatchCall.md)
+
+#### Overrides
+
+BaseContractInteraction.constructor
+
+## Properties
+
+### calls
+
+• `Protected` **calls**: `FunctionCall`[]
+
+___
+
+### pxe
+
+• `Protected` **pxe**: `PXE`
+
+#### Inherited from
+
+BaseContractInteraction.pxe
+
+___
+
+### tx
+
+• `Protected` `Optional` **tx**: `Tx`
+
+#### Inherited from
+
+BaseContractInteraction.tx
+
+___
+
+### txRequest
+
+• `Protected` `Optional` **txRequest**: `TxExecutionRequest`
+
+#### Inherited from
+
+BaseContractInteraction.txRequest
+
+___
+
+### wallet
+
+• `Protected` **wallet**: [`Wallet`](../modules/account.md#wallet)
+
+## Methods
+
+### create
+
+▸ **create**(): `Promise`\<`TxExecutionRequest`\>
+
+Create a transaction execution request that represents this batch, encoded and authenticated by the
+user's wallet, ready to be simulated.
+
+#### Returns
+
+`Promise`\<`TxExecutionRequest`\>
+
+A Promise that resolves to a transaction instance.
+
+#### Overrides
+
+BaseContractInteraction.create
+
+___
+
+### send
+
+▸ **send**(`options?`): [`SentTx`](contract.SentTx.md)
+
+Sends a transaction to the contract function with the specified options.
+This function throws an error if called on an unconstrained function.
+It creates and signs the transaction if necessary, and returns a SentTx instance,
+which can be used to track the transaction status, receipt, and events.
+
+#### Parameters
+
+| Name | Type | Description |
+| :------ | :------ | :------ |
+| `options` | [`SendMethodOptions`](../modules/contract.md#sendmethodoptions) | An optional object containing 'from' property representing the AztecAddress of the sender. If not provided, the default address is used. |
+
+#### Returns
+
+[`SentTx`](contract.SentTx.md)
+
+A SentTx instance for tracking the transaction status and information.
+
+#### Inherited from
+
+BaseContractInteraction.send
+
+___
+
+### simulate
+
+▸ **simulate**(`options?`): `Promise`\<`Tx`\>
+
+Simulates a transaction execution request and returns a tx object ready to be sent.
+
+#### Parameters
+
+| Name | Type | Description |
+| :------ | :------ | :------ |
+| `options` | [`SendMethodOptions`](../modules/contract.md#sendmethodoptions) | optional arguments to be used in the creation of the transaction |
+
+#### Returns
+
+`Promise`\<`Tx`\>
+
+The resulting transaction
+
+#### Inherited from
+
+BaseContractInteraction.simulate
diff --git a/docs/docs/developers/apis/aztec-js/classes/contract.Contract.md b/docs/docs/developers/apis/aztec-js/classes/contract.Contract.md
new file mode 100644
index 00000000000..b958283dd17
--- /dev/null
+++ b/docs/docs/developers/apis/aztec-js/classes/contract.Contract.md
@@ -0,0 +1,210 @@
+---
+id: "contract.Contract"
+title: "Class: Contract"
+sidebar_label: "Contract"
+custom_edit_url: null
+---
+
+[contract](../modules/contract.md).Contract
+
+The Contract class represents a contract and provides utility methods for interacting with it.
+It enables the creation of ContractFunctionInteraction instances for each function in the contract's ABI,
+allowing users to call or send transactions to these functions. Additionally, the Contract class can be used
+to attach the contract instance to a deployed contract on-chain through the PXE, which facilitates
+interaction with Aztec's privacy protocol.
+
+## Hierarchy
+
+- [`ContractBase`](contract.ContractBase.md)
+
+  ↳ **`Contract`**
+
+## Constructors
+
+### constructor
+
+• **new Contract**(`completeAddress`, `artifact`, `wallet`, `portalContract`): [`Contract`](contract.Contract.md)
+
+#### Parameters
+
+| Name | Type | Description |
+| :------ | :------ | :------ |
+| `completeAddress` | `CompleteAddress` | The deployed contract's complete address. |
+| `artifact` | `ContractArtifact` | The Application Binary Interface for the contract. |
+| `wallet` | [`Wallet`](../modules/account.md#wallet) | The wallet used for interacting with this contract. |
+| `portalContract` | `EthAddress` | The portal contract address on L1, if any. |
+
+#### Returns
+
+[`Contract`](contract.Contract.md)
+
+#### Inherited from
+
+[ContractBase](contract.ContractBase.md).[constructor](contract.ContractBase.md#constructor)
+
+## Properties
+
+### artifact
+
+• `Readonly` **artifact**: `ContractArtifact`
+
+The Application Binary Interface for the contract.
+
+#### Inherited from
+
+[ContractBase](contract.ContractBase.md).[artifact](contract.ContractBase.md#artifact)
+
+___
+
+### completeAddress
+
+• `Readonly` **completeAddress**: `CompleteAddress`
+
+The deployed contract's complete address.
+
+#### Inherited from
+
+[ContractBase](contract.ContractBase.md).[completeAddress](contract.ContractBase.md#completeaddress)
+
+___
+
+### methods
+
+• **methods**: `Object` = `{}`
+
+An object containing contract methods mapped to their respective names.
+
+#### Index signature
+
+▪ [name: `string`]: [`ContractMethod`](../modules/contract.md#contractmethod)
+
+#### Inherited from
+
+[ContractBase](contract.ContractBase.md).[methods](contract.ContractBase.md#methods)
+
+___
+
+### portalContract
+
+• `Readonly` **portalContract**: `EthAddress`
+
+The portal contract address on L1, if any.
+
+#### Inherited from
+
+[ContractBase](contract.ContractBase.md).[portalContract](contract.ContractBase.md#portalcontract)
+
+___
+
+### wallet
+
+• `Protected` **wallet**: [`Wallet`](../modules/account.md#wallet)
+
+The wallet used for interacting with this contract.
+
+#### Inherited from
+
+[ContractBase](contract.ContractBase.md).[wallet](contract.ContractBase.md#wallet)
+
+## Accessors
+
+### address
+
+• `get` **address**(): `AztecAddress`
+
+Address of the contract.
+
+#### Returns
+
+`AztecAddress`
+
+#### Inherited from
+
+ContractBase.address
+
+## Methods
+
+### withWallet
+
+▸ **withWallet**(`wallet`): `this`
+
+Creates a new instance of the contract wrapper attached to a different wallet.
+
+#### Parameters
+
+| Name | Type | Description |
+| :------ | :------ | :------ |
+| `wallet` | [`Wallet`](../modules/account.md#wallet) | Wallet to use for sending txs. |
+
+#### Returns
+
+`this`
+
+A new contract instance.
+
+#### Inherited from
+
+[ContractBase](contract.ContractBase.md).[withWallet](contract.ContractBase.md#withwallet)
+
+___
+
+### at
+
+▸ **at**(`address`, `artifact`, `wallet`): `Promise`\<[`Contract`](contract.Contract.md)\>
+
+Creates a contract instance.
+
+#### Parameters
+
+| Name | Type | Description |
+| :------ | :------ | :------ |
+| `address` | `AztecAddress` | The deployed contract's address. |
+| `artifact` | `ContractArtifact` | Build artifact of the contract. |
+| `wallet` | [`Wallet`](../modules/account.md#wallet) | The wallet to use when interacting with the contract. |
+
+#### Returns
+
+`Promise`\<[`Contract`](contract.Contract.md)\>
+
+A promise that resolves to a new Contract instance.
+
+___
+
+### deploy
+
+▸ **deploy**(`wallet`, `artifact`, `args`): [`DeployMethod`](contract.DeployMethod.md)\<[`Contract`](contract.Contract.md)\>
+
+Creates a tx to deploy a new instance of a contract.
+
+#### Parameters
+
+| Name | Type | Description |
+| :------ | :------ | :------ |
+| `wallet` | [`Wallet`](../modules/account.md#wallet) | The wallet for executing the deployment. |
+| `artifact` | `ContractArtifact` | Build artifact of the contract to deploy |
+| `args` | `any`[] | Arguments for the constructor. |
+
+#### Returns
+
+[`DeployMethod`](contract.DeployMethod.md)\<[`Contract`](contract.Contract.md)\>
+
+___
+
+### deployWithPublicKey
+
+▸ **deployWithPublicKey**(`publicKey`, `wallet`, `artifact`, `args`): [`DeployMethod`](contract.DeployMethod.md)\<[`Contract`](contract.Contract.md)\>
+
+Creates a tx to deploy a new instance of a contract using the specified public key to derive the address.
+
+#### Parameters
+
+| Name | Type | Description |
+| :------ | :------ | :------ |
+| `publicKey` | `Point` | Public key for deriving the address. |
+| `wallet` | [`Wallet`](../modules/account.md#wallet) | The wallet for executing the deployment. |
+| `artifact` | `ContractArtifact` | Build artifact of the contract. |
+| `args` | `any`[] | Arguments for the constructor. |
+
+#### Returns
+
+[`DeployMethod`](contract.DeployMethod.md)\<[`Contract`](contract.Contract.md)\>
diff --git a/docs/docs/developers/apis/aztec-js/classes/contract.ContractBase.md b/docs/docs/developers/apis/aztec-js/classes/contract.ContractBase.md
new file mode 100644
index 00000000000..23fcaf83923
--- /dev/null
+++ b/docs/docs/developers/apis/aztec-js/classes/contract.ContractBase.md
@@ -0,0 +1,127 @@
+---
+id: "contract.ContractBase"
+title: "Class: ContractBase"
+sidebar_label: "ContractBase"
+custom_edit_url: null
+---
+
+[contract](../modules/contract.md).ContractBase
+
+Abstract implementation of a contract extended by the Contract class and generated contract types.
+
+## Hierarchy
+
+- **`ContractBase`**
+
+  ↳ [`Contract`](contract.Contract.md)
+
+## Implements
+
+- `DeployedContract`
+
+## Constructors
+
+### constructor
+
+• **new ContractBase**(`completeAddress`, `artifact`, `wallet`, `portalContract`): [`ContractBase`](contract.ContractBase.md)
+
+#### Parameters
+
+| Name | Type | Description |
+| :------ | :------ | :------ |
+| `completeAddress` | `CompleteAddress` | The deployed contract's complete address. |
+| `artifact` | `ContractArtifact` | The Application Binary Interface for the contract. |
+| `wallet` | [`Wallet`](../modules/account.md#wallet) | The wallet used for interacting with this contract. |
+| `portalContract` | `EthAddress` | The portal contract address on L1, if any. |
+
+#### Returns
+
+[`ContractBase`](contract.ContractBase.md)
+
+## Properties
+
+### artifact
+
+• `Readonly` **artifact**: `ContractArtifact`
+
+The Application Binary Interface for the contract.
+
+#### Implementation of
+
+DeployedContract.artifact
+
+___
+
+### completeAddress
+
+• `Readonly` **completeAddress**: `CompleteAddress`
+
+The deployed contract's complete address.
+
+#### Implementation of
+
+DeployedContract.completeAddress
+
+___
+
+### methods
+
+• **methods**: `Object` = `{}`
+
+An object containing contract methods mapped to their respective names.
+
+#### Index signature
+
+▪ [name: `string`]: [`ContractMethod`](../modules/contract.md#contractmethod)
+
+___
+
+### portalContract
+
+• `Readonly` **portalContract**: `EthAddress`
+
+The portal contract address on L1, if any.
+
+#### Implementation of
+
+DeployedContract.portalContract
+
+___
+
+### wallet
+
+• `Protected` **wallet**: [`Wallet`](../modules/account.md#wallet)
+
+The wallet used for interacting with this contract.
+
+## Accessors
+
+### address
+
+• `get` **address**(): `AztecAddress`
+
+Address of the contract.
+
+#### Returns
+
+`AztecAddress`
+
+## Methods
+
+### withWallet
+
+▸ **withWallet**(`wallet`): `this`
+
+Creates a new instance of the contract wrapper attached to a different wallet.
+
+#### Parameters
+
+| Name | Type | Description |
+| :------ | :------ | :------ |
+| `wallet` | [`Wallet`](../modules/account.md#wallet) | Wallet to use for sending txs. |
+
+#### Returns
+
+`this`
+
+A new contract instance.
diff --git a/docs/docs/developers/apis/aztec-js/classes/contract.ContractFunctionInteraction.md b/docs/docs/developers/apis/aztec-js/classes/contract.ContractFunctionInteraction.md
new file mode 100644
index 00000000000..298ee397492
--- /dev/null
+++ b/docs/docs/developers/apis/aztec-js/classes/contract.ContractFunctionInteraction.md
@@ -0,0 +1,201 @@
+---
+id: "contract.ContractFunctionInteraction"
+title: "Class: ContractFunctionInteraction"
+sidebar_label: "ContractFunctionInteraction"
+custom_edit_url: null
+---
+
+[contract](../modules/contract.md).ContractFunctionInteraction
+
+This is the class that is returned when calling e.g. `contract.methods.myMethod(arg0, arg1)`.
+It contains available interactions one can call on a method, including view.
+
+## Hierarchy
+
+- `BaseContractInteraction`
+
+  ↳ **`ContractFunctionInteraction`**
+
+## Constructors
+
+### constructor
+
+• **new ContractFunctionInteraction**(`wallet`, `contractAddress`, `functionDao`, `args`): [`ContractFunctionInteraction`](contract.ContractFunctionInteraction.md)
+
+#### Parameters
+
+| Name | Type |
+| :------ | :------ |
+| `wallet` | [`Wallet`](../modules/account.md#wallet) |
+| `contractAddress` | `AztecAddress` |
+| `functionDao` | `FunctionAbi` |
+| `args` | `any`[] |
+
+#### Returns
+
+[`ContractFunctionInteraction`](contract.ContractFunctionInteraction.md)
+
+#### Overrides
+
+BaseContractInteraction.constructor
+
+## Properties
+
+### args
+
+• `Protected` **args**: `any`[]
+
+___
+
+### contractAddress
+
+• `Protected` **contractAddress**: `AztecAddress`
+
+___
+
+### functionDao
+
+• `Protected` **functionDao**: `FunctionAbi`
+
+___
+
+### pxe
+
+• `Protected` **pxe**: `PXE`
+
+#### Inherited from
+
+BaseContractInteraction.pxe
+
+___
+
+### tx
+
+• `Protected` `Optional` **tx**: `Tx`
+
+#### Inherited from
+
+BaseContractInteraction.tx
+
+___
+
+### txRequest
+
+• `Protected` `Optional` **txRequest**: `TxExecutionRequest`
+
+#### Inherited from
+
+BaseContractInteraction.txRequest
+
+___
+
+### wallet
+
+• `Protected` **wallet**: [`Wallet`](../modules/account.md#wallet)
+
+## Methods
+
+### create
+
+▸ **create**(): `Promise`\<`TxExecutionRequest`\>
+
+Create a transaction execution request that represents this call, encoded and authenticated by the
+user's wallet, ready to be simulated.
+
+#### Returns
+
+`Promise`\<`TxExecutionRequest`\>
+
+A Promise that resolves to a transaction instance.
+
+#### Overrides
+
+BaseContractInteraction.create
+
+___
+
+### request
+
+▸ **request**(): `FunctionCall`
+
+Returns an execution request that represents this operation. Useful as a building
+block for constructing batch requests.
+
+#### Returns
+
+`FunctionCall`
+
+An execution request wrapped in promise.
+
+___
+
+### send
+
+▸ **send**(`options?`): [`SentTx`](contract.SentTx.md)
+
+Sends a transaction to the contract function with the specified options.
+This function throws an error if called on an unconstrained function.
+It creates and signs the transaction if necessary, and returns a SentTx instance,
+which can be used to track the transaction status, receipt, and events.
+
+#### Parameters
+
+| Name | Type | Description |
+| :------ | :------ | :------ |
+| `options` | [`SendMethodOptions`](../modules/contract.md#sendmethodoptions) | An optional object containing 'from' property representing the AztecAddress of the sender. If not provided, the default address is used. |
+
+#### Returns
+
+[`SentTx`](contract.SentTx.md)
+
+A SentTx instance for tracking the transaction status and information.
+
+#### Inherited from
+
+BaseContractInteraction.send
+
+___
+
+### simulate
+
+▸ **simulate**(`options?`): `Promise`\<`Tx`\>
+
+Simulates a transaction execution request and returns a tx object ready to be sent.
+
+#### Parameters
+
+| Name | Type | Description |
+| :------ | :------ | :------ |
+| `options` | [`SendMethodOptions`](../modules/contract.md#sendmethodoptions) | optional arguments to be used in the creation of the transaction |
+
+#### Returns
+
+`Promise`\<`Tx`\>
+
+The resulting transaction
+
+#### Inherited from
+
+BaseContractInteraction.simulate
+
+___
+
+### view
+
+▸ **view**(`options?`): `Promise`\<`any`\>
+
+Execute a view (read-only) transaction on an unconstrained function.
+This method is used to call functions that do not modify the contract state and only return data.
+Throws an error if called on a non-unconstrained function.
+
+#### Parameters
+
+| Name | Type | Description |
+| :------ | :------ | :------ |
+| `options` | [`ViewMethodOptions`](../modules/contract.md#viewmethodoptions) | An optional object containing additional configuration for the transaction. |
+
+#### Returns
+
+`Promise`\<`any`\>
+
+The result of the view transaction as returned by the contract function.
diff --git a/docs/docs/developers/apis/aztec-js/classes/contract.DeployMethod.md b/docs/docs/developers/apis/aztec-js/classes/contract.DeployMethod.md
new file mode 100644
index 00000000000..62e599ab5fd
--- /dev/null
+++ b/docs/docs/developers/apis/aztec-js/classes/contract.DeployMethod.md
@@ -0,0 +1,215 @@
+---
+id: "contract.DeployMethod"
+title: "Class: DeployMethod<TContract>"
+sidebar_label: "DeployMethod"
+custom_edit_url: null
+---
+
+[contract](../modules/contract.md).DeployMethod
+
+Creates a TxRequest from a contract ABI, for contract deployment.
+Extends the ContractFunctionInteraction class.
+
+## Type parameters
+
+| Name | Type |
+| :------ | :------ |
+| `TContract` | extends [`ContractBase`](contract.ContractBase.md) = [`Contract`](contract.Contract.md) |
+
+## Hierarchy
+
+- `BaseContractInteraction`
+
+  ↳ **`DeployMethod`**
+
+## Constructors
+
+### constructor
+
+• **new DeployMethod**\<`TContract`\>(`publicKey`, `pxe`, `artifact`, `postDeployCtor`, `args?`): [`DeployMethod`](contract.DeployMethod.md)\<`TContract`\>
+
+#### Type parameters
+
+| Name | Type |
+| :------ | :------ |
+| `TContract` | extends [`ContractBase`](contract.ContractBase.md) = [`Contract`](contract.Contract.md) |
+
+#### Parameters
+
+| Name | Type | Default value |
+| :------ | :------ | :------ |
+| `publicKey` | `Point` | `undefined` |
+| `pxe` | `PXE` | `undefined` |
+| `artifact` | `ContractArtifact` | `undefined` |
+| `postDeployCtor` | (`address`: `AztecAddress`, `wallet`: [`Wallet`](../modules/account.md#wallet)) => `Promise`\<`TContract`\> | `undefined` |
+| `args` | `any`[] | `[]` |
+
+#### Returns
+
+[`DeployMethod`](contract.DeployMethod.md)\<`TContract`\>
+
+#### Overrides
+
+BaseContractInteraction.constructor
+
+## Properties
+
+### args
+
+• `Private` **args**: `any`[] = `[]`
+
+___
+
+### artifact
+
+• `Private` **artifact**: `ContractArtifact`
+
+___
+
+### completeAddress
+
+• `Optional` **completeAddress**: `CompleteAddress` = `undefined`
+
+The complete address of the contract.
+
+___
+
+### constructorArtifact
+
+• `Private` **constructorArtifact**: `FunctionArtifact`
+
+Constructor function to call.
+
+___
+
+### postDeployCtor
+
+• `Private` **postDeployCtor**: (`address`: `AztecAddress`, `wallet`: [`Wallet`](../modules/account.md#wallet)) => `Promise`\<`TContract`\>
+
+#### Type declaration
+
+▸ (`address`, `wallet`): `Promise`\<`TContract`\>
+
+##### Parameters
+
+| Name | Type |
+| :------ | :------ |
+| `address` | `AztecAddress` |
+| `wallet` | [`Wallet`](../modules/account.md#wallet) |
+
+##### Returns
+
+`Promise`\<`TContract`\>
+
+___
+
+### publicKey
+
+• `Private` **publicKey**: `Point`
+
+___
+
+### pxe
+
+• `Protected` **pxe**: `PXE`
+
+#### Inherited from
+
+BaseContractInteraction.pxe
+
+___
+
+### tx
+
+• `Protected` `Optional` **tx**: `Tx`
+
+#### Inherited from
+
+BaseContractInteraction.tx
+
+___
+
+### txRequest
+
+• `Protected` `Optional` **txRequest**: `TxExecutionRequest`
+
+#### Inherited from
+
+BaseContractInteraction.txRequest
+
+## Methods
+
+### create
+
+▸ **create**(`options?`): `Promise`\<`TxExecutionRequest`\>
+
+Create a contract deployment transaction, given the deployment options.
+This function internally calls `request()` and `sign()` methods to prepare
+the transaction for deployment. The resulting signed transaction can be
+later sent using the `send()` method.
+
+#### Parameters
+
+| Name | Type | Description |
+| :------ | :------ | :------ |
+| `options` | [`DeployOptions`](../modules/contract.md#deployoptions) | An object containing optional deployment settings, including portalContract, contractAddressSalt, and from. |
+
+#### Returns
+
+`Promise`\<`TxExecutionRequest`\>
+
+A Promise resolving to an object containing the signed transaction data and other relevant information.
+
+#### Overrides
+
+BaseContractInteraction.create
+
+___
+
+### send
+
+▸ **send**(`options?`): [`DeploySentTx`](contract.DeploySentTx.md)\<`TContract`\>
+
+Send the contract deployment transaction using the provided options.
+This function extends the 'send' method from the ContractFunctionInteraction class,
+allowing us to send a transaction specifically for contract deployment.
+
+#### Parameters
+
+| Name | Type | Description |
+| :------ | :------ | :------ |
+| `options` | [`DeployOptions`](../modules/contract.md#deployoptions) | An object containing various deployment options such as portalContract, contractAddressSalt, and from. |
+
+#### Returns
+
+[`DeploySentTx`](contract.DeploySentTx.md)\<`TContract`\>
+
+A SentTx object that returns the receipt and the deployed contract instance.
+
+#### Overrides
+
+BaseContractInteraction.send
+
+___
+
+### simulate
+
+▸ **simulate**(`options`): `Promise`\<`Tx`\>
+
+Simulate the request.
+
+#### Parameters
+
+| Name | Type | Description |
+| :------ | :------ | :------ |
+| `options` | [`DeployOptions`](../modules/contract.md#deployoptions) | Deployment options. |
+
+#### Returns
+
+`Promise`\<`Tx`\>
+
+The simulated tx.
+
+#### Overrides
+
+BaseContractInteraction.simulate
diff --git a/docs/docs/developers/apis/aztec-js/classes/contract.DeploySentTx.md b/docs/docs/developers/apis/aztec-js/classes/contract.DeploySentTx.md
new file mode 100644
index 00000000000..daac2a1461b
--- /dev/null
+++ b/docs/docs/developers/apis/aztec-js/classes/contract.DeploySentTx.md
@@ -0,0 +1,264 @@
+---
+id: "contract.DeploySentTx"
+title: "Class: DeploySentTx<TContract>"
+sidebar_label: "DeploySentTx"
+custom_edit_url: null
+---
+
+[contract](../modules/contract.md).DeploySentTx
+
+A contract deployment transaction sent to the network, extending SentTx with methods to create a contract instance.
+
+## Type parameters
+
+| Name | Type |
+| :------ | :------ |
+| `TContract` | extends [`Contract`](contract.Contract.md) = [`Contract`](contract.Contract.md) |
+
+## Hierarchy
+
+- [`SentTx`](contract.SentTx.md)
+
+  ↳ **`DeploySentTx`**
+
+## Constructors
+
+### constructor
+
+• **new DeploySentTx**\<`TContract`\>(`wallet`, `txHashPromise`, `postDeployCtor`, `completeContractAddress?`): [`DeploySentTx`](contract.DeploySentTx.md)\<`TContract`\>
+
+#### Type parameters
+
+| Name | Type |
+| :------ | :------ |
+| `TContract` | extends [`Contract`](contract.Contract.md) = [`Contract`](contract.Contract.md) |
+
+#### Parameters
+
+| Name | Type | Description |
+| :------ | :------ | :------ |
+| `wallet` | `PXE` \| [`Wallet`](../modules/account.md#wallet) | - |
+| `txHashPromise` | `Promise`\<`TxHash`\> | - |
+| `postDeployCtor` | (`address`: `AztecAddress`, `wallet`: [`Wallet`](../modules/account.md#wallet)) => `Promise`\<`TContract`\> | - |
+| `completeContractAddress?` | `CompleteAddress` | The complete address of the deployed contract |
+
+#### Returns
+
+[`DeploySentTx`](contract.DeploySentTx.md)\<`TContract`\>
+
+#### Overrides
+
+[SentTx](contract.SentTx.md).[constructor](contract.SentTx.md#constructor)
+
+## Properties
+
+### completeContractAddress
+
+• `Optional` **completeContractAddress**: `CompleteAddress`
+
+The complete address of the deployed contract
+
+___
+
+### postDeployCtor
+
+• `Private` **postDeployCtor**: (`address`: `AztecAddress`, `wallet`: [`Wallet`](../modules/account.md#wallet)) => `Promise`\<`TContract`\>
+
+#### Type declaration
+
+▸ (`address`, `wallet`): `Promise`\<`TContract`\>
+
+##### Parameters
+
+| Name | Type |
+| :------ | :------ |
+| `address` | `AztecAddress` |
+| `wallet` | [`Wallet`](../modules/account.md#wallet) |
+
+##### Returns
+
+`Promise`\<`TContract`\>
+
+___
+
+### pxe
+
+• `Protected` **pxe**: `PXE`
+
+#### Inherited from
+
+[SentTx](contract.SentTx.md).[pxe](contract.SentTx.md#pxe)
+
+___
+
+### txHashPromise
+
+• `Protected` **txHashPromise**: `Promise`\<`TxHash`\>
+
+#### Inherited from
+
+[SentTx](contract.SentTx.md).[txHashPromise](contract.SentTx.md#txhashpromise)
+
+## Methods
+
+### deployed
+
+▸ **deployed**(`opts?`): `Promise`\<`TContract`\>
+
+Awaits for the tx to be mined and returns the contract instance. Throws if tx is not mined.
+
+#### Parameters
+
+| Name | Type | Description |
+| :------ | :------ | :------ |
+| `opts?` | [`DeployedWaitOpts`](../modules/contract.md#deployedwaitopts) | Options for configuring the waiting for the tx to be mined. |
+
+#### Returns
+
+`Promise`\<`TContract`\>
+
+The deployed contract instance.
+
+___
+
+### getContractInstance
+
+▸ **getContractInstance**(`wallet?`, `address?`): `Promise`\<`TContract`\>
+
+#### Parameters
+
+| Name | Type |
+| :------ | :------ |
+| `wallet?` | [`Wallet`](../modules/account.md#wallet) |
+| `address?` | `AztecAddress` |
+
+#### Returns
+
+`Promise`\<`TContract`\>
+
+___
+
+### getReceipt
+
+▸ **getReceipt**(): `Promise`\<`TxReceipt`\>
+
+Retrieve the transaction receipt associated with the current SentTx instance.
+The function fetches the transaction hash using 'getTxHash' and then queries
+the PXE to get the corresponding transaction receipt.
+
+#### Returns
+
+`Promise`\<`TxReceipt`\>
+
+A promise that resolves to a TxReceipt object representing the fetched transaction receipt.
+
+#### Inherited from
+
+[SentTx](contract.SentTx.md).[getReceipt](contract.SentTx.md#getreceipt)
+
+___
+
+### getTxHash
+
+▸ **getTxHash**(): `Promise`\<`TxHash`\>
+
+Retrieves the transaction hash of the SentTx instance.
+The function internally awaits for the 'txHashPromise' to resolve, and then returns the resolved transaction hash.
+
+#### Returns
+
+`Promise`\<`TxHash`\>
+
+A promise that resolves to the transaction hash of the SentTx instance.
+
+#### Inherited from
+
+[SentTx](contract.SentTx.md).[getTxHash](contract.SentTx.md#gettxhash)
+
+___
+
+### getUnencryptedLogs
+
+▸ **getUnencryptedLogs**(): `Promise`\<`GetUnencryptedLogsResponse`\>
+
+Gets unencrypted logs emitted by this tx.
+
+#### Returns
+
+`Promise`\<`GetUnencryptedLogsResponse`\>
+
+The requested logs.
+
+**`Remarks`**
+
+This function will wait for the tx to be mined if it hasn't been already.
+
+#### Inherited from
+
+[SentTx](contract.SentTx.md).[getUnencryptedLogs](contract.SentTx.md#getunencryptedlogs)
+
+___
+
+### getVisibleNotes
+
+▸ **getVisibleNotes**(): `Promise`\<`ExtendedNote`[]\>
+
+Get notes of accounts registered in the provided PXE/Wallet created in this tx.
+
+#### Returns
+
+`Promise`\<`ExtendedNote`[]\>
+
+The requested notes.
+
+**`Remarks`**
+
+This function will wait for the tx to be mined if it hasn't been already.
+
+#### Inherited from
+
+[SentTx](contract.SentTx.md).[getVisibleNotes](contract.SentTx.md#getvisiblenotes)
+
+___
+
+### wait
+
+▸ **wait**(`opts?`): `Promise`\<[`DeployTxReceipt`](../modules/contract.md#deploytxreceipt)\<`TContract`\>\>
+
+Awaits for the tx to be mined and returns the receipt along with a contract instance. Throws if tx is not mined.
+
+#### Parameters
+
+| Name | Type | Description |
+| :------ | :------ | :------ |
+| `opts?` | [`DeployedWaitOpts`](../modules/contract.md#deployedwaitopts) | Options for configuring the waiting for the tx to be mined. |
+
+#### Returns
+
+`Promise`\<[`DeployTxReceipt`](../modules/contract.md#deploytxreceipt)\<`TContract`\>\>
+
+The transaction receipt with the deployed contract instance.
+
+#### Overrides
+
+[SentTx](contract.SentTx.md).[wait](contract.SentTx.md#wait)
+
+___
+
+### waitForReceipt
+
+▸ **waitForReceipt**(`opts?`): `Promise`\<`TxReceipt`\>
+
+#### Parameters
+
+| Name | Type |
+| :------ | :------ |
+| `opts?` | [`WaitOpts`](../modules/contract.md#waitopts) |
+
+#### Returns
+
+`Promise`\<`TxReceipt`\>
+
+#### Inherited from
+
+[SentTx](contract.SentTx.md).[waitForReceipt](contract.SentTx.md#waitforreceipt)
diff --git a/docs/docs/developers/apis/aztec-js/classes/contract.SentTx.md b/docs/docs/developers/apis/aztec-js/classes/contract.SentTx.md
new file mode 100644
index 00000000000..accede6ccfb
--- /dev/null
+++ b/docs/docs/developers/apis/aztec-js/classes/contract.SentTx.md
@@ -0,0 +1,149 @@
+---
+id: "contract.SentTx"
+title: "Class: SentTx"
+sidebar_label: "SentTx"
+custom_edit_url: null
+---
+
+[contract](../modules/contract.md).SentTx
+
+The SentTx class represents a sent transaction through the PXE, providing methods to fetch
+its hash, receipt, and mining status.
+
+## Hierarchy
+
+- **`SentTx`**
+
+  ↳ [`DeploySentTx`](contract.DeploySentTx.md)
+
+## Constructors
+
+### constructor
+
+• **new SentTx**(`pxe`, `txHashPromise`): [`SentTx`](contract.SentTx.md)
+
+#### Parameters
+
+| Name | Type |
+| :------ | :------ |
+| `pxe` | `PXE` |
+| `txHashPromise` | `Promise`\<`TxHash`\> |
+
+#### Returns
+
+[`SentTx`](contract.SentTx.md)
+
+## Properties
+
+### pxe
+
+• `Protected` **pxe**: `PXE`
+
+___
+
+### txHashPromise
+
+• `Protected` **txHashPromise**: `Promise`\<`TxHash`\>
+
+## Methods
+
+### getReceipt
+
+▸ **getReceipt**(): `Promise`\<`TxReceipt`\>
+
+Retrieve the transaction receipt associated with the current SentTx instance.
+The function fetches the transaction hash using 'getTxHash' and then queries
+the PXE to get the corresponding transaction receipt.
+
+#### Returns
+
+`Promise`\<`TxReceipt`\>
+
+A promise that resolves to a TxReceipt object representing the fetched transaction receipt.
+
+___
+
+### getTxHash
+
+▸ **getTxHash**(): `Promise`\<`TxHash`\>
+
+Retrieves the transaction hash of the SentTx instance.
+The function internally awaits for the 'txHashPromise' to resolve, and then returns the resolved transaction hash.
+
+#### Returns
+
+`Promise`\<`TxHash`\>
+
+A promise that resolves to the transaction hash of the SentTx instance.
+
+___
+
+### getUnencryptedLogs
+
+▸ **getUnencryptedLogs**(): `Promise`\<`GetUnencryptedLogsResponse`\>
+
+Gets unencrypted logs emitted by this tx.
+
+#### Returns
+
+`Promise`\<`GetUnencryptedLogsResponse`\>
+
+The requested logs.
+
+**`Remarks`**
+
+This function will wait for the tx to be mined if it hasn't been already.
+
+___
+
+### getVisibleNotes
+
+▸ **getVisibleNotes**(): `Promise`\<`ExtendedNote`[]\>
+
+Get notes of accounts registered in the provided PXE/Wallet created in this tx.
+
+#### Returns
+
+`Promise`\<`ExtendedNote`[]\>
+
+The requested notes.
+
+**`Remarks`**
+
+This function will wait for the tx to be mined if it hasn't been already.
+
+___
+
+### wait
+
+▸ **wait**(`opts?`): `Promise`\<`FieldsOf`\<`TxReceipt`\>\>
+
+Awaits for a tx to be mined and returns the receipt. Throws if tx is not mined.
+
+#### Parameters
+
+| Name | Type | Description |
+| :------ | :------ | :------ |
+| `opts?` | [`WaitOpts`](../modules/contract.md#waitopts) | Options for configuring the waiting for the tx to be mined. |
+
+#### Returns
+
+`Promise`\<`FieldsOf`\<`TxReceipt`\>\>
+
+The transaction receipt.
+
+___
+
+### waitForReceipt
+
+▸ **waitForReceipt**(`opts?`): `Promise`\<`TxReceipt`\>
+
+#### Parameters
+
+| Name | Type |
+| :------ | :------ |
+| `opts?` | [`WaitOpts`](../modules/contract.md#waitopts) |
+
+#### Returns
+
+`Promise`\<`TxReceipt`\>
diff --git a/docs/docs/developers/apis/aztec-js/index.md b/docs/docs/developers/apis/aztec-js/index.md
new file mode 100644
index 00000000000..388fadecb3d
--- /dev/null
+++ b/docs/docs/developers/apis/aztec-js/index.md
@@ -0,0 +1,50 @@
+---
+id: "index"
+title: "@aztec/aztec.js"
+sidebar_label: "Readme"
+sidebar_position: 0
+custom_edit_url: null
+---
+
+# Aztec.js
+
+Aztec.js is a library that provides APIs for managing accounts and interacting with contracts on the Aztec network. It communicates with the [Private eXecution Environment (PXE)](https://docs.aztec.network/apis/pxe/interfaces/PXE) through a `PXE` implementation, allowing developers to easily register new accounts, deploy contracts, view functions, and send transactions.
+
+## Installing
+
+```
+npm install @aztec/aztec.js
+```
+
+## Usage
+
+Use the `@aztec/accounts` package in order to create and manage accounts, and acquire a `Wallet` object needed to send transactions and interact with the network.
+
+### Deploy a contract
+
+```typescript
+import { Contract } from '@aztec/aztec.js';
+
+const contract = await Contract.deploy(wallet, MyContractArtifact, [...constructorArgs]).send().deployed();
+console.log(`Contract deployed at ${contract.address}`);
+```
+
+### Send a transaction
+
+```typescript
+import { Contract } from '@aztec/aztec.js';
+
+const contract = await Contract.at(contractAddress, MyContractArtifact, wallet);
+const tx = await contract.methods.transfer(amount, recipientAddress).send().wait();
+console.log(`Transferred ${amount} to ${recipientAddress} on block ${tx.blockNumber}`);
+```
+
+### Call a view function
+
+```typescript
+import { Contract } from '@aztec/aztec.js';
+
+const contract = await Contract.at(contractAddress, MyContractArtifact, wallet);
+const balance = await contract.methods.getBalance(wallet.getAddress()).view();
+console.log(`Account balance is ${balance}`);
+```
diff --git a/docs/docs/developers/apis/aztec-js/interfaces/_category_.yml b/docs/docs/developers/apis/aztec-js/interfaces/_category_.yml
new file mode 100644
index 00000000000..43bec88cfa0
--- /dev/null
+++ b/docs/docs/developers/apis/aztec-js/interfaces/_category_.yml
@@ -0,0 +1,2 @@
+label: "Interfaces"
+position: 4
\ No newline at end of file
diff --git a/docs/docs/developers/apis/aztec-js/interfaces/account.AccountContract.md b/docs/docs/developers/apis/aztec-js/interfaces/account.AccountContract.md
new file mode 100644
index 00000000000..cc78bca8da5
--- /dev/null
+++ b/docs/docs/developers/apis/aztec-js/interfaces/account.AccountContract.md
@@ -0,0 +1,58 @@
+---
+id: "account.AccountContract"
+title: "Interface: AccountContract"
+sidebar_label: "AccountContract"
+custom_edit_url: null
+---
+
+[account](../modules/account.md).AccountContract
+
+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
+
+### getContractArtifact
+
+▸ **getContractArtifact**(): `ContractArtifact`
+
+Returns the artifact of this account contract.
+
+#### Returns
+
+`ContractArtifact`
+
+___
+
+### getDeploymentArgs
+
+▸ **getDeploymentArgs**(): `any`[]
+
+Returns the deployment arguments for this instance.
+
+#### Returns
+
+`any`[]
+
+___
+
+### getInterface
+
+▸ **getInterface**(`address`, `nodeInfo`): [`AccountInterface`](account.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`](account.AccountInterface.md)
+
+An account interface instance for creating tx requests and authorizing actions.
diff --git a/docs/docs/developers/apis/aztec-js/interfaces/account.AccountInterface.md b/docs/docs/developers/apis/aztec-js/interfaces/account.AccountInterface.md
new file mode 100644
index 00000000000..491e09fbbb1
--- /dev/null
+++ b/docs/docs/developers/apis/aztec-js/interfaces/account.AccountInterface.md
@@ -0,0 +1,77 @@
+---
+id: "account.AccountInterface"
+title: "Interface: AccountInterface"
+sidebar_label: "AccountInterface"
+custom_edit_url: null
+---
+
+[account](../modules/account.md).AccountInterface
+
+Handler for interfacing with an account. Knows how to create transaction execution
+requests and authorize actions for its corresponding account.
+
+## Hierarchy
+
+- [`AuthWitnessProvider`](account.AuthWitnessProvider.md)
+
+- [`EntrypointInterface`](account.EntrypointInterface.md)
+
+  ↳ **`AccountInterface`**
+
+## Methods
+
+### createAuthWitness
+
+▸ **createAuthWitness**(`message`): `Promise`\<`AuthWitness`\>
+
+Create an authorization witness for the given message.
+
+#### Parameters
+
+| Name | Type | Description |
+| :------ | :------ | :------ |
+| `message` | `Fr` | Message to authorize. |
+
+#### Returns
+
+`Promise`\<`AuthWitness`\>
+
+#### Inherited from
+
+[AuthWitnessProvider](account.AuthWitnessProvider.md).[createAuthWitness](account.AuthWitnessProvider.md#createauthwitness)
+
+___
+
+### createTxExecutionRequest
+
+▸ **createTxExecutionRequest**(`executions`): `Promise`\<`TxExecutionRequest`\>
+
+Generates an authenticated request out of set of function calls.
+
+#### Parameters
+
+| Name | Type | Description |
+| :------ | :------ | :------ |
+| `executions` | `FunctionCall`[] | The execution intents to be run. |
+
+#### Returns
+
+`Promise`\<`TxExecutionRequest`\>
+
+The authenticated transaction execution request.
+
+#### Inherited from
+
+[EntrypointInterface](account.EntrypointInterface.md).[createTxExecutionRequest](account.EntrypointInterface.md#createtxexecutionrequest)
+
+___
+
+### getCompleteAddress
+
+▸ **getCompleteAddress**(): `CompleteAddress`
+
+Returns the complete address for this account.
+
+#### Returns
+
+`CompleteAddress`
diff --git a/docs/docs/developers/apis/aztec-js/interfaces/account.AuthWitnessProvider.md b/docs/docs/developers/apis/aztec-js/interfaces/account.AuthWitnessProvider.md
new file mode 100644
index 00000000000..6775118d095
--- /dev/null
+++ b/docs/docs/developers/apis/aztec-js/interfaces/account.AuthWitnessProvider.md
@@ -0,0 +1,34 @@
+---
+id: "account.AuthWitnessProvider"
+title: "Interface: AuthWitnessProvider"
+sidebar_label: "AuthWitnessProvider"
+custom_edit_url: null
+---
+
+[account](../modules/account.md).AuthWitnessProvider
+
+Creates authorization witnesses.
+
+## Hierarchy
+
+- **`AuthWitnessProvider`**
+
+  ↳ [`AccountInterface`](account.AccountInterface.md)
+
+## Methods
+
+### createAuthWitness
+
+▸ **createAuthWitness**(`message`): `Promise`\<`AuthWitness`\>
+
+Create an authorization witness for the given message.
+
+#### Parameters
+
+| Name | Type | Description |
+| :------ | :------ | :------ |
+| `message` | `Fr` | Message to authorize. |
+
+#### Returns
+
+`Promise`\<`AuthWitness`\>
diff --git a/docs/docs/developers/apis/aztec-js/interfaces/account.EntrypointInterface.md b/docs/docs/developers/apis/aztec-js/interfaces/account.EntrypointInterface.md
new file mode 100644
index 00000000000..a8b660029a6
--- /dev/null
+++ b/docs/docs/developers/apis/aztec-js/interfaces/account.EntrypointInterface.md
@@ -0,0 +1,36 @@
+---
+id: "account.EntrypointInterface"
+title: "Interface: EntrypointInterface"
+sidebar_label: "EntrypointInterface"
+custom_edit_url: null
+---
+
+[account](../modules/account.md).EntrypointInterface
+
+Creates transaction execution requests out of a set of function calls.
+
+## Hierarchy
+
+- **`EntrypointInterface`**
+
+  ↳ [`AccountInterface`](account.AccountInterface.md)
+
+## Methods
+
+### createTxExecutionRequest
+
+▸ **createTxExecutionRequest**(`executions`): `Promise`\<`TxExecutionRequest`\>
+
+Generates an authenticated request out of set of function calls.
+
+#### Parameters
+
+| Name | Type | Description |
+| :------ | :------ | :------ |
+| `executions` | `FunctionCall`[] | The execution intents to be run. |
+
+#### Returns
+
+`Promise`\<`TxExecutionRequest`\>
+
+The authenticated transaction execution request.
diff --git a/docs/docs/developers/apis/aztec-js/modules.md b/docs/docs/developers/apis/aztec-js/modules.md
new file mode 100644
index 00000000000..f7beffd6eb3
--- /dev/null
+++ b/docs/docs/developers/apis/aztec-js/modules.md
@@ -0,0 +1,13 @@
+---
+id: "modules"
+title: "@aztec/aztec.js"
+sidebar_label: "Table of Contents"
+sidebar_position: 0.5
+hide_table_of_contents: true
+custom_edit_url: null
+---
+
+## Modules
+
+- [account](modules/account.md)
+- [contract](modules/contract.md)
diff --git a/docs/docs/developers/apis/aztec-js/modules/_category_.yml b/docs/docs/developers/apis/aztec-js/modules/_category_.yml
new file mode 100644
index 00000000000..63f9c4e4016
--- /dev/null
+++ b/docs/docs/developers/apis/aztec-js/modules/_category_.yml
@@ -0,0 +1,2 @@
+label: "Modules"
+position: 1
\ No newline at end of file
diff --git a/docs/docs/developers/apis/aztec-js/modules/account.md b/docs/docs/developers/apis/aztec-js/modules/account.md
new file mode 100644
index 00000000000..7668eddf0ec
--- /dev/null
+++ b/docs/docs/developers/apis/aztec-js/modules/account.md
@@ -0,0 +1,35 @@
+---
+id: "account"
+title: "Module: account"
+sidebar_label: "account"
+sidebar_position: 0
+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/account.AccountContract.md)
+- [AccountInterface](../interfaces/account.AccountInterface.md)
+- [AuthWitnessProvider](../interfaces/account.AuthWitnessProvider.md)
+- [EntrypointInterface](../interfaces/account.EntrypointInterface.md)
+
+## Type Aliases
+
+### Salt
+
+Ƭ **Salt**: `Fr` \| `number` \| `bigint`
+
+A contract deployment salt.
+
+___
+
+### Wallet
+
+Ƭ **Wallet**: [`AccountInterface`](../interfaces/account.AccountInterface.md) & `PXE`
+
+The wallet interface.
diff --git a/docs/docs/developers/apis/aztec-js/modules/contract.md b/docs/docs/developers/apis/aztec-js/modules/contract.md
new file mode 100644
index 00000000000..d39d055e09d
--- /dev/null
+++ b/docs/docs/developers/apis/aztec-js/modules/contract.md
@@ -0,0 +1,146 @@
+---
+id: "contract"
+title: "Module: contract"
+sidebar_label: "contract"
+sidebar_position: 0
+custom_edit_url: null
+---
+
+The `contract` module provides utilities for deploying and interacting with contracts, based on a
+`Wallet` instance and a compiled artifact. Refer to the [account](account.md) module for how to obtain a valid
+`Wallet` instance, and to the [Compiling contracts](https://docs.aztec.network/developers/contracts/compiling)
+section of the documentation for how to generate an artifact out of your Noir source code.
+
+The [Contract](../classes/contract.Contract.md) class is the main class in this module, and provides static methods for deploying
+a contract or interacting with an already deployed one. The `methods` property of the contract instance
+provides access to private, public, and view methods, that can be invoked in a transaction via `send()`,
+or can be queried via `view()`.
+
+```ts
+const contract = await Contract.deploy(wallet, MyContractArtifact, [...constructorArgs]).send().deployed();
+console.log(`Contract deployed at ${contract.address}`);
+```
+
+```ts
+const contract = await Contract.at(address, MyContractArtifact, wallet);
+await contract.methods.mint(1000, owner).send().wait();
+console.log(`Total supply is now ${await contract.methods.totalSupply().view()}`);
+```
+
+The result of calling a method in a contract instance, such as `contract.methods.mint(1000, owner)`
+in the example, is a [ContractFunctionInteraction](../classes/contract.ContractFunctionInteraction.md) instance. Usually this will be just sent as
+a transaction to the network via the `send` method, but you can also `simulate` it without sending,
+or obtaining the `request` for aggregating into a [BatchCall](../classes/contract.BatchCall.md).
+
+The result of `send`ing a transaction is a [SentTx](../classes/contract.SentTx.md) object, from which you can get the
+transaction hash, or simply `wait` until the transaction is mined and the local PXE Service
+has synchronized its changes.
+
+**`Remarks`**
+
+If you are using typescript, consider using the
+[autogenerated type-safe interfaces](https://docs.aztec.network/developers/contracts/compiling#typescript-interfaces)
+for interacting with your contracts.
+
+## Classes
+
+- [BatchCall](../classes/contract.BatchCall.md)
+- [Contract](../classes/contract.Contract.md)
+- [ContractBase](../classes/contract.ContractBase.md)
+- [ContractFunctionInteraction](../classes/contract.ContractFunctionInteraction.md)
+- [DeployMethod](../classes/contract.DeployMethod.md)
+- [DeploySentTx](../classes/contract.DeploySentTx.md)
+- [SentTx](../classes/contract.SentTx.md)
+
+## Type Aliases
+
+### ContractMethod
+
+Ƭ **ContractMethod**: (...`args`: `any`[]) => [`ContractFunctionInteraction`](../classes/contract.ContractFunctionInteraction.md) & \{ `selector`: `FunctionSelector`  }
+
+Type representing a contract method that returns a ContractFunctionInteraction instance
+and has a readonly 'selector' property of type Buffer. Takes any number of arguments.
+
+___
+
+### DeployOptions
+
+Ƭ **DeployOptions**: \{ `contractAddressSalt?`: `Fr` ; `portalContract?`: `EthAddress`  } & [`SendMethodOptions`](contract.md#sendmethodoptions)
+
+Options for deploying a contract on the Aztec network.
+Allows specifying a portal contract, contract address salt, and additional send method options.
+
+___
+
+### DeployTxReceipt
+
+Ƭ **DeployTxReceipt**\<`TContract`\>: `FieldsOf`\<`TxReceipt`\> & \{ `contract`: `TContract`  }
+
+Extends a transaction receipt with a contract instance that represents the newly deployed contract.
+
+#### Type parameters
+
+| Name | Type |
+| :------ | :------ |
+| `TContract` | extends [`ContractBase`](../classes/contract.ContractBase.md) = [`Contract`](../classes/contract.Contract.md) |
+
+___
+
+### DeployedWaitOpts
+
+Ƭ **DeployedWaitOpts**: [`WaitOpts`](contract.md#waitopts) & \{ `wallet?`: [`Wallet`](account.md#wallet)  }
+
+Options related to waiting for a deployment tx.
+
+___
+
+### SendMethodOptions
+
+Ƭ **SendMethodOptions**: `Object`
+
+Represents options for calling a (constrained) function in a contract.
+Allows the user to specify the sender address and nonce for a transaction.
+
+#### Type declaration
+
+| Name | Type | Description |
+| :------ | :------ | :------ |
+| `skipPublicSimulation?` | `boolean` | Wether to skip the simulation of the public part of the transaction. |
+
+___
+
+### ViewMethodOptions
+
+Ƭ **ViewMethodOptions**: `Object`
+
+Represents the options for a view method in a contract function interaction.
+Allows specifying the address from which the view method should be called.
+
+#### Type declaration
+
+| Name | Type | Description |
+| :------ | :------ | :------ |
+| `from?` | `AztecAddress` | The sender's Aztec address. |
+
+___
+
+### WaitOpts
+
+Ƭ **WaitOpts**: `Object`
+
+Options related to waiting for a tx.
+
+#### Type declaration
+
+| Name | Type | Description |
+| :------ | :------ | :------ |
+| `debug?` | `boolean` | Whether to include information useful for debugging/testing in the receipt. |
+| `interval?` | `number` | The time interval (in seconds) between retries to fetch the transaction receipt. Defaults to 1. |
+| `timeout?` | `number` | The maximum time (in seconds) to wait for the transaction to be mined. Defaults to 60. |
+| `waitForNotesSync?` | `boolean` | Whether to wait for the PXE Service to sync all notes up to the block in which this tx was mined. If false, then any queries that depend on state set by this transaction may return stale data. Defaults to true. |
+
+## Variables
+
+### DefaultWaitOpts
+
+• `Const` **DefaultWaitOpts**: [`WaitOpts`](contract.md#waitopts)
diff --git a/docs/docs/developers/apis/pxe/_category_.yml b/docs/docs/developers/apis/pxe/_category_.yml
new file mode 100644
index 00000000000..24a46026174
--- /dev/null
+++ b/docs/docs/developers/apis/pxe/_category_.yml
@@ -0,0 +1 @@
+label: "API"
\ No newline at end of file
diff --git a/docs/docs/developers/apis/pxe/index.md b/docs/docs/developers/apis/pxe/index.md
new file mode 100644
index 00000000000..f3862305aeb
--- /dev/null
+++ b/docs/docs/developers/apis/pxe/index.md
@@ -0,0 +1,10 @@
+---
+id: "index"
+title: "@aztec/circuit-types"
+sidebar_label: "Private Execution Environment (PXE)"
+sidebar_position: 0
+custom_edit_url: null
+---
+
+# Circuit Types
+A package containing circuit dependent types which are relevant through all the Aztec Typescript codebase.
diff --git a/docs/docs/developers/apis/pxe/interfaces/PXE.md b/docs/docs/developers/apis/pxe/interfaces/PXE.md
new file mode 100644
index 00000000000..3d3d7e33cda
--- /dev/null
+++ b/docs/docs/developers/apis/pxe/interfaces/PXE.md
@@ -0,0 +1,582 @@
+---
+id: "PXE"
+title: "Interface: PXE"
+sidebar_label: "Private Execution Environment (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
+
+### addAuthWitness
+
+▸ **addAuthWitness**(`authWitness`): `Promise`\<`void`\>
+
+Insert an auth witness for a given message hash. Auth witnesses are used to authorize actions on
+behalf of a user. For instance, a token transfer initiated by a different address may request
+authorization from the user to move their tokens. This authorization is granted by the user
+account contract by verifying an auth witness requested to the execution oracle. Witnesses are
+usually a signature over a hash of the action to be authorized, but their actual contents depend
+on the account contract that consumes them.
+
+#### Parameters
+
+| Name | Type | Description |
+| :------ | :------ | :------ |
+| `authWitness` | `AuthWitness` | The auth witness to insert. Composed of an identifier, which is the hash of the action to be authorized, and the actual witness as an array of fields, which are to be deserialized and processed by the account contract. |
+
+#### Returns
+
+`Promise`\<`void`\>
+
+___
+
+### addCapsule
+
+▸ **addCapsule**(`capsule`): `Promise`\<`void`\>
+
+Adding a capsule to the capsule dispenser.
+
+#### Parameters
+
+| Name | Type | Description |
+| :------ | :------ | :------ |
+| `capsule` | `Fr`[] | An array of field elements representing the capsule. |
+
+#### Returns
+
+`Promise`\<`void`\>
+
+**`Remarks`**
+
+A capsule is a "blob" of data that is passed to the contract through an oracle.
+
+___
+
+### addContracts
+
+▸ **addContracts**(`contracts`): `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 |
+| :------ | :------ | :------ |
+| `contracts` | `DeployedContract`[] | An array of DeployedContract objects containing contract ABI, address, and portal contract. |
+
+#### Returns
+
+`Promise`\<`void`\>
+
+___
+
+### addNote
+
+▸ **addNote**(`note`): `Promise`\<`void`\>
+
+Adds a note to the database.
+
+#### Parameters
+
+| Name | Type | Description |
+| :------ | :------ | :------ |
+| `note` | `ExtendedNote` | The note to add. |
+
+#### Returns
+
+`Promise`\<`void`\>
+
+**`Throws`**
+
+If the note hash of the note doesn't exist in the tree.
+
+___
+
+### 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.
+
+___
+
+### getContractData
+
+▸ **getContractData**(`contractAddress`): `Promise`\<`undefined` \| `ContractData`\>
+
+Gets the portal contract address on L1 for the given contract.
+
+#### Parameters
+
+| Name | Type | Description |
+| :------ | :------ | :------ |
+| `contractAddress` | `AztecAddress` | The contract's address. |
+
+#### Returns
+
+`Promise`\<`undefined` \| `ContractData`\>
+
+The contract's portal address if found.
+
+___
+
+### 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.
+
+___
+
+### getExtendedContractData
+
+▸ **getExtendedContractData**(`contractAddress`): `Promise`\<`undefined` \| `ExtendedContractData`\>
+
+Gets the extended contract data for this contract. Extended contract data includes the address,
+portal contract address on L1, public functions, partial address, and encryption public key.
+
+#### Parameters
+
+| Name | Type | Description |
+| :------ | :------ | :------ |
+| `contractAddress` | `AztecAddress` | The contract's address. |
+
+#### Returns
+
+`Promise`\<`undefined` \| `ExtendedContractData`\>
+
+The extended contract data if found.
+
+___
+
+### getNodeInfo
+
+▸ **getNodeInfo**(): `Promise`\<`NodeInfo`\>
+
+Returns the information about the server's node. Includes current Node version, compatible Noir version,
+L1 chain identifier, protocol version, and L1 address of the rollup contract.
+
+#### Returns
+
+`Promise`\<`NodeInfo`\>
+
+- The node information.
+
+___
+
+### getNotes
+
+▸ **getNotes**(`filter`): `Promise`\<`ExtendedNote`[]\>
+
+Gets notes of accounts registered in this PXE based on the provided filter.
+
+#### Parameters
+
+| Name | Type | Description |
+| :------ | :------ | :------ |
+| `filter` | `NoteFilter` | The filter to apply to the notes. |
+
+#### Returns
+
+`Promise`\<`ExtendedNote`[]\>
+
+The requested notes.
+
+___
+
+### 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.
+
+___
+
+### getRecipient
+
+▸ **getRecipient**(`address`): `Promise`\<`undefined` \| `CompleteAddress`\>
+
+Retrieves the complete address of the recipient corresponding to the provided aztec address.
+Complete addresses include the address, the partial address, and the encryption public key.
+
+#### Parameters
+
+| Name | Type | Description |
+| :------ | :------ | :------ |
+| `address` | `AztecAddress` | The aztec address of the recipient. |
+
+#### Returns
+
+`Promise`\<`undefined` \| `CompleteAddress`\>
+
+The complete address of the requested recipient.
+
+___
+
+### getRecipients
+
+▸ **getRecipients**(): `Promise`\<`CompleteAddress`[]\>
+
+Retrieves the recipients added to this PXE Service.
+
+#### Returns
+
+`Promise`\<`CompleteAddress`[]\>
+
+An array of recipients registered on this PXE Service.
+
+___
+
+### getRegisteredAccount
+
+▸ **getRegisteredAccount**(`address`): `Promise`\<`undefined` \| `CompleteAddress`\>
+
+Retrieves the complete address of the account corresponding to the provided aztec address.
+Complete addresses include the address, the partial address, and the encryption public key.
+
+#### Parameters
+
+| Name | Type | Description |
+| :------ | :------ | :------ |
+| `address` | `AztecAddress` | The address of account. |
+
+#### Returns
+
+`Promise`\<`undefined` \| `CompleteAddress`\>
+
+The complete address of the requested account if found.
+
+___
+
+### 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.
+
+___
+
+### getSyncStatus
+
+▸ **getSyncStatus**(): `Promise`\<`SyncStatus`\>
+
+Returns the latest block that has been synchronized globally and for each account. The global block number
+indicates whether global state has been updated up to that block, whereas each address indicates up to which
+block the private state has been synced for that account.
+
+#### Returns
+
+`Promise`\<`SyncStatus`\>
+
+The latest block synchronized for blocks, and the latest block synched for notes for each public key being tracked.
+
+___
+
+### getTx
+
+▸ **getTx**(`txHash`): `Promise`\<`undefined` \| `L2Tx`\>
+
+Fetches a transaction by its hash.
+
+#### Parameters
+
+| Name | Type | Description |
+| :------ | :------ | :------ |
+| `txHash` | `TxHash` | The transaction hash |
+
+#### Returns
+
+`Promise`\<`undefined` \| `L2Tx`\>
+
+A transaction object or undefined if the transaction hasn't been mined yet
+
+___
+
+### 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.
+
+___
+
+### getUnencryptedLogs
+
+▸ **getUnencryptedLogs**(`filter`): `Promise`\<`GetUnencryptedLogsResponse`\>
+
+Gets unencrypted logs based on the provided filter.
+
+#### Parameters
+
+| Name | Type | Description |
+| :------ | :------ | :------ |
+| `filter` | `LogFilter` | The filter to apply to the logs. |
+
+#### Returns
+
+`Promise`\<`GetUnencryptedLogsResponse`\>
+
+The requested logs.
+
+___
+
+### isAccountStateSynchronized
+
+▸ **isAccountStateSynchronized**(`account`): `Promise`\<`boolean`\>
+
+Checks if the specified account is synchronized.
+
+#### Parameters
+
+| Name | Type | Description |
+| :------ | :------ | :------ |
+| `account` | `AztecAddress` | The aztec address for which to query the sync status. |
+
+#### Returns
+
+`Promise`\<`boolean`\>
+
+True if the account is fully synched, false otherwise.
+
+**`Deprecated`**
+
+Use `getSyncStatus` instead.
+
+**`Remarks`**
+
+Checks whether all the notes from all the blocks have been processed. If it is not the case, the
+retrieved information from contracts might be old/stale (e.g. old token balance).
+
+**`Throws`**
+
+If checking a sync status of account which is not registered.
+
+___
+
+### isGlobalStateSynchronized
+
+▸ **isGlobalStateSynchronized**(): `Promise`\<`boolean`\>
+
+Checks whether all the blocks were processed (tree roots updated, txs updated with block info, etc.).
+
+#### Returns
+
+`Promise`\<`boolean`\>
+
+True if there are no outstanding blocks to be synched.
+
+**`Remarks`**
+
+This indicates that blocks and transactions are synched even if notes are not. Compares local block number with the block number from aztec node.
+
+**`Deprecated`**
+
+Use `getSyncStatus` instead.
+
+___
+
+### registerAccount
+
+▸ **registerAccount**(`privKey`, `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 |
+| :------ | :------ | :------ |
+| `privKey` | `Fq` | Private 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.
+
+___
+
+### registerRecipient
+
+▸ **registerRecipient**(`recipient`): `Promise`\<`void`\>
+
+Registers a recipient in PXE. This is required when sending encrypted notes to
+a user who hasn't deployed their account contract yet. Since their account is not deployed, their
+encryption public key has not been broadcasted, so we need to manually register it on the PXE Service
+in order to be able to encrypt data for this recipient.
+
+#### Parameters
+
+| Name | Type | Description |
+| :------ | :------ | :------ |
+| `recipient` | `CompleteAddress` | The complete address of the recipient |
+
+#### Returns
+
+`Promise`\<`void`\>
+
+**`Remarks`**
+
+Called recipient because we can only send notes to this account and not receive them via this PXE Service.
+This is because we don't have the associated private key and for this reason we can't decrypt
+the recipient's notes. We can send notes to this account because we can encrypt them with the recipient's
+public key.
+
+___
+
+### 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 `simulateTx`. |
+
+#### Returns
+
+`Promise`\<`TxHash`\>
+
+A hash of the transaction, used to identify it.
+
+___
+
+### simulateTx
+
+▸ **simulateTx**(`txRequest`, `simulatePublic`): `Promise`\<`Tx`\>
+
+Creates a transaction based on the provided preauthenticated execution request. This will
+run a local simulation of the private execution (and optionally of public as well), assemble
+the zero-knowledge proof for the private execution, and return the transaction object.
+
+#### Parameters
+
+| Name | Type | Description |
+| :------ | :------ | :------ |
+| `txRequest` | `TxExecutionRequest` | An authenticated tx request ready for simulation |
+| `simulatePublic` | `boolean` | Whether to simulate the public part of the transaction. |
+
+#### Returns
+
+`Promise`\<`Tx`\>
+
+A transaction ready to be sent to the network for execution.
+
+**`Throws`**
+
+If the code for the functions executed in this transaction has not been made available via `addContracts`.
+
+___
+
+### viewTx
+
+▸ **viewTx**(`functionName`, `args`, `to`, `from?`): `Promise`\<`any`\>
+
+Simulate the execution of a view (read-only) function on a deployed contract without actually modifying state.
+This is useful to inspect contract state, for example fetching a variable value or calling a getter function.
+The function takes function name and arguments as parameters, along with the contract address
+and optionally the sender's address.
+
+#### Parameters
+
+| Name | Type | Description |
+| :------ | :------ | :------ |
+| `functionName` | `string` | The name of the function to be called in the contract. |
+| `args` | `any`[] | The arguments to be provided to the function. |
+| `to` | `AztecAddress` | The address of the contract to be called. |
+| `from?` | `AztecAddress` | (Optional) The msg sender to set for the call. |
+
+#### Returns
+
+`Promise`\<`any`\>
+
+The result of the view function call, structured based on the function ABI.
diff --git a/docs/docs/developers/apis/pxe/interfaces/_category_.yml b/docs/docs/developers/apis/pxe/interfaces/_category_.yml
new file mode 100644
index 00000000000..43bec88cfa0
--- /dev/null
+++ b/docs/docs/developers/apis/pxe/interfaces/_category_.yml
@@ -0,0 +1,2 @@
+label: "Interfaces"
+position: 4
\ No newline at end of file
diff --git a/docs/docs/developers/apis/pxe/modules.md b/docs/docs/developers/apis/pxe/modules.md
new file mode 100644
index 00000000000..0b801ef4fe2
--- /dev/null
+++ b/docs/docs/developers/apis/pxe/modules.md
@@ -0,0 +1,11 @@
+---
+id: "modules"
+title: "@aztec/circuit-types"
+sidebar_label: "Private Execution Environment (PXE)"
+sidebar_position: 0.5
+custom_edit_url: null
+---
+
+## Interfaces
+
+- [PXE](interfaces/PXE.md)
diff --git a/docs/docs/dev_docs/aztecjs/main.md b/docs/docs/developers/aztecjs/main.md
similarity index 100%
rename from docs/docs/dev_docs/aztecjs/main.md
rename to docs/docs/developers/aztecjs/main.md
diff --git a/docs/docs/dev_docs/cli/blank_box.md b/docs/docs/developers/cli/blank_box.md
similarity index 100%
rename from docs/docs/dev_docs/cli/blank_box.md
rename to docs/docs/developers/cli/blank_box.md
diff --git a/docs/docs/dev_docs/cli/cli-commands.md b/docs/docs/developers/cli/cli-commands.md
similarity index 97%
rename from docs/docs/dev_docs/cli/cli-commands.md
rename to docs/docs/developers/cli/cli-commands.md
index 080dd071ab5..83c107365d8 100644
--- a/docs/docs/dev_docs/cli/cli-commands.md
+++ b/docs/docs/developers/cli/cli-commands.md
@@ -41,11 +41,11 @@ You can find more information about compiling contracts [on this page](../contra
 
 ## Creating Accounts
 
-The first thing we want to do is create a couple of accounts. We will use the `create-account` command which will generate a new private key for us, register the account on the sandbox, and deploy a simple account contract which [uses a single key for privacy and authentication](../../concepts/foundation/accounts/keys.md):
+The first thing we want to do is create a couple of accounts. We will use the `create-account` command which will generate a new private key for us, register the account on the sandbox, and deploy a simple account contract which [uses a single key for privacy and authentication](../../learn/concepts/accounts/keys.md):
 
 #include_code create-account yarn-project/end-to-end/src/cli_docs_sandbox.test.ts bash
 
-Once the account is set up, the CLI returns the resulting address, its privacy key, and partial address. You can read more about these [here](../../concepts/foundation/accounts/keys.md#addresses-partial-addresses-and-public-keys).
+Once the account is set up, the CLI returns the resulting address, its privacy key, and partial address. You can read more about these [here](../../learn/concepts/accounts/keys.md#addresses-partial-addresses-and-public-keys).
 
 Save the Address and Private key as environment variables. We will be using them later.
 
diff --git a/docs/docs/dev_docs/cli/main.md b/docs/docs/developers/cli/main.md
similarity index 100%
rename from docs/docs/dev_docs/cli/main.md
rename to docs/docs/developers/cli/main.md
diff --git a/docs/docs/dev_docs/cli/run_more_than_one_pxe_sandbox.md b/docs/docs/developers/cli/run_more_than_one_pxe_sandbox.md
similarity index 100%
rename from docs/docs/dev_docs/cli/run_more_than_one_pxe_sandbox.md
rename to docs/docs/developers/cli/run_more_than_one_pxe_sandbox.md
diff --git a/docs/docs/dev_docs/cli/sandbox-reference.md b/docs/docs/developers/cli/sandbox-reference.md
similarity index 100%
rename from docs/docs/dev_docs/cli/sandbox-reference.md
rename to docs/docs/developers/cli/sandbox-reference.md
diff --git a/docs/docs/dev_docs/contracts/abi.md b/docs/docs/developers/contracts/abi.md
similarity index 100%
rename from docs/docs/dev_docs/contracts/abi.md
rename to docs/docs/developers/contracts/abi.md
diff --git a/docs/docs/dev_docs/contracts/artifacts.md b/docs/docs/developers/contracts/artifacts.md
similarity index 100%
rename from docs/docs/dev_docs/contracts/artifacts.md
rename to docs/docs/developers/contracts/artifacts.md
diff --git a/docs/docs/dev_docs/contracts/compiling.md b/docs/docs/developers/contracts/compiling.md
similarity index 98%
rename from docs/docs/dev_docs/contracts/compiling.md
rename to docs/docs/developers/contracts/compiling.md
index 8d19f7811a8..1351006ed65 100644
--- a/docs/docs/dev_docs/contracts/compiling.md
+++ b/docs/docs/developers/contracts/compiling.md
@@ -217,7 +217,7 @@ At the moment, the compiler generates these interfaces from already compiled ABI
 
 ## Next steps
 
-Once you have compiled your contracts, you can use the generated artifacts via the `Contract` class in the `aztec.js` package to deploy and interact with them, or rely on the type-safe typescript classes directly. Alternatively, use the CLI [to deploy](../../dev_docs/cli/main.md#deploying-a-token-contract) and [interact](../../dev_docs/cli/main.md#sending-a-transaction) with them.
+Once you have compiled your contracts, you can use the generated artifacts via the `Contract` class in the `aztec.js` package to deploy and interact with them, or rely on the type-safe typescript classes directly. Alternatively, use the CLI [to deploy](../../developers/cli/main.md#deploying-a-token-contract) and [interact](../../developers/cli/main.md#sending-a-transaction) with them.
 
 import Disclaimer from "../../misc/common/\_disclaimer.mdx";
 <Disclaimer/>
diff --git a/docs/docs/dev_docs/contracts/deploying.md b/docs/docs/developers/contracts/deploying.md
similarity index 100%
rename from docs/docs/dev_docs/contracts/deploying.md
rename to docs/docs/developers/contracts/deploying.md
diff --git a/docs/docs/dev_docs/contracts/example-contract.md b/docs/docs/developers/contracts/example-contract.md
similarity index 100%
rename from docs/docs/dev_docs/contracts/example-contract.md
rename to docs/docs/developers/contracts/example-contract.md
diff --git a/docs/docs/dev_docs/contracts/layout.md b/docs/docs/developers/contracts/layout.md
similarity index 100%
rename from docs/docs/dev_docs/contracts/layout.md
rename to docs/docs/developers/contracts/layout.md
diff --git a/docs/docs/dev_docs/contracts/main.md b/docs/docs/developers/contracts/main.md
similarity index 100%
rename from docs/docs/dev_docs/contracts/main.md
rename to docs/docs/developers/contracts/main.md
diff --git a/docs/docs/dev_docs/contracts/portals/data_structures.md b/docs/docs/developers/contracts/portals/data_structures.md
similarity index 100%
rename from docs/docs/dev_docs/contracts/portals/data_structures.md
rename to docs/docs/developers/contracts/portals/data_structures.md
diff --git a/docs/docs/dev_docs/contracts/portals/inbox.md b/docs/docs/developers/contracts/portals/inbox.md
similarity index 100%
rename from docs/docs/dev_docs/contracts/portals/inbox.md
rename to docs/docs/developers/contracts/portals/inbox.md
diff --git a/docs/docs/dev_docs/contracts/portals/main.md b/docs/docs/developers/contracts/portals/main.md
similarity index 97%
rename from docs/docs/dev_docs/contracts/portals/main.md
rename to docs/docs/developers/contracts/portals/main.md
index ab0654dba98..11fc1c0b9de 100644
--- a/docs/docs/dev_docs/contracts/portals/main.md
+++ b/docs/docs/developers/contracts/portals/main.md
@@ -7,7 +7,7 @@ description: Documentation of Aztec's Portals and Cross-chain communication.
 
 A portal is the point of contact between L1 and a specific contract on Aztec. For applications such as token bridges, this is the point where the tokens are held on L1 while used in L2.
 
-As outlined in the [foundational concepts](../../../concepts/foundation/communication/cross_chain_calls.md), an Aztec L2 contract is linked to _ONE_ L1 address at time of deployment (specified by the developer). This L1 address is the only address that can send messages to that specific L2 contract, and the only address that can receive messages sent from the L2 contract to L1. Note, that a portal don't actually need to be a contract, it could be any address on L1. We say that an Aztec contract is attached to a portal.
+As outlined in [Communication](../../../learn/concepts/communication/cross_chain_calls.md), an Aztec L2 contract is linked to _ONE_ L1 address at time of deployment (specified by the developer). This L1 address is the only address that can send messages to that specific L2 contract, and the only address that can receive messages sent from the L2 contract to L1. Note, that a portal don't actually need to be a contract, it could be any address on L1. We say that an Aztec contract is attached to a portal.
 
 ## Passing data to the rollup
 
diff --git a/docs/docs/dev_docs/contracts/portals/outbox.md b/docs/docs/developers/contracts/portals/outbox.md
similarity index 100%
rename from docs/docs/dev_docs/contracts/portals/outbox.md
rename to docs/docs/developers/contracts/portals/outbox.md
diff --git a/docs/docs/dev_docs/contracts/portals/registry.md b/docs/docs/developers/contracts/portals/registry.md
similarity index 100%
rename from docs/docs/dev_docs/contracts/portals/registry.md
rename to docs/docs/developers/contracts/portals/registry.md
diff --git a/docs/docs/dev_docs/contracts/resources/common_patterns/authwit.md b/docs/docs/developers/contracts/resources/common_patterns/authwit.md
similarity index 97%
rename from docs/docs/dev_docs/contracts/resources/common_patterns/authwit.md
rename to docs/docs/developers/contracts/resources/common_patterns/authwit.md
index 54e5c3c8dd3..5700644561b 100644
--- a/docs/docs/dev_docs/contracts/resources/common_patterns/authwit.md
+++ b/docs/docs/developers/contracts/resources/common_patterns/authwit.md
@@ -5,13 +5,13 @@ description: Developer Documentation to use Authentication Witness for authentic
 
 ## Prerequisite reading
 
-- [Authwit from Foundational Concepts](./../../../../concepts/foundation/accounts/authwit.md)
+- [Authwit](./../../../../learn/concepts/accounts/authwit.md)
 
 ## Introduction
 
 Authentication Witness is a scheme for authentication actions on Aztec, so users can allow third-parties (eg protocols or other users) to execute an action on their behalf.
 
-How it works logically is explained in the [foundational concepts](./../../../../concepts/foundation/accounts/authwit.md) but we will do a short recap here.
+How it works logically is explained in the [foundational concepts](./../../../../learn/concepts/accounts/authwit.md) but we will do a short recap here.
 
 An authentication witness is defined for a specific action, such as allowing a Defi protocol to transfer funds on behalf of the user. An action is here something that could be explained as `A is allowed to perform X operation on behalf of B` and we define it as a hash computed as such:
 
@@ -168,7 +168,7 @@ With private functions covered, how can we use this in a public function? Well,
 
 Authenticating an action in the public domain is quite similar to the private domain, with the difference that we are executing a function on the account contract to add the witness, if you recall, this is because we don't have access to the oracle in the public domain.
 
-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 [foundational concepts](./../../../../concepts/foundation/accounts/authwit.md#what-about-public).
+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](./../../../../learn/concepts/accounts/authwit.md#what-about-public).
 
 #include_code authwit_public_transfer_example /yarn-project/end-to-end/src/e2e_token_contract.test.ts typescript
 
diff --git a/docs/docs/dev_docs/contracts/resources/common_patterns/main.md b/docs/docs/developers/contracts/resources/common_patterns/main.md
similarity index 96%
rename from docs/docs/dev_docs/contracts/resources/common_patterns/main.md
rename to docs/docs/developers/contracts/resources/common_patterns/main.md
index 18592c18902..5d54f7b6e35 100644
--- a/docs/docs/dev_docs/contracts/resources/common_patterns/main.md
+++ b/docs/docs/developers/contracts/resources/common_patterns/main.md
@@ -48,7 +48,7 @@ Note - you could also create a note and send it to the user. The problem is ther
 
 You can't read public storage in private domain. But nevertheless reading public storage is desirable. There are two ways:
 
-1. For public storage that changes infrequently, use the slow updates tree! Learn more about it [here](../../../../concepts/foundation/communication/public_private_calls/slow_updates_tree.md).
+1. For public storage that changes infrequently, use the slow updates tree! Learn more about it [here](../../../../learn/concepts/communication/public_private_calls/slow_updates_tree.md).
 
 2. You pass the data as a parameter to your private method and later assert in public that the data is correct. E.g.:
 
@@ -93,7 +93,7 @@ This pattern is discussed in detail in [writing a token contract section in the
 
 ### Discovering my notes
 
-When you send someone a note, the note hash gets added to the [note hash tree](../../../../concepts/advanced/data_structures/trees#note-hash-tree). To spend the note, the receiver needs to get the note itself (the note hash preimage). There are two ways you can get a hold of your notes:
+When you send someone a note, the note hash gets added to the [note hash tree](../../../../learn/concepts/storage/trees/main.md#note-hash-tree). To spend the note, the receiver needs to get the note itself (the note hash preimage). There are two ways you can get a hold of your notes:
 
 1. When sending someone a note, use `emit_encrypted_log` (the function encrypts the log in such a way that only a recipient can decrypt it). PXE then tries to decrypt all the encrypted logs, and stores the successfully decrypted one. [More info here](../../syntax/events.md)
 2. Manually using `pxe.addNote()` - If you choose to not emit logs to save gas or when creating a note in the public domain and want to consume it in private domain (`emit_encrypted_log` shouldn't be called in the public domain because everything is public), like in the previous section where we created a TransparentNote in public.
@@ -169,6 +169,6 @@ PS: when calling from private to public, `msg_sender` is the contract address wh
 
 In the [Prevent the same user flow from happening twice using nullifier](#prevent-the-same-user-flow-from-happening-twice-using-nullifiers), we recommended using nullifiers. But what you put in the nullifier is also as important.
 
-E.g. for a voting contract, if your nullifier simply emits just the `user_address`, then privacy can easily be leaked as nullifiers are deterministic (have no randomness), especially if there are few users of the contract. So you need some kind of randomness. You can add the user's secret key into the nullifier to add randomness. We call this "nullifier secrets" as explained [here](../../../../concepts/foundation/accounts/keys.md#nullifier-secrets). E.g.:
+E.g. for a voting contract, if your nullifier simply emits just the `user_address`, then privacy can easily be leaked as nullifiers are deterministic (have no randomness), especially if there are few users of the contract. So you need some kind of randomness. You can add the user's secret key into the nullifier to add randomness. We call this "nullifier secrets" as explained [here](../../../../learn/concepts/accounts/keys.md#nullifier-secrets). E.g.:
 
 #include_code nullifier /yarn-project/aztec-nr/value-note/src/value_note.nr rust
diff --git a/docs/docs/dev_docs/contracts/resources/dependencies.md b/docs/docs/developers/contracts/resources/dependencies.md
similarity index 100%
rename from docs/docs/dev_docs/contracts/resources/dependencies.md
rename to docs/docs/developers/contracts/resources/dependencies.md
diff --git a/docs/docs/dev_docs/contracts/resources/main.md b/docs/docs/developers/contracts/resources/main.md
similarity index 100%
rename from docs/docs/dev_docs/contracts/resources/main.md
rename to docs/docs/developers/contracts/resources/main.md
diff --git a/docs/docs/dev_docs/contracts/resources/style_guide.md b/docs/docs/developers/contracts/resources/style_guide.md
similarity index 100%
rename from docs/docs/dev_docs/contracts/resources/style_guide.md
rename to docs/docs/developers/contracts/resources/style_guide.md
diff --git a/docs/docs/dev_docs/contracts/security/breaking_changes/main.md b/docs/docs/developers/contracts/security/breaking_changes/main.md
similarity index 100%
rename from docs/docs/dev_docs/contracts/security/breaking_changes/main.md
rename to docs/docs/developers/contracts/security/breaking_changes/main.md
diff --git a/docs/docs/dev_docs/contracts/security/breaking_changes/v0.md b/docs/docs/developers/contracts/security/breaking_changes/v0.md
similarity index 100%
rename from docs/docs/dev_docs/contracts/security/breaking_changes/v0.md
rename to docs/docs/developers/contracts/security/breaking_changes/v0.md
diff --git a/docs/docs/dev_docs/contracts/security/main.md b/docs/docs/developers/contracts/security/main.md
similarity index 100%
rename from docs/docs/dev_docs/contracts/security/main.md
rename to docs/docs/developers/contracts/security/main.md
diff --git a/docs/docs/dev_docs/contracts/setup.md b/docs/docs/developers/contracts/setup.md
similarity index 100%
rename from docs/docs/dev_docs/contracts/setup.md
rename to docs/docs/developers/contracts/setup.md
diff --git a/docs/docs/dev_docs/contracts/syntax/constrain.md b/docs/docs/developers/contracts/syntax/constrain.md
similarity index 100%
rename from docs/docs/dev_docs/contracts/syntax/constrain.md
rename to docs/docs/developers/contracts/syntax/constrain.md
diff --git a/docs/docs/dev_docs/contracts/syntax/context.mdx b/docs/docs/developers/contracts/syntax/context.mdx
similarity index 93%
rename from docs/docs/dev_docs/contracts/syntax/context.mdx
rename to docs/docs/developers/contracts/syntax/context.mdx
index 3321cd91c4a..8f6ee0d937f 100644
--- a/docs/docs/dev_docs/contracts/syntax/context.mdx
+++ b/docs/docs/developers/contracts/syntax/context.mdx
@@ -10,7 +10,7 @@ import Image from "@theme/IdealImage";
 
 ## What is the context
 
-The context is an object that is made available within every function in `Aztec.nr`. As mentioned in the [kernel circuit documentation](../../../concepts/advanced/circuits/kernels/private_kernel.md). At the beginning of a function's execution, the context contains all of the kernel information that application needs to execute. During the lifecycle of a transaction, the function will update the context with each of it's side effects (created notes, nullifiers etc.). At the end of a function's execution the mutated context is returned to the kernel to be checked for validity.
+The context is an object that is made available within every function in `Aztec.nr`. As mentioned in the [kernel circuit documentation](../../../learn/concepts/circuits/kernels/private_kernel.md). At the beginning of a function's execution, the context contains all of the kernel information that application needs to execute. During the lifecycle of a transaction, the function will update the context with each of it's side effects (created notes, nullifiers etc.). At the end of a function's execution the mutated context is returned to the kernel to be checked for validity.
 
 Behind the scenes, Aztec.nr will pass data the kernel needs to and from a circuit, this is abstracted away from the developer. In an developer's eyes; the context is a useful structure that allows access and mutate the state of the `Aztec` blockchain.
 
@@ -23,7 +23,7 @@ On this page, you'll learn
 - Differences between the private and public contexts, especially the unique features and variables in the public context
 
 ## Two context's one API
-The `Aztec` blockchain contains two environments [public and private](../../../concepts/foundation/state_model/main.md). 
+The `Aztec` blockchain contains two environments [public and private](../../../learn/concepts/hybrid_state/main.md). 
 - Private, for private transactions taking place on user's devices.
 - Public, for public transactions taking place on the network's sequencers.
 
@@ -129,7 +129,7 @@ The public call stack contains all of the external function calls that are creat
 
 ### New L2 to L1 msgs
 
-New L2 to L1 messages contains messages that are delivered to the [l1 outbox](../../../concepts/foundation/communication/cross_chain_calls.md) on the execution of each rollup.
+New L2 to L1 messages contains messages that are delivered to the [l1 outbox](../../../learn/concepts/communication/cross_chain_calls.md) on the execution of each rollup.
 
 ## Public Context
 
diff --git a/docs/docs/dev_docs/contracts/syntax/control_structure.md b/docs/docs/developers/contracts/syntax/control_structure.md
similarity index 100%
rename from docs/docs/dev_docs/contracts/syntax/control_structure.md
rename to docs/docs/developers/contracts/syntax/control_structure.md
diff --git a/docs/docs/dev_docs/contracts/syntax/events.md b/docs/docs/developers/contracts/syntax/events.md
similarity index 100%
rename from docs/docs/dev_docs/contracts/syntax/events.md
rename to docs/docs/developers/contracts/syntax/events.md
diff --git a/docs/docs/dev_docs/contracts/syntax/functions.md b/docs/docs/developers/contracts/syntax/functions.md
similarity index 95%
rename from docs/docs/dev_docs/contracts/syntax/functions.md
rename to docs/docs/developers/contracts/syntax/functions.md
index 7bda2b14e87..763f6349cdb 100644
--- a/docs/docs/dev_docs/contracts/syntax/functions.md
+++ b/docs/docs/developers/contracts/syntax/functions.md
@@ -19,7 +19,7 @@ In Aztec there are multiple different types of visibility that can be applied to
 
 ### Data Visibility
 
-Data visibility is used to describe whether the data (or state) used in a function is generally accessible (public) or on a need to know basis (private). Functions with public data visibility are executed by the sequencer, and functions with private data visibility are executed by the user. For more information on why this is the case, see [communication](../../../concepts/foundation/communication/public_private_calls/main.md).
+Data visibility is used to describe whether the data (or state) used in a function is generally accessible (public) or on a need to know basis (private). Functions with public data visibility are executed by the sequencer, and functions with private data visibility are executed by the user. For more information on why this is the case, see [communication](../../../learn/concepts/communication/public_private_calls/main.md).
 
 In the following sections, we are going to see how these two "types" co-exists and interact.
 
@@ -114,7 +114,7 @@ You can learn how to use oracles in your smart contracts [here](../syntax/oracle
 
 ### Private -> Private
 
-In Aztec Private to Private function calls are handled by the [private kernel circuit](../../../concepts/advanced/circuits/kernels/private_kernel.md), and take place on the user's device.
+In Aztec Private to Private function calls are handled by the [private kernel circuit](../../../learn/concepts/circuits/kernels/private_kernel.md), and take place on the user's device.
 Behind the scenes, the `Private Execution Environment (PXE)` (the beating heart of Aztec that runs in your wallet) will execute all of the functions in the desired order "simulating" them in sequence. For example, a very common use-case of Private to Private interaction is calling another private function from an `account contract` (Account contracts are a general concept, more information about them can be found [here](../../wallets/writing_an_account_contract.md)).
 
 Take, for example, the following call stack:
@@ -187,13 +187,13 @@ The following snippet is from a token bridge that is burning the underlying toke
 
 ### Public -> Public
 
-The public execution environment in Aztec takes place on the sequencer through a [Public VM](../../../concepts/advanced/public_vm.md). This execution model is conceptually much simpler than the private transaction model as code is executed and proven on the sequencer.
+The public execution environment in Aztec takes place on the sequencer through a [Public VM](../../../learn/concepts/hybrid_state/public_vm.md). This execution model is conceptually much simpler than the private transaction model as code is executed and proven on the sequencer.
 
 Using the same example code and call stack from the section [above](#private----private-function-calls), we will walk through how it gets executed in public.
 
 The first key difference is that public functions are not compiled to circuits, rather they are compiled to `Aztec Bytecode` (might also be referred to as brillig).
 
-This bytecode is run by the sequencer in the `Aztec VM`, which is in turn proven by the [`Aztec VM circuit`](../../../concepts/advanced/public_vm.md).
+This bytecode is run by the sequencer in the `Aztec VM`, which is in turn proven by the [`Aztec VM circuit`](../../../learn/concepts/hybrid_state/public_vm.md).
 The mental model for public execution carries many of the same idea as are carried by Ethereum. Programs are compiled into a series of opcodes (known as bytecode). This bytecode is then executed. The extra step for the Aztec VM is that each opcode is then proven for correctness.
 
 Calling a public function from another public function is quite similar to what we saw for private to private, with the keyword private swapped for public.
@@ -203,7 +203,7 @@ Calling a public function from another public function is quite similar to what
 
 ### Private -> Public
 
-As discussed above, private function execution and calls take place on the user's device, while public function execution and calls take place on a sequencer, in two different places at two different times, it is natural to question how we can achieve composability between the two. The solution is asynchronicity. Further reading can be found in the foundational concepts [here](../../../concepts/foundation/communication/public_private_calls/main.md).
+As discussed above, private function execution and calls take place on the user's device, while public function execution and calls take place on a sequencer, in two different places at two different times, it is natural to question how we can achieve composability between the two. The solution is asynchronicity. Further reading can be found in the foundational concepts [here](../../../learn/concepts/communication/public_private_calls/main.md)).
 
 Private function execution takes place on the users device, where it keeps track of any public function calls that have been made. Whenever private execution completes, and a kernel proof is produced, the transaction sent to the network will include all of the public calls that were dispatched.
 When the sequencer receives the messages, it will take over and execute the public parts of the transaction.
@@ -249,7 +249,7 @@ Below, we go more into depth of what is happening under the hood when you create
 
 Aztec.nr uses an attribute system to annotate a function's type. Annotating a function with the `#[aztec(private)]` attribute tells the framework that this will be a private function that will be executed on a users device. Thus the compiler will create a circuit to define this function.
 
-However; `#aztec(private)` is just syntactic sugar. At compile time, the framework inserts code that allows the function to interact with the [kernel](../../../concepts/advanced/circuits/kernels/private_kernel.md).
+However; `#aztec(private)` is just syntactic sugar. At compile time, the framework inserts code that allows the function to interact with the [kernel](../../../learn/concepts/circuits/kernels/private_kernel.md).
 
 To help illustrate how this interacts with the internals of Aztec and its kernel circuits, we can take an example private function, and explore what it looks like after Aztec.nr's macro expansion.
 
@@ -263,12 +263,12 @@ To help illustrate how this interacts with the internals of Aztec and its kernel
 
 #### The expansion broken down?
 
-Viewing the expanded noir contract uncovers a lot about how noir contracts interact with the [kernel](../../../concepts/advanced/circuits/kernels/private_kernel.md). To aid with developing intuition, we will break down each inserted line.
+Viewing the expanded noir contract uncovers a lot about how noir contracts interact with the [kernel](../../../learn/concepts/circuits/kernels/private_kernel.md). To aid with developing intuition, we will break down each inserted line.
 
 **Receiving context from the kernel.**
 #include_code context-example-inputs /yarn-project/noir-contracts/contracts/docs_example_contract/src/main.nr rust
 
-Private function calls are able to interact with each other through orchestration from within the [kernel circuit](../../../concepts/advanced/circuits/kernels/private_kernel.md). The kernel circuit forwards information to each app circuit. This information then becomes part of the private context.
+Private function calls are able to interact with each other through orchestration from within the [kernel circuit](../../../learn/concepts/circuits/kernels/private_kernel.md). The kernel circuit forwards information to each app circuit. This information then becomes part of the private context.
 For example, within each circuit we can access some global variables. To access them we can call `context.chain_id()`. The value of this chain ID comes from the values passed into the circuit from the kernel.
 
 The kernel can then check that all of the values passed to each circuit in a function call are the same.
diff --git a/docs/docs/dev_docs/contracts/syntax/globals.md b/docs/docs/developers/contracts/syntax/globals.md
similarity index 100%
rename from docs/docs/dev_docs/contracts/syntax/globals.md
rename to docs/docs/developers/contracts/syntax/globals.md
diff --git a/docs/docs/dev_docs/contracts/syntax/historical_access/history_lib_reference.md b/docs/docs/developers/contracts/syntax/historical_access/history_lib_reference.md
similarity index 98%
rename from docs/docs/dev_docs/contracts/syntax/historical_access/history_lib_reference.md
rename to docs/docs/developers/contracts/syntax/historical_access/history_lib_reference.md
index b798a129243..d7688909262 100644
--- a/docs/docs/dev_docs/contracts/syntax/historical_access/history_lib_reference.md
+++ b/docs/docs/developers/contracts/syntax/historical_access/history_lib_reference.md
@@ -21,7 +21,7 @@ Note inclusion proves that a note existed (its hash was included in a note hash
 
 ## prove_note_commitment_inclusion
 
-A **commitment**, also referred to as a **note hash** is a public acknowledgment of the existence of a note without revealing the content of the note. You can learn more about how to compress a note to a note hash [here](../../../../concepts/advanced/data_structures/trees.md#example-note).
+A **commitment**, also referred to as a **note hash** is a public acknowledgment of the existence of a note without revealing the content of the note. You can learn more about how to compress a note to a note hash [here](../../../../learn/concepts/storage/trees/main.md#example-note).
 
 `prove_note_commitment_inclusion` takes 3 parameters:
 
diff --git a/docs/docs/dev_docs/contracts/syntax/historical_access/how_to_prove_history.md b/docs/docs/developers/contracts/syntax/historical_access/how_to_prove_history.md
similarity index 97%
rename from docs/docs/dev_docs/contracts/syntax/historical_access/how_to_prove_history.md
rename to docs/docs/developers/contracts/syntax/historical_access/how_to_prove_history.md
index 28e3ea04ccf..8441611dbf2 100644
--- a/docs/docs/dev_docs/contracts/syntax/historical_access/how_to_prove_history.md
+++ b/docs/docs/developers/contracts/syntax/historical_access/how_to_prove_history.md
@@ -2,7 +2,7 @@
 title: How to prove existence of historical notes and nullifiers
 ---
 
-The Aztec Protocol uses an append-only Merkle tree to store hashes of the headers of all previous blocks in the chain as its leaves. This is known as an archive tree. You can learn more about how it works in the [concepts section](../../../../concepts/advanced/data_structures/trees.md#archive-tree).
+The Aztec Protocol uses an append-only Merkle tree to store hashes of the headers of all previous blocks in the chain as its leaves. This is known as an archive tree. You can learn more about how it works in the [concepts section](../../../../learn/concepts/storage/trees/main.md#archive-tree).
 
 # History library
 
diff --git a/docs/docs/dev_docs/contracts/syntax/main.md b/docs/docs/developers/contracts/syntax/main.md
similarity index 100%
rename from docs/docs/dev_docs/contracts/syntax/main.md
rename to docs/docs/developers/contracts/syntax/main.md
diff --git a/docs/docs/dev_docs/contracts/syntax/oracles.md b/docs/docs/developers/contracts/syntax/oracles.md
similarity index 100%
rename from docs/docs/dev_docs/contracts/syntax/oracles.md
rename to docs/docs/developers/contracts/syntax/oracles.md
diff --git a/docs/docs/dev_docs/contracts/syntax/slow_updates_tree.md b/docs/docs/developers/contracts/syntax/slow_updates_tree.md
similarity index 98%
rename from docs/docs/dev_docs/contracts/syntax/slow_updates_tree.md
rename to docs/docs/developers/contracts/syntax/slow_updates_tree.md
index cfe7d5905f9..3f8538baeb9 100644
--- a/docs/docs/dev_docs/contracts/syntax/slow_updates_tree.md
+++ b/docs/docs/developers/contracts/syntax/slow_updates_tree.md
@@ -2,7 +2,7 @@
 title: Slow Updates Tree
 ---
 
-Slow Updates Tree is a data structure that allows for historical public data to be accessed in both private and public domains. Read the high level overview in the [concepts section](../../../concepts/foundation/communication/public_private_calls/slow_updates_tree.md).
+Slow Updates Tree is a data structure that allows for historical public data to be accessed in both private and public domains. Read the high level overview in the [Communication section](../../../learn/concepts/communication/public_private_calls/slow_updates_tree.md).
 
 The slow updates tree works by having a current tree and a pending tree, and replacing the current tree with the pending tree after an epoch has passed. Public functions can read directly from the current tree, and private functions can perform a membership proof that values are part of a commitment to the current state of the tree.
 
diff --git a/docs/docs/dev_docs/contracts/syntax/storage/main.md b/docs/docs/developers/contracts/syntax/storage/main.md
similarity index 94%
rename from docs/docs/dev_docs/contracts/syntax/storage/main.md
rename to docs/docs/developers/contracts/syntax/storage/main.md
index 89b61684fbb..7e9b382f82d 100644
--- a/docs/docs/dev_docs/contracts/syntax/storage/main.md
+++ b/docs/docs/developers/contracts/syntax/storage/main.md
@@ -23,7 +23,7 @@ On this and the following pages in this section, you’ll learn:
 
 Public state variables can be read by anyone, while private state variables can only be read by their owner (or people whom the owner has shared the decrypted data or note viewing key with).
 
-Public state follows the Ethereum style account model, where each contract has its own key-value datastore. Private state follows a UTXO model, where note contents (pre-images) are only known by the sender and those able to decrypt them - see ([state model](../../../../concepts/foundation/state_model/main.md) and [private/public execution](../../../../concepts/foundation/communication/public_private_calls/main.md)) for more background.
+Public state follows the Ethereum style account model, where each contract has its own key-value datastore. Private state follows a UTXO model, where note contents (pre-images) are only known by the sender and those able to decrypt them - see ([state model](../../../../learn/concepts/hybrid_state/main.md) and [private/public execution](../../../../learn/concepts/communication/public_private_calls/main.md)) for more background.
 
 ## Storage struct
 
@@ -128,6 +128,6 @@ require(minters[msg.sender], "caller is not minter");
 
 ## Concepts mentioned
 
-- [State Model](../../../../concepts/foundation/state_model/main.md)
-- [Public-private execution](../../../../concepts/foundation/communication/public_private_calls/main.md)
+- [Hybrid State Model](../../../../learn/concepts/hybrid_state/main.md)
+- [Public-private execution](../../../../learn/concepts/communication/public_private_calls/main.md)
 - [Function Contexts](../context.mdx)
diff --git a/docs/docs/dev_docs/contracts/syntax/storage/private_state.md b/docs/docs/developers/contracts/syntax/storage/private_state.md
similarity index 98%
rename from docs/docs/dev_docs/contracts/syntax/storage/private_state.md
rename to docs/docs/developers/contracts/syntax/storage/private_state.md
index c663f7c187f..e1b2064dfa0 100644
--- a/docs/docs/dev_docs/contracts/syntax/storage/private_state.md
+++ b/docs/docs/developers/contracts/syntax/storage/private_state.md
@@ -4,7 +4,7 @@ title: Private State
 
 On this page we will look at how to manage private state in Aztec contracts. We will look at how to declare private state, how to read and write to it, and how to use it in your contracts.
 
-For a higher level overview of the state model in Aztec, see the [state model](../../../../concepts/foundation/state_model/main.md) page, or jump back to the previous page on [Storage](./main.md).
+For a higher level overview of the state model in Aztec, see the [hybrid state model](../../../../learn/concepts/hybrid_state/main.md) page, or jump back to the previous page on [Storage](./main.md).
 
 ## Overview
 
@@ -12,7 +12,7 @@ In contrast to public state, private state is persistent state that is **not** v
 
 The value of a private state variable can either be shared via an [encrypted log](../events.md#encrypted-events), or offchain via web2, or completely offline: it's up to the app developer.
 
-Aztec private state follows a [utxo](https://en.wikipedia.org/wiki/Unspent_transaction_output)-based model. That is, a private state's current value is represented as one or many [notes](#notes). Each note is stored as an individual leaf in a utxo-based merkle tree: the [private state tree](../../../../concepts/advanced/data_structures/trees.md).
+Aztec private state follows a [utxo](https://en.wikipedia.org/wiki/Unspent_transaction_output)-based model. That is, a private state's current value is represented as one or many [notes](#notes). Each note is stored as an individual leaf in a utxo-based merkle tree: the [private state tree](../../../../learn/concepts/storage/trees/main.md).
 
 To greatly simplify the experience of writing private state, Aztec.nr provides three different types of private state variable:
 
diff --git a/docs/docs/dev_docs/contracts/syntax/storage/public_state.md b/docs/docs/developers/contracts/syntax/storage/public_state.md
similarity index 90%
rename from docs/docs/dev_docs/contracts/syntax/storage/public_state.md
rename to docs/docs/developers/contracts/syntax/storage/public_state.md
index 5ef81e3b44f..fa66f66ec6f 100644
--- a/docs/docs/dev_docs/contracts/syntax/storage/public_state.md
+++ b/docs/docs/developers/contracts/syntax/storage/public_state.md
@@ -4,7 +4,7 @@ title: Public State
 
 On this page we will look at how to manage public state in Aztec contracts. We will look at how to declare public state, how to read and write to it, and how to use it in your contracts.
 
-For a higher level overview of the state model in Aztec, see the [state model](../../../../concepts/foundation/state_model/main.md) page, or jump back to the previous page on [Storage](./main.md).
+For a higher level overview of the state model in Aztec, see the [state model](../../../../learn/concepts/hybrid_state/main.md) page, or jump back to the previous page on [Storage](./main.md).
 
 ## Overview
 
@@ -14,7 +14,7 @@ The `PublicState` struct is generic over the variable type `T` and its serialize
 Currently, the length of the types must be specified when declaring the storage struct but the intention is that this will be inferred in the future.
 :::
 
-The struct contains a `storage_slot` which, similar to Ethereum, is used to figure out _where_ in storage the variable is located. Notice that while we don't have the exact same [state model](../../../../concepts/foundation/state_model/main.md) as EVM chains it will look similar from the contract developers point of view.
+The struct contains a `storage_slot` which, similar to Ethereum, is used to figure out _where_ in storage the variable is located. Notice that while we don't have the exact same [state model](../../../../learn/concepts/hybrid_state/main.md) as EVM chains it will look similar from the contract developers point of view.
 
 Beyond the struct, the `PublicState` also contains `serialization_methods`, which is a struct with methods that instruct the `PublicState` how to serialize and deserialize the variable. You can find the details of `PublicState` in the implementation [here](https://github.com/AztecProtocol/aztec-packages/blob/#include_aztec_version/yarn-project/aztec-nr/aztec/src/state_vars/public_state.nr).
 
@@ -50,7 +50,7 @@ We know its verbose, and are working on making it less so.
 
 #### Mapping example
 
-Say we want to have a group of `minters` that are able to mint assets in our contract, and we want them in public storage, because [access control in private is quite cumbersome](../../../../concepts/foundation/communication/public_private_calls/main.md#a-note-on-l2-access-control). In the `Storage` struct we can add it as follows:
+Say we want to have a group of `minters` that are able to mint assets in our contract, and we want them in public storage, because [access control in private is quite cumbersome](../../../../learn/concepts/communication/cross_chain_calls.md#a-note-on-l2-access-control). In the `Storage` struct we can add it as follows:
 
 #include_code storage_minters /yarn-project/noir-contracts/contracts/token_contract/src/main.nr rust
 
diff --git a/docs/docs/dev_docs/contracts/syntax/storage/storage_slots.md b/docs/docs/developers/contracts/syntax/storage/storage_slots.md
similarity index 88%
rename from docs/docs/dev_docs/contracts/syntax/storage/storage_slots.md
rename to docs/docs/developers/contracts/syntax/storage/storage_slots.md
index dd8d1b01d18..af14fdeebfa 100644
--- a/docs/docs/dev_docs/contracts/syntax/storage/storage_slots.md
+++ b/docs/docs/developers/contracts/syntax/storage/storage_slots.md
@@ -2,7 +2,7 @@
 title: Storage slots
 ---
 
-From the description of [storage slot in concepts](./../../../../concepts/foundation/state_model/storage_slots.md) you will get an idea around the logic of storage slots. In this section we will go into more detail and walk through an entire example of how storage slots are computed for private state to improve our storage slot intuition. Recall, that storage slots in the private domain is just a logical construct, and are not "actually" used for lookups, but rather just as a value to constrain against.
+From the description of storage slots [in the Concepts](./../../../../learn/concepts/storage/storage_slots.md) you will get an idea around the logic of storage slots. In this section we will go into more detail and walk through an entire example of how storage slots are computed for private state to improve our storage slot intuition. Recall, that storage slots in the private domain is just a logical construct, and are not "actually" used for lookups, but rather just as a value to constrain against.
 
 For the case of the example, we will look at what is inserted into the note hashes tree when adding a note in the Token contract. Specifically, we are looking at the last part of the `transfer` function:
 
diff --git a/docs/docs/dev_docs/contracts/workflow.md b/docs/docs/developers/contracts/workflow.md
similarity index 100%
rename from docs/docs/dev_docs/contracts/workflow.md
rename to docs/docs/developers/contracts/workflow.md
diff --git a/docs/docs/dev_docs/debugging/aztecnr-errors.md b/docs/docs/developers/debugging/aztecnr-errors.md
similarity index 100%
rename from docs/docs/dev_docs/debugging/aztecnr-errors.md
rename to docs/docs/developers/debugging/aztecnr-errors.md
diff --git a/docs/docs/dev_docs/debugging/main.md b/docs/docs/developers/debugging/main.md
similarity index 100%
rename from docs/docs/dev_docs/debugging/main.md
rename to docs/docs/developers/debugging/main.md
diff --git a/docs/docs/dev_docs/debugging/sandbox-errors.md b/docs/docs/developers/debugging/sandbox-errors.md
similarity index 89%
rename from docs/docs/dev_docs/debugging/sandbox-errors.md
rename to docs/docs/developers/debugging/sandbox-errors.md
index f95925a4da2..6e1a92f154e 100644
--- a/docs/docs/dev_docs/debugging/sandbox-errors.md
+++ b/docs/docs/developers/debugging/sandbox-errors.md
@@ -13,7 +13,7 @@ This section contains a list of errors you may encounter when using Aztec Sandbo
 
 ### Kernel Circuits
 
-We have several versions of public and private kernels as explained in [our circuits section](../../concepts/advanced/circuits/kernels/main.md). Certain things are only possible in certain versions of the circuits. So always ensure that the right version is being used for proof generation. For example, there is a specific version of the public kernel that only works if the previous kernel iteration was a private kernel. Similarly there is one that only works if the previous kernel was public.
+We have several versions of public and private kernels as explained in [our circuits section](../../learn/concepts/circuits/main.md). Certain things are only possible in certain versions of the circuits. So always ensure that the right version is being used for proof generation. For example, there is a specific version of the public kernel that only works if the previous kernel iteration was a private kernel. Similarly there is one that only works if the previous kernel was public.
 
 Remember that for each function call (i.e. each item in the call stack), there is a new kernel iteration that gets run.
 
@@ -86,7 +86,7 @@ Calling a private Aztec.nr function in a public kernel is not allowed.
 
 #### 3005 - PUBLIC_KERNEL\_\_NON_EMPTY_PRIVATE_CALL_STACK
 
-Public functions are executed after all the private functions are (see [private-public execution](../../concepts/foundation/communication/public_private_calls/main.md)). As such, private call stack must be empty when executing in the public kernel.
+Public functions are executed after all the private functions are (see [private-public execution](../../learn/concepts/communication/public_private_calls/main.md)). As such, private call stack must be empty when executing in the public kernel.
 
 #### 3011 - PUBLIC_KERNEL\_\_CALCULATED_PRIVATE_CALL_HASH_AND_PROVIDED_PRIVATE_CALL_HASH_MISMATCH
 
@@ -130,7 +130,7 @@ For static calls, no new commitments or nullifiers can be added to the state.
 
 ### Rollup circuit errors
 
-These are errors that occur when kernel proofs (transaction proofs) are sent to the rollup circuits to create an L2 block. See [rollup circuits](../../concepts/advanced/circuits/rollup_circuits/main.md) for more information.
+These are errors that occur when kernel proofs (transaction proofs) are sent to the rollup circuits to create an L2 block. See [rollup circuits](../../learn/concepts/circuits/rollup_circuits/main.md) for more information.
 
 #### 4007 - BASE\_\_INVALID_CHAIN_ID
 
@@ -140,7 +140,7 @@ The L1 chain ID you used in your proof generation (for your private transaction)
 
 Same as [section 4007](#4007---base__invalid_chain_id) except the `version` refers to the version of the Aztec L2 instance.
 
-Some scary bugs like `4003 - BASE__INVALID_NULLIFIER_SUBTREE` and `4004 - BASE__INVALID_NULLIFIER_RANGE` which are to do malformed nullifier trees (see [Indexed Merkle Trees](../../concepts/advanced/data_structures/indexed_merkle_tree.md)) etc may seem unrelated at a glance, but at a closer look may be because of some bug in an application's Aztec.nr code. Same is true for certain instances of `7008 - MEMBERSHIP_CHECK_FAILED`.
+Some scary bugs like `4003 - BASE__INVALID_NULLIFIER_SUBTREE` and `4004 - BASE__INVALID_NULLIFIER_RANGE` which are to do malformed nullifier trees (see [Indexed Merkle Trees](../../learn/concepts/storage/trees/indexed_merkle_tree.md)) etc may seem unrelated at a glance, but at a closer look may be because of some bug in an application's Aztec.nr code. Same is true for certain instances of `7008 - MEMBERSHIP_CHECK_FAILED`.
 
 ### Generic circuit errors
 
@@ -171,7 +171,7 @@ Users may create a proof against a historical state in Aztec. The rollup circuit
 - using invalid historical L1 to L2 message data tree state
 - inserting a subtree into the greater tree
   - we make a smaller merkle tree of all the new commitments/nullifiers etc that were created in a transaction or in a rollup and add it to the bigger state tree. Before inserting, we do a merkle membership check to ensure that the index to insert at is indeed an empty subtree (otherwise we would be overwriting state). This can happen when `next_available_leaf_index` in the state tree's snapshot is wrong (it is fetched by the sequencer from the archiver). The error message should reveal which tree is causing this issue
-  - nullifier tree related errors - The nullifier tree uses an [Indexed Merkle Tree](../../concepts/advanced/data_structures/indexed_merkle_tree.md). It requires additional data from the archiver to know which is the nullifier in the tree that is just below the current nullifier before it can perform batch insertion. If the low nullifier is wrong, or the nullifier is in incorrect range, you may receive this error.
+  - nullifier tree related errors - The nullifier tree uses an [Indexed Merkle Tree](../../learn/concepts/storage/trees/indexed_merkle_tree.md). It requires additional data from the archiver to know which is the nullifier in the tree that is just below the current nullifier before it can perform batch insertion. If the low nullifier is wrong, or the nullifier is in incorrect range, you may receive this error.
 
 ---
 
@@ -191,7 +191,7 @@ Users may create a proof against a historical state in Aztec. The rollup circuit
 
 - "${treeName} tree next available leaf index mismatch" - validating a tree's root is not enough. It also checks that the `next_available_leaf_index` is as expected. This is the next index we can insert new values into. Note that for the public data tree, this test is skipped since as it is a sparse tree unlike the others.
 
-- "Public call stack size exceeded" - In Aztec, the sequencer executes all enqueued public functions in a transaction (to prevent race conditions - see [private-public execution](../../concepts/foundation/communication/public_private_calls/main.md)). This error says there are too many public functions requested.
+- "Public call stack size exceeded" - In Aztec, the sequencer executes all enqueued public functions in a transaction (to prevent race conditions - see [private-public execution](../../learn/concepts/communication/public_private_calls/main.md)). This error says there are too many public functions requested.
 
 - "Array size exceeds target length" - happens if you add more items than allowed by the constants set due to our circuit limitations (eg sending too many L2 to L1 messages or creating a function that exceeds the call stack length or returns more values than what Aztec.nr functions allow)
 
diff --git a/docs/docs/dev_docs/getting_started/aztecjs-getting-started.md b/docs/docs/developers/getting_started/aztecjs-getting-started.md
similarity index 97%
rename from docs/docs/dev_docs/getting_started/aztecjs-getting-started.md
rename to docs/docs/developers/getting_started/aztecjs-getting-started.md
index 637da709e60..d2f1fd6c2e6 100644
--- a/docs/docs/dev_docs/getting_started/aztecjs-getting-started.md
+++ b/docs/docs/developers/getting_started/aztecjs-getting-started.md
@@ -152,7 +152,7 @@ The sandbox is preloaded with multiple accounts so you don't have to sit and cre
 
 #include_code load_accounts /yarn-project/end-to-end/src/e2e_sandbox_example.test.ts typescript
 
-An explanation on accounts on Aztec can be found [here](../../concepts/foundation/accounts/main.md).
+An explanation on accounts on Aztec can be found [here](../../learn/concepts/accounts/main.md).
 
 If you want more accounts, you can find instructions in the [Account creation section](../wallets/creating_schnorr_accounts.md).
 
@@ -268,7 +268,7 @@ Now lets transfer some funds from Alice to Bob by calling the `transfer` functio
 1. The sender.
 2. The recipient.
 3. The quantity of tokens to be transferred.
-4. The nonce for the [authentication witness](../../concepts//foundation/accounts/main.md#authorizing-actions), or 0 if msg.sender equal sender.
+4. The nonce for the [authentication witness](../../learn//concepts/accounts/main.md#authorizing-actions), or 0 if msg.sender equal sender.
 
 Here is the Typescript code to call the `transfer` function, add this to your `index.ts` at the bottom of the `main` function:
 
@@ -371,7 +371,7 @@ Our complete output should now be something like:
   token Bob's balance 10543 +43ms
 ```
 
-That's it! We have successfully deployed a token contract to an instance of the Aztec network and mined private state-transitioning transactions. We have also queried the resulting state all via the interfaces provided by the contract. To see exactly what has happened here, you can learn about the transaction flow [here](../../concepts/foundation/transactions.md).
+That's it! We have successfully deployed a token contract to an instance of the Aztec network and mined private state-transitioning transactions. We have also queried the resulting state all via the interfaces provided by the contract. To see exactly what has happened here, you can learn about the transaction flow [here](../../learn/concepts/transactions.md).
 
 ## Next Steps
 
diff --git a/docs/docs/dev_docs/getting_started/aztecnr-getting-started.md b/docs/docs/developers/getting_started/aztecnr-getting-started.md
similarity index 97%
rename from docs/docs/dev_docs/getting_started/aztecnr-getting-started.md
rename to docs/docs/developers/getting_started/aztecnr-getting-started.md
index 27357e5640e..599c50d84e0 100644
--- a/docs/docs/dev_docs/getting_started/aztecnr-getting-started.md
+++ b/docs/docs/developers/getting_started/aztecnr-getting-started.md
@@ -223,7 +223,7 @@ Now you can explore.
 
 **Interested in learning more about how Aztec works under the hood?**
 
-Understand the high level architecture [here](../../concepts/foundation/main.md).
+Understand the high level architecture [here](../../learn/about_aztec/technical_overview.md).
 
 **Want to write more advanced smart contracts?**
 
@@ -231,4 +231,4 @@ Follow the token contract tutorial [here](../tutorials/writing_token_contract.md
 
 **Ready to dive into Aztec and Ethereum cross-chain communication?**
 
-Read the [Portals page](../../concepts/foundation/communication/cross_chain_calls.md) and learn how to practically implement portals in the [token bridge tutorial](../tutorials/token_portal/main.md).
+Read the [Portals page](../../learn/concepts/communication/cross_chain_calls.md) and learn how to practically implement portals in the [token bridge tutorial](../tutorials/token_portal/main.md).
diff --git a/docs/docs/dev_docs/getting_started/main.md b/docs/docs/developers/getting_started/main.md
similarity index 91%
rename from docs/docs/dev_docs/getting_started/main.md
rename to docs/docs/developers/getting_started/main.md
index f2f343b0c2e..0ee5ab59990 100644
--- a/docs/docs/dev_docs/getting_started/main.md
+++ b/docs/docs/developers/getting_started/main.md
@@ -12,7 +12,7 @@ If this is your first time using Aztec, and you want to get started by learning
 
 ## Learn
 
-If you want to read more about the high level concepts of Aztec before writing some code, head to the [Foundational Concepts section](../../concepts/foundation/main.md).
+If you want to read more about the high level concepts of Aztec before writing some code, head to the [Foundational Concepts section](../../learn/about_aztec/technical_overview.md).
 
 ## In this section
 
diff --git a/docs/docs/dev_docs/getting_started/quickstart.md b/docs/docs/developers/getting_started/quickstart.md
similarity index 100%
rename from docs/docs/dev_docs/getting_started/quickstart.md
rename to docs/docs/developers/getting_started/quickstart.md
diff --git a/docs/docs/dev_docs/limitations/main.md b/docs/docs/developers/limitations/main.md
similarity index 93%
rename from docs/docs/dev_docs/limitations/main.md
rename to docs/docs/developers/limitations/main.md
index bc28d3fd480..bc719c9307a 100644
--- a/docs/docs/dev_docs/limitations/main.md
+++ b/docs/docs/developers/limitations/main.md
@@ -54,7 +54,7 @@ That's right, the Sandbox doesn't actually generate or verify any zk-SNARKs yet!
 
 The main goal of the Sandbox is to enable developers to experiment with building apps, and hopefully to provide feedback. We want the developer experience to be as fast as possible, much like how Ethereum developers use Ganache or Anvil to get super-fast block times, instead of the slow-but-realistic 12-second block times that they'll encounter in production. A fast Sandbox enables fast testing, which enables developers to iterate quickly.
 
-That's not to say a super-fast proving system isn't being worked on [as we speak](../../about_aztec/roadmap/cryptography_roadmap.md).
+That's not to say a super-fast proving system isn't being worked on [as we speak](../../misc/roadmap/cryptography_roadmap.md).
 
 #### What are the consequences?
 
@@ -209,13 +209,13 @@ Not only are there limits on a _per function_ basis, there are also limits on a
 
 **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](../../concepts/advanced/circuits/kernels/main.md), and introducing a 'bus' to ferry varying lengths of data between kernel iterations. But that'll all take some time.
+There are plans to relax all of this rigidity, by providing many 'sizes' of [kernel circuit](../../learn/concepts/circuits/main.md), 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](../../concepts/advanced/circuits/kernels/private_kernel.md) 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.
+Each function call is represented by a circuit with a dedicated zero-knowledge proof of its execution. The [private kernel circuit](../../learn/concepts/circuits/kernels/private_kernel.md) 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.
 
@@ -243,7 +243,7 @@ Transaction output elements such as notes in encrypted logs, note hashes (commit
 
 ### 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](../../concepts/advanced/circuits/kernels/private_kernel.md) and is never stored in any persistent data tree.
+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](../../learn/concepts/circuits/kernels/private_kernel.md) 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](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](https://github.com/AztecProtocol/aztec-packages/issues/1641).
diff --git a/docs/docs/dev_docs/privacy/main.md b/docs/docs/developers/privacy/main.md
similarity index 100%
rename from docs/docs/dev_docs/privacy/main.md
rename to docs/docs/developers/privacy/main.md
diff --git a/docs/docs/dev_docs/testing/cheat_codes.md b/docs/docs/developers/testing/cheat_codes.md
similarity index 100%
rename from docs/docs/dev_docs/testing/cheat_codes.md
rename to docs/docs/developers/testing/cheat_codes.md
diff --git a/docs/docs/dev_docs/testing/main.md b/docs/docs/developers/testing/main.md
similarity index 100%
rename from docs/docs/dev_docs/testing/main.md
rename to docs/docs/developers/testing/main.md
diff --git a/docs/docs/dev_docs/tutorials/main.md b/docs/docs/developers/tutorials/main.md
similarity index 100%
rename from docs/docs/dev_docs/tutorials/main.md
rename to docs/docs/developers/tutorials/main.md
diff --git a/docs/docs/dev_docs/tutorials/testing.md b/docs/docs/developers/tutorials/testing.md
similarity index 95%
rename from docs/docs/dev_docs/tutorials/testing.md
rename to docs/docs/developers/tutorials/testing.md
index ca2d015bd90..3b19d4c3bb7 100644
--- a/docs/docs/dev_docs/tutorials/testing.md
+++ b/docs/docs/developers/tutorials/testing.md
@@ -154,7 +154,7 @@ To query storage directly, you'll need to know the slot you want to access. This
 
 #### Querying private state
 
-Private state in the Aztec Network is represented via sets of [private notes](../../concepts/foundation/state_model/main.md#private-state). In our token contract example, the balance of a user is represented as a set of unspent value notes, each with their own corresponding numeric value.
+Private state in the Aztec Network is represented via sets of [private notes](../../learn/concepts/hybrid_state/main.md#private-state). In our token contract example, the balance of a user is represented as a set of unspent value notes, each with their own corresponding numeric value.
 
 #include_code value-note-def yarn-project/aztec-nr/value-note/src/value_note.nr rust
 
@@ -164,7 +164,7 @@ We can query the Private eXecution Environment (PXE) for all notes encrypted for
 
 #### Querying public state
 
-[Public state](../../concepts/foundation/state_model/main.md#public-state) behaves as a key-value store, much like in the EVM. This scenario is much more straightforward, in that we can directly query the target slot and get the result back as a buffer. Note that we use the [`TokenContract`](https://github.com/AztecProtocol/aztec-packages/blob/master/yarn-project/noir-contracts/contracts/token_contract/src/main.nr) in this example, which defines a mapping of public balances on slot 6.
+[Public state](../../learn/concepts/hybrid_state/main.md#public-state) behaves as a key-value store, much like in the EVM. This scenario is much more straightforward, in that we can directly query the target slot and get the result back as a buffer. Note that we use the [`TokenContract`](https://github.com/AztecProtocol/aztec-packages/blob/master/yarn-project/noir-contracts/contracts/token_contract/src/main.nr) in this example, which defines a mapping of public balances on slot 6.
 
 #include_code public-storage /yarn-project/end-to-end/src/guides/dapp_testing.test.ts typescript
 
diff --git a/docs/docs/dev_docs/tutorials/token_portal/cancelling_deposits.md b/docs/docs/developers/tutorials/token_portal/cancelling_deposits.md
similarity index 100%
rename from docs/docs/dev_docs/tutorials/token_portal/cancelling_deposits.md
rename to docs/docs/developers/tutorials/token_portal/cancelling_deposits.md
diff --git a/docs/docs/dev_docs/tutorials/token_portal/depositing_to_aztec.md b/docs/docs/developers/tutorials/token_portal/depositing_to_aztec.md
similarity index 100%
rename from docs/docs/dev_docs/tutorials/token_portal/depositing_to_aztec.md
rename to docs/docs/developers/tutorials/token_portal/depositing_to_aztec.md
diff --git a/docs/docs/dev_docs/tutorials/token_portal/main.md b/docs/docs/developers/tutorials/token_portal/main.md
similarity index 97%
rename from docs/docs/dev_docs/tutorials/token_portal/main.md
rename to docs/docs/developers/tutorials/token_portal/main.md
index 5e9caf8ce54..5739d5b81aa 100644
--- a/docs/docs/dev_docs/tutorials/token_portal/main.md
+++ b/docs/docs/developers/tutorials/token_portal/main.md
@@ -35,7 +35,7 @@ Aztec has the following core smart contracts on L1 that we need to know about:
 - `Outbox.sol` - a mailbox to the rollup for L2 to L1 messages (e.g. withdrawing tokens). Aztec contracts emit these messages and the sequencer adds these to the outbox. Portals then consume these messages.
 - `Registry.sol` - just like L1, we assume there will be various versions of Aztec (due to upgrades, forks etc). In such a case messages must not be replayable in other Aztec “domains”. A portal must decide which version/ID of Aztec the message is for. The registry stores the rollup, inbox and outbox address for each version of Aztec deployments, so the portal can find out the address of the mailbox it wants to talk to
 
-For more information, read [cross-chain calls](../../../concepts/foundation/communication/cross_chain_calls).
+For more information, read [cross-chain calls](../../../learn/concepts/communication/cross_chain_calls).
 
 ## Building a Token Bridge with Portals
 
diff --git a/docs/docs/dev_docs/tutorials/token_portal/minting_on_aztec.md b/docs/docs/developers/tutorials/token_portal/minting_on_aztec.md
similarity index 100%
rename from docs/docs/dev_docs/tutorials/token_portal/minting_on_aztec.md
rename to docs/docs/developers/tutorials/token_portal/minting_on_aztec.md
diff --git a/docs/docs/dev_docs/tutorials/token_portal/setup.md b/docs/docs/developers/tutorials/token_portal/setup.md
similarity index 97%
rename from docs/docs/dev_docs/tutorials/token_portal/setup.md
rename to docs/docs/developers/tutorials/token_portal/setup.md
index 3f738e02fc0..fc5d141381a 100644
--- a/docs/docs/dev_docs/tutorials/token_portal/setup.md
+++ b/docs/docs/developers/tutorials/token_portal/setup.md
@@ -19,7 +19,7 @@ However if you’d rather skip this part, our dev-rels repo contains the starter
 
 - [node v18+](https://github.com/tj/n)
 - [docker](https://docs.docker.com/)
-- [Aztec sandbox](https://docs.aztec.network/dev_docs/getting_started/sandbox) - you should have this running before starting the tutorial
+- [Aztec sandbox](https://docs.aztec.network/developers/getting_started/sandbox) - you should have this running before starting the tutorial
 - [Aztec CLI](../../getting_started/quickstart.md)
 
 ```bash
diff --git a/docs/docs/dev_docs/tutorials/token_portal/typescript_glue_code.md b/docs/docs/developers/tutorials/token_portal/typescript_glue_code.md
similarity index 100%
rename from docs/docs/dev_docs/tutorials/token_portal/typescript_glue_code.md
rename to docs/docs/developers/tutorials/token_portal/typescript_glue_code.md
diff --git a/docs/docs/dev_docs/tutorials/token_portal/withdrawing_to_l1.md b/docs/docs/developers/tutorials/token_portal/withdrawing_to_l1.md
similarity index 93%
rename from docs/docs/dev_docs/tutorials/token_portal/withdrawing_to_l1.md
rename to docs/docs/developers/tutorials/token_portal/withdrawing_to_l1.md
index 8716421c10b..ff0be84bb85 100644
--- a/docs/docs/dev_docs/tutorials/token_portal/withdrawing_to_l1.md
+++ b/docs/docs/developers/tutorials/token_portal/withdrawing_to_l1.md
@@ -17,7 +17,7 @@ For this to work we import the `get_withdraw_content_hash` helper function from
 The `exit_to_l1_public` function enables anyone to withdraw their L2 tokens back to L1 publicly. This is done by burning tokens on L2 and then creating an L2->L1 message.
 
 1. Like with our deposit function, we need to create the L2 to L1 message. The content is the _amount_ to burn, the recipient address, and who can execute the withdraw on the L1 portal on behalf of the user. It can be `0x0` for anyone, or a specified address.
-2. `context.message_portal()` passes this content to the [kernel circuit](../../../concepts/advanced/circuits/kernels/public_kernel.md) which creates the proof for the transaction. The kernel circuit then adds the sender (the L2 address of the bridge + version of aztec) and the recipient (the portal to the L2 address + the chain ID of L1) under the hood, to create the message which gets added as rollup calldata by the sequencer and is stored in the outbox for consumption.
+2. `context.message_portal()` passes this content to the [kernel circuit](../../../learn/concepts/circuits/kernels/public_kernel.md) which creates the proof for the transaction. The kernel circuit then adds the sender (the L2 address of the bridge + version of aztec) and the recipient (the portal to the L2 address + the chain ID of L1) under the hood, to create the message which gets added as rollup calldata by the sequencer and is stored in the outbox for consumption.
 3. Finally, you also burn the tokens on L2! Note that it burning is done at the end to follow the check effects interaction pattern. Note that the caller has to first approve the bridge contract to burn tokens on its behalf. Refer to [burn_public function on the token contract](../writing_token_contract.md#burn_public). The nonce parameter refers to the approval message that the user creates - also refer to [authorizing token spends here](../writing_token_contract.md#authorizing-token-spends).
    - We burn the tokens from the `msg_sender()`. Otherwise, a malicious user could burn someone else’s tokens and mint tokens on L1 to themselves. One could add another approval flow on the bridge but that might make it complex for other applications to call the bridge.
 
diff --git a/docs/docs/dev_docs/tutorials/uniswap/execute_private_swap_on_l1.md b/docs/docs/developers/tutorials/uniswap/execute_private_swap_on_l1.md
similarity index 100%
rename from docs/docs/dev_docs/tutorials/uniswap/execute_private_swap_on_l1.md
rename to docs/docs/developers/tutorials/uniswap/execute_private_swap_on_l1.md
diff --git a/docs/docs/dev_docs/tutorials/uniswap/execute_public_swap_on_l1.md b/docs/docs/developers/tutorials/uniswap/execute_public_swap_on_l1.md
similarity index 100%
rename from docs/docs/dev_docs/tutorials/uniswap/execute_public_swap_on_l1.md
rename to docs/docs/developers/tutorials/uniswap/execute_public_swap_on_l1.md
diff --git a/docs/docs/dev_docs/tutorials/uniswap/l1_portal.md b/docs/docs/developers/tutorials/uniswap/l1_portal.md
similarity index 100%
rename from docs/docs/dev_docs/tutorials/uniswap/l1_portal.md
rename to docs/docs/developers/tutorials/uniswap/l1_portal.md
diff --git a/docs/docs/dev_docs/tutorials/uniswap/l2_contract_setup.md b/docs/docs/developers/tutorials/uniswap/l2_contract_setup.md
similarity index 100%
rename from docs/docs/dev_docs/tutorials/uniswap/l2_contract_setup.md
rename to docs/docs/developers/tutorials/uniswap/l2_contract_setup.md
diff --git a/docs/docs/dev_docs/tutorials/uniswap/main.md b/docs/docs/developers/tutorials/uniswap/main.md
similarity index 100%
rename from docs/docs/dev_docs/tutorials/uniswap/main.md
rename to docs/docs/developers/tutorials/uniswap/main.md
diff --git a/docs/docs/dev_docs/tutorials/uniswap/redeeming_swapped_assets_on_l2.md b/docs/docs/developers/tutorials/uniswap/redeeming_swapped_assets_on_l2.md
similarity index 100%
rename from docs/docs/dev_docs/tutorials/uniswap/redeeming_swapped_assets_on_l2.md
rename to docs/docs/developers/tutorials/uniswap/redeeming_swapped_assets_on_l2.md
diff --git a/docs/docs/dev_docs/tutorials/uniswap/setup.md b/docs/docs/developers/tutorials/uniswap/setup.md
similarity index 100%
rename from docs/docs/dev_docs/tutorials/uniswap/setup.md
rename to docs/docs/developers/tutorials/uniswap/setup.md
diff --git a/docs/docs/dev_docs/tutorials/uniswap/swap_privately.md b/docs/docs/developers/tutorials/uniswap/swap_privately.md
similarity index 100%
rename from docs/docs/dev_docs/tutorials/uniswap/swap_privately.md
rename to docs/docs/developers/tutorials/uniswap/swap_privately.md
diff --git a/docs/docs/dev_docs/tutorials/uniswap/swap_publicly.md b/docs/docs/developers/tutorials/uniswap/swap_publicly.md
similarity index 100%
rename from docs/docs/dev_docs/tutorials/uniswap/swap_publicly.md
rename to docs/docs/developers/tutorials/uniswap/swap_publicly.md
diff --git a/docs/docs/dev_docs/tutorials/uniswap/typescript_glue_code.md b/docs/docs/developers/tutorials/uniswap/typescript_glue_code.md
similarity index 100%
rename from docs/docs/dev_docs/tutorials/uniswap/typescript_glue_code.md
rename to docs/docs/developers/tutorials/uniswap/typescript_glue_code.md
diff --git a/docs/docs/dev_docs/tutorials/writing_dapp/contract_deployment.md b/docs/docs/developers/tutorials/writing_dapp/contract_deployment.md
similarity index 100%
rename from docs/docs/dev_docs/tutorials/writing_dapp/contract_deployment.md
rename to docs/docs/developers/tutorials/writing_dapp/contract_deployment.md
diff --git a/docs/docs/dev_docs/tutorials/writing_dapp/contract_interaction.md b/docs/docs/developers/tutorials/writing_dapp/contract_interaction.md
similarity index 93%
rename from docs/docs/dev_docs/tutorials/writing_dapp/contract_interaction.md
rename to docs/docs/developers/tutorials/writing_dapp/contract_interaction.md
index 73c0eef546c..058fa3483f5 100644
--- a/docs/docs/dev_docs/tutorials/writing_dapp/contract_interaction.md
+++ b/docs/docs/developers/tutorials/writing_dapp/contract_interaction.md
@@ -93,12 +93,12 @@ At the time of this writing, there are no events emitted when new private notes
 
 ## Working with public state
 
-While [private and public state](../../../concepts/foundation/state_model/main.md) are fundamentally different, the API for working with private and public functions and state from `aztec.js` is equivalent. To query the balance in public tokens for our user accounts, we can just call the `balance_of_public` view function in the contract:
+While [private and public state](../../../learn/concepts/hybrid_state/main.md) are fundamentally different, the API for working with private and public functions and state from `aztec.js` is equivalent. To query the balance in public tokens for our user accounts, we can just call the `balance_of_public` view function in the contract:
 
 #include_code showPublicBalances yarn-project/end-to-end/src/sample-dapp/index.mjs javascript
 
 :::info
-Since this we are working with pubic balances, we can now query the balance for any address, not just those registered in our local PXE. We can also send funds to addresses for which we don't know their [public encryption key](../../../concepts/foundation/accounts/keys.md#encryption-keys).
+Since this we are working with pubic balances, we can now query the balance for any address, not just those registered in our local PXE. We can also send funds to addresses for which we don't know their [public encryption key](../../../learn/concepts/accounts/keys.md#encryption-keys).
 :::
 
 Here, since the token contract does not mint any initial funds upon deployment, the balances for all of our user's accounts will be zero.
diff --git a/docs/docs/dev_docs/tutorials/writing_dapp/main.md b/docs/docs/developers/tutorials/writing_dapp/main.md
similarity index 100%
rename from docs/docs/dev_docs/tutorials/writing_dapp/main.md
rename to docs/docs/developers/tutorials/writing_dapp/main.md
diff --git a/docs/docs/dev_docs/tutorials/writing_dapp/project_setup.md b/docs/docs/developers/tutorials/writing_dapp/project_setup.md
similarity index 100%
rename from docs/docs/dev_docs/tutorials/writing_dapp/project_setup.md
rename to docs/docs/developers/tutorials/writing_dapp/project_setup.md
diff --git a/docs/docs/dev_docs/tutorials/writing_dapp/pxe_service.md b/docs/docs/developers/tutorials/writing_dapp/pxe_service.md
similarity index 100%
rename from docs/docs/dev_docs/tutorials/writing_dapp/pxe_service.md
rename to docs/docs/developers/tutorials/writing_dapp/pxe_service.md
diff --git a/docs/docs/dev_docs/tutorials/writing_dapp/testing.md b/docs/docs/developers/tutorials/writing_dapp/testing.md
similarity index 98%
rename from docs/docs/dev_docs/tutorials/writing_dapp/testing.md
rename to docs/docs/developers/tutorials/writing_dapp/testing.md
index 7178e895b6e..6e835783d3d 100644
--- a/docs/docs/dev_docs/tutorials/writing_dapp/testing.md
+++ b/docs/docs/developers/tutorials/writing_dapp/testing.md
@@ -67,4 +67,4 @@ yarn node --experimental-vm-modules $(yarn bin jest) --testRegex '.*\.test\.mjs$
 
 ## Next steps
 
-Now that you have finished the tutorial, you can learn more about [writing contracts with Noir](../../contracts/main.md) or read about the [fundamental concepts behind Aztec Network](../../../concepts/foundation/main.md).
+Now that you have finished the tutorial, you can learn more about [writing contracts with Noir](../../contracts/main.md) or read about the [fundamental concepts behind Aztec Network](../../../learn/about_aztec/technical_overview.md).
diff --git a/docs/docs/dev_docs/tutorials/writing_private_voting_contract.md b/docs/docs/developers/tutorials/writing_private_voting_contract.md
similarity index 97%
rename from docs/docs/dev_docs/tutorials/writing_private_voting_contract.md
rename to docs/docs/developers/tutorials/writing_private_voting_contract.md
index c8ab1e70f64..82f46f860de 100644
--- a/docs/docs/dev_docs/tutorials/writing_private_voting_contract.md
+++ b/docs/docs/developers/tutorials/writing_private_voting_contract.md
@@ -107,7 +107,7 @@ This `init` function will be called every time we access `storage` in our functi
 
 The next step is to initialize the contract with a constructor. The constructor will take an address as a parameter and set the admin.
 
-All constructors must be private, and because the admin is in public storage, we cannot directly update it from the constructor. You can find more information about this [here](../../concepts/foundation/communication/public_private_calls/main.md).
+All constructors must be private, and because the admin is in public storage, we cannot directly update it from the constructor. You can find more information about this [here](../../learn/concepts/communication/public_private_calls/main.md).
 
 Therefore our constructor must call a public function by using `context.call_public_function()`. Paste this under the `impl` storage block:
 
@@ -141,7 +141,7 @@ Create a private function called `cast_vote`:
 
 #include_code cast_vote yarn-project/noir-contracts/contracts/easy_private_voting_contract/src/main.nr rust
 
-In this function, we do not create a nullifier with the address directly. This would leak privacy as it would be easy to reverse-engineer. We must add some randomness or some form of secret, like [nullifier secrets](../../concepts/foundation/accounts/keys.md#nullifier-secrets).
+In this function, we do not create a nullifier with the address directly. This would leak privacy as it would be easy to reverse-engineer. We must add some randomness or some form of secret, like [nullifier secrets](../../learn/concepts/accounts/keys.md#nullifier-secrets).
 
 To do this, we make an [oracle call](../contracts/syntax/functions.md#oracle-functions) to fetch the caller's secret key, hash it to create a nullifier, and push the nullifier to Aztec. The `secret.high` and `secret.low` values here refer to how we divide a large [Grumpkin scalar](https://github.com/AztecProtocol/aztec-packages/blob/7fb35874eae3f2cad5cb922282a619206573592c/noir/noir_stdlib/src/grumpkin_scalar.nr) value into its higher and lower parts. This allows for faster cryptographic computations so our hash can still be secure but is calculated faster.
 
@@ -163,7 +163,7 @@ We will create a function that anyone can call that will return the number of vo
 
 #include_code get_vote yarn-project/noir-contracts/contracts/easy_private_voting_contract/src/main.nr rust
 
-We set it as `unconstrained` and do not annotate it because it is only reading from state. You can read more about unconstrained functions [here](../../concepts/advanced/acir_simulator.md#unconstrained-functions).
+We set it as `unconstrained` and do not annotate it because it is only reading from state. You can read more about unconstrained functions [here](../../learn/concepts/pxe/acir_simulator.md#unconstrained-functions).
 
 ## Allowing an admin to end a voting period
 
diff --git a/docs/docs/dev_docs/tutorials/writing_token_contract.md b/docs/docs/developers/tutorials/writing_token_contract.md
similarity index 97%
rename from docs/docs/dev_docs/tutorials/writing_token_contract.md
rename to docs/docs/developers/tutorials/writing_token_contract.md
index f4fda400456..fe3b71421e4 100644
--- a/docs/docs/dev_docs/tutorials/writing_token_contract.md
+++ b/docs/docs/developers/tutorials/writing_token_contract.md
@@ -155,7 +155,7 @@ These are functions that have transparent logic, will execute in a publicly veri
 
 ### Private functions
 
-These are functions that have private logic and will be executed on user devices to maintain privacy. The only data that is submitted to the network is a proof of correct execution, new data [commitments](https://en.wikipedia.org/wiki/Commitment_scheme) and [nullifiers](../../concepts/advanced/data_structures/trees#nullifier-tree), so users will not reveal which contract they are interacting with or which function they are executing. The only information that will be revealed publicly is that someone executed a private transaction on Aztec.
+These are functions that have private logic and will be executed on user devices to maintain privacy. The only data that is submitted to the network is a proof of correct execution, new data [commitments](https://en.wikipedia.org/wiki/Commitment_scheme) and [nullifiers](../../learn/concepts/storage/trees/main.md#nullifier-tree), so users will not reveal which contract they are interacting with or which function they are executing. The only information that will be revealed publicly is that someone executed a private transaction on Aztec.
 
 - `redeem_shield` enables accounts to claim tokens that have been made private via `mint_private` or `shield` by providing the secret
 - `unshield` enables an account to send tokens from their private balance to any other account's public balance
@@ -208,11 +208,11 @@ Just below the contract definition, add the following imports:
 
 #include_code imports /yarn-project/noir-contracts/contracts/token_contract/src/main.nr rust
 
-We are importing the Option type, items from the `value_note` library to help manage private value storage, note utilities, context (for managing private and public execution contexts), `state_vars` for helping manage state, `types` for data manipulation and `oracle` for help passing data from the private to public execution context. We also import the `auth` [library](https://github.com/AztecProtocol/aztec-packages/blob/#include_aztec_version/yarn-project/aztec-nr/aztec/src/auth.nr) to handle token authorizations from [Account Contracts](../../concepts/foundation/accounts/main). Check out the Account Contract with AuthWitness [here](https://github.com/AztecProtocol/aztec-packages/blob/#include_aztec_version/yarn-project/noir-contracts/contracts/schnorr_single_key_account_contract/src/main.nr).
+We are importing the Option type, items from the `value_note` library to help manage private value storage, note utilities, context (for managing private and public execution contexts), `state_vars` for helping manage state, `types` for data manipulation and `oracle` for help passing data from the private to public execution context. We also import the `auth` [library](https://github.com/AztecProtocol/aztec-packages/blob/#include_aztec_version/yarn-project/aztec-nr/aztec/src/auth.nr) to handle token authorizations from [Account Contracts](../../learn/concepts/accounts/main). Check out the Account Contract with AuthWitness [here](https://github.com/AztecProtocol/aztec-packages/blob/#include_aztec_version/yarn-project/noir-contracts/contracts/schnorr_single_key_account_contract/src/main.nr).
 
 [SafeU120](https://github.com/AztecProtocol/aztec-packages/blob/#include_aztec_version/yarn-project/aztec-nr/safe-math/src/safe_u120.nr) is a library to do safe math operations on unsigned integers that protects against overflows and underflows.
 
-For more detail on execution contexts, see [Contract Communication](../../concepts/foundation/communication/main).
+For more detail on execution contexts, see [Contract Communication](../../learn/concepts/communication/main).
 
 ### Types files
 
diff --git a/docs/docs/dev_docs/updating.md b/docs/docs/developers/updating.md
similarity index 96%
rename from docs/docs/dev_docs/updating.md
rename to docs/docs/developers/updating.md
index e9f0b54abcc..6e9a3b47d57 100644
--- a/docs/docs/dev_docs/updating.md
+++ b/docs/docs/developers/updating.md
@@ -19,7 +19,7 @@ cd your/aztec/project
 aztec-cli update . --contract src/contract1 --contract src/contract2
 ```
 
-The sandbox must be running for the update command to work. Make sure it is [installed and running](../dev_docs/cli/sandbox-reference.md).
+The sandbox must be running for the update command to work. Make sure it is [installed and running](../developers/cli/sandbox-reference.md).
 
 3. Refer [Migration Notes](../misc/migration_notes.md) on any breaking changes that might affect your dapp
 
diff --git a/docs/docs/dev_docs/wallets/architecture.md b/docs/docs/developers/wallets/architecture.md
similarity index 80%
rename from docs/docs/dev_docs/wallets/architecture.md
rename to docs/docs/developers/wallets/architecture.md
index 7785d43e41b..3d010fd3267 100644
--- a/docs/docs/dev_docs/wallets/architecture.md
+++ b/docs/docs/developers/wallets/architecture.md
@@ -8,7 +8,7 @@ Architecture-wise, a wallet is an instance of an **Private Execution Environment
 The PXE also communicates with an **Aztec Node** for retrieving public information or broadcasting transactions.
 Note that the PXE requires a local database for keeping private state, and is also expected to be continuously syncing new blocks for trial-decryption of user notes.
 
-Additionally, a wallet must be able to handle one or more [account contract implementations](../../concepts/foundation/accounts/main.md#account-contracts-and-wallets). When a user creates a new account, the account is represented on-chain by an account contract. The wallet is responsible for deploying and interacting with this contract. A wallet may support multiple flavours of accounts, such as an account that uses ECDSA signatures, or one that relies on WebAuthn, or one that requires multi-factor authentication. For a user, the choice of what account implementation to use is then determined by the wallet they interact with.
+Additionally, a wallet must be able to handle one or more [account contract implementations](../../learn/concepts/accounts/main.md#account-contracts-and-wallets). When a user creates a new account, the account is represented on-chain by an account contract. The wallet is responsible for deploying and interacting with this contract. A wallet may support multiple flavours of accounts, such as an account that uses ECDSA signatures, or one that relies on WebAuthn, or one that requires multi-factor authentication. For a user, the choice of what account implementation to use is then determined by the wallet they interact with.
 
 In code, this translates to a wallet implementing an **AccountInterface** interface that defines [how to create an _execution request_ out of an array of _function calls_](./main.md#transaction-lifecycle) for the specific implementation of an account contract and [how to generate an _auth witness_](./main.md#authorizing-actions) for authorizing actions on behalf of the user. Think of this interface as the Javascript counterpart of an account contract, or the piece of code that knows how to format a transaction and authenticate an action based on the rules defined by the user's account contract implementation.
 
diff --git a/docs/docs/dev_docs/wallets/creating_schnorr_accounts.md b/docs/docs/developers/wallets/creating_schnorr_accounts.md
similarity index 96%
rename from docs/docs/dev_docs/wallets/creating_schnorr_accounts.md
rename to docs/docs/developers/wallets/creating_schnorr_accounts.md
index d4dfa04e2c3..636bf8df4af 100644
--- a/docs/docs/dev_docs/wallets/creating_schnorr_accounts.md
+++ b/docs/docs/developers/wallets/creating_schnorr_accounts.md
@@ -6,7 +6,7 @@ title: Creating Schnorr Accounts
 
 This section shows how to create schnorr account wallets on the Aztec Sandbox.
 
-An in-depth explaining about accounts on aztec can be found [here](../../concepts/foundation/accounts/main.md). But creating an account on the Sandbox does 2 things:
+An in-depth explaining about accounts on aztec can be found [here](../../learn/concepts/accounts/main.md). But creating an account on the Sandbox does 2 things:
 
 1. Deploys an account contract -- representing you -- allowing you to perform actions on the network (deploy contracts, call functions etc).
 2. Adds your encryption keys to the Private eXecution Environment (PXE) allowing it to decrypt and manage your private state.
diff --git a/docs/docs/dev_docs/wallets/main.md b/docs/docs/developers/wallets/main.md
similarity index 75%
rename from docs/docs/dev_docs/wallets/main.md
rename to docs/docs/developers/wallets/main.md
index 898acb41c55..6e458d8241d 100644
--- a/docs/docs/dev_docs/wallets/main.md
+++ b/docs/docs/developers/wallets/main.md
@@ -10,17 +10,17 @@ In this page we will cover the main responsibilities of a wallet in the Aztec ne
 
 ## Account setup
 
-The first step for any wallet is to let the user set up their [accounts](../../concepts/foundation/accounts/main.md). An account in Aztec is represented on-chain by its corresponding account contract that the user must deploy to begin interacting with the network. This account contract dictates how transactions are authenticated and executed.
+The first step for any wallet is to let the user set up their [accounts](../../learn/concepts/accounts/main.md). An account in Aztec is represented on-chain by its corresponding account contract that the user must deploy to begin interacting with the network. This account contract dictates how transactions are authenticated and executed.
 
 A wallet must support at least one specific [account contract implementation](./writing_an_account_contract.md), which means being able to deploy such a contract, as well as interacting with it when sending transactions. Code-wise, this requires [implementing the `AccountContract` interface](https://github.com/AztecProtocol/aztec-packages/blob/master/yarn-project/aztec.js/src/account_contract/index.ts).
 
-Note that users must be able to receive funds in Aztec before deploying their account. A wallet should let a user generate a [deterministic complete address](../../concepts/foundation/accounts/keys.md#addresses-partial-addresses-and-public-keys) without having to interact with the network, so they can share it with others to receive funds. This requires that the wallet pins a specific contract implementation, its initialization arguments, a deployment salt, and a privacy key. These values yield a deterministic address, so when the account contract is actually deployed, it is available at the precalculated address. Once the account contract is deployed, the user can start sending transactions using it as the transaction origin.
+Note that users must be able to receive funds in Aztec before deploying their account. A wallet should let a user generate a [deterministic complete address](../../learn/concepts/accounts/keys.md#addresses-partial-addresses-and-public-keys) without having to interact with the network, so they can share it with others to receive funds. This requires that the wallet pins a specific contract implementation, its initialization arguments, a deployment salt, and a privacy key. These values yield a deterministic address, so when the account contract is actually deployed, it is available at the precalculated address. Once the account contract is deployed, the user can start sending transactions using it as the transaction origin.
 
 ## Transaction lifecycle
 
 Every transaction in Aztec is broadcast to the network as a zero-knowledge proof of correct execution, in order to preserve privacy. This means that transaction proofs are generated on the wallet and not on a remote node. This is one of the biggest differences with regard to EVM chain wallets.
 
-A wallet is responsible for **creating** an [_execution request_](https://github.com/AztecProtocol/aztec-packages/blob/master/yarn-project/types/src/tx_execution_request.ts) out of one or more [_function calls_](https://github.com/AztecProtocol/aztec-packages/blob/master/yarn-project/types/src/function_call.ts) requested by a dapp. For example, a dapp may request a wallet to "invoke the `transfer` function on the contract at `0x1234` with the following arguments", in response to a user action. The wallet [turns that into an execution request](../../concepts/foundation/accounts/main.md#execution-requests) with the signed instructions to execute that function call from the user's account contract. In an [ECDSA-based account](https://github.com/AztecProtocol/aztec-packages/blob/master/yarn-project/noir-contracts/contracts/ecdsa_account_contract/src/main.nr), for instance, this is an execution request that encodes the function call in the _entrypoint payload_, and includes its ECDSA signature with the account's signing private key.
+A wallet is responsible for **creating** an [_execution request_](https://github.com/AztecProtocol/aztec-packages/blob/master/yarn-project/types/src/tx_execution_request.ts) out of one or more [_function calls_](https://github.com/AztecProtocol/aztec-packages/blob/master/yarn-project/types/src/function_call.ts) requested by a dapp. For example, a dapp may request a wallet to "invoke the `transfer` function on the contract at `0x1234` with the following arguments", in response to a user action. The wallet [turns that into an execution request](../../learn/concepts/accounts/main.md#execution-requests) with the signed instructions to execute that function call from the user's account contract. In an [ECDSA-based account](https://github.com/AztecProtocol/aztec-packages/blob/master/yarn-project/noir-contracts/contracts/ecdsa_account_contract/src/main.nr), for instance, this is an execution request that encodes the function call in the _entrypoint payload_, and includes its ECDSA signature with the account's signing private key.
 
 Once the _execution request_ is created, the wallet is responsible for **simulating** and **proving** the execution of its private functions. The simulation yields an execution trace, which can be used to provide the user with a list of side effects of the private execution of the transaction. During this simulation, the wallet is responsible of providing data to the virtual machine, such as private notes, encryption keys, or nullifier secrets. This execution trace is fed into the prover, which returns a zero-knowledge proof that guarantees correct execution and hides all private information. The output of this process is a [_transaction_](https://github.com/AztecProtocol/aztec-packages/blob/master/yarn-project/types/src/tx/tx.ts) object.
 
@@ -36,20 +36,20 @@ There are no proofs generated as of the Sandbox release. This will be included i
 
 ## Authorizing actions
 
-Account contracts in Aztec expose an interface for other contracts to validate [whether an action is authorized by the account or not](../../concepts/foundation/accounts/main.md#authorizing-actions). For example, an application contract may want to transfer tokens on behalf of a user, in which case the token contract will check with the account contract whether the application is authorized to do so. These actions may be carried out in private or in public functions, and in transactions originated by the user or by someone else.
+Account contracts in Aztec expose an interface for other contracts to validate [whether an action is authorized by the account or not](../../learn/concepts/accounts/main.md#authorizing-actions). For example, an application contract may want to transfer tokens on behalf of a user, in which case the token contract will check with the account contract whether the application is authorized to do so. These actions may be carried out in private or in public functions, and in transactions originated by the user or by someone else.
 
 Wallets should manage these authorizations, prompting the user when they are requested by an application. Authorizations in private executions come in the form of _auth witnesses_, which are usually signatures over an identifier for an action. Applications can request the wallet to produce an auth witness via the `createAuthWitness` call. In public functions, authorizations are pre-stored in the account contract storage, which is handled by a call to an internal function in the account contract implementation.
 
 ## Key management
 
-As in EVM-based chains, wallets are expected to manage user keys, or provide an interface to hardware wallets or alternative key stores. Keep in mind that in Aztec each account requires [two sets of keys](../../concepts/foundation/accounts/keys.md): privacy keys and authentication keys. Privacy keys are mandated by the protocol and used for encryption and nullification, whereas authentication keys are dependent on the account contract implementation rolled out by the wallet. Should the account contract support it, wallets must provide the user with the means to rotate or recover their authentication keys.
+As in EVM-based chains, wallets are expected to manage user keys, or provide an interface to hardware wallets or alternative key stores. Keep in mind that in Aztec each account requires [two sets of keys](../../learn/concepts/accounts/keys.md): privacy keys and authentication keys. Privacy keys are mandated by the protocol and used for encryption and nullification, whereas authentication keys are dependent on the account contract implementation rolled out by the wallet. Should the account contract support it, wallets must provide the user with the means to rotate or recover their authentication keys.
 
 :::info
 Due to limitations in the current architecture, privacy keys need to be available in the wallet software itself and cannot be punted to an external keystore. This restriction may be lifted in a future release.
 :::
 ## Recipient encryption keys
 
-Wallets are also expected to manage the public encryption keys of any recipients of local transactions. When creating an encrypted note for a recipient given their address, the wallet needs to provide their [complete address](../../concepts/foundation/accounts/keys.md#addresses-partial-addresses-and-public-keys). Recipients broadcast their complete addresses when deploying their account contracts, and wallets collect this information and save it in a local registry for easy access when needed.
+Wallets are also expected to manage the public encryption keys of any recipients of local transactions. When creating an encrypted note for a recipient given their address, the wallet needs to provide their [complete address](../../learn/concepts/accounts/keys.md#addresses-partial-addresses-and-public-keys). Recipients broadcast their complete addresses when deploying their account contracts, and wallets collect this information and save it in a local registry for easy access when needed.
 
 Note that, in order to interact with a recipient who has not yet deployed their account contract (and thus not broadcasted their complete address), it must also be possible to manually add an entry to a wallet's local registry of complete addresses.
 
diff --git a/docs/docs/dev_docs/wallets/writing_an_account_contract.md b/docs/docs/developers/wallets/writing_an_account_contract.md
similarity index 88%
rename from docs/docs/dev_docs/wallets/writing_an_account_contract.md
rename to docs/docs/developers/wallets/writing_an_account_contract.md
index 058a02fb349..fdc46499755 100644
--- a/docs/docs/dev_docs/wallets/writing_an_account_contract.md
+++ b/docs/docs/developers/wallets/writing_an_account_contract.md
@@ -11,15 +11,15 @@ You will learn:
 - Typescript glue code to format and authenticate transactions
 - Deploying and testing the account contract
 
-Writing your own account contract allows you to define the rules by which user transactions are authorized and paid for, as well as how user keys are managed (including key rotation and recovery). In other words, writing an account contract lets you make the most out of [account abstraction](../../concepts/foundation/accounts/main.md#what-is-account-abstraction) in the Aztec network.
+Writing your own account contract allows you to define the rules by which user transactions are authorized and paid for, as well as how user keys are managed (including key rotation and recovery). In other words, writing an account contract lets you make the most out of [account abstraction](../../learn/concepts/accounts/main.md#what-is-account-abstraction) in the Aztec network.
 
-It is highly recommended that you understand how an [account](../../concepts/foundation/accounts/main.md) is defined in Aztec, as well as the differences between privacy and authentication [keys](../../concepts/foundation/accounts/keys.md). You will also need to know how to write a [contract in Noir](../contracts/main.md), as well as some basic [Typescript](https://www.typescriptlang.org/).
+It is highly recommended that you understand how an [account](../../learn/concepts/accounts/main.md) is defined in Aztec, as well as the differences between privacy and authentication [keys](../../learn/concepts/accounts/keys.md). You will also need to know how to write a [contract in Noir](../contracts/main.md), as well as some basic [Typescript](https://www.typescriptlang.org/).
 
 For this tutorial, we will write an account contract that uses Schnorr signatures for authenticating transaction requests.
 
 > That is, every time a transaction payload is passed to this account contract's 'entrypoint' function, the account contract will demand a valid Schnorr signature, whose signed message matches the transaction payload, and whose signer matches the account contract owner's public key. If the signature fails, the transaction will fail.
 
-For the sake of simplicity, we will hardcode the signing public key into the contract, but you could store it [in a private note](../../concepts/foundation/accounts/keys.md#using-a-private-note), [in an immutable note](../../concepts/foundation/accounts/keys.md#using-an-immutable-private-note), or [on a separate keystore](../../concepts/foundation/accounts/keys.md#using-a-separate-keystore), to mention a few examples.
+For the sake of simplicity, we will hardcode the signing public key into the contract, but you could store it [in a private note](../../learn/concepts/accounts/keys.md#using-a-private-note), [in an immutable note](../../learn/concepts/accounts/keys.md#using-an-immutable-private-note), or [on a separate keystore](../../learn/concepts/accounts/keys.md#using-a-separate-keystore), to mention a few examples.
 
 ## The account contract
 
@@ -83,7 +83,7 @@ More signing schemes are available in case you want to experiment with other typ
 
 Let's try creating a new account backed by our account contract, and interact with a simple token contract to test it works.
 
-To create and deploy the account, we will use the `AccountManager` class, which takes an instance of an Private Execution Environment (PXE), a [privacy private key](../../concepts/foundation/accounts/keys.md#privacy-keys), and an instance of our `AccountContract` class:
+To create and deploy the account, we will use the `AccountManager` class, which takes an instance of an Private Execution Environment (PXE), a [privacy private key](../../learn/concepts/accounts/keys.md#privacy-keys), and an instance of our `AccountContract` class:
 
 #include_code account-contract-deploy yarn-project/end-to-end/src/guides/writing_an_account_contract.test.ts typescript
 
diff --git a/docs/docs/concepts/foundation/main.md b/docs/docs/learn/about_aztec/technical_overview.md
similarity index 79%
rename from docs/docs/concepts/foundation/main.md
rename to docs/docs/learn/about_aztec/technical_overview.md
index 6c861dfe12d..8a5e3ac8638 100644
--- a/docs/docs/concepts/foundation/main.md
+++ b/docs/docs/learn/about_aztec/technical_overview.md
@@ -1,5 +1,5 @@
 ---
-title: Foundational Concepts
+title: Core Components
 ---
 
 Aztec Labs is building a layer 2 rollup on Ethereum focused on 3 things:
@@ -40,9 +40,9 @@ A user of the Aztec network will interact with the network through Aztec.js. Azt
 
 ### Private Execution Environment
 
-The PXE provides a secure environment for the execution of sensitive operations, ensuring private information and decrypted data are not accessible to unauthorized applications. It hides the details of the [state model](./state_model/main.md) from end users, but the state model is important for Aztec developers to understand as it has implications for [private/public execution](./communication/public_private_calls/main.md) and [L1/L2 communication](./communication/cross_chain_calls.md). The PXE also includes the [ACIR Simulator](../advanced/acir_simulator.md) for private executions and the KeyStore for secure key management.
+The PXE provides a secure environment for the execution of sensitive operations, ensuring private information and decrypted data are not accessible to unauthorized applications. It hides the details of the [state model](../concepts/hybrid_state/main.md) from end users, but the state model is important for Aztec developers to understand as it has implications for [private/public execution](../concepts/communication/public_private_calls/main.md) and [L1/L2 communication](../concepts/communication/cross_chain_calls.md). The PXE also includes the [ACIR Simulator](../concepts/pxe/acir_simulator.md) for private executions and the KeyStore for secure key management.
 
-Procedurally, the PXE sends results of private function execution and requests for public function executions to the [sequencer](./nodes_clients/sequencer.md), which will update the state of the rollup.
+Procedurally, the PXE sends results of private function execution and requests for public function executions to the [sequencer](../concepts/nodes_clients/sequencer/main.md), which will update the state of the rollup.
 
 ### Sequencer
 
@@ -50,8 +50,8 @@ The sequencer aggregates transactions into a block, generates proofs of the stat
 
 ## Further Reading
 
-- [The state model](./state_model/main.md)
-- [Accounts](./accounts/main.md)
-- [Aztec Smart Contracts](./contracts.md)
-- [Transactions](./transactions.md)
-- [Communication between network components](./communication/main.md)
+- [The state model](../concepts/hybrid_state/main.md)
+- [Accounts](../concepts/accounts/main.md)
+- [Aztec Smart Contracts](../concepts/smart_contracts/main.md)
+- [Transactions](../concepts/transactions.md)
+- [Communication between network components](../concepts/communication/main.md)
diff --git a/docs/docs/about_aztec/vision.md b/docs/docs/learn/about_aztec/vision.md
similarity index 96%
rename from docs/docs/about_aztec/vision.md
rename to docs/docs/learn/about_aztec/vision.md
index 505c29794f5..f29b308f8d3 100644
--- a/docs/docs/about_aztec/vision.md
+++ b/docs/docs/learn/about_aztec/vision.md
@@ -22,5 +22,5 @@ We are building the [Aztec Network](https://aztec.network/), a fully programmabl
 
 To achieve these goals, we are pioneering the cryptography and research needed to bring our next generation, privacy-preserving zk-roll-up to mainnet.
 
-import Disclaimer from "../misc/common/\_disclaimer.mdx";
+import Disclaimer from "../../misc/common/\_disclaimer.mdx";
 <Disclaimer/>
diff --git a/docs/docs/about_aztec/overview.mdx b/docs/docs/learn/about_aztec/what_is_aztec.mdx
similarity index 95%
rename from docs/docs/about_aztec/overview.mdx
rename to docs/docs/learn/about_aztec/what_is_aztec.mdx
index c2e3d1b97a3..76080a98c4a 100644
--- a/docs/docs/about_aztec/overview.mdx
+++ b/docs/docs/learn/about_aztec/what_is_aztec.mdx
@@ -1,5 +1,5 @@
 ---
-title: Overview
+title: What is Aztec?
 ---
 
 import ReactPlayer from "react-player/youtube";
@@ -50,7 +50,7 @@ Contributors to Aztec uphold many of the values of the Ethereum community -- bui
 
 Noir is a domain specific programming language for writing zero-knowledge circuits. On Aztec a smart contract is a collection of circuits that developers write using Noir.
 
-You can find more information and resources for learning about Noir smart contracts on [this page](../dev_docs/contracts/main.md).
+You can find more information and resources for learning about Noir smart contracts on [this page](../../developers/contracts/main.md).
 
 ## Cryptography
 
@@ -60,5 +60,5 @@ To support Aztec's rollup, our cryptography team is building [Honk](https://gith
 
 Keep up with the latest discussion and join the conversation in the [Aztec forum](https://discourse.aztec.network) or [Discord server](https://discord.gg/DgWG2DBMyB).
 
-import Disclaimer from "../misc/common/_disclaimer.mdx";
+import Disclaimer from "../../misc/common/_disclaimer.mdx";
 <Disclaimer />;
diff --git a/docs/docs/concepts/foundation/accounts/authwit.md b/docs/docs/learn/concepts/accounts/authwit.md
similarity index 95%
rename from docs/docs/concepts/foundation/accounts/authwit.md
rename to docs/docs/learn/concepts/accounts/authwit.md
index ac26bf13ba1..31fa51e1efa 100644
--- a/docs/docs/concepts/foundation/accounts/authwit.md
+++ b/docs/docs/learn/concepts/accounts/authwit.md
@@ -54,7 +54,7 @@ All of these issues have been discussed in the community for a while, and there
 
 Adopting ERC20 for Aztec is not as simple as it might seem because of private state.
 
-If you recall from [State model](./../state_model/main.md), private state is generally only known by its owner and those they have shared it with. Because it relies on secrets, private state might be "owned" by a contract, but it needs someone with knowledge of these secrets to actually spend it. You might see where this is going.
+If you recall from the [Hybrid State model](../hybrid_state/main.md), private state is generally only known by its owner and those they have shared it with. Because it relies on secrets, private state might be "owned" by a contract, but it needs someone with knowledge of these secrets to actually spend it. You might see where this is going.
 
 If we were to implement the `approve` with an allowance in private, you might know the allowance, but unless you also know about the individual notes that make up the user's balances, it would be of no use to you! It is private after all. To spend the user's funds you would need to know the decryption key, see [keys for more](../accounts/keys.md). 
 
@@ -182,7 +182,7 @@ For the transfer, this could be done simply by appending a nonce to the argument
 action = H(defi, token, transfer_selector, H(alice_account, defi, 1000, nonce));
 ```
 
-Beware that the account contract will be unable to emit the nullifier since it is checked with a static call, so the calling contract must do it. This is similar to nonces in ERC20 tokens today. We provide a small library that handles this which we will see in the [developer documentation](./../../../dev_docs/contracts/resources/common_patterns/authwit.md).
+Beware that the account contract will be unable to emit the nullifier since it is checked with a static call, so the calling contract must do it. This is similar to nonces in ERC20 tokens today. We provide a small library that handles this which we will see in the [developer documentation](./../../../developers/contracts/resources/common_patterns/authwit.md).
 
 ### Differences to approval
 
@@ -196,4 +196,4 @@ We don't need to limit ourselves to the `transfer` function, we can use the same
 
 ### Next Steps
 
-Check out the [developer documentation](./../../../dev_docs/contracts/resources/common_patterns/authwit.md) to see how to implement this in your own contracts.
+Check out the [developer documentation](./../../../developers/contracts/resources/common_patterns/authwit.md) to see how to implement this in your own contracts.
diff --git a/docs/docs/concepts/foundation/accounts/keys.md b/docs/docs/learn/concepts/accounts/keys.md
similarity index 98%
rename from docs/docs/concepts/foundation/accounts/keys.md
rename to docs/docs/learn/concepts/accounts/keys.md
index e5d897d0ffc..5802996cf5e 100644
--- a/docs/docs/concepts/foundation/accounts/keys.md
+++ b/docs/docs/learn/concepts/accounts/keys.md
@@ -14,7 +14,7 @@ This is a snippet of our Schnorr Account contract implementation, which uses Sch
 
 #include_code entrypoint /yarn-project/noir-contracts/contracts/schnorr_account_contract/src/main.nr rust
 
-Still, different accounts may use different signing schemes, may require multi-factor authentication, or _may not even use signing keys_ and instead rely on other authentication mechanisms. Read [how to write an account contract](../../../dev_docs/wallets/writing_an_account_contract.md) for a full example of how to manage authentication.
+Still, different accounts may use different signing schemes, may require multi-factor authentication, or _may not even use signing keys_ and instead rely on other authentication mechanisms. Read [how to write an account contract](../../../developers/wallets/writing_an_account_contract.md) for a full example of how to manage authentication.
 
 Furthermore, and since signatures are fully abstracted, how the key is stored in the contract is abstracted as well and left to the developer of the account contract. Here are a few ideas on how to store them, each with their pros and cons.
 
diff --git a/docs/docs/concepts/foundation/accounts/main.md b/docs/docs/learn/concepts/accounts/main.md
similarity index 99%
rename from docs/docs/concepts/foundation/accounts/main.md
rename to docs/docs/learn/concepts/accounts/main.md
index c96238632be..3ad58265637 100644
--- a/docs/docs/concepts/foundation/accounts/main.md
+++ b/docs/docs/learn/concepts/accounts/main.md
@@ -68,7 +68,7 @@ def entryPoint(payload):
         enqueueCall(to, data, value, gasLimit);
 ```
 
-Read more about how to write an account contract [here](../../../dev_docs/wallets/writing_an_account_contract.md).
+Read more about how to write an account contract [here](../../../developers/wallets/writing_an_account_contract.md).
 
 ### Account contracts and wallets
 
diff --git a/docs/docs/concepts/foundation/block_production.md b/docs/docs/learn/concepts/block_production.md
similarity index 100%
rename from docs/docs/concepts/foundation/block_production.md
rename to docs/docs/learn/concepts/block_production.md
diff --git a/docs/docs/concepts/foundation/blocks.md b/docs/docs/learn/concepts/blocks.md
similarity index 100%
rename from docs/docs/concepts/foundation/blocks.md
rename to docs/docs/learn/concepts/blocks.md
diff --git a/docs/docs/concepts/advanced/circuits/kernels/private_kernel.md b/docs/docs/learn/concepts/circuits/kernels/private_kernel.md
similarity index 93%
rename from docs/docs/concepts/advanced/circuits/kernels/private_kernel.md
rename to docs/docs/learn/concepts/circuits/kernels/private_kernel.md
index cc0632c986f..1fccebbfa83 100644
--- a/docs/docs/concepts/advanced/circuits/kernels/private_kernel.md
+++ b/docs/docs/learn/concepts/circuits/kernels/private_kernel.md
@@ -16,10 +16,10 @@ This circuit is executed by the user, on their own device. This is to ensure pri
   - public call stacks: hashes representing calls to other public functions;
   - events;
   - all data accumulated by all previous private kernel circuit recursions of this tx;
-- Hides which private function has been executed, by performing a zero-knowledge proof of membership against the [contract tree](../../data_structures/trees).
+- Hides which private function has been executed, by performing a zero-knowledge proof of membership against the [contract tree](../../storage/trees/main.md#contract-tree).
 - Ensures the entire stack trace of private functions (for a particular tx) adheres to function execution rules.
 - Verifies a previous 'Private Kernel Proof', recursively, when verifying transactions which are composed of many private function calls.
-- Optionally can [deploy](../../contract_creation) a new private contract.
+- Optionally can [deploy](../../smart_contracts/contract_creation.md) a new private contract.
 
 > Note: **This is the only core protocol circuit which actually needs to be "zk" (zero-knowledge)!!!** That's because this is the only core protocol circuit which handles private data, and hence the only circuit for which proofs must not leak any information about witnesses! (The private data being handled includes: details of the Aztec.nr Contract function which has been executed; the address of the user who executed the function; the intelligible inputs and outputs of that function).
 > This is a really interesting point. Most so-called "zk-Rollups" do not make use of this "zero-knowledge" property. Their snarks are "snarks"; with no need for zero-knowledge, because they don't seek privacy; they only seek the 'succinct' computation-compression properties of snarks. Aztec's "zk-Rollup" actually makes use of "zero-knowledge" snarks. That's why we sometimes call it a "zk-zk-Rollup", or "_actual_ zk-Rollup".
diff --git a/docs/docs/concepts/advanced/circuits/kernels/public_kernel.md b/docs/docs/learn/concepts/circuits/kernels/public_kernel.md
similarity index 82%
rename from docs/docs/concepts/advanced/circuits/kernels/public_kernel.md
rename to docs/docs/learn/concepts/circuits/kernels/public_kernel.md
index 0bd2c0b7870..e9454ceb545 100644
--- a/docs/docs/concepts/advanced/circuits/kernels/public_kernel.md
+++ b/docs/docs/learn/concepts/circuits/kernels/public_kernel.md
@@ -2,7 +2,7 @@
 title: Public Kernel Circuit
 ---
 
-This circuit is executed by a Sequencer, since only a Sequencer knows the current state of the [public data tree](../../data_structures/trees) at any time. A Sequencer might choose to delegate proof generation to the Prover pool.
+This circuit is executed by a Sequencer, since only a Sequencer knows the current state of the [public data tree](../../storage/trees/main.md#public-state-tree) at any time. A Sequencer might choose to delegate proof generation to the Prover pool.
 
 - Exposes (forwards) the following data to the next recursive circuit:
   - all data accumulated by all previous private kernel circuit recursions of this tx;
diff --git a/docs/docs/concepts/advanced/circuits/main.md b/docs/docs/learn/concepts/circuits/main.md
similarity index 98%
rename from docs/docs/concepts/advanced/circuits/main.md
rename to docs/docs/learn/concepts/circuits/main.md
index 9a84f9cf60b..8db42f4e153 100644
--- a/docs/docs/concepts/advanced/circuits/main.md
+++ b/docs/docs/learn/concepts/circuits/main.md
@@ -51,7 +51,7 @@ In other words, since neither the EVM nor other rollups have rules for how to pr
 
 What kind of extra rules / checks does a rollup need, to enforce notions of private states and private functions? Stuff like:
 
-- "Perform state reads and writes using new tree structures which prevent tx linkability" (see [trees](../data_structures/trees)).
+- "Perform state reads and writes using new tree structures which prevent tx linkability" (see [trees](../storage/trees/main.md)).
 - "Hide which function was just executed, by wrapping it in a zk-snark"
 - "Hide all functions which were executed as part of this tx's stack trace, by wrapping the whole tx in a zk-snark"
 
diff --git a/docs/docs/concepts/advanced/circuits/rollup_circuits/main.md b/docs/docs/learn/concepts/circuits/rollup_circuits/main.md
similarity index 96%
rename from docs/docs/concepts/advanced/circuits/rollup_circuits/main.md
rename to docs/docs/learn/concepts/circuits/rollup_circuits/main.md
index 6fee1408755..d5ac8be56c8 100644
--- a/docs/docs/concepts/advanced/circuits/rollup_circuits/main.md
+++ b/docs/docs/learn/concepts/circuits/rollup_circuits/main.md
@@ -23,7 +23,7 @@ For both transactions, it:
 
 - Performs public state read membership checks.
 - Updates the public data tree in line with the requested state transitions.
-- Checks that the nullifiers haven't previously been inserted into the [indexed nullifier tree](../../data_structures/indexed_merkle_tree).
+- Checks that the nullifiers haven't previously been inserted into the [indexed nullifier tree](../../storage/trees/indexed_merkle_tree.md#primer-on-nullifier-trees).
 - Batch-inserts new nullifiers into the nullifier tree.
 - Batch-inserts new commitments into the note hash tree
 - Batch-inserts any new contract deployments into the contract tree.
diff --git a/docs/docs/concepts/foundation/communication/cross_chain_calls.md b/docs/docs/learn/concepts/communication/cross_chain_calls.md
similarity index 100%
rename from docs/docs/concepts/foundation/communication/cross_chain_calls.md
rename to docs/docs/learn/concepts/communication/cross_chain_calls.md
diff --git a/docs/docs/concepts/foundation/communication/main.md b/docs/docs/learn/concepts/communication/main.md
similarity index 100%
rename from docs/docs/concepts/foundation/communication/main.md
rename to docs/docs/learn/concepts/communication/main.md
diff --git a/docs/docs/concepts/foundation/communication/public_private_calls/main.md b/docs/docs/learn/concepts/communication/public_private_calls/main.md
similarity index 100%
rename from docs/docs/concepts/foundation/communication/public_private_calls/main.md
rename to docs/docs/learn/concepts/communication/public_private_calls/main.md
diff --git a/docs/docs/concepts/foundation/communication/public_private_calls/slow_updates_tree.md b/docs/docs/learn/concepts/communication/public_private_calls/slow_updates_tree.md
similarity index 97%
rename from docs/docs/concepts/foundation/communication/public_private_calls/slow_updates_tree.md
rename to docs/docs/learn/concepts/communication/public_private_calls/slow_updates_tree.md
index c6ceb070e26..a7459932f07 100644
--- a/docs/docs/concepts/foundation/communication/public_private_calls/slow_updates_tree.md
+++ b/docs/docs/learn/concepts/communication/public_private_calls/slow_updates_tree.md
@@ -70,4 +70,4 @@ Developers are used to instant state updates, so the Slow Updates Tree might tak
 
 ## Dive into the code
 
-For a code walkthrough of how a token blacklist contract can use a slow updates tree, read [this](../../../../dev_docs/contracts/syntax/slow_updates_tree.md).
\ No newline at end of file
+For a code walkthrough of how a token blacklist contract can use a slow updates tree, read [this](../../../../developers/contracts/syntax/slow_updates_tree.md).
\ No newline at end of file
diff --git a/docs/docs/concepts/foundation/globals.md b/docs/docs/learn/concepts/globals.md
similarity index 100%
rename from docs/docs/concepts/foundation/globals.md
rename to docs/docs/learn/concepts/globals.md
diff --git a/docs/docs/concepts/foundation/state_model/main.md b/docs/docs/learn/concepts/hybrid_state/main.md
similarity index 97%
rename from docs/docs/concepts/foundation/state_model/main.md
rename to docs/docs/learn/concepts/hybrid_state/main.md
index 36ca4515c3f..ac2565ee39f 100644
--- a/docs/docs/concepts/foundation/state_model/main.md
+++ b/docs/docs/learn/concepts/hybrid_state/main.md
@@ -55,4 +55,4 @@ This is achieved with two main features:
 
 ## Further reading
 
-Read more about how to leverage the Aztec state model in Aztec contracts [here](../../../dev_docs/contracts/syntax/storage/main.md).
+Read more about how to leverage the Aztec state model in Aztec contracts [here](../../../developers/contracts/syntax/storage/main.md).
diff --git a/docs/docs/concepts/advanced/public_vm.md b/docs/docs/learn/concepts/hybrid_state/public_vm.md
similarity index 100%
rename from docs/docs/concepts/advanced/public_vm.md
rename to docs/docs/learn/concepts/hybrid_state/public_vm.md
diff --git a/docs/docs/learn/concepts/main.md b/docs/docs/learn/concepts/main.md
new file mode 100644
index 00000000000..0a8c74b2bc0
--- /dev/null
+++ b/docs/docs/learn/concepts/main.md
@@ -0,0 +1,75 @@
+---
+title: Concepts
+---
+
+import Image from '@theme/IdealImage';
+import DocCardList from '@theme/DocCardList';
+
+This page outlines Aztec's fundamental technical concepts.
+
+## Aztec Overview
+
+<Image img={require('/img/aztec_high_level_network_architecture.svg')} />
+
+1. A user interacts with Aztec through Aztec.js (like web3js or ethersjs) or Aztec CLI
+2. Private functions are executed in the PXE, which is client-side
+3. They are rolled up and sent to the Public VM (running on an Aztec node)
+4. Public functions are executed in the Public VM
+5. The Public VM rolls up the private & public transaction rollups
+6. These rollups are submitted to Ethereum
+
+The PXE is unaware of the Public VM. And the Public VM is unaware of the PXE. They are completely separate execution environments. This means:
+
+- The PXE and the Public VM cannot directly communicate with each other
+- Private transactions in the PXE are executed first, followed by public transactions
+
+### Private and public state
+
+Private state works with UTXOs, or what we call notes. To keep things private, everything is stored in an [append-only UTXO tree](../../learn/concepts/storage/trees/main.md#note-hash-tree), and a nullifier is created when notes are invalidated. Nullifiers are then stored in their own [nullifier tree](./storage/trees/indexed_merkle_tree.md#primer-on-nullifier-trees).
+
+Public state works similarly to other chains like Ethereum, behaving like a public ledger. Public data is stored in a [public data tree](./storage/trees/main.md#public-state-tree).
+
+Aztec [smart contract](../concepts/smart_contracts/main.md) developers should keep in mind that different types are used when manipulating private or public state. Working with private state is creating commitments and nullifiers to state, whereas working with public state is directly updating state. 
+
+## Accounts
+
+Every account in Aztec is a smart contract (account abstraction). This allows implementing different schemes for transaction signing, nonce management, and fee payments.
+
+Developers can write their own account contract to define the rules by which user transactions are authorized and paid for, as well as how user keys are managed.
+
+Learn more about account contracts [here](../../learn/concepts/accounts/main.md).
+
+## Smart contracts
+
+Developers can write [smart contracts](./smart_contracts/main.md) that manipulate both public and private state. They are written in a framework on top of Noir, the zero-knowledge domain-specific language developed specifically for Aztec. Outside of Aztec, Noir is used for writing circuits that can be verified on EVM chains.
+
+Noir has its own doc site that you can find [here](https://noir-lang.org).
+
+## Communication with Ethereum
+
+Aztec allows private communications with Ethereum - ie no-one knows where the transaction is coming from, just that it is coming from somewhere on Aztec.
+
+This is achieved through portals - these are smart contracts deployed on an EVM that are related to the Ethereum smart contract you want to interact with.
+
+Learn more about portals [here](./communication/cross_chain_calls.md).
+
+## Circuits
+
+Aztec operates on three types of circuits:
+
+- [Private kernel circuits](./circuits/kernels/private_kernel.md), which are executed by the user on their own device and prove correct execution of a function
+- [Public kernel circuits](./circuits/kernels/public_kernel.md), which are executed by the [sequencer](./nodes_clients/sequencer/main.md) and ensure the stack trace of transactions adheres to function execution rules
+- [Rollup circuits](./circuits/rollup_circuits/main.md), which bundle all of the Aztec transactions into a proof that can be efficiently verified on Ethereum
+
+## What's next?
+
+### Dive deeper into how Aztec works
+
+Explore the Concepts for a deeper understanding into the components that make up Aztec:
+
+<DocCardList />
+
+### Start coding
+
+Follow the [developer getting started guide](../../developers/getting_started/main.md).
+
diff --git a/docs/docs/concepts/foundation/nodes_clients/execution_client.md b/docs/docs/learn/concepts/nodes_clients/execution_client.md
similarity index 100%
rename from docs/docs/concepts/foundation/nodes_clients/execution_client.md
rename to docs/docs/learn/concepts/nodes_clients/execution_client.md
diff --git a/docs/docs/concepts/foundation/nodes_clients/prover_client.md b/docs/docs/learn/concepts/nodes_clients/prover_client.md
similarity index 100%
rename from docs/docs/concepts/foundation/nodes_clients/prover_client.md
rename to docs/docs/learn/concepts/nodes_clients/prover_client.md
diff --git a/docs/docs/concepts/foundation/nodes_clients/sequencer.md b/docs/docs/learn/concepts/nodes_clients/sequencer/main.md
similarity index 97%
rename from docs/docs/concepts/foundation/nodes_clients/sequencer.md
rename to docs/docs/learn/concepts/nodes_clients/sequencer/main.md
index e9a20081223..4173dd87e2f 100644
--- a/docs/docs/concepts/foundation/nodes_clients/sequencer.md
+++ b/docs/docs/learn/concepts/nodes_clients/sequencer/main.md
@@ -40,4 +40,4 @@ You can view the current implementation on Github [here](https://github.com/Azte
 
 ## Further Reading
 
-- [Sequencer Selection](../../advanced/sequencer_selection.md)
+- [Sequencer Selection](../../../concepts/nodes_clients/sequencer/sequencer_selection.md)
diff --git a/docs/docs/concepts/advanced/sequencer_selection.md b/docs/docs/learn/concepts/nodes_clients/sequencer/sequencer_selection.md
similarity index 100%
rename from docs/docs/concepts/advanced/sequencer_selection.md
rename to docs/docs/learn/concepts/nodes_clients/sequencer/sequencer_selection.md
diff --git a/docs/docs/concepts/advanced/acir_simulator.md b/docs/docs/learn/concepts/pxe/acir_simulator.md
similarity index 88%
rename from docs/docs/concepts/advanced/acir_simulator.md
rename to docs/docs/learn/concepts/pxe/acir_simulator.md
index bae95f54ff1..1df355c9bb7 100644
--- a/docs/docs/concepts/advanced/acir_simulator.md
+++ b/docs/docs/learn/concepts/pxe/acir_simulator.md
@@ -14,13 +14,13 @@ It simulates three types of functions:
 
 Private functions are simulated and proved client-side, and verified client-side in the private kernel circuit.
 
-They are run with the assistance of a DB oracle that provides any private data requested by the function. You can read more about oracle functions in the smart contract section [here](../../dev_docs/contracts/syntax/functions.md#oracle-functions).
+They are run with the assistance of a DB oracle that provides any private data requested by the function. You can read more about oracle functions in the smart contract section [here](../../../developers/contracts/syntax/functions.md#oracle-functions).
 
 Private functions can call other private functions and can request to call a public function. The public function execution will be performed by the sequencer asynchronously, so private functions don't have direct access to the return values of public functions.
 
 ### Public Functions
 
-Public functions are simulated and proved on the [sequencer](../foundation/nodes_clients/sequencer.md) side, and verified by the [public kernel circuit](./circuits/kernels/public_kernel.md).
+Public functions are simulated and proved on the [sequencer](../nodes_clients/sequencer/main.md) side, and verified by the [public kernel circuit](../circuits/kernels/public_kernel.md).
 
 They are run with the assistance of an oracle that provides any value read from the public state tree.
 
diff --git a/docs/docs/concepts/advanced/private_execution_environment.md b/docs/docs/learn/concepts/pxe/main.md
similarity index 91%
rename from docs/docs/concepts/advanced/private_execution_environment.md
rename to docs/docs/learn/concepts/pxe/main.md
index 50eadfa4820..effb02a1072 100644
--- a/docs/docs/concepts/advanced/private_execution_environment.md
+++ b/docs/docs/learn/concepts/pxe/main.md
@@ -31,7 +31,7 @@ graph TD;
 
 ## PXE Service 
 
-The PXE is a client-side interface of the PXE Service, which is a set of server-side APIs for interacting with the network. It provides functions for account management, contract and transaction interactions, note management, and more. For a more extensive list of operations, refer to the [PXE reference](../../apis/pxe/interfaces/PXE.md).
+The PXE is a client-side interface of the PXE Service, which is a set of server-side APIs for interacting with the network. It provides functions for account management, contract and transaction interactions, note management, and more. For a more extensive list of operations, refer to the [PXE reference](../../../developers/apis/pxe/index.md).
 
 ## Components
 
@@ -62,9 +62,9 @@ The keystore is a secure storage for private and public keys.
 
 ## Oracles
 
-Oracles are pieces of data that are injected into a smart contract function from the client side. You can read more about why and how they work in the [functions section](../../dev_docs/contracts/syntax/functions.md).
+Oracles are pieces of data that are injected into a smart contract function from the client side. You can read more about why and how they work in the [functions section](../../../developers/contracts/syntax/functions.md#oracle-functions).
 
 ## For developers
 To learn how to develop on top of the PXE, refer to these guides:
-* [Run more than one PXE on your local machine](../../dev_docs/cli/run_more_than_one_pxe_sandbox.md)
-* [Use in-built oracles including oracles for arbitrary data](../../dev_docs/contracts/syntax/oracles.md)
+* [Run more than one PXE on your local machine](../../../developers/cli/run_more_than_one_pxe_sandbox.md)
+* [Use in-built oracles including oracles for arbitrary data](../../../developers/contracts/syntax/oracles.md)
\ No newline at end of file
diff --git a/docs/docs/concepts/advanced/contract_creation.md b/docs/docs/learn/concepts/smart_contracts/contract_creation.md
similarity index 99%
rename from docs/docs/concepts/advanced/contract_creation.md
rename to docs/docs/learn/concepts/smart_contracts/contract_creation.md
index 3eb3380b6c9..b93f5a7d54e 100644
--- a/docs/docs/concepts/advanced/contract_creation.md
+++ b/docs/docs/learn/concepts/smart_contracts/contract_creation.md
@@ -4,7 +4,7 @@ title: Contract Creation
 
 <!-- TODO: Mike to update -->
 
-import Disclaimer from '../../misc/common/\_disclaimer.mdx';
+import Disclaimer from '../../../misc/common/\_disclaimer.mdx';
 
 <Disclaimer/>
 
@@ -327,4 +327,4 @@ Adds initial public state variables to the public data tree.
 
 ## Further reading
 
-To see how to deploy a contract in practice, check out the [dapp development tutorial](../../dev_docs/tutorials/writing_dapp/main.md).
+To see how to deploy a contract in practice, check out the [dapp development tutorial](../../../developers/tutorials/writing_dapp/main.md).
diff --git a/docs/docs/concepts/foundation/contracts.md b/docs/docs/learn/concepts/smart_contracts/main.md
similarity index 95%
rename from docs/docs/concepts/foundation/contracts.md
rename to docs/docs/learn/concepts/smart_contracts/main.md
index 98cbd438992..822c7811ac3 100644
--- a/docs/docs/concepts/foundation/contracts.md
+++ b/docs/docs/learn/concepts/smart_contracts/main.md
@@ -23,4 +23,4 @@ There are no plans for EVM compatibility or to support Solidity in Aztec. The pr
 
 ## Further reading
 
-Read more about writing Aztec contracts [here](../../dev_docs/contracts/main.md).
+Read more about writing Aztec contracts [here](../../../developers/contracts/main.md).
diff --git a/docs/docs/concepts/foundation/state_model/storage_slots.md b/docs/docs/learn/concepts/storage/storage_slots.md
similarity index 77%
rename from docs/docs/concepts/foundation/state_model/storage_slots.md
rename to docs/docs/learn/concepts/storage/storage_slots.md
index 0f67af9ec11..80013ecd156 100644
--- a/docs/docs/concepts/foundation/state_model/storage_slots.md
+++ b/docs/docs/learn/concepts/storage/storage_slots.md
@@ -11,7 +11,7 @@ It also means that we need to be careful about how we allocate storage to ensure
 
 ## Public State Slots
 
-As mentioned in [State Model](./main.md), Aztec public state behaves similarly to public state on Ethereum from the point of view of the developer. Behind the scenes however, the storage is managed differently. As mentioned, public state has just one large sparse tree in Aztec - so we silo slots of public data by hashing it together with its contract address. 
+As mentioned in [State Model](./../hybrid_state/main.md), Aztec public state behaves similarly to public state on Ethereum from the point of view of the developer. Behind the scenes however, the storage is managed differently. As mentioned, public state has just one large sparse tree in Aztec - so we silo slots of public data by hashing it together with its contract address. 
 
 The mental model is that we have a key-value store, where the siloed slot is the key, and the value is the data stored in that slot. You can think of the `real_storage_slot` identifying its position in the tree, and the `logical_storage_slot` identifying the position in the contract storage.
 
@@ -19,14 +19,14 @@ The mental model is that we have a key-value store, where the siloed slot is the
 real_storage_slot = H(contract_address, logical_storage_slot)
 ```
 
-The siloing is performed by the [Kernel circuits](../../advanced/circuits/kernels/main.md). 
+The siloing is performed by the [Kernel circuits](../../concepts/circuits/main.md). 
 
 For structs and arrays, we are logically using a similar storage slot computation to ethereum, e.g., as a struct with 3 fields would be stored in 3 consecutive slots. However, because the "actual" storage slot is computed as a hash of the contract address and the logical storage slot, the actual storage slot is not consecutive.
 
 
 ## Private State Slots - Slots aren't real
 
-Private storage is a different beast. As you might remember from [State Model](./main.md), private state is stored in encrypted logs and the corresponding private state commitments in append-only tree where each leaf is a commitment. Being append-only, means that leaves are never updated or deleted; instead a nullifier is emitted to signify that some note is no longer valid. A major reason we used this tree, is that lookups at a specific storage slot would leak information in the context of private state. If you could look up a specific address balance just by looking at the storage slot, even if encrypted you would be able to see it changing! That is not good privacy. 
+Private storage is a different beast. As you might remember from [Hybrid State Model](../hybrid_state/main.md), private state is stored in encrypted logs and the corresponding private state commitments in append-only tree where each leaf is a commitment. Being append-only, means that leaves are never updated or deleted; instead a nullifier is emitted to signify that some note is no longer valid. A major reason we used this tree, is that lookups at a specific storage slot would leak information in the context of private state. If you could look up a specific address balance just by looking at the storage slot, even if encrypted you would be able to see it changing! That is not good privacy. 
 
 Following this, the storage slot as we know it doesn't really exist. The leaves of the note hashes tree are just commitments to content (think of it as a hash of its content).
 
@@ -62,4 +62,4 @@ By doing this address-siloing at the kernel circuit we *force* the inserted comm
 To ensure that nullifiers don't collide across contracts we also force this contract siloing at the kernel level.
 :::
 
-For an example of this see [developer documentation storage slots](./../../../dev_docs/contracts/syntax/storage/storage_slots.md).
+For an example of this see [developer documentation storage slots](./../../../developers/contracts/syntax/storage/storage_slots.md).
diff --git a/docs/docs/concepts/advanced/data_structures/indexed_merkle_tree.md b/docs/docs/learn/concepts/storage/trees/indexed_merkle_tree.md
similarity index 100%
rename from docs/docs/concepts/advanced/data_structures/indexed_merkle_tree.md
rename to docs/docs/learn/concepts/storage/trees/indexed_merkle_tree.md
diff --git a/docs/docs/concepts/advanced/data_structures/trees.md b/docs/docs/learn/concepts/storage/trees/main.md
similarity index 96%
rename from docs/docs/concepts/advanced/data_structures/trees.md
rename to docs/docs/learn/concepts/storage/trees/main.md
index d29f9c04669..af58086e10f 100644
--- a/docs/docs/concepts/advanced/data_structures/trees.md
+++ b/docs/docs/learn/concepts/storage/trees/main.md
@@ -132,7 +132,7 @@ nullifier = hash(note_hash, owner_secret_key);
 
 This has the property that it's inextricably linked to the Note it is nullifying, and it can only be derived by the owner of the `owner_public_key` contained within the Note. Ensuring that the secret key corresponds to the public key would be implemented in the Aztec contract.
 
-A smart contract that generates this nullifier and submits it to the network will only be allowed to submit it once; a second submission will be rejected by the base [Rollup Circuit](../circuits/rollup_circuits/main.md#base-rollup-circuit) (which performs Merkle non-membership checks against the Nullifier Tree). This prevents a Note from being 'deleted' twice.
+A smart contract that generates this nullifier and submits it to the network will only be allowed to submit it once; a second submission will be rejected by the base [Rollup Circuit](../../circuits/rollup_circuits/main.md) (which performs Merkle non-membership checks against the Nullifier Tree). This prevents a Note from being 'deleted' twice.
 
 :::note
 
@@ -171,7 +171,7 @@ This tree's data can only be read/written by the Sequencer, since only they can
 
 ## Contract Tree
 
-The contract tree contains information about every function of every contract deployed to the Aztec network. This allows the [Kernel Circuits](../circuits/kernels/main.md) to validate that a function belongs to a specific contract.
+The contract tree contains information about every function of every contract deployed to the Aztec network. This allows the [Kernel Circuits](../../circuits/main.md) to validate that a function belongs to a specific contract.
 
 <Image img={require("/img/contract-tree.png")} />
 
@@ -211,7 +211,7 @@ HistoricalAccessTree --- Header
 
 ```
 
-It can also be used to find information about notes, public state, and contracts that were included in a certain block using [inclusion and non-inclusion proofs](../../../dev_docs/contracts/syntax/historical_access/how_to_prove_history.md).
+It can also be used to find information about notes, public state, and contracts that were included in a certain block using [inclusion and non-inclusion proofs](../../../../developers/contracts/syntax/historical_access/how_to_prove_history.md).
 
 ## Trees of valid Kernel/Rollup circuit Verification Keys
 
diff --git a/docs/docs/concepts/foundation/transactions.md b/docs/docs/learn/concepts/transactions.md
similarity index 93%
rename from docs/docs/concepts/foundation/transactions.md
rename to docs/docs/learn/concepts/transactions.md
index ff1dce31933..5cad5bda8e8 100644
--- a/docs/docs/concepts/foundation/transactions.md
+++ b/docs/docs/learn/concepts/transactions.md
@@ -29,9 +29,9 @@ _The transaction has not been broadcasted to the sequencer network yet._
 
 _The transaction has still not been broadcasted to the sequencer network yet._
 
-3. **The PXE proves correct execution** – the PXE proves correct execution (via zero-knowledge proofs) of the authorization and the private transfer method. Once the proofs have been generated, the PXE sends the proofs and required inputs (inputs are new note commitments, stored in the [note hash tree](../advanced/data_structures/trees.md#note-hash-tree) and nullifiers stored in the [nullifiers tree](../advanced/data_structures/trees.md#nullifier-tree)) to the sequencer. Nullifiers are data that invalidate old commitments, ensuring that commitments can only be used once.
+3. **The PXE proves correct execution** – the PXE proves correct execution (via zero-knowledge proofs) of the authorization and the private transfer method. Once the proofs have been generated, the PXE sends the proofs and required inputs (inputs are new note commitments, stored in the [note hash tree](../concepts/storage/trees/main.md#note-hash-tree) and nullifiers stored in the [nullifiers tree](../concepts/storage/trees/main.md#nullifier-tree)) to the sequencer. Nullifiers are data that invalidate old commitments, ensuring that commitments can only be used once.
 
-The sequencer has received transaction proof and can begin to process the transaction (verify proofs and apply updates to the relevant [data trees](../advanced/data_structures/trees.md)) alongside other public and private transactions.
+The sequencer has received transaction proof and can begin to process the transaction (verify proofs and apply updates to the relevant [data trees](../concepts/storage/trees/main.md)) alongside other public and private transactions.
 
 4. **The sequencer has the necessary information to act** – the randomly-selected sequencer (based on the Fernet sequencer selection protocol) validates the transaction proofs along with required inputs (e.g. the note commitments and nullifiers) for this private transfer. The sequencer also executes public functions and requests proofs of public execution from a prover network. The sequencer updates the corresponding data trees and does the same for other private transactions. The sequencer requests proofs from a prover network that will be bundled into a final rollup proof.
 
diff --git a/docs/docs/concepts/foundation/upgrade_mechanism.md b/docs/docs/learn/concepts/upgrade_mechanism.md
similarity index 100%
rename from docs/docs/concepts/foundation/upgrade_mechanism.md
rename to docs/docs/learn/concepts/upgrade_mechanism.md
diff --git a/docs/docs/misc/common/_disclaimer.mdx b/docs/docs/misc/common/_disclaimer.mdx
index 2bd4a3a0cfc..b6d393fef45 100644
--- a/docs/docs/misc/common/_disclaimer.mdx
+++ b/docs/docs/misc/common/_disclaimer.mdx
@@ -3,7 +3,7 @@
 :::caution Disclaimer
 We are building Aztec as transparently as we can. The documents published here are living documents. The protocol, sandbox, language, and tools are all subject to change over time.
 
-Please see [here](../../dev_docs/limitations/main.md) for details of known Aztec protocol and Aztec Sandbox limitations.
+Please see [here](../../developers/limitations/main.md) for details of known Aztec protocol and Aztec Sandbox limitations.
 
 If you would like to help us build Aztec:
 - Contribute code on [GitHub](https://github.com/AztecProtocol); or
diff --git a/docs/docs/about_aztec/how_to_contribute.md b/docs/docs/misc/how_to_contribute.md
similarity index 100%
rename from docs/docs/about_aztec/how_to_contribute.md
rename to docs/docs/misc/how_to_contribute.md
diff --git a/docs/docs/about_aztec/roadmap/cryptography_roadmap.md b/docs/docs/misc/roadmap/cryptography_roadmap.md
similarity index 100%
rename from docs/docs/about_aztec/roadmap/cryptography_roadmap.md
rename to docs/docs/misc/roadmap/cryptography_roadmap.md
diff --git a/docs/docs/about_aztec/roadmap/engineering_roadmap.md b/docs/docs/misc/roadmap/engineering_roadmap.md
similarity index 98%
rename from docs/docs/about_aztec/roadmap/engineering_roadmap.md
rename to docs/docs/misc/roadmap/engineering_roadmap.md
index 890d0f1e14a..4b5163f90ad 100644
--- a/docs/docs/about_aztec/roadmap/engineering_roadmap.md
+++ b/docs/docs/misc/roadmap/engineering_roadmap.md
@@ -121,7 +121,7 @@ CI takes up a significant amount of time. It gets its own section here, so we re
 
 We _need_ a way to read mutable public data from a private function. 
 
-Note: we just published the [Slow Updates Tree](../../concepts/foundation/communication/public_private_calls/slow_updates_tree.md).
+Note: we just published the [Slow Updates Tree](../../learn/concepts/communication/public_private_calls/slow_updates_tree.md).
 
 ## Contract classes and instances?
 
diff --git a/docs/docs/about_aztec/roadmap/features_initial_ldt.md b/docs/docs/misc/roadmap/features_initial_ldt.md
similarity index 100%
rename from docs/docs/about_aztec/roadmap/features_initial_ldt.md
rename to docs/docs/misc/roadmap/features_initial_ldt.md
diff --git a/docs/docs/about_aztec/roadmap/main.md b/docs/docs/misc/roadmap/main.md
similarity index 100%
rename from docs/docs/about_aztec/roadmap/main.md
rename to docs/docs/misc/roadmap/main.md
diff --git a/docs/docs/intro.md b/docs/docs/welcome.md
similarity index 62%
rename from docs/docs/intro.md
rename to docs/docs/welcome.md
index ca9ff902fe9..6be66998211 100644
--- a/docs/docs/intro.md
+++ b/docs/docs/welcome.md
@@ -1,11 +1,11 @@
 ---
 slug: "/"
-id: "intro"
-title: What is Aztec?
+id: "welcome"
+title: Welcome
 description: "Aztec introduces a privacy-centric zkRollup solution for Ethereum, enhancing confidentiality and scalability within the Ethereum ecosystem."
 ---
 
-# Aztec: Ethereum, encrypted
+# Aztec: A Privacy-First L2 on Ethereum
 
 On Ethereum today, everything is publicly visible, by everyone. In the real world, people enjoy privacy. Aztec brings privacy to Ethereum.
 
@@ -13,11 +13,11 @@ On Ethereum today, everything is publicly visible, by everyone. In the real worl
 
 ### Learn :book:
 
-Start on the [Foundational Concepts page](./concepts/foundation/main.md) to read about how Aztec works.
+Start on the [Technical Overview page](./learn/about_aztec/technical_overview.md) to read about how Aztec works.
 
 ### Build :technologist:
 
-Go to the [Getting Started section](./dev_docs/getting_started/main.md) of the developer docs to get your hands dirty and start developing on Aztec.
+Go to the [Getting Started section](./developers/getting_started/main.md) of the developer docs to get your hands dirty and start developing on Aztec.
 
 #### Go deeper 🔬
 
@@ -25,4 +25,4 @@ Check out the [Awesome Aztec repo](https://github.com/AztecProtocol/awesome-azte
 
 Clone the [Aztec Starter repo](https://github.com/AztecProtocol/aztec-starter) to get a minimal project set up with Sandbox (local developer network), a simple contract and a test suite.
 
-Jump into one of the [tutorials](./dev_docs/tutorials/main.md) to learn how to build more complex applications on Aztec.
+Jump into one of the [tutorials](./developers/tutorials/main.md) to learn how to build more complex applications on Aztec.
diff --git a/docs/docusaurus.config.js b/docs/docusaurus.config.js
index efe1271187e..d2ffd760db2 100644
--- a/docs/docusaurus.config.js
+++ b/docs/docusaurus.config.js
@@ -195,7 +195,7 @@ const config = {
         items: [
           {
             type: "doc",
-            docId: "intro",
+            docId: "welcome",
             position: "left",
             label: "Aztec Protocol",
           },
@@ -213,7 +213,7 @@ const config = {
               },
               {
                 label: "Developer Quickstart",
-                to: "/dev_docs/getting_started/quickstart",
+                to: "/developers/getting_started/quickstart",
               },
               {
                 label: "Aztec.nr",
diff --git a/docs/internal_notes/building_dapps.md b/docs/internal_notes/building_dapps.md
index b6d4f3a1be1..4cc8792a3bd 100644
--- a/docs/internal_notes/building_dapps.md
+++ b/docs/internal_notes/building_dapps.md
@@ -36,7 +36,7 @@ FOR INSTRUCTIONS FOR BUILDING A WALLET, WE SHOULD WRITE DOCS HERE
 
 ERRORS:
 
-- Add any error explanations to [errors.md](../docs/dev_docs/contracts/common_errors.md) (and break that file into multiple files if it's too unwieldy).
+- Add any error explanations to [errors.md](../docs/developers/contracts/common_errors.md) (and break that file into multiple files if it's too unwieldy).
 
 ## Testing a dapp
 
diff --git a/docs/netlify.toml b/docs/netlify.toml
index a26ea50351b..79a888a51b3 100644
--- a/docs/netlify.toml
+++ b/docs/netlify.toml
@@ -112,55 +112,55 @@
 
 [[redirects]]
     from = "/aztec/protocol/trees"
-    to = "/concepts/advanced/data_structures/trees"
+    to = "/learn/concepts/storage/trees/main"
 
 [[redirects]]
     from = "/aztec/protocol/trees/indexed-merkle-tree"
-    to = "/concepts/advanced/data_structures/indexed_merkle_tree"
+    to = "/learn/concepts/storage/trees/indexed_merkle_tree"
 
 [[redirects]]
     from = "/aztec/protocol/circuits/private-kernel"
-    to = "/concepts/advanced/circuits/kernels/private_kernel"
+    to = "/learn/concepts/circuits/kernels/private_kernel"
 
 [[redirects]]
     from = "/aztec/protocol/circuits/public-kernel"
-    to = "/concepts/advanced/circuits/kernels/public_kernel"
+    to = "/learn/concepts/circuits/kernels/public_kernel"
 
 [[redirects]]
     from = "/aztec/protocol/circuits/rollup"
-    to = "/concepts/advanced/circuits/rollup_circuits/main"
+    to = "/learn/concepts/circuits/rollup_circuits/main"
 
 [[redirects]]
     from = "/aztec/protocol/public-functions-vm-architectures"
-    to = "/concepts/advanced/public_vm"
+    to = "/learn/concepts/hybrid_state/public_vm"
 
 [[redirects]]
     from = "/aztec/how-it-works/private-smart-contracts"
-    to = "/concepts/foundation/contracts"
+    to = "/learn/concepts/contracts/main"
 
 [[redirects]]
     from = "/aztec/how-it-works/private-state"
-    to = "/concepts/foundation/state_model/main"
+    to = "/learn/concepts/hybrid_state/main"
 
 [[redirects]]
     from = "/concepts/foundation/state_model"
-    to = "/concepts/foundation/state_model/main"
+    to = "/learn/concepts/hybrid_state/main"
 
 [[redirects]]
     from = "/aztec/how-it-works/private-public-execution"
-    to = "/concepts/foundation/communication/public_private_calls/main"
+    to = "/learn/concepts/communication/public_private_calls/main"
 
 [[redirects]]
     from="/concepts/foundation/communication/public_private_calls"
-    to="/concepts/foundation/communication/public_private_calls/main"
+    to="/learn/concepts/communication/public_private_calls/main"
 
 [[redirects]]
     from = "/aztec/how-it-works/l1-l2-messaging"
-    to = "/concepts/foundation/communication/cross_chain_calls"
+    to = "/learn/concepts/communication/cross_chain_calls"
 
 [[redirects]]
     from = "/aztec/protocol/contract-creation"
-    to = "/concepts/advanced/contract_creation"
+    to = "/learn/concepts/contracts/contract_creation"
 
 [[redirects]]
     from = "/noir"
diff --git a/docs/sidebars.js b/docs/sidebars.js
index 0829e9fca27..aa455539b96 100644
--- a/docs/sidebars.js
+++ b/docs/sidebars.js
@@ -24,34 +24,15 @@ const sidebars = {
     {
       type: "html",
       className: "sidebar-title",
-      value: "About Aztec",
+      value: "LEARN",
       defaultStyle: true,
     },
 
-    {
-      label: "What is Aztec?",
-      type: "category",
-      link: { type: "doc", id: "intro" },
-      items: ["about_aztec/overview"],
-    },
-
-    "about_aztec/vision",
-
-    {
-      label: "Roadmap",
-      type: "category",
-      link: {
-        type: "doc",
-        id: "about_aztec/roadmap/main",
-      },
-      items: [
-        "about_aztec/roadmap/features_initial_ldt",
-        "about_aztec/roadmap/cryptography_roadmap",
-      ],
-    },
-
-    "about_aztec/how_to_contribute",
-
+    "welcome",
+    "learn/about_aztec/what_is_aztec",
+    "learn/about_aztec/vision",
+    "learn/about_aztec/technical_overview",
+  
     {
       type: "html",
       value: '<span clasuns="sidebar-divider" />',
@@ -60,99 +41,93 @@ const sidebars = {
     // SPECIFICATION
 
     {
-      type: "html",
-      className: "sidebar-title",
-      value: "Specification",
-      defaultStyle: true,
-    },
-
-    {
-      label: "Foundational Concepts",
+      label: "Concepts",
       type: "category",
       link: {
         type: "doc",
-        id: "concepts/foundation/main",
+        id: "learn/concepts/main",
       },
       items: [
         {
-          label: "State Model",
+          label: "Hybrid State Model",
           type: "category",
           link: {
             type: "doc",
-            id: "concepts/foundation/state_model/main",
+            id: "learn/concepts/hybrid_state/main",
           },
-          items: ["concepts/foundation/state_model/storage_slots"],
+          items: [
+            "learn/concepts/hybrid_state/public_vm",
+          ],
+        },
+        {
+          label: "Storage",
+          type: "category",
+          items: [
+            {
+              label: "Trees",
+              type: "category",
+              link: {
+                type: "doc",
+                id: "learn/concepts/storage/trees/main",
+              },
+              items: [
+                "learn/concepts/storage/trees/indexed_merkle_tree",
+              ],
+            },
+            "learn/concepts/storage/storage_slots",
+          ],
         },
         {
           label: "Accounts",
           type: "category",
-          link: { type: "doc", id: "concepts/foundation/accounts/main" },
+          link: {
+            type: "doc",
+            id: "learn/concepts/accounts/main",
+          },
           items: [
-            "concepts/foundation/accounts/keys",
-            "concepts/foundation/accounts/authwit",
+            "learn/concepts/accounts/keys",
+            "learn/concepts/accounts/authwit",
           ],
         },
-        "concepts/foundation/contracts",
-        "concepts/foundation/transactions",
-        // "concepts/foundation/globals",
+        "learn/concepts/transactions",
         {
-          label: "Communication",
+          label: "Smart Contracts",
           type: "category",
           link: {
             type: "doc",
-            id: "concepts/foundation/communication/main",
+            id: "learn/concepts/smart_contracts/main",
           },
+          items: [
+            "learn/concepts/smart_contracts/contract_creation",
+          ],
+        },
+        {
+          label: "Communication",
+          type: "category",
           items: [
             {
               label: "Public <> Private Communication",
               type: "category",
               link: {
                 type: "doc",
-                id: "concepts/foundation/communication/public_private_calls/main",
+                id: "learn/concepts/communication/public_private_calls/main",
               },
               items: [
-                "concepts/foundation/communication/public_private_calls/slow_updates_tree",
+                "learn/concepts/communication/public_private_calls/slow_updates_tree",
               ],
             },
-            "concepts/foundation/communication/cross_chain_calls",
+            "learn/concepts/communication/cross_chain_calls",
           ],
         },
         {
-          label: "Nodes and Clients",
-          type: "category",
-          // link: {
-          //   type: "doc",
-          //   id: "concepts/foundation/nodes_clients/main",
-          // },
-          items: [
-            // "concepts/foundation/nodes_clients/execution_client",
-            // "concepts/foundation/nodes_clients/prover_client",
-            "concepts/foundation/nodes_clients/sequencer",
-          ],
-        },
-        // "concepts/foundation/block_production",
-        // "concepts/foundation/upgrade_mechanism",
-      ],
-    },
-
-    {
-      label: "Advanced Concepts",
-      type: "category",
-      link: {
-        type: "doc",
-        id: "concepts/advanced/main",
-      },
-      items: [
-        {
-          label: "Data Structures",
+          label: "Private Execution Environment (PXE)",
           type: "category",
           link: {
             type: "doc",
-            id: "concepts/advanced/data_structures/main",
+            id: "learn/concepts/pxe/main",
           },
           items: [
-            "concepts/advanced/data_structures/trees",
-            "concepts/advanced/data_structures/indexed_merkle_tree",
+            "learn/concepts/pxe/acir_simulator",
           ],
         },
         {
@@ -160,51 +135,46 @@ const sidebars = {
           type: "category",
           link: {
             type: "doc",
-            id: "concepts/advanced/circuits/main",
+            id: "learn/concepts/circuits/main",
           },
           items: [
             {
-              label: "Kernels",
+              label: "Kernel Circuits",
               type: "category",
-              link: {
-                type: "doc",
-                id: "concepts/advanced/circuits/kernels/main",
-              },
               items: [
-                "concepts/advanced/circuits/kernels/private_kernel",
-                "concepts/advanced/circuits/kernels/public_kernel",
+                "learn/concepts/circuits/kernels/private_kernel",
+                "learn/concepts/circuits/kernels/public_kernel",
               ],
             },
+            "learn/concepts/circuits/rollup_circuits/main",
+          ],
+        },
+        {
+          label: "Nodes and Clients",
+          type: "category",
+          items: [
             {
-              label: "Rollup Circuits",
-              type: "category",
+              label: "Sequencer",
               link: {
                 type: "doc",
-                id: "concepts/advanced/circuits/rollup_circuits/main",
+                id: "learn/concepts/nodes_clients/sequencer/main",
               },
-              items: [],
+              type: "category",
+              items: [
+                "learn/concepts/nodes_clients/sequencer/sequencer_selection",
+              ],
             },
           ],
         },
-        "concepts/advanced/public_vm",
-        "concepts/advanced/contract_creation",
-        "concepts/advanced/private_execution_environment",
-        "concepts/advanced/sequencer_selection",
-        "concepts/advanced/acir_simulator",
       ],
     },
 
-    {
-      type: "html",
-      value: '<span class="sidebar-divider" />',
-    },
-
     // DEVELOPER DOCUMENTATION
 
     {
       type: "html",
       className: "sidebar-title",
-      value: "Developer Documentation",
+      value: "BUILD",
       defaultStyle: true,
     },
 
@@ -213,13 +183,12 @@ const sidebars = {
       type: "category",
       link: {
         type: "doc",
-        id: "dev_docs/getting_started/main",
+        id: "developers/getting_started/main",
       },
       items: [
-        "dev_docs/getting_started/quickstart",
-        "dev_docs/getting_started/core-concepts",
-        "dev_docs/getting_started/aztecnr-getting-started",
-        "dev_docs/getting_started/aztecjs-getting-started",
+        "developers/getting_started/quickstart",
+        "developers/getting_started/aztecnr-getting-started",
+        "developers/getting_started/aztecjs-getting-started",
       ],
     },
 
@@ -228,25 +197,25 @@ const sidebars = {
       type: "category",
       link: {
         type: "doc",
-        id: "dev_docs/tutorials/main",
+        id: "developers/tutorials/main",
       },
       items: [
-        "dev_docs/tutorials/writing_token_contract",
-        "dev_docs/tutorials/writing_private_voting_contract",
+        "developers/tutorials/writing_token_contract",
+        "developers/tutorials/writing_private_voting_contract",
 
         {
           label: "Writing a DApp",
           type: "category",
           link: {
             type: "doc",
-            id: "dev_docs/tutorials/writing_dapp/main",
+            id: "developers/tutorials/writing_dapp/main",
           },
           items: [
-            "dev_docs/tutorials/writing_dapp/project_setup",
-            "dev_docs/tutorials/writing_dapp/pxe_service",
-            "dev_docs/tutorials/writing_dapp/contract_deployment",
-            "dev_docs/tutorials/writing_dapp/contract_interaction",
-            "dev_docs/tutorials/writing_dapp/testing",
+            "developers/tutorials/writing_dapp/project_setup",
+            "developers/tutorials/writing_dapp/pxe_service",
+            "developers/tutorials/writing_dapp/contract_deployment",
+            "developers/tutorials/writing_dapp/contract_interaction",
+            "developers/tutorials/writing_dapp/testing",
           ],
         },
         {
@@ -254,15 +223,15 @@ const sidebars = {
           type: "category",
           link: {
             type: "doc",
-            id: "dev_docs/tutorials/token_portal/main",
+            id: "developers/tutorials/token_portal/main",
           },
           items: [
-            "dev_docs/tutorials/token_portal/setup",
-            "dev_docs/tutorials/token_portal/depositing_to_aztec",
-            "dev_docs/tutorials/token_portal/minting_on_aztec",
-            "dev_docs/tutorials/token_portal/cancelling_deposits",
-            "dev_docs/tutorials/token_portal/withdrawing_to_l1",
-            "dev_docs/tutorials/token_portal/typescript_glue_code",
+            "developers/tutorials/token_portal/setup",
+            "developers/tutorials/token_portal/depositing_to_aztec",
+            "developers/tutorials/token_portal/minting_on_aztec",
+            "developers/tutorials/token_portal/cancelling_deposits",
+            "developers/tutorials/token_portal/withdrawing_to_l1",
+            "developers/tutorials/token_portal/typescript_glue_code",
           ],
         },
         {
@@ -270,21 +239,21 @@ const sidebars = {
           type: "category",
           link: {
             type: "doc",
-            id: "dev_docs/tutorials/uniswap/main",
+            id: "developers/tutorials/uniswap/main",
           },
           items: [
-            "dev_docs/tutorials/uniswap/setup",
-            "dev_docs/tutorials/uniswap/l1_portal",
-            "dev_docs/tutorials/uniswap/l2_contract_setup",
-            "dev_docs/tutorials/uniswap/swap_publicly",
-            "dev_docs/tutorials/uniswap/execute_public_swap_on_l1",
-            "dev_docs/tutorials/uniswap/swap_privately",
-            "dev_docs/tutorials/uniswap/execute_private_swap_on_l1",
-            "dev_docs/tutorials/uniswap/redeeming_swapped_assets_on_l2",
-            "dev_docs/tutorials/uniswap/typescript_glue_code",
+            "developers/tutorials/uniswap/setup",
+            "developers/tutorials/uniswap/l1_portal",
+            "developers/tutorials/uniswap/l2_contract_setup",
+            "developers/tutorials/uniswap/swap_publicly",
+            "developers/tutorials/uniswap/execute_public_swap_on_l1",
+            "developers/tutorials/uniswap/swap_privately",
+            "developers/tutorials/uniswap/execute_private_swap_on_l1",
+            "developers/tutorials/uniswap/redeeming_swapped_assets_on_l2",
+            "developers/tutorials/uniswap/typescript_glue_code",
           ],
         },
-        "dev_docs/tutorials/testing",
+        "developers/tutorials/testing",
       ],
     },
 
@@ -293,12 +262,12 @@ const sidebars = {
       type: "category",
       link: {
         type: "doc",
-        id: "dev_docs/cli/main",
+        id: "developers/cli/main",
       },
       items: [
-        "dev_docs/cli/cli-commands",
-        "dev_docs/cli/sandbox-reference",
-        "dev_docs/cli/run_more_than_one_pxe_sandbox"
+        "developers/cli/cli-commands",
+        "developers/cli/sandbox-reference",
+        "developers/cli/run_more_than_one_pxe_sandbox"
       ],
     },
     {
@@ -306,18 +275,18 @@ const sidebars = {
       type: "category",
       link: {
         type: "doc",
-        id: "dev_docs/contracts/main",
+        id: "developers/contracts/main",
       },
       items: [
-        "dev_docs/contracts/workflow",
-        "dev_docs/contracts/setup",
-        "dev_docs/contracts/layout",
+        "developers/contracts/workflow",
+        "developers/contracts/setup",
+        "developers/contracts/layout",
         {
           label: "Syntax",
           type: "category",
           link: {
             type: "doc",
-            id: "dev_docs/contracts/syntax/main",
+            id: "developers/contracts/syntax/main",
           },
           items: [
             {
@@ -325,67 +294,63 @@ const sidebars = {
               type: "category",
               link: {
                 type: "doc",
-                id: "dev_docs/contracts/syntax/storage/main",
+                id: "developers/contracts/syntax/storage/main",
               },
-              items: [
-                "dev_docs/contracts/syntax/storage/public_state",
-                "dev_docs/contracts/syntax/storage/private_state",
-                "dev_docs/contracts/syntax/storage/storage_slots",
-              ],
+              items: ["developers/contracts/syntax/storage/storage_slots"],
             },
-            "dev_docs/contracts/syntax/events",
-            "dev_docs/contracts/syntax/functions",
-            "dev_docs/contracts/syntax/oracles",
+            "developers/contracts/syntax/events",
+            "developers/contracts/syntax/functions",
+            "developers/contracts/syntax/oracles",
             {
               label: "Proving Historical Blockchain Data",
               type: "category",
               items: [
-                "dev_docs/contracts/syntax/historical_access/how_to_prove_history",
-                "dev_docs/contracts/syntax/historical_access/history_lib_reference",
+                "developers/contracts/syntax/historical_access/how_to_prove_history",
+                "developers/contracts/syntax/historical_access/history_lib_reference",
             ],
             },
-            "dev_docs/contracts/syntax/slow_updates_tree",
+            "developers/contracts/syntax/slow_updates_tree",
             
-            "dev_docs/contracts/syntax/context",
-            "dev_docs/contracts/syntax/globals",
+            "developers/contracts/syntax/context",
+            "developers/contracts/syntax/globals",
           ],
         },
-        "dev_docs/contracts/compiling",
-        "dev_docs/contracts/deploying",
-        "dev_docs/contracts/artifacts",
+        "developers/contracts/compiling",
+        "developers/contracts/deploying",
+        "developers/contracts/artifacts",
         {
           label: "Portals",
           type: "category",
           link: {
             type: "doc",
-            id: "dev_docs/contracts/portals/main",
+            id: "developers/contracts/portals/main",
           },
           items: [
-            "dev_docs/contracts/portals/data_structures",
-            "dev_docs/contracts/portals/registry",
-            "dev_docs/contracts/portals/inbox",
-            "dev_docs/contracts/portals/outbox",
+            "developers/contracts/portals/data_structures",
+            "developers/contracts/portals/registry",
+            "developers/contracts/portals/inbox",
+            "developers/contracts/portals/outbox",
           ],
         },
         {
           label: "Resources",
           type: "category",
           items: [
-            "dev_docs/contracts/resources/dependencies",
-            //"dev_docs/contracts/resources/style_guide",
+            "developers/contracts/resources/dependencies",
+            //"developers/contracts/resources/style_guide",
             {
               label: "Common Patterns",
               type: "category",
               link: {
                 type: "doc",
-                id: "dev_docs/contracts/resources/common_patterns/main",
+                id: "developers/contracts/resources/common_patterns/main",
               },
               items: [
-                "dev_docs/contracts/resources/common_patterns/authwit",
-                //         "dev_docs/contracts/resources/common_patterns/sending_tokens_to_user",
-                //         "dev_docs/contracts/resources/common_patterns/sending_tokens_to_contract",
-                //         "dev_docs/contracts/resources/common_patterns/access_control",
-                //         "dev_docs/contracts/resources/common_patterns/interacting_with_l1",
+                "developers/contracts/resources/common_patterns/authwit",
+                //         "developers/contracts/resources/common_patterns/sending_tokens_to_user",
+                //         "developers/contracts/resources/common_patterns/sending_tokens_to_contract",
+                //         "developers/contracts/resources/common_patterns/access_control",
+                //         "developers/contracts/resources/common_patterns/interacting_with_l1",
               ],
             },
           ],
@@ -399,9 +364,9 @@ const sidebars = {
         //       type: "category",
         //       link: {
         //         type: "doc",
-        //         id: "dev_docs/contracts/security/breaking_changes/main",
+        //         id: "developers/contracts/security/breaking_changes/main",
         //       },
-        //       items: ["dev_docs/contracts/security/breaking_changes/v0"],
+        //       items: ["developers/contracts/security/breaking_changes/v0"],
         //     },
         //   ],
         // },
@@ -411,24 +376,24 @@ const sidebars = {
     {
       label: "Aztec.js",
       type: "doc",
-      id: "dev_docs/aztecjs/main",
+      id: "developers/aztecjs/main",
     },
     {
       label: "Debugging",
       type: "category",
       link: {
         type: "doc",
-        id: "dev_docs/debugging/main",
+        id: "developers/debugging/main",
       },
       items: [
-        "dev_docs/debugging/aztecnr-errors",
-        "dev_docs/debugging/sandbox-errors",
+        "developers/debugging/aztecnr-errors",
+        "developers/debugging/sandbox-errors",
       ],
     },
     {
       label: "Updating",
       type: "doc",
-      id: "dev_docs/updating",
+      id: "developers/updating",
     },
 
     {
@@ -436,21 +401,21 @@ const sidebars = {
       type: "category",
       link: {
         type: "doc",
-        id: "dev_docs/testing/main",
+        id: "developers/testing/main",
       },
-      items: ["dev_docs/testing/cheat_codes"],
+      items: ["developers/testing/cheat_codes"],
     },
     {
       label: "Wallets",
       type: "category",
       link: {
         type: "doc",
-        id: "dev_docs/wallets/main",
+        id: "developers/wallets/main",
       },
       items: [
-        "dev_docs/wallets/architecture",
-        "dev_docs/wallets/writing_an_account_contract",
-        "dev_docs/wallets/creating_schnorr_accounts",
+        "developers/wallets/architecture",
+        "developers/wallets/writing_an_account_contract",
+        "developers/wallets/creating_schnorr_accounts",
       ],
     },
 
@@ -459,8 +424,8 @@ const sidebars = {
       type: "category",
       items: [],
     },*/
-    "dev_docs/privacy/main",
-    "dev_docs/limitations/main",
+    "developers/privacy/main",
+    "developers/limitations/main",
 
     {
       label: "API Reference",
@@ -469,7 +434,7 @@ const sidebars = {
         {
           label: "Private Execution Environment (PXE)",
           type: "doc",
-          id: "apis/pxe/interfaces/PXE",
+          id: "developers/apis/pxe/interfaces/PXE",
         },
         {
           label: "Aztec.js",
@@ -494,11 +459,24 @@ const sidebars = {
     {
       type: "html",
       className: "sidebar-title",
-      value: "Miscellaneous",
+      value: "MISCELLANEOUS",
       defaultStyle: true,
     },
     "misc/migration_notes",
     "misc/glossary",
+    {
+      label: "Roadmap",
+      type: "category",
+      link: {
+        type: "doc",
+        id: "misc/roadmap/main",
+      },
+      items: [
+        "misc/roadmap/features_initial_ldt",
+        "misc/roadmap/cryptography_roadmap",
+      ],
+    },
+    "misc/how_to_contribute",
 
     {
       type: "html",
@@ -509,4 +487,4 @@ const sidebars = {
   ],
 };
 
-module.exports = sidebars;
+module.exports = sidebars;
\ No newline at end of file