You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
|`No public key registered for address`| Call `wallet.registerSender(...)`|
100
100
|`Direct invocation of ... functions is not supported`| Use `self.call()`, `self.view()`, or `self.enqueue()` to [call contract functions](framework-description/calling_contracts.md)|
101
101
|`Failed to solve brillig function`| Check function parameters and note validity |
102
+
|`Cross-contract utility call denied`| Configure an `authorizeUtilityCall`[execution hook](#cross-contract-utility-call-denied) on your PXE |
103
+
104
+
#### Cross-contract utility call denied
105
+
106
+
When a contract executes a utility function that calls into a different contract, PXE asks an **execution hook** whether the call should be allowed. If no hook is configured, or the hook denies the request, you will see:
To fix this, pass an `authorizeUtilityCall` hook when creating your PXE:
113
+
114
+
```typescript
115
+
import { PXE } from"@aztec/pxe/server";
116
+
117
+
const pxe =awaitPXE.create({
118
+
// ...other options
119
+
hooks: {
120
+
authorizeUtilityCall: async (request) => {
121
+
// Inspect request.caller, request.target, request.functionSelector, etc.
122
+
return { authorized: true };
123
+
},
124
+
},
125
+
});
126
+
```
127
+
128
+
The hook receives a `UtilityCallAuthorizationRequest` with the caller address, target address, function selector, function name, arguments, and caller context (`'private'` or `'utility'`). Return `{ authorized: true }` to allow or `{ authorized: false, reason: '...' }` to deny with a message.
Copy file name to clipboardExpand all lines: docs/docs-developers/docs/resources/migration_notes.md
+111Lines changed: 111 additions & 0 deletions
Display the source diff
Display the rich diff
Original file line number
Diff line number
Diff line change
@@ -40,6 +40,117 @@ If you relied on a bundled bare-name binary for general use:
40
40
41
41
If you set `Noir: Nargo Path` in the VS Code Noir extension to `$HOME/.aztec/current/bin/nargo`, change it to `$HOME/.aztec/current/bin/aztec-nargo` (the symlink is a drop-in for `nargo`). See the [Noir VSCode Extension guide](../aztec-nr/installation.md) for details.
42
42
43
+
### [Aztec.js]`DeployMethod` address-affecting parameters move to construction time
44
+
45
+
Salt, deployer, and public keys are now passed when the `DeployMethod` is constructed, not on every call to `send` / `simulate` / `request` / `getInstance`. This locks the contract address once it is determined and prevents the silent salt-cache poisoning bug where the address could change between calls.
46
+
47
+
`contractAddressSalt`, `deployer`, and `universalDeploy` have been removed from `DeployOptions`, `RequestDeployOptions`, and `SimulateDeployOptions`. They now live on a new `DeployInstantiationOptions` argument passed at construction. `deployer` and `universalDeploy` are mutually exclusive; passing both throws. `Contract.deployWithPublicKeys` and the generated `MyContract.deployWithPublicKeys(...)` factories have been removed; pass `publicKeys` via the `instantiation` argument of `deploy(...)` instead. The buggy synchronous `address` and `partialAddress` getters have been removed and replaced with `getAddress()` and `getPartialAddress()` (both `async`).
48
+
49
+
The compact form keeps working: `MyContract.deploy(wallet, ...args).send({ from: alice })` deploys with `deployer = alice` and `salt = random()`, exactly as before. The deployer is locked the first time `send` / `simulate` / `profile` is called (from `options.from`, with `NO_FROM` or undefined → universal) and cannot change after that:
50
+
51
+
- Subsequent `send` / `simulate` / `profile` calls with a `from` that would imply a different deployer throw, instead of silently producing a different address.
52
+
- A lock to universal (`AztecAddress.ZERO`) is the only one compatible with any sender, since the universal address does not depend on `from`.
53
+
- A lock to a concrete address only accepts that exact `from` on subsequent calls.
`ContractDeployer.deploy(...)` now takes the instantiation argument as its first parameter (pass `{}` to use defaults and rely on lazy locking from `from`):
109
+
110
+
```diff
111
+
- const cd = new ContractDeployer(artifact, wallet);
112
+
- await cd.deploy(...ctorArgs).send({ from: alice, contractAddressSalt: salt });
113
+
+ const cd = new ContractDeployer(artifact, wallet);
114
+
+ await cd.deploy(ctorArgs, { salt }).send({ from: alice });
115
+
```
116
+
117
+
The synchronous `address` / `partialAddress` getters are gone:
### [Aztec.nr] TXE `call_public_incognito` no longer takes a `from` parameter
135
+
136
+
`TestEnvironment::call_public_incognito` previously accepted a `from` address that was silently ignored (the function always uses a null `msg_sender`). The `from` parameter has been removed.
`PXE.proveTx` used to accept `scopes` as a positional argument; it now takes an options bag consistent with `simulateTx` and `profileTx`, and adds an optional `senderForTags` field. Update direct callers:
0 commit comments