Your zkKYC credential may still be within its validity period, but after a protocol upgrade, it is no longer recognized. This is not uncommon. It does not mean the credential is 'broken.' It means the verification system has trouble recognizing a new format, a new key, or new rules.
A Valid Credential Does Not Mean the Verifier Can Recognize It
A zk KYC credential is essentially an encrypted data package issued by a credential issuer. It contains identity claims and a signature. When you present the credential to an on-chain protocol, the protocol's verification contract runs a set of rules: check the signature, check the credential type, compare version numbers, verify the public key, and so on.
If an upgrade changes any of these verification steps, the credential can be correct but still fail verification.
Where Verification Can Get Stuck After an Upgrade
- The credential format is new, but the old contract does not recognize it: If a protocol upgrade changes the credential's data structure (for example, adding new fields or rearranging fields), the old contract cannot correctly parse the new-format credential, so verification fails. The Galactica Snap upgrade is a good example: it fixed compatibility with new types of ZK certificates, allowing Snap to derive field lists directly from JSON content instead of hardcoding recognition of only fixed KYC formats. This shows the old version may not support some new credential types.
- The verification key (Verification Key) has been replaced: In zero-knowledge proofs, a credential is created with a 'Prover Key,' and verified with a matching 'Verification Key.' If a protocol upgrade replaces the verification key in the contract, credentials generated with the old proof process will fail the new key check. Mina protocol documentation also explains that upgrading a ZkApp only changes the on-chain verification key; proofs generated with the old proof function become invalid under the new key, and users must download the new proof function and generate again.
- The credential's validity period or 'nullifier' is consumed early: In on-chain compliance verification, once a credential's 'nullifier' (unique identifier) is consumed, the credential is spent and cannot be reused. If an upgrade changes how the nullifier is handled—for example, consuming the nullifier even when verification fails—your credential may be marked as 'already used' even though it was never successfully used. Basalt's audit report recorded a similar issue: the contract consumed the nullifier before Groth16 verification. If verification failed due to format errors, invalid curve points, or other reasons, users could not retry with the same nullifier until the next block.
Practical Suggestions
- Check what the upgrade changed first: Go to the project's official docs or announcements and confirm what changed—whether the verification contract was replaced or new credential formats are now supported.
- Check whether your credential is compatible with the new version: Some protocols support a migration path that can convert old-format credentials to the new format without repeating the full KYC process.
- Regenerate the proof if necessary: If the protocol only replaced the verification key, you need to use the new wallet or proof tool to regenerate the proof.
How to Check
After submitting verification, you can check the transaction's failure reason (Revert Reason) on a block explorer. If it includes 'verification key mismatch' or 'invalid proof format,' the verifier side is incompatible. If it says 'nullifier already used,' the credential's nullifier has been consumed, and you should contact the project team for confirmation.
