AppliedBlock

A block as the subscription hub consumes it.

block is the raw ledger block when the provider has one. Providers that synthesise blocks — an emulator applying one transaction at a time — have nothing truthful to put here, which is why it is optional and why such providers declare that they do not serve Block subscriptions rather than fabricating a header.

The contract for partial coverage

A provider producing anything other than BlockCoverage.Complete owes the hub two things.

• One block per height, carrying the union of every source probed at that height — not one block per watcher. A query spanning two sources is covered only by a block that probed both (a union is as covered as its worst arm), so splitting a height across per-watcher blocks would leave such a subscription permanently uncovered and silent.
• Every height examined, whether or not it matched anything. An empty txs with the right coverage is how a provider says "I looked here for these sources and there was nothing", which is both what makes Idle truthful and what keeps watermarks tracking the tip. A provider that reported only the heights it found matches in would let its subscriptions fall arbitrarily far behind the retention window and lose events to pruning.

Heights are applied in ascending order and each is applied once — SubscriptionHub.applyBlock takes the block's height as the new tip unconditionally, so it has always required this.

Not yet supported: backfill. A provider that runs out of request budget mid-height and wants to come back for the sources it skipped would have to re-report a height it has already applied, and there is no representation for that: recent is ordered by height and a subscription's progress is a single watermark. Such a provider must instead defer the whole height until it can cover everything it has subscriptions for. Lifting this needs per-height observation sets and is a deliberate design step, not an implementation detail — see the M2 plan.