docs: point the contract standards at the Aztec Foundation's aztec-standards repo, and fix the private FPC salt

docs/developer_versioned_docs/version-v5.2.0/docs/aztec-js/how_to_pay_fees.md

@@ -181,7 +181,7 @@ const { receipt: tx } = await bananaCoin.methods
 For transactions where the fee payment itself should be private, you can use a fully private FPC, one that holds Fee Juice claimed from L1 as an internal private balance, works on every network, and never needs an onchain deployment. See [Pay Fees Privately](./how_to_use_private_fee_juice.md) for how this pattern works and a walkthrough using a community-built example.
 
 :::tip Shared salt for privacy
-When multiple apps derive the same private FPC address (using the same artifact and salt), every private fee payment joins a single, larger privacy set. See [recommended salt](./how_to_use_private_fee_juice.md#recommended-salt-0) for details.
+When multiple apps derive the same private FPC address (using the same artifact and salt), every private fee payment joins a single, larger privacy set. See [recommended salt](./how_to_use_private_fee_juice.md#recommended-salt-1) for details.
 :::
 
 ### Third-party FPCs on testnet and mainnet

docs/developer_versioned_docs/version-v5.2.0/docs/aztec-js/how_to_use_private_fee_juice.md

@@ -34,7 +34,7 @@ This section describes the design pattern using the `private-fee-juice` package'
 
 Two different salt values show up in this flow; it's worth naming them up front so they don't get confused:
 
-- **Deployment salt.** Used to derive the FPC's contract address. Once a community agrees on the bytecode and this salt, everyone can derive the same address locally without an onchain deployment tx. The convention for the `private-fee-juice` `PrivateFPC` is `Fr.ZERO` (see [Recommended salt](#recommended-salt-0)).
+- **Deployment salt.** Used to derive the FPC's contract address. Once a community agrees on the bytecode and this salt, everyone can derive the same address locally without an onchain deployment tx. The canonical value for the `private-fee-juice` `PrivateFPC` is `1` (see [Recommended salt](#recommended-salt-1)).
 - **Bridge salt.** A random value the user chooses per L1 deposit. Combined with the user's Aztec address, it derives the _bridge secret_ (`secret = poseidon2([salt, claimer], DOM_SEP__FPC_BRIDGE_SECRET)`), whose hash is passed as the `secretHash` on the L1 deposit. Only the user knows the preimage, so only the user can later produce the `secret` that `FeeJuice.claim` requires to consume the L1-to-L2 message.
 
 `PrivateFPC.mint(amount, salt, leaf_index)` and `PrivateFPC.mint_and_pay_fee(amount, salt, leaf_index)` take the **bridge** salt (along with the leaf index and the user's claimer address, which is `msg_sender`) to reconstruct the Fee Juice claim nullifier and verify the bridge was consumed.
@@ -70,9 +70,9 @@ Fee payments add one extra observable: the transaction's fee payer address, set
 
 This is the whole point of a fully private FPC. Because you don't have to deploy it on L2, there is no race to "be the deployer": the only thing that matters is that everyone agrees on the address.
 
-## Recommended salt: `0`
+## Recommended salt: `1`
 
-Two parties derive the same contract address if and only if they use the same compiled artifact and the same deployment salt. For any fully private FPC, using a common salt maximizes the shared privacy set. The community convention for the `private-fee-juice` `PrivateFPC` is `Fr.ZERO`.
+Two parties derive the same contract address if and only if they use the same compiled artifact and the same deployment salt. For any fully private FPC, using a common salt maximizes the shared privacy set. The canonical salt for the `private-fee-juice` `PrivateFPC` is `1` (`Fr.ONE`).
 
 This is a convention, not a protocol-enforced default. It is up to each developer to pass the salt when registering the contract with their PXE, just as they choose any other deployment parameter. Following the convention means your users' private fee payments join the same privacy set as every other app that follows it.
 

docs/developer_versioned_docs/version-v5.2.0/docs/aztec-nr/standards/aip-20.md

@@ -4,7 +4,7 @@ sidebar_position: 1
 description: Fungible token standard with private balances, partial-note transfers, and recursive note consumption.
 ---
 
-[Source](https://github.com/defi-wonderland/aztec-standards/tree/dev/src/token_contract)
+[Source](https://github.com/AztecProtocol/aztec-standards/tree/v5.2.0/src/token_contract)
 
 AIP-20 defines a fungible token with support for private balances (stored as notes in the note hash tree), public balances (stored in contract public storage), and a hybrid transfer path between the two.
 

docs/developer_versioned_docs/version-v5.2.0/docs/aztec-nr/standards/aip-4626.md

@@ -4,7 +4,7 @@ sidebar_position: 3
 description: Yield-bearing vault standard with share conversion across private and public contexts.
 ---
 
-[Source](https://github.com/defi-wonderland/aztec-standards/tree/dev/src/vault_contract) (extends the AIP-20 token contract)
+[Source](https://github.com/AztecProtocol/aztec-standards/tree/v5.2.0/src/vault_contract) (extends the AIP-20 token contract)
 
 AIP-4626 extends [AIP-20](./aip-20.md) to describe a tokenized vault: a contract that holds an underlying asset and issues shares representing a proportional claim on that asset. It mirrors the design of ERC-4626 but adapts the share conversion arithmetic for Aztec's `u128` integer type.
 

docs/developer_versioned_docs/version-v5.2.0/docs/aztec-nr/standards/aip-721.md

@@ -4,7 +4,7 @@ sidebar_position: 2
 description: Non-fungible token standard with private ownership, partial-note support, and commitment-based transfers.
 ---
 
-[Source](https://github.com/defi-wonderland/aztec-standards/tree/dev/src/nft_contract)
+[Source](https://github.com/AztecProtocol/aztec-standards/tree/v5.2.0/src/nft_contract)
 
 AIP-721 defines a non-fungible token (NFT). Each token is identified by a unique `token_id` field. Tokens can be held privately in the note hash tree or publicly in a map from `token_id` to owner address.
 

docs/developer_versioned_docs/version-v5.2.0/docs/aztec-nr/standards/dripper.md

@@ -4,6 +4,6 @@ sidebar_position: 6
 description: Convenience faucet for minting tokens into private or public balances during development.
 ---
 
-[Source](https://github.com/defi-wonderland/aztec-standards/tree/dev/src/dripper)
+[Source](https://github.com/AztecProtocol/aztec-standards/tree/v5.2.0/src/dripper)
 
 The `aztec-standards` repository also ships a **Dripper** contract — a convenience faucet for minting tokens into private or public balances during development. It is not a formal AIP standard and should not be used in production.

docs/developer_versioned_docs/version-v5.2.0/docs/aztec-nr/standards/escrow.md

@@ -4,7 +4,7 @@ sidebar_position: 4
 description: Minimal token and NFT custody contract with salt-based authorization.
 ---
 
-[Source](https://github.com/defi-wonderland/aztec-standards/tree/dev/src/escrow_contract)
+[Source](https://github.com/AztecProtocol/aztec-standards/tree/v5.2.0/src/escrow_contract)
 
 The Escrow standard provides a minimal contract for holding tokens or NFTs on behalf of a single owner. Rather than storing the owner in mutable private state — which would require note discovery and decryption on every authorization check — the owner is encoded in the contract's own `salt` and thus baked into the contract address at deploy time. This makes authorization a simple field comparison against immutable deployment parameters: cheaper, simpler, and impossible to front-run.
 

docs/developer_versioned_docs/version-v5.2.0/docs/aztec-nr/standards/index.md

@@ -1,17 +1,17 @@
 ---
 title: Aztec Contract Standards
 sidebar_position: 0
-description: Overview of Aztec Improvement Proposal (AIP) contract standards maintained by DeFi Wonderland.
+description: Overview of Aztec Improvement Proposal (AIP) contract standards maintained by the Aztec Foundation.
 ---
 
 Aztec contract standards define shared interfaces and behaviors for common onchain primitives. They serve the same role that ERC standards play on Ethereum: establishing conventions that allow contracts, wallets, and tooling to interoperate without prior coordination.
 
-The standards described in this section are maintained by [DeFi Wonderland](https://github.com/defi-wonderland/aztec-standards) in the `aztec-standards` repository. Each standard is identified by an **Aztec Improvement Proposal (AIP)** number that mirrors its Ethereum counterpart where applicable (AIP-20 corresponds to ERC-20, AIP-721 to ERC-721, AIP-4626 to ERC-4626).
+The standards described in this section are maintained by the Aztec Foundation in the [`aztec-standards` repository](https://github.com/AztecProtocol/aztec-standards). Each standard is identified by an **Aztec Improvement Proposal (AIP)** number that mirrors its Ethereum counterpart where applicable (AIP-20 corresponds to ERC-20, AIP-721 to ERC-721, AIP-4626 to ERC-4626).
 
 Because Aztec contracts have both private and public execution contexts, the standards are more involved than their Ethereum equivalents. Transfers can move value between private notes and public balances, and many operations require coordination between encrypted state and transparent state within a single transaction.
 
 :::note
-The code examples in this section are taken from the [aztec-standards repository](https://github.com/defi-wonderland/aztec-standards) maintained by DeFi Wonderland. They will differ from the reference contract implementations shipped in the [aztec-packages repo](https://github.com/AztecProtocol/aztec-packages) under `noir-projects/noir-contracts/contracts/`. When in doubt, consult the aztec-standards github repo for the canonical standard interfaces.
+The code examples in this section are taken from the [aztec-standards repository](https://github.com/AztecProtocol/aztec-standards) maintained by the Aztec Foundation. They will differ from the reference contract implementations shipped in the [aztec-packages repo](https://github.com/AztecProtocol/aztec-packages) under `noir-projects/noir-contracts/contracts/`. When in doubt, consult the aztec-standards github repo for the canonical standard interfaces.
 :::
 
 ## Standards
@@ -30,4 +30,4 @@ The code examples in this section are taken from the [aztec-standards repository
 - [Deploying a Token Contract](../../tutorials/js_tutorials/aztecjs-getting-started.md) — deploy and interact with the reference token contract using Aztec.js
 - [Counter Contract](../../tutorials/contract_tutorials/counter_contract.md) — introduces private state, notes, and balance management
 
-For the canonical implementations and latest interface specifications, refer to the [aztec-standards repository](https://github.com/defi-wonderland/aztec-standards) maintained by DeFi Wonderland.
+For the canonical implementations and latest interface specifications, refer to the [aztec-standards repository](https://github.com/AztecProtocol/aztec-standards) maintained by the Aztec Foundation.

docs/developer_versioned_docs/version-v5.2.0/docs/tutorials/js_tutorials/aztecjs-getting-started.md

@@ -197,7 +197,7 @@ Have a look at the [contract source](https://github.com/AztecProtocol/aztec-pack
 
 The pre-compiled token contract used in this tutorial is Aztec's reference implementation. It covers the core operations you need to get started: minting, private transfers, and public balance management.
 
-For production applications, consider the **AIP-20 Token Standard** maintained by [DeFi Wonderland](https://github.com/defi-wonderland/aztec-standards/tree/dev/src/token_contract). AIP-20 formalizes the same patterns used in the reference contract and adds:
+For production applications, consider the **AIP-20 Token Standard** maintained by the Aztec Foundation in the [`aztec-standards` repository](https://github.com/AztecProtocol/aztec-standards/tree/v5.2.0/src/token_contract). AIP-20 formalizes the same patterns used in the reference contract and adds:
 
 - **Commitment-based transfers** for DeFi protocols where the recipient is determined asynchronously
 - **Recursive note consumption** for handling large balances that span many notes

docs/developer_versioned_docs/version-v6.0.0/docs/aztec-js/how_to_pay_fees.md

@@ -182,7 +182,7 @@ const { receipt: tx } = await bananaCoin.methods
 For transactions where the fee payment itself should be private, you can use a fully private FPC, one that holds Fee Juice claimed from L1 as an internal private balance, works on every network, and never needs an onchain deployment. See [Pay Fees Privately](./how_to_use_private_fee_juice.md) for how this pattern works and a walkthrough using a community-built example.
 
 :::tip Shared salt for privacy
-When multiple apps derive the same private FPC address (using the same artifact and salt), every private fee payment joins a single, larger privacy set. See [recommended salt](./how_to_use_private_fee_juice.md#recommended-salt-0) for details.
+When multiple apps derive the same private FPC address (using the same artifact and salt), every private fee payment joins a single, larger privacy set. See [recommended salt](./how_to_use_private_fee_juice.md#recommended-salt-1) for details.
 :::
 
 ### Third-party FPCs on testnet and mainnet

docs/developer_versioned_docs/version-v6.0.0/docs/aztec-js/how_to_use_private_fee_juice.md

@@ -35,7 +35,7 @@ This section describes the design pattern using the `private-fee-juice` package'
 
 Two different salt values show up in this flow; it's worth naming them up front so they don't get confused:
 
-- **Deployment salt.** Used to derive the FPC's contract address. Once a community agrees on the bytecode and this salt, everyone can derive the same address locally without an onchain deployment tx. The convention for the `private-fee-juice` `PrivateFPC` is `Fr.ZERO` (see [Recommended salt](#recommended-salt-0)).
+- **Deployment salt.** Used to derive the FPC's contract address. Once a community agrees on the bytecode and this salt, everyone can derive the same address locally without an onchain deployment tx. The canonical value for the `private-fee-juice` `PrivateFPC` is `1` (see [Recommended salt](#recommended-salt-1)).
 - **Bridge salt.** A random value the user chooses per L1 deposit. Combined with the user's Aztec address, it derives the _bridge secret_ (`secret = poseidon2([salt, claimer], DOM_SEP__FPC_BRIDGE_SECRET)`), whose hash is passed as the `secretHash` on the L1 deposit. Only the user knows the preimage, so only the user can later produce the `secret` that `FeeJuice.claim` requires to consume the L1-to-L2 message.
 
 `PrivateFPC.mint(amount, salt, leaf_index)` and `PrivateFPC.mint_and_pay_fee(amount, salt, leaf_index)` take the **bridge** salt (along with the leaf index and the user's claimer address, which is `msg_sender`) to reconstruct the Fee Juice claim nullifier and verify the bridge was consumed.
@@ -71,9 +71,9 @@ Fee payments add one extra observable: the transaction's fee payer address, set
 
 This is the whole point of a fully private FPC. Because you don't have to deploy it on L2, there is no race to "be the deployer": the only thing that matters is that everyone agrees on the address.
 
-## Recommended salt: `0`
+## Recommended salt: `1`
 
-Two parties derive the same contract address if and only if they use the same compiled artifact and the same deployment salt. For any fully private FPC, using a common salt maximizes the shared privacy set. The community convention for the `private-fee-juice` `PrivateFPC` is `Fr.ZERO`.
+Two parties derive the same contract address if and only if they use the same compiled artifact and the same deployment salt. For any fully private FPC, using a common salt maximizes the shared privacy set. The `private-fee-juice` package fixes the canonical salt for its `PrivateFPC` at `1` (`Fr.ONE`) and records it, with the expected address for the Aztec version the package targets, in [`canonical-deployment.json`](https://github.com/alejoamiras/ecosystem-tooling/blob/main/packages/private-fee-juice/canonical-deployment.json).
 
 This is a convention, not a protocol-enforced default. It is up to each developer to pass the salt when registering the contract with their PXE, just as they choose any other deployment parameter. Following the convention means your users' private fee payments join the same privacy set as every other app that follows it.