Since the minting of the first Non Fungible Token (NFT) in 2014 we have seen increased interest in their capabilities as unique, one-of-kind digital “deeds of ownership” representing assets such as artwork, music, collectibles and more. In May of 2022 we saw the release of the paper “Decentralized Society: Finding Web3's Soul” which raised the concept of a Soulbound Tokens (Non Transferable Non Fungible Tokens), generating a spirited conversation on the concept of using NFTs for identity applications.
Since then we have seen increased interest and development of a new class of NFTs based around components of a user’s identity, which I call “Identity Tokens”. Within Identity Tokens we see two distinct subclasses emerging. The first is the “KYC/KYB Token”, which involves a 3rd party providing an assertion about someone’s real-world identity on-chain - without disclosing the “core facts” of that identity themselves. The second is a “Badge Token”, which straightforwardly makes claims about the user’s actions, history, or reputation, or those of their Web3 “persona”. While both of these sub classes of tokens might technically be very similar, the key difference, as explored below, is that KYC/KYB Tokens are strongly controlled by their issuer and have a very specific identity proofing application. Badge Tokens on the other hand may be 3rd party or even self issued, and usage of the token is much more controlled and directed by the user for a broad wide range of public identity applications.
Within the Web3 ecosystem we are seeing many dApps hitting the limitations imposed by user anonymity. For example DAOs are unable to determine if participants are genuine humans, collectives of interchangeable gig workers, or bots. AirDrops are flooded with fake users trying to game the allocation and distribution mechanisms. Defi is under threat by regulators who are looking to clamp down on money laundering and sanctions violations. The honeymoon of on-chain anonymity and real-world economics is over.
As a result we are seeing a growing group of identity companies looking to provide real-world PII custodian services using what we are calling KYC/KYB tokens. In general the model around KYC tokens starts with a user going to a service and undergoing a process to validate their real-world identity. Often this will take the form of scanning the back and front of a recognized government ID, and then a liveness detection that tries to ensure the human presenting the ID matches the face on the ID itself. After confirmation of the identity document the company may perform further checks to validate the user’s country of residence, ensure they are not on a sanctions list for a given country, etc. After the identity checks are complete, the user will confirm they control a crypto account, and then the identity company will issue a non-transferable non-fungible identity token (KYC Token) to the otherwise pseudonymous account they control. The KYC Token does not contain any of the user’s PII; instead, the token itself symbolizes that the user went through the identity proofing process of the issuing Identity company. The Identity company might also make further claims available through a Smart Contract or additional on-chain storage, a just-in-time API, an off-chain identity wallet etc. The identity company may also monitor components of the user’s identity, such as presence on one or more sanctions lists or law-enforcement/AML watchlists, and assume SLA-style responsibility for proactive actions such as burning the KYC Token or modifying its associated metadata if the user’s status changes. The process would be similar for KYB Tokens but with an onboarding process tailored to validating the business identity, and monitoring representative control.
KYC / KYB Tokens have some interesting characteristics for many Web3 identity applications. Let’s use a few KYC Token user stories to illustrate their potential uses. Across all three stories, we have a user Alice. Alice has signed up for the services of a company called AcmeKYC. She has submitted a government-issued identity document which was approved. AcmeKYC then issued a KYC Token mapped to Alice’s account.
KYC Token User Story 1: DAOs
Alice wants to join a DAO. She submits to join using her crypto account. Before allowing her to join, the DAO wants to know if Alice is a real person or a bot. The DAO discovers that the crypto account has a KYC token issued by AcmeKYC. The DAO doesn’t know anything about Alice herself, but by the presence of the token they know that the controller of this crypto account must have passed AcmeKYC’s identity proofing process - and is therefore more than likely a real person, and they allow her entry to the DAO. If AcmeKYC’s policies and supported jurisdictions are public, the DAO can deduce at a minimum that Alice used an identity document that fit within these policies.
KYC Token User Story 2: DeFi LIquidity Pool
Alice wants to participate in a DeFi Liquidity Pool. The Pool’s operators don’t want to get on the wrong side of the U.S. Department of Treasury, so they require that all participants in the exchange are not on a US sanctions list, and are not domiciled in a US-sanctioned country (Iran, N Korea, Cuba etc.). Alice applies to join with her crypto account. The Pool operators see that Alice has an AcmeKYC token and they call AcmeKYC’s governing smart contract to ensure that the owner of the crypto account is not currently on a US sanctions list and has shown residence in one of the 188 countries not on the current US sanctions list (but not disclosing the country of residence itself). The Pool’s operators confirm these details and Alice’s crypto address is added to an allow list to enable interaction with their smart contract, where she deposits some capital and receives dividends daily. The Pool’s operators perform a daily check to ensure Alice still has the AcmeKYC token. One day, Alice’s name appears on a US Sanctions list. AcmeKYC, who monitors the lists, notices the addition and burns Alice’s KYC token. The Pool Operator notices the token has been burned and remove’s Alice’s name from the allow list for their smart contract, disallowing her from withdrawing the funds she’s deposited or collecting dividends until or unless she returns to permissible status according to the Pool Operator’s regulatory obligations.
KYC Token User Story 3: Travel Rule
Ajay wants to transfer $10000 worth of crypto from his custodial crypto account to Alice’s crypto account - given the jurisdictions where Ajay and Alice are domiciled, the so-called “travel rule” for mutual authentication in international value transfers will apply. Ajay sees that Alice has an AcmeKYC token. Ajay pings the AcmeKYC smart contract and sees that Alice’s account uses the OpenVASP travel rule protocol. Ajay’s VASP does the necessary travel rule due diligence over the mutually-supported OpenVASP protocol. After both parties have the appropriate information to file to their respective regulators, Ajay’s custodian proceeds with the transaction to Alice’s crypto account.
KYC Token User Story 4: Gaming
Alice wants to join an online multi-player game that is restricted to users over 18 years of age regardless of jurisdiction. The gaming operator sees that Alice’s crypto account has a KYC Token issued by AcmeKYC.The Game operator pings the AcmeKYC smart contract that responds that the account owner has proven they are over 18. Alice is able to join the game.
The other wide-spread pattern in Identity Tokens is the “Badge Token”. To understand Badge Tokens, it's helpful to look at an older and widely-used identity standard called “Open Badges”. Open Badges are web-crawler/big-data-friend data objects originally designed to be hosted on Web1 or even Web2 websites. In their most popular format, Open Badges are icons or symbols that link to an authoritative human-readable form on an associated public webpage. Users thus link to these public webpages from their social media feeds, in a resume, from emails, etc. Anyone with the link can go to the webpage and see whatever info the user wants to proclaim about themselves, whether it be a serious professional certificate or something fun like an online gaming tournament trophy.
Badge Tokens therefore take the concept and spirit of Open Badges - and tokenize them for web3’s wallet-based identity systems (and for chain indexers and blockchain analytics engines, rather than search-engine crawlers, to find and aggregate). Instead of web pages, the users receive Badge Tokens (non transferable non fungible tokens) with associated metadata such as images or descriptions; like art or music NFTs, these are typically hosted “offchain” on decentralized storage media such as IPFS or at least on a cheaper, storage-focused chain like Arweave or Filecoin. Users can then display their Badge Tokens for the world to see as a public expression of their identity.
Let’s take a look at some potential use cases for Badge Tokens, in which an end-user Ivan controls a crypto account.
Badge Token User Story 1: Attendance
Ivan attends Devcon 2023 and receives a Badge Token. The next year, for Devcon 2024, when he connects his wallet to sign up, the Devcon website queries to see which Devcon Attendance Tokens are held by that address, and he automatically receives a discount. The same website might also check if he received any Trophy Tokens for winning hackathon tracks last year, or is a member of any developer DAOs hosting networking events he should know about!
Badge Token User Story 2: Accomplishment
Ivan does a course on Solidity Security and receives a Badge Token which he displays in his otherwise pseudonymous Gitcoin profile so that he will stand out among other applicants when applying to competitive bounties.
Badge Token User Story 3: Reputation
Ivan participates in a DAO and receives an award for outstanding contributions as a Badge Token. Ivan joins another DAO and displays his Badge Token to get some instant street cred as a participant of value.
The vision of Soulbound tokens is visionary, expansive, and controversial. The name “Soulbound” entices excitement and groans in most conversations. I would argue that there are a few reasons why neither kind of Identity Token described above realizes the Soulbound Token vision as it has been articulated:
There is a limited number of ways available to strongly and immutably connect an NFT to a natural person. Available options might include ingraining a person's biometrics or a high value identifier (i.e. passport #) into the Token’s data but these approaches come with privacy challenges, and at a minimum are best supported through decentralized offchain identity architectures like those proposed by the Verifiable Credentials community. So if the data is not strongly tied to your natural person, what we are really left with is that you as a natural person have friends, family, acquaintances that strongly associate your crypto account with your natural person, and that crypto account in turn has data in the form of NFTs associated with it. However in today's environment, for most users their crypto accounts are not strongly associated with their natural persons and are trivially easy to share or sell. Furthermore, to maintain a minimum level of on-chain privacy and pseudonymity, many people prefer to have multiple long-term crypto accounts on top of countless transient accounts (often custodial) in an attempt to disassociate their on-chain transactions from their person or at least create “plausible deniability” as to their dissociation. Identity Tokens therefore inhabit a grey area between total anonymity, and crypto accounts being strongly associated with an individual user.
A key requirement of Soulbound tokens is support for Social Recovery. There is some early work on Social Recovery standards (check out the DeRec proposal by Swirlds Labs) but nothing mature and widely adopted as of yet at the protocol level, or even at the smart contract/standardized-interface level.
The more expansive features of the DeSoc vision of Soulbound tokens would need to support the disclosure of PII on-chain, whether through zero-knowledge proofs, trusted intermediaries, account abstraction, and/or some other mechanism. In the current environment it is generally accepted that direct PII should be kept off-chain from a privacy and regulatory perspective. Probably the closest path we have to supporting PII on-chain is the development of off-chain wallets and architectures that hold PII as credentials that can present zero knowledge proofs (ZKP) on-chain, or exchange of credentials between parties through entirely off-chain architectures such as Verifiable Credentials. The potential connection between data held in these off-chain wallets and a “soulbound token” still needs to be defined.
So the simple response on why we are calling these non-transferrable NFTs “Identity Tokens” and not “Soulbound tokens” is because the ecosystem is not ready for Soulbound tokens as they have been defined to date by their proponents.
The use of identity tokens raises a number of questions that need continued exploration:
Privacy
As explored in this article, putting PII on-chain is a compliance gray zone that carries potential risks for all involved. That said, even if you are not putting direct PII on-chain there remains concerns about liabilities incurred by creating even potential future correlation between any on-chain data and a natural person; whoever puts PII information into immutable public storage is thus holding an immutable, open-ended liability as long as that information is persisted and accessible to anyone who uses it.
However I feel it helps to start by grounding this conversation with some perspective on real-world conditions. If you’re using a crypto account there are already probably some linkages between the account and its associated data to your natural person. This might be because you have made this association known to others (by “proving control” through publishing a signature on twitter, for example), or because blockchain analytic providers like Chain Analysis or TRM Labs can figure it out with enough off-chain and on-chain data sources. There are also little-publicized data crumbs left by today’s web3 stack, such as major node RPC providers like infura logging IP addresses, front-ends fingerprinting in-browser wallets for their own analytics purposes, and native wallets creating mountains of interceptable and analyzable traffic through non-standardized transports.
As Web3 applications start to apply more regulation to their users, many of these leakages will be cross-referenced and aggregated to profile and fingerprint web3 traffic inferentially and retroactively. Let’s say you control a crypto account and want to interact with a DeFi protocol that only allows use by US residents. You sign up for their service and prove you’re a US resident in the most privacy preserving off-chain method possible. You then start interacting with the service using your crypto account. By simply looking at on-chain data, and through the understanding that all accounts that interact with that service must have proven US residence, anyone can then infer that your otherwise anonymous wallet address is controlled by a US resident.
In summary, correlation is always a challenging and systemic problem when we are dealing with Public Networks, and a very grey zone in regulations that were never designed to address blockchain architectures or other pseudonymous public records. Identity Tokens must try to find a balance between benefits such as discoverability and usability without disclosing information not otherwise available that will furnish future scammers and spammers with additional “freebie” data points for connecting accounts to natural persons.
Black Market Identity Fraud
Even though Identity tokens are expressly non-transferable, there is always the concern that someone could obtain a KYC Token and then sell the private key and associated blockchain account to a malicious actor. This is not an identity token problem, it is a blockchain wallet problem, or more precisely a problem any time you make private key knowledge coterminous with asset ownership. KYC Token providers are aware of this issue, and looking at numerous piecemeal mitigations such as only issuing a single KYC Token to a single blockchain account per identity proofing event. In our physical world the high natural barrier that prevents you from selling your passport or driver's license to someone, beyond it being against the law, is that you’re afraid that the purchaser will do something illegal with it and it will come back to bite you. This same barrier does exist in the Web3 space in that if you sell your KYC token you risk that purchaser will do something illegal with it and you will end up on a sanctions list or in trouble with the law. At the end of the day, just as desperate people sell their passports, we can acknowledge that without the correct controls and disincentives people could sell their KYC Tokens– and in the short term, there will remain far weaker consequences or countermeasures preventing it.
Conforming to the Letter of the Law
We think Identity Tokens such as KYC Tokens are a good step in providing Web3 dApps the tools they need to move towards better compliance with KYC and AML regulation. That being said, we fully acknowledge that for a company such as a VASP to be in full compliance with most countries' regulations, they would need a lot more information about the user to meet their due diligence and record retention requirements.
The question for us then is not whether Identity Tokens can 100% meet the requirements of local laws and regulations, but rather whether they facilitate web3 organizations taking reasonable and good-faith “first steps” towards compliance in an evolving framework rewarding good-faith efforts and incremental progress. Many of these organizations are rightly anxious about escaping the fate imposed by the US Treasury on Tornado Cash‘s developers and deployers; surely some line in the sand can be drawn between flaunting sanctions and making reasonable steps towards distributed mitigation strategies?
The journey on Identity Tokens is just starting and there are potentially a lot of standards effort that can support its development. Currently a lot of this thinking is happening within Centre Consortium. Some of the next steps being considered include:
Defining a common baseline standard for Identity Proofing associated with the issuance of a KYC Token. This would reduce the need for “verifiers” to have to understand each individual companies process to understand if they can trust the token.
Define a common methodology to ping a smart contract or API for more information about the account controller. This would include the definition of schemas for common requests and responses
Define precise, infrastructure-agnostic functional requirements for “revocation” obligations for KYC tokens when the status of an Account Controller has changed.
This post tries to lay out concepts and frameworks to evaluate new classes of NFTs around identity. In subsequent blog posts we will lay out how KYC/KYB Tokens and Badge Tokens can be implemented on Hedera, and the benefits that Hedera can bring to such offerings.
While the opinions expressed in this article are purely my own - I do want to thank a lot of people for providing their input and insights to inform my thinking on this topic: