Nobody told me "confirmed" and "indexed" are two different events inside $SIGN. I had to find out the hard way. 🙃
Here's what happened:
Batch ran. 47 attestations confirmed on-chain. Clean settlement, no errors. I checked SignScan it returned 44. Three records were just... gone from the query surface.
My first instinct was to look for a bug. Spent an hour going through everything. No bug. The records existed on-chain. The indexing layer just hadn't caught up yet.
Meanwhile, downstream integrators were already hitting those retrieval paths. Getting empty responses. On records that had already settled.
That's when it clicked 👇
On-chain finality and SignScan availability are not the same gate.
A record can confirm cleanly and still sit outside the retrieval index long enough that anyone depending on the query path starts routing around it. And the workarounds arrive faster than you expect.
Three missing retrieval paths become a standing assumption: confirmed does not mean queryable.
That assumption is silent. It spreads without a postmortem. And once it's baked into how your team thinks about the system — it's really hard to unlearn.
The stricter fix costs more. Tighter indexing windows. Release flows that treat finality and availability as two separate gates. Retrieval checks before downstream calls go out.
But here's the thing about $SIGN that I keep coming back to:
This is exactly the surface where it earns its place. Not in the clean happy path where everything confirms and indexes in sync. But in that gap where settlement is final and retrievability hasn't started yet.
The side lookup off raw chain data stops appearing when the index catches the record before the integrator queries it. That's the standard Sign s building toward.
Not there yet. But the fact that the boundary is this well-defined is already more than most attestation infra gives you.
Are you building retrieval discipline into your integration flows — or are you trusting confirmed = queryable? 👇