I was wiring identity attestations inside Sign Network and the part that slowed everything down was not storage or gas. It was deciding who gets to be recognized as “real” when the system is under pressure. That question shows up earlier than expected. Before UI, before scaling, before even thinking about cross-chain sync. You hit it the moment multiple issuers start writing identity claims into the same schema. The friction sits at admission.
Sign lets you define schemas for attestations and then different entities can issue claims against them. On paper, that feels flexible enough to model government-style identity. Multiple authorities. Verifiable records. Reusable across services. But once you try to treat those attestations as a gate into something sensitive, like access to benefits or compliance-restricted services, flexibility starts behaving like risk. Because not every issuer should carry the same weight.
In one setup I tested, we allowed three different issuers to write identity attestations under a shared schema. One was a verified institution, the other two were semi-trusted partners. The system technically accepted all three. But downstream applications didn’t treat them equally. Some flows started implicitly prioritizing one issuer over the others, even though nothing in the schema enforced that hierarchy. It emerged through usage. That is where it starts to feel like government systems. Not because of centralization, but because admission quietly becomes policy.
You can keep the schema open and let anyone write attestations, but then you spend your time filtering downstream. Or you tighten admission at the schema level, requiring issuers to meet certain conditions before they can even write. Both paths shift where the burden lives. In the first case, applications absorb the complexity. In the second, the protocol does. One strong line kept coming back while working through this: Identity systems are not built on data, they are built on who is allowed to write it.
Sign exposes that clearly because attestations are composable. Once a claim exists, it can be reused across contexts. That reuse is where things get messy. A single weak issuer can leak into multiple applications if the schema doesn’t gate properly. And once those attestations are referenced elsewhere, cleaning them up is not straightforward.
I tried a stricter admission model next. Issuers had to stake before writing identity attestations. Not a large amount, but enough to make careless issuance expensive. It worked in one sense. Low-quality attestations dropped immediately. The noise reduced. But a different cost appeared. Onboarding slowed down. Smaller institutions hesitated. The system became cleaner, but also quieter. That tradeoff sits right in the middle of the design. You reduce false identities, but you also reduce participation.
Another friction point showed up when syncing identity across services. Even with a shared schema, interpretation drifted. One application treated an attestation as sufficient proof. Another required two independent attestations for the same identity before granting access. Same data, different thresholds. The protocol stayed neutral, but the system as a whole became inconsistent.
If you test this yourself, try issuing a single identity attestation from a trusted source and plug it into two different apps. Watch how each one reacts. One will likely accept it immediately. The other may ask for reinforcement. The difference is not technical. It is policy leaking through implementation. That is where retry behavior becomes visible.
When an attestation is not accepted, users don’t see a schema mismatch. They see failure. They try again. Maybe through a different issuer. Maybe with additional data. Over time, this creates patterns. Certain issuers become default paths not because they are explicitly required, but because they succeed more often. Routing quality turns into hidden privilege. And once that happens, the system is no longer as open as it looks.
There is also the question of permanence. Because Sign anchors references on-chain while allowing data to live off-chain, identity records can be updated without rewriting everything. That helps with corrections and revocations. But it also introduces timing gaps. Between issuance and propagation, different parts of the system can hold slightly different views of the same identity.
If you simulate a revocation event and query immediately from two services, you might get conflicting answers for a short window. Not a bug. Just propagation lag. But in a government-grade context, even small windows like that matter. I’m not fully convinced where the right boundary sits.
Too open, and you spend your time filtering unreliable identity signals. Too closed, and you recreate the same bottlenecks these systems were trying to avoid. Sign does not force either direction. It gives you the surface area to make that decision, which is both useful and uncomfortable.
At some point, the economic layer becomes unavoidable. When you start thinking about issuer reputation, staking requirements, and penalties for bad attestations, the token stops being optional. It becomes the mechanism that holds the admission policy together. Not as an incentive headline, but as a way to price trust. Still feels early.
If you are building identity flows on top of this, try a simple test. Let two issuers with different trust levels write into the same schema and see how your application reacts over time. Then tighten admission and watch what breaks. The difference between those two states says more about your system than any documentation.
I keep coming back to the same unresolved question.
Who should be allowed to write identity, and how expensive should it be to be wrong.
@SignOfficial #SignDigitalSovereignInfra $SIGN
