Skip to main content

Query the attestation snapshot

What this lets you do​

Pull the ASP's full event-indexed snapshot of pool activity in a single HTTP request. The snapshot contains every deposit, transact, and ragequit the ASP knows about, structured for fast client-side iteration, so one call replaces dozens of eth_getLogs chunks.

The SDK uses it automatically when aspUrl is configured on the session. The /note-events endpoint is the primary discovery feed, and this snapshot reconciles the status of the notes that discovery finds (spent, ragequit, and phantom-purge checks), rather than being the primary Note-event scan itself.

Constraints & limits​

  • Cache freshness. The ASP regenerates the snapshot periodically, typically every few seconds, so very recent events may not be in it yet. Fall back to chain reads for the tail.
  • Public read. Anyone can pull the snapshot. It doesn't reveal recipient identity (Note events are encrypted), but it does reveal the full event timeline including value distributions.
  • Snapshot size. The snapshot is currently a few hundred kilobytes on Sepolia, and it grows linearly with pool activity, so on a busy mainnet the download and parsing costs stop being trivial.
  • HTTP, not WebSocket. With no subscription model, your client polls. If you need real-time updates, watch the chain tip directly.

What it unlocks next​

  • Discover your notes in one HTTP call instead of a long chain scan.
  • Build your own indexers and dashboards on Privacy Pools v2 without running an Ethereum archive node.
  • Cold-sync new devices in seconds instead of minutes.

How to use it​

const response = await fetch(
    `https://api-dev.0xbow.io/${chainId}/public/event-snapshot/payload?entrypoint=${entrypointAddress}`,
);
const snapshot = await response.json();
console.log("Snapshot block:", snapshot.snapshotBlockNumber);

const session = await PoolSessionBuilder.fromConfig({
    ...baseConfig,
    aspUrl: "https://api-dev.0xbow.io",
}).create();
await session.discoverNotes();

The entrypoint query parameter is required: the SDK always scopes its ASP requests to the pool entrypoint address in its configuration, which is how the ASP returns the right pool's events on a chain that hosts multiple pools. The frontend resolves the address-to-pool mapping from /global/public/entrypoints.

Behind the scenes​

Endpoint GET {aspUrl}/{chainId}/public/event-snapshot/payload?entrypoint={entrypointAddress}. The entrypoint query param is always required, so the ASP returns the right pool's events on multi-pool chains.
SDK service HttpASPDataProvider scopes association-set, snapshot, and note-event requests by both chainId and entrypoint (both required in its config), e.g. /association-set/root?chainId=…&entrypoint=…. Label-status lookups use /labels/{decimalLabelHash}/status (path-only in the SDK) and report one of approved, pending, rejected, or unknown. A frontend may add optional chainId and entrypoint query params there as a multi-pool best practice.
What the ASP indexes All pool events visible on-chain: deposits, transacts, and ragequits. The ASP decrypts the deposit openings encrypted to its own key (the aspCiphertext) so it can screen labels, but it cannot decrypt the recipient note payloads in Note events, which are encrypted to recipient viewing keys. The snapshot is the public on-chain view, just pre-indexed.