aztec-wallet deploy fails: "Public keys not registered for account" when deploying contract with private initializer + SinglePrivateMutable

[gobugi222]

Problem Statement

Environment

• CLI: aztec-wallet 4.0.0-devnet.2-patch.1
• Network: Devnet (NODE_URL=https://v4-devnet-2.aztec-labs.com/)
• Account: created with create-account + FPC-sponsored, alias my-wallet

What we do
We deploy a token contract (SnvrToken) that has a private initializer and uses SinglePrivateMutable for admin/state. Constructor:

#[external("private")]
#[initializer]
fn constructor(initial_admin_balance: u128, admin: AztecAddress) {
self.storage.admin.initialize(AddressNote { address: admin }, admin).deliver(...);
self.storage.balances.at(admin).add(initial_admin_balance).deliver(...);
self.storage.total_supply.initialize(UintNote { value: initial_admin_balance }, admin).deliver(...);
}

Assertion failed: Public keys not registered for account AztecAddress { inner: 0x2e26ccc617f0b9bc46907df85d65be78ceeba5c13341b3f4079a62fb09a26d63 } 'self.is_some()'
at get_public_keys(contract_address) (.../single_private_mutable.nr:125:30)
at self.get_initialization_nullifier (...)
at self.storage.admin.initialize (...)
at SnvrToken.constructor

The address 0x2e26... is the contract being deployed (SnvrToken), not the admin account. The runtime appears to require public keys for the new contract address during private init, but contract addresses are not registered as accounts.
Questions
Is this a known limitation for contracts with private initializers that use SinglePrivateMutable.initialize?
Is there a recommended workaround (e.g. deploy via Aztec.js, or a different storage pattern)?
Any plan to support this deployment path on devnet?
Note
The same contract deploys and runs correctly on local network via Aztec.js (E2E). Only CLI deploy to devnet fails.
Thanks.

Proposed Solution

No response

Example Use Case

No response

Alternative Solutions

No response

Additional Context

No response

[nventuro]

Hello! Thank you for reporting this failure, it is very useful information for us.

Nothing you're doing here is wrong, this is a very valid usecase. The key request is for privacy reasons: the contract will include a secret in the initialization note so that external actors cannot observe that the contract has initialized. Typically this is done with user data, e.g. your own notes that make up your balance, and we just use that user's keys, but this is contract state - it doesn't belong to anyone. Hence we decided to use the contract's own keys for it.

The same contract deploys and runs correctly on local network via Aztec.js (E2E). Only CLI deploy to devnet fails.

This is probably the key piece of information, there's likely a divergence and lack of configurability on the CLI as opposed to aztec.js which is causing issues to you. Unfortunately the CLI has historically received a bit less attention and love, so this is to be expected.

As a workaround, you can create a js script and use the same aztec.js functions as in your e2e tests to get unblocked. Meanwhile we'll look into this and make sure that the CLI deploy command supports this usecase.

---

If possible, could you share the aztec.js line you use for deployment and the CLI command that fails for you?

Thanks!