I want to focus on one specific thing because I think it's more operationally important than most Sign content admits.
Revocation on Sign works correctly. An issuer decides a credential is no longer valid. They update the status. The change lands on chain. SignScan reflects it accurately. The protocol did exactly what it's supposed to do.
The problem starts one step earlier in the timeline.
A system reads a Sign attestation at 2pm Tuesday. The credential is valid. The system processes eligibility, grants access, moves the workflow forward. Revocation hits at 4pm Tuesday.
Same attestation now shows invalid. Sign's protocol knows. SignScan shows it. Every new query returns the updated status.
The system from 2pm Tuesday doesn't know. It already acted. It completed a workflow, wrote an eligibility flag somewhere upstream, passed the result to a downstream process that nobody is going to re-query because nothing told it to look again.
I kept thinking about what this looks like inside a government deployment. A citizen credential gets issued through Sign's attestation layer for CBDC access. Something changes, compliance status, residency verification, sanctions check. The issuer revokes.
Sign records the revocation perfectly.
But the CBDC distribution contract that read the credential at setup time already has that wallet marked eligible. It doesn't recheck on execution unless someone specifically built that recheck into the contract logic.
Most teams don't build that recheck. It's an extra query. It adds complexity. It feels like an edge case until a finance team asks why a revoked credential's wallet is still receiving distributions.
Sign's evidence layer is honest about everything it records.
The gap isn't in the protocol.
It's in the assumption that downstream systems stay synchronized with a revocation status that can change after they've already consumed the record. That assumption holds until it doesn't and when it breaks it breaks quietly. @SignOfficial $SIGN #SignDigitalSovereignInfra