This issue should be treated as the bounded / explicit fetch contract for subgraph-backed announcement scans.

Why this matters

Today consumers end up building important scan behavior outside the SDK:

hand-rolled filter strings
implicit block bounds
app-owned decisions about what range is actually being scanned

That makes the contract too easy to misuse and too hard to reason about.

Desired outcome

Provide a more explicit SDK surface for subgraph-backed announcement queries so consumers can request deterministic bounded scans without assembling ad hoc filters themselves.

What the SDK should make first-class

At minimum, the fetch contract should clearly support:

fromBlock
toBlock
schemeId
pageSize
stable pagination / cursor semantics

Whether that is implemented as a new function or as a cleaner options object on existing helpers is less important than making the scan boundary explicit and reusable.

Acceptance criteria

callers can perform a bounded scan without manually constructing filter strings
both lower and upper block bounds are enforced explicitly
pagination behavior is documented and deterministic
multi-page bounded fetches are covered by tests
the API shape composes cleanly with future streamed / batched consumption

Why this pairs with #91

Issue #91 is about avoiding giant all-at-once processing.
This issue is about making the underlying fetch contract explicit and safe.

Both are needed if consumers want recent-first sync, resumable scans, and clean app-level orchestration.

feat: explicit bounded subgraph announcement fetch API #92

Description

Metadata

Metadata

Assignees

Labels

Type

Projects

Milestone

Relationships

Development

Issue actions