From 26e779492457a69d06c01477139d1cdf2e0216a9 Mon Sep 17 00:00:00 2001 From: josh crites Date: Thu, 23 Apr 2026 17:08:07 +0000 Subject: [PATCH 1/3] cherry-pick: docs: fix v4.2.0 developer tutorial/guide bugs (#22618) (with conflicts) --- .../docs/aztec-js/how_to_use_authwit.md | 3 +- .../docs/aztec-nr/debugging.md | 28 ++++++---- .../contract_structure.md | 20 +++++++ .../functions/how_to_define_functions.md | 4 +- .../docs/aztec-nr/index.md | 11 ++++ .../docs/aztec-nr/testing_contracts.md | 40 +++++++++++-- .../contract_tutorials/counter_contract.md | 4 +- .../recursive_verification.md | 14 +++-- .../contract_tutorials/token_contract.md | 47 +++++++++++++++- .../testing_governance_rollup_upgrade.md | 3 + .../docs/aztec-js/how_to_pay_fees.md | 44 +++++++++++++++ .../advanced/how_to_prove_history.md | 12 ++-- .../advanced/how_to_retrieve_filter_notes.md | 4 +- .../advanced/writing_efficient_contracts.md | 4 +- .../docs/aztec-js/how_to_pay_fees.md | 2 +- .../docs/aztec-js/how_to_test.md | 2 +- .../docs/aztec-js/how_to_use_authwit.md | 3 +- .../docs/aztec-nr/debugging.md | 9 ++- .../advanced/how_to_prove_history.md | 12 ++-- .../advanced/how_to_retrieve_filter_notes.md | 4 +- .../advanced/writing_efficient_contracts.md | 4 +- .../contract_structure.md | 22 ++------ docs/docs-developers/docs/aztec-nr/index.md | 6 +- .../docs/aztec-nr/testing_contracts.md | 56 +++++++++---------- .../recursive_verification.md | 16 ++++-- .../contract_tutorials/token_contract.md | 39 ++++++++++++- .../testing_governance_rollup_upgrade.md | 3 + .../contracts/counter_contract/src/main.nr | 4 +- docs/examples/ts/bob_token_contract/index.ts | 4 +- 29 files changed, 311 insertions(+), 113 deletions(-) diff --git a/docs/developer_versioned_docs/version-v4.1.0-rc.2/docs/aztec-js/how_to_use_authwit.md b/docs/developer_versioned_docs/version-v4.1.0-rc.2/docs/aztec-js/how_to_use_authwit.md index 3103c25e60f4..fe03ed980f21 100644 --- a/docs/developer_versioned_docs/version-v4.1.0-rc.2/docs/aztec-js/how_to_use_authwit.md +++ b/docs/developer_versioned_docs/version-v4.1.0-rc.2/docs/aztec-js/how_to_use_authwit.md @@ -33,7 +33,8 @@ Therefore it is recommended to read the `aztec-nr` [guide on authwitnesses](../a The authwit system supports different intent types depending on your use case: -- **`CallIntent`**: Use when authorizing a specific contract function call. Contains `{ caller, action }` where `action` is a `ContractFunctionInteraction`. +- **`CallIntent`**: Use when authorizing a specific contract function call. Contains `{ caller, call }` where `call` is a `FunctionCall`, typically obtained with `await interaction.getFunctionCall()`. +- **`ContractFunctionInteractionCallIntent`**: Convenience form that takes the interaction directly. Contains `{ caller, action }` where `action` is a `ContractFunctionInteraction`; internally resolved to a `FunctionCall` before signing. - **`IntentInnerHash`**: Use when authorizing arbitrary data. Contains `{ consumer, innerHash }` where `consumer` is the contract that will verify the authwit. ## Create private authwits diff --git a/docs/developer_versioned_docs/version-v4.1.0-rc.2/docs/aztec-nr/debugging.md b/docs/developer_versioned_docs/version-v4.1.0-rc.2/docs/aztec-nr/debugging.md index d5af37e48e04..b9e0aaeb5c29 100644 --- a/docs/developer_versioned_docs/version-v4.1.0-rc.2/docs/aztec-nr/debugging.md +++ b/docs/developer_versioned_docs/version-v4.1.0-rc.2/docs/aztec-nr/debugging.md @@ -33,7 +33,11 @@ Log values from your contract using `debug_log`: ```rust // Import debug logging +<<<<<<< HEAD:docs/developer_versioned_docs/version-v4.1.0-rc.2/docs/aztec-nr/debugging.md use dep::aztec::oracle::debug_log::{ debug_log, debug_log_format }; +======= +use aztec::oracle::logging::{ debug_log, debug_log_format }; +>>>>>>> 31fedbddff (docs: fix v4.2.0 developer tutorial/guide bugs (#22618)):docs/developer_versioned_docs/version-v4.2.0/docs/aztec-nr/debugging.md // Log simple messages debug_log("checkpoint reached"); @@ -65,23 +69,20 @@ LOG_LEVEL="info;debug:simulator:client_execution_context;debug:simulator:client_ ``` :::info Log filter format -`LOG_LEVEL` accepts a semicolon-delimited list of filters. Each filter can be: - -- `level` - Sets default level for all modules -- `level:module` - Sets level for a specific module -- `level:module:submodule` - Sets level for a specific submodule +`LOG_LEVEL` is a semicolon-delimited list. The **first segment must be a bare log level** — it sets the default level for all modules. Subsequent segments are `level:module` (or `level:module:submodule`) overrides. ```bash # Default level only LOG_LEVEL="debug" -# Default level + specific module overrides +# Default level + module overrides LOG_LEVEL="info;debug:simulator;debug:execution" -# Default level + specific submodule overrides +# Default level + submodule overrides LOG_LEVEL="info;debug:simulator:client_execution_context;debug:simulator:client_view_context" ``` +A bare `level:module` (e.g. `LOG_LEVEL="warn:simulator"`) is **not valid** — the parser reads the first segment as the default level and rejects it with `Invalid log level: warn:simulator`. ::: ## Debugging common errors @@ -113,9 +114,12 @@ LOG_LEVEL="info;debug:simulator:client_execution_context;debug:simulator:client_ ### Quick Fixes for Common Issues ```bash -# Archiver sync issues - force progress with dummy transactions -aztec-wallet send transfer --from test0 --to test0 --amount 0 -aztec-wallet send transfer --from test0 --to test0 --amount 0 +# Archiver sync issues - force progress with dummy transactions. +# Assumes you have imported the local network test accounts +# (aztec-wallet import-test-accounts) and have a deployed token +# aliased as `testtoken`. +aztec-wallet send transfer --from test0 --contract-address testtoken --args accounts:test0 0 +aztec-wallet send transfer --from test0 --contract-address testtoken --args accounts:test0 0 # L1 to L2 message pending - wait for inclusion # Messages need 2 blocks to be processed @@ -207,7 +211,11 @@ LOG_LEVEL=verbose aztec start --local-network ### Common debug imports ```rust +<<<<<<< HEAD:docs/developer_versioned_docs/version-v4.1.0-rc.2/docs/aztec-nr/debugging.md use dep::aztec::oracle::debug_log::{ debug_log, debug_log_format }; +======= +use aztec::oracle::logging::{ debug_log, debug_log_format }; +>>>>>>> 31fedbddff (docs: fix v4.2.0 developer tutorial/guide bugs (#22618)):docs/developer_versioned_docs/version-v4.2.0/docs/aztec-nr/debugging.md ``` ### Check contract registration diff --git a/docs/developer_versioned_docs/version-v4.1.0-rc.2/docs/aztec-nr/framework-description/contract_structure.md b/docs/developer_versioned_docs/version-v4.1.0-rc.2/docs/aztec-nr/framework-description/contract_structure.md index 616a45b3f4ae..b1ebd129e07f 100644 --- a/docs/developer_versioned_docs/version-v4.1.0-rc.2/docs/aztec-nr/framework-description/contract_structure.md +++ b/docs/developer_versioned_docs/version-v4.1.0-rc.2/docs/aztec-nr/framework-description/contract_structure.md @@ -10,6 +10,7 @@ High-level structure of how Aztec smart contracts including the different compon ## Directory structure +<<<<<<< HEAD:docs/developer_versioned_docs/version-v4.1.0-rc.2/docs/aztec-nr/framework-description/contract_structure.md Here's a common layout for a basic Aztec.nr Contract project: ```text title="layout of an aztec contract project" @@ -19,6 +20,21 @@ Here's a common layout for a basic Aztec.nr Contract project: └── Nargo.toml <-- package and dependency management ``` +======= +When you create a new project with `aztec new my_project`, it generates a single-crate Noir contract project: + +```text title="layout of an aztec contract project" +─── my_project + ├── Nargo.toml <-- contract package and dependencies + └── src + └── main.nr <-- your contract +``` + +`Nargo.toml` declares the contract package (with `type = "contract"`) and its dependencies. Your contract code lives in `src/main.nr`. Noir tests using `#[test]` live alongside the contract in the same crate — see [Testing Contracts](../testing_contracts.md). + +To add another contract as a sibling of an existing one, run `aztec new ` from the parent directory (each contract is its own crate). To initialize a contract project inside an existing empty directory instead, `cd` into it and run `aztec init` (it takes no positional argument; pass `--name ` if you want the package name to differ from the directory name). + +>>>>>>> 31fedbddff (docs: fix v4.2.0 developer tutorial/guide bugs (#22618)):docs/developer_versioned_docs/version-v4.2.0/docs/aztec-nr/framework-description/contract_structure.md See the vanilla Noir docs for [more info on packages](https://noir-lang.org/docs/noir/modules_packages_crates/crates_and_packages). ## Contract block @@ -44,7 +60,11 @@ The `#[aztec]` macro performs a lot of the low-level operations required to take ## Imports +<<<<<<< HEAD:docs/developer_versioned_docs/version-v4.1.0-rc.2/docs/aztec-nr/framework-description/contract_structure.md Aside from the [`#[aztec]`](pathname:///aztec-nr-api/testnet/noir_aztec/macros/aztec/fn.aztec) macro import, all other imports need to go _inside_ the `contract` block - this is because `contract` acts like `mod`, creating a new [module](https://noir-lang.org/docs/noir/modules_packages_crates/modules). +======= +Aside from the [`#[aztec]`](pathname:///aztec-nr-api/mainnet/noir_aztec/macros/fn.aztec) macro import, all other imports need to go _inside_ the `contract` block - this is because `contract` acts like `mod`, creating a new [module](https://noir-lang.org/docs/noir/modules_packages_crates/modules). +>>>>>>> 31fedbddff (docs: fix v4.2.0 developer tutorial/guide bugs (#22618)):docs/developer_versioned_docs/version-v4.2.0/docs/aztec-nr/framework-description/contract_structure.md ```rust use aztec::macros::aztec; diff --git a/docs/developer_versioned_docs/version-v4.1.0-rc.2/docs/aztec-nr/framework-description/functions/how_to_define_functions.md b/docs/developer_versioned_docs/version-v4.1.0-rc.2/docs/aztec-nr/framework-description/functions/how_to_define_functions.md index cc59d3ad36b5..11cb65f6b55e 100644 --- a/docs/developer_versioned_docs/version-v4.1.0-rc.2/docs/aztec-nr/framework-description/functions/how_to_define_functions.md +++ b/docs/developer_versioned_docs/version-v4.1.0-rc.2/docs/aztec-nr/framework-description/functions/how_to_define_functions.md @@ -121,8 +121,8 @@ Create constructor-like functions using the `#[initializer]` annotation: #[initializer] #[external("private")] // We can name our initializer anything we want as long as it's marked as aztec(initializer) -fn initialize(headstart: u64, owner: AztecAddress) { - self.storage.counters.at(owner).add(headstart as u128).deliver( +fn initialize(headstart: u128, owner: AztecAddress) { + self.storage.counters.at(owner).add(headstart).deliver( MessageDelivery.ONCHAIN_CONSTRAINED, ); } diff --git a/docs/developer_versioned_docs/version-v4.1.0-rc.2/docs/aztec-nr/index.md b/docs/developer_versioned_docs/version-v4.1.0-rc.2/docs/aztec-nr/index.md index 2d77e12be70c..a3ec37bf7e84 100644 --- a/docs/developer_versioned_docs/version-v4.1.0-rc.2/docs/aztec-nr/index.md +++ b/docs/developer_versioned_docs/version-v4.1.0-rc.2/docs/aztec-nr/index.md @@ -42,16 +42,27 @@ storage.votes.insert(new_vote).deliver(vote_counter); // the vote counter accoun ### Flow +<<<<<<< HEAD:docs/developer_versioned_docs/version-v4.1.0-rc.2/docs/aztec-nr/index.md 1. Write your contract and specify your contract dependencies. Every contract written for Aztec will have aztec-nr as a dependency. Add it to your `Nargo.toml` with ```toml # Nargo.toml +======= +1. Write your contract and specify your contract dependencies. Create a new project with `aztec new my_project`, which creates a single-crate Noir contract project (`Nargo.toml` + `src/main.nr`) with the `aztec` dependency already configured. If you need additional dependencies, add them to `my_project/Nargo.toml`: + +```toml +# my_project/Nargo.toml +>>>>>>> 31fedbddff (docs: fix v4.2.0 developer tutorial/guide bugs (#22618)):docs/developer_versioned_docs/version-v4.2.0/docs/aztec-nr/index.md [dependencies] aztec = { git="https://github.com/AztecProtocol/aztec-nr/", tag="v4.1.0-rc.2", directory="aztec" } ``` +<<<<<<< HEAD:docs/developer_versioned_docs/version-v4.1.0-rc.2/docs/aztec-nr/index.md Update your `main.nr` contract file to use the Aztec.nr macros for writing contracts. +======= +Update your `my_project/src/main.nr` contract file to use the Aztec.nr macros for writing contracts. +>>>>>>> 31fedbddff (docs: fix v4.2.0 developer tutorial/guide bugs (#22618)):docs/developer_versioned_docs/version-v4.2.0/docs/aztec-nr/index.md ```rust title="setup" showLineNumbers use aztec::macros::aztec; diff --git a/docs/developer_versioned_docs/version-v4.1.0-rc.2/docs/aztec-nr/testing_contracts.md b/docs/developer_versioned_docs/version-v4.1.0-rc.2/docs/aztec-nr/testing_contracts.md index 5401e2f6a6d4..29f9ad3a3963 100644 --- a/docs/developer_versioned_docs/version-v4.1.0-rc.2/docs/aztec-nr/testing_contracts.md +++ b/docs/developer_versioned_docs/version-v4.1.0-rc.2/docs/aztec-nr/testing_contracts.md @@ -46,20 +46,37 @@ Always use `aztec test` instead of `nargo test`. The `TestEnvironment` requires ## Basic test structure +<<<<<<< HEAD:docs/developer_versioned_docs/version-v4.1.0-rc.2/docs/aztec-nr/testing_contracts.md ```rust use crate::MyContract; use aztec::{ protocol::address::AztecAddress, test::helpers::test_environment::TestEnvironment, }; +======= +Tests live in the same crate as your contract. `aztec new` creates a single-crate project, and the convention is to place `#[test]` functions in a `mod tests` block alongside the contract (or in submodules of the crate): -#[test] -unconstrained fn test_basic_flow() { - // 1. Create test environment - let mut env = TestEnvironment::new(); +```rust +use aztec::macros::aztec; +>>>>>>> 31fedbddff (docs: fix v4.2.0 developer tutorial/guide bugs (#22618)):docs/developer_versioned_docs/version-v4.2.0/docs/aztec-nr/testing_contracts.md - // 2. Create accounts - let owner = env.create_light_account(); +#[aztec] +pub contract MyContract { + // ...contract functions... +} + +mod tests { + use super::MyContract; + use aztec::test::helpers::test_environment::TestEnvironment; + + #[test] + unconstrained fn test_basic_flow() { + // 1. Create test environment + let mut env = TestEnvironment::new(); + + // 2. Create accounts + let _owner = env.create_light_account(); + } } ``` @@ -72,6 +89,7 @@ unconstrained fn test_basic_flow() { ::: :::tip Organizing test files +<<<<<<< HEAD:docs/developer_versioned_docs/version-v4.1.0-rc.2/docs/aztec-nr/testing_contracts.md You can organize tests in separate files: - Create `src/test.nr` with `mod utils;` to import helper functions @@ -79,6 +97,16 @@ You can organize tests in separate files: - Import the test module in `src/main.nr` with `mod test;` - Share setup functions in `src/test/utils.nr` ::: +======= +For larger test suites, split tests into submodules of your crate rather than keeping them all inside `main.nr`: + +- Create modules like `src/transfer_tests.nr`, `src/auth_tests.nr` +- Declare them from `src/main.nr` with `mod transfer_tests;`, `mod auth_tests;` +- Share setup functions in `src/test_utils.nr` + +See the [aztec-standards token contract](https://github.com/defi-wonderland/aztec-standards/tree/dev/src/token_contract) for a worked example of this layout. +::: +>>>>>>> 31fedbddff (docs: fix v4.2.0 developer tutorial/guide bugs (#22618)):docs/developer_versioned_docs/version-v4.2.0/docs/aztec-nr/testing_contracts.md ## Deploying contracts diff --git a/docs/developer_versioned_docs/version-v4.1.0-rc.2/docs/tutorials/contract_tutorials/counter_contract.md b/docs/developer_versioned_docs/version-v4.1.0-rc.2/docs/tutorials/contract_tutorials/counter_contract.md index 15c73bdb3285..3853e9c0b0e6 100644 --- a/docs/developer_versioned_docs/version-v4.1.0-rc.2/docs/tutorials/contract_tutorials/counter_contract.md +++ b/docs/developer_versioned_docs/version-v4.1.0-rc.2/docs/tutorials/contract_tutorials/counter_contract.md @@ -125,8 +125,8 @@ Let’s create a constructor method to run on deployment that assigns an initial #[initializer] #[external("private")] // We can name our initializer anything we want as long as it's marked as aztec(initializer) -fn initialize(headstart: u64, owner: AztecAddress) { - self.storage.counters.at(owner).add(headstart as u128).deliver( +fn initialize(headstart: u128, owner: AztecAddress) { + self.storage.counters.at(owner).add(headstart).deliver( MessageDelivery.ONCHAIN_CONSTRAINED, ); } diff --git a/docs/developer_versioned_docs/version-v4.1.0-rc.2/docs/tutorials/contract_tutorials/recursive_verification.md b/docs/developer_versioned_docs/version-v4.1.0-rc.2/docs/tutorials/contract_tutorials/recursive_verification.md index 0949806e796b..831552ab6a40 100644 --- a/docs/developer_versioned_docs/version-v4.1.0-rc.2/docs/tutorials/contract_tutorials/recursive_verification.md +++ b/docs/developer_versioned_docs/version-v4.1.0-rc.2/docs/tutorials/contract_tutorials/recursive_verification.md @@ -202,9 +202,9 @@ nargo test Expected output: ```text -[hello_circuit] Running 1 test functions -[hello_circuit] Testing test_main... ok -[hello_circuit] All tests passed +[hello_circuit] Running 1 test function +[hello_circuit] Testing test_main ... ok +[hello_circuit] 1 test passed ``` **Tip**: Circuit tests run without generating proofs, making them fast for development. Use them to verify your circuit logic before the more expensive proof generation step. @@ -228,9 +228,15 @@ The contract demonstrates several important patterns: Use `aztec new` to generate the contract project structure: ```bash +<<<<<<< HEAD:docs/developer_versioned_docs/version-v4.1.0-rc.2/docs/tutorials/contract_tutorials/recursive_verification.md aztec new contract --name ValueNotEqual +======= +aztec new --name ValueNotEqual contract +>>>>>>> 31fedbddff (docs: fix v4.2.0 developer tutorial/guide bugs (#22618)):docs/developer_versioned_docs/version-v4.2.0/docs/tutorials/contract_tutorials/recursive_verification.md ``` +The `aztec new` wrapper stops parsing arguments at the first positional, so `--name` must come **before** the `contract` path — otherwise the flag is silently dropped and the Nargo package ends up named `contract`. The Nargo package name (`--name`) is independent of the Noir contract name declared inside `main.nr`; the artifact filename downstream is driven by the contract name. + This creates: ```tree @@ -701,7 +707,7 @@ Expected output: Proof verification: SUCCESS Using deflattenFields to convert proof... VK size: 115 -Proof size: 508 +Proof size: 500 Public inputs: 1 Done ``` diff --git a/docs/developer_versioned_docs/version-v4.1.0-rc.2/docs/tutorials/contract_tutorials/token_contract.md b/docs/developer_versioned_docs/version-v4.1.0-rc.2/docs/tutorials/contract_tutorials/token_contract.md index cf616fc69c6d..1661b8660c6d 100644 --- a/docs/developer_versioned_docs/version-v4.1.0-rc.2/docs/tutorials/contract_tutorials/token_contract.md +++ b/docs/developer_versioned_docs/version-v4.1.0-rc.2/docs/tutorials/contract_tutorials/token_contract.md @@ -39,9 +39,15 @@ We'll create BOB tokens with: Let's create a simple yarn + aztec.nr project: ```bash +<<<<<<< HEAD:docs/developer_versioned_docs/version-v4.1.0-rc.2/docs/tutorials/contract_tutorials/token_contract.md mkdir bob_token_contract cd bob_token_contract yarn init +======= +aztec new bob_token +cd bob_token +yarn init -y +>>>>>>> 31fedbddff (docs: fix v4.2.0 developer tutorial/guide bugs (#22618)):docs/developer_versioned_docs/version-v4.2.0/docs/tutorials/contract_tutorials/token_contract.md # This is to ensure yarn uses node_modules instead of pnp for dependency installation yarn config set nodeLinker node-modules yarn add @aztec/aztec.js@v4.1.0-rc.2 @aztec/accounts@v4.1.0-rc.2 @aztec/test-wallet@v4.1.0-rc.2 @aztec/kv-store@v4.1.0-rc.2 @@ -90,6 +96,10 @@ pub contract BobToken { These are the different macros we need to define the visibility of functions, and some handy types and functions. +:::note +You may see "unused import" warnings from your IDE or compiler for `only_self`, `MessageDelivery`, and `Owned`. That's expected at this stage — we'll start using them in Part 2 when we add the private half of the contract. +::: + ## Building the Mental Health Token System ### The Privacy Architecture @@ -270,7 +280,9 @@ async function main() { // Connect to local network const node = createAztecNodeClient("http://localhost:8080"); - const wallet = await EmbeddedWallet.create(node); + // `ephemeral: true` keeps PXE state in memory, so restarting the local + // network won't leave this script pointing at stale block hashes. + const wallet = await EmbeddedWallet.create(node, { ephemeral: true }); const [giggleWalletData, aliceWalletData, bobClinicWalletData] = await getInitialTestAccountsData(); @@ -319,6 +331,14 @@ What's this `tsx` dark magic? Well, it just compiles and runs typescript using r ::: +:::tip Ephemeral PXE state + +We pass `{ ephemeral: true }` to `EmbeddedWallet.create`. This tells the PXE to keep its state in memory instead of writing it to `pxe_data_*` / `wallet_data_*` folders on disk. If you ever stop and restart your local network (or wipe its state), the next run starts clean instead of failing with errors like `No local block hash for block number …` because on-disk PXE state no longer matches the chain. + +For real applications you typically want persistent state, but for tutorials that spin up a fresh network each run, ephemeral is the safer default. + +::: + ### 🎉 Celebrate Congratulations! You've just deployed a working token contract on Aztec! You can: @@ -353,11 +373,19 @@ When Alice spends 40 BOB tokens at Bob's clinic: 3. She creates a "change" note for herself (40 BOB) 4. The consumed notes are nullified (marked as spent) +:::info What is a nullifier? +A **nullifier** is a unique, one-way tag emitted when a private note is spent. The network adds it to a nullifier tree so the same note can't be spent twice, but because the nullifier is derived from secrets only the note's owner knows, nobody can link a nullifier back to the note it invalidated. See [State Management](../../foundational-topics/state_management.md#private-state) for more. +::: + In this case, all that the network sees (including Giggle) is just "something happening to some state in some contract". How cool is that? ### Updating Storage for Privacy +<<<<<<< HEAD:docs/developer_versioned_docs/version-v4.1.0-rc.2/docs/tutorials/contract_tutorials/token_contract.md For something like balances, you can use a simple library called `easy_private_state` which abstracts away a custom private Note. A Note is at the core of how private state works in Aztec and you can read about it [here](../../foundational-topics/state_management.md). For now, let's just import the library in `Nargo.toml`: +======= +For something like balances, you can use a simple library called `balance_set` which abstracts away a custom private Note. A Note is at the core of how private state works in Aztec and you can read about it [here](../../foundational-topics/state_management.md). For now, let's add it by replacing the `[dependencies]` section in `Nargo.toml`: +>>>>>>> 31fedbddff (docs: fix v4.2.0 developer tutorial/guide bugs (#22618)):docs/developer_versioned_docs/version-v4.2.0/docs/tutorials/contract_tutorials/token_contract.md ```toml [dependencies] @@ -580,6 +608,14 @@ aztec codegen target --outdir artifacts ## Testing the Complete Privacy System +Before running the updated script, double-check your local network is still running: + +```bash +aztec start --local-network +``` + +If you stopped it between parts of the tutorial, start it again here. Because we set `ephemeral: true` when creating the wallet, restarting the network is safe — the script won't try to reuse stale PXE state from a previous run. + Now that you've implemented all the privacy features, let's update our test script to showcase the full privacy flow: ### Update Your Test Script @@ -680,7 +716,14 @@ Let's give it a try: npx tsx index.ts ``` -You should see the complete privacy journey from transparent allocation to confidential usage! +You should see the complete privacy journey from transparent allocation to confidential usage. The final pair of log lines should look like: + +```text +📊 Alice has 100 public BOB tokens and 130 private BOB tokens +📊 Bob's Clinic has 20 public BOB tokens and 50 private BOB tokens +``` + +If your output doesn't match, double-check that the local network is running and that you started this run with a fresh `aztec start --local-network`. ## Summary diff --git a/docs/developer_versioned_docs/version-v4.1.0-rc.2/docs/tutorials/testing_governance_rollup_upgrade.md b/docs/developer_versioned_docs/version-v4.1.0-rc.2/docs/tutorials/testing_governance_rollup_upgrade.md index 83271a6c6ab0..182958f1e823 100644 --- a/docs/developer_versioned_docs/version-v4.1.0-rc.2/docs/tutorials/testing_governance_rollup_upgrade.md +++ b/docs/developer_versioned_docs/version-v4.1.0-rc.2/docs/tutorials/testing_governance_rollup_upgrade.md @@ -359,10 +359,13 @@ aztec get-l1-addresses \ ```bash aztec debug-rollup \ + --rollup $NEW_ROLLUP_ADDRESS \ --l1-rpc-urls $L1_RPC_URL \ -c $L1_CHAIN_ID ``` +The `--rollup` flag is required; without it the command may fail trying to resolve the default rollup address. + --- ## Quick Test (Empty Payload) diff --git a/docs/developer_versioned_docs/version-v4.2.0-aztecnr-rc.2/docs/aztec-js/how_to_pay_fees.md b/docs/developer_versioned_docs/version-v4.2.0-aztecnr-rc.2/docs/aztec-js/how_to_pay_fees.md index 1dcaacd8c744..c73ebbf68d27 100644 --- a/docs/developer_versioned_docs/version-v4.2.0-aztecnr-rc.2/docs/aztec-js/how_to_pay_fees.md +++ b/docs/developer_versioned_docs/version-v4.2.0-aztecnr-rc.2/docs/aztec-js/how_to_pay_fees.md @@ -167,9 +167,53 @@ Third-party FPCs can pay for your fees using custom logic, such as accepting dif ```typescript import { GasSettings } from "@aztec/stdlib/gas"; +<<<<<<< HEAD:docs/developer_versioned_docs/version-v4.2.0-aztecnr-rc.2/docs/aztec-js/how_to_pay_fees.md // node is from createAztecNodeClient() in the connection guide (see prerequisites) const maxFeesPerGas = (await node.getCurrentMinFees()).mul(1.5); //adjust this to your needs const gasSettings = GasSettings.default({ maxFeesPerGas }); +======= +On networks where the Sponsored FPC is unavailable, third-party FPCs deployed by ecosystem teams let you pay fees in tokens other than Fee Juice. Each FPC provider typically offers an SDK or API that handles payment method construction on the client side — this may include quote fetching and authwit creation, though the exact flow depends on the FPC design. For background on how FPCs work at the protocol level, see [How FPCs work](../foundational-topics/fees.md#how-fpcs-work). + +#### Example: Nethermind Private Multi Asset FPC + +To illustrate how a third-party FPC integration works, the following walkthrough uses Nethermind's [Private Multi Asset FPC](https://github.com/NethermindEth/aztec-fpc) as a reference. This is one implementation — other FPCs may differ in design and API. + +This FPC is quote-based and operates privately: + +- A single deployment accepts many tokens — the asset is selected per quote rather than hard-coded at deploy time. +- Fee payments are transferred as private notes, so fee activity is not visible onchain. +- An operator-run attestation service signs per-user quotes binding the FPC address, accepted asset, amounts, expiry, and user. +- A cold-start entrypoint allows a brand-new account to bridge tokens from L1, claim on L2, and pay the fee in a single transaction. Note that the cold-start path calls `Token::mint_to_private`, which enqueues a public call to update the token's total supply — so the minted amount is visible onchain even though the user's identity and balances remain private. + +:::warning Third-party software +This FPC is developed and maintained by Nethermind, not by Aztec Labs. The SDK (`@nethermindeth/aztec-fpc-sdk`) may not yet be published to npm — check the [repository README](https://github.com/NethermindEth/aztec-fpc/blob/main/sdk/README.md) for current install instructions. Review the [protocol spec](https://github.com/NethermindEth/aztec-fpc/blob/main/docs/spec/protocol-spec.md) and evaluate independently before integrating. +::: + +The SDK wraps the quote-and-pay flow into a single call. The snippet below shows the general shape of the integration (illustrative — verify against the current SDK API before using): + +```ts +import { FpcClient } from "@nethermindeth/aztec-fpc-sdk"; + +// Point the client at the FPC's attestation service +const fpcClient = new FpcClient({ + fpcAddress, // the deployed FPC contract address + operator, // operator's Aztec address + node, // PXE or node connection + attestationBaseUrl: "https://...", // attestation service URL from the FPC provider +}); + +// Estimate gas, fetch a signed quote, and build the payment method +const payment = await fpcClient.createPaymentMethod({ + wallet, + user: aliceAddress, // the account paying the fee + tokenAddress, // the token you want to pay in + estimatedGas, // from a prior estimateGas call +}); + +// Use it like any other payment method +const tx = await myContract.methods.myMethod(args).send({ fee: payment.fee }); +await tx.wait(); +>>>>>>> 31fedbddff (docs: fix v4.2.0 developer tutorial/guide bugs (#22618)):docs/developer_versioned_docs/version-v4.2.0/docs/aztec-js/how_to_pay_fees.md ``` Private FPCs enable fee payments without revealing the payer's identity onchain: diff --git a/docs/developer_versioned_docs/version-v4.2.0-aztecnr-rc.2/docs/aztec-nr/framework-description/advanced/how_to_prove_history.md b/docs/developer_versioned_docs/version-v4.2.0-aztecnr-rc.2/docs/aztec-nr/framework-description/advanced/how_to_prove_history.md index 5e1d62646524..0e1bec918529 100644 --- a/docs/developer_versioned_docs/version-v4.2.0-aztecnr-rc.2/docs/aztec-nr/framework-description/advanced/how_to_prove_history.md +++ b/docs/developer_versioned_docs/version-v4.2.0-aztecnr-rc.2/docs/aztec-nr/framework-description/advanced/how_to_prove_history.md @@ -51,7 +51,7 @@ let confirmed_note = assert_note_existed_by(header, hinted_note); To prove a note was valid (existed AND wasn't nullified) at a historical block: ```rust -use dep::aztec::history::note::assert_note_was_valid_by; +use aztec::history::note::assert_note_was_valid_by; let header = self.context.get_anchor_block_header(); assert_note_was_valid_by(header, hinted_note, &mut self.context); @@ -66,7 +66,7 @@ This verifies both: To prove against state at a specific past block (not just the anchor block): ```rust -use dep::aztec::history::note::assert_note_existed_by; +use aztec::history::note::assert_note_existed_by; let historical_header = self.context.get_block_header_at(block_number); assert_note_existed_by(historical_header, hinted_note); @@ -81,7 +81,7 @@ Using `get_block_header_at` adds ~3k constraints to prove Archive tree membershi To prove a note has been spent/nullified: ```rust -use dep::aztec::history::note::assert_note_was_nullified_by; +use aztec::history::note::assert_note_was_nullified_by; let header = self.context.get_anchor_block_header(); assert_note_was_nullified_by(header, confirmed_note, &mut self.context); @@ -92,7 +92,7 @@ assert_note_was_nullified_by(header, confirmed_note, &mut self.context); To prove a contract's bytecode was published at a historical block: ```rust -use dep::aztec::history::deployment::assert_contract_bytecode_was_published_by; +use aztec::history::deployment::assert_contract_bytecode_was_published_by; let header = self.context.get_anchor_block_header(); assert_contract_bytecode_was_published_by(header, contract_address); @@ -101,8 +101,8 @@ assert_contract_bytecode_was_published_by(header, contract_address); You can also prove a contract was initialized (constructor was called): ```rust -use dep::aztec::history::deployment::assert_contract_was_initialized_by; -use dep::aztec::oracle::get_contract_instance::get_contract_instance; +use aztec::history::deployment::assert_contract_was_initialized_by; +use aztec::oracle::get_contract_instance::get_contract_instance; let header = self.context.get_anchor_block_header(); let instance = get_contract_instance(contract_address); diff --git a/docs/developer_versioned_docs/version-v4.2.0-aztecnr-rc.2/docs/aztec-nr/framework-description/advanced/how_to_retrieve_filter_notes.md b/docs/developer_versioned_docs/version-v4.2.0-aztecnr-rc.2/docs/aztec-nr/framework-description/advanced/how_to_retrieve_filter_notes.md index 3e4a685ec22c..0de497f3bb45 100644 --- a/docs/developer_versioned_docs/version-v4.2.0-aztecnr-rc.2/docs/aztec-nr/framework-description/advanced/how_to_retrieve_filter_notes.md +++ b/docs/developer_versioned_docs/version-v4.2.0-aztecnr-rc.2/docs/aztec-nr/framework-description/advanced/how_to_retrieve_filter_notes.md @@ -16,8 +16,8 @@ This guide shows you how to retrieve and filter notes from private storage using ## Required imports ```rust -use dep::aztec::note::note_getter_options::{NoteGetterOptions, NoteStatus, SortOrder}; -use dep::aztec::utils::comparison::Comparator; +use aztec::note::note_getter_options::{NoteGetterOptions, NoteStatus, SortOrder}; +use aztec::utils::comparison::Comparator; ``` ## Set up basic note retrieval diff --git a/docs/developer_versioned_docs/version-v4.2.0-aztecnr-rc.2/docs/aztec-nr/framework-description/advanced/writing_efficient_contracts.md b/docs/developer_versioned_docs/version-v4.2.0-aztecnr-rc.2/docs/aztec-nr/framework-description/advanced/writing_efficient_contracts.md index 71977ac0aeb9..833baf624d67 100644 --- a/docs/developer_versioned_docs/version-v4.2.0-aztecnr-rc.2/docs/aztec-nr/framework-description/advanced/writing_efficient_contracts.md +++ b/docs/developer_versioned_docs/version-v4.2.0-aztecnr-rc.2/docs/aztec-nr/framework-description/advanced/writing_efficient_contracts.md @@ -179,11 +179,11 @@ See [this example](https://github.com/noir-lang/noir-examples/blob/master/noir_b Consider the following example of an implementation of the `sqrt` function: ```rust -use dep::aztec::macros::aztec; +use aztec::macros::aztec; #[aztec] pub contract OptimisationExample { - use dep::aztec::macros::{functions::{external, initializer}, storage::storage}; + use aztec::macros::{functions::{external, initializer}, storage::storage}; #[storage] struct Storage {} diff --git a/docs/docs-developers/docs/aztec-js/how_to_pay_fees.md b/docs/docs-developers/docs/aztec-js/how_to_pay_fees.md index 28434f87ddae..f5a7b44f9ce3 100644 --- a/docs/docs-developers/docs/aztec-js/how_to_pay_fees.md +++ b/docs/docs-developers/docs/aztec-js/how_to_pay_fees.md @@ -154,7 +154,7 @@ const fpcClient = new FpcClient({ // Estimate gas, fetch a signed quote, and build the payment method const payment = await fpcClient.createPaymentMethod({ wallet, - user: wallet.getAddress(), + user: aliceAddress, // the account paying the fee tokenAddress, // the token you want to pay in estimatedGas, // from a prior estimateGas call }); diff --git a/docs/docs-developers/docs/aztec-js/how_to_test.md b/docs/docs-developers/docs/aztec-js/how_to_test.md index ae916c535cb1..d22443b724e2 100644 --- a/docs/docs-developers/docs/aztec-js/how_to_test.md +++ b/docs/docs-developers/docs/aztec-js/how_to_test.md @@ -37,7 +37,7 @@ Deploy contracts using the generated contract class: Use `.simulate()` to read contract state without creating a transaction: -#include_code simulate_function docs/examples/ts/aztecjs_connection/index.ts typescript +#include_code simulate_function /docs/examples/ts/aztecjs_connection/index.ts typescript Simulations are free (no gas cost) and return the function's result directly. Use them for: diff --git a/docs/docs-developers/docs/aztec-js/how_to_use_authwit.md b/docs/docs-developers/docs/aztec-js/how_to_use_authwit.md index 1b38f508a8fe..7390e1a451cf 100644 --- a/docs/docs-developers/docs/aztec-js/how_to_use_authwit.md +++ b/docs/docs-developers/docs/aztec-js/how_to_use_authwit.md @@ -35,7 +35,8 @@ import { General } from '@site/src/components/Snippets/general_snippets'; The authwit system supports different intent types depending on your use case: -- **`CallIntent`**: Use when authorizing a specific contract function call. Contains `{ caller, action }` where `action` is a `ContractFunctionInteraction`. +- **`CallIntent`**: Use when authorizing a specific contract function call. Contains `{ caller, call }` where `call` is a `FunctionCall`, typically obtained with `await interaction.getFunctionCall()`. +- **`ContractFunctionInteractionCallIntent`**: Convenience form that takes the interaction directly. Contains `{ caller, action }` where `action` is a `ContractFunctionInteraction`; internally resolved to a `FunctionCall` before signing. - **`IntentInnerHash`**: Use when authorizing arbitrary data. Contains `{ consumer, innerHash }` where `consumer` is the contract that will verify the authwit. ## Create private authwits diff --git a/docs/docs-developers/docs/aztec-nr/debugging.md b/docs/docs-developers/docs/aztec-nr/debugging.md index ca48d4cc7ab7..d2cf39a47e56 100644 --- a/docs/docs-developers/docs/aztec-nr/debugging.md +++ b/docs/docs-developers/docs/aztec-nr/debugging.md @@ -116,9 +116,12 @@ LOG_LEVEL="silent;debug:simulator" ### Quick Fixes for Common Issues ```bash -# Archiver sync issues - force progress with dummy transactions -aztec-wallet send transfer --from test0 --to test0 --amount 0 -aztec-wallet send transfer --from test0 --to test0 --amount 0 +# Archiver sync issues - force progress with dummy transactions. +# Assumes you have imported the local network test accounts +# (aztec-wallet import-test-accounts) and have a deployed token +# aliased as `testtoken`. +aztec-wallet send transfer --from test0 --contract-address testtoken --args accounts:test0 0 +aztec-wallet send transfer --from test0 --contract-address testtoken --args accounts:test0 0 # L1 to L2 message pending - wait for inclusion # Messages need 2 blocks to be processed diff --git a/docs/docs-developers/docs/aztec-nr/framework-description/advanced/how_to_prove_history.md b/docs/docs-developers/docs/aztec-nr/framework-description/advanced/how_to_prove_history.md index b3c3cc6105c4..dfd246633454 100644 --- a/docs/docs-developers/docs/aztec-nr/framework-description/advanced/how_to_prove_history.md +++ b/docs/docs-developers/docs/aztec-nr/framework-description/advanced/how_to_prove_history.md @@ -42,7 +42,7 @@ Prove a note exists in the note hash tree: To prove a note was valid (existed AND wasn't nullified) at a historical block: ```rust -use dep::aztec::history::note::assert_note_was_valid_by; +use aztec::history::note::assert_note_was_valid_by; let header = self.context.get_anchor_block_header(); assert_note_was_valid_by(header, hinted_note, &mut self.context); @@ -57,7 +57,7 @@ This verifies both: To prove against state at a specific past block (not just the anchor block): ```rust -use dep::aztec::history::note::assert_note_existed_by; +use aztec::history::note::assert_note_existed_by; let historical_header = self.context.get_block_header_at(block_number); assert_note_existed_by(historical_header, hinted_note); @@ -72,7 +72,7 @@ Using `get_block_header_at` adds ~3k constraints to prove Archive tree membershi To prove a note has been spent/nullified: ```rust -use dep::aztec::history::note::assert_note_was_nullified_by; +use aztec::history::note::assert_note_was_nullified_by; let header = self.context.get_anchor_block_header(); assert_note_was_nullified_by(header, confirmed_note, &mut self.context); @@ -83,7 +83,7 @@ assert_note_was_nullified_by(header, confirmed_note, &mut self.context); To prove a contract's bytecode was published at a historical block: ```rust -use dep::aztec::history::deployment::assert_contract_bytecode_was_published_by; +use aztec::history::deployment::assert_contract_bytecode_was_published_by; let header = self.context.get_anchor_block_header(); assert_contract_bytecode_was_published_by(header, contract_address); @@ -92,8 +92,8 @@ assert_contract_bytecode_was_published_by(header, contract_address); You can also prove a contract was initialized (constructor was called): ```rust -use dep::aztec::history::deployment::assert_contract_was_initialized_by; -use dep::aztec::oracle::get_contract_instance::get_contract_instance; +use aztec::history::deployment::assert_contract_was_initialized_by; +use aztec::oracle::get_contract_instance::get_contract_instance; let header = self.context.get_anchor_block_header(); let instance = get_contract_instance(contract_address); diff --git a/docs/docs-developers/docs/aztec-nr/framework-description/advanced/how_to_retrieve_filter_notes.md b/docs/docs-developers/docs/aztec-nr/framework-description/advanced/how_to_retrieve_filter_notes.md index ede622c187d7..b0fb8969443d 100644 --- a/docs/docs-developers/docs/aztec-nr/framework-description/advanced/how_to_retrieve_filter_notes.md +++ b/docs/docs-developers/docs/aztec-nr/framework-description/advanced/how_to_retrieve_filter_notes.md @@ -16,8 +16,8 @@ This guide shows you how to retrieve and filter notes from private storage using ## Required imports ```rust -use dep::aztec::note::note_getter_options::{NoteGetterOptions, NoteStatus, SortOrder}; -use dep::aztec::utils::comparison::Comparator; +use aztec::note::note_getter_options::{NoteGetterOptions, NoteStatus, SortOrder}; +use aztec::utils::comparison::Comparator; ``` ## Set up basic note retrieval diff --git a/docs/docs-developers/docs/aztec-nr/framework-description/advanced/writing_efficient_contracts.md b/docs/docs-developers/docs/aztec-nr/framework-description/advanced/writing_efficient_contracts.md index 71977ac0aeb9..833baf624d67 100644 --- a/docs/docs-developers/docs/aztec-nr/framework-description/advanced/writing_efficient_contracts.md +++ b/docs/docs-developers/docs/aztec-nr/framework-description/advanced/writing_efficient_contracts.md @@ -179,11 +179,11 @@ See [this example](https://github.com/noir-lang/noir-examples/blob/master/noir_b Consider the following example of an implementation of the `sqrt` function: ```rust -use dep::aztec::macros::aztec; +use aztec::macros::aztec; #[aztec] pub contract OptimisationExample { - use dep::aztec::macros::{functions::{external, initializer}, storage::storage}; + use aztec::macros::{functions::{external, initializer}, storage::storage}; #[storage] struct Storage {} diff --git a/docs/docs-developers/docs/aztec-nr/framework-description/contract_structure.md b/docs/docs-developers/docs/aztec-nr/framework-description/contract_structure.md index 1151f67f1dbb..e9fb3e3a5062 100644 --- a/docs/docs-developers/docs/aztec-nr/framework-description/contract_structure.md +++ b/docs/docs-developers/docs/aztec-nr/framework-description/contract_structure.md @@ -10,28 +10,18 @@ High-level structure of how Aztec smart contracts including the different compon ## Directory structure -When you create a new project with `aztec new my_project`, it generates a workspace with two crates named after your project: a `my_project_contract` crate for your smart contract and a `my_project_test` crate for Noir tests. +When you create a new project with `aztec new my_project`, it generates a single-crate Noir contract project: ```text title="layout of an aztec contract project" ─── my_project - ├── Nargo.toml <-- workspace root - ├── my_project_contract - │ ├── src - │ │ └── main.nr <-- your contract - │ └── Nargo.toml <-- contract package and dependencies - └── my_project_test - ├── src - │ └── lib.nr <-- your tests - └── Nargo.toml <-- test package and dependencies + ├── Nargo.toml <-- contract package and dependencies + └── src + └── main.nr <-- your contract ``` -The workspace root `Nargo.toml` declares both crates as workspace members. The contract code lives in `my_project_contract/src/main.nr`, and tests live in a separate `my_project_test` crate that depends on the contract crate. +`Nargo.toml` declares the contract package (with `type = "contract"`) and its dependencies. Your contract code lives in `src/main.nr`. Noir tests using `#[test]` live alongside the contract in the same crate — see [Testing Contracts](../testing_contracts.md). -You can add more contracts to an existing workspace by running `aztec new ` from inside the workspace directory. This creates a new `_contract` and `_test` crate pair and adds them to the workspace. - -:::warning Keep tests out of the contract crate -Do not add `#[test]` functions to the `_contract` crate. Because the contract artifact depends on everything in its crate, any change — including a test-only change — forces a full recompilation of the contract. The separate `_test` crate lets you iterate on tests without rebuilding the contract. See [Testing Contracts](../testing_contracts.md#keep-tests-in-the-test-crate) for details. -::: +To add another contract as a sibling of an existing one, run `aztec new ` from the parent directory (each contract is its own crate). To initialize a contract project inside an existing empty directory instead, `cd` into it and run `aztec init` (it takes no positional argument; pass `--name ` if you want the package name to differ from the directory name). See the vanilla Noir docs for [more info on packages](https://noir-lang.org/docs/noir/modules_packages_crates/crates_and_packages). diff --git a/docs/docs-developers/docs/aztec-nr/index.md b/docs/docs-developers/docs/aztec-nr/index.md index 646d94a67ba1..3e42007a7d72 100644 --- a/docs/docs-developers/docs/aztec-nr/index.md +++ b/docs/docs-developers/docs/aztec-nr/index.md @@ -42,15 +42,15 @@ storage.votes.insert(new_vote).deliver(MessageDelivery.ONCHAIN_CONSTRAINED); // ### Flow -1. Write your contract and specify your contract dependencies. Create a new project with `aztec new my_project`, which sets up a workspace with a `my_project_contract` crate and a `my_project_test` crate, with the `aztec` dependency already configured. If you need additional dependencies, add them to `my_project_contract/Nargo.toml`: +1. Write your contract and specify your contract dependencies. Create a new project with `aztec new my_project`, which creates a single-crate Noir contract project (`Nargo.toml` + `src/main.nr`) with the `aztec` dependency already configured. If you need additional dependencies, add them to `my_project/Nargo.toml`: ```toml -# my_project_contract/Nargo.toml +# my_project/Nargo.toml [dependencies] aztec = { git="https://github.com/AztecProtocol/aztec-nr/", tag="#include_aztec_version", directory="aztec" } ``` -Update your `my_project_contract/src/main.nr` contract file to use the Aztec.nr macros for writing contracts. +Update your `my_project/src/main.nr` contract file to use the Aztec.nr macros for writing contracts. #include_code setup /docs/examples/contracts/counter_contract/src/main.nr rust diff --git a/docs/docs-developers/docs/aztec-nr/testing_contracts.md b/docs/docs-developers/docs/aztec-nr/testing_contracts.md index cfde168a0415..7ff5a70db8c4 100644 --- a/docs/docs-developers/docs/aztec-nr/testing_contracts.md +++ b/docs/docs-developers/docs/aztec-nr/testing_contracts.md @@ -44,38 +44,30 @@ aztec test Always use `aztec test` instead of `nargo test`. The `TestEnvironment` requires the TXE (Test eXecution Environment) oracle resolver. ::: -## Keep tests in the test crate - -When you create a project with `aztec new` or `aztec init`, the generated workspace has two crates: `_contract` and `_test`. It is important that all tests live in the `_test` crate, **not** in the `_contract` crate. - -If you place `#[test]` functions inside the contract crate, `aztec compile` will emit a warning: - -``` -WARNING: Found tests in contract crate(s): - my_contract::test_something -Tests should be in a dedicated test crate, not in the contract crate. -``` - -The reason is **unnecessary recompilation**: the contract artifact depends on everything inside the contract crate. If tests live there too, editing a test changes the crate and forces the contract to be recompiled and reprocessed, even though the contract logic itself has not changed. By keeping tests in a separate crate, you can iterate on tests without triggering a full contract rebuild. - ## Basic test structure -Tests live in `_test/src/lib.nr` and import the contract crate by name (not `crate::`): +Tests live in the same crate as your contract. `aztec new` creates a single-crate project, and the convention is to place `#[test]` functions in a `mod tests` block alongside the contract (or in submodules of the crate): ```rust -use my_contract::MyContract; -use aztec::{ - protocol::address::AztecAddress, - test::helpers::test_environment::TestEnvironment, -}; +use aztec::macros::aztec; -#[test] -unconstrained fn test_basic_flow() { - // 1. Create test environment - let mut env = TestEnvironment::new(); +#[aztec] +pub contract MyContract { + // ...contract functions... +} - // 2. Create accounts - let owner = env.create_light_account(); +mod tests { + use super::MyContract; + use aztec::test::helpers::test_environment::TestEnvironment; + + #[test] + unconstrained fn test_basic_flow() { + // 1. Create test environment + let mut env = TestEnvironment::new(); + + // 2. Create accounts + let _owner = env.create_light_account(); + } } ``` @@ -88,12 +80,14 @@ unconstrained fn test_basic_flow() { ::: :::tip Organizing test files -Tests live in the separate `_test` crate that `aztec new` creates. You can organize them into modules: +For larger test suites, split tests into submodules of your crate rather than keeping them all inside `main.nr`: -- Split tests into modules like `_test/src/transfer_tests.nr`, `_test/src/auth_tests.nr` -- Import them in `_test/src/lib.nr` with `mod transfer_tests;`, `mod auth_tests;` -- Share setup functions in `_test/src/utils.nr` - ::: +- Create modules like `src/transfer_tests.nr`, `src/auth_tests.nr` +- Declare them from `src/main.nr` with `mod transfer_tests;`, `mod auth_tests;` +- Share setup functions in `src/test_utils.nr` + +See the [aztec-standards token contract](https://github.com/defi-wonderland/aztec-standards/tree/dev/src/token_contract) for a worked example of this layout. +::: ## Deploying contracts diff --git a/docs/docs-developers/docs/tutorials/contract_tutorials/recursive_verification.md b/docs/docs-developers/docs/tutorials/contract_tutorials/recursive_verification.md index f340dcc28eb9..b93c3a2e7aaf 100644 --- a/docs/docs-developers/docs/tutorials/contract_tutorials/recursive_verification.md +++ b/docs/docs-developers/docs/tutorials/contract_tutorials/recursive_verification.md @@ -182,9 +182,9 @@ nargo test Expected output: ```text -[hello_circuit] Running 1 test functions -[hello_circuit] Testing test_main... ok -[hello_circuit] All tests passed +[hello_circuit] Running 1 test function +[hello_circuit] Testing test_main ... ok +[hello_circuit] 1 test passed ``` **Tip**: Circuit tests run without generating proofs, making them fast for development. Use them to verify your circuit logic before the more expensive proof generation step. @@ -208,10 +208,16 @@ The contract demonstrates several important patterns: Use `aztec new` to generate the contract project structure: ```bash -aztec new contract --name ValueNotEqual +aztec new --name ValueNotEqual contract ``` +<<<<<<< HEAD This creates a workspace with two crates: +======= +The `aztec new` wrapper stops parsing arguments at the first positional, so `--name` must come **before** the `contract` path — otherwise the flag is silently dropped and the Nargo package ends up named `contract`. The Nargo package name (`--name`) is independent of the Noir contract name declared inside `main.nr`; the artifact filename downstream is driven by the contract name. + +This creates: +>>>>>>> 31fedbddff (docs: fix v4.2.0 developer tutorial/guide bugs (#22618)) ```tree contract/ @@ -550,7 +556,7 @@ Expected output: Proof verification: SUCCESS Using deflattenFields to convert proof... VK size: 115 -Proof size: 508 +Proof size: 500 Public inputs: 1 Done ``` diff --git a/docs/docs-developers/docs/tutorials/contract_tutorials/token_contract.md b/docs/docs-developers/docs/tutorials/contract_tutorials/token_contract.md index a408634df7cc..eaf0df9c671c 100644 --- a/docs/docs-developers/docs/tutorials/contract_tutorials/token_contract.md +++ b/docs/docs-developers/docs/tutorials/contract_tutorials/token_contract.md @@ -41,7 +41,7 @@ Let's create a simple yarn + aztec.nr project: ```bash aztec new bob_token cd bob_token -yarn init +yarn init -y # This is to ensure yarn uses node_modules instead of pnp for dependency installation yarn config set nodeLinker node-modules yarn add @aztec/aztec.js@#include_aztec_version @aztec/accounts@#include_aztec_version @aztec/kv-store@#include_aztec_version @aztec/wallets@#include_aztec_version @@ -79,6 +79,10 @@ Since we're here, let's import more specific stuff from this library: These are the different macros we need to define the visibility of functions, and some handy types and functions. +:::note +You may see "unused import" warnings from your IDE or compiler for `only_self`, `MessageDelivery`, and `Owned`. That's expected at this stage — we'll start using them in Part 2 when we add the private half of the contract. +::: + ## Building the Mental Health Token System ### The Privacy Architecture @@ -215,6 +219,14 @@ What's this `tsx` dark magic? `tsx` is a tool that compiles and runs TypeScript ::: +:::tip Ephemeral PXE state + +We pass `{ ephemeral: true }` to `EmbeddedWallet.create`. This tells the PXE to keep its state in memory instead of writing it to `pxe_data_*` / `wallet_data_*` folders on disk. If you ever stop and restart your local network (or wipe its state), the next run starts clean instead of failing with errors like `No local block hash for block number …` because on-disk PXE state no longer matches the chain. + +For real applications you typically want persistent state, but for tutorials that spin up a fresh network each run, ephemeral is the safer default. + +::: + ### 🎉 Celebrate Congratulations! You've just deployed a working token contract on Aztec! You can: @@ -249,11 +261,19 @@ When Alice spends 40 BOB tokens at Bob's clinic: 3. She creates a "change" note for herself (40 BOB) 4. The consumed notes are nullified (marked as spent) +:::info What is a nullifier? +A **nullifier** is a unique, one-way tag emitted when a private note is spent. The network adds it to a nullifier tree so the same note can't be spent twice, but because the nullifier is derived from secrets only the note's owner knows, nobody can link a nullifier back to the note it invalidated. See [State Management](../../foundational-topics/state_management.md#private-state) for more. +::: + In this case, all that the network sees (including Giggle) is just "something happening to some state in some contract". How cool is that? ### Updating Storage for Privacy +<<<<<<< HEAD For something like balances, you can use a simple library called `easy_private_state` which abstracts away a custom private Note. A Note is at the core of how private state works in Aztec and you can read about it [here](../../foundational-topics/state_management.md). For now, let's just import the library in `bob_token_contract/Nargo.toml`: +======= +For something like balances, you can use a simple library called `balance_set` which abstracts away a custom private Note. A Note is at the core of how private state works in Aztec and you can read about it [here](../../foundational-topics/state_management.md). For now, let's add it by replacing the `[dependencies]` section in `Nargo.toml`: +>>>>>>> 31fedbddff (docs: fix v4.2.0 developer tutorial/guide bugs (#22618)) ```toml [dependencies] @@ -373,6 +393,14 @@ aztec codegen target --outdir artifacts ## Testing the Complete Privacy System +Before running the updated script, double-check your local network is still running: + +```bash +aztec start --local-network +``` + +If you stopped it between parts of the tutorial, start it again here. Because we set `ephemeral: true` when creating the wallet, restarting the network is safe — the script won't try to reuse stale PXE state from a previous run. + Now that you've implemented all the privacy features, let's update our test script to showcase the full privacy flow: ### Update Your Test Script @@ -409,7 +437,14 @@ Let's give it a try: npx tsx index.ts ``` -You should see the complete privacy journey from transparent allocation to confidential usage! +You should see the complete privacy journey from transparent allocation to confidential usage. The final pair of log lines should look like: + +```text +📊 Alice has 100 public BOB tokens and 130 private BOB tokens +📊 Bob's Clinic has 20 public BOB tokens and 50 private BOB tokens +``` + +If your output doesn't match, double-check that the local network is running and that you started this run with a fresh `aztec start --local-network`. ## Summary diff --git a/docs/docs-developers/docs/tutorials/testing_governance_rollup_upgrade.md b/docs/docs-developers/docs/tutorials/testing_governance_rollup_upgrade.md index 28a9a41c6673..a19a4bf0e1f9 100644 --- a/docs/docs-developers/docs/tutorials/testing_governance_rollup_upgrade.md +++ b/docs/docs-developers/docs/tutorials/testing_governance_rollup_upgrade.md @@ -359,10 +359,13 @@ aztec get-l1-addresses \ ```bash aztec debug-rollup \ + --rollup $NEW_ROLLUP_ADDRESS \ --l1-rpc-urls $L1_RPC_URL \ -c $L1_CHAIN_ID ``` +The `--rollup` flag is required; without it the command may fail trying to resolve the default rollup address. + --- ## Quick Test (Empty Payload) diff --git a/docs/examples/contracts/counter_contract/src/main.nr b/docs/examples/contracts/counter_contract/src/main.nr index d4502f12ab60..da23da3d221f 100644 --- a/docs/examples/contracts/counter_contract/src/main.nr +++ b/docs/examples/contracts/counter_contract/src/main.nr @@ -26,8 +26,8 @@ pub contract Counter { #[initializer] #[external("private")] // We can name our initializer anything we want as long as it's marked as aztec(initializer) - fn initialize(headstart: u64, owner: AztecAddress) { - self.storage.counters.at(owner).add(headstart as u128).deliver( + fn initialize(headstart: u128, owner: AztecAddress) { + self.storage.counters.at(owner).add(headstart).deliver( MessageDelivery.ONCHAIN_CONSTRAINED, ); } diff --git a/docs/examples/ts/bob_token_contract/index.ts b/docs/examples/ts/bob_token_contract/index.ts index 9b154e1279a3..6ce79a32c124 100644 --- a/docs/examples/ts/bob_token_contract/index.ts +++ b/docs/examples/ts/bob_token_contract/index.ts @@ -52,7 +52,9 @@ async function main() { // Connect to local network const node = createAztecNodeClient("http://localhost:8080"); - const wallet = await EmbeddedWallet.create(node); + // `ephemeral: true` keeps PXE state in memory, so restarting the local + // network won't leave this script pointing at stale block hashes. + const wallet = await EmbeddedWallet.create(node, { ephemeral: true }); const [giggleWalletData, aliceWalletData, bobClinicWalletData] = await getInitialTestAccountsData(); From d62d6769ed5474723c7977adb1526d8a8bdc279c Mon Sep 17 00:00:00 2001 From: AztecBot Date: Fri, 24 Apr 2026 13:06:46 +0000 Subject: [PATCH 2/3] fix: resolve cherry-pick conflicts --- .../docs/aztec-nr/debugging.md | 8 ---- .../contract_structure.md | 16 ------- .../docs/aztec-nr/index.md | 12 ----- .../docs/aztec-nr/testing_contracts.md | 19 -------- .../recursive_verification.md | 4 -- .../contract_tutorials/token_contract.md | 10 ----- .../docs/aztec-js/how_to_pay_fees.md | 44 ------------------- .../recursive_verification.md | 16 ++----- .../contract_tutorials/token_contract.md | 4 -- 9 files changed, 3 insertions(+), 130 deletions(-) diff --git a/docs/developer_versioned_docs/version-v4.1.0-rc.2/docs/aztec-nr/debugging.md b/docs/developer_versioned_docs/version-v4.1.0-rc.2/docs/aztec-nr/debugging.md index b9e0aaeb5c29..b3158e558356 100644 --- a/docs/developer_versioned_docs/version-v4.1.0-rc.2/docs/aztec-nr/debugging.md +++ b/docs/developer_versioned_docs/version-v4.1.0-rc.2/docs/aztec-nr/debugging.md @@ -33,11 +33,7 @@ Log values from your contract using `debug_log`: ```rust // Import debug logging -<<<<<<< HEAD:docs/developer_versioned_docs/version-v4.1.0-rc.2/docs/aztec-nr/debugging.md -use dep::aztec::oracle::debug_log::{ debug_log, debug_log_format }; -======= use aztec::oracle::logging::{ debug_log, debug_log_format }; ->>>>>>> 31fedbddff (docs: fix v4.2.0 developer tutorial/guide bugs (#22618)):docs/developer_versioned_docs/version-v4.2.0/docs/aztec-nr/debugging.md // Log simple messages debug_log("checkpoint reached"); @@ -211,11 +207,7 @@ LOG_LEVEL=verbose aztec start --local-network ### Common debug imports ```rust -<<<<<<< HEAD:docs/developer_versioned_docs/version-v4.1.0-rc.2/docs/aztec-nr/debugging.md -use dep::aztec::oracle::debug_log::{ debug_log, debug_log_format }; -======= use aztec::oracle::logging::{ debug_log, debug_log_format }; ->>>>>>> 31fedbddff (docs: fix v4.2.0 developer tutorial/guide bugs (#22618)):docs/developer_versioned_docs/version-v4.2.0/docs/aztec-nr/debugging.md ``` ### Check contract registration diff --git a/docs/developer_versioned_docs/version-v4.1.0-rc.2/docs/aztec-nr/framework-description/contract_structure.md b/docs/developer_versioned_docs/version-v4.1.0-rc.2/docs/aztec-nr/framework-description/contract_structure.md index b1ebd129e07f..3888f30143f0 100644 --- a/docs/developer_versioned_docs/version-v4.1.0-rc.2/docs/aztec-nr/framework-description/contract_structure.md +++ b/docs/developer_versioned_docs/version-v4.1.0-rc.2/docs/aztec-nr/framework-description/contract_structure.md @@ -10,17 +10,6 @@ High-level structure of how Aztec smart contracts including the different compon ## Directory structure -<<<<<<< HEAD:docs/developer_versioned_docs/version-v4.1.0-rc.2/docs/aztec-nr/framework-description/contract_structure.md -Here's a common layout for a basic Aztec.nr Contract project: - -```text title="layout of an aztec contract project" -─── my_aztec_contract_project - ├── src - │ └── main.nr <-- your contract - └── Nargo.toml <-- package and dependency management -``` - -======= When you create a new project with `aztec new my_project`, it generates a single-crate Noir contract project: ```text title="layout of an aztec contract project" @@ -34,7 +23,6 @@ When you create a new project with `aztec new my_project`, it generates a single To add another contract as a sibling of an existing one, run `aztec new ` from the parent directory (each contract is its own crate). To initialize a contract project inside an existing empty directory instead, `cd` into it and run `aztec init` (it takes no positional argument; pass `--name ` if you want the package name to differ from the directory name). ->>>>>>> 31fedbddff (docs: fix v4.2.0 developer tutorial/guide bugs (#22618)):docs/developer_versioned_docs/version-v4.2.0/docs/aztec-nr/framework-description/contract_structure.md See the vanilla Noir docs for [more info on packages](https://noir-lang.org/docs/noir/modules_packages_crates/crates_and_packages). ## Contract block @@ -60,11 +48,7 @@ The `#[aztec]` macro performs a lot of the low-level operations required to take ## Imports -<<<<<<< HEAD:docs/developer_versioned_docs/version-v4.1.0-rc.2/docs/aztec-nr/framework-description/contract_structure.md -Aside from the [`#[aztec]`](pathname:///aztec-nr-api/testnet/noir_aztec/macros/aztec/fn.aztec) macro import, all other imports need to go _inside_ the `contract` block - this is because `contract` acts like `mod`, creating a new [module](https://noir-lang.org/docs/noir/modules_packages_crates/modules). -======= Aside from the [`#[aztec]`](pathname:///aztec-nr-api/mainnet/noir_aztec/macros/fn.aztec) macro import, all other imports need to go _inside_ the `contract` block - this is because `contract` acts like `mod`, creating a new [module](https://noir-lang.org/docs/noir/modules_packages_crates/modules). ->>>>>>> 31fedbddff (docs: fix v4.2.0 developer tutorial/guide bugs (#22618)):docs/developer_versioned_docs/version-v4.2.0/docs/aztec-nr/framework-description/contract_structure.md ```rust use aztec::macros::aztec; diff --git a/docs/developer_versioned_docs/version-v4.1.0-rc.2/docs/aztec-nr/index.md b/docs/developer_versioned_docs/version-v4.1.0-rc.2/docs/aztec-nr/index.md index a3ec37bf7e84..45cea9242a7b 100644 --- a/docs/developer_versioned_docs/version-v4.1.0-rc.2/docs/aztec-nr/index.md +++ b/docs/developer_versioned_docs/version-v4.1.0-rc.2/docs/aztec-nr/index.md @@ -42,27 +42,15 @@ storage.votes.insert(new_vote).deliver(vote_counter); // the vote counter accoun ### Flow -<<<<<<< HEAD:docs/developer_versioned_docs/version-v4.1.0-rc.2/docs/aztec-nr/index.md -1. Write your contract and specify your contract dependencies. Every contract written for Aztec will have - aztec-nr as a dependency. Add it to your `Nargo.toml` with - -```toml -# Nargo.toml -======= 1. Write your contract and specify your contract dependencies. Create a new project with `aztec new my_project`, which creates a single-crate Noir contract project (`Nargo.toml` + `src/main.nr`) with the `aztec` dependency already configured. If you need additional dependencies, add them to `my_project/Nargo.toml`: ```toml # my_project/Nargo.toml ->>>>>>> 31fedbddff (docs: fix v4.2.0 developer tutorial/guide bugs (#22618)):docs/developer_versioned_docs/version-v4.2.0/docs/aztec-nr/index.md [dependencies] aztec = { git="https://github.com/AztecProtocol/aztec-nr/", tag="v4.1.0-rc.2", directory="aztec" } ``` -<<<<<<< HEAD:docs/developer_versioned_docs/version-v4.1.0-rc.2/docs/aztec-nr/index.md -Update your `main.nr` contract file to use the Aztec.nr macros for writing contracts. -======= Update your `my_project/src/main.nr` contract file to use the Aztec.nr macros for writing contracts. ->>>>>>> 31fedbddff (docs: fix v4.2.0 developer tutorial/guide bugs (#22618)):docs/developer_versioned_docs/version-v4.2.0/docs/aztec-nr/index.md ```rust title="setup" showLineNumbers use aztec::macros::aztec; diff --git a/docs/developer_versioned_docs/version-v4.1.0-rc.2/docs/aztec-nr/testing_contracts.md b/docs/developer_versioned_docs/version-v4.1.0-rc.2/docs/aztec-nr/testing_contracts.md index 29f9ad3a3963..edc3882175c4 100644 --- a/docs/developer_versioned_docs/version-v4.1.0-rc.2/docs/aztec-nr/testing_contracts.md +++ b/docs/developer_versioned_docs/version-v4.1.0-rc.2/docs/aztec-nr/testing_contracts.md @@ -46,19 +46,10 @@ Always use `aztec test` instead of `nargo test`. The `TestEnvironment` requires ## Basic test structure -<<<<<<< HEAD:docs/developer_versioned_docs/version-v4.1.0-rc.2/docs/aztec-nr/testing_contracts.md -```rust -use crate::MyContract; -use aztec::{ - protocol::address::AztecAddress, - test::helpers::test_environment::TestEnvironment, -}; -======= Tests live in the same crate as your contract. `aztec new` creates a single-crate project, and the convention is to place `#[test]` functions in a `mod tests` block alongside the contract (or in submodules of the crate): ```rust use aztec::macros::aztec; ->>>>>>> 31fedbddff (docs: fix v4.2.0 developer tutorial/guide bugs (#22618)):docs/developer_versioned_docs/version-v4.2.0/docs/aztec-nr/testing_contracts.md #[aztec] pub contract MyContract { @@ -89,15 +80,6 @@ mod tests { ::: :::tip Organizing test files -<<<<<<< HEAD:docs/developer_versioned_docs/version-v4.1.0-rc.2/docs/aztec-nr/testing_contracts.md -You can organize tests in separate files: - -- Create `src/test.nr` with `mod utils;` to import helper functions -- Split tests into modules like `src/test/transfer_tests.nr`, `src/test/auth_tests.nr` -- Import the test module in `src/main.nr` with `mod test;` -- Share setup functions in `src/test/utils.nr` - ::: -======= For larger test suites, split tests into submodules of your crate rather than keeping them all inside `main.nr`: - Create modules like `src/transfer_tests.nr`, `src/auth_tests.nr` @@ -106,7 +88,6 @@ For larger test suites, split tests into submodules of your crate rather than ke See the [aztec-standards token contract](https://github.com/defi-wonderland/aztec-standards/tree/dev/src/token_contract) for a worked example of this layout. ::: ->>>>>>> 31fedbddff (docs: fix v4.2.0 developer tutorial/guide bugs (#22618)):docs/developer_versioned_docs/version-v4.2.0/docs/aztec-nr/testing_contracts.md ## Deploying contracts diff --git a/docs/developer_versioned_docs/version-v4.1.0-rc.2/docs/tutorials/contract_tutorials/recursive_verification.md b/docs/developer_versioned_docs/version-v4.1.0-rc.2/docs/tutorials/contract_tutorials/recursive_verification.md index 831552ab6a40..3da4630e89d5 100644 --- a/docs/developer_versioned_docs/version-v4.1.0-rc.2/docs/tutorials/contract_tutorials/recursive_verification.md +++ b/docs/developer_versioned_docs/version-v4.1.0-rc.2/docs/tutorials/contract_tutorials/recursive_verification.md @@ -228,11 +228,7 @@ The contract demonstrates several important patterns: Use `aztec new` to generate the contract project structure: ```bash -<<<<<<< HEAD:docs/developer_versioned_docs/version-v4.1.0-rc.2/docs/tutorials/contract_tutorials/recursive_verification.md -aztec new contract --name ValueNotEqual -======= aztec new --name ValueNotEqual contract ->>>>>>> 31fedbddff (docs: fix v4.2.0 developer tutorial/guide bugs (#22618)):docs/developer_versioned_docs/version-v4.2.0/docs/tutorials/contract_tutorials/recursive_verification.md ``` The `aztec new` wrapper stops parsing arguments at the first positional, so `--name` must come **before** the `contract` path — otherwise the flag is silently dropped and the Nargo package ends up named `contract`. The Nargo package name (`--name`) is independent of the Noir contract name declared inside `main.nr`; the artifact filename downstream is driven by the contract name. diff --git a/docs/developer_versioned_docs/version-v4.1.0-rc.2/docs/tutorials/contract_tutorials/token_contract.md b/docs/developer_versioned_docs/version-v4.1.0-rc.2/docs/tutorials/contract_tutorials/token_contract.md index 1661b8660c6d..a29cb0ee0616 100644 --- a/docs/developer_versioned_docs/version-v4.1.0-rc.2/docs/tutorials/contract_tutorials/token_contract.md +++ b/docs/developer_versioned_docs/version-v4.1.0-rc.2/docs/tutorials/contract_tutorials/token_contract.md @@ -39,15 +39,9 @@ We'll create BOB tokens with: Let's create a simple yarn + aztec.nr project: ```bash -<<<<<<< HEAD:docs/developer_versioned_docs/version-v4.1.0-rc.2/docs/tutorials/contract_tutorials/token_contract.md -mkdir bob_token_contract -cd bob_token_contract -yarn init -======= aztec new bob_token cd bob_token yarn init -y ->>>>>>> 31fedbddff (docs: fix v4.2.0 developer tutorial/guide bugs (#22618)):docs/developer_versioned_docs/version-v4.2.0/docs/tutorials/contract_tutorials/token_contract.md # This is to ensure yarn uses node_modules instead of pnp for dependency installation yarn config set nodeLinker node-modules yarn add @aztec/aztec.js@v4.1.0-rc.2 @aztec/accounts@v4.1.0-rc.2 @aztec/test-wallet@v4.1.0-rc.2 @aztec/kv-store@v4.1.0-rc.2 @@ -381,11 +375,7 @@ In this case, all that the network sees (including Giggle) is just "something ha ### Updating Storage for Privacy -<<<<<<< HEAD:docs/developer_versioned_docs/version-v4.1.0-rc.2/docs/tutorials/contract_tutorials/token_contract.md -For something like balances, you can use a simple library called `easy_private_state` which abstracts away a custom private Note. A Note is at the core of how private state works in Aztec and you can read about it [here](../../foundational-topics/state_management.md). For now, let's just import the library in `Nargo.toml`: -======= For something like balances, you can use a simple library called `balance_set` which abstracts away a custom private Note. A Note is at the core of how private state works in Aztec and you can read about it [here](../../foundational-topics/state_management.md). For now, let's add it by replacing the `[dependencies]` section in `Nargo.toml`: ->>>>>>> 31fedbddff (docs: fix v4.2.0 developer tutorial/guide bugs (#22618)):docs/developer_versioned_docs/version-v4.2.0/docs/tutorials/contract_tutorials/token_contract.md ```toml [dependencies] diff --git a/docs/developer_versioned_docs/version-v4.2.0-aztecnr-rc.2/docs/aztec-js/how_to_pay_fees.md b/docs/developer_versioned_docs/version-v4.2.0-aztecnr-rc.2/docs/aztec-js/how_to_pay_fees.md index c73ebbf68d27..1dcaacd8c744 100644 --- a/docs/developer_versioned_docs/version-v4.2.0-aztecnr-rc.2/docs/aztec-js/how_to_pay_fees.md +++ b/docs/developer_versioned_docs/version-v4.2.0-aztecnr-rc.2/docs/aztec-js/how_to_pay_fees.md @@ -167,53 +167,9 @@ Third-party FPCs can pay for your fees using custom logic, such as accepting dif ```typescript import { GasSettings } from "@aztec/stdlib/gas"; -<<<<<<< HEAD:docs/developer_versioned_docs/version-v4.2.0-aztecnr-rc.2/docs/aztec-js/how_to_pay_fees.md // node is from createAztecNodeClient() in the connection guide (see prerequisites) const maxFeesPerGas = (await node.getCurrentMinFees()).mul(1.5); //adjust this to your needs const gasSettings = GasSettings.default({ maxFeesPerGas }); -======= -On networks where the Sponsored FPC is unavailable, third-party FPCs deployed by ecosystem teams let you pay fees in tokens other than Fee Juice. Each FPC provider typically offers an SDK or API that handles payment method construction on the client side — this may include quote fetching and authwit creation, though the exact flow depends on the FPC design. For background on how FPCs work at the protocol level, see [How FPCs work](../foundational-topics/fees.md#how-fpcs-work). - -#### Example: Nethermind Private Multi Asset FPC - -To illustrate how a third-party FPC integration works, the following walkthrough uses Nethermind's [Private Multi Asset FPC](https://github.com/NethermindEth/aztec-fpc) as a reference. This is one implementation — other FPCs may differ in design and API. - -This FPC is quote-based and operates privately: - -- A single deployment accepts many tokens — the asset is selected per quote rather than hard-coded at deploy time. -- Fee payments are transferred as private notes, so fee activity is not visible onchain. -- An operator-run attestation service signs per-user quotes binding the FPC address, accepted asset, amounts, expiry, and user. -- A cold-start entrypoint allows a brand-new account to bridge tokens from L1, claim on L2, and pay the fee in a single transaction. Note that the cold-start path calls `Token::mint_to_private`, which enqueues a public call to update the token's total supply — so the minted amount is visible onchain even though the user's identity and balances remain private. - -:::warning Third-party software -This FPC is developed and maintained by Nethermind, not by Aztec Labs. The SDK (`@nethermindeth/aztec-fpc-sdk`) may not yet be published to npm — check the [repository README](https://github.com/NethermindEth/aztec-fpc/blob/main/sdk/README.md) for current install instructions. Review the [protocol spec](https://github.com/NethermindEth/aztec-fpc/blob/main/docs/spec/protocol-spec.md) and evaluate independently before integrating. -::: - -The SDK wraps the quote-and-pay flow into a single call. The snippet below shows the general shape of the integration (illustrative — verify against the current SDK API before using): - -```ts -import { FpcClient } from "@nethermindeth/aztec-fpc-sdk"; - -// Point the client at the FPC's attestation service -const fpcClient = new FpcClient({ - fpcAddress, // the deployed FPC contract address - operator, // operator's Aztec address - node, // PXE or node connection - attestationBaseUrl: "https://...", // attestation service URL from the FPC provider -}); - -// Estimate gas, fetch a signed quote, and build the payment method -const payment = await fpcClient.createPaymentMethod({ - wallet, - user: aliceAddress, // the account paying the fee - tokenAddress, // the token you want to pay in - estimatedGas, // from a prior estimateGas call -}); - -// Use it like any other payment method -const tx = await myContract.methods.myMethod(args).send({ fee: payment.fee }); -await tx.wait(); ->>>>>>> 31fedbddff (docs: fix v4.2.0 developer tutorial/guide bugs (#22618)):docs/developer_versioned_docs/version-v4.2.0/docs/aztec-js/how_to_pay_fees.md ``` Private FPCs enable fee payments without revealing the payer's identity onchain: diff --git a/docs/docs-developers/docs/tutorials/contract_tutorials/recursive_verification.md b/docs/docs-developers/docs/tutorials/contract_tutorials/recursive_verification.md index b93c3a2e7aaf..b01dc9199eac 100644 --- a/docs/docs-developers/docs/tutorials/contract_tutorials/recursive_verification.md +++ b/docs/docs-developers/docs/tutorials/contract_tutorials/recursive_verification.md @@ -211,25 +211,15 @@ Use `aztec new` to generate the contract project structure: aztec new --name ValueNotEqual contract ``` -<<<<<<< HEAD -This creates a workspace with two crates: -======= The `aztec new` wrapper stops parsing arguments at the first positional, so `--name` must come **before** the `contract` path — otherwise the flag is silently dropped and the Nargo package ends up named `contract`. The Nargo package name (`--name`) is independent of the Noir contract name declared inside `main.nr`; the artifact filename downstream is driven by the contract name. This creates: ->>>>>>> 31fedbddff (docs: fix v4.2.0 developer tutorial/guide bugs (#22618)) ```tree contract/ -├── Nargo.toml # Workspace root -├── contract/ -│ ├── src/ -│ │ └── main.nr # Contract code -│ └── Nargo.toml # Contract configuration -└── test/ - ├── src/ - │ └── lib.nr # Test code - └── Nargo.toml # Test configuration +├── src/ +│ └── main.nr # Contract code +└── Nargo.toml # Contract configuration ``` ### Contract Configuration diff --git a/docs/docs-developers/docs/tutorials/contract_tutorials/token_contract.md b/docs/docs-developers/docs/tutorials/contract_tutorials/token_contract.md index eaf0df9c671c..6dd334e1b060 100644 --- a/docs/docs-developers/docs/tutorials/contract_tutorials/token_contract.md +++ b/docs/docs-developers/docs/tutorials/contract_tutorials/token_contract.md @@ -269,11 +269,7 @@ In this case, all that the network sees (including Giggle) is just "something ha ### Updating Storage for Privacy -<<<<<<< HEAD -For something like balances, you can use a simple library called `easy_private_state` which abstracts away a custom private Note. A Note is at the core of how private state works in Aztec and you can read about it [here](../../foundational-topics/state_management.md). For now, let's just import the library in `bob_token_contract/Nargo.toml`: -======= For something like balances, you can use a simple library called `balance_set` which abstracts away a custom private Note. A Note is at the core of how private state works in Aztec and you can read about it [here](../../foundational-topics/state_management.md). For now, let's add it by replacing the `[dependencies]` section in `Nargo.toml`: ->>>>>>> 31fedbddff (docs: fix v4.2.0 developer tutorial/guide bugs (#22618)) ```toml [dependencies] From 1317ffc657268e5b5746c998986288868b76f6d5 Mon Sep 17 00:00:00 2001 From: AztecBot Date: Fri, 24 Apr 2026 13:10:48 +0000 Subject: [PATCH 3/3] fix: adapt local_network.md for v4-next (file deleted in source) --- .../docs/tutorials/local_network.md | 13 ++++--------- 1 file changed, 4 insertions(+), 9 deletions(-) diff --git a/docs/developer_versioned_docs/version-v4.1.0-rc.2/docs/tutorials/local_network.md b/docs/developer_versioned_docs/version-v4.1.0-rc.2/docs/tutorials/local_network.md index ecaf5c143dd0..5d244a8f903f 100644 --- a/docs/developer_versioned_docs/version-v4.1.0-rc.2/docs/tutorials/local_network.md +++ b/docs/developer_versioned_docs/version-v4.1.0-rc.2/docs/tutorials/local_network.md @@ -80,19 +80,14 @@ This can present confusion when opening older contracts (and dependencies) writt ### Steps to keep up to date -1. Update the Aztec local network to the latest version (includes `aztec` command, pxe, etc): +1. Update the Aztec local network to a specific version (includes `aztec` command, pxe, etc) — `aztec-up` uses explicit subcommands to install and switch between versions. For example, to install and use [v**0.77.0**](https://github.com/AztecProtocol/aztec-packages/tree/v0.77.0): ```shell -aztec-up +aztec-up install 0.77.0 +aztec-up use 0.77.0 ``` -To update to a specific version, pass the version number after the `aztec-up` command, or set `VERSION` for a particular git tag, eg for [v**0.77.0**](https://github.com/AztecProtocol/aztec-packages/tree/v0.77.0) - -```shell -aztec-up 0.77.0 -# or -VERSION=0.77.0 aztec-up -``` +Run `aztec-up list` to see installed versions, or `aztec-up --help` for all available subcommands. 2. Update Aztec.nr and individual @aztec dependencies: