feat(aztec-nr): wire constrained message delivery

docs/docs-developers/docs/aztec-nr/framework-description/note_delivery.md

@@ -140,13 +140,15 @@ self.storage.balances.at(admin).add(amount)
 
 **Onchain delivery with guaranteed correct content.**
 
-**WARNING**: This mode is [currently NOT fully constrained](https://github.com/AztecProtocol/aztec-packages/issues/14565). The log's tag is unconstrained, meaning a malicious sender could prevent the recipient from finding the message.
-
 - **Use when:** The sender cannot be trusted to deliver correctly (e.g., paying fees, creating notes for others, multisig configuration changes). Use this when you need to prove to a contract that the delivery has been done correctly. You can imagine a private NFT sale escrow contract where the escrow would be holding the NFT (the contract itself would be the NFT note owner) and then the escrow would release the NFT to the buyer once the NFT buyer pays the seller. In this case the `NFTSale::buy(...)` function would trigger the payment token transfer from the buyer to the seller and it would need to use `ONCHAIN_CONSTRAINED` delivery otherwise the escrow contract would be willing to transfer the NFT without the NFT seller actually being able to then spend the money. Note that for the transfer of the NFT from the escrow contract to the buyer you could use `OFFCHAIN` delivery because the delivery and encryption would be done in the buyer's PXE and hence there is alignment.
 - **Costs:** DA gas fees for the encrypted log, proving time overhead for encryption and tagging
-- **Guarantees:** Recipient receives correctly encrypted content (once tag constraining is implemented, recipient will be able to find it)
+- **Guarantees:** Recipient receives correctly encrypted content and can discover the message through constrained tags
 - **Privacy:** High - encrypted log reveals minimal information
 
+By default, constrained delivery uses the wallet-supplied sender for tags (typically the account that initiated the
+transaction), the same default as unconstrained delivery. Use `.with_sender(...)` when the intended sender differs from
+that account.
+
 ```rust
 // Minting to an arbitrary recipient - must guarantee delivery
 self.storage.balances.at(recipient).add(amount)
@@ -175,20 +177,26 @@ When your wallet submits a transaction, it tells PXE which address to use as the
 
 ### Discovering Notes from Unknown Senders
 
-**You cannot receive notes from an unknown sender** without additional mechanisms. The tagging system requires you to know the sender's address in advance to compute the shared secret needed to find the note (i.e., the sender needs to be added to your wallet).
+For address-secret tagging, **you cannot receive notes from an unknown sender** without additional mechanisms. The
+tagging system requires you to know the sender's address in advance to compute the shared secret needed to find the note
+(i.e., the sender needs to be added to your wallet). This applies to the default `onchain_unconstrained()` sender-for-tags
+path.
 
 There are three approaches to solve this:
 
 **a) Brute force search** - Download every log and attempt to decrypt it. This becomes prohibitively expensive as the network grows.
 
-**b) Known sender tagging** (current implementation) - Only receive notes from senders whose addresses you've registered in your PXE. This is very fast and allows you to block spammers by removing them from your sender list. However, you must know who might send you notes in advance.
+**b) Known sender tagging** - Only receive notes from senders whose addresses you've registered in your PXE. This is very fast and allows you to block spammers by removing them from your sender list. However, you must know who might send you notes in advance.
 
-**c) Handshaking protocols** (not yet implemented) - A two-phase approach where senders first perform a "handshake" that notifies you of their existence, then use regular tagging afterward. This trades off either privacy (public handshake events) or performance (scanning all handshake logs).
+**c) Handshaking protocols** - A two-phase approach where senders first perform a handshake that notifies you of their
+existence, then use regular tagging afterward. Constrained delivery uses this kind of approach through the standard
+handshake registry: the sender emits a recipient-discoverable handshake, then uses regular constrained tags derived from
+that handshake secret.
 
 **Workarounds for receiving notes from unknown senders:**
 - Require senders to register in a contract first, then search for notes from all registered senders
 - Share sender addresses through offchain communication
-- Implement a custom discovery mechanism in your contract
+- Use constrained delivery when you need recipient-discoverable handshakes and constrained message tags
 
 See the [Note Discovery](../../foundational-topics/advanced/storage/note_discovery.md) documentation for technical details on the tagging mechanism.
 
@@ -234,8 +242,8 @@ fn transfer(amount: u128, sender: AztecAddress, recipient: AztecAddress) {
 #[external("private")]
 #[initializer]
 fn constructor(admin: AztecAddress) {
-    // Admin is the owner of the note and is motivated to receive it
-    // Use unconstrained delivery since we don't know if deployer is incentivized
+    // Admin is the owner of the note.
+    // Use constrained delivery since we don't know if the deployer is incentivized.
     self.storage.admin
         .initialize(AddressNote { address: admin }, admin)
         .deliver(MessageDelivery::onchain_constrained());

docs/docs-developers/docs/aztec-nr/framework-description/state_variables.md

@@ -273,7 +273,7 @@ When working with private state variables, many operations return a `NoteMessage
 #### Delivery Methods
 
 Private notes need to be communicated to their recipients so they know the note exists and can use it. The [`NoteMessage`](pathname:///aztec-nr-api/#api_ref_version/noir_aztec/note/struct.NoteMessage) wrapper forces you to make an explicit choice about how this happens:
-  - [`MessageDelivery::onchain_constrained()`](pathname:///aztec-nr-api/#api_ref_version/noir_aztec/messages/delivery/global.MessageDelivery): Verified in the circuit (most secure, but highest cost) - Use when the sender cannot be trusted to deliver correctly (e.g., protocol fees, multisig config updates). **Warning:** Currently [not fully constrained](https://github.com/AztecProtocol/aztec-packages/issues/14565) - the log's tag is unconstrained.
+  - [`MessageDelivery::onchain_constrained()`](pathname:///aztec-nr-api/#api_ref_version/noir_aztec/messages/delivery/global.MessageDelivery): Verified in the circuit (most secure, but highest cost) - Use when the sender cannot be trusted to deliver correctly (e.g., protocol fees, multisig config updates).
   - [`MessageDelivery::onchain_unconstrained()`](pathname:///aztec-nr-api/#api_ref_version/noir_aztec/messages/delivery/global.MessageDelivery): Message stored onchain but no guarantees on content - Use when the sender is incentivized to deliver correctly but may not have an offchain channel to the recipient.
   - [`MessageDelivery::offchain()`](pathname:///aztec-nr-api/#api_ref_version/noir_aztec/messages/delivery/global.MessageDelivery): Lowest cost, no onchain data - Use when the sender and recipient can communicate and the sender is incentivized to deliver correctly.
 

docs/docs-developers/docs/foundational-topics/advanced/storage/note_discovery.md

@@ -59,14 +59,15 @@ This sender address is used along with the recipient address to compute the shar
 
 #### Registering known senders
 
-To discover notes from a particular sender, the recipient's PXE must know the sender's address in advance so it can compute the shared tagging secret. Register senders using the wallet API:
+To discover address-secret notes from a particular sender, the recipient's PXE must know the sender's address in advance so it can compute the shared tagging secret. Register senders using the wallet API:
 
 ```typescript
 // Register a sender so your PXE can discover notes from them
 await wallet.registerSender(senderAddress);
 ```
 
 Notes sent to yourself are always discoverable — the PXE automatically adds all local accounts as implicit senders.
+Constrained-delivery handshakes are discovered through the handshake registry instead.
 
 ### The sync process
 
@@ -96,25 +97,28 @@ This means there's a practical limit on how many logs a single sender can emit t
 
 ### Limitations and solutions
 
-#### You cannot receive tagged notes from an unknown sender
+#### You cannot receive address-secret tagged notes from an unknown sender
 
-Without knowing the sender's address, you cannot create the shared secret needed to derive the note tag. This is a fundamental limitation of the current tagging scheme.
+Without knowing the sender's address, you cannot create the shared secret needed to derive an address-secret note tag.
+This is a fundamental limitation of address-secret tagging.
 
 There are three broad families of solutions to this problem:
 
 **a) Brute force search** - Scan every single log and test if it decrypts. This has obvious performance issues as the network grows and becomes prohibitively expensive.
 
-**b) Tagging with known sender** (current implementation) - You know who will send you messages and search for those specifically. This is very fast and allows you to remove senders who spam you. However, we don't currently have a mechanism for constraining this (i.e., guaranteeing that the recipient will find the message).
+**b) Tagging with known sender** - You know who will send you messages and search for those specifically. This is very fast and allows you to remove senders who spam you. However, address-secret tagging requires knowing who might send you notes in advance.
 
-**c) Tagging with handshaking** - An intermediate solution where you can be notified of new senders. A handshake occurs onchain that lets the recipient discover a new sender, and from that point on there's regular tagging. This design either:
+**c) Tagging with handshaking** - An intermediate solution where the sender performs a handshake that lets the recipient discover a new sender, and from that point on there's regular tagging. This design either:
 - Is fast but leaks privacy (e.g., a public event with "new handshake for Alice!")
 - Is slow but doesn't leak (you brute force scan all logs from a handshake contract, testing if any handshakes are for you)
 
 The handshaking design space is large — for example, you could set up infrastructure where a server searches handshakes for you, trading off infrastructure requirements for performance.
 
-**Handshaking is not currently implemented in Aztec.nr.** For now, if you need to receive notes from unknown senders, potential workarounds include:
+Aztec.nr's constrained delivery uses the standard handshake registry for this purpose. If you need recipient-discoverable handshakes and constrained message tags, use `MessageDelivery::onchain_constrained()`.
+
+Other potential workarounds include:
 - Having senders register themselves in a contract first, allowing recipients to search for note tags from all registered senders
-- Using offchain communication to share sender addresses with recipients, who then call `wallet.registerSender(address)` to enable discovery
+- Using offchain communication to share sender addresses with recipients, who then call `wallet.registerSender(address)` to enable address-secret discovery
 - Implementing a custom discovery mechanism in your contract
 
 See the [Note Delivery](../../../aztec-nr/framework-description/note_delivery.md) documentation for more details on how the sender is used when delivering notes.

docs/examples/webapp-tutorial/contracts/src/main.nr

@@ -95,7 +95,7 @@ pub contract PodRacing {
             .at(game_id)
             .at(player)
             .insert(GameRoundNote::new(track1, track2, track3, track4, track5, round, player))
-            .deliver(MessageDelivery::onchain_constrained());
+            .deliver(MessageDelivery::onchain_unconstrained());
 
         self.enqueue(PodRacing::at(self.context.this_address()).validate_and_play_round(
             player,

noir-projects/aztec-nr/aztec/src/contract_self/contract_self_private.nr

@@ -187,7 +187,7 @@ impl<Storage, CallSelf, EnqueueSelf, CallSelfStatic, EnqueueSelfStatic, CallInte
     ///
     /// # Cost
     ///
-    /// Private event emission always results in the creation of a nullifer, which acts as a commitment to the event
+    /// Private event emission always results in the csreation of a nullifer, which acts as a commitment to the event
     /// and is used by third parties to verify its authenticity. See [`EventMessage::deliver_to`] for the costs
     /// associated to delivery.
     ///

noir-projects/aztec-nr/aztec/src/messages/delivery/builder.nr

@@ -19,8 +19,7 @@ use super::tag_secret_derivation::TagSecretDerivation;
 /// ## Construction
 ///
 /// The fields are private and there is no public constructor: a `MessageDelivery` can only be produced by a
-/// [`MessageDeliveryBuilder`] that enforces valid configurations, so invalid field combinations cannot be
-/// represented to the consumer.
+/// [`MessageDeliveryBuilder`]. The delivery APIs validate the built configuration before consuming it.
 pub struct MessageDelivery {
     mode: DeliveryMode,
     tag_secret_derivation: TagSecretDerivation,
@@ -144,10 +143,6 @@ impl MessageDelivery {
 
     /// Delivers the message on-chain, guaranteeing the recipient will receive the correct content.
     ///
-    /// >**WARNING**: this delivery mode is [currently NOT fully
-    /// constrained](https://github.com/AztecProtocol/aztec-packages/issues/14565). The log's tag is unconstrained,
-    /// meaning a malicious sender could manipulate it to prevent the recipient from finding the message.
-    ///
     /// ## Use Cases
     ///
     /// This delivery method is suitable for all use cases, since it always works as expected. It is however the most