Done. Everything verified.

Result

107 unique seat tokenIds performed attributable work on the IMD task network in the window 2026-09-22T08:53:15Z → 2026-09-24T08:53:15Z, across 216 in-window jobs.

Deliverables

• artifacts/report.md — the required report, split into facts (F1–F11) / inferences (I1–I4) / uncertainty (U1–U6) / open questions, each fact tied to a specific API response
• ACTIVE_SEATS_48H.json — all required fields, plus a coverage block of diagnostics
• ACTIVE_SEATS_48H.md — count, top 10, caveats
• tools/collect_active_seats.py, evidence/api_snapshot.json, README.md — generator and the frozen raw responses behind every number

Committed source and in-tree deliverables; artifacts/ is excluded by .git/info/exclude, so the named outputs are untracked as required. No token launched, no contract deployed — read-only GETs only.

Verification: 23/23 checks, run by a separate checker that re-fetched from the live API rather than my snapshot. The success criterion was checked exhaustively, not sampled: for all 107 seats, a cited job was re-fetched and the tokenId confirmed present on one of its nodes with createdAt inside the window. Zero failures.

Three things worth your attention before these numbers feed WorkerSubsidy:

1. Failed work is unattributable. Every in-window node in state failed carried seat: null (10/10 in-window, 54/54 across the full 500-job pull). A seat that tried and failed leaves no trace tied to its tokenId, so this census can only undercount. Relatedly, the 99.1% acceptance rate is an artifact — failure purges the denominator — and shouldn't be quoted as a network success rate.
2. The 500-row cap is an unguarded cliff. limit caps at 500 and offset/page/cursor are all ignored (each returned a byte-identical first page). This run is complete only because that page happens to reach ~18.5h past windowStart. At roughly 1.8× the current job rate the window would silently truncate with no way to recover the remainder. I put coverage.listingReachesBeforeWindowStart in the JSON as the tripwire for that.
3. The brief's node-state vocabulary doesn't match the API. It assumed accepted|completed|executing|failed|blocked; the API emits accepted|ready|failed|waiting|working. I mapped working→executing and admitted ready/waiting only with a verdict present (a verdict proves dispatch), and documented the mapping in method.

One correction during the work: I first wrote the top-10 table's agentIds from memory and 6 of 10 were wrong. They're now taken from the data, and the verifier parses that table and diffs it against the JSON so it can't drift again.