Everyone talks about Sign's attestation layer. Not many ask what the ZK part is actually doing under the hood.

Sign supports private and ZK attestations as part of the S.I.G.N. Stack. The use case makes sense on paper. A government issues verifiable credentials without exposing raw citizen data. A bank confirms KYC without transmitting personal records. A citizen proves eligibility without revealing income. Clean, sovereign, private.
And honestly, the technical instinct behind this is sound.
Here is where I started reading more carefully though. ZK attestations in Sign are a mode you opt into, not the default behavior. The base layer is transparent. Issuers sign claims onchain and those records are queryable by default. ZK sits on top for cases where the client specifically needs privacy. Which means the actual privacy guarantee is not in the protocol. It is in the deployment decision made by whoever is running the node.
Sign is not wrong to build it this way. Enterprise infrastructure needs optionality. You cannot ship a national identity system that forces ZK proofs before the ministry understands what a proof even is.
But that framing changes the sales pitch slightly. Sign is not selling a privacy-preserving protocol in the strict cryptographic sense. It is selling a platform with privacy capability available to clients ready to use it correctly. So when sovereign deployments in Kyrgyzstan or Sierra Leone get announced, the question worth asking is not whether Sign has ZK. It is whether those deployments are actually using it.
@Sign $SIGN #SignDigitalSovereignInfra