Most people, when they think about blockchain-based verification, focus on the attestation itself.
Whether it’s valid.
Whether it can be faked.
Whether it travels across systems the way it’s supposed to.
Those are reasonable things to focus on.
But they’re not where the real leverage sits.
There’s a layer underneath that almost nobody talks about.
Before an attestation can exist, someone has to design the schema it follows.
A schema is the template. It defines what fields get recorded, what data types are accepted, what the structure looks like. Without it, an attestation is just noise.
The schema is what makes a claim legible.
Comparable.
Usable.
And once you look at it that way, a different question starts to form.
Not whether a credential is valid.
But what it was designed to mean in the first place.
Because whoever controls the schema controls what the credential means.
This is where Sign Protocol starts to get interesting.
And also where something more uncomfortable begins to show up.
Sign’s architecture treats schemas as foundational primitives.
Any issuer can create one. A government, a university, a KYC provider, an auditing firm like OtterSec — they all define their own schema before they start issuing attestations.
That openness is intentional.
It avoids a single authority defining what credentials should look like.
But open schema creation introduces a different kind of constraint.
If two governments issue “national ID” attestations using different schemas, a downstream system has to decide which one it recognizes.
If a KYC provider updates its schema after millions of attestations have already been issued, those earlier records don’t automatically align with the new structure.
And if a large issuer — operating at the scale of a platform like Binance — defines a schema that becomes widely adopted simply because of its reach, smaller issuers are left with a choice:
conform to that schema, or risk being ignored by the systems that matter.
That last scenario is the one I keep coming back to.
Because this is how standards tend to form in practice.
Not through formal governance.
But through integration.
The largest issuer doesn’t just issue more attestations.
It quietly defines what “verified” looks like.
And once that happens, the schema stops being neutral.
It becomes an opinion — about what should be recorded, what should be ignored, and what counts as sufficient proof — reinforced by adoption.
At that point, the system is still open.
But it’s no longer evenly shaped.
SignScan makes schemas visible, which helps.
Developers can compare structures, evaluate issuers, and understand what exists.
But visibility isn’t the same as coordination.
Knowing that multiple schemas exist doesn’t resolve which one a protocol should accept.
And it doesn’t answer what happens when a widely-used schema evolves in a way that breaks compatibility with what came before.
There’s also the issue of time.
An attestation issued under schema version one doesn’t disappear when version two replaces it.
It remains valid.
But it describes a credential using a structure the issuer no longer uses.
A system reading that attestation has to know the version, understand what changed, and decide whether the older definition still satisfies its requirements.
At small scale, that’s manageable.
Across millions of attestations, issued by hundreds of issuers, across different chains and jurisdictions…
it becomes a coordination problem without a clean boundary.
Which leads to a quieter realization.
The proof can travel.
The meaning doesn’t necessarily keep up.
None of this is unique to Sign Protocol.
Any open attestation system will run into the same tension.
The question is whether the governance layer — still forming — becomes strong enough to prevent schema fragmentation from undermining the portability the system is built on.
Because there is a version of this future where everything verifies perfectly…
and still fails to align.
Not because the cryptography breaks.
But because a small number of dominant issuers end up shaping the schemas that matter.
Their definition of “verified” becomes the default.
Not by design.
But by scale.
And at that point, the system hasn’t really solved the problem.
It has just moved it.
From verifying claims…
to deciding whose definition of those claims gets accepted everywhere else.
Sign has already published schemas for audit verification, KYC compliance, developer reputation.
Each one is a reasonable starting point.
But the harder question isn’t how these schemas work today.
It’s what happens when they need to change.
Because at scale, verification isn’t just about proving something is true.
It’s about agreeing on what “true” is supposed to mean.
And that’s not a technical problem.
It’s a coordination one.