Does digital ID have risks even if it's ZK-wrapped?

2025 Jun 28 See all posts


Does digital ID have risks even if it's ZK-wrapped?

Special thanks to Balvi volunteers, Silviculture members and World team members for discussion.

The use of zero-knowledge proofs to protect privacy in digital ID systems is now becoming at least somewhat mainstream. Various ZK-passport projects are creating very user-friendly software packages that use zero-knowledge proofs to prove that a user has a valid ID without revealing any details of their ID. World ID (formerly Worldcoin), which uses biometrics for verification and zero knowledge proofs for privacy, recently passed 10 million users. A Taiwan government project for digital ID uses zero knowledge proofs, and EU digital ID work is also increasingly taking zero knowledge proofs seriously.

On the surface, widespread adoption of ZK-wrapped digital ID seems like it would be a great victory for d/acc, protecting our social media, voting, and all kinds of internet services against manipulation from sybils and bots, all without compromising on privacy. But is it that simple, or does ZK-wrapped ID still have risks? This post will make the following argument:

How ZK-wrapped identity works

Imagine that you've scanned your eyeballs to get a World ID. Or perhaps, you scanned your passport with your phone's NFC reader to get a ZK-passport-based ID. For the purposes of the arguments made in this post, the two have the same properties (barring a few edge cases like multiple citizenships).

On your phone, you have a secret value, s. In the onchain global registry, there is a public hash, H(s). To log into an application, you generate an application-specific user ID, H(s, app_name) , and you use a zero-knowledge proof to prove that this ID comes from the same s as one of the public hashes in the registry. Hence, for each public hash, you can only generate one ID for each application, but it is never revealed which application-specific ID corresponds to which public hash.



In reality, the design can be somewhat more complex. In World ID, the app-specific ID is actually a hash that takes in the application ID and a session ID. Hence, different actions within the same app can also be unlinked from each other. A ZK-passport-based design can be built in a similar way.

Before we get into the downsides of this type of identity, it's first important to appreciate the upsides that it offers. Outside of the very small world of ZKID, in order to authenticate yourself to a service that requires ID, you need to actually reveal your legal identity. This is a gross violation of the common computer-security principle of least privilege: a process should only get the least authority and information required to accomplish its task. They need a proof that you're not a bot, or are over 18, or are from a particular country; they get a pointer to your entire identity.

The best that we get as an improvement is indirect tokens like phone numbers or credit card numbers, where the actor knowing the link between your phone or credit card number and your activity (the app), and the actor knowing the link between your phone or credit card number and your legal identity (the company or bank) are separate. But even this separation is very tenuous: phone numbers get leaked all the time, as does everything else.

With ZK-wrapping, these problems to a large extent go away. Now, let's get to what has so far been less discussed: the remaining problems that do not go away, and in fact may even get worse specifically because of the stronger one-per-person restriction of these schemes.

ZK on its own does not enable pseudonymity

Suppose that a ZK-identity platform works exactly as intended, faithfully replicating all the logic above, and we even figure out how to keep user secrets safe for the long term, for non-technically-proficient users, without trusting centralized authorities. But at the same time, let us make the realistic assumption that applications will not be cooperative; they will be "pragmatic", pursuing design choices that are justified as maximizing user convenience but that always seem to lean toward their political and business interests.

