ERC-7812: ZK Identity Registry

ERCs
, ,
21

Hi,
We’re building a ZK-based identity protocol that derives cryptographic keys from biometric data in a non-storage, reproducible manner.

We’re exploring how to integrate Tunnel ID as a registrar on top of ERC-7812. The registry structure aligns really well with our design, especially the use of Poseidon-based SMT, commitment isolation, and the delegated ZK verifier model.

We had a few questions to ensure we’re implementing this correctly and future-proofing our registrar integration:

1. For inputs that may slightly vary between sessions (but still map to the same identity or key via ZK verification), is it acceptable to:

  • Always register a fixed commitment, and let ZK proofs handle verification of equivalence/proximity?
  • Or are registrars expected to allow updating/replacing commitments when drift is anticipated?

We’re asking this to determine whether the registry should act as a persistent anchor or a periodically rotated state point.

2. Can the value field in addStatement(key, value) be used by registrars to encode auxiliary metadata, such as circuit versioning, verification parameters, or commitment type identifiers?

Or is it assumed that all semantic information is handled off-chain by the ZK proof and verifier logic?

3. Is there a canonical pattern for linking specific verifier circuits to a registrar or statement type?

For example, if different registrars use different verification semantics (e.g., proof-of-ownership, proof-of-age, proof-of-proximity), how should dApps or wallets know:

  • what circuit applies to which commitment?
  • what inputs or public signals are expected?

4. Should this be externalized via IPFS, ENS, or would it make sense to suggest a verifier registry pattern in a future spec?

How should registrars handle users who want to register multiple statements (e.g., different modalities or backup factors) that all represent the same identity?

Should this be modeled via:

  • One commitment per modality (e.g., key1, key2) and an external linkage circuit?
  • Or a Merkle tree of sub-commitments as the stored value?

5. Credential Refresh & Recovery

In scenarios where a user loses access to the original input used to generate their statement (e.g., hardware change, sensor drift, or theft of auxiliary material), what is the recommended pattern for refreshing or recovering their credential?

  • Should registrars implement a replaceStatement() flow with ZK linkability to the previous statement?
  • Or is the expectation that the user simply registers a new statement, and recovery or linkage is handled off-chain?
  • Is there scope in the registry to formally support “rotatable credentials” or mark older statements as revoked/expired?

We’re asking this in the context of identity systems where users may not be able to reproduce the exact statement, but can still prove linkage to the original in zero-knowledge.

6. Backup & Recovery Patterns

For identity systems where users generate their commitments from private, non-stored inputs, what are the best practices for supporting backup and recovery?

Specifically:

  • Is it advisable for registrars to allow a user to register multiple recovery commitments under their namespace (e.g., main, backup1, backup2)?
  • Should recovery be handled via a ZK proof of linkage to the original statement (e.g., same preimage, same derived key)?
  • Is there value in formalizing a recovery framework (e.g., a substandard for credential fallback and delegation)?

We’re designing with the assumption that no original input is stored, so we want to ensure users can securely reassert their identity or keys in case of device loss or corruption.

22

will it use a lot of gas?

23

This heavily depends on the size of the registry, as the operational complexity grows logarithmically. Here is a gas usage table of the insertion operation of the SMT used as the data structure in this EIP. You can add another ~50k on top of that to get the EvidenceRegistry gas consumption.

SMT insertiob gas usage
SMT insertiob gas usage662×298 42.6 KB

24

Hey, apologies for the long reply. Here are the quick answers to the questions to clarify the registry intents:

I’d say this is fully up to the registrar to decide what to do with the commitments. For example, a user may register their identity once, and then decide to revoke it. The registrar may either remove the commitment from the EvidenceRegistry, or simply update it as “revoked”.

I personally wouldn’t add any metadata to the value as is. It is worth considering having some mapping on the registrar itself for that. For example, you may have a mapping key => timestamp to indicate when the identity has been created.

This is a good question which should be solved on a registry abstraction level. There may be a special national passports registrar with its own registration and verification circuits, and proper documentation how to use them. The dapp/wallet is required to integrate registrars individually since every ZK circuit has a unique zkey.

There is a huge room for improvement in this area since every registrar may well be worth a separate EIP.

It would be cool to explore storing a Merkle tree root in the value. Similarly to how iden3 does it in their identity protocol.

There should be some invariant users should be able to stick to so that the revoke/reissue flow is possible. Please check out the Rarimo passports repository to have a better understanding of the concept. There, the invariant is the user’s national passport.

Long story short, it is full up to the registrar to define the recovery rules. As an offtop, I am currently working on standardising the recovery of account abstracted accounts within EIP-7947, the idea which may be also used in the registrars.

Hope you would find these answers helpful.