The Construction of the Soul Part 1: The ABCs of SBT

Contents

1. What is a Soul Bound Token and why is it important?
1.1 Problems in the Web3 space
1.2 SBT as a solution for social composability
1.3 Use cases of SBT
→ 1.3.1 Real-Life Examples of SBTs
2. Spartan Labs’ Vision for SBTs
2.1 How does the vision of SBT play out in the real world?
2.2 Third-Party Verification of Attributes
2.3 Usage of SBT by Counter Party Souls
3. Key Features of Our Soul Bound Token
3.1 Non-Transferability
→ 3.1.1 Governance
→ 3.1.2 Identity
→ 3.1.3 Importance of Proper Non-Transferability Implementation
3.2 Non-Fungible
→ 3.2.1 Fungible SBT
→ 3.2.2 Non-Fungible SBT
3.3 Privacy in SBT
→ 3.3.1 What kind of data should we keep private?
→ 3.3.2 How can we keep data within SBT private?
3.4 Off-Chain Storage
3.5 Issuance and Verification of Souls
→ 3.5.1 Verification of the Soul
→ 3.5.2 Updating of SBT Data
→ 3.5.3 Issuance of SBTs
4. How do the key features in SBT work for Web3 projects?
5. Conclusion

Abstract

In part 1 of the series, we will go over the basics of Soul Bound Tokens (SBTs) and their importance, and also propose a vision for the key features of SBTs.

1. What is a Soul Bound Token and why is it important?

Vitalik Buterin, best known as one of the co-founders of Ethereum, co-authored a white paper entitled “Decentralised Society: Finding Web3’s Soul,” with his fellow authors — Glen Weyl and Puja Ohlhaver, detailing their vision for a fully decentralised society (DeSoc) and how the concepts of ‘Soulbound’ tokens (SBT) could make it a reality.

1.1 Problems in the Web3 space

The economic value of the world is largely produced by people and their interdependent relationships. Being a system that is fully run by mathematical and cryptographic functions, Web3 lacks the primitives to represent such social relationships and identities, which resulted in its dependence on the centralised Web2 infrastructure that it originally aimed to disrupt.

The core aspects of trust and ownership should be on-chain in order to enhance social composability in the world of smart contracts, which could open many possibilities for decentralised applications.

1.2 SBT as a solution for social composability

Souls are defined as wallets that hold SBTs. SBTs are digital tokens that represent the credentials, commitments, and affiliation of “Souls”. It can encode the trust networks of the real economy with reputation and credibility on-chain.

In the Decentralised Finance space, for example, if a lending platform like Aave were to deploy an SBT, each address (Soul) could have a unique identity on-chain, enabling credit-score based lending.

Meaning if Aave deployed SBTs, it will allow credit-score based lending by Aave themselves or allow composability by other Dapps .

Credit scores are now held centrally by government entities such as credit bureaus.

What makes SBT powerful is that it decentralises fundamental concepts such as credit score. Instead of having to trust Credit Bureaus just because they are the only entity holding such information, each Decentralised application (Dapp) is empowered to choose whichever credit system they believe in and develop their own judgement.

More importantly, SBTs enable various other critical applications and use cases, such as community wallet recovery, Sybil-resistant governance, mechanisms for decentralisation, and novel markets with decomposable, shared rights.

1.3 Use cases of SBT

There could be many implications possible with the use of SBTs. Here are some pertinent use cases that were highlighted in the paper co-authored by Vitalik:

1. Verifying the artist’s legitimacy in the NFT project
2. Most NFT artists rely on centralised platforms like OpenSea and Twitter to commit to scarcity and initial provenance.
3. SBT helps to provide provenance if an artist can link their NFT project to their SBT
4. Unlocking under-collateralized lending markets through reputation
5. SBTs that represent education credentials, work history, and rental contracts could serve as a persistent record of credit-relevant history, allowing Souls to stake a meaningful reputation to avoid collateral requirements and secure a loan.
6. Mitigating attacks on and improving coordination of DAO governance
7. Mitigation of Sybil attacks
8. Dynamic leadership allocation
9. Diversity in governance
10. Creating novel markets with decomposable, shared rights and permissions
11. Measuring Decentralisation

