The recent DeSoc paper illustrated how Soulbound tokens (SBTs) could combat the over-financialized phenomenon in Web3, and encode a trust network where human connection and broad collaboration across differences can flourish. Amid a heated discussion about SBT and alternative solutions such as VC or ‘signed claim’, we want to give a general comparison of Soulbound Token and Verifiable Credential (VC) and explore constructing identity on the implementation level.
This article is reproduced from a 28 min presentation from Kailai Wang, a parachain engineer at Litentry.
Identity in Web 1.0, 2.0, and 3.0
Back in Web 1.0, you log in with your username and password to gain access to authorized content, i.e. your personal profile on the website or data that are exclusively visible to you. In Web 2.0, centralized big tech companies brought convenience to the login process using their administrative federal identity system, which means you could simply log into a new website using, for example, a Google account.
In Web 3.0, you probably only need one wallet address, which is like a one-stop pass to the whole web and unlocks all customized features and data. There’s nothing inherently wrong with that, but it also says so much about the importance of a wallet - a wallet represents your whole identity, and says who you are as a person. Our cyberselves are flattened into our wallets in cyberspace.
However, a wallet address is still nothing more than some random string of characters. It’s quite obvious those hex numbers starting with 0x can’t tell you what kind of person is behind that wallet. Apart from that, people are using their wallets mostly for financial activities, i.e. transferring assets, staking, lending and borrowing, mining (liquidity swap pools) It says nothing about your human character – are you assertive, trustworthy, active in the ecosystem?
Therefore, we must extend the wallet functionality to either store or associate our social attributes with it. This is where decentralized identifiers (DIDs) come from, and what basically SBT and VC are trying to solve.
What are Soulbound Tokens (SBTs) and Verifiable Credentials(VC)?
From a higher level perspective, Soulbound Token is just a token type in nature. It’s similar to a nontransferable NFT, so there's a corresponding Ethereum standard for it. A Verifiable Credential is issued by some third-party authority to prove a certain assertion or claims of a person, who is called the VC holder.
From a standard point of view, the standards of SBT are not finalized yet, but there are mainly two standards that are work in progress, namely the EIP-5114, and EIP-4974. VC, as a W3C standard, has a W3C data model which defines different roles and responsibilities, description of the data being transferred (how the data should look), and gives detailed definitions and terminologies for documents such as presentations, proofs, subjects, and so on.
Let’s take EIP-5114, a work-in-progress SBT standard, as an example. We can tell it’s pretty similar to the well-known ERC-20 or ERC-71 standard. This code snippet defines the events, and functions of the token. For example, the minting event which is filed anytime a new instance of a token is minted, and functions that return various information about the token itself and resistant URI. In short, those events and functions are for the smart contract implementation and those implementations will be used to mint or manage this token type.
On the other hand, in the VC data model from W3C, there are different roles in the system. For instance, Issuers are responsible for issuing the credentials; Holders acquire the VC, store the VC, extract the information inside, and can even merge them into a ‘Presentation’ of data and send the ‘Presentation’ to the Verifier; Verifier then verifies and consumes the VC. There is also a common infrastructure called Verifiable Data Registry, which is basically registries that maintains different identifiers and schemas. For example, there could be a registry for VC storage. This W3C model is rather generic, it doesn’t mention any implementation details and offers great flexibility. So it’s not restricted to a certain technical protocol like TCP, IP, or HTTP for which not following implementation would simply not work. It’s highly customizable.
Comparisons Overview
- Issuer(s): SBT can be issued by anyone, i.e. our families, friends, and strangers. SBT emphasize the socially intersectional attribute of dentities, which considers the set of people who know best about us differ and no group can serve as a single checkpoint for all individuals. However, decentralization and low issuance critiria allows fraudulent and malicious behavior to arise, meaning there will likely be abuse of SBT. There could be, for example, a reject machanism where an SBT need the consent of the token receiver to complete transfer. Comparatively, VCs are usually issued by trusted authorities (i.e. dapp) to enhance its trustworthiness because proof of a personal claim requires extensive trust and authorization.
- Revocability: SBT is revocable but VC is not. It means that an issuer can revoke an SBT if, for example, its statement about the SBT holder is no longer true. This timely ensures the validity of data in the SBT. However, revocability poses a potential risk of manipulation, such as an unilateral revocation when the issuer got hacked. Comparatively, a VC cannot be revoked, which means you can carry around an invalid credential and claim you’re still a member of a gym club. That’s also why a VC or physical certificates always associate with a timestamp that states its expiration date.
- Implementation: On the implementation level, SBT can be seamlessly integrated into existing on-chain protocols because it’s simply a token type. The existing infrastructure for NFT, such as a series of tool for NFT on-chain management, can be easily adjusted and utilized for the use of SBTs. On the other hand, VC and its W3C data model are very generic. It can be considered as a container for different types of data including on-chain data, off-chain data and others. The implementation is also very flexible: you don’t have to follow any interfaces or preset APIs, and can simply write your own.
- Privacy: VC allows more fine-grained control of privacy because the holder of VCs can easily choose which VC to present or present only a part of a VC. For example, a holder of a VC, which proves his or her bachelor's degree from a university, can extract partial information from a VC and prove that s/he graduated without disclosing which university s/he went to. SBT doesn’t have this feature by default, but it can potentially utilize zero-knowledge proof to achieve a similar privacy-enhancing effect.
Privacy Concerns for SBT & VC: Publicity and Unilateral Permission
People are concerned about SBT’s potential publicity.
What types of SBTs will be public? And do they risk over-exposing our personal information? There are already several privacy solutions such as hashing the SBT: we can hash the token and put all private data on a privacy-preserving chain or encrypted data storage, and give out decryption keys to only whitelisted individuals. However, SBT will still lose some of its soul-representing attributes if made private.
Alternatively, we can separate the data to fully public on-chain data and off-chain data stored within a private data storage. And we could write a smart contract to program the privacy rules so that content revelation is triggered only upon certain conditions. For example, only members from a specific DAO can view my proof of attendance. The important thing here is that SBT is programmable and configurable so that SBT holders can decide on their own privacy rules.
On the other hand, VC is subject to its unilateral privacy.
When obtaining a VC or verifying a statement in VC you would usually require the holder of a VC to be present and is willing to cooperate. One potential solution is delegation. You can delegate a third party to have partial or complete access to your VCs. Similar to programmable SBTs you could add rules to selectively grant access to trusted visitors, and the process is automated using a smart contract or a code logic. Moreover, we always encourage VC holders to only acquire VCs that contain the needed information but nothing more.
In fact, those potential solutions to privacy issues are following the same principle, which is to find the middle ground between private and public data.
For example, SBT on-chain data is fully public, so we shift more sensitive personal data to private storage and grant access permission selectively. While for VCs, we offload partial data controls to third parties, so that those data are more public and accessible to visitors. Generally speaking, there is always a trade-off between privacy and simplicity, When you increase the security level by a lot, you also make the whole procedure more complicated. We should find the balance in between.
Looking at the Future
All in all, VC and SBT are complementary. At the end of the day, there is no one single solution or theory that is perfect and can apply to all circumstances.
We anticipate possible collaborations between SBTs and VCs, such as social recovery mechanisms and the way VCs handle privacy. We could combine the usage of SBT and VC as long as it is meaningful for the use cases. For example, the link in an SBT could actually point to a VC.
Looking ahead, we look to solve the information reselling problem, because neither is doing very well at the moment as it's really difficult to prevent that. Although SBT or credentials are revocable, you can't revoke information that has already been exposed. We also need to work on the standardization of both SBT and VCs for better implementation and adoption.
Last but not least, we are working on the aggregation of the different DIDs, which could bring all kinds of existing VCs and SBTs together for better management and more extensive use cases.
✨ Cheers!
Thank you for reading this article. If you have any questions or would like to join our discussion, please shoot an email to kailai.wang@litentry.com.
References:
https://www.w3.org/TR/vc-data-model/
https://eips.ethereum.org/EIPS/eip-5114
https://papers.ssrn.com/sol3/papers.cfm?abstract_id=4105763
https://kevinyu.substack.com/p/a-technical-commentary-on-desoc-part