AztecProtocol · jzaki · Dec 24, 2024 · Dec 17, 2024 · Dec 17, 2024 · Dec 23, 2024
diff --git a/docs/components/snippet.js b/docs/components/snippet.js
@@ -0,0 +1,8 @@
+import React from 'react';
+
+const Spec_Placeholder = () => (
+  <p>The design and implementation have largely changed since the original specification, and these docs will soon be updated to reflect the latest implementation.
+</p>
+);
+
+export default Spec_Placeholder;
diff --git a/...tocol-specs/addresses-and-keys/address.md → ...tocol-specs/addresses-and-keys/address.md b/...tocol-specs/addresses-and-keys/address.md → ...tocol-specs/addresses-and-keys/address.md
diff --git a/...esses-and-keys/diversified-and-stealth.md → ...esses-and-keys/diversified-and-stealth.md b/...esses-and-keys/diversified-and-stealth.md → ...esses-and-keys/diversified-and-stealth.md
diff --git a/...ple-usage/diversified-and-stealth-keys.md → ...ple-usage/diversified-and-stealth-keys.md b/...ple-usage/diversified-and-stealth-keys.md → ...ple-usage/diversified-and-stealth-keys.md
diff --git a/...and-keys/example-usage/encrypt-and-tag.md → ...and-keys/example-usage/encrypt-and-tag.md b/...and-keys/example-usage/encrypt-and-tag.md → ...and-keys/example-usage/encrypt-and-tag.md
diff --git a/...esses-and-keys/example-usage/nullifier.md → ...esses-and-keys/example-usage/nullifier.md b/...esses-and-keys/example-usage/nullifier.md → ...esses-and-keys/example-usage/nullifier.md
diff --git a/.../example-usage/tag-sequence-derivation.md → .../example-usage/tag-sequence-derivation.md b/.../example-usage/tag-sequence-derivation.md → .../example-usage/tag-sequence-derivation.md
diff --git a/...rotocol-specs/addresses-and-keys/index.md → ...rotocol-specs/addresses-and-keys/index.md b/...rotocol-specs/addresses-and-keys/index.md → ...rotocol-specs/addresses-and-keys/index.md
diff --git a/...s/addresses-and-keys/keys-requirements.md → ...s/addresses-and-keys/keys-requirements.md b/...s/addresses-and-keys/keys-requirements.md → ...s/addresses-and-keys/keys-requirements.md
diff --git a/...protocol-specs/addresses-and-keys/keys.md → ...protocol-specs/addresses-and-keys/keys.md b/...protocol-specs/addresses-and-keys/keys.md → ...protocol-specs/addresses-and-keys/keys.md
diff --git a/...l-specs/addresses-and-keys/precompiles.md → ...l-specs/addresses-and-keys/precompiles.md b/...l-specs/addresses-and-keys/precompiles.md → ...l-specs/addresses-and-keys/precompiles.md
diff --git a/docs/docs/protocol-specs/bytecode/index.md → docs/docs/_protocol-specs/bytecode/index.md b/docs/docs/protocol-specs/bytecode/index.md → docs/docs/_protocol-specs/bytecode/index.md
diff --git a/...ocs/protocol-specs/calls/batched-calls.md → ...cs/_protocol-specs/calls/batched-calls.md b/...ocs/protocol-specs/calls/batched-calls.md → ...cs/_protocol-specs/calls/batched-calls.md
diff --git a/...cs/protocol-specs/calls/enqueued-calls.md → ...s/_protocol-specs/calls/enqueued-calls.md b/...cs/protocol-specs/calls/enqueued-calls.md → ...s/_protocol-specs/calls/enqueued-calls.md
diff --git a/docs/docs/protocol-specs/calls/index.md → docs/docs/_protocol-specs/calls/index.md b/docs/docs/protocol-specs/calls/index.md → docs/docs/_protocol-specs/calls/index.md
diff --git a/...l-specs/calls/public-private-messaging.md → ...l-specs/calls/public-private-messaging.md b/...l-specs/calls/public-private-messaging.md → ...l-specs/calls/public-private-messaging.md
diff --git a/...docs/protocol-specs/calls/static-calls.md → ...ocs/_protocol-specs/calls/static-calls.md b/...docs/protocol-specs/calls/static-calls.md → ...ocs/_protocol-specs/calls/static-calls.md
diff --git a/docs/docs/protocol-specs/calls/sync-calls.md → .../docs/_protocol-specs/calls/sync-calls.md b/docs/docs/protocol-specs/calls/sync-calls.md → .../docs/_protocol-specs/calls/sync-calls.md
diff --git a/...otocol-specs/calls/unconstrained-calls.md → ...otocol-specs/calls/unconstrained-calls.md b/...otocol-specs/calls/unconstrained-calls.md → ...otocol-specs/calls/unconstrained-calls.md
diff --git a/...col-specs/circuits/high-level-topology.md → ...col-specs/circuits/high-level-topology.md b/...col-specs/circuits/high-level-topology.md → ...col-specs/circuits/high-level-topology.md
diff --git a/...otocol-specs/circuits/private-function.md → ...otocol-specs/circuits/private-function.md b/...otocol-specs/circuits/private-function.md → ...otocol-specs/circuits/private-function.md
diff --git a/...specs/circuits/private-kernel-initial.mdx → ...specs/circuits/private-kernel-initial.mdx b/...specs/circuits/private-kernel-initial.mdx → ...specs/circuits/private-kernel-initial.mdx
diff --git a/...l-specs/circuits/private-kernel-inner.mdx → ...l-specs/circuits/private-kernel-inner.mdx b/...l-specs/circuits/private-kernel-inner.mdx → ...l-specs/circuits/private-kernel-inner.mdx
diff --git a/...ol-specs/circuits/private-kernel-reset.md → ...ol-specs/circuits/private-kernel-reset.md b/...ol-specs/circuits/private-kernel-reset.md → ...ol-specs/circuits/private-kernel-reset.md
diff --git a/...col-specs/circuits/private-kernel-tail.md → ...col-specs/circuits/private-kernel-tail.md b/...col-specs/circuits/private-kernel-tail.md → ...col-specs/circuits/private-kernel-tail.md
diff --git a/...l-specs/circuits/public-kernel-initial.md → ...l-specs/circuits/public-kernel-initial.md b/...l-specs/circuits/public-kernel-initial.md → ...l-specs/circuits/public-kernel-initial.md
diff --git a/...col-specs/circuits/public-kernel-inner.md → ...col-specs/circuits/public-kernel-inner.md b/...col-specs/circuits/public-kernel-inner.md → ...col-specs/circuits/public-kernel-inner.md
diff --git a/...ocol-specs/circuits/public-kernel-tail.md → ...ocol-specs/circuits/public-kernel-tail.md b/...ocol-specs/circuits/public-kernel-tail.md → ...ocol-specs/circuits/public-kernel-tail.md
diff --git a/docs/docs/protocol-specs/constants.md → docs/docs/_protocol-specs/constants.md b/docs/docs/protocol-specs/constants.md → docs/docs/_protocol-specs/constants.md
diff --git a/...ocol-specs/contract-deployment/classes.md → ...ocol-specs/contract-deployment/classes.md b/...ocol-specs/contract-deployment/classes.md → ...ocol-specs/contract-deployment/classes.md
diff --git a/...otocol-specs/contract-deployment/index.md → ...otocol-specs/contract-deployment/index.md b/...otocol-specs/contract-deployment/index.md → ...otocol-specs/contract-deployment/index.md
diff --git a/...ol-specs/contract-deployment/instances.md → ...ol-specs/contract-deployment/instances.md b/...ol-specs/contract-deployment/instances.md → ...ol-specs/contract-deployment/instances.md
diff --git a/...col-specs/cryptography/hashing/hashing.md → ...col-specs/cryptography/hashing/hashing.md b/...col-specs/cryptography/hashing/hashing.md → ...col-specs/cryptography/hashing/hashing.md
diff --git a/...ol-specs/cryptography/hashing/pedersen.md → ...ol-specs/cryptography/hashing/pedersen.md b/...ol-specs/cryptography/hashing/pedersen.md → ...ol-specs/cryptography/hashing/pedersen.md
diff --git a/...l-specs/cryptography/hashing/poseidon2.md → ...l-specs/cryptography/hashing/poseidon2.md b/...l-specs/cryptography/hashing/poseidon2.md → ...l-specs/cryptography/hashing/poseidon2.md
diff --git a/...docs/protocol-specs/cryptography/index.md → ...ocs/_protocol-specs/cryptography/index.md b/...docs/protocol-specs/cryptography/index.md → ...ocs/_protocol-specs/cryptography/index.md
diff --git a/...otocol-specs/cryptography/merkle-trees.md → ...otocol-specs/cryptography/merkle-trees.md b/...otocol-specs/cryptography/merkle-trees.md → ...otocol-specs/cryptography/merkle-trees.md
diff --git a/...s/cryptography/proving-system/data-bus.md → ...s/cryptography/proving-system/data-bus.md b/...s/cryptography/proving-system/data-bus.md → ...s/cryptography/proving-system/data-bus.md
diff --git a/...s/cryptography/proving-system/overview.md → ...s/cryptography/proving-system/overview.md b/...s/cryptography/proving-system/overview.md → ...s/cryptography/proving-system/overview.md
diff --git a/...phy/proving-system/performance-targets.md → ...phy/proving-system/performance-targets.md b/...phy/proving-system/performance-targets.md → ...phy/proving-system/performance-targets.md
diff --git a/...ata-publication-and-availability/index.md → ...ata-publication-and-availability/index.md b/...ata-publication-and-availability/index.md → ...ata-publication-and-availability/index.md
diff --git a/...-publication-and-availability/overview.md → ...-publication-and-availability/overview.md b/...-publication-and-availability/overview.md → ...-publication-and-availability/overview.md
diff --git a/...cation-and-availability/published-data.md → ...cation-and-availability/published-data.md b/...cation-and-availability/published-data.md → ...cation-and-availability/published-data.md
diff --git a/...protocol-specs/decentralization/actors.md → ...protocol-specs/decentralization/actors.md b/...protocol-specs/decentralization/actors.md → ...protocol-specs/decentralization/actors.md
diff --git a/...pecs/decentralization/block-production.md → ...pecs/decentralization/block-production.md b/...pecs/decentralization/block-production.md → ...pecs/decentralization/block-production.md
diff --git a/...ocol-specs/decentralization/governance.md → ...ocol-specs/decentralization/governance.md b/...ocol-specs/decentralization/governance.md → ...ocol-specs/decentralization/governance.md
diff --git a/...col-specs/decentralization/p2p-network.md → ...col-specs/decentralization/p2p-network.md b/...col-specs/decentralization/p2p-network.md → ...col-specs/decentralization/p2p-network.md
diff --git a/.../protocol-specs/gas-and-fees/fee-juice.md → ..._protocol-specs/gas-and-fees/fee-juice.md b/.../protocol-specs/gas-and-fees/fee-juice.md → ..._protocol-specs/gas-and-fees/fee-juice.md
diff --git a/...otocol-specs/gas-and-fees/fee-schedule.md → ...otocol-specs/gas-and-fees/fee-schedule.md b/...otocol-specs/gas-and-fees/fee-schedule.md → ...otocol-specs/gas-and-fees/fee-schedule.md
diff --git a/...docs/protocol-specs/gas-and-fees/index.md → ...ocs/_protocol-specs/gas-and-fees/index.md b/...docs/protocol-specs/gas-and-fees/index.md → ...ocs/_protocol-specs/gas-and-fees/index.md
diff --git a/...col-specs/gas-and-fees/kernel-tracking.md → ...col-specs/gas-and-fees/kernel-tracking.md b/...col-specs/gas-and-fees/kernel-tracking.md → ...col-specs/gas-and-fees/kernel-tracking.md
diff --git a/...as-and-fees/published-gas-and-fee-data.md → ...as-and-fees/published-gas-and-fee-data.md b/...as-and-fees/published-gas-and-fee-data.md → ...as-and-fees/published-gas-and-fee-data.md
diff --git a/...s/gas-and-fees/specifying-gas-fee-info.md → ...s/gas-and-fees/specifying-gas-fee-info.md b/...s/gas-and-fees/specifying-gas-fee-info.md → ...s/gas-and-fees/specifying-gas-fee-info.md
diff --git a/...ecs/gas-and-fees/tx-setup-and-teardown.md → ...ecs/gas-and-fees/tx-setup-and-teardown.md b/...ecs/gas-and-fees/tx-setup-and-teardown.md → ...ecs/gas-and-fees/tx-setup-and-teardown.md
diff --git a/docs/docs/protocol-specs/intro.md → docs/docs/_protocol-specs/intro.md b/docs/docs/protocol-specs/intro.md → docs/docs/_protocol-specs/intro.md
diff --git a/...ocol-specs/l1-smart-contracts/frontier.md → ...ocol-specs/l1-smart-contracts/frontier.md b/...ocol-specs/l1-smart-contracts/frontier.md → ...ocol-specs/l1-smart-contracts/frontier.md
diff --git a/...rotocol-specs/l1-smart-contracts/index.md → ...rotocol-specs/l1-smart-contracts/index.md b/...rotocol-specs/l1-smart-contracts/index.md → ...rotocol-specs/l1-smart-contracts/index.md
diff --git a/docs/docs/protocol-specs/logs/index.md → docs/docs/_protocol-specs/logs/index.md b/docs/docs/protocol-specs/logs/index.md → docs/docs/_protocol-specs/logs/index.md
diff --git a/...col-specs/pre-compiled-contracts/index.md → ...col-specs/pre-compiled-contracts/index.md b/...col-specs/pre-compiled-contracts/index.md → ...col-specs/pre-compiled-contracts/index.md
diff --git a/...-specs/pre-compiled-contracts/registry.md → ...-specs/pre-compiled-contracts/registry.md b/...-specs/pre-compiled-contracts/registry.md → ...-specs/pre-compiled-contracts/registry.md
diff --git a/...l-specs/private-message-delivery/index.md → ...l-specs/private-message-delivery/index.md b/...l-specs/private-message-delivery/index.md → ...l-specs/private-message-delivery/index.md
diff --git a/...-message-delivery/private-msg-delivery.md → ...-message-delivery/private-msg-delivery.md b/...-message-delivery/private-msg-delivery.md → ...-message-delivery/private-msg-delivery.md
diff --git a/...-message-delivery/send-note-guidelines.md → ...-message-delivery/send-note-guidelines.md b/...-message-delivery/send-note-guidelines.md → ...-message-delivery/send-note-guidelines.md
diff --git a/...otocol-specs/public-vm/_nested-context.md → ...otocol-specs/public-vm/_nested-context.md b/...otocol-specs/public-vm/_nested-context.md → ...otocol-specs/public-vm/_nested-context.md
diff --git a/docs/docs/protocol-specs/public-vm/alu.md → docs/docs/_protocol-specs/public-vm/alu.md b/docs/docs/protocol-specs/public-vm/alu.md → docs/docs/_protocol-specs/public-vm/alu.md
diff --git a/...s/protocol-specs/public-vm/avm-circuit.md → .../_protocol-specs/public-vm/avm-circuit.md b/...s/protocol-specs/public-vm/avm-circuit.md → .../_protocol-specs/public-vm/avm-circuit.md
diff --git a/.../public-vm/bytecode-validation-circuit.md → .../public-vm/bytecode-validation-circuit.md b/.../public-vm/bytecode-validation-circuit.md → .../public-vm/bytecode-validation-circuit.md
diff --git a/...protocol-specs/public-vm/circuit-index.md → ...protocol-specs/public-vm/circuit-index.md b/...protocol-specs/public-vm/circuit-index.md → ...protocol-specs/public-vm/circuit-index.md
diff --git a/...docs/protocol-specs/public-vm/context.mdx → ...ocs/_protocol-specs/public-vm/context.mdx b/...docs/protocol-specs/public-vm/context.mdx → ...ocs/_protocol-specs/public-vm/context.mdx
diff --git a/.../protocol-specs/public-vm/control-flow.md → ..._protocol-specs/public-vm/control-flow.md b/.../protocol-specs/public-vm/control-flow.md → ..._protocol-specs/public-vm/control-flow.md
diff --git a/...ocs/protocol-specs/public-vm/execution.md → ...cs/_protocol-specs/public-vm/execution.md b/...ocs/protocol-specs/public-vm/execution.md → ...cs/_protocol-specs/public-vm/execution.md
diff --git a/docs/docs/_protocol-specs/public-vm/gen/_instruction-set.mdx b/docs/docs/_protocol-specs/public-vm/gen/_instruction-set.mdx
diff --git a/docs/docs/protocol-specs/public-vm/index.md → docs/docs/_protocol-specs/public-vm/index.md b/docs/docs/protocol-specs/public-vm/index.md → docs/docs/_protocol-specs/public-vm/index.md
diff --git a/...tocol-specs/public-vm/instruction-set.mdx → ...tocol-specs/public-vm/instruction-set.mdx b/...tocol-specs/public-vm/instruction-set.mdx → ...tocol-specs/public-vm/instruction-set.mdx
diff --git a/docs/docs/protocol-specs/public-vm/intro.md → docs/docs/_protocol-specs/public-vm/intro.md b/docs/docs/protocol-specs/public-vm/intro.md → docs/docs/_protocol-specs/public-vm/intro.md
diff --git a/.../protocol-specs/public-vm/memory-model.md → ..._protocol-specs/public-vm/memory-model.md b/.../protocol-specs/public-vm/memory-model.md → ..._protocol-specs/public-vm/memory-model.md
diff --git a/...protocol-specs/public-vm/nested-calls.mdx → ...protocol-specs/public-vm/nested-calls.mdx b/...protocol-specs/public-vm/nested-calls.mdx → ...protocol-specs/public-vm/nested-calls.mdx
diff --git a/...docs/protocol-specs/public-vm/security.md → ...ocs/_protocol-specs/public-vm/security.md b/...docs/protocol-specs/public-vm/security.md → ...ocs/_protocol-specs/public-vm/security.md
diff --git a/docs/docs/protocol-specs/public-vm/state.md → docs/docs/_protocol-specs/public-vm/state.md b/docs/docs/protocol-specs/public-vm/state.md → docs/docs/_protocol-specs/public-vm/state.md
diff --git a/.../protocol-specs/public-vm/type-structs.md → ..._protocol-specs/public-vm/type-structs.md b/.../protocol-specs/public-vm/type-structs.md → ..._protocol-specs/public-vm/type-structs.md
diff --git a/...ocol-specs/rollup-circuits/base-rollup.md → ...ocol-specs/rollup-circuits/base-rollup.md b/...ocol-specs/rollup-circuits/base-rollup.md → ...ocol-specs/rollup-circuits/base-rollup.md
diff --git a/...s/protocol-specs/rollup-circuits/index.md → .../_protocol-specs/rollup-circuits/index.md b/...s/protocol-specs/rollup-circuits/index.md → .../_protocol-specs/rollup-circuits/index.md
diff --git a/...col-specs/rollup-circuits/merge-rollup.md → ...col-specs/rollup-circuits/merge-rollup.md b/...col-specs/rollup-circuits/merge-rollup.md → ...col-specs/rollup-circuits/merge-rollup.md
diff --git a/...ocol-specs/rollup-circuits/root-rollup.md → ...ocol-specs/rollup-circuits/root-rollup.md b/...ocol-specs/rollup-circuits/root-rollup.md → ...ocol-specs/rollup-circuits/root-rollup.md
diff --git a/...ocol-specs/rollup-circuits/tree-parity.md → ...ocol-specs/rollup-circuits/tree-parity.md b/...ocol-specs/rollup-circuits/tree-parity.md → ...ocol-specs/rollup-circuits/tree-parity.md
diff --git a/docs/docs/protocol-specs/state/archive.md → docs/docs/_protocol-specs/state/archive.md b/docs/docs/protocol-specs/state/archive.md → docs/docs/_protocol-specs/state/archive.md
diff --git a/docs/docs/protocol-specs/state/index.md → docs/docs/_protocol-specs/state/index.md b/docs/docs/protocol-specs/state/index.md → docs/docs/_protocol-specs/state/index.md
diff --git a/...cs/protocol-specs/state/note-hash-tree.md → ...s/_protocol-specs/state/note-hash-tree.md b/...cs/protocol-specs/state/note-hash-tree.md → ...s/_protocol-specs/state/note-hash-tree.md
diff --git a/...cs/protocol-specs/state/nullifier-tree.md → ...s/_protocol-specs/state/nullifier-tree.md b/...cs/protocol-specs/state/nullifier-tree.md → ...s/_protocol-specs/state/nullifier-tree.md
diff --git a/.../protocol-specs/state/public-data-tree.md → ..._protocol-specs/state/public-data-tree.md b/.../protocol-specs/state/public-data-tree.md → ..._protocol-specs/state/public-data-tree.md
diff --git a/...tocol-specs/state/tree-implementations.md → ...tocol-specs/state/tree-implementations.md b/...tocol-specs/state/tree-implementations.md → ...tocol-specs/state/tree-implementations.md
diff --git a/docs/docs/protocol-specs/state/wonky-tree.md → .../docs/_protocol-specs/state/wonky-tree.md b/docs/docs/protocol-specs/state/wonky-tree.md → .../docs/_protocol-specs/state/wonky-tree.md
diff --git a/docs/docs/protocol-specs/todo.md → docs/docs/_protocol-specs/todo.md b/docs/docs/protocol-specs/todo.md → docs/docs/_protocol-specs/todo.md
diff --git a/...docs/protocol-specs/transactions/index.md → ...ocs/_protocol-specs/transactions/index.md b/...docs/protocol-specs/transactions/index.md → ...ocs/_protocol-specs/transactions/index.md
diff --git a/...col-specs/transactions/local-execution.md → ...col-specs/transactions/local-execution.md b/...col-specs/transactions/local-execution.md → ...col-specs/transactions/local-execution.md
diff --git a/...ol-specs/transactions/public-execution.md → ...ol-specs/transactions/public-execution.md b/...ol-specs/transactions/public-execution.md → ...ol-specs/transactions/public-execution.md
diff --git a/.../protocol-specs/transactions/tx-object.md → ..._protocol-specs/transactions/tx-object.md b/.../protocol-specs/transactions/tx-object.md → ..._protocol-specs/transactions/tx-object.md
diff --git a/...s/protocol-specs/transactions/validity.md → .../_protocol-specs/transactions/validity.md b/...s/protocol-specs/transactions/validity.md → .../_protocol-specs/transactions/validity.md
diff --git a/docs/docs/aztec/concepts/accounts/index.md b/docs/docs/aztec/concepts/accounts/index.md
@@ -156,5 +156,3 @@ NOTE: While we entertained the idea of abstracting note encryption, where accoun
 In order to be considered valid, an account must prove that it has locked enough funds to pay for itself. However, this does not mandate where those funds come from. This fee abstraction allows for easy implementation of paymasters or payment-in-kind via on-the-fly swaps.
 
 However, there is one major consideration around public execution reverts. In the current design, if one of the public function executions enqueued in a transaction fails, then the entire transaction is reverted. But reverting the whole transaction would also revert the fee payment, and leave the sequencer with their hands empty after running the public execution. This means we will need to enshrine an initial verification and fee payment phase that is _not_ reverted if public execution fails.
