Skip to main content

ASP snapshot API

The snapshot API is the HTTP surface the ASP exposes so clients can sync without scanning the chain directly. Its /note-events endpoint is the primary discovery feed, while the /event-snapshot/payload endpoint serves a pre-indexed view of all pool activity that clients use to reconcile note status. Both replace dozens of chunked eth_getLogs calls with a single JSON payload.

Endpoint​

GET https://api-dev.0xbow.io/{chainId}/public/event-snapshot/payload?entrypoint={entrypointAddress}

The entrypoint query parameter scopes the snapshot to one pool on multi-pool chains, and the SDK's HttpASPDataProvider always sends it (see Multi-pool deployments below).

Response schema (abridged)​

{
    "chainId": "11155111",
    "snapshotBlockNumber": "10881152",
    "generatedAt": "2026-05-19T19:57:03.712Z",
    "deposits": [
        {
            "txHash": "0x...",
            "logIndex": 549,
            "depositAddress": "0x...",
            "outputCommitment": "31452408...",
            "depositedValue": "10000000000000000",
            "fee": "0",
            "blockNumber": "10758126",
            "blockTimestamp": "2026-04-29T21:41:12.000Z",
            "asset": "0xeeee..."
        },
        ...
    ],
    "transacts": [ ... ],
    "ragequits": [ ... ]
}

Other endpoints​

GET /{chainId}/public/note-events?since={fromBlock}&until={toBlock} Encrypted Note-event payloads over a block range. This is the primary feed discoverNotes() pulls, with RPC gap-fill past the ASP's last-synced block.
GET /association-set/root?chainId={chainId} The ASP's current association-set root.
GET /association-set/leaves?chainId={chainId} The approved-label leaves backing the current root.
GET /labels/{decimalLabelHash}/status Status of a specific deposit label (approved / pending / rejected / unknown). The path segment is Poseidon(label) encoded as a decimal integer. The SDK calls this path-only form with no query scoping. A frontend may additionally pass optional chainId and entrypoint query parameters here as a multi-pool best practice, while the SDK label-status lookup stays path-only.
GET /public-key The ASP's X25519 pubkey. Clients encrypt the deposit's label-registration payload (the aspCiphertext passed to Entrypoint.deposit) to this key. Note events are encrypted to recipient viewing keys, never to the ASP.

Multi-pool deployments​

The SDK's HttpASPDataProvider scopes its requests by both chainId and entrypoint: the entrypoint address is a required field of its config, and the provider appends entrypoint={entrypointAddress} to the association-set, event-snapshot, and note-events requests (e.g. /association-set/root?chainId={chainId}&entrypoint={entrypoint}, /{chainId}/public/event-snapshot/payload?entrypoint={entrypoint}). On a chain that hosts more than one pool, resolve your pool's entrypoint from the ASP's /global/public/entrypoints feed (matched by PoolVault address).

How the SDK uses it​

The SDK reaches these endpoints through HttpASPDataProvider. When aspUrl is present in the session config, discoverNotes() pulls encrypted Note events from the /note-events endpoint as its primary feed, gap-fills any range past the ASP's last-synced block over RPC, and reads the /event-snapshot/payload view to reconcile note status (the spent, ragequit, and phantom-purge checks). It falls back to chunked log scans if the ASP returns a 404 or is unavailable.

Caching​

The ASP regenerates the snapshot server-side every few seconds. For a real-time UI, poll the snapshot every 5 to 10 seconds and watch the chain tip directly for the very latest events.