Sync and caching

Sync the registry

Keeping a local copy for a wallet or explorer: bootstrap once, then poll for changes and removals.

1. Bootstrap

   Download /v2/assets/all.json once (use gzip). Record the largest updated_at as since, and the largest audit_id from GET /v2/audit?order=desc&limit=1 as cursor.

2. Check whether anything changed

   Send a cheap conditional request first, e.g. GET /v2/assets?page_size=1 with If-Modified-Since set to the Last-Modified you saw last time. 304 means no asset changed, removals included: skip this round. Otherwise note the new Last-Modified, run the steps below, and store it only after they complete.

3. Poll for changes

   Page newest-first with GET /v2/assets?sort=updated_at_desc&updated_after=<since − 1 s>&page_size=500 until a page is empty or its last item is older than since. Upsert each asset by asset_id.

   • The one-second overlap catches ties: updated_after is strictly after, and many assets can share one updated_at (many share the icon-import time). Expect duplicates.
   • Store the new since only after a complete pass, so an interrupted pass is retried.

4. Poll for removals

   Deregistered assets disappear from every listing (404 on lookups), so updated_after never reports them. Read them from the log: GET /v2/audit?operation=deregister&since_audit_id=<cursor> and the same with operation=legacy_deregister. Delete each action.asset_id locally and advance cursor to next_since_audit_id.

Caching

Last-Modified is registry-wide: it is the time of the last change to any asset, including removals and icons, so every listing, page, lookup and the icon map change together. A 304 on any of them therefore means no asset changed at all.