1.3.1 Real-Life Examples of SBTs

Projects have already started implementing SBTs as a solution for on-chain identity.

As of August 19th 2022, Binance is preparing to launch the Binance Account Bound (BAB) token, the company’s version of soulbound or non-transferable and non-financialized token based on the company’s native Build and Build (BNB) chain. Users whose identities have been verified through the platform’s know-your-customer (KYC) procedure can directly mint the SBT on their digital Binance wallets. BAB will be used as KYC credentials, indicating when users’ identities have been validated. Third-party protocols can also utilise it to airdrop NFTs and prevent bots. BAB may also be used by decentralised autonomous groups to enable quadratic voting.

Other NFT projects have also tried to integrate SBT with their projects as well. Arc Community, for example, is issuing its Pyxis NFT to community members as a method of on-chain recognition and future rewards.

2. Spartan Labs’ Vision for SBTs

Although Vitalik’s paper sets the stage for SBTs, its key features, implementation, and use cases have yet to be fully defined. In this section, we will outline our vision for SBTs and how different siloed projects can collaborate with the system’s embedded social trust.

We envision a society that combines reputation systems with Zero-knowledge (ZK) mechanisms to protect individuals’ privacy. Balaji Srinivasan, who coined and popularised the phrase “pseudonymous economy,” has been the most vocal proponent of this concept.

We believe that SBTs could integrate the idea of pseudonymous economy and social composability in the Web3 space. SBTs not only serve as an additional opportunity for trusted composability of anonymous individuals, but they also enable interoperability across projects and protocols, reimagining the Web3 ecosystem we currently have.

2.1 How does the vision of SBT play out in the real world?

Imagine a world in which most participants have Souls that store SBTs corresponding to a variety of affiliations, memberships, and credentials. A person could have a Soul that stores SBTs representing different attributes like educational credentials, credit score, and accomplishments.

2.2 Third-Party Verification of Attributes

How could attributes within SBT be verified and linked to on-chain identity?

These trusted 3rd party verifiers could function similarly to Certificate Authority(CA) whose purpose is to verify identities and link the identities to digital Certificates. These certificates are used to protect the information, encrypt billions of transactions, and enable secure communication. that store, sign, and issue digital certificates. The CA will conduct several identity checks on the applicant before issuing a digital certificate.

In the context of SBT, there could be a trusted decentralised 3rd party intermediary DAO whose interests are aligned with the accurate verification of attributes. The individual seeking the SBT could pay an initial verification fee to the DAO. A panel of unrelated individuals from the DAO would conduct checks before allowing the minting of SBT data, and the verifiers would be paid a fee for their verification.

2.3 Usage of SBT by Counter Party Souls

In their most basic form, the data in SBTs can be declared by an individual, much to how we reveal information about ourselves in our CVs. However, the system’s true potential is highlighted when SBTs held by one Soul can be issued or attested by other Souls who are counterparties to these links. These Counterparty Souls could be individuals, businesses, institutions and other Web3 projects.

Counterparty souls could airdrop SBTs to their users. The users will then interact with the SBT project, which updates SBT data. Other permissioned protocols can then make use of the SBT to read and verify the attributes of the individual. Other permissioned protocols can then utilise this SBT to read and verify the individual’s attributes. This enables Web3 projects to be socially composable, allowing them to implement different mechanisms based on an individual’s attributes, such as allowing addresses that belong to a specific organisation to use its products or conferring higher voting rights to key stakeholders verified by their SBTs.

For example, an influencer could be a Soul that issues SBTs to longtime fans. A university could be a Soul that issues SBTs to graduates. An event organiser could be a Soul that issues SBTs to people who attend the event.

In the next section that follows, we will demonstrate how the core principles of SBTs can arise spontaneously from the design itself.

3. Key Features of Our Soul Bound Token

There are currently no formal definitions of SBT’s main features. With the goal of generalising SBT for usage in Web3 projects, we identified important qualities that SBT should have.

3.1 Non-Transferability

Non Transferability means that SBT should remain in a user’s Soul or be tagged to the user’s address. There should be hard checks to prevent the transferability of SBT.

But why should we make it non-transferable?

3.1.1 Governance

The transferability of SBT could lead to governance problems.

