There is a new buzzword in Web3 Identity - “Soulbound Tokens” - a very expressive name for non-transferable non-fungible tokens (NFTs) intended to represent an aspect of someone's identity, skills, or qualifications. If you’re hearing about Soulbound Tokens for the first time and want a good snapshot of the proposal please check out this paper.
But while Soulbound tokens hold appeal for their ease of quickly conveying facets of a person’s identity, the concept of on-chain tokens representing personal identifiable information (PII) is controversial due to the immutable public nature of distributed ledgers, lack of user control over their PII, and regulatory headwinds with laws like GDPR’s right to be forgotten. It is often contrasted with the “off-chain” identity stack being built up around Verifiable Credentials (VCs) and Decentralized Identifiers (DIDs) that put privacy at the forefront of their design. We believe however that the better comparison for Soulbound Tokens is with Open Badges 2.0 - which in its most common implementation has an associated public webpage that anyone with the link can view. Like Open Badges, Soulbound Tokens can be designed to display aspects of someone’s identity that they expressly wish to be public for all time.
That being said this paper does not dive into the Soulbound Token debate - but rather we consider what an early implementation of Soulbound Tokens might look like, and how they can be easily implemented on the Hedera network, leveraging the powerful capabilities of the Hedera Token Service (HTS).
Before we dive into an implementation of Soulbound Tokens let’s first consider basic product requirements for an implementation:
Issuance: Issuers will want to generate and send Soulbound Tokens to users with tools that make Soulbound Tokens easy to set up, provide high performance and scalability for issuance en masse, and with the lowest possible cost that is predictable.
User Acceptance: Since Soulbound Tokens are public and tied to the user's account, users will want the ability to vet and proactively accept any Soulbound Tokens they are issued. This prevents problems where an issuer could spam the user a Soulbound Token they don’t want, or a bad actor could issue the user a Soulbound Token that could be harmful to their reputation.
Revocation: Soulbound Tokens are often attestations from the issuer about the user. If an Issuer can make an attestation, they also need the ability to remove their attestation at a later time if it’s no longer valid or true.
Expiration: It’s quite common for assertions to have an expiration date that needs to be supported. For example, your First Aid course is only valid for 2 years after which a refresher is required, or you have a membership card that is only good for until Jan 2023.
Discoverability: it should be possible for 3rd parties to discover which accounts have a particular Soulbound Token. As an example, an airdrop might go only to accounts with a token reflecting some accomplishment or contribution of a community member.
Queryability: it should be possible for 3rd parties to easily query a given address to determine which Soulbound tokens are attached to that address.
Trust: Anyone viewing a user’s Soulbound Token(s) should have trust about who issued the Soulbound Token, that it was issued to the user, and if it is still valid.
With the above baseline product requirements in place let’s look at a set of sample Soulbound Token user stories, from the perspective of different users in the Token Ecosystem. We then outline how each story can be implemented using the Hedera Token Service, and the associated costs:
Token Issuer: Acme Training offers a course and exam to become a Certified Blockchain Security Professional (CBSP). Acme Training offers all successful graduates of the course a Soulbound Token.
HTS Implementation: Acme Training will create the CBSP non-fungible token (the Soulbound Token). They will configure all of the information for the token and in particular, for the below actions, they will configure a Freeze Key (to make tokens non-transferable once issued to a student) and a Wipe Key (for revocation of a student’s token if necessary). The token name & symbol will be chosen to make clear the meaning of the token. Read more about creating a token here
Cost: USD$1.0028*. Fee calculator here
* This cost is for all CBSP Soulbound Tokens issued for all time and should be seen as a type of one-time setup fee.
Token Recipient: Alice takes Acme Training’s CBSP course and passes the exam. Acme Training sends an offer to Alice’s wallet to receive her Soulbound Token. Alice accepts the offer. Alternatively, if Alice did not want the Soulbound Token she could ignore or decline the request.
HTS Implementation: Before Alice can receive the Soulbound Token, she must explicitly opt in or associate to the token. Acme Training creates an association request transaction. As Alice wants the Soulbound Token she signs the transaction via her wallet. Once Alice is associated, Acme Training mints an instance of the token for her. If relevant, Alice’s token can link to off-chain metadata that provides additional information about Alice’s particular token, e.g. her GPA etc. Read more about how to associate tokens with accounts here and minting of tokens here.
Cost: USD$0.05 for the association. USD$0.05 for minting
Token Recipient: Alice receives her Soulbound Token in her wallet.
HTS Implementation: Acme Training transfers the Soulbound Token to Alice’s account. Immediately after transferring the token Acme Training will Freeze Alice’s account which makes the Soulbound Token non-transferable. Read more about the transfer of tokens here and freezing an account for a token here.
Cost: USD$0.001 for Transfer. USD$0.001 for Freeze
Token Owner Sharing Credentials: Alice wants to join a DAO. The DAO membership application sees that Alice has the CBSP qualification in her wallet, and as the DAO membership is looking for new members with a security skill set, they accept her application to join.
HTS Implementation: Alice connects her wallet to the DAO membership application to demonstrate she controls her account. The DAO membership application queries a Hedera explorer with Alice’s Hedera account address to determine if the CBSP token (or others) is held by Alice. The DAO is able to confirm that the token was issued by Acme Training (and not perhaps by Alice herself) by examining the original transaction that created the token, and verifying that it was paid by an account known to belong to Acme Training. A list of Hedera explorers can be found here.
Token Surveyor: A different online university Beta School wants to encourage graduates of Acme Training’s CBST program to join their advanced program.
HTS Implementation: Beta School queries a Hedera mirror node to identify all accounts that have the Acme Training CBST Soulbound token.
Cost: Free
Token Issuer/Revoker: Acme Training comes to learn that Alice cheated on her CBSP exam. They revoke her CBSP qualification and remove the associated Soulbound Token from Alice’s account. The DAO notices the removal and reconsiders her membership.
HTS Implementation: Using the previously established Wipe Key, Acme Training removes the Soulbound Token from Alice’s account. If and when the DAO membership application subsequently queries a mirror for the current status of Alice’s Soulbound Token, it will be apparent she no longer has the token.
Cost: USD$0.001
Enabling Users to Remove Tokens: Acme Training has a scandal and their certification standards are called into question. Alice is embarrassed to have an SBT associated with Acme Training and she wishes to remove it from her account.
HTS Implementation: An alternative implementation on Hedera is possible to enable this user today. If the token were created specifically for Alice (rather than an instance of an existing token minted for her) then she could have the same ability as Acme Training to remove the token from her account. In this model, the economics change - the USD$1 for creating the token would not be amortized across multiple students (as in the model described above) but would need to be paid by either Acme or Alice.
Another path for consideration in the Hedera Roadmap would be to add a feature where instances of a token have a holder account wipe key allowing Alice to independently wipe the token from her account.
Managing Token Expiration: The CBSP certification offered by Acme Training is only good for 1 year after which point Alice would need to take a refresher course to maintain her certification.
HTS Implementation: There are a number of ways Soulbound token expiration could be implemented.
When creating the token Acme Training can set an Expiration Time and disable Auto Renew. This means that when the expiration time passes the token will be automatically deleted. See more about the Auto Renewal feature here
Acme Training could bake the expiration date right into the Soulbound token itself by giving it a name like “CBSP Certification 2022” or including the expiration time in the memo field.
The Soulbound token can reference an off-chain representation of the credential which contains the expiration metadata
Acme Training could wipe the Token from Alice’s account when the expiration date is passed.
Beyond these user stories over time a Soulbound Token “standard” could add a range of features and functionality:
Support for Zero-knowledge / zk-SNARKs which would allow Soulbound tokens to disclose PII in a more privacy-preserving way.
Cross-chain interoperability that would allow Alice to attach her Soulbound token to her address on Ethereum, Solana, Avalanche, etc.
As illustrated above Hedera’s Token Service has a flexible and powerful feature set that will allow you to start experimenting and issuing Soul-bound tokens today. Hedera’s enterprise-class scalability, predictable pricing, and granular control capabilities give companies looking to create Soulbound tokens an ideal platform to start their journey.
If Soulbound Tokens are not for you we would also encourage you to explore Hedera’s support for an off-chain identity stack of DIDs and VCs via the Hedera DID Method & Revocation framework. As SBTs and VCs address very different use cases with different privacy models and requirements, we see no conflict between the two models.
If you have any comments or questions please feel free to contact us anytime. If you would like to see Hedera add more features to the Token Service to support your Soulbound Token project please submit a Hedera Improvement proposal here.