feat(aztec-nr)!: add msg_sender to the utility context by nchamo · Pull Request #24062 · AztecProtocol/aztec-packages

nchamo · 2026-06-12T16:43:21Z

Why we are doing this

Utility functions had no notion of msg_sender, so a utility that wanted to know its caller had to accept it as a parameter. HandshakeRegistry::get_app_siloed_secret took an explicit caller argument and siloed the returned secret by it, so a hostile contract could pass another address and read an app's siloed secret it shouldn't see.

Our fix

UtilityContext gains a msg_sender, exposed as self.msg_sender() and self.context.maybe_msg_sender(), mirroring the private and public contexts.
It is set only for cross-contract calls (utility-to-utility or private-to-utility), where it is the calling contract's address taken from the call graph and so cannot be forged. A top-level call (invoked directly by a wallet or dapp) has no caller: maybe_msg_sender() is none and msg_sender() panics. The from supplied when simulating still only controls note/key visibility; it is never exposed as a sender.
HandshakeRegistry::get_app_siloed_secret drops the forgeable caller parameter and silos by self.msg_sender(), so a contract can only retrieve secrets siloed to its own address.
TestEnvironment gains ExecuteUtilityOptions::with_from to simulate a cross-contract caller in tests without routing through an actual nested call.

Fixes F-671

nchamo · 2026-06-12T19:44:52Z

      throw new Error(`Cannot run ${entryPointArtifact.functionType} function as private`);
    }

-    if (request.origin !== contractAddress) {


We are now simply avoiding the extra param and doing:

const contractAddress = request.origin;

nchamo · 2026-06-12T19:45:51Z

  }
