PERSONHOOD CREDENTIAL · PEP

Build experiences for real, unique participants.

Give your product a trustworthy participation rule: confirm a human is behind an action, or count each participant once for a defined purpose.

THE PRODUCT PROBLEM

Accounts do not always mean meaningful participation.

A personhood rule can help answer

  • Is a human behind this action?
  • Has this participant already acted?
  • Can this workflow count a person once?

Personhood Credential complements your login, accounts, and sessions. Your product still makes every final authorization decision.

CHOOSE YOUR RULE

Ask for the proof your product actually needs.

01

Human Credential

Confirm that a human is behind an action when automation or fake participation would undermine the experience.

Sign-upPostingHuman-only access

Uniqueness is a product rule, not a requirement to expose a participant’s real-world identity.

USE CASES

Make the rule visible in the experience.

Community onboarding

Rule
A human starts the conversation
Credential
Human
Outcome
More confidence in each new voice

Voting and polling

Rule
One participant, one vote
Credential
Uniqueness
Outcome
Results that reflect people, not account volume
Explore Real Human Vote →

Limited rewards

Rule
One eligible claim per person
Credential
Uniqueness
Outcome
A fairer distribution rule

Ticketing and drops

Rule
One access opportunity per participant
Credential
Uniqueness
Outcome
Less incentive for duplicate entries

Creator and marketplace protection

Rule
Provide a name that cannot be forged for a sensitive action
Credential
Uniqueness
Outcome
A clearer trust signal for the community

Human-only AI features

Rule
A human accesses a scarce feature
Credential
Human
Outcome
A product rule beyond account creation

HOW IT WORKS

Your application stays in control.

  1. 1

    Your app requests proof

  2. 2

    The user reviews it in Credential Wallet

  3. 3

    The wallet returns a verifiable presentation

  4. 4

    Your backend verifies and applies its rule

PEP is the registration and trust layer for app policy and domains. Your app continues to own users, sessions, stored data, and authorization.

PRIVACY BY DESIGN

Ask for proof, not more data than you need.

01

User consent

Users see what your app requests before they approve it.

02

Purpose-specific requests

Match each request to a clear product rule.

03

Data minimization

Request only the attributes needed for that decision.

FOR PRODUCT TEAMS

Questions teams ask before they integrate.

Does this replace login?

No. Your app still owns accounts, sessions, and access control. Personhood Credential adds a verification signal when a product rule needs it.

Which credential should my product use?

Choose Human Credential when you need a human behind an action. Choose Uniqueness Credential when the same person must be counted only once.

What information does an application receive?

The request should be limited to the credential and attributes needed for the specific product decision. Users review the request in their wallet before approval.

Does the app receive passport data?

Not by default. Your app should request only the information it needs; a personhood check does not require a copy of passport data.

Can verification be used only for sensitive actions?

Yes. Your product determines where verification belongs, such as registration, a vote, a claim, or another protected action.

Who makes the final authorization decision?

Your backend does. It verifies the presentation and applies your application’s policy before permitting an action.

How should expiration and revocation affect our policy?

That depends on the action’s risk and your product policy. Re-check credential state before sensitive or recurring decisions.

START WITH THE RIGHT RULE

Ready to make participation more trustworthy?