diff --git a/aztec-up/README.md b/aztec-up/README.md
index 4a8ebf22fa2..e46bfbceaec 100644
--- a/aztec-up/README.md
+++ b/aztec-up/README.md
@@ -1,7 +1,7 @@
 # The Aztec Installation Script
 
 ```
-bash -i <(curl -s install.aztec.network)
+bash -i <(curl -s https://install.aztec.network)
 ```
 
 That is all.
diff --git a/aztec-up/bin/aztec-up b/aztec-up/bin/aztec-up
index 6f86c093fa8..7e718a33dab 100755
--- a/aztec-up/bin/aztec-up
+++ b/aztec-up/bin/aztec-up
@@ -3,4 +3,4 @@ set -euo pipefail
 
 export VERSION=${1:-${VERSION:-}}
 export NON_INTERACTIVE=1
-bash -i <(curl -s http://install.aztec.network)
+bash -i <(curl -s https://install.aztec.network)
diff --git a/docs/docs/aztec/concepts/storage/partial_notes.md b/docs/docs/aztec/concepts/storage/partial_notes.md
index 2ea605e50df..7a72ef21814 100644
--- 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 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](../../../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.
 
 So, in general, the user is:
 
@@ -18,7 +18,7 @@ So, in general, the user is:
 - encrypting/compressing that computation with a point
 - passing that point as an argument to a public function
 
-And the fee payer is:
+And the paymaster is:
 
 - updating that point in public
 - treating/emitting the result(s) as a note hash(es)
@@ -32,6 +32,20 @@ To do this, we leverage the following properties of elliptic curve operations:
 
 Property 1 allows us to be continually adding to a point on elliptic curve and property 2 allows us to pass the point to a public realm without revealing anything about the point preimage.
 
+### DEXes
+
+Currently private swaps require 2 transactions. One to start the swap and another to claim the swapped token from the DEX. With partial notes, you can create a note with zero value for the received amount and have another party complete it later from a public function, with the final swapped amount. This reduces the number of transactions needed to swap privately.
+
+Comparing to the flow above, the user is doing some private computation to stage the swap, encrypting the computation with a point and passing the point as an argument to a public function. Then another party is updating that point in public and emitting the result as a note hash for the user doing the swap.
+
+### Lending
+
+A similar pattern can be used for a lending protocol. The user can deposit a certain amount of a token to the lending contract and create a partial note for the borrowed token that will be completed by another party. This reduces the number of required transactions from 2 to 1.
+
+### Private Refunds
+
+Private transaction refunds from paymasters are the original inspiration for partial notes. Without partial notes, you have to claim your refund note. But the act of claiming itself needs gas! What if you overpaid fees on the refund tx? Then you have another 2nd order refund that you need to claim. This creates a never ending cycle! Partial notes allow paymasters to refund users without the user needing to claim the refund.
+
 Before getting to partial notes let's recap what is the flow of standard notes.
 
 ## Note lifecycle recap
diff --git a/docs/docs/guides/developer_guides/getting_started/quickstart.md b/docs/docs/guides/developer_guides/getting_started/quickstart.md
index d296b31af94..6ec66163c11 100644
--- a/docs/docs/guides/developer_guides/getting_started/quickstart.md
+++ b/docs/docs/guides/developer_guides/getting_started/quickstart.md
@@ -20,7 +20,7 @@ You need two global dependencies in your machine:
 Run:
 
 ```bash
-bash -i <(curl -s install.aztec.network)
+bash -i <(curl -s https://install.aztec.network)
 ```
 
 This will install the following tools:
diff --git a/docs/docs/guides/developer_guides/smart_contracts/writing_contracts/common_patterns/key_rotation.md b/docs/docs/guides/developer_guides/smart_contracts/writing_contracts/common_patterns/key_rotation.md
index 1a8a31e971a..5841e5eb3fc 100644
--- a/docs/docs/guides/developer_guides/smart_contracts/writing_contracts/common_patterns/key_rotation.md
+++ b/docs/docs/guides/developer_guides/smart_contracts/writing_contracts/common_patterns/key_rotation.md
@@ -9,20 +9,34 @@ tags: [accounts, keys]
 
 ## Introduction
 
-It is possible for users to rotate their keys, which can be helpful if some of their keys are leaked.
+It is possible for users to rotate their keys, which can be helpful if some of their keys are leaked. Key rotation allows users to continue using the same account without having to create a new one.
 
-Because of this, notes are associated with their `nullifier key` rather than any sort of 'owner' address. 
+Because of this, notes are often associated with their `nullifier key` (through a nullifier public key hash, often called `npk_m_hash`) rather than any sort of 'owner' address.
 
 It is still possible to nullify the notes with the old nullifier key even after the key rotation.
 
+## `TokenNote` example
+
+See the structure of the `TokenNote` below:
+
+#include_code TokenNote noir-projects/noir-contracts/contracts/token_contract/src/types/token_note.nr rust
+
+In the `TokenNote` type, you can see that the nullifer computation gets the nullifier secret key specific to the contract from the PXE, based on the stored `npk_m_hash`, so a `TokenNote` is not inherently or permanently linked to a specific Aztec account.
+
+#include_code nullifier noir-projects/noir-contracts/contracts/token_contract/src/types/token_note.nr rust
+
 ## Things to consider
 
-- 'Owner' is arbitrary - as long as you know the nullifier secret, you can nullify a note
-- Consider how key rotation can affect account contracts, eg you can add additional security checks for who or how the key rotation is called
+- When using the `npk_m_hash`, used to represent ownership, whoever has the nullifier secret can nullify a note.
+- Consider how key rotation can affect account contracts, e.g. you can add additional security checks for who or how the key rotation is called
+
+## Resources
+
+- End to end tests for key rotation can be found [here](https://github.com/AztecProtocol/aztec-packages/blob/#include_aztec_version/yarn-project/end-to-end/src/e2e_key_rotation.test.ts)
 
 ## Glossary
 
 - `npk_m_hash`: master nullifying public key hash
 - `nsk_app`: app nullifying secret key - the app-specific NSK (learn more about app-scoped keys [here](../../../../../aztec/concepts/accounts/keys.md#scoped-keys))
 - `nsk_hash`: nullifying secret key hash
-- `ivpk_m`: incoming view public key (master) (learn more about IVPKs [here](../../../../../aztec/concepts/accounts/keys.md#incoming-viewing-keys))
\ No newline at end of file
+- `ivpk_m`: incoming view public key (master) (learn more about IVPKs [here](../../../../../aztec/concepts/accounts/keys.md#incoming-viewing-keys))
diff --git a/docs/docs/guides/developer_guides/smart_contracts/writing_contracts/how_to_emit_event.md b/docs/docs/guides/developer_guides/smart_contracts/writing_contracts/how_to_emit_event.md
index 97918ab49b5..0c0c7fc9d33 100644
--- a/docs/docs/guides/developer_guides/smart_contracts/writing_contracts/how_to_emit_event.md
+++ b/docs/docs/guides/developer_guides/smart_contracts/writing_contracts/how_to_emit_event.md
@@ -54,14 +54,7 @@ Aztec.nr enables smart contract developers to design custom notes, meaning devel
 
 ## Unencrypted Events
 
-Unencrypted events are events which can be read by anyone.
-They can be emitted by both public and private functions.
-
-:::danger
-
-- Emitting unencrypted events from private function is a significant privacy leak and it should be considered by the developer whether it is acceptable.
-
-:::
+Unencrypted events are events which can be read by anyone. They can be emitted **only** by public functions.
 
 ### Call emit_unencrypted_log
 
diff --git a/noir-projects/noir-contracts/contracts/token_contract/src/types/token_note.nr b/noir-projects/noir-contracts/contracts/token_contract/src/types/token_note.nr
index 1b83782f9e6..2d678006e7f 100644
--- a/noir-projects/noir-contracts/contracts/token_contract/src/types/token_note.nr
+++ b/noir-projects/noir-contracts/contracts/token_contract/src/types/token_note.nr
@@ -18,6 +18,7 @@ trait OwnedNote {
 global TOKEN_NOTE_LEN: Field = 3; // 3 plus a header.
 global TOKEN_NOTE_BYTES_LEN: Field = 3 * 32 + 64;
 
+// docs:start:TokenNote
 #[aztec(note)]
 struct TokenNote {
     // The amount of tokens in the note
@@ -27,6 +28,7 @@ struct TokenNote {
     // Randomness of the note to hide its contents
     randomness: Field,
 }
+// docs:end:TokenNote
 
 impl NoteInterface<TOKEN_NOTE_LEN, TOKEN_NOTE_BYTES_LEN> for TokenNote {
     // docs:start:nullifier
diff --git a/yarn-project/cli/README.md b/yarn-project/cli/README.md
index cb164a202a4..76a90f506b2 100644
--- a/yarn-project/cli/README.md
+++ b/yarn-project/cli/README.md
@@ -7,7 +7,7 @@ The Aztec CLI `aztec-cli` is a command-line interface (CLI) tool for interacting
 1. In your terminal, download the sandbox by running
 
 ```
-bash -i <(curl -s install.aztec.network)
+bash -i <(curl -s https://install.aztec.network)
 ```
 
 2. Verify the installation: After the installation is complete, run the following command to verify that `aztec-cli` is installed correctly:
diff --git a/yarn-project/end-to-end/src/sample-dapp/connect.mjs b/yarn-project/end-to-end/src/sample-dapp/connect.mjs
index 6486f7447a1..560a337ba33 100644
--- a/yarn-project/end-to-end/src/sample-dapp/connect.mjs
+++ b/yarn-project/end-to-end/src/sample-dapp/connect.mjs
@@ -5,8 +5,8 @@ const { PXE_URL = 'http://localhost:8080' } = process.env;
 
 async function main() {
   const pxe = createPXEClient(PXE_URL);
-  const { chainId } = await pxe.getNodeInfo();
-  console.log(`Connected to chain ${chainId}`);
+  const { l1ChainId } = await pxe.getNodeInfo();
+  console.log(`Connected to chain ${l1ChainId}`);
 }
 
 main().catch(err => {