How Polkadot Proof of Personhood Works

In Part One, we explored why the internet increasingly needs to distinguish one person from many accounts without forcing everyone to reveal who they are. This article looks under the hood of Humanity, one personhood mechanism currently being developed and tested for Polkadot. It combines a recurring recognition game with a privacy-preserving proof layer and presents one approach to establishing personhood; the underlying architecture can support other recognition and attestation protocols over time.

What Humanity Is

Humanity is not an identity system. It is designed to credit personhood to individuals and let them prove that they represent one unique participant within a chosen context, without revealing their legal identity or presenting the same reusable identifier everywhere.

A context is a defined scope of interaction, as narrow or broad as the application requires. Within it, each recognized personhood key derives one deterministic alias. The same key produces a different alias in another context. From the aliases and cryptographic proofs alone, a verifier cannot determine whether the two aliases belong to the same participant.

At the protocol level, a context is represented by a 32-byte identifier. An application must derive that identifier consistently so that every verifier uses the same scope.

Suppose a social network derives a context from "social101.example" and requires each message to carry a proof of personhood. Alice posts "Memory, along with the twilight." Her proof is bound to both the message and the context, and it carries the alias "0x9f4c...". Alice does not choose this alias; it is derived by the proof. Bob replies with his own proof for the same context, carrying the alias "0x2ea7...".

Readers can verify that two distinct recognized personhood credentials authorized the messages. They do not learn the legal identity behind either credential from the proof. Nor does the proof establish that a human personally composed every word: a recognized participant could still use an AI agent or another tool.

When Alice posts again in the same context, the alias "0x9f4c..." reappears. The application can therefore treat it as one stable participant within that context, although whether it becomes an account, entitlement, or reputation record is an application-level decision.

If Alice later uses a second social network with a different context, the same key derives a different alias, such as "0xc013...". From the proofs alone, observers cannot link it to "0x9f4c...". That is the core primitive: a recognized participant can use one stable alias within a context and a different alias elsewhere, without exposing the underlying membership key.

This simple property creates a wide range of possible applications.

What it Makes Possible

Consider an online game that bans a cheater. Today the ban usually lands on an account, email address, or device. The player may return with a replacement, while every honest participant is asked to provide an expensive anchor, perhaps a phone number, a locked-down device, or a legal identity so that the game has something meaningful to revoke.

Humanity allows the game to define its own context, or participate in one shared with other games, and attach the sanction to the stable alias used there. Creating a new application account would no longer be enough to evade the ban. This does not make evasion impossible, keys can be compromised, and credentials can be misused, but it can raise the cost without requiring every honest player to reveal a legal identity.

Another use case is rate limiting. A website may offer a free tier to everyone while preventing one participant from generating an unlimited number of requests. Existing approaches often impose a CAPTCHA, rely on IP addresses, or require an account with an identity provider.

With Humanity, the website can define an access context and limit each alias in that context to, for example, one thousand requests per day. Verifying a Ring-VRF proof is more expensive than checking a conventional signature: in the benchmark described later, one proof takes about 5 ms to validate. One optimization in the current design is to associate an sr25519 public key with the alias during the first interaction, then use ordinary signatures for subsequent requests.

That design creates a privacy trade-off: all one thousand requests are associated with the same alias. An application that does not need that linkability could instead define one thousand single-use contexts per day and permit one request per alias in each context. The participant selects a context they have not yet used. This preserves the daily limit while preventing the proofs themselves from linking the requests, at the cost of generating and verifying a new proof each time.

The single-use-context design cannot rely on the same long-lived sr25519 association, but proofs can be validated in batches. Batch validation lowers the average cost but returns a result for the batch as a whole. A service can therefore validate optimistically under normal load and fall back to checking proofs individually when a batch fails. This is an operational trade-off: an attacker may deliberately force that slower path during a spam event.

A project could also use a context to offer one allocation per recognized personhood credential, rather than one allocation per account. Referral programs could similarly distinguish a new recognized participant from another account controlled through the same credential.

Some communities may also want a form of governance in which each recognized participant can vote once on a proposal, while votes remain unlinkable across proposals. The application can assign one context to each proposal. Alice votes in favor of proposal A under the alias "0x71ad...". Because the alias is deterministic within that proposal's context, the system can reject a second vote from the same personhood key.

Alice can then vote on proposal B under the different alias "0x3ec6...". The two proofs do not reveal that the same membership key produced both aliases. This prevents the cryptographic voting record itself from accumulating into a cross-proposal profile, although coercion, vote buying, and metadata correlation remain separate application and governance problems.

What Humanity Does not Prove

Humanity does not prove that a human personally authored a message, that no automation was used, or that a participant has a particular legal identity, age, nationality, or eligibility status. It also does not make credentials impossible to share, sell, steal, or lose.

Humanity is a building block rather than a complete trust or identity system, as applications can combine it with additional mechanisms, such as reputation or honor systems, credentials, attestations, and eligibility checks, depending on what they need.

Ring-VRF protects the relationship between aliases at the cryptographic layer; applications must still consider network metadata, behavioral correlation, key recovery, revocation, and abuse of valid credentials.

How it Works

Humanity separates two engineering problems. First, a recurring recognition mechanism attempts to build an on-chain set in which each membership entry corresponds to a distinct person.

Second, a Ring-VRF allows the controller of one of those membership keys to prove membership and derive one alias per context without revealing which key they control. The cryptography proves membership in the set; the recognition mechanism is responsible for making the set credibly represent unique people.

Building a Recognized Set

In the current design, a participant can use supported mobile-platform attestation signals as an initial anti-spam barrier, or register by placing a deposit. These signals do not prove the existence of a globally unique physical device; they provide evidence about an application and device environment. Their role is to make mass registration more costly before the recognition game begins. Registration routes may evolve independently of the later proof layer.

The recognition game runs at one scheduled moment each week. Participants are randomly assigned to groups of six and play two rounds with different co-players. In each round, every participant takes a turn as master, inventing a gesture for the other five to follow. The unexpected gesture provides a live interaction that is harder to pre-record. Participants approve or reject each co-player, allowing a player to collect up to ten attestations in a week.

Simultaneity is intended to turn these attestations into evidence of distinctness rather than merely evidence of liveness. A participant attempting to maintain several registrations may be placed in different groups and asked to respond to different unpredictable interactions at the same time. The mechanism does not make duplication mathematically impossible, but it is designed to increase the operational cost and difficulty of sustaining several convincing participants.

Attestations are weighted according to whether the attester is already recognized by the system. Under the current rules, a participant is recorded as having attended when weighted approvals exceed rejections. A round with no votes either way can also count as attendance when no other player appears. That unusual edge case relies on the wider scoring and participation rules rather than one round alone, and it should be evaluated as part of the system's security model.

One weekly result is only a single data point. Recognition accumulates over time through a score and a streak. Attendance increases the positive streak and adds that value to the score. Non-attendance starts or extends a negative streak and subtracts its magnitude. A threshold determines when a membership entry becomes recognized as personhood by the system.

For example, a participant who attends three games, misses one, and then attends two more moves through streak values of 1, 2, 3, -1, 1 and 2. Their score moves through 1, 3, 6, 5, 6 and 8. The score is capped at the recognition threshold, and an increase in that threshold does not by itself suspend an existing recognized participant.

Recognition is suspended only after the participant exceeds the permitted absence allowance---for example, where one missed game in five is tolerated. In the current design, both the threshold and the grace allowance become stricter as the recognized set grows.

Accumulation is designed to require repeated evidence over time, resist rapid capture of the recognized set and allow honest participants to recover from occasional absence. Collusion remains possible. How costly or successful it is depends on participation levels, group assignment, attestation weights, thresholds, deposits and the proportion of attackers in the population.

Random group assignment reduces an attacker's ability to choose their co-players. Reaching the threshold requires repeated results over multiple games, so a coordinated attack must continue over time. Each additional registration also requires another accepted device environment or deposit. These mechanisms increase attack cost, but their strength should be supported by parameter analysis, simulation, and adversarial testing.

The current design also requires participants to establish peer-to-peer connections. During setup, they use collator-provided services such as the statement store to exchange their initial connection offers.

The live interaction then takes place over those peer-to-peer connections. At the end of the game, participants report attestations on-chain, where attendance, scores, and recognition status are updated. The result is a public set of registered membership keys that the protocol treats as recognized participants.

Proving Membership Without Revealing the Key

The resulting membership set is public: it contains the registered keys that have reached recognition under the current rules. A participant could sign directly with that key, but doing so would reveal which member acted and link every action to the same public key. Humanity therefore uses the Bandersnatch Ring-VRF primitive to prove membership without disclosing the member key.

Bandersnatch Ring-VRF public keys are grouped into rings. In the current implementation, a ring contains up to 255 keys. If 1,000 membership keys have reached recognition, they would therefore be distributed across three full rings of 255 keys and one ring of 235.

For a given context, each Ring-VRF key derives one deterministic alias from the key and the context. The key holder can generate a proof showing that the alias belongs to some key in an accepted ring and that this key authorized a particular message, without revealing which ring member produced it. Alice registers her Bandersnatch Ring-VRF key after reaching the recognition threshold.

Alice can then generate a proof for the social-network context and the message "The white moon / Gleams in the woods." The proof carries the alias "0x9f4c..." and references ring number 2. A verifier can confirm that the alias was derived for that context from a key in the ring and that the same hidden key authorized the message. At the cryptographic layer, the verifier learns only that the signer is one of the members of that ring.

The current anonymity layer still has important limitations. Suspension can leak information: if an alias disappears at the same time that only one membership key is suspended, an observer may infer a connection. A returning participant may also be assigned to a different ring, causing their existing aliases to produce proofs against a new anonymity set.

Comparing the membership of the old and new rings may then narrow---or in some cases reveal---which key corresponds to an alias. Larger rings are being explored to reduce this leakage, but the final anonymity properties will depend on the resulting design, ring-update behavior, and the metadata visible to applications.

Illustrative measurements on an 11th-generation Intel i7-1165G7 report proof generation at approximately 100 ms and individual validation at approximately 5 ms. A batch of 128 proofs validates in about 230 ms, or roughly 1.8 ms per proof. These results are based on a ring size of 255 using the verifiable library at commit 1f9f675. The benchmark implementations can be found at https://github.com/gui1117/crypto-benchmarks

What This Primitive Offers  

Humanity combines two distinct components: a recurring game intended to build a credible set of recognized participants, and a Ring-VRF layer that lets members of that set act through stable, context-specific aliases without disclosing their public membership key. The weekly game is one possible route into that proof layer, not the only personhood or attestation protocol Polkadot could support.

The mechanism does not eliminate bots, fraud, or the need for identity checks where legal identity genuinely matters. It offers a narrower primitive: applications can make one-per-person rules more credible while collecting less identifying information and reducing the creation of a permanent profile across services.