1. If the goal of transferability is so that governance power can be widely distributed, this would lead to a reverse effect since concentrated interests are more inclined to acquire governance rights from everyone else.
2. Transferability is counterproductive if the goal is to entrust authority to competent leaders since nothing prohibits the motivated but unskilled from attaining governance capabilities.

3.1.2 Identity

SBT represents an individual identity; hence, preventing impersonation is critical. Identity should not be transferred, especially if there is sensitive data within the SBT. We do not want a case where someone could easily acquire favourable attributes by acquiring SBTs on the secondary market.

3.1.3 Importance of Proper Non-Transferability Implementation

As Vitalik mentioned in his article, if non-transferability were to be done “naively”, transferability could still present a problem. Users can easily construct a wrapper account that preserves the SBT and then sell account ownership.

Prevention of Transferability

Other checks might be necessary, such as checking on-chain if the current owner is at the same address as the original owner, and more sophisticated checks over time if deemed necessary. Projects could also require SBTs to be the original SBTs, and this could reduce the incentive to create and utilise wrappers meant to game the system.

3.2 Non-Fungible

SBTs can be both fungible and non-fungible, and the resulting function would differ drastically.

3.2.1 Fungible SBT

Fungible SBT could be useful for voting rights and governance where it could be important to have an easily determinable way to find out voting power. A trivial implementation of the fungible soul could remove the ability to transfer a token similar to ERC20 except for the contract or owner itself.

3.2.2 Non-Fungible SBT

Non-Fungible SBTs, on the other hand, allow more possibilities because all Souls are unique, and we would like to correlate those distinctions with their SBTs. Credit history, negative reputation, and educational credentials might all be linked to SBTs, with the option to make such details private.

3.3 Privacy in SBT

Any relationship that is recorded on-chain is immediately visible to anyone in the entire world, not just the participants. By correlating SBT data, hostile actors may be able to dox users’ real identities from their Souls.

The success of the Web3 ecosystem is dependent on privacy. In certain cases, as the underlying entity that the item represents is already public, adding privacy is unnecessary. However, in many other situations, people may not wish to reveal all the data that they own as it could present a potential threat to them.

For instance, if one’s vaccination status became a SBT, one of the worst things we could do is set up a system in which the SBT is automatically publicised for everyone to view, as this creates social pressure on people’s medical decisions.

By including privacy in the design, we may prevent these negative effects of having an identity on-chain and enhance the likelihood of producing something fantastic.

3.3.1 What kind of data should we keep private?

Sensitive data or those that enable malicious actors to correlate with and dox an individual’s identity. Examples include:

• Personal particulars
• Medical data
• Financial data
• Reputation-based data

3.3.2 How can we keep data within SBT private?

There are various ways to keep this data private, such as:

3.3.2.1 Hashing of Data

Source: https://www.thesslstore.com/blog

• Hashing data is a relatively simple way to keep the data private.
• Hash is a fixed-length one-way transformation of input data.
• For example, if we could input a secret “Spartan Labs” into the hash function.
• The hash function would convert this data into a series of hexadecimals such as `ca9210da4bd8dda215176e8621b84f477da40ffa2158eeff7ef5d14613dfa695`
• This hexadecimal is fixed length, which means that all hashed results have the same length and it is statistically impossible to deduce “Spartan Labs” from it.
• The hash function used here is SHA-256.
• If the hashed data corresponds to the hash on-chain, the user’s attribute can be verified.
• Other parties would not be able to view the SBT’s data on-chain and the validity of the data can be proven if the hashed results are the same.

3.3.2.2 Symmetric Key Encryption

• Projects can issue a secret key to users, which they can then encrypt their data and they can share it with other projects who might need to verify their data.
• However, this is not a simple method and it requires the user to keep their symmetric key private and the other Web3 projects that want to make use of the user’s SBT data to implement the same decryption process.

3.3.2.3 zk-Proofs

Source: jamesbachini.com

• Zero-knowledge proofs (zk-Proofs) allow people to prove arbitrary statements without revealing any more information beyond the statement itself.
• zk-Proofs can be computed over SBTs to prove the characteristics of a Soul (e.g., that it has certain memberships) without revealing what are the characteristics.
• This has commonly been used in L2s using ZK-Rollup technology such as zkSync, Polygon Hermez and Scroll.