-
-You can read the latest information about fees in the [protocol specs](../../../protocol-specs/gas-and-fees/index.md).
diff --git a/docs/docs/aztec/concepts/accounts/keys.md b/docs/docs/aztec/concepts/accounts/keys.md
@@ -4,7 +4,6 @@ tags: [accounts, keys]
 ---
 
 The goal of this section is to give app developer a good idea what keys there are used in the system.
-For a detailed description head over to the [protocol specification](../../../protocol-specs/addresses-and-keys/index.md).
 
 In short, there is a **nullifier key** (to spend your notes), an **incoming viewing key** (to view any notes or logs that were sent to you), an **outgoing viewing key** (to view any logs or notes you sent to another entity), a **tagging key** (to quickly find notes relevant to you) and oftentimes a signing key. A signing key is not strictly required by the protocol, but are often used with specific account contracts for authorization purposes.
 
@@ -13,10 +12,10 @@ Each account in Aztec is backed by 4 key pairs:
 - A **nullifier key pair** used for note nullifier computation, comprising the master nullifier secret key (`nsk_m`) and master nullifier public key (`Npk_m`).
 - An **incoming viewing key pair** used to encrypt a note for the recipient, consisting of the master incoming viewing secret key (`ivsk_m`) and master incoming viewing public key (`Ivpk_m`).
 - An **outgoing viewing key pair** used to encrypt a note for the sender, includes the master outgoing viewing secret key (`ovsk_m`) and master outgoing viewing public key (`Ovpk_m`).
