Skip to content

feat: AUS Perps Watchlist#9010

Draft
gambinish wants to merge 3 commits into
mainfrom
perps/tat-2663-migrate-perps-watchlist-to-aus
Draft

feat: AUS Perps Watchlist#9010
gambinish wants to merge 3 commits into
mainfrom
perps/tat-2663-migrate-perps-watchlist-to-aus

Conversation

@gambinish
Copy link
Copy Markdown
Member

Explanation

References

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

@gambinish gambinish changed the title feat: aus watchlist init feat: AUS Perps Watchlist Jun 4, 2026
Comment on lines +5157 to +5159
const prefs = await this.messenger.call(
'AuthenticatedUserStorageService:getNotificationPreferences',
);
Copy link
Copy Markdown
Member Author

@gambinish gambinish Jun 4, 2026

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

@aganglada One note on storage approach: why NotificationPreferences and not AssetsWatchlistBlob or some other purpose built storage blob like PerpsWatchlistBlob.

The AUS package actually has two separate storage endpoints:

  1. getAssetsWatchlist / setAssetsWatchlist/assets-watchlist — a dedicated, atomic watchlist blob ({ version: 1, assets: string[] })
  2. getNotificationPreferences / putNotificationPreferences/preferences/notifications — a combined blob covering wallet activity, marketing, perps, and social AI settings

At first glance assets-watchlist would be the cleaner fit — or potentially even a new purpose built storage endpoint perps-watchlist, but per the ticket spec we are following the existing schema. Using a separate endpoint would arguably be cleaner because we don't need to do this read-merge-write pattern, which runs the risk of accidentally clobbering our existing notification settings.

The tradeoff to be aware of with this approach: every watchlist toggle now does a GET → merge → PUT on the entire notification preferences blob. This is the same pattern NotificationServicesController uses for wallet account updates, so it's consistent with the existing codebase — but it does mean a concurrent notification preference change and a watchlist toggle could race. That's worth keeping in mind as the perps notification work continues.

Should we consider storing this under a dedicated endpoint in @metamask/authenticated-user-storage instead?

Copy link
Copy Markdown
Member Author

@gambinish gambinish Jun 4, 2026

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

If we do want to have this purpose built endpoint (I think we should), the changes needed would roughly follow the pattern of asset-watchlist:

  1. New server endpoint in user storage API (likely a GET/PUT)
  2. New methods and types on @metamask/authenticated-user-storage
  3. Simplify this sync code in perps-controller, which would make things much cleaner

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

1 participant