We will be exploring the implementation of privacy in SBTs in the second and third articles of the series.

3.4 Off-Chain Storage

The data for SBTs could be stored on-chain or off-chain depending on the project’s needs. If stored on-chain, it could be stored on a separate contract with a reference to another address, or it could be stored in the SBT contract itself.

However, it is computationally expensive to store the data on-chain. Therefore, we propose that one of the key features of SBTs is the ability to integrate off-chain storage of data, similar to how ERC721 NFTs store their data off-chain. This allows for less expensive and varied types of data to be associated with SBT.

3.5 Issuance and Verification of Souls

The issuance and verification of attributes of SBTs are crucial for composability.

3.5.1 Verification of the Soul

The SBT interface should be designed such that other projects can easily interact with a user’s SBT. It should not be complex for other Web3 projects to design an on-chain mechanism to verify the attributes of a user. This means that the attributes of the soul can easily be queried on-chain and validated.

• If the SBT is stored in an off-chain location, there should be a proposed standard for how other projects can query the data based on the structure of the data stored off-chain.
• If the SBT has private data, there should be an easy way to either (1) verify the URI provided by the user or (2) prove that the user has a certain attribute without revealing the URI but just the hash of the secret itself. This is with reference to the use of ZK technology.

3.5.2 Updating of SBT Data

To prevent data faking by the user, only the contract owners have access to update the user’s SBT data. However, projects should make it such that projects can propose modifications to their SBT data.

3.5.3 Issuance of SBTs

SBTs can be easily issued by projects to users. This can be done in a similar fashion to how NFTs are being minted or how airdrops are being done.

4. How do the key features in SBT work for Web3 projects?

Suppose a project wants to have a smart contract that only allows users with KYC information to interact with the contract. This smart contract can perform different actions based on the attributes of the user’s data. Other projects should be able to verify and perform operations on the user’s data on-chain.

However, on the blockchain, everything is anonymous and the user only has their address as a publicly verifiable attribute.

The project could consider using SBT as a mechanism for on-chain identification and storing a user’s KYC data.

In order to use SBT as a mechanism, the project could undertake the following actions.

1. Users submit their KYC information that is verified by real-world entities. Once this information is verified, the project mints SBTs for the user. The information provided by the users is encrypted and stored off-chain
2. Other counterparty projects can also verify that the users are KYC-ed and have certain attributes, but do not know the specific information about the user. These on-chain KYC attributes are private through encryption. However, users can provide secrets to these other counterparty projects, which provides them with the ability to read and verify their on-chain private information.
3. Users can update their off-chain information by proposing changes to the main project responsible.

In the next 2 articles of the series, we will present how projects are able to implement such mechanisms with SBTs.

5. Conclusion

SBTs are reputation-based non-transferable, non-fungible tokens with data that can only be accessed by selected parties. The integration of social identities with trustless composability, if done right, could change the future of the Web3 ecosystem.

In this article, we laid out our vision for SBTs, their potential use cases, and the key features that should be implemented for SBTs. We’ve sketched out the design principles of the SBTs, but our work is just beginning.

In the next article, we will be going through the implementations of SBT based on the design principles discussed in this article.

Disclaimer: This post is for general information purposes only. It does not constitute investment advice or a recommendation or solicitation to buy or sell any investment and should not be used in the evaluation of the merits of making any investment decision. It should not be relied upon for accounting, legal or tax advice or investment recommendations. This post reflects the current opinions of the authors and is not made on behalf of Spartan Labs or its affiliates and does not necessarily reflect the opinions of Spartan Labs, its affiliates or individuals associated with Spartan Labs. The opinions reflected herein are subject to change without being updated.

About the Author
This is part 1 of a 3-part Soul Bound Token Tech Research Article Series that is co-authored by Yong Kang Chia and Jun Hao Yap of Spartan Labs.

Spartan Labs is a venture studio under Spartan Group that advises and co-builds projects with the most optimal and effective design at launch and beyond by providing tokenomics design and project implementation. Spartan Labs also produces research reports and articles that are aimed at helping Web3 users gain insightful perspectives with regard to the developments and issues within the space.