Skip to main content
If a filter has thousands of addresses (every pool of a DEX, every wallet you track) and you reuse it across many requests, upload it once as a set and refer to it by id. Requests stay small, and the server can cache which parts of the chain contain your addresses.

Create a set

  • kind is "address" (20-byte values) or "topic" (32-byte values).
  • Up to 100,000 values per set (about 4.6 MB of JSON for addresses).
  • The id is a hash of the sorted, deduplicated values. Posting the same values again returns the same set_id with "created": false. Creating a set is idempotent and cheap, so you don’t have to remember whether you already did.
With a client library:

Use it in a filter

A literal list and a set in the same object are combined: "address": [...] plus "addressSet": "…" matches either. To track wallets in topics (transfers to any of 50,000 wallets), create a topic set of the wallets padded to 32 bytes and use it as topic2Set.

Growing a set

A common pattern: you discover new addresses as you go (child contracts of a factory, new wallets) and want to query future ranges with the bigger list. Create the new set with basedOn pointing at the previous one:
basedOn is only a hint: the server can work out the new set’s matches incrementally instead of from scratch. The new set is a normal set with its own id. Always pass the previous id when you grow a set. See Factory contracts.

Lifetime and limits

  • Scope: sets belong to your project. Every key of the project can use them; nobody else can.
  • Per chain: a set lives on the chain where you created it. Create it on each chain you use it on.
  • Expiry: a set nobody has used for 7 days is deleted automatically. Don’t rely on an unused set surviving; just create it again (same values, same id).
  • Quota: 50 sets and 50 MiB of set data per project. A create past it makes room by deleting the project’s least recently used sets that have been idle for at least 10 minutes, so a set you grow step by step never needs cleaning up by hand. Only when every set was used more recently is the create refused with 403 quota_exceeded; delete sets you no longer need.
  • Create rate: up to 1,000,000 values per minute per project, counted across creates. Past it, 429 set_rate_limited with Retry-After.
  • Unknown set: a filter referring to a set that doesn’t exist (expired, made room for, or created on another chain) gets 404 unknown_set. Create the set again and retry.
The safe pattern is to create the set at the start of every job, even if it exists. It costs one small request and makes unknown_set impossible for the rest of the job.
Set management calls (POST/GET/DELETE /v1/sets) count toward your rate limit but return no row data, so they’re billed at the 10 KB minimum.