Plural Passports without literally plural passports?

One of the great things about Gitcoin’s Passport vision is that passports can draw legitimacy from multiple credentials (pluralism), rather than de-duping via a single-point-of-failure such as the USA’s Social Security Number (SSN).

That said, “dual citizenship” presents a challenge if the end-user considers every “citizenship” as independently legitimate. (arguably, dual citizenship IRL is already overpowered even without this, but to a much smaller degree)

The fundamental choice is: if I have stamps from all of {PoH, Worldcoin, Idena, Bright ID, KYC, Web2}, what is the incentive for me to put all of these on the same passport, versus creating multiple passports?

The toy model I’ll assume here is:

  • There are a number of “personhood score” algorithms personhood(credential1, credential2, ..., credentialN) each developer can use.
  • Each end-user application delivers a payoff of payoff(personhood) for a given personhood score.
  • Composing these functions implies a payoff function payoff(credential1, credential2, ..., credentialN) for the application.
  • If every application has their own passport registry, one may choose a different distribution of stamps across passports per app. If every applications checks the Gitcoin registry to dedup stamps, then users must use a consistent set of passports across all apps. In the latter case, each passport has a total_payoff(credential1, credential2, ..., credentialN).
  • WLOG, we’ll just work with one payoff function.

When to split and when to merge?

If there is some partition of my set of credentials such that sum(payoff(credentials_i)) > payoff(credentials), then it is in my self-interest to maintain multiple passports along this partition.

If payoff is convex, then this will never hold, due to multivariate Jensen’s inequality (in fact, the opposite would hold - if there is someone with an orthogonal set of credentials, I should merge with them). However, personhood is explicitly meant to support concave payoffs - the problem of splitting credentials mirrors the problem of splitting tokens across wallets, in that 2x the personhood shouldn’t give 2x the payoff.

In most cases (for example, cutoff-based systems where you get the max payoff for having a sufficient number of credentials), we’ll be incentivized to split.

Cross-credential linkability?

A natural way to approach this (other than accepting only one type of credential), would be to have e.g. a Worldcoin ID linkable to a Bright ID. That way, split passports can be detected and penalized.

Not only do we need to be able to detect this link, but we should be able to detect it post-anonymization. i.e. in the following diagram, the application must be able to deduce B without knowing C or D:


There are possibly some clever cryptographic ways this could be done, but at some point someone must know A. In practice this means that information linking a face, iris, social graph, Web2 handles, etc together would be out there somewhere.

One could argue that forming this profile is both inevitable (and presents no real harm) and a necessary precondition for Sybil resistance (otherwise, how do we prevent someone from using their iris for one account and their face for another?), and it is sufficient privacy to just not link this profile to any actual activity.

Another viewpoint could be that it is unviable for communities to accept outside credentials (especially anonymized credentials) without having their own additional screens.

I’m curious to hear thoughts on these viewpoints.


This is a wonderful, well-articulated post. It triggered some late night thoughts.

I think I’m ok with people having multiple passports or identities — provided they don’t engage in Sybil behavior.

Borrowing your dual citizenship analogy: dual citizens IRL can choose which passport to use, however they can’t use their passports to be registered in two countries at once or to count as two people in one country. Once they’ve entered a country with a given passport, they can only leave by showing the same passport.

The primary issue Gitcoin cares about is stopping n sock puppets from getting match funds for funding the same project n times.

We need to learn to better detect Sybil behavior. We need to increase the price / diminish the benefit of Sybil behavior. We need to create positive network effects for reputation building behavior. Cross linking credentials could definitely be one of those ways!


One of the reasons I liked the idea of using a PersonhoodScore in this post was that it allows the system to scale against different sophistication levels of attackers, including handling dual passports elegantly.

assuming cost of forgery = personhood score, if the cost of forgery of identity 1 is $10, and the cost of forgery for identity 2 is $100, then the combined identity for these two is $110.

if you can get $10 in matching from identity 1 and $100 in matching from identity 2, or if you combined the passports + get $110 in matching, then there is no incentive to sybil attack the system.

I think this is what you already said in different words tho :slight_smile:

This might not be realistic though. For example for a voting app, would you get 2x the voting power for having 2 credentials? Even in QF I’d argue that the match amount shouldn’t equal the personhood score. For example, let’s say we updated the “legacy” trust score to be linear in personhood score. That would require removing the 150% cap, allowing me to get 250% or more in trust bonus if I used all of the verification methods. This number would only go up the more verification methods get added.

So in this system, indeed there would be no incentive to “Sybil”, but that’s because we would just be handing excess power to the user directly.

The math here is actually important. Any system with a cap or tapering will be concave. For example the spreadsheets in the post you linked (where you link to this) are concave (e.g. if the aggregate match was $100k and I was capable of getting $1m cost-of-forgery then I would want to split into 10 passports). And indeed they should be concave: in a world where there are hundreds of verification mechanisms, someone shouldn’t get double the match because they had the tenacity to sign up with 20 verification methods instead of 10 (otherwise you get farming captchas all over again).

Another point to note is that forgeries themselves are not independent events. So it’s unclear if the assumption cost_of_forgery(methods) == sum(cost_of_forgery(methods[i])) is ideal.

thats up to whomever is writing the scoring algorithm + the weight they assign to each stamp.

i dont think trustbonus scales in a personhoodscore world.

IMO cGrants is architected backwards. It makes more sense to start with the personhood score + guide the user to either increasing it or muting their contributions by computing their trustbonus.

I agree. Especially about your point about convex/concave designs. Perhaps whomever at the FDD (or similar) is designing the scoring algorithms for a grants 2.0 world can chime in from here about how those are being designed :slight_smile:

This is the spreadsheet I was referring to - at any given aggregate match amount it tapers at 100%, once I hit 100% I should start over with a new account, basically getting 100% per aggregate_match_amount in cost_of_forgery I’m able to accrue.

Agreed, very important workstream!

Oddly the FDD design space reminds me a lot of Palantir (similar skillset and probably some tech that can be taken - though their ideology couldn’t be any more different than ours)

1 Like

i agree. here is a better model

1 Like

Your post nerd-sniped inspired me to do some analysis on dual citizenship in real life.

My question: If you could have any two passports, which combination would afford you the greatest freedom to travel around the world with minimal overlap & reliance on a single passport?

The answer: Ghana & United Arab Emirates. Those passports enable visa-free travel to 131 countries, with only 14 cases of overlap.

Runner-up combos include: Andorra & Gambia, Cote d’Ivoire & Japan, Guinea & Malaysia.

(If you have a US passport, dual citizenship in Ghana or Mali would offer the most visa-tree travel optionality.)

h/t: GitHub - ilyankou/passport-index-dataset: Passport Index 2022: visa requirements for 199 countries, in .csv


With this considered, I could imagine organizations/platforms who might use Passport for sybil resistance might not use it as we imagine. Instead of computing some “trust score” as a function of all of the credentials within a passport, they choose 1 really robust/secure credential for their ecosystem. In this case, they don’t technically NEED Passport, but Passport creates a common interface for these credentials, so a platform/org does not need to research how to integrate with a specific credential’s SDK. Also, if they want to switch to a different credential, they can do that with ease without needing to deal with the different integration process of a separate credential. Also, from an end-user perspective, I can keep all of my credentials in one Passport. So if PlatformA requires BrightID and PlatformB requires KYC, then I have all of that in one place.