feat!: stop deriving signing key from privacy keys #24439
Merged
nventuro merged 14 commits intoJul 6, 2026
Merged
Conversation
Renames the account flag from --secret-key to --signing-key: the signing key is now the account's root and the privacy secret is derived from it, instead of deriving the signing key from the privacy secret. SSH accounts keep an independent random secret since their key is external. The wallet DB persists both keys. Also splits the ambiguous createOrRetrieveAccount into separate createAccount and retrieveAccount, and wires up the previously-unhandled ecdsasecp256k1 account type. BREAKING CHANGE: --secret-key is renamed to --signing-key and account addresses change.
The embedded stub providers routed schnorr_initializerless accounts to the ECDSA stub, disagreeing with stubClassIds which registers them under the schnorr stub class.
…unts Removes the deriveSigningKey(secret) fallback from the embedded wallet and TestWallet createSchnorr* methods so the signing key is always supplied explicitly, and threads it through the worker registerAccount RPC. Callers pass their fixture's signing key or a fresh random one. BREAKING CHANGE: createSchnorrAccount/createSchnorrInitializerlessAccount now require a signing key argument.
Removes the last usages of deriveSigningKey (which derived the account signing key from the privacy secret) and deletes the function, closing out #5837. The bot now treats its configured senderPrivateKey as the signing key and derives the privacy secret from it; the remaining test callers pass an explicit random signing key. BREAKING CHANGE: deriveSigningKey is removed; the bot's account address changes for a given senderPrivateKey.
cli-wallet switched to --signing-key, leaving createSecretKeyOption and parseSecretKey without any callers, so drop them. Also removes a now-redundant comment in the bot factory.
Adds migration notes for the signing-key decoupling, the aztec-wallet --secret-key -> --signing-key rename, and the bot senderPrivateKey change. Corrects the create-account guide and the wallet-extension tutorial (which taught the removed deriveSigningKey), and updates the type-checked examples to pass an explicit signing key.
nchamo
approved these changes
Jul 2, 2026
…o/f-778-remove-usage-of-ivsk-in-schnorr-account-derivation # Conflicts: # docs/docs-developers/docs/resources/migration_notes.md # yarn-project/end-to-end/src/bench/client_flows/client_flows_benchmark.ts # yarn-project/wallets/src/embedded/embedded_wallet.ts
- Rename SECRET_KEY to SIGNING_KEY in docker-compose.yml cli service - Fix docs snippet to use DomainSeparator instead of removed GeneratorIndex - Clear error when retrieving accounts stored by older aztec-wallet versions
nventuro
enabled auto-merge (squash)
July 2, 2026 18:31
nventuro
changed the title
…-ivsk-in-schnorr-account-derivation
…o/f-778-remove-usage-of-ivsk-in-schnorr-account-derivation # Conflicts: # docs/docs-developers/docs/resources/migration_notes.md # yarn-project/wallet-sdk/src/base-wallet/base_wallet.ts
nventuro
deleted the
nico/f-778-remove-usage-of-ivsk-in-schnorr-account-derivation
branch
July 6, 2026 21:26
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
3 participants
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Closes #5837
This PR makes it so we no longer derive signing keys from the master privacy key. If there's no user-supplied privacy key seed, we instead derive it from the signing key, which is a safe derivation: PXE never sees the signing key nor any value it is derived from.
This has a large knock-on effect on wallets, CLI, tutorials, etc., but there's ultimately no large decisions being made there, it is mostly mechanical changes. In some cases I reworked some internals of wallets to make this distinction clearer.