Early this year, I used Sign Protocol to build a credential system for an edtech startup. Students who completed a course received an on-chain credential. Employers could verify it without seeing raw grade data. Test environment ran clean.
Production told a different story.
Students would get the completion email, claim their credential on Sign, and hit “attestation not found.” Reload a few times — it shows up. Employers would verify immediately, get an invalid result, then five minutes later it resolves. Support tickets piled up in week one.
Not a bug. Not a code issue.
This is Sign’s indexer lag window: the gap between when an on-chain record exists and when the off-chain indexer catches up. Sign uses an off-chain anchor architecture, with SignScan bridging the two.
During that gap, the chain says the credential exists. The API says it doesn’t.
Two conflicting truths at the same time.
That’s where my mental model broke.
This isn’t a design flaw. It’s a structural constraint. Sign doesn’t eliminate the data consistency problem. It relocates it — from on-chain to the gap between the indexer and the chain.
Last week Sign reported a 40% reduction in API latency after optimizing SignScan. Real improvement. But latency reduction doesn’t remove the lag window. It compresses it.
My fix: a polling layer on the client side, querying every 2 seconds until the attestation appears, capped at 30 seconds.
This works for delay-tolerant flows like certifications. It breaks in systems that assume instant finality — payments or access control.
At that point, the lag window isn’t UX. It’s a system constraint.
That’s why I track Sign by how they handle this gap over time.
Sign doesn’t eliminate the consistency problem.
It turns verification into a time-dependent function — where the same credential can be invalid, then valid, without anything changing on-chain.