-- A **tagging key pair** used to compute tags in a [tagging note discovery scheme](../../../protocol-specs/private-message-delivery/private-msg-delivery.md#note-tagging), comprising the master tagging secret key (`tsk_m`) and master tagging public key (`Tpk_m`).
+- A **tagging key pair** used to compute tags in a tagging note discovery scheme, comprising the master tagging secret key (`tsk_m`) and master tagging public key (`Tpk_m`).
 
 :::info
-All key pairs above are derived from a secret using a ZCash inspired scheme defined in [protocol specification](../../../protocol-specs/addresses-and-keys/keys.md#cheat-sheet).
+Key pairs are derived from a secret using a ZCash inspired scheme.
 :::
 
 :::note
@@ -52,7 +51,6 @@ If that happens, only the nullifier secret for that application is compromised (
 Above we mentioned that the notes typically contain `Npk_m`.
 It might seem like a mistake given that the notes are nullified with `nsk_app`.
 This is intentional and instead of directly trying to derive `Npk_m` from `nsk_app` we instead verify that both of the keys were derived from the same `nsk_m` in our protocol circuits.
-If you are curious how the derivation scheme works head over to [protocol specification](../../../protocol-specs/addresses-and-keys/example-usage/nullifier#diagram).
 
 ## Protocol key types
 
@@ -71,7 +69,7 @@ An application in Aztec.nr can request a secret from the current user for comput
 
 Typically, `Npk_m` is stored in a note and later on, the note is nullified using the secret app-siloed version (denoted `nsk_app`).
 `nsk_app` is derived by hashing `nsk_m` with the app contract address and it is necessary to present it to compute the nullifier.
-Validity of `nsk_app` is verified by our [protocol kernel circuits](../../../protocol-specs/circuits/private-kernel-tail#verifying-and-splitting-ordered-data).
+Validity of `nsk_app` is verified by our protocol kernel circuits.
 
 ## Incoming viewing keys
 
@@ -86,7 +84,7 @@ If these keys were not used and a new device would be synched there would be no
 
 ## Tagging keys
 
-Used to compute tags in a [tagging note discovery scheme](../../../protocol-specs/private-message-delivery/private-msg-delivery#note-tagging).
+Used to compute tags in a tagging note discovery scheme.
 
 :::note
 Tagging note discovery scheme won't be present in our testnet so we are intentionally not providing you with much info yet.

diff --git a/docs/docs/aztec/concepts/circuits/index.md b/docs/docs/aztec/concepts/circuits/index.md
@@ -61,14 +61,6 @@ What kind of extra rules / checks does a rollup need, to enforce notions of priv
 
 So what kinds of core protocol circuits does Aztec have?
 
-### Kernel Circuits
+### Kernel, Rollup, and Squisher Circuits
 
-Read more about the Kernel circuits in the protocol specs [here](../../../protocol-specs/circuits/high-level-topology.md).
-
-### Rollup Circuits
-
-- [Rollup Circuits](../../../protocol-specs/rollup-circuits/index.md)
-
-#### Squisher Circuits
-
-We haven't fully spec'ed these out, as Honk and Goblin Plonk schemes are still being improved! But we'll need some extra circuit(s) to squish a Honk proof (as produced by the Root Rollup Circuit) into a Standard Plonk or Fflonk proof, for cheap verification on Ethereum.
+The specs of these have recently been updated. Eg for squisher circuits since Honk and Goblin Plonk schemes are still being improved! But we'll need some extra circuit(s) to squish a Honk proof (as produced by the Root Rollup Circuit) into a Standard Plonk or Fflonk proof, for cheap verification on Ethereum.
diff --git a/docs/docs/aztec/concepts/circuits/kernels/private_kernel.md b/docs/docs/aztec/concepts/circuits/kernels/private_kernel.md
@@ -5,8 +5,6 @@ tags: [protocol, circuits]
 
 This circuit is executed by the user, on their own device. This is to ensure private inputs to the circuit remain private!
 
-Read the latest information about the Aztec Private Kernel Circuit in the [protocol specs section](../../../../protocol-specs/circuits/private-kernel-tail.md).
-
 :::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).

diff --git a/docs/docs/aztec/concepts/circuits/kernels/public_kernel.md b/docs/docs/aztec/concepts/circuits/kernels/public_kernel.md
@@ -4,5 +4,3 @@ tags: [protocol, circuits]
 ---
 
 This circuit is executed by a Sequencer, since only a Sequencer knows the current state of the [public data tree](../../storage/trees/index.md) at any time. A Sequencer might choose to delegate proof generation to the Prover pool.
-
-Read more about the public kernel circuits in the protocol specs [here](../../../../protocol-specs/circuits/public-kernel-initial.md).
diff --git a/docs/docs/aztec/concepts/circuits/rollup_circuits/index.md b/docs/docs/aztec/concepts/circuits/rollup_circuits/index.md
@@ -15,5 +15,3 @@ The way we 'squish' all this data is in a 'binary tree of proofs' topology.
 > Note: 'binary tree of proofs' is actually an oversimplification. The Rollup Circuits are designed so that a Sequencer can actually deviate from a neat, symmetrical tree, for the purposes of efficiency, and instead sometimes create wonky trees.
 
 Some of the Rollup Circuits also do some protocol checks and computations, for efficiency reasons. We might rearrange which circuit does what computation, as we discover opportunities for efficiency.
-
-Read more about the rollup circuits in the protocol spec [here](../../../../protocol-specs/rollup-circuits/index.md).
diff --git a/docs/docs/aztec/concepts/communication/cross_chain_calls.md b/docs/docs/aztec/concepts/communication/cross_chain_calls.md
@@ -150,7 +150,3 @@ To make it possible to hide when a specific message is consumed, the `L1ToL2Msg`
 The following diagram shows the overall architecture, combining the earlier sections.
 
 <Image img={require("/img/com-abs-7.png")} />
-
-## Learn more
-
-Check out the [protocol specs](../../../protocol-specs/l1-smart-contracts#portals) for more information about cross-chain communication and contracts on L1.
diff --git a/docs/docs/aztec/concepts/storage/partial_notes.md b/docs/docs/aztec/concepts/storage/partial_notes.md
@@ -10,7 +10,7 @@ Partial notes are a concept that allows users to commit to an encrypted value, a
 
 Why is this useful?
 
-Consider the case where a user wants to pay for a transaction fee, using a [fee-payment contract](../../../protocol-specs/gas-and-fees/index.md) and they want to do this privately. They can't be certain what the transaction fee will be because the state of the network will have progressed by the time the transaction is processed by the sequencer, and transaction fees are dynamic. So the user can commit to a value for the transaction fee, publicly post this commitment, the fee payer (aka paymaster) can update the public commitment, deducting the final cost of the transaction from the commitment and returning the unused value to the user.
+Consider the case where a user wants to pay for a transaction fee, using a fee-payment contract and they want to do this privately. They can't be certain what the transaction fee will be because the state of the network will have progressed by the time the transaction is processed by the sequencer, and transaction fees are dynamic. So the user can commit to a value for the transaction fee, publicly post this commitment, the fee payer (aka paymaster) can update the public commitment, deducting the final cost of the transaction from the commitment and returning the unused value to the user.
 
 So, in general, the user is:
 

diff --git a/docs/docs/aztec/concepts/storage/state_model/public_vm.md b/docs/docs/aztec/concepts/storage/state_model/public_vm.md
@@ -2,4 +2,6 @@
 title: Public VM
 ---
 
-Refer to the [protocol specs section](../../../../protocol-specs/public-vm/index.md) for the latest information about the Aztec Public VM.
+import Spec_Placeholder from '/components/snippet';
+
+<Spec_Placeholder />
diff --git a/docs/docs/aztec/concepts/storage/trees/index.md b/docs/docs/aztec/concepts/storage/trees/index.md
@@ -2,4 +2,6 @@
 title: Trees
 ---
 
-Refer to [this section](../../../../protocol-specs/state/index.md) of the protocol specification for the latest information on the trees used in Aztec.
+import Spec_Placeholder from '/components/snippet';
+
+<Spec_Placeholder />
diff --git a/docs/docs/aztec/concepts/transactions.md b/docs/docs/aztec/concepts/transactions.md
@@ -31,9 +31,9 @@ _The transaction has not been broadcasted to the sequencer network yet. For now,
 
 _The transaction has still not been broadcasted to the sequencer network yet and continues to live solely within the context of the PXE._
 
-3. **The PXE proves correct execution** – At this point, the PXE proves correct execution (via zero-knowledge proofs) of the authorization and of the private transfer method. Once the proofs have been generated, the PXE sends the proofs and required inputs (inputs are new note commitments, stored in the [note hash tree](../../protocol-specs/state/note-hash-tree.md) and nullifiers stored in the [nullifiers tree](../../protocol-specs/state/nullifier-tree.md)) to the sequencer. Nullifiers are data that invalidate old commitments, ensuring that commitments can only be used once.
+3. **The PXE proves correct execution** – At this point, the PXE proves correct execution (via zero-knowledge proofs) of the authorization and of the private transfer method. Once the proofs have been generated, the PXE sends the proofs and required inputs (inputs are new note commitments, stored in the note hash tree and nullifiers stored in the nullifiers tree) to the sequencer. Nullifiers are data that invalidate old commitments, ensuring that commitments can only be used once.
 
-_The sequencer has received the transaction proof and can begin to process the transaction - verifying proofs and applying updates to the relevant [data trees](../../protocol-specs/state/index.md) - alongside other public and private transactions._
+_The sequencer has received the transaction proof and can begin to process the transaction - verifying proofs and applying updates to the relevant data trees - alongside other public and private transactions._
 
 4. **The sequencer has the necessary information to act** – the randomly-selected sequencer (based on the Fernet sequencer selection protocol) validates the transaction proofs along with required inputs (e.g. the note commitments and nullifiers) for this private transfer. The sequencer also executes public functions and requests proofs of public execution from a prover network. The sequencer updates the corresponding data trees and does the same for other private transactions. When the sequencer receives proofs from the prover network, the proofs will be bundled into a final rollup proof.
 

diff --git a/docs/docs/aztec/concepts/wallets/index.md b/docs/docs/aztec/concepts/wallets/index.md
@@ -28,9 +28,9 @@ Note that users must be able to receive funds in Aztec before deploying their ac
 
 Every transaction in Aztec is broadcast to the network as a zero-knowledge proof of correct execution, in order to preserve privacy. This means that transaction proofs are generated on the wallet and not on a remote node. This is one of the biggest differences with regard to EVM chain wallets.
 
-A wallet is responsible for **creating** an _execution request_ out of one or more _function calls_ requested by a dapp. For example, a dapp may request a wallet to "invoke the `transfer` function on the contract at `0x1234` with the following arguments", in response to a user action. The wallet [turns that into an execution request](../../../protocol-specs/transactions/local-execution.md#execution-request) with the signed instructions to execute that function call from the user's account contract. In an [ECDSA-based account](https://github.com/AztecProtocol/aztec-packages/blob/master/noir-projects/noir-contracts/contracts/ecdsa_k_account_contract/src/main.nr), for instance, this is an execution request that encodes the function call in the _entrypoint payload_, and includes its ECDSA signature with the account's signing private key.
+A wallet is responsible for **creating** an _execution request_ out of one or more _function calls_ requested by a dapp. For example, a dapp may request a wallet to "invoke the `transfer` function on the contract at `0x1234` with the following arguments", in response to a user action. The wallet turns that into an execution request with the signed instructions to execute that function call from the user's account contract. In an [ECDSA-based account](https://github.com/AztecProtocol/aztec-packages/blob/master/noir-projects/noir-contracts/contracts/ecdsa_k_account_contract/src/main.nr), for instance, this is an execution request that encodes the function call in the _entrypoint payload_, and includes its ECDSA signature with the account's signing private key.
 
-Once the _execution request_ is created, the wallet is responsible for **simulating** and **proving** the execution of its private functions. The simulation yields an execution trace, which can be used to provide the user with a list of side effects of the private execution of the transaction. During this simulation, the wallet is responsible of providing data to the virtual machine, such as private notes, encryption keys, or nullifier secrets. This execution trace is fed into the prover, which returns a zero-knowledge proof that guarantees correct execution and hides all private information. The output of this process is a [_transaction object_](../../../protocol-specs/transactions/tx-object.md).
+Once the _execution request_ is created, the wallet is responsible for **simulating** and **proving** the execution of its private functions. The simulation yields an execution trace, which can be used to provide the user with a list of side effects of the private execution of the transaction. During this simulation, the wallet is responsible of providing data to the virtual machine, such as private notes, encryption keys, or nullifier secrets. This execution trace is fed into the prover, which returns a zero-knowledge proof that guarantees correct execution and hides all private information. The output of this process is a _transaction object_.
 
 :::info
 Since private functions rely on a UTXO model, the private execution trace of a transaction is determined exclusively by the notes used as inputs. Since these notes are immutable, the trace of a transaction is always the same, so any effects observed during simulation will be exactly the same when the transaction is mined. However, the transaction may be dropped if it attempts to consume a private note that another transaction nullified before it gets mined. Note that this applies only to private function execution. Public functions rely on an account model, similar to Ethereum, so their execution trace depends on the chain's public state at the point they are included in a block, which may have changed since the transaction was simulated locally.

diff --git a/docs/docs/aztec/concepts_overview.md b/docs/docs/aztec/concepts_overview.md
@@ -10,7 +10,7 @@ This page outlines Aztec's fundamental technical concepts. It is recommended to
 
 ## What is Aztec?
 
-Aztec is a privacy-first Layer 2 on Ethereum. It supports smart contracts with both private & public state and private & public execution. 
+Aztec is a privacy-first Layer 2 on Ethereum. It supports smart contracts with both private & public state and private & public execution.
 
 ## High level view
 
@@ -33,7 +33,7 @@ Private functions are executed first on the user's device in the Private Executi
 
 ### Aztec VM
 
-Public functions are executed by the Aztec Virtual Machine (AVM), which is conceptually similar to the Ethereum Virtual Machine (EVM). To learn more about how it works and its instruction set, go to the [protocol specs](../protocol-specs/public-vm/intro.md).
+Public functions are executed by the Aztec Virtual Machine (AVM), which is conceptually similar to the Ethereum Virtual Machine (EVM).
 
 The PXE is unaware of the Public VM. And the Public VM is unaware of the PXE. They are completely separate execution environments. This means:
 
@@ -54,7 +54,7 @@ Aztec [smart contract](./smart_contracts_overview.md) developers should keep in
 
 ### Account abstraction
 
-Every account in Aztec is a smart contract (account abstraction). This allows implementing different schemes for authorizing transactions, nonce management, and fee payments. 
+Every account in Aztec is a smart contract (account abstraction). This allows implementing different schemes for authorizing transactions, nonce management, and fee payments.
 
 Developers can write their own account contract to define the rules by which user transactions are authorized and paid for, as well as how user keys are managed.
 

diff --git a/docs/docs/aztec/smart_contracts/contract_creation.md b/docs/docs/aztec/smart_contracts/contract_creation.md
@@ -3,7 +3,9 @@ title: Contract Deployment
 tags: [contracts, protocol]
 ---
 
-The latest information about contract deployment has moved to the protocol specification. You can find it [here](../../protocol-specs/contract-deployment/index.md).
+import Spec_Placeholder from '/components/snippet';
+
+<Spec_Placeholder />
 
 ## Further reading
 

diff --git a/docs/docs/aztec/smart_contracts/functions/context.md b/docs/docs/aztec/smart_contracts/functions/context.md
@@ -127,7 +127,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](../../../protocol-specs/l1-smart-contracts/index.md) on the execution of each rollup.
+New L2 to L1 messages contains messages that are delivered to the l1 outbox on the execution of each rollup.
 
 ## Public Context
 

diff --git a/.../docs/guides/developer_guides/smart_contracts/writing_contracts/initializers.md b/.../docs/guides/developer_guides/smart_contracts/writing_contracts/initializers.md
@@ -45,6 +45,4 @@ You can set multiple functions as an initializer function simply by annotating e
 
 Calling any one of the functions annotated with `#[initializer]` will mark the contract as initialized.
 
-See [this page of the protocol specs](../../../../protocol-specs/contract-deployment/instances.md#initialization) for more info about what marking a function as initialized means.
-
 To see an initializer in action, follow the [Counter codealong tutorial](../../../../tutorials/codealong/contract_tutorials/counter_contract.md).
diff --git a/...per_guides/smart_contracts/writing_contracts/portals/communicate_with_portal.md b/...per_guides/smart_contracts/writing_contracts/portals/communicate_with_portal.md
@@ -3,8 +3,6 @@ title: Communicating with L1
 tags: [contracts, portals]
 ---
 
-Is this your first time hearing the word `Portal`? You might want to check out the [protocol specs](../../../../../protocol-specs/l1-smart-contracts/index.md).
-
 Follow the [token bridge tutorial](../../../../../tutorials/codealong/contract_tutorials/token_bridge/index.md) for hands-on experience writing and deploying a Portal contract.
 
 ## Passing data to the rollup
Original file line number	Diff line number	Diff line change
Expand Up		@@ -156,5 +156,3 @@ NOTE: While we entertained the idea of abstracting note encryption, where accoun
		In order to be considered valid, an account must prove that it has locked enough funds to pay for itself. However, this does not mandate where those funds come from. This fee abstraction allows for easy implementation of paymasters or payment-in-kind via on-the-fly swaps.

		However, there is one major consideration around public execution reverts. In the current design, if one of the public function executions enqueued in a transaction fails, then the entire transaction is reverted. But reverting the whole transaction would also revert the fee payment, and leave the sequencer with their hands empty after running the public execution. This means we will need to enshrine an initial verification and fee payment phase that is _not_ reverted if public execution fails.

		You can read the latest information about fees in the [protocol specs](../../../protocol-specs/gas-and-fees/index.md).
-Original file line number
+Diff line change
@@ Expand Up / @@ -5,8 +5,6 @@ tags: [protocol, circuits] @@
     This circuit is executed by the user, on their own device. This is to ensure private inputs to the circuit remain private!
-    Read the latest information about the Aztec Private Kernel Circuit in the [protocol specs section](../../../../protocol-specs/circuits/private-kernel-tail.md).
     :::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).
@@ Expand Down @@
Original file line number	Diff line number	Diff line change
Expand Up		@@ -4,5 +4,3 @@ tags: [protocol, circuits]
		---

		This circuit is executed by a Sequencer, since only a Sequencer knows the current state of the [public data tree](../../storage/trees/index.md) at any time. A Sequencer might choose to delegate proof generation to the Prover pool.

		Read more about the public kernel circuits in the protocol specs [here](../../../../protocol-specs/circuits/public-kernel-initial.md).
Original file line number	Diff line number	Diff line change
Expand Up		@@ -15,5 +15,3 @@ The way we 'squish' all this data is in a 'binary tree of proofs' topology.
		> Note: 'binary tree of proofs' is actually an oversimplification. The Rollup Circuits are designed so that a Sequencer can actually deviate from a neat, symmetrical tree, for the purposes of efficiency, and instead sometimes create wonky trees.

		Some of the Rollup Circuits also do some protocol checks and computations, for efficiency reasons. We might rearrange which circuit does what computation, as we discover opportunities for efficiency.

		Read more about the rollup circuits in the protocol spec [here](../../../../protocol-specs/rollup-circuits/index.md).
Original file line number	Diff line number	Diff line change
Expand Up		@@ -45,6 +45,4 @@ You can set multiple functions as an initializer function simply by annotating e

		Calling any one of the functions annotated with `#[initializer]` will mark the contract as initialized.

		See [this page of the protocol specs](../../../../protocol-specs/contract-deployment/instances.md#initialization) for more info about what marking a function as initialized means.

		To see an initializer in action, follow the [Counter codealong tutorial](../../../../tutorials/codealong/contract_tutorials/counter_contract.md).