+
+  /** The address of the contract whose function is being executed, from the call context. */
+  protected get contractAddress(): AztecAddress {


Added this to avoid changing over 50 this.contractAddress to this.callContext.contractAddress

nchamo · 2026-06-12T19:46:18Z

+export type PrivateExecutionOracleArgs = UtilityExecutionOracleArgs & {
  argsHash: Fr;
  txContext: TxContext;
-  callContext: CallContext;


Moved into UtilityOracle

nchamo · 2026-06-12T19:47:04Z

+   * The caller address: it becomes the utility's `msg_sender` and determines which notes and keys are visible
+   * during execution. Pass `NO_FROM` when there is no acting account.
+   */
+  from: AztecAddress | NoFrom;


Made this change to keep it consistent with proveTx and simulateTx

…to-utility-context

nventuro

Fantastic, thanks!

…r-to-utility-context

## Conflict resolution (PR 2 of 2) Stacked on top of the raw merge #24221. This is the **reviewable diff** — it resolves the single conflict from merging `v5-next` into `merge-train/spartan-v5`. Once both are green, merge this into #24221, then #24221 into `merge-train/spartan-v5`, which catches the train up to its base and makes the long-lived `merge-train/spartan-v5` → `v5-next` PR conflict-free. ### Conflicts resolved (1) **`yarn-project/end-to-end/src/e2e_nested_utility_calls.test.ts`** — both sides added content at the same point in the `authorizeUtilityCall hook` describe block: - **train (`ours`)** added a doc comment above the existing `denies cross-contract utility call from private function when hook returns false` test (from the e2e annotation pass on the train). - **base `v5-next` (`theirs`)** added a new `nested utility call sees the calling contract as its msg_sender` test (from `feat(aztec-nr)!: add msg_sender to the utility context` #24062). **Resolution:** keep both — the new `msg_sender` test followed by the doc-commented `denies…private function` test. No code was dropped from either side. The `delegate_get_msg_sender` contract method the new test exercises is brought in by the merge (it lives in `noir-projects/noir-contracts/contracts/test/nested_utility_contract`, non-conflicting). No fixtures or generated files were involved. PR 1's CI is red by design (conflict markers committed there); this PR's CI is the one to watch. --- *Created by [claudebox](https://claudebox.work/v2/sessions/51d528a3438f2849) · group: `slackbot`*

) ## Summary Addresses the review comments on #23866 (constrained message delivery). Branched off and based on that PR so these follow-up changes can be reviewed in isolation. - **aztec-nr helpers**: tightened the constrained-delivery docs, fixed the misleading `index > 0` nullifier comment, switched secret resolution to `map`/`unwrap_or_else`, and renamed "chain" -> "sequence" across code/tests to avoid colliding with the existing "chain" (blockchain) meaning. - **Noir tests/contracts**: pinned the `get_handshakes` selector in the registry selector-match test, renamed the test helper to `authorizing`, and dropped redundant TXE tests now covered by the e2e and unit suites (plus the `delivery_unconstrained_handshake` compile-failure pin). - **PXE**: removed the temporary `get_app_siloed_secret` caller-arg authorization check (avoids conflicting with #24062), moved the registry-read helpers below the class, and reworked the cross-contract authorization test into `it.each` with shared `beforeEach`/`afterEach`. - Removed a stray `pied!` file that had been accidentally committed. The docs changes from the review are deferred to #24040, which owns the tagging-secret-source framing.

feat(aztec-nr)!: add msg_sender to the utility context

c63979a

nchamo requested review from a team and nventuro as code owners June 12, 2026 16:43

nchamo self-assigned this Jun 12, 2026

nventuro reviewed Jun 12, 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 Jun 12, 2026

refactor(aztec-nr)!: move utility from into ExecuteUtilityOptions

1e351b3

nchamo commented Jun 12, 2026

View reviewed changes

nchamo requested a review from nventuro June 12, 2026 20:04

nchamo added 2 commits June 17, 2026 11:54

refactor(aztec-nr)!: restrict utility msg_sender to cross-contract calls

19f3188

Merge origin/merge-train/fairies-v5 into nchamo/f-671-add-msg_sender-…

127e6d6

…to-utility-context

nchamo mentioned this pull request Jun 17, 2026

feat(aztec-nr): wire constrained message delivery #23866

Merged

nventuro reviewed Jun 18, 2026

View reviewed changes

nchamo added 2 commits June 18, 2026 17:46

refactor(aztec-nr): unconstrained utility msg_sender + Option oracle

92bc277

chore(txe): update oracle interface hash for Option msg_sender

3191b61

nchamo requested a review from nventuro June 18, 2026 21:14

nventuro approved these changes Jun 19, 2026

View reviewed changes

Merge branch 'merge-train/fairies-v5' into nchamo/f-671-add-msg_sende…

40f41c0

…r-to-utility-context

nventuro enabled auto-merge (squash) June 19, 2026 20:51

nventuro merged commit 25fa57e into merge-train/fairies-v5 Jun 19, 2026
12 checks passed

nventuro deleted the nchamo/f-671-add-msg_sender-to-utility-context branch June 19, 2026 21:11

AztecBot mentioned this pull request Jun 19, 2026

feat: merge-train/fairies-v5 #24206

Merged

nchamo mentioned this pull request Jun 20, 2026

refactor(aztec-nr): address constrained-delivery review comments #24217

Merged

AztecBot mentioned this pull request Jun 22, 2026

fix: resolve v5-next ← merge-train/spartan-v5 conflicts #24222

Merged

AztecBot mentioned this pull request Jul 21, 2026

chore: port v5-next to next #24825

Open

pplmaverick mentioned this pull request Jul 21, 2026

[BUG] SchnorrAccount (v5.0.1) bakes in stale v5.0.0 HandshakeRegistry address, breaking private function calls after network upgrade #24846

Open

Navigation Menu

Uh oh!

feat(aztec-nr)!: add msg_sender to the utility context - #24062

feat(aztec-nr)!: add msg_sender to the utility context#24062
nventuro merged 7 commits into
merge-train/fairies-v5from
nchamo/f-671-add-msg_sender-to-utility-context

nchamo commented Jun 12, 2026 •

edited

Loading

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

nchamo Jun 12, 2026 •

edited

Loading

Uh oh!

nchamo Jun 12, 2026

Uh oh!

nchamo Jun 12, 2026

Uh oh!

nchamo Jun 12, 2026

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

nventuro left a comment

Uh oh!

Uh oh!

Reviewers

Assignees

Labels

Projects

Milestone

Development

Uh oh!

2 participants

Uh oh!

Conversation

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

Uh oh!

Why we are doing this

Our fix

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

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

Uh oh!

Choose a reason for hiding this comment

Uh oh!

nchamo Jun 12, 2026

Choose a reason for hiding this comment

Uh oh!

nchamo Jun 12, 2026

Choose a reason for hiding this comment

Uh oh!

nchamo Jun 12, 2026

Choose a reason for hiding this comment

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

nventuro left a comment

Choose a reason for hiding this comment

Uh oh!

Uh oh!

Reviewers

Assignees

Labels

Projects

Milestone

Development

Uh oh!

2 participants

nchamo commented Jun 12, 2026 •

edited

Loading

nchamo Jun 12, 2026 •

edited

Loading