feat: merge-train/spartan-v5

.claude/agents/aztec-wallet.md

@@ -48,7 +48,7 @@ fi
 
 # Query node version
 RESPONSE=$(curl -sf -X POST -H 'Content-type: application/json' \
-  --data '{"jsonrpc":"2.0","id":1,"method":"node_getNodeInfo"}' \
+  --data '{"jsonrpc":"2.0","id":1,"method":"aztec_getNodeInfo"}' \
   "$RPC_URL" 2>&1) || {
   echo "ERROR: Could not reach node at $RPC_URL" >&2
   echo "Response: $RESPONSE" >&2

.claude/skills/release-docs/SKILL.md

@@ -30,7 +30,7 @@ Fetch node info from the provided RPC URL:
 
 ```bash
 curl -s -X POST -H 'Content-Type: application/json' \
-  -d '{"method":"node_getNodeInfo"}' <RPC_URL> | jq .result
+  -d '{"method":"aztec_getNodeInfo"}' <RPC_URL> | jq .result
 ```
 
 Parse the response to extract:
@@ -214,7 +214,7 @@ These files are auto-generated — do not hand-edit them.
 
 Regenerate the Node JSON-RPC API reference documentation. This script parses the
 TypeScript interface definitions and Zod schemas in `yarn-project/stdlib/src/interfaces/`
-to produce a complete markdown reference for the `node_` and `nodeAdmin_` RPC methods.
+to produce a complete markdown reference for the `aztec_` and `aztecAdmin_` RPC methods.
 
 **Prerequisite:** `yarn-project` must be built (already done in Step 6 prerequisites).
 
@@ -259,7 +259,7 @@ docs (Step 13), the generated content is included in the snapshot automatically.
 ### Step 9: Resolve Missing Contract Addresses & Update Network Info
 
 The `networks.md` L1 table includes contracts that are **not** returned by
-`node_getNodeInfo`. Before updating the tables, resolve these in three tiers.
+`aztec_getNodeInfo`. Before updating the tables, resolve these in three tiers.
 
 Determine the L1 RPC URL from the `l1ChainId`: `1` → Ethereum mainnet,
 `11155111` → Sepolia. The Rollup and Registry addresses are already known from

.claude/skills/release-network-docs/SKILL.md

@@ -45,7 +45,7 @@ Fetch node info from the provided RPC URL:
 
 ```bash
 curl -s -X POST -H 'Content-Type: application/json' \
-  -d '{"method":"node_getNodeInfo"}' <RPC_URL> | jq .result
+  -d '{"method":"aztec_getNodeInfo"}' <RPC_URL> | jq .result
 ```
 
 Parse the response to extract:
@@ -87,7 +87,7 @@ git tag -l "v<nodeVersion>"
 ### Step 3: Identify and Resolve Missing Contract Addresses
 
 The `networks.md` L1 table includes contracts that are **not** returned by
-`node_getNodeInfo`. Resolve these addresses in three tiers:
+`aztec_getNodeInfo`. Resolve these addresses in three tiers:
 
 #### Tier 1: Query on-chain from known contracts
 

.test_patterns.yml

@@ -371,7 +371,7 @@ tests:
     owners:
       - *palla
 
-  - regex: "yarn-project/end-to-end/scripts/run_test.sh ha src/composed/ha/e2e_ha_full.test.ts"
+  - regex: "yarn-project/end-to-end/scripts/run_test.sh ha src/composed/ha/e2e_ha_full.parallel.test.ts"
     owners:
       - *spyros
 

docs/README.md

@@ -276,8 +276,8 @@ The Node JSON-RPC API reference is auto-generated from the TypeScript interface
 
 **Source files:**
 
-- `yarn-project/stdlib/src/interfaces/aztec-node.ts` — `AztecNode` interface (`node_` methods)
-- `yarn-project/stdlib/src/interfaces/aztec-node-admin.ts` — `AztecNodeAdmin` interface (`nodeAdmin_` methods)
+- `yarn-project/stdlib/src/interfaces/aztec-node.ts` — `AztecNode` interface (`aztec_` methods)
+- `yarn-project/stdlib/src/interfaces/aztec-node-admin.ts` — `AztecNodeAdmin` interface (`aztecAdmin_` methods)
 - `yarn-project/stdlib/src/block/l2_block_source.ts` — `L2BlockSource` interface (JSDoc for inherited methods)
 
 **Prerequisites:** `yarn-project` must have `node_modules/` installed so `npx tsx` can resolve `typescript`. Run `yarn install` from `yarn-project` if needed. No build is required — the generator parses source `.ts` files via the TypeScript Compiler API, not compiled output.

docs/docs-developers/docs/aztec-js/how_to_pay_fees.md

@@ -171,7 +171,7 @@ Fee Juice is non-transferable on L2, but you can bridge it from L1, claim it on
 
 #include_code bridge_fee_juice_setup /docs/examples/ts/aztecjs_connection/index.ts typescript
 
-Under the hood, `L1FeeJuicePortalManager` gets the L1 addresses from the node `node_getNodeInfo` endpoint. It then exposes an easy method `bridgeTokensPublic` which mints fee juice on L1 and sends it to an L2 address via the L1 portal:
+Under the hood, `L1FeeJuicePortalManager` gets the L1 addresses from the node `aztec_getNodeInfo` endpoint. It then exposes an easy method `bridgeTokensPublic` which mints fee juice on L1 and sends it to an L2 address via the L1 portal:
 
 #include_code bridge_fee_juice_execute /docs/examples/ts/aztecjs_connection/index.ts typescript
 

docs/docs-developers/docs/resources/migration_notes.md

@@ -18,6 +18,19 @@ The `message_delivery` module has been renamed to `delivery`. Update imports acc
 + use aztec::messages::delivery::MessageDelivery;
 ```
 
+### [Node JSON-RPC] Method prefixes changed to `aztec_*` and `aztecAdmin_*`
+
+All Aztec node JSON-RPC method prefixes have changed:
+
+- `node_*` → `aztec_*` (public node methods, port 8080)
+- `nodeAdmin_*` → `aztecAdmin_*` (admin methods, port 8880)
+- `nodeDebug_*` → `aztecDebug_*` (debug methods, port 8080, local-network or `--node-debug` only)
+- `p2p_*` namespace removed; P2P queries are on `aztec_*`: `getPeers`, `getCheckpointAttestationsForSlot`, `getProposalsForSlot`
+- New archiver sync helpers on `aztec_*`: `getL1Constants`, `getSyncedL2SlotNumber`, `getSyncedL2EpochNumber`, `getSyncedL1Timestamp`
+
+If you call the node RPC directly (e.g. via `curl` or a custom client), update all method names accordingly.
+Clients created via `createAztecNodeClient`, `createAztecNodeAdminClient`, and `createAztecNodeDebugClient` are updated automatically.
+
 ### [Aztec.nr] `get_pending_tagged_logs` oracle interface updated (oracle version 28)
 
 The `aztec_utl_getPendingTaggedLogs` oracle now takes an additional `provided_secrets` parameter of type `EphemeralArray<ProvidedSecret>`. This lets apps pass tagging secrets that PXE cannot derive on its own (e.g. handshake-derived secrets) alongside the secrets PXE manages internally.
@@ -100,7 +113,7 @@ After the `auth_registry`, `public_checks`, and `multi_call_entrypoint` demotion
 
 ### [Aztec.nr] `multi_call_entrypoint` demoted from protocol contract
 
-`multi_call_entrypoint` is no longer a protocol contract; its address is derived from its artifact rather than hardcoded at `6`, and PXE no longer auto-registers it. It is now a standard contract that PXE *preloads*: both `createPXE` and `EmbeddedWallet` preload the standard MultiCallEntrypoint automatically (and `EmbeddedWallet` additionally preloads `AuthRegistry`). **If you use the standard PXE or `EmbeddedWallet`, no changes are needed** — multicall keeps working out of the box.
+`multi_call_entrypoint` is no longer a protocol contract; its address is derived from its artifact rather than hardcoded at `6`, and PXE no longer auto-registers it. It is now a standard contract that PXE _preloads_: both `createPXE` and `EmbeddedWallet` preload the standard MultiCallEntrypoint automatically (and `EmbeddedWallet` additionally preloads `AuthRegistry`). **If you use the standard PXE or `EmbeddedWallet`, no changes are needed** — multicall keeps working out of the box.
 
 To preload a different set of standard contracts (for example to also preload `PublicChecks`, which is not preloaded by default), a wallet or app passes its own `preloadedContractsProvider` through the wallet's PXE options:
 
@@ -121,7 +134,7 @@ const wallet = await EmbeddedWallet.create(node, {
 });
 ```
 
-The provider *replaces* the default list (it is not additive), so include every standard contract you want available.
+The provider _replaces_ the default list (it is not additive), so include every standard contract you want available.
 
 ### [Aztec.nr] `public_checks` demoted from protocol contract
 

docs/docs-developers/docs/tutorials/testing_governance_rollup_upgrade.md

@@ -43,7 +43,7 @@ Wait for output showing deployed contract addresses. To get the **Registry Addre
 
 ```bash
 curl -s http://localhost:8080 -X POST -H "Content-Type: application/json" \
-  -d '{"jsonrpc":"2.0","method":"node_getNodeInfo","params":[],"id":1}' | jq '.result.l1ContractAddresses'
+  -d '{"jsonrpc":"2.0","method":"aztec_getNodeInfo","params":[],"id":1}' | jq '.result.l1ContractAddresses'
 ```
 
 Note the `registryAddress` from the output.

docs/docs-developers/getting_started_on_local_network.md

@@ -12,11 +12,14 @@ Get started on your local environment using a local network. If you'd rather dep
 
 The local network is a local development Aztec network running fully on your machine, and interacting with a development Ethereum node. You can develop and deploy on it just like on a testnet or mainnet (when the time comes). The local network makes it faster and easier to develop and test your Aztec applications.
 
+The local network always owns the local chain it starts. It deploys its own Aztec protocol contracts to the local Ethereum node and is not a mode for connecting to an existing Aztec network.
+
 What's included in the local network:
 
 - Local Ethereum network (Anvil)
 - Deployed Aztec protocol contracts (for L1 and L2)
 - A set of test accounts with some test tokens to pay fees
+- On-demand block production via the automine sequencer
 - Development tools to compile contracts and interact with the network (`aztec` and `aztec-wallet`)
 
 This guide will teach you how to install the Aztec local network, run it using the Aztec CLI, and interact with contracts using the wallet CLI. To jump right into the testnet instead, click the `Testnet` tab.