Bringing real-world identity on-chain

December 24, 2023

This is a non-technical write-up based on my work on Anon Aadhaar project at PSE. Last update: 12-06-2024*

In this post, we will explore how we can bring real-world identities on-chain in a privacy-friendly way, and what are some new things we can build by doing so.

What is identity?

Identity of a person is some information that "uniquely" identifies them. For example, your name, date of birth, address, etc. are all your identity.

Other attributes that you gain over time like your education, job, etc. can be considered as part of your identity.

In general, identity can be thought of as a set of attributes someone attests about you - the government can attest to your name, date of birth, address, etc. and your university can attest to your education.

When you want to prove your identity to someone, you can show these attestations and they can verify you if they trust the attestor.

Why do we need real-world identity on-chain?

Identity is probably the most valuable use case for blockchain after money. Identity requires unique properties of blockchains like global consensus, immutability, and censorship resistance.

With real-world identity on-chain, we can build applications that can solve real-world problems - some of them are discussed below, but fundamentally, we can achieve the following properties:

Sybil Resistance

If we can map one person to one on-chain identity, we can build applications where one person can do "an action" only once (or as many as allowed by the app). For example:

  • Vote only once.
  • Claim an airdrop only once.
  • Other proof of personhood applications.

Scoped applications

If we can bring demographic identities like nationality, city, age, etc. on-chain, we can build applications that are scoped to a particular identity group. For example:

  • applications where only people from a country or city can participate.
  • applications that are only allowed for people above 18.

How can we do this?

There are different approaches to bringing identity on-chain, each with its own trust assumptions and trade-offs.

1. Signed digital IDs

The most practical way to do this would be by using government-issued documents that are digitally signed. This can be National IDs, Passports, Resident IDs, or Driving License, that are digitally signed by the issuing authority.

That is, the issuing authority digitally signs the identity attributes of a person by their private key. We can then verify these signatures on-chain and bring verified identity attributes of people on-chain.

Some governments that issue digitally signed IDs:

Assuming governments issue only one identity document per person, we can get sybil resistance property.

2. Existing Web2.0 data

There are already attestations on a person's identity available on the internet - like emails, websites, APIs, etc. There are some techniques to bring Web 2.0 data on-chain:

  • ZK Email - protocol for generating proof of emails with selectively revealing information from the email content. This can be used to extract personal identity attributes from relevant emails.
    • can be an email from the government that contains your name and DOB.
    • an email from your bank that contains your name and address.
    • an email from your university that contains your degree.
    • highly trustable as the email is signed by the issuing entity directly (using DKIM protocol) and doesn't involve any third-party attestors.
  • There are protocols like TLS Notary and Reclaim Protocol that can extract data from websites and make proofs of it which are verifiable on-chain, but they come with some additional trust assumptions.

3. Explicit on-chain attestations

We can use a system like EAS where issuers directly attest to a person's identity on-chain.

There are no additional trust assumptions or complex signature verification required in this case. However, this is practically difficult as we need to convince governments, universities, etc. to issue attestations using some specific protocol.

4. Social Graphs

The most trustless and decentralized way would be to have each person attest to each other's identity attributes - like a social graph. The authenticity of someone's attribute can be based on the number of attestations they have from other people.

Again, this is practically difficult as:

  • bootstrapping the first set of "genuine" users is difficult.
  • designing this in a fool-proof way even for proving someone is a human is difficult, let alone other attributes like nationality, DOB, city, etc.

A probable solution here would be to use government-issued documents to bootstrap the first set of users for the social graph model.

As discussed above, the most practical way would be to use some signed data like government-issued documents or emails and **verify the signature on-chain (at least at the start before adding social graphs). Let's see how we can design a system based on this.


The biggest concern about bringing identity on-chain is privacy. We don't want to put the personal information of everyone on a public blockchain.

However, verifying a signature requires access to the signed data, and if we verify signed identity data on-chain, it would result in revealing the personal information of everyone to the whole world.

To solve this, we can use Zero Knowledge Proofs.

Zero Knowledge Proofs

We are not going into the details of how ZK works, but in short, it allows you to prove that you have run some computation correctly without revealing the input to the computation.

For our case, we can create a ZK circuit that verifies the signature of digital identity without revealing information that is signed.

Users can then create a proof of their digital ID using this circuit, and the verifier (smart contract) verifying the proof is convinced that the user possesses the signed data.

Users can also selectively reveal some information from their ID like age or city (as configured in the ZK circuit). This is how we can extract necessary identity claims from a signed document without exposing everything.

Solution - ZK-based identity system

An ideal solution would be an identity app where users can import their digitally signed documents from multiple sources and generate proofs as required by a consuming app while only revealing requested identity attributes - a self-sovereign identity system.

Read more on how to build this technically.

Current Projects

There are already some projects that use ZKP to create proof of real-world identity which are verifiable on-chain. Some of them are:

As more countries move on to digital identities or NFC-enabled IDs and passports, we can build similar solutions to onboard them. See proof-of-citizenship channel in PSE discord for discussions around this.

What kind of on-chain apps can we build?

Blockchains can act as a coordination layer. Bringing real-world identity on-chain means we can use Blockchains to coordinate around real-world problems and solve some of them.

"Blockchains" are used in a broad sense here, and it does not always mean Ethereum L1. For most applications, an L2 or even a hybrid mode where only essential data is kept on-chain and rest in IPFS (or similar P2P protocols) is sufficient.

Applications we can build depend on the issuer and the amount of data we can extract privately.

  • Depending on the identity system, we can generate proof of citizenship or proof of residency for a country.
  • If we can extract the DOB, we can generate proof of age.
  • If we can extract the address, we can generate proof of city, proof of state, etc.
  • If we have additional attestations, we can generate proof of education, proof of experience, etc.

More importantly, one person can only have one identity from an issuer, and we can get "one person one vote" property. Below are some ideas for novel on-chain applications we can build with real-world identity:

1. Decentralized Petition Portal

Similar to, UK Government (and the now discontinued one in USA), we can build a blockchain-based petition portal where citizens can create petitions and other eligible citizens can "sign" on them to show their support.

Building this on-chain means it's open to everyone and the results are transparent and credible. At the same time, we can verify the ZK proof identity to ensure that only eligible people (for example, citizens above 18 years) can sign and one person can only sign once.

If we can extract city or state from the identity source, we can also have petitions scoped to a locality where only people from that locality can sign.

2. Anonymous Survey Portal

This is similar to the petition portal, but instead of petitions, anyone can create polls where users can vote on the available options.

This can be used to build credible opinion polls where the results are verifiable by anyone. Like above, only eligible people can vote and can vote only once.

3. Anonymous Social Media

A social media platform where users can post anonymously, but all participants are real people (no bots). User can also prove their additional attributes to join special rooms.

Imagine a Reddit-like app where:

  • There is a section for the whole country where anyone can prove their identity and post.
  • There is a section just for your city where only people from your city can post.
  • The identity of the poster is not revealed, but you know that they are a real person with the required attributes.
  • Spam protection can be enforced by limiting a user from making X posts in an hour (note that one person cannot create multiple accounts).
  • [Bonus] A user can prove they are a doctor and post a comment on a medical issue.

4. Funding Platform

An on-chain platform where funds are distributed based on the votes of people living in the affected locality; or distributed to people that prove certain identity criteria.

Some examples:

  • Pension for people above 60 (or similar).
  • Disaster relief funds for people who prove they are from the city affected.
  • Funding pool for personal needs where distribution is based on votes from other people. This can be thought of as a real-world, localized, sybil-resistant version of Gitcoin.

5. Others

We can build more applications that make use of transparent and censorship-resistant properties of blockchains mixed with proof-of-personhood and demographic-scoping properties of real-world identity.

  • Government Reporting: Map of a country that displays the efficiency of government in each area as reported by people who live there.
  • Happiness meter: A fun app where people simply vote on how happy they are on a scale of 1-3 every day. UI can be built on this data to show distribution on a map based on locality, age and trends over time.

Real-world identity can also be used to enhance existing on-chain applications:

  • Account recovery for smart accounts like (4337).
  • Sybil resistance on DAO, airdrop claims, etc.
  • Permissioned Defi where only people from a certain country can participate.
  • As a stamp on Gitcoin passport.

We can also use the ZK proof of identity for off-chain applications where blockchain properties are not needed. Some ideas:

  • KYC without revealing full identity.
  • Spam prevention for existing Web 2.0 apps (to prevent multiple accounts, fake follows/upvotes).
  • Sign PDF documents digitally with proof of identity (maybe with proof of name).
  • As a source for Verifiable Credentials.


There are some challenges in building blockchain apps operated using ZK proof of identity.

Privacy with issuer

ZK circuit (for an issuer) needs to output a unique identifier for a person called a nullifier (along with revealed attributes). This is what applications use to ensure the uniqueness of a person.

The problem is that the circuit can only derive the nullifier from some information in the identity or signature (for example, hash(name, dob)). This means the issuer can de-anonymize the user from the nullifier (as they have access to every data).

This is an open problem and there is no direct solution to this. Some solutions:

  • Add another layer of indirection where the user joins an anonymous set (like Semaphore) with proof of identity, and then uses proof of membership in the set when taking an action in the application. This way, the issuer can only find that the user joined the "group" but not what they do in each application (eg: vote).
  • Use a private blockchain like Aztec where application states are not public.
  • Wait for modern cryptography like FHE-ZK to be practical, where we can create ZK proofs on encrypted data.


There are cases when your ID "card" is handed over to a third party - like your landlord, bank staff, etc. If they have access to the signature from your ID, they can impersonate you.

This can be solved if the digital ID has some sort of timestamp mechanism. In the case of Aadhaar, there is a timestamp indicating when it was generated (we can generate a new Aadhaar signature anytime). Some National ID and Passports even has a private key and can sign arbitrary data which can be used to sign the current timestamp.

  • Applications can demand that the timestamp on the identity should be less than a certain value.
  • Applications can overwrite the "vote" of the user with the new value if the user generates a proof with a newer timestamp.

The assumption here is that only the right owner can generate a "fresh" signature. In this case it's also important that the nullifier should not be derived from the signature.

Changes in identity

Another concern around nullifier is what happens when the identity attributes used to derive it change. We want the nullifier to be unique for a person forever.

If the nullifier is derived from something that doesn't change (like hash(name, dob)), there it introduces another problem where anyone can brute force (or dictionary attack) to de-anonymize a user.

If we use attributes with more entropy (like hash(photo) or hash(address)), then it is more probable that the **nullifier changes over time **and allows the user to "double-spend".

Potential solutions:

  • Use a high entropy value and implement the timestamp-based solution like the above.
  • Use a low entropy value, but implement the anonymous-set approach discussed above to prevent the de-anonymization of a user on their "actions".

Issuer issuing fake identities

What if the issuer issues fake identities? There is no direct way to prevent this from happening, but some ideas:

  • Applications can ask the user to show proof of identity from multiple sources. Ultimately it's up to the consuming app what attributes from which issuer(s) they trust.
  • Integrate with World ID.
  • Use social graphs in conjunction with government IDs.


What if an issuer revokes an identity that was previously issued to someone? Like when you change your citizenship or lose your residency status.

One solution would be to use the timestamp technique discussed above.


For apps where the user takes an action (like voting) on-chain with proof of identity, frontrunning is a problem. i.e. someone else can watch the mempool, take the proof generated by you, and call the smart contract with a different "vote".

To prevent this, ZK circuit needs to have additional input to capture the user's "action". i.e. every attribute that the user is committing to should be part of the proof.

ZK Proving time

This is more of a UX issue where generating ZK proofs usually takes tens of seconds or minutes. This is very slow compared to traditional Web 2.0 apps.

Research and development is happening to improve browser and mobile proving, and innovation is happening in this space very fast.

Also, the aggregated identity system (register once and then create proof of membership) explained above can solve this to some extent as proof of membership can be generated very quickly.


Bringing real-world identity on-chain can unlock many interesting applications that can solve real-world problems, and also complement existing on-chain apps.

The ZK-based identity system can also be used for off-chain use cases to build privacy-preserving apps where blockchain properties are not needed.

What we need from governments and other institutions is to issue digitally signed identity documents, which can also be used for other purposes.