Pool Catalogue

Use Shredo Pool Catalogue for signed Solana pool snapshots, token and pair search, resumable inventory changes and separate catalogue API keys.

Price: $99 per calendar month

Delivery: signed full inventory snapshots, pool search and resumable catalogue changes over HTTPS

Public API: https://console.shredo.xyz/catalogue/v1

Availability: purchasing is offered only when the console marks this product available

What the product delivers

The catalogue is a reproducible inventory of supported Solana liquidity pools and their dependency accounts. Full snapshots provide a verified starting point; resumable changes keep that local inventory current without downloading the complete inventory for each update. Search by token, pair or DEX through the documented API.

Catalogue membership answers “which pool identities and accounts are known in this generation?” It does not assert that every pool is liquid, currently executable, or in the state encoded by its latest on-chain accounts.

This is not a promise to cover every Solana pool or every DEX. A publisher timestamp and generation identify the inventory being read; a paid subscription alone does not establish data freshness.

Buy and open your catalogue

1. Continue from the product popup to the Shredo Console.
2. Sign in or create an account and verify your email.
3. Choose 1, 2, 3, 6 or 12 calendar months at 99 USDC per month. Only native USDC on Solana is accepted; there is no prepayment discount.
4. Pay your invoice, then press Check payment. The paid period starts from the finalized payment time, not from your first download or API-key creation.
5. Open My services → Pool Catalogue to manage your subscription, pause access and create catalogue API keys. Use your key to read publisher status, search pools, download snapshots and resume changes through the API.

An early renewal extends the current paid-until date. Setup delays and paused access do not extend the paid period. See Access and crypto payment.

Authentication and API keys

Catalogue data is available only through the API using a catalogue-specific key. A signed-in console session does not grant data access, including for administrators. The console manages subscriptions, billing, access controls and API keys; it does not browse the inventory or download snapshots.

Your application uses a separate catalogue key, created in your service page. The full key is displayed once. Store it in a secret manager or environment variable and send it only in an HTTPS authorization header:

curl --fail-with-body \
  -H "Authorization: Bearer $SHREDO_CATALOGUE_API_KEY" \
  'https://console.shredo.xyz/catalogue/v1/status'

Never put API keys in URLs, query strings, screenshots, public repositories or browser storage. Catalogue keys do not grant access to Raw Shreds or Decoded Transactions, and keys for those products cannot read the catalogue.

Create issues an independent key. Rotate atomically revokes the selected key and displays a replacement once. To overlap a client migration, create a separate key, switch the client, then revoke its predecessor. Revoke is irreversible. Operators can view metadata and revoke keys, but cannot retrieve your secret key.

Pause, resume and administrator stops

You can pause and resume catalogue access from the service page. Pausing does not pause billing. Access stops at expiry or when an account or service is blocked. Existing authorization leases are bounded to at most 30 seconds and cannot extend beyond paid-until.

Customer resume does not override an administrator stop. An administrator may stop or resume this specific catalogue service with an audit reason, independently of other subscribed products. Resuming an administrator stop does not clear a customer pause.

Contract

• Ed25519-signed manifests using a versioned schema.
• Immutable snapshot ID, feed epoch and cutoff checkpoint.
• Complete active pool and dependency-account inventory in SHA-256-verified NDJSON chunks.
• Signed, integrity-linked published metadata batches, including explicit pool removals.
• Full snapshots identify their inventory cut and publisher time; use status metadata to evaluate freshness, not subscription status.

All public endpoints begin with https://console.shredo.xyz/catalogue/v1 and require your catalogue API key in the authorization header. There is no unauthenticated download URL or API-key query parameter.

Request	Response
GET /status	Publisher readiness, staleness reason, publication and synchronization timestamps, snapshot ID, head and earliest checkpoints, as-of slot and pool count
GET /pools?mint=...&pair=...&venue=...&limit=25&cursor=...	Snapshot-pinned pool records and an optional next-page cursor
GET /snapshots/latest	Latest snapshot descriptor, cutoff checkpoint, manifest SHA-256 and chunk metadata
GET /snapshots/{snapshotId}/manifest	Exact signed UTF-8 JSON manifest bytes
GET /snapshots/{snapshotId}/signature	Detached Ed25519 signature, key ID and public-key metadata
GET /snapshots/{snapshotId}/chunks/{ordinal}	Exact NDJSON pool-record chunk bytes
GET /changes?after=...&limit=1&wait=25	At most one complete signed metadata batch, next and head checkpoints, and whether another batch is available
GET /keys	Active and retained publisher public-key metadata; not an independent trust root

Each API response is bounded to 4 MiB; a decoded change-batch body is bounded to 2 MiB. Slots, sequences and pool counts are decimal strings: preserve their precision instead of converting them to floating-point numbers.

Publisher identity and exact-byte verification

Before accepting a snapshot or change batch, obtain and pin the publisher’s key ID and raw Ed25519 public key through independently trusted Shredo documentation or operator configuration. The key ID is the lowercase hexadecimal SHA-256 of the raw 32-byte public key.

