Problem
Today the SDK / Platform query surface supports point lookups and a few specialized batch queries for top-level Platform objects, but it does not expose a paginated way to enumerate whole top-level collections.
Examples of what exists today:
- data contracts:
getDataContract(id), getDataContracts([ids...]), getDataContractHistory(...)
- identities:
getIdentity(id), getIdentityByPublicKeyHash(...), balances / nonces / keys
- tokens: token-specific lookups such as status, total supply, pricing, contract info, balances, etc.
- documents: paginated / cursor-based document queries already exist and can optionally be proved
What is missing is the ability to ask the SDK / Platform for things like:
- "give me all data contracts"
- "give me all identities"
- "give me all tokens"
with normal pagination semantics.
Why this is desirable
The data is already stored in Platform state trees, and paginated proved queries already exist for documents. So this does not appear to be a fundamental proof limitation; it looks more like a missing public query/API shape for top-level collections.
This would be useful for:
- explorer / admin tooling
- wallets / dashboards that want to discover available contracts or tokens
- migration / inspection tools
- SDK consumers who currently have to maintain side indexes just to enumerate top-level objects
Requested behavior
Add paginated query support for top-level collections, and expose it through the SDKs.
Example API shape
The exact naming is flexible, but conceptually something like:
getDataContractsPage({ startAfterId?, limit, prove? })
getIdentitiesPage({ startAfterId?, limit, prove? })
getTokensPage({ startAfterId?, limit, prove? })
Desired semantics
- deterministic ordering by key / identifier
- bounded pagination (
limit <= max)
- cursor support (
startAfter and/or startAt)
- optional proof support, like existing document queries
- response should make pagination easy (
nextCursor / hasMore / equivalent)
Token note
For tokens, the request here is specifically about enumerating tokens themselves, not every token-related per-identity or per-distribution row in the system.
Since token data is split across several token-keyed subtrees (status, contract info, pricing, balances, etc.), Platform would need to define a canonical enumeration source and a reasonable summary payload for a token page.
Why documents are a useful precedent
Platform already supports paginated, optionally proved document queries. That suggests the main missing piece here is not proofability, but adding the dedicated query/plumbing for these top-level collections.
Acceptance criteria
- Platform exposes paginated queries for enumerating data contracts, identities, and tokens
- queries can be optionally proved
- limits are validated and bounded
- SDKs expose ergonomic wrappers for these queries
- docs/examples show how to iterate through all pages safely
Problem
Today the SDK / Platform query surface supports point lookups and a few specialized batch queries for top-level Platform objects, but it does not expose a paginated way to enumerate whole top-level collections.
Examples of what exists today:
getDataContract(id),getDataContracts([ids...]),getDataContractHistory(...)getIdentity(id),getIdentityByPublicKeyHash(...), balances / nonces / keysWhat is missing is the ability to ask the SDK / Platform for things like:
with normal pagination semantics.
Why this is desirable
The data is already stored in Platform state trees, and paginated proved queries already exist for documents. So this does not appear to be a fundamental proof limitation; it looks more like a missing public query/API shape for top-level collections.
This would be useful for:
Requested behavior
Add paginated query support for top-level collections, and expose it through the SDKs.
Example API shape
The exact naming is flexible, but conceptually something like:
getDataContractsPage({ startAfterId?, limit, prove? })getIdentitiesPage({ startAfterId?, limit, prove? })getTokensPage({ startAfterId?, limit, prove? })Desired semantics
limit <= max)startAfterand/orstartAt)nextCursor/hasMore/ equivalent)Token note
For tokens, the request here is specifically about enumerating tokens themselves, not every token-related per-identity or per-distribution row in the system.
Since token data is split across several token-keyed subtrees (status, contract info, pricing, balances, etc.), Platform would need to define a canonical enumeration source and a reasonable summary payload for a token page.
Why documents are a useful precedent
Platform already supports paginated, optionally proved document queries. That suggests the main missing piece here is not proofability, but adding the dedicated query/plumbing for these top-level collections.
Acceptance criteria