just checked the Sign Protocol attestation architecture this morning and honestly i wasn't expecting the schema layer to be the thing that kept me up 😂
most people reading through this skip straight to attestations. the signed statements, the on-chain records, the ZK proofs. and those are interesting. but i spent the last two days on something quieter - the schema registry - and i think its the most load-bearing component in the entire evidence layer that nobody is talking about.
here's what schemas actually are in this system.
a schema isnt a formatting preference
its a machine-readable contract between the issuer and the verifier. it defines the data structure, the field types, the validation rules, and the versioning of an attestation before a single credential is issued. when a government agency issues an attestation that a citizen is eligible for a benefit program, that attestation conforms to a schema
when a verifier checks that attestation
they're checking it against the same schema. the schema is what makes the attestation interpretable across different systems, chains, and environments without anyone needing to call an API or negotiate a custom integration.and the four attestation placement modes built on top of that schema layer are genuinely flexible
fully on-chain for public verification
fully off-chain with a verifiable anchor for sensitive payloads
hybrid combining both
ZK-enhanced for privacy-preserving proofs where the verifier confirms a property without seeing the underlying data. four real options, each mapped to a different sensitivity and use case requirement. issuers can choose based on what the program actually needs rather than being forced into one model.
SignScan then aggregates all of this - attestations across chains, storage layers, execution environments queryable via REST, GraphQL, SDK. the indexing layer is what makes attestations operationally useful rather than just cryptographically correct. you can issue a perfectly valid attestation and it means nothing if nobody can find or query it when verification is needed.
but here's what i cant resolve after two days in this documentation.schema versioning is listed as a property of schemas. that means schemas can change. and if schemas can change, existing attestations issued under an earlier version of a schema exist in the registry while the current schema has moved on.
the docs dont describe what happens at that point.
if a verifier queries an attestation issued under schema
version 1 after the issuer has migrated to schema
version 2 does the verification pathway still work?
does SignScan return the attestation with a version flag?
does the verifier need to maintain compatibility with old schema versions themselves?
is there a deprecation mechanism that signals to verifiers that an attestation's schema is no longer current?
this matters more than it sounds. in a sovereign deployment, attestations dont expire quickly. a land title attestation, a professional license, an eligibility credential these could be issued today and queried years later. if schema versioning isnt handled with explicit backward compatibility guarantees, the evidence layer accumulates orphaned attestations that are cryptographically valid but practically unverifiable because the schema they reference has drifted.what the design gets right is the foundation. schema-driven structured data with machine-readable validation, four placement modes mapped to real use cases, omni-chain indexing that makes attestations queryable regardless of where they were issued. thats the right architecture for a system that needs to operate across agencies, vendors, and networks without custom integration at every junction.
what i cant find is the schema lifecycle specification. what version compatibility looks like. whether old attestations remain verifiable after a schema update or whether they need to be reissued. whether the schema registry maintains a history of previous versions or only the current one.
It's very well project that looks like RIVER to me
I dont know if the schema versioning model is a solved problem that just isnt documented at this level of detail or a gap that surfaces quietly years into a deployment when attestations issued under deprecated schemas stop being verifiable in practice?? 🤔#SignDigitalSovereignInfra @SignOfficial $SIGN
