feat: add optional additional scopes to wallet transaction API by nchamo · Pull Request #20487 · AztecProtocol/aztec-packages

nchamo · 2026-02-13T13:50:51Z

Summary

Previously, PrivateExecutionOracle automatically expanded scopes when making nested private calls to registered account contracts. This behavior was pretty hidden and made it hard to reason about which addresses' private state was accessible during execution.

This PR removes the auto-expansion and instead introduces an explicit additionalScopes option on send(), simulate(), and deploy(). Callers now declare upfront which additional addresses' private state they need access to beyond the sender's.

nchamo · 2026-02-13T13:55:34Z

noir-projects/noir-contracts/contracts/test/pending_note_hashes_contract/src/main.nr


    #[external("private")]
-    fn test_recursively_create_notes(owner: AztecAddress, how_many_recursions: u64) {
+    fn test_recursively_create_notes(recipients: [AztecAddress; 10], how_many_recursions: u64) {


We had to make these changes when we introduced scopes, because there was no way to inject multiple scopes. Since now there is, we can revert the change we made

…move unnecessary scopes

…ivate token transfer

nchamo · 2026-02-13T17:43:44Z

yarn-project/pxe/src/contract_function_simulator/oracle/private_execution_oracle.ts


    isStaticCall = isStaticCall || this.callContext.isStaticCall;

-    // When scopes are set and the target contract is a registered account (has keys in the keyStore),


Die hack, die!

congrats :D

mverzilli · 2026-02-13T18:16:18Z

yarn-project/wallet-sdk/src/base-wallet/base_wallet.ts

+  // When `from` is the zero address (e.g. when deploying a new account contract), we use only the
+  // additionalScopes if any, or an empty list which acts as deny-all: no notes are visible and
+  // no keys are accessible. Otherwise, we combine `from` with any additionalScopes, deduplicating.
+  protected scopesFor(from: AztecAddress, additionalScopes: AztecAddress[] = []): AztecAddress[] {


I find this name doesn't make match sense, maybe scopesFrom would make more sense.

And the comments are just a natural language description of the imperative steps the function does, which personally distracted me more than just reading the code. I would just remove the comment.

mverzilli

Looks good! I think it's missing migration notes, and some documentation in general

Thunkar · 2026-02-16T05:27:30Z

yarn-project/bot/src/bot.ts


    const batch = new BatchCall(wallet, calls);
    const opts = await this.getSendMethodOpts(batch);
+    const additionalScopes = isStandardTokenContract(token) ? undefined : [token.address];


Why does the non standard token need additional scopes?

Thunkar · 2026-02-16T05:28:51Z

yarn-project/end-to-end/src/e2e_fees/account_init.test.ts

-      const tx = await bobsDeployMethod.send({ from: AztecAddress.ZERO, wait: { returnReceipt: true } });
+      const tx = await bobsDeployMethod.send({
+        from: AztecAddress.ZERO,
+        additionalScopes: [bobsAddress],


This is the only thing that worries me. It makes 100% total sense that account contract self-deployments need this, but for such a common operation it's getting very verbose. Maybe we should consider this a higher level abstraction and provide some sane defaults

Thunkar

I'm fine with merging this as-is, but two important things remain:

Modify the capabilities manifest so simulations and transactions declare extra scopes might be required. Take into account the case where these scopes are not known in advance by the app, but are the same ones requested by the getAccounts capability
Talk about account contract self-deployments and how to add defaults (and the problems this caused in the past.

benesjan

I am repeating myself in some of the comments but think it would be useful to put everywhere a comment on why the scopes are getting expanded

benesjan · 2026-02-16T08:22:08Z

yarn-project/aztec.js/src/contract/interaction_options.ts

  /** The fee options for the transaction. */
  fee?: InteractionFeeOptions;
+  /**
+   * Additional addresses whose private state should be accessible during execution,


Suggested change

* Additional addresses whose private state should be accessible during execution,

* Additional addresses whose private state and keys should be accessible during execution,

benesjan · 2026-02-16T08:23:11Z

yarn-project/aztec.js/src/contract/interaction_options.ts

  fee?: InteractionFeeOptions;
+  /**
+   * Additional addresses whose private state should be accessible during execution,
+   * beyond the sender's


Think it would be useful to have here an example of why you would want this.

benesjan · 2026-02-16T08:24:14Z

yarn-project/cli-wallet/src/cmds/create_account.ts

      skipInstancePublication: !publicDeploy,
      skipInitialization,
      from,
+      additionalScopes: [address],


Would put here a comment regarding why we need to add the additional scope

benesjan · 2026-02-16T08:24:32Z

yarn-project/end-to-end/src/composed/docs_examples.test.ts

-    await newAccountDeployMethod.send({ from: prefundedAccount.address });
+    await newAccountDeployMethod.send({
+      from: prefundedAccount.address,
+      additionalScopes: [newAccountManager.address],


Would put here a comment regarding why we need to add the additional scope

benesjan · 2026-02-16T08:24:49Z

yarn-project/end-to-end/src/composed/e2e_local_network_example.test.ts

        accountManagers.map(async x => {
          const deployMethod = await x.getDeployMethod();
-          await deployMethod.send({ from: fundedAccount });
+          await deployMethod.send({ from: fundedAccount, additionalScopes: [x.address] });


Would put here a comment regarding why we need to add the additional scope

refactor: add explicit additionalScopes to wallet transaction API

79d75ae

nchamo changed the title ~~refactor: add explicit additionalScopes to wallet transaction API~~ feat: add optional additional scopes to wallet transaction API Feb 13, 2026

nchamo commented Feb 13, 2026

View reviewed changes

nchamo added the ci-no-fail-fast Sets NO_FAIL_FAST in the CI so the run is not aborted on the first failure label Feb 13, 2026

fix: add additionalScopes for account deploy in docs_examples test

f9bdde3

nchamo self-assigned this Feb 13, 2026

nchamo added 2 commits February 13, 2026 16:32

fix: add missing additionalScopes to account deploy call sites and re…

36301c1

…move unnecessary scopes

refactor: remove unnecessary additionalScopes from escrow mint and pr…

2a114c8

…ivate token transfer

nchamo commented Feb 13, 2026

View reviewed changes

nchamo requested review from Thunkar, benesjan and mverzilli February 13, 2026 17:52

mverzilli reviewed Feb 13, 2026

View reviewed changes

Thunkar reviewed Feb 16, 2026

View reviewed changes

Thunkar approved these changes Feb 16, 2026

View reviewed changes

benesjan reviewed Feb 16, 2026

View reviewed changes


		isStaticCall = isStaticCall \|\| this.callContext.isStaticCall;

		// When scopes are set and the target contract is a registered account (has keys in the keyStore),

	* Additional addresses whose private state should be accessible during execution,
	* Additional addresses whose private state and keys should be accessible during execution,

Conversation

nchamo commented Feb 13, 2026 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Summary

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

mverzilli left a comment

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Thunkar left a comment

Choose a reason for hiding this comment

Uh oh!

benesjan left a comment

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Reviewers

Assignees

Labels

Projects

Milestone

Development

Uh oh!

4 participants

nchamo commented Feb 13, 2026 •

edited

Loading