The /keys and /signature responses help identify a key; they do not make an unknown key trusted. Do not automatically trust a replacement key because a response advertises it. If a trusted key pin has not been provisioned for your integration, do not promote the inventory.

Current publisher key

The production publisher identity was verified through the operator’s authenticated server connection on 20 October 2026. Pin this identity before verifying downloaded data. The same public values are available as publisher key JSON.

{
  "algorithm": "Ed25519",
  "keyId": "101b4556c709be219e45590b6a787183e677f4ff7df814ad304819a02300c082",
  "publicKeyBase64": "60MTDVlpXpVueNSP30JLt0CXWtS0cucOEWnXavfCsOw="
}

Only the public verification key is published here. No private signing material is distributed. Future key rotations require an explicitly reviewed trust-pin update in your integration.

Verify snapshot signatures over these exact bytes:

ASCII("shredo/catalogue/snapshot/v1") || 0x00 || exact downloaded manifest bytes

Verify change-batch signatures over:

ASCII("shredo/catalogue/change-batch/v1") || 0x00 || base64-decoded bodyBase64 bytes

Use the pinned Ed25519 public key and the base64-decoded signatureBase64. Hash downloaded manifest and chunk bytes directly with SHA-256. For changes, sha256 hashes the decoded body bytes and previousHash links to the preceding body hash. Do not reserialize parsed JSON before signature or digest verification: whitespace and property order are part of the signed bytes.

Consumer workflow

1. Read /status and obtain /snapshots/latest. Check readiness, timestamps and the staleness reason independently of your paid access.
2. Download the descriptor’s snapshot manifest and signature. Verify the manifest SHA-256, pinned key ID, Ed25519 signature and supported schema version.
3. Download every chunk for that snapshot. Verify every chunk’s exact byte length and SHA-256 before parsing its NDJSON pool records. Validate the declared record counts and complete pool count.
4. Persist the complete snapshot and its signed cutoffCursor atomically.
5. Request changes strictly after that cutoff; verify and apply each complete batch and its integrity link before advancing your durable checkpoint.

Do not partially promote a generation. If signature, integrity-link, chunk or record-count verification fails, keep the previous verified catalogue. A snapshot ID is an opaque 64-character lowercase hexadecimal identifier, not its manifest digest.

Search and resumable changes

Search results are bounded pages belonging to a particular snapshot generation. Keep the generation and continuation cursor together while paging; do not concatenate pages from different snapshots as though they were one complete inventory.

The search response’s snapshotId identifies its logical pagination view, not a downloadable archive. Obtain archived snapshot IDs and download paths from /snapshots/latest; do not substitute a search-view ID into a snapshot download URL.

Use mint for one Solana mint, pair for two comma-separated Solana mints, and venue for the lowercase hyphenated DEX slug included in pool records, for example raydium-clmm. Public venue slugs use letters, digits and hyphens, not internal underscore-separated names. These optional filters combine; limit must be between 1 and 100. Continuation cursors are opaque and belong to the original filters and snapshot. A pool record includes id, venue, programId, address, mintA, mintB, kind, dependency roles and addresses, lifecycle, executable capability labels, incarnation, observation slot and update time. A capability label describes inventory eligibility, not a current execution or liquidity guarantee.

After verifying a full snapshot, resume changes from its checkpoint. Persist a checkpoint only after applying its complete change unit durably. Preserve the epoch, sequence and integrity linkage supplied by the API; never fabricate a continuation cursor from wall-clock time.

/changes uses bounded HTTP polling, not Server-Sent Events. Send after as your last verified checkpoint, limit=1, and wait from 0 to 25 seconds. The response contains feedEpoch, items, nextCursor, headCursor and hasMore. Each item carries sequence, sha256, keyId, bodyBase64 and signatureBase64.

After signature verification, parse the decoded body: its epoch and sequence must match the envelope; its events are either upsert with a complete pool record, or remove with the pool id and a reason. These are coalesced changes to published catalogue metadata, not every on-chain account mutation.

If the server reports a reset, an expired cursor or unavailable retained history, obtain and verify a fresh full snapshot. Do not silently skip a missing interval. Empty change pages are not proof of current publisher health. A disconnect or a pause does not create an unlimited replay guarantee.

Treat HTTP 401 or 403 as an authentication/access problem, 410 as an expired checkpoint requiring full-snapshot recovery, 429 as a request-rate or concurrency limit, and 503 as unavailable publisher data. Limit parallel downloads, pace archive requests, and retry 429 with bounded backoff (respect Retry-After when present). Rate limits may be shared by requests from the same IP. Keep your last verified inventory and checkpoint on failures; retry transient errors with bounded backoff. Do not replace an unavailable or incomplete catalogue with an empty inventory.

API consumers must retain their own verified inventory and checkpoint and handle the documented recovery responses. The console does not maintain an inventory replica or observe catalogue changes on your behalf.

Not included

Current executable pool state, live token prices or balances, trade history, trading rankings, and downstream redistribution are outside the base product. The catalogue does not expose private signing keys, payment wallets or searcher strategy metadata.