In this world, social media apps will not use some fancy design involving frequently rotating session keys. Instead, they will just use one app-specific ID for each user - and because the ID system is one-per-person, each user will only be able to have one account (as opposed to "weak ID" like eg. Google accounts today, where it's reasonably feasible for an average person to get ~5 accounts). In the real world, pseudonymity generally requires having multiple accounts: one for your "regular identity" and others for any pseudonymous identities (see "finsta and rinsta"). Hence, the practical level of pseudonymity that you get is plausibly lower than today's status quo, and so under one-per-person ID, even if ZK-wrapped, we risk coming closer to a world where all of your activity must de-facto be under a single public identity. In a world of growing risk (eg. drones), taking away the option for people to protect themselves through pseudonymity has significant downsides.

ZK on its own does not protect you from coercion

If you do not publish your secret s , no one can see the public link between your various accounts. But what if someone does? A government could force someone to reveal their secret, so that they can see their entire activity. This is not theoretical: the US government is already starting to require visa applicants to make their social media accounts public. Additionally, employers can easily make revealing your full public profile a condition of employment. Even individual applications could technically require revealing your identities on other applications as a condition of joining (in fact, "Sign In With [app]" does this by default).



Again, in these situations, the value of the ZK property falls away, but the downside of the new "one account per person" property remains.

It is possible to design these schemes to make coercion more difficult: for example, you could use a multi-party computation to generate each app-specific ID, involving the user and the service. This would make it impossible for a user to prove their app-specific ID for a particular application without the application operator's participation. This raises the difficulty of demanding that someone reveal their entire identity - but it does not eliminate the possibility, and such schemes have other downsides, eg. requiring the application developer to be a live entity instead of something like a passive onchain smart contract.

ZK on its own does not solve non-privacy risks, like errors

All forms of ID have edge cases:

These edge cases are most harmful in the case of systems that try to maintain a one-per-person property, and they have nothing to do with privacy; hence, ZK does not help.

Proof of wealth for anti-sybil is insufficient; hence, we need some kind of identity

Among the purist cypherpunks, a common proposed alternative to attempting any kind of identity system is to rely entirely on proof-of-wealth as anti-sybil. You can prevent someone from easily creating a huge number of accounts, by making each account cost some amount of money. This has precedent on the internet; for example, the Somethingawful forum required a one-time fee of $10 to create an account, which would be forfeited if you get banned - though this was not truly cryptoeconomic in practice, because the hardest part of creating a new account is not replacing the $10, it's getting a new credit card.

Potentially, you can even make the payments conditional: to get an account, you only put the funds up at stake, and lose the funds in the rare case that you get banned. This theoretically makes it possible to raise the stakes much higher.

This can work well in many types of situations. But there are some classes of situations where this kind of approach does not work at all. I will talk about two primary classes, which I will describe as "UBI-like" and "governance-like".

The need for identity in UBI-like situations

By a UBI-like situation, I mean a situation where there is value in giving a very wide (ideally universal) set of users some quantity of assets or services, regardless of their ability to pay. Worldcoin does this systematically: anyone with a World ID gets a small but regular ongoing supply of WLD tokens. Plenty of token airdrops have done this in a more informal way, trying to get at least a few of their tokens in the hands of as many of their users as possible.

Personally, I do not expect such tokens to be worth anywhere close to enough to pay for a person's subsistence. In a 1000x richer AI-powered economy, they could be, but in such a world government-run programs backed by natural resource wealth if nothing else would continue to be much more economically meaningful. Rather, I think the realistic problem that such mini-UBIs solve is giving people access to a sufficient quantity of cryptocurrency to make a few basic onchain transactions and online purchases. This could include things like:

If cryptocurrency is very widely adopted worldwide, this stops being a problem. But while cryptocurrency is not very widely adopted worldwide, this can be a lifeline for people to gain access to onchain non-financial apps and to online goods and services that would otherwise not be accessible at all.

There is also another way to accomplish a similar thing: "universal basic services". Give each person with an identity the ability to send a limited number of free transactions within a particular application. This approach is potentially more incentive-aligned and capital-efficient, because it can be done by each application that benefits from such adoption, without needing to pay for non-users, though this comes with the tradeoff of being less universal (users only get guaranteed access to participating applications). But here too, you need an identity solution to protect the system from spam, without the exclusionary nature of requiring payment via a payment method that perhaps not everyone has access to.

A final important category to highlight is the "universal basic security deposit". One of the functions of identity is to have something that can be targeted for punishment, without requiring the user to put up an amount of capital at stake equal to the size of the incentive. This also serves the goal of making participation less contingent on how much capital you have (or the need to have any capital at all).

The need for identity in governance-like situations

Consider the case of a voting system (eg. likes and retweets on a social media platform). If user A has 10x the resources of user B, then they have 10x the voting power. But each unit of voting power benefits user A 10x more (in economic terms) than it benefits user B (because A is bigger, and so A gains or loses more in economic terms from everything). Hence, in total, A's vote benefits A 100x more than B's vote benefits B. For this reason, we would expect A to put far more effort into showing up to vote, determining how to vote to maximize their goals, and perhaps even being strategic in manipulating algorithms. This is the basic reason why whales in coin voting schemes have an outsized effect.



Here is a more general, deeper reason why a governance system would not want to give equal weight to $100,000 controlled by one person and $100,000 split between 1,000 people: the $100,000 split between 1,000 people represents 1,000 different people, and so it's more likely to incorporate a higher volume of valuable information, as opposed to a smaller volume of information blasted at high volume. The signal from 1,000 different people is also likely to come more "muted", because its different component signals from the different people will often cancel each other out.



This applies both to formal voting systems, and also to "informal voting systems", such as people's ability to participate in the evolution of the culture by making public statements.

What this shows is that a governance-like system would not truly be satisfied with treating each equal-sized bundle of dollars the same regardless of provenance. The system has an interest in knowing the internal coordination level of the bundle of dollars.

Notice that if you accept the frame that I use to describe both cases (UBI-like and governance-like), then technically the explicit need for any kind of one-person-one-vote falls away.

Identity is still very useful in both cases - but the requirement for it to follow any kind of strict one-per-person rule is no longer there.

The theoretical ideal is N identities at a cost of N²

From the above arguments, we can see that there are two pressures that bound from opposite ends the desired difficulty of acquiring multiple identities in an identity system:

Taking these arguments together, we want it to be as easy as possible to get multiple identities, subject to the constraints of (i) limiting the power of large-scale actors in governance-like applications, (ii) limiting the ability to exploit UBI-like applications.

If we draw directly from the mathematical models for governance-like applications in the previous section, then we get a very clean answer: if having N identities gives you N² power, then the cost of getting N identities should be N². And, it just so happens, this is a satisfactory answer for UBI-like applications as well.


Long-time readers of this blog may notice that this looks exactly like the chart from an earlier post on quadratic funding. This is not a coincidence.


Pluralistic identity accommodates this ideal

By "pluralistic identity", I mean an identity regime where there is no single dominant issuing authority, whether that's a person, or an institution, or a platform. This can be accomplished in two ways:


A recent snapshot of the Circles identity graph. Circles is one of the largest live running social-graph-based identity projects.


Explicit pluralistic identity naturally bakes in the capacity for pseudonymity: you can have a pseudonymous identity (or even multiple), and each of those identities can build up reputation in their communities through their actions. An ideal explicit pluralistic identity system may not even need to have the concept of discrete identities; rather, you might have an amorphous cloud of your provable past actions, and prove different parts of it in a fine-grained way as needed for each action.

Zero-knowledge proofs will make pseudonymity easier, because you can use your primary identity to bootstrap a pseudonym, by privately providing the first signal that the new pseudonym should be taken seriously (eg. ZK-proving ownership of some quantity of coins to post from anon.world, or perhaps one can ZK-prove some claim about what kind of Twitter followers one has). There may well be even more effective ways of using zero-knowledge proofs.

Implicit pluralistic identity has a "cost curve" which is steeper than quadratic, but still has most of the right properties. Most people have some of the forms of ID that I've listed in this post, but not all. You can get one more form of ID with some effort, and the more forms of ID you get, the less favorable the benefit/cost ratio of getting the next one. Hence, it provides the needed brake on governance attacks and other abuse, while still ensuring that there is no fixed set of IDs that a coercer can demand, and reasonably expect, you to reveal.

Any form of pluralistic identity (implicit or explicit) is naturally more error-tolerant: someone with disfigured hands or eyes would still likely have a passport, and a stateless person would still likely have access to some non-state way of proving that they are a person.

Note that these properties break if any one form of ID gets close to 100% market share, and it becomes realistic to demand it as a sole login option. This to me is the biggest risk that could come from identity systems that try too hard to be "universal": if their market share gets too close to 100%, they shift the world from the pluralistic identity to a one-per-person model, which has worse properties for the reasons I described in this post.

In my view, the ideal outcome of "one-per-person" identity projects that exist today is if they were to merge with social-graph-based identity. The largest problem that social-graph-based identity projects have is scaling to a very large number of users. One-per-person identity systems could be used to bootstrap social graphs, creating millions of "seeds", at which point there would be enough adoption to safely grow a globally distributed social graph from that point forward.