From d87c56d5996769d6a4daf06fabf41c829530702a Mon Sep 17 00:00:00 2001
From: Cat McGee <hello@mcgee.cat>
Date: Thu, 8 Aug 2024 11:09:43 +0100
Subject: [PATCH 01/12] update twitter link

---
 docs/docusaurus.config.js | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/docs/docusaurus.config.js b/docs/docusaurus.config.js
index f46a98abadf1..44f6ec5f9af7 100644
--- a/docs/docusaurus.config.js
+++ b/docs/docusaurus.config.js
@@ -317,7 +317,7 @@ const config = {
                 rel: "noopener noreferrer",
               },
               {
-                to: "https://twitter.com/aztecprotocol",
+                to: "https://x.com/aztecnetwork",
                 label: "X/Twitter",
                 target: "_blank",
                 rel: "noopener noreferrer",
@@ -359,7 +359,7 @@ const config = {
                 href: "https://discord.gg/DgWG2DBMyB",
               },
               {
-                label: "X/Twitter",
+                label: "X (Twitter)",
                 href: "https://twitter.com/aztecnetwork",
               },
               {

From abbf8c32f54cab6a8829735497268678b054fff1 Mon Sep 17 00:00:00 2001
From: Cat McGee <hello@mcgee.cat>
Date: Thu, 8 Aug 2024 11:15:33 +0100
Subject: [PATCH 02/12] resources dropdown

---
 docs/docusaurus.config.js | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/docs/docusaurus.config.js b/docs/docusaurus.config.js
index 44f6ec5f9af7..746da4354044 100644
--- a/docs/docusaurus.config.js
+++ b/docs/docusaurus.config.js
@@ -290,14 +290,14 @@ const config = {
               {
                 type: "docSidebar",
                 sidebarId: "protocolSpecSidebar",
-                target: "_blank",
                 label: "Protocol Specification",
+                className: "no-external-icon",
               },
               {
                 type: "docSidebar",
                 sidebarId: "roadmapSidebar",
-                target: "_blank",
                 label: "Roadmap",
+                className: "no-external-icon",
               },
               {
                 to: "https://noir-lang.org/docs",

From a011df4816014f2131279970df947d2b40b4f01b Mon Sep 17 00:00:00 2001
From: Cat McGee <hello@mcgee.cat>
Date: Thu, 8 Aug 2024 11:31:23 +0100
Subject: [PATCH 03/12] themed cookies popup

---
 docs/src/css/custom.css | 31 +++++++++++--------------------
 1 file changed, 11 insertions(+), 20 deletions(-)

diff --git a/docs/src/css/custom.css b/docs/src/css/custom.css
index 07c07791dfa1..c41961437a41 100644
--- a/docs/src/css/custom.css
+++ b/docs/src/css/custom.css
@@ -19,6 +19,7 @@
   --ifm-link-color: #8C7EFF;
   --ifm-menu-color-active: #8C7EFF;
   --ifm-navbar-link-hover-color: #8C7EFF;
+  --docsearch-modal-background: white;
 }
 
 [data-theme="light"] .alert--danger {
@@ -170,24 +171,6 @@ a {
   color: #8C7EFF;
 }
 
-/* Style for tip admonitions */
-.admonition-tip {
-  background-color: rgba(49, 166, 123, 0.1);
-  border-left-color: #31A67B;
-}
-
-.admonition-tip .admonition-icon svg {
-  fill: #31A67B;
-}
-
-.admonition-warning, .admonition-danger {
-  background-color: rgba(255, 119, 100, 0.1);
-  border-left-color: #FF7764;
-}
-
-.admonition-warning .admonition-icon svg, .admonition-danger .admonition-icon svg {
-  fill: #FF7764;
-}
 .code-block-error-line {
   background-color: #f0000038;
   display: block;
@@ -228,7 +211,15 @@ html[data-theme="dark"] .sidebar-divider {
 }
 
 [data-theme="light"] #optout-form {
-  background: #f6fbfc;
+  background: white;
+}
+
+[data-theme="light"] .button--secondary{
+  background: var(--ifm-color-primary-lightest);
+}
+
+[data-theme="dark"] .button--secondary {
+  background: var(--ifm-color-primary-dark);
 }
 
 #optout-form {
@@ -246,7 +237,7 @@ html[data-theme="dark"] .sidebar-divider {
   padding: 1.5rem 2rem;
   display: flex;
   flex-direction: column;
-  border: 1px solid #bec2c3;
+  border: 1px solid var(--ifm-color-primary-lightest);
   border-radius: 12px;
 }
 

From 0422ba87dc89ce3a1da37e5bd5c8e6b227e6cf99 Mon Sep 17 00:00:00 2001
From: josh crites <critesjosh@gmail.com>
Date: Thu, 8 Aug 2024 12:39:07 -0400
Subject: [PATCH 04/12] Update overview.md

---
 .../docs/protocol-specs/cryptography/proving-system/overview.md | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/docs/docs/protocol-specs/cryptography/proving-system/overview.md b/docs/docs/protocol-specs/cryptography/proving-system/overview.md
index 74e1c7306e56..c7d1ce69d070 100644
--- a/docs/docs/protocol-specs/cryptography/proving-system/overview.md
+++ b/docs/docs/protocol-specs/cryptography/proving-system/overview.md
@@ -90,7 +90,7 @@ When passing data between successive IVC steps, the canonical method is to do so
 
 The Data Bus protocol eliminates this cost by representing cross-step data via succinct commitments instead of raw field elements.
 
-The [Plonk Data Bus](https://aztecprotocol.slack.com/files/U8Q1VAX6Y/F05G2B971FY/plonk_bus.pdf) protocol enables efficient data transfer between two Honk instances within a larger IVC protocol.
+The Plonk Data Bus protocol enables efficient data transfer between two Honk instances within a larger IVC protocol.
 
 # Polynomial Commitment Schemes
 

From d8a52cd56f43c06221a2bdd89460900044874894 Mon Sep 17 00:00:00 2001
From: josh crites <jc@joshcrites.com>
Date: Wed, 14 Aug 2024 09:04:52 -0400
Subject: [PATCH 05/12] delete roadmaps

---
 .../aztec/roadmap/cryptography_roadmap.md     |  26 --
 .../docs/aztec/roadmap/engineering_roadmap.md | 273 ------------------
 2 files changed, 299 deletions(-)
 delete mode 100644 docs/docs/aztec/roadmap/cryptography_roadmap.md
 delete mode 100644 docs/docs/aztec/roadmap/engineering_roadmap.md

diff --git a/docs/docs/aztec/roadmap/cryptography_roadmap.md b/docs/docs/aztec/roadmap/cryptography_roadmap.md
deleted file mode 100644
index 4b732f0aa9ab..000000000000
--- a/docs/docs/aztec/roadmap/cryptography_roadmap.md
+++ /dev/null
@@ -1,26 +0,0 @@
----
-title: Cryptography Roadmap
-sidebar_position: 2
----
-
-
-The cryptography team is currently working on [Barretenberg here.](https://github.com/AztecProtocol/aztec-packages/tree/master/barretenberg)
-
-## R&D projects
-
-Publish the Honk paper, describing practical considerations for constructing our cutting-edge proving system Honk along with formal proofs of its security properties.
-
-## Honk
-
-Honk is a sumcheck-based zk-SNARK protocol with blazing-fast zk proof construction. We need Honk to allow users to prove correct execution of complicated, multi-step computations using recursion in a resource constraint environment like a cell phone. This is necessary for our mission, because we need to make sure our users' sensitive information never leaves their devices!
-
-List of Honk projects:
-
-- Completed: basic Honk prover and verifier with respectable construction and verification speeds, but no optimization.
-- Upcoming:
-  - Bringing "Ultra" functionality to Honk: lookup tables, efficient range constraints, RAM, ROM, and more will result in orders-of-magnitude improvements to Honk's prover times.
-  - Recursion using cycles of curves will allow for efficient recursive verification of Honk proofs. Using this technique will lower the barrier to entry of our rollup providers, resulting in a more robust set of providers and greater security for the Aztec network.
-
-## Goblin projects
-
-Goblin is a deferred verification framework that allows for an order-of-magnitude increase in the complexity of computations that Aztec users can execute with full privacy. This corresponds to a 10x increase in the expressivity of Noir programs that can be run in practice without melting anybody's favorite phone or laptop. Read more [here](https://hackmd.io/@aztec-network/B19AA8812).
diff --git a/docs/docs/aztec/roadmap/engineering_roadmap.md b/docs/docs/aztec/roadmap/engineering_roadmap.md
deleted file mode 100644
index 14b1431f6b17..000000000000
--- a/docs/docs/aztec/roadmap/engineering_roadmap.md
+++ /dev/null
@@ -1,273 +0,0 @@
----
-title: Engineering Roadmap
-sidebar_position: 1
----
-
-The engineering roadmap is long. There are no timings assigned here. In a loose priority order:
-
-## Sandbox Community Support
-
-- Triage on discord / discourse / github.
-- Iterating on the docs and code, given people's issues.
-- Encouraging contributions to 'good first issue' issues.
-- Release notes.
-- Versioning.
-- Aztec Improvement Proposals (AZIPs)
-- Aztec Requests for Comment (AZRCs)
-
-## Benchmarking
-
-- Gather metrics about everything, to guide future decisions.
-
-## Standardization efforts
-
-- Recommended Aztec smart contract coding patterns
-- Access Control (whitelists/blacklists) - probably needs the Shared Mutable.
-- Basic _example_ private tokens
-  - Including recursive calls to 'get_notes'.
-- Compliant private tokens
-- Private NFTs
-- Public tokens
-- Depositing and withdrawing tokens
-  - L1\<\>L2
-  - public\<\>private
-- The Aztec Connect bridging pattern
-- Using Keys (the fully-featured version of keys that we want to build)
-- Plume nullifiers
-- Negative reputation example
-- Anti-denial-of-service
-- Combining Aztec with MPC
-
-## Polishing what we have
-
-- Refactoring sprints.
-  - Reduce tech debt.
-  - More tests.
-
-## Enforcing correct ordering Public & Private State Transitions
-
-## Enforcing correct ordering of other 'side effects'
-
-- Log ordering
-- Enqueued public function calls
-
-## What data actually needs to be submitted on-chain?
-
-- For Public Functions:
-  - Just emit the initially-enqueued public function request data? (The 'inputs' of the tx);
-    - I.e. contract address, function selector, args, call_context.
-  - OR, Just emit the final state transitions? (The 'outputs' of the tx)
-    - I.e. the leaf indices and new values of the public data tree; and the new note hashes/nullifiers of the note hash tree; and logs; and l2->L1 messages.
-
-## Proper specs
-
-- Write detailed specs, given recent protocol changes.
-- Review the code to ensure it matches what we _think_ the protocol is.
-- Open issues to ensure the code matches the spec.
-- (Note: bringing cryptographers into the fold (to review specs) is a separate section, later in this doc).
-
-## Iterate on the Sandbox
-
-Based on community feedback, we'll need some teams to iterate on Sandbox features and fix bugs.
-
-## Iterate on the Aztec Smart Contract Library
-
-## Iterating on CI
-
-CI takes up a significant amount of time. It gets its own section here, so we remember it exists.
-
-## Sequencer & Prover Selection protocols
-
-- Decide on protocol
-- Spec
-- Build.
-
-## Upgradeability
-
-- Decide on protocol
-- Spec
-- Build.
-
-## Fees
-
-- Design the Protocol
-  - Interdependence on the Sequencer & Upgradeability protocols.
-  - Pay fees in 1 currency, or fee abstraction?
-  - Escrowing fees
-  - Rebates
-  - L1->L2 message fees.
-  - L2->L1 fees
-  - Etc.
-- Build it.
-  - Gas metering
-  - Etc.
-
-## Note Discovery
-
-- Note Discovery RFP
-- Decide on the protocol
-- Spec
-- Build it.
-
-## Privacy-preserving queries to public nodes
-
-- Explore PIR
-- Explore alternatives
-- Implement
-
-## Keys
-
-- Write up keys spec
-- Get internal comments
-- Do a RFC from the external community
-- Implement
-
-## Shared Mutable State
-
-We _need_ a way to read mutable public data from a private function. We are moving away from the old Slow Updates Tree in favor of [Shared Mutable](../../reference/developer_references/smart_contract_reference/storage/shared_state.md#sharedmutable).
-
-## Contract classes and instances?
-
-- There's a suggestion to introduce contract classes.
-
-## Delegatecalls vs SetCode
-
-- Which? (if at all)
-
-## Remove the contracts tree? 🤯
-
-- There's a suggestion to remove the notion of a contracts tree. What do we actually need the tree for? To check that a vk hash exists for a particular contract address?
-- If the contract address contains the function tree, and it also contains data about the constructor args to that contract, then perhaps we don't need the contract tree to exist.
-- We might still need the notion of a 'deployment':
-  - to broadcast a contract's bytecode;
-  - to 'reserve' a contract address;
-  - and possibly to prevent a constructor from being executed twice (although an app could do this ("constructor abstraction")).
-
-## Cryptography review checkpoint
-
-- Once we have specs (see above), we should review the rigour and secureness to our protocol.
-  - Choice of hashes
-  - Domain separation
-  - Choice of encryption scheme
-  - Keys
-  - A security review of the protocol as a whole
-
-## Testing UX team
-
-A team focussed on testing and debugging UX.
-This team should have free rein to design and add any features they see fit.
-
-Some example features:
-
-- Writing contract tests in Noir.
-  - Mocking oracles.
-- Taking inspiration from other testing frameworks.
-- Much more detailed logging if things go wrong.
-- Errors which only spit out opaque 254-bit hex numbers are bad.
-  - Ensure all circuits are fed the human-readable information underlying all of these hex numbers.
-  - If tree root comparisons (expected vs actual) fail, human-readable details about the leaves in trees should be provided.
-
-## Tooling
-
-## Proper Circuits
-
-### Redesign
-
-- The Bus
-  - The bus will have an impact on the way we design the circuit logic.
-  - We can hopefully avoid hashing in circuit 1 and unpacking that hash in circuit 2.
-  - Understand the 'bus' and how we can use it to pass variable amounts of data between recursive circuit iterations.
-  - Redesign all circuit logic to allow for the variable-sized arrays that the 'bus' enables.
-- Enable 'dynamic/variable-sized **loops**'
-  - allow each `for` loop (eg read requests, insertions, commitment squashing, call stack processing, bip32 key derivation, etc.) to vary in size, by deferring each loop to its own final circuit. This would require complex folding stuff.
-  - This would give much more flexibility over the sizes of various arrays that a circuit can output. Without it, if one array of an app circuit needs to be size 2000, but other arrays aren't used, we'd use a kernel where every array is size 2048, meaning a huge amount of unnecessary loops of computation for those empty arrays.
-- Improvements
-  - We can definitely change how call stacks are processed within a kernel, to reduce hashing.
-  - Squash pending note hashes/nullifiers in every kernel iteration, to enable a deeper nested call depth.
-- Topology of a rollup
-  - Revisit the current topology:
-    - We can make the rollup trees 'wonky' (rather than balanced), meaning a sequencer doesn't need to prove a load of pointless 'padding' proofs?
-      - This would also enable new txs (entering the tx pool) to be added to a rollup block 'on-the-fly' (mid way through a rollup being proven) - but of course, the sequencer selection protocol might require an up-front commitment, so this might not be possible for that reason (sad face).
-    - We can definitely redesign the public kernel circuit to be a '2x2' topology (i.e. a tree of public kernel proofs), to get a logarithmic speed-up (parallelism). The question is, with folding schemes, do we need that optimization?
-
-#### Refactor of packing & unpacking data in circuits
-
-We often pack data in circuit A, and then unpack it again in circuit B.
-
-- args_hash
-- return_values_hash
-- call stacks
-- read requests
-- etc.
-
-Also, for logs in particular, we allow arbitrary-sized logs. But this requires sha256 packing inside an app circuit (which is slow) (and sha256 unpacking in Solidity (which is relatively cheap)). Perhaps we also use the bus ideas for logs, to give _some_ variability in log length, but up to an upper bound.
-
-Also, we do a lot of sha256-compressing in our kernel and rollup circuits for data which must be checked on-chain, but grows exponentially with every round of iteration. E.g.: new contract deployment data, new nullifiers, new note hashes, public state transition data, etc. This might be unavoidable. Maybe all we can do is use polynomial commitments when the EIP-4844 work is done. But maybe we can use the bus for this stuff too.
-
-### Write proper circuits
-
-### The Public VM Circuit
-
-- Design it
-- Build it
-
-### The Brillig Bytecode Commitment Circuit
-
-- A circuit which proves the brillig bytecode being emitted matches the polynomial commitment to that bytecode.
-
-### Decide on constants!
-
-### Honk -> Ultra Squisher Circuit
-
-### Ultra -> Standard Squisher Circuit
-
-## Authentication: access to private data
-
-- Private data must not be returned to an app, unless the user authorizes it.
-
-## Validation: preventing execution of malicious bytecode
-
-- A node should check that the bytecode provided by an application for a given app matches the leaf in the contract tree to ensure that user doesn't execute unplanned code which might access their notes.
-
-## Fuzz Testing
-
-## Formal Verification
-
-An investigation into how formal verification techniques might improve the security of Aztec software.
-
-## P2P network
-
-- A robust p2p network for the tx pool and the proof pool.
-
-## Hashes
-
-- An improved, standardized Pedersen hash in barretenberg.
-- Poseidon hashing in barretenberg.
-
-## Tree epochs
-
-- Nullifier tree epochs
-- Maybe other tree epochs.
-
-## Chaining txs
-
-- We have the ability to spend pending notes (which haven't-yet been added to the tree) _within the context of a single tx_.
-- We need the ability to spend pending notes (which haven't yet been added to the tree) across different txs, within the context of a single rollup.
-  - This happens if Alice generates two txs X & Y, where tx Y spends notes from tx X. If we want Alice to be able to generate these txs in parallel (without interacting with the network at all), we need a way for tx Y to spend notes before they've been added to the tree. The 'chaining tx' concepts from Aztec Connect can enable this.
-- This added _a lot_ of complexity to Aztec Connect. Especially around fees, iirc. Caution needed.
-
-## EIP-4844
-
-- Understand it. Spec it. Build it.
-- Includes:
-  - Smart Contract changes
-  - Circuit changes
-  - A circuit to prove equivalence vs a BLS12-381 polynomial commitment.
-
-## Make it all work in a browser
-
-## Code Freeze
-
-## Internal Audit
-
-## External Audits

From 177cabd42d78d77db2865961be1584312c4e95dc Mon Sep 17 00:00:00 2001
From: josh crites <jc@joshcrites.com>
Date: Wed, 14 Aug 2024 10:47:04 -0400
Subject: [PATCH 06/12] remove link, update redirects

---
 docs/docs/reference/developer_references/limitations.md | 2 +-
 docs/netlify.toml                                       | 8 ++++++++
 2 files changed, 9 insertions(+), 1 deletion(-)

diff --git a/docs/docs/reference/developer_references/limitations.md b/docs/docs/reference/developer_references/limitations.md
index cb13ddf47799..60c659119c2a 100644
--- a/docs/docs/reference/developer_references/limitations.md
+++ b/docs/docs/reference/developer_references/limitations.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](../../aztec/roadmap/cryptography_roadmap.md).
+That's not to say a super-fast proving system isn't being worked on as we speak.
 
 #### What are the consequences?
 
diff --git a/docs/netlify.toml b/docs/netlify.toml
index d1aef404fb30..8f6e99a4728f 100644
--- a/docs/netlify.toml
+++ b/docs/netlify.toml
@@ -58,6 +58,14 @@
     from = "/compliance"
     to = "/"
 
+[[redirects]]
+    from = "/aztec/roadmap/engineering_roadmap"
+    to = "/"
+
+[[redirects]]
+    from = "/aztec/roadmap/cryptography_roadmap"
+    to = "/"
+
 [[redirects]]
     from = "/protocol-specs/gas-and-fees/fee-payment-asset"
     to = "/protocol-specs/gas-and-fees/fee-juice"

From fe0192425fde71124d539a91c8e24770d345208a Mon Sep 17 00:00:00 2001
From: Cat McGee <hello@mcgee.cat>
Date: Wed, 14 Aug 2024 16:21:32 +0100
Subject: [PATCH 07/12] tutorial redirects

---
 docs/netlify.toml | 52 +++++++++++++++++++++++++++++++++++++++++++++--
 1 file changed, 50 insertions(+), 2 deletions(-)

diff --git a/docs/netlify.toml b/docs/netlify.toml
index 8f6e99a4728f..6d4bdb925488 100644
--- a/docs/netlify.toml
+++ b/docs/netlify.toml
@@ -1,14 +1,62 @@
+[[redirects]]
+    from = "/tutorials/simple_dapp/*
+    to = "tutorials/codealong/simple_dapp
+
+[[redirects]]
+    from = "/tutorials/simple_dapp
+    to = "tutorials/codealong/simple_dapp
+
+[[redirects]]
+    from = "/tutorials/contract_tutorials/advanced/token_bridge/typescript_glue_code
+    to = "tutorials/codealong/contract_tutorials/advanced/token_bridge/typescript_glue_code
+
+[[redirects]]
+    from = "/tutorials/contract_tutorials/advanced/token_bridge/withdrawing_to_l1
+    to = "tutorials/codealong/contract_tutorials/advanced/token_bridge/withdrawing_to_l1
+
+[[redirects]]
+    from = "/tutorials/contract_tutorials/advanced/token_bridge/minting_on_aztec
+    to = "tutorials/codealong/contract_tutorials/advanced/token_bridge/minting_on_aztec
+
+[[redirects]]
+    from = "/tutorials/contract_tutorials/advanced/token_bridge/depositing_to_aztec"
+    to = "tutorials/codealong/contract_tutorials/advanced/token_bridge/depositing_to_aztec"
+
+[[redirects]]
+    from = "/tutorials/contract_tutorials/advanced/token_bridge"
+    to = "tutorials/codealong/contract_tutorials/advanced/token_bridge"
+
+[[redirects]]
+    from = "/tutorials/contract_tutorials/advanced/token_bridge/setup"
+    to = "tutorials/codealong/contract_tutorials/advanced/token_bridge/setup"
+
+[[redirects]]
+    from = "/tutorials/contract_tutorials/crowdfunding_contract"
+    to = "tutorials/codealong/contract_tutorials/crowdfunding_contract"
+
+[[redirects]]
+    from = "/tutorials/contract_tutorials/private_voting_contract"
+    to = "tutorials/codealong/contract_tutorials/private_voting_contract"
+
+[[redirects]]
+    from = "/tutorials/contract_tutorials/token_contract"
+    to = "tutorials/codealong/contract_tutorials/token_contract"
+
+[[redirects]]
+    from = "/tutorials/*"
+    to = "/tutorials/codealong/contract_tutorials/private_voting_contract"
+
 [[redirects]]
     from = "/developers/tutorials/*"
     to = "/tutorials/codealong/contract_tutorials/private_voting_contract"
 
 [[redirects]]
     from = "/developers/sandbox/*"
-    to = "/reference/developer_references/sandbox_reference"
+    to = "/guides/developer_guides/getting_started/quickstart"
 
 [[redirects]]
     from = "/developers/contracts/*"
-    to = "/reference/developer_references/smart_contract_reference"
+    to = "/aztec/smart_contracts_overview"
 
 [[redirects]]
     from = "/dev_docs/*"

From 44adb00b4620e79fcf328be75021570d9eaf90f0 Mon Sep 17 00:00:00 2001
From: Cat McGee <hello@mcgee.cat>
Date: Wed, 14 Aug 2024 16:28:13 +0100
Subject: [PATCH 08/12] fixing redirects

---
 docs/docs/aztec/concepts/accounts/index.md           |  2 +-
 .../data-publication-and-availability/overview.md    |  4 ++--
 docs/docusaurus.config.js                            |  2 +-
 docs/netlify.toml                                    | 12 ++++++++++++
 noir-projects/aztec-nr/authwit/src/auth.nr           |  2 +-
 5 files changed, 17 insertions(+), 5 deletions(-)

diff --git a/docs/docs/aztec/concepts/accounts/index.md b/docs/docs/aztec/concepts/accounts/index.md
index 07bb62954517..f8fd5c16f29c 100644
--- a/docs/docs/aztec/concepts/accounts/index.md
+++ b/docs/docs/aztec/concepts/accounts/index.md
@@ -35,7 +35,7 @@ Instead of implementing it at the protocol level as in Aztec, account abstractio
 
 A simple example would be Gnosis Safe (see [_Account Abstraction is NOT coming_](https://safe.mirror.xyz/9KmZjEbFkmI79s28d9xar6JWYrE50F5AHpa5CR12YGI)), where it's the multisig contract responsibility to define when an execution request is valid by checking it carries N out of M signatures, and then executing it. [Argent](https://www.argent.xyz/blog/wtf-is-account-abstraction/) has also been working on smart wallets for years, and collaborating with network teams to implement AA natively at the protocol layer.
 
-Ethereum is currently following this approach via [EIP4337](https://eips.ethereum.org/EIPS/eip-4337), an evolution of the [GSN](https://opengsn.org/). This EIP defines a standard method for relaying meta-transactions in a decentralized way, including options for delegating payment to other agents (called paymasters). See [this chart](https://twitter.com/koeppelmann/status/1632257610455089154) on how 4337 relates to other smart contract wallet efforts.
+Ethereum is currently following this approach via [EIP4337](https://eips.ethereum.org/EIPS/eip-4337), an evolution of the [GSN](https://opengsn.org/). This EIP defines a standard method for relaying meta-transactions in a decentralized way, including options for delegating payment to other agents (called paymasters). See [this chart](https://x.com/koeppelmann/status/1632257610455089154) on how 4337 relates to other smart contract wallet efforts.
 
 Implementing AA at the application layer has the main drawback that it's more complex than doing so at the protocol layer. It also leads to duplicated efforts in both layers (eg the wrapper transaction in a meta-transactions still needs to be checked for its ECDSA signature, and then the smart contract wallet needs to verify another set of signatures).
 
diff --git a/docs/docs/protocol-specs/data-publication-and-availability/overview.md b/docs/docs/protocol-specs/data-publication-and-availability/overview.md
index 1a1bba6b76fa..ca46010fc151 100644
--- a/docs/docs/protocol-specs/data-publication-and-availability/overview.md
+++ b/docs/docs/protocol-specs/data-publication-and-availability/overview.md
@@ -30,7 +30,7 @@ From distributed systems, the _security_ of a protocol or system is defined by:
 :::
 
 In the context of blockchain, this _security_ is defined by the confirmation rule, while this can be chosen individually by the user, our validating light node (L1 bridge) can be seen as a user, after all, it's "just" another node.
-For the case of a validity proof based blockchain, a good confirmation rule should satisfy the following sub-properties (inspired by [Sreeram's framing](https://twitter.com/sreeramkannan/status/1683735050897207296)):
+For the case of a validity proof based blockchain, a good confirmation rule should satisfy the following sub-properties (inspired by [Sreeram's framing](https://x.com/sreeramkannan/status/1683735050897207296)):
 
 - **Liveness**:
   - Data Availability - The chain data must be available for anyone to reconstruct the state and build blocks
@@ -318,5 +318,5 @@ Of these, Celestia has the current best "out-the-box" solution, but Eigen-da and
 - https://forum.celestia.org/t/security-levels-for-data-availability-for-light-nodes/919
 - https://ethresear.ch/t/peerdas-a-simpler-das-approach-using-battle-tested-p2p-components/16541
 - https://jumpcrypto.com/writing/bridging-and-finality-ethereum/
-- https://twitter.com/sreeramkannan/status/1683735050897207296
+- https://x.com/sreeramkannan/status/1683735050897207296
 - https://blog.celestia.org/introducing-blobstream/
diff --git a/docs/docusaurus.config.js b/docs/docusaurus.config.js
index 746da4354044..fd5215f99a54 100644
--- a/docs/docusaurus.config.js
+++ b/docs/docusaurus.config.js
@@ -360,7 +360,7 @@ const config = {
               },
               {
                 label: "X (Twitter)",
-                href: "https://twitter.com/aztecnetwork",
+                href: "https://x.com/aztecnetwork",
               },
               {
                 label: "Plonk Cafe",
diff --git a/docs/netlify.toml b/docs/netlify.toml
index 6d4bdb925488..54755d563417 100644
--- a/docs/netlify.toml
+++ b/docs/netlify.toml
@@ -1,3 +1,15 @@
+[[redirects]]
+    from = "/guides/smart_contracts/writing_contracts/initializers"
+    to = "/guides/developer_guides/smart_contracts/writing_contracts/initializers"
+
+[[redirects]]
+    from = "/reference/aztecjs/accounts"
+    to = "/reference/developer_references/aztecjs/accounts"
+
+[[redirects]]
+    from = "/getting_started"
+    to = "/guides/developer_guides/getting_started/quickstart"
+
 [[redirects]]
     from = "/tutorials/simple_dapp/*
     to = "tutorials/codealong/simple_dapp
diff --git a/noir-projects/aztec-nr/authwit/src/auth.nr b/noir-projects/aztec-nr/authwit/src/auth.nr
index dd3cbb900f12..0a3c991987af 100644
--- a/noir-projects/aztec-nr/authwit/src/auth.nr
+++ b/noir-projects/aztec-nr/authwit/src/auth.nr
@@ -62,7 +62,7 @@ use dep::aztec::{prelude::Deserialize, context::{PrivateContext, PublicContext,
  * contract. Since the `DeFi` contract is trying to pull funds from an account that is not its own, it needs to 
  * convince the `Token` contract that it is allowed to do so. 
  * 
- * This is where the authentication witness comes in! The `Token` contract computes a `message_hash` from the 
+ * This is where the authentication witness comes in The `Token` contract computes a `message_hash` from the 
  * `transfer` call, and then asks `Alice Account` contract to verify that the `DeFi` contract is allowed to 
  * execute that call.
  * 

From ad218f450eec0abfa266f0f34212211be2bae920 Mon Sep 17 00:00:00 2001
From: josh crites <jc@joshcrites.com>
Date: Wed, 14 Aug 2024 11:41:32 -0400
Subject: [PATCH 09/12] add missing quotes

---
 docs/netlify.toml | 20 ++++++++++----------
 1 file changed, 10 insertions(+), 10 deletions(-)

diff --git a/docs/netlify.toml b/docs/netlify.toml
index 436e3f3aca65..5eee94e7358c 100644
--- a/docs/netlify.toml
+++ b/docs/netlify.toml
@@ -11,24 +11,24 @@
     to = "/guides/developer_guides/getting_started/quickstart"
 
 [[redirects]]
-    from = "/tutorials/simple_dapp/*
-    to = "tutorials/codealong/simple_dapp
+    from = "/tutorials/simple_dapp/*"
+    to = "tutorials/codealong/simple_dapp"
 
 [[redirects]]
-    from = "/tutorials/simple_dapp
-    to = "tutorials/codealong/simple_dapp
+    from = "/tutorials/simple_dapp"
+    to = "tutorials/codealong/simple_dapp"
 
 [[redirects]]
-    from = "/tutorials/contract_tutorials/advanced/token_bridge/typescript_glue_code
-    to = "tutorials/codealong/contract_tutorials/advanced/token_bridge/typescript_glue_code
+    from = "/tutorials/contract_tutorials/advanced/token_bridge/typescript_glue_code"
+    to = "tutorials/codealong/contract_tutorials/advanced/token_bridge/typescript_glue_code"
 
 [[redirects]]
-    from = "/tutorials/contract_tutorials/advanced/token_bridge/withdrawing_to_l1
-    to = "tutorials/codealong/contract_tutorials/advanced/token_bridge/withdrawing_to_l1
+    from = "/tutorials/contract_tutorials/advanced/token_bridge/withdrawing_to_l1"
+    to = "tutorials/codealong/contract_tutorials/advanced/token_bridge/withdrawing_to_l1"
 
 [[redirects]]
-    from = "/tutorials/contract_tutorials/advanced/token_bridge/minting_on_aztec
-    to = "tutorials/codealong/contract_tutorials/advanced/token_bridge/minting_on_aztec
+    from = "/tutorials/contract_tutorials/advanced/token_bridge/minting_on_aztec"
+    to = "tutorials/codealong/contract_tutorials/advanced/token_bridge/minting_on_aztec"
 
 [[redirects]]
     from = "/tutorials/contract_tutorials/advanced/token_bridge/depositing_to_aztec"

From b48bd4cc49d943568d93a378423935440e19dfee Mon Sep 17 00:00:00 2001
From: josh crites <jc@joshcrites.com>
Date: Wed, 14 Aug 2024 11:49:25 -0400
Subject: [PATCH 10/12] prepend slashes

---
 docs/netlify.toml | 22 +++++++++++-----------
 1 file changed, 11 insertions(+), 11 deletions(-)

diff --git a/docs/netlify.toml b/docs/netlify.toml
index 5eee94e7358c..811750ba29ab 100644
--- a/docs/netlify.toml
+++ b/docs/netlify.toml
@@ -12,47 +12,47 @@
 
 [[redirects]]
     from = "/tutorials/simple_dapp/*"
-    to = "tutorials/codealong/simple_dapp"
+    to = "/tutorials/codealong/simple_dapp"
 
 [[redirects]]
     from = "/tutorials/simple_dapp"
-    to = "tutorials/codealong/simple_dapp"
+    to = "/tutorials/codealong/simple_dapp"
 
 [[redirects]]
     from = "/tutorials/contract_tutorials/advanced/token_bridge/typescript_glue_code"
-    to = "tutorials/codealong/contract_tutorials/advanced/token_bridge/typescript_glue_code"
+    to = "/tutorials/codealong/contract_tutorials/advanced/token_bridge/typescript_glue_code"
 
 [[redirects]]
     from = "/tutorials/contract_tutorials/advanced/token_bridge/withdrawing_to_l1"
-    to = "tutorials/codealong/contract_tutorials/advanced/token_bridge/withdrawing_to_l1"
+    to = "/tutorials/codealong/contract_tutorials/advanced/token_bridge/withdrawing_to_l1"
 
 [[redirects]]
     from = "/tutorials/contract_tutorials/advanced/token_bridge/minting_on_aztec"
-    to = "tutorials/codealong/contract_tutorials/advanced/token_bridge/minting_on_aztec"
+    to = "/tutorials/codealong/contract_tutorials/advanced/token_bridge/minting_on_aztec"
 
 [[redirects]]
     from = "/tutorials/contract_tutorials/advanced/token_bridge/depositing_to_aztec"
-    to = "tutorials/codealong/contract_tutorials/advanced/token_bridge/depositing_to_aztec"
+    to = "/tutorials/codealong/contract_tutorials/advanced/token_bridge/depositing_to_aztec"
 
 [[redirects]]
     from = "/tutorials/contract_tutorials/advanced/token_bridge"
-    to = "tutorials/codealong/contract_tutorials/advanced/token_bridge"
+    to = "/tutorials/codealong/contract_tutorials/advanced/token_bridge"
 
 [[redirects]]
     from = "/tutorials/contract_tutorials/advanced/token_bridge/setup"
-    to = "tutorials/codealong/contract_tutorials/advanced/token_bridge/setup"
+    to = "/tutorials/codealong/contract_tutorials/advanced/token_bridge/setup"
 
 [[redirects]]
     from = "/tutorials/contract_tutorials/crowdfunding_contract"
-    to = "tutorials/codealong/contract_tutorials/crowdfunding_contract"
+    to = "/tutorials/codealong/contract_tutorials/crowdfunding_contract"
 
 [[redirects]]
     from = "/tutorials/contract_tutorials/private_voting_contract"
-    to = "tutorials/codealong/contract_tutorials/private_voting_contract"
+    to = "/tutorials/codealong/contract_tutorials/private_voting_contract"
 
 [[redirects]]
     from = "/tutorials/contract_tutorials/token_contract"
-    to = "tutorials/codealong/contract_tutorials/token_contract"
+    to = "/tutorials/codealong/contract_tutorials/token_contract"
 
 [[redirects]]
     from = "/tutorials/*"

From d7655e23dc4b2c42ed984dec0043f7051d50f755 Mon Sep 17 00:00:00 2001
From: josh crites <jc@joshcrites.com>
Date: Wed, 14 Aug 2024 11:54:53 -0400
Subject: [PATCH 11/12] 1 more

---
 docs/netlify.toml | 4 ++++
 1 file changed, 4 insertions(+)

diff --git a/docs/netlify.toml b/docs/netlify.toml
index 811750ba29ab..b1fd1528562f 100644
--- a/docs/netlify.toml
+++ b/docs/netlify.toml
@@ -136,4 +136,8 @@
 
 [[redirects]]
     from = "/reference/sandbox_reference/sandbox-reference"
+    to = "/guides/developer_guides/getting_started/quickstart" 
+
+[[redirects]]
+    from = "/reference/sandbox_reference"
     to = "/guides/developer_guides/getting_started/quickstart" 
\ No newline at end of file

From 307a79b5216053bfb2dc38c9d599e7ebb1aa2489 Mon Sep 17 00:00:00 2001
From: josh crites <critesjosh@gmail.com>
Date: Wed, 14 Aug 2024 12:10:14 -0400
Subject: [PATCH 12/12] Update crowdfunding_contract.md

---
 .../codealong/contract_tutorials/crowdfunding_contract.md       | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/docs/docs/tutorials/codealong/contract_tutorials/crowdfunding_contract.md b/docs/docs/tutorials/codealong/contract_tutorials/crowdfunding_contract.md
index 2c7953a8daeb..198c1a3dfc22 100644
--- a/docs/docs/tutorials/codealong/contract_tutorials/crowdfunding_contract.md
+++ b/docs/docs/tutorials/codealong/contract_tutorials/crowdfunding_contract.md
@@ -195,7 +195,7 @@ Copy the last function into your Crowdfunding contract:
 
 You should be able to compile successfully with `aztec-nargo compile`. 
 
-**Congraulations,** you have just built a multi-contract project on Aztec!
+**Congratulations,** you have just built a multi-contract project on Aztec!
 
 ## Conclusion