I want to start with something small. When you go to renew a professional license, the renewal board does not just check that you passed the original exam. It checks what happened between then and now. Whether you completed continuing education. Whether any complaints were filed. Whether your circumstances changed in ways that affect whether you should still hold that credential. The original qualification is not the whole picture. What happened after it matters just as much.
This is the gap I have been thinking about after spending time inside Sign Protocol's attestation architecture.
Sign Protocol records claims on chain. When an attester issues an attestation, the protocol captures three pieces of temporal information. There is the attestTimestamp, which records when the attestation was created. There is validUntil, which is an expiry timestamp the issuer sets at the time of creation, and zero means it never expires. And there is revokeTimestamp, which records when an attestation was actively revoked. These three fields define the temporal vocabulary of the protocol.
What I find interesting is what happens when block.timestamp passes the validUntil value. Nothing, at the protocol level. The revoked field stays false. No state changes. No event fires. The attestation sits there looking identical to a valid one unless the person reading it explicitly checks whether the timestamp has passed. Expiry is data the protocol stores. It is not something the protocol enforces.
Revocation is a different and more deliberate act. When an issuer calls the revoke function, the revoked field flips to true and the revokeTimestamp populates with the current block time. The record does not disappear. The attestation remains on-chain with all its original data, now annotated with the fact that it was revoked. Sign Protocol's FAQ describes attestations as meant to be final and immutable. Revocation does not delete. It annotates.
What this means is that Sign Protocol handles two out of three validity failure modes. It handles active revocation cleanly. It handles time based expiry as a data field that verifiers must check themselves. What it does not handle at all is the third category, which is the one I keep coming back to.
That third category is when a credential becomes factually wrong because circumstances changed, and no one triggered a revocation.
Someone is attested as eligible for a government benefit in January. In March their income changes and they no longer qualify. The issuer does not know this has happened. The attestation still reads as valid. The revoked field is still false. The validUntil timestamp has not passed. From the protocol's perspective, nothing has changed. From reality's perspective, the credential is no longer accurate. There is no mechanism inside Sign Protocol that can detect or flag this condition. The burden of knowing that circumstances changed falls entirely on the issuer, who has to revoke the old attestation and issue a new one. If the issuer does not know, nothing happens.
This is not a flaw I invented. The US Social Security Administration has been dealing with the exact same problem in a traditional system for decades. A report from the SSA's Inspector General found billions of dollars in improper payments between 2015 and 2022, most of them occurring because eligibility determinations drifted from reality between the moment they were made and when benefits were distributed. People's circumstances changed. The records did not. The payments continued.
Medical licensing produces a similar picture from a different angle. Investigations have found cases where physicians surrendered a license in one state after complaints or disciplinary action, then continued practicing in another state where that history was not visible. The credential in the new state was cryptographically valid in the sense that the license was real and the issuer was legitimate. The underlying situation it was supposed to represent had changed in ways the second state's verification system could not detect.
Sign Protocol's schema hooks offer one architectural surface for building around this problem. Hooks are smart contracts that execute on attestation creation and revocation. They can enforce conditions, reject invalid data, and fire notifications. A sophisticated implementation could connect hooks to oracles that periodically check whether conditions underlying an attestation still hold. But hooks fire on writes, not reads. There is no hook that runs when someone queries an attestation to verify it. The verification moment is outside the hook system entirely.
There is a workaround pattern in the protocol documentation that involves revoking a stale attestation and linking a new one to the old record using the linkedAttestationId field. This creates a correction chain that is auditable and on chain. But the precondition for this working is that the issuer knows a correction is needed. Which brings the problem back to the same place. The protocol can record that a correction happened. It cannot detect that one is needed.
The W3C Verifiable Credentials specification handles this differently, at least conceptually. It distinguishes between verification, meaning the cryptographic checks, and validation, meaning whether the claims are acceptable for a given use case. It also defines a refresh mechanism that signals to verifiers that an updated credential may be available from the issuer. None of this solves the underlying problem of detecting semantic staleness automatically, but it at least names the distinction explicitly. Sign Protocol's architecture largely inherits this limitation without naming it, which I think makes it harder to reason about.
What I keep coming back to is that Sign Protocol is building toward government-scale credential infrastructure. Sierra Leone, Kyrgyzstan, Abu Dhabi. Identity systems, benefits distribution, eligibility attestations. The environments where the gap between issuance validity and present validity is most consequential are exactly the environments Sign Protocol is pursuing. If someone's eligibility for housing assistance or food subsidy is recorded as an on-chain attestation, and their circumstances change in ways the issuer does not immediately know about, the protocol has no mechanism to bridge that gap. The credential will verify correctly. The underlying fact it describes may not still be true.
I do not think this is a reason to dismiss the project. The same limitation exists in every credential system, digital or paper. Traditional systems have not solved it either, as the SSA numbers demonstrate. What I think it means is that the application layer design built on top of Sign Protocol matters enormously, perhaps more than the protocol layer itself. The hooks, the oracle integrations, the periodic refresh cycles, the re-verification logic that someone has to build into the systems using Sign Protocol for real government services. The protocol provides the vocabulary. Whether those systems are designed to catch semantic staleness is a different question entirely.
Whether that design work is happening alongside the infrastructure agreements, or whether it will be figured out later, is something I cannot tell from looking at the protocol alone. $SIGN