(I initially posted this as a HIP, but after further thought I’m not sure it’s the right direction to go, so I removed the HIP tag. I’ll still leave it up as a jumping-off point for feedback/brainstorming.)
Allow each project that depends on Proof of Humanity to decide for itself how large a challenge deposit/number of vouches it requires from users to count as “authenticated” for its specific use case.
Right now, Proof of Humanity’s “public API” is a simple function
isRegistered(address), which consuming projects can use to determine whether a specific address is registered with Proof of Humanity or not. Since this function just returns a binary true/false, all Proof of Humanity registrations are held to the same standard.
This proposal would add a new function to the public API
meetsThreshold(address, minDeposit, minVouches). This function would allow projects where the cost of fraud is high to require registrants to meet stricter requirements, such as a larger challenge deposit or more community vouches. It would also allow projects where the cost of fraud is low (eg some NFT/token drops) to relax the PoH registration requirements for their users, instead prioritizing ease of use.
There will always be some tension between the ease of onboarding with Proof of Humanity and the difficulty of creating a fraudulent account. Adding more onboarding requirements makes it harder to slip a fake account through, but also inconveniences legitimate users and could cause some projects not to adopt PoH out of concern for our impact on their signup funnel.
The right way to balance that tradeoff isn’t obvious a priori—that’s why parameters like
submissionBaseDeposit were made tune-able. But the right tradeoff also depends on the damage a fraudulent account can do. And that number varies significantly depending on the use case.
For example, an artist who’s minting 1,000 low-value NFTs and wants to limit orders to one per customer might prefer making signup for her users super easy, even at the cost of many fraudulent accounts getting through. She could require a very small deposit and no vouches. At the other extreme, Gitcoin may care very deeply about avoiding fraud when assigning its matching grants, and thus require each user to have 5 vouches to qualify for the maximum match.
There’s another good reason to let users easily sign up for a “basic” PoH profile with a minimal (or no) deposit. Right now, PoH isn’t a widely-known protocol, and community trust and understanding will inevitably be low. Lowering the requirements for signing up with a basic profile allows users to “get their feet wet” before committing to a larger deposit and earning a higher-trust account.
I’m happy to brainstorm more specifics in this thread, or if there’s broad consensus that this is a useful change I can write up a more formal HIP. A few important implementation details up front, though:
- Registrants can earn a higher
minDepositnumber at any time by putting up a new, larger deposit. At the end of a 3-day challenge window, they can withdraw the collateral and their registration is assigned the higher
minDepositnumber also resets to 0 one year after they last posted a deposit, requiring a renewal to stay current.
- Only accounts that have made a
minDepositlarge enough to attract potential challenges should be allowed to vouch. This cutoff can be determined by the
- For backwards compatibility, the
isRegisteredfunction should be modified to return
falsefor newly-registered addresses that don’t match the current