I think the most clarifying thing I ever observed about verification systems happened not in a blockchain context but in a hiring process I was peripherally involved in three years ago.
A colleague was reviewing candidates for a senior technical role. One applicant had strong credentials. Verified university degree. Previous employer reference checked. Skills assessment passed. Everything validated through proper channels by proper authorities at the time the checks were run.
The hire was made. Six months later it emerged that the candidate's claimed expertise in a specific technology had been accurate at the time of verification but referred to a version of that technology that had been superseded eighteen months earlier. The credential was valid. The validation was correct. The context had moved. The system had no mechanism for noticing the gap between what was verified and what was currently true.
Nobody had lied. Nobody had made a mistake. The verification had worked exactly as designed. And the outcome was still wrong because the credential had traveled further than the truth it was carrying.
I thought about that hiring process for a long time reading through Sign Protocol's credential architecture. Because the problem it is solving is genuine. Constant reverification is tedious and does not scale. Compressing verification into a reusable portable layer makes operational sense. The architecture is thoughtful and the direction is correct.
But there is a gap at the center of it that I keep coming back to.
What they got right:
The dual namespace CBDC architecture is one of Sign's more structurally sound design decisions and it deserves honest acknowledgment before the concerns.
Separating wholesale infrastructure for banks and large financial institutions from retail infrastructure for everyday users is not just an organizational choice. It is a risk management decision. Wholesale transactions carry different regulatory requirements different counterparty profiles and different failure consequences than retail payments. Keeping those flows in separate namespaces means a problem in one environment does not automatically propagate to the other. A retail payment system experiencing congestion does not affect institutional settlement. An institutional compliance requirement does not impose unnecessary friction on everyday transactions.
The separation also allows each namespace to be optimized for its actual use case. Wholesale systems can prioritize finality and auditability. Retail systems can prioritize speed and user experience. Trying to serve both purposes with a single unified architecture creates inevitable compromises. The dual namespace avoids that.
What bugs me:
What Sign compresses when it creates reusable portable credentials is not just verification overhead. It is time.
A credential reflects a moment. A point where something was true under specific conditions verified by specific actors. Once validated that moment becomes portable. It moves forward reused across contexts that were not part of the original verification. And the system does not reassess relevance. It checks whether the rules were followed at the time of issuance. Valid does not always mean current. Correct does not always mean appropriate to the context receiving it.
The colleague I hired had valid credentials. The validation process had functioned correctly. The credential had simply traveled further than the truth it was carrying. Nothing in the verification architecture was designed to notice that drift because noticing drift would require the system to continuously reassess credentials against changing reality rather than simply confirming they were correctly issued at the original moment.
Sign's architecture inherits this structural property. A credential issued by a government agency for a specific compliance purpose will be accepted by any system configured to recognize that issuer's attestations regardless of whether the underlying conditions that justified the original issuance have changed since. The ZK proof confirms the credential satisfies the stated conditions. It does not confirm the stated conditions are still the relevant ones.
My concern though:
The layered responsibility model compounds this. Issuers define truth. Validators confirm it. Platforms accept it. Users carry it. Each layer assumes the others did their job correctly. Most of the time that assumption holds because most cases are clean and standard.
Systems rarely fail at obvious points. They fail in the gaps between layers.
A slightly outdated credential. A validator interpreting an edge case differently from how another validator interpreted an identical edge case last month. A platform applying its own understanding of what a credential means in its specific context. None of these break the system outright. They introduce drift. And drift is harder to notice than failure because the system keeps functioning correctly at each individual layer while slowly stopping to reflect reality accurately at the system level.
The dual namespace CBDC design manages this drift risk better than a unified architecture would. Separating wholesale and retail keeps the drift in one namespace from affecting the other. But it does not eliminate drift within each namespace. It manages the blast radius while leaving the underlying dynamic unchanged.
Still figuring out:
The candidate I mentioned was eventually let go. The credential had been valid. The verification had been correct. The outcome was still wrong. The system that produced the hire had no mechanism for distinguishing between a credential that was accurate and a credential that was currently accurate. Those are different things and the architecture treated them as the same thing.
Sign is building infrastructure where that distinction will eventually matter at national scale. The efficiency of portable reusable credentials is real. The question of what happens when those credentials travel further than the truth they are carrying is the one I cannot find a satisfying answer to in the current documentation.
Honestly still figuring out whether Sign is making trust easier to move or just easier to stop questioning. The architecture makes trust more portable. Whether it makes trust more accurate over time is a different question that deployment at scale will eventually force into the open.