Explanation

Users are receiving notifications for addresses they do not own.

Since notification-services-controller v24, the wallet-activity address list has been stored in Authenticated User Storage, whose notification-preferences blob is keyed by canonical profile ID. Profile pairing shares that ID across every SRP belonging to the same human, so the stored list pools the addresses of unrelated SRPs and every installation reads back the union of all of them. Addresses are keyring-scoped and cannot live in profile-scoped storage.

This restores the pre-v24 arrangement: the keyring is the source of truth for which addresses exist, and the Trigger API for which of them are enabled.

What changed

• checkAccountsPresence, fetchAndUpdateMetamaskNotifications and enablePushNotifications take the candidate addresses from the keyring and read the per-address enabled bit from the Trigger API. An installation can therefore only ever ask about addresses it actually holds.
• enableAccounts / disableAccounts write subscriptions through the reintroduced updateOnChainNotifications. The endpoint is a per-address upsert rather than a full replace, so two installations authenticating as the same profile no longer clobber each other's subscriptions.
• createOnChainTriggers writes walletActivity.accounts: [] and subscribes the keyring's accounts only on genuine first-time setup.

Two decisions worth reviewing

First-time subscribe is gated on the absence of a preferences blob, not the absence of subscriptions. createOnChainTriggers also runs on the daily re-subscribe, so the pre-v24 condition ("no subscriptions yet, enable everything") would re-enable every account each day for a user who had turned them all off. Even at first-time setup, existing subscriptions win, so a user upgrading from a client that never wrote a preferences blob keeps whichever accounts they had already disabled.

The two user-level walletActivity channel toggles are still read from Authenticated User Storage. They contain no addresses, so sharing them across a paired profile is correct, and they need no follow-up removal. An unreadable blob now counts as both toggles enabled, matching the API's "every toggle is on unless stated otherwise" default — previously a storage outage produced an empty address list and silently emptied the notification list.

Drive-by fix

The device is now unregistered from push when no account has notifications enabled. The push API rejects a registration with no addresses, and that request is what performs the delete-and-reinsert of the device's links, so the rejection left the previous links in place and push kept arriving after a user disabled every account. This was reachable before this PR too, via an all-disabled list in storage.

References

• Backend prerequisite: consensys-vertical-apps/va-mmcx-notify-users-storage#124, which preserves the stored account list when a client sends an empty one, so this change cannot blank the list that unmigrated installations on the same profile still read.
• Client PRs to follow once this is released; both have had their now-dead reads of walletActivity.accounts removed locally and are ready to raise.

Checklist

• I've updated the test suite for new or updated code as appropriate
• I've updated documentation (JSDoc, Markdown, etc.) for new or updated code as appropriate
• I've communicated my changes to consumers by updating changelogs for packages I've changed
• I've introduced breaking changes in this PR and have prepared draft pull requests for clients and consumer packages to resolve them

Testing

292 tests pass across the package's 18 suites with coverage thresholds met. New coverage for: the Trigger API write path including address lower-casing, the daily re-subscribe not re-enabling disabled accounts, existing subscriptions surviving first-time setup, both push-unregister paths, the wallet-activity in-app toggle gating the on-chain fetch without affecting other notification types, and the fetch surviving an unavailable preferences blob.

Made with Cursor