Soulbound Tokens on Solana

Solana has introduced a new standard called Solana Token 2022 which supports, among other things, non-transferable or “Soulbound” tokens (SBTs). Instead of using this new standard at Civic, we use Civic Passes, an SBT standard, to allow individuals to represent aspects of their identity on-chain.

In this educational article, we deep-dive into SBTs from a technical perspective and show how Civic Pass fits into the Solana ecosystem.

Soulbound Tokens

SBTs are an emerging standard for non-transferable NFTs, initially proposed by Ethereum leaders in the DeSoc paper, published in early 2022. Currently, this new standard is being implemented in various forms, especially on EVM chains.

SBTs aim to use tokens to associate properties to individuals and make those properties discoverable on-chain. It is, in many ways, the natural next step in the evolution of NFTs, given that NFTs are already being used to indicate aspects of identity through PFPs, governance tokens, membership of a community and POAPs, to name a few examples.

Currently, NFTs are not used for identity purposes because they are transferable. For example, this means that if someone holds a token indicating they attended a conference, it cannot be inferred that the holder actually attended the conference because the holder could have purchased the token or received it from another person.

SBTs allow the use of NFTs for identity purposes by forcing non-transferability of tokens. This means that tokens cannot leave the wallet they are minted to. Because of this constraint, the tokens become “attributes of an individual” rather than tokens inside a wallet.

Criticisms of SBTs

The concept of SBTs have received significant criticism in the decentralized and self-sovereign identity communities, because they are seen as a poor approximation of verifiable credentials, which are “self-sovereign” claims about a person that they own and control.

In particular, SBTs have received criticism for being public, immutable and non-consensual:

• Public: the information that an SBT conveys on the holder is visible to all, there is no support for selective disclosure.
• Immutable: an SBT can (typically) not be changed, and although a holder can collect tokens that “update” older ones, there is no guarantee that a client will respect this relationship, as disclosure is passive, which means that the holder does not actively choose which claims to present and which to withhold.
• Non-consensual: There is (typically) no mechanism by which a user can reject an SBT being passed to their wallet.

One of the standard-bearers for resistance to the SBT idea is Evin McMullen, CEO at Disco.xyz, and her debate with Vitalik on Bankless is required listening for those interested in the topic.

Civic’s view of SBTs

Earlier in the year, we shared some initial thoughts about SBTs and what Civic has been building with Civic Pass and the Gateway Protocol, and have continued to develop thinking on the topic in presentations and additional blogs. In sum, we believe that SBTs have some inherent problems, but that they can be greatly useful in some cases, particularly when gating smart contracts. Many of the problematic issues with SBTs are mitigated by our model of issuing Civic Passes, backed by Verifiable Credentials.

• Privacy: Use Verifiable Credentials to store personal information, and only store on-chain information required by smart-contracts to grant access.
• Mutable: Passes contain no information by themselves, but rather point to information stored off-chain which is in the custody of the individual, and may be changed.
• Consensual: Individuals request and co-sign the issuance of a pass.

In addition, Civic proposes associating SBTs with decentralized identifiers (DIDs), rather than wallets. DIDs may be thought of as an abstraction layer over a wallet, which allows users to connect multiple wallets together into a single identity across chains, define controller relationships between DIDs, and even add constraints to them.

The difference is subtle, but associating tokens with DIDs ensures these tokens are not lost if the private key material controlling the DID changes (e.g. through account recovery, key rotation, or simply using a different device).

DIDs may be combined with Verifiable Credentials (VCs), which are another decentralized identity standard. Civic uses VCs to attest identity information while maintaining privacy and GDPR compliance. Civc attests to identity information by issuing a VC, then registers that attestation on chain in the form of a token. Together, DIDs and VCs present a framework that offers users more granular control over their digital identities.

Solana SPL-Tokens

Solana has a token standard, called SPL-Token. Unlike other chains, this standard is encapsulated in a single smart contract, maintained by Solana Labs. Essentially all tokens and NFTs on Solana use this standard. Civic Pass is a notable exception.

The SPL-Token has limited support for SBTs, in that you can create an NFT (supply = 1) and freeze it so that it cannot be transferred.

However, SPL-Token does not truly support SBTs in the current version. This is because tokens in Solana are associated with token accounts, which can be thought of as an individual bank account for each token type. Through a quirk of SPL-Token, these token accounts can have their owner changed. Thus, the SPL-Token is transferable and does not support SBTs.

Solana Token 2022

Solana is releasing an upgrade to SPL-Token, known colloquially as Token-2022. It is live in mainnet, but still running through audits.

Token-2022 introduces the concept of “extensions.” These are features on a mint that add extra behavior or constraints. Examples are:

• Transfer Fee: Charges a fee in tokens whenever these tokens are transferred.
• Confidential Transfers: Encrypts token balances and transfer amounts.
• Interest Bearing: Accrues interest on token balances over time.

The extension provided by Token2022 that is relevant for the SBT use case is the “non-transferrable” extension. This extension freezes accounts by default, ensuring tokens cannot be transferred.

Civic Pass

The initial proof of concept for Civic Pass used SPL-Token despite the previously outlined constraints. However, we soon decided that the SPL-Token was insufficient for the requirements for Civic Pass use-cases.

In particular, the Gateway Protocol, used by Civic Pass, provides the following:

• Expirability & refreshability
• Freeze & revocability
• Non-burnability
• DID support
• Decentralized issuance

Instead of using the SPL Token, the Gateway Protocol uses its own separate token standard, and does not appear in wallets as an SPL Token.

SPL-Token – Gateway Summary

The following table summarizes the differences between Solana SPL-Token and Token 2022 standards and the combined approach of using the Gateway Protocol and Verifiable Credentials, which were all outlined above.

Our approach is based on private, self-sovereign, verifiable credentials, with on-chain passes for those that need to be represented on chain. This approach offers more privacy and consent than a more limited standard for identity-related tokens.

Conclusion

In this blog, we’ve covered how SBTs can be useful to the broader ecosystem community as well as their constraints and criticism from the identity community. We’ve also explored how Civic has implemented our Gateway Protocol using our own separate token standard after moving away from SPL tokens.

As such, Civic will continue to use the Gateway Protocol,  and we will be adding an “equivalency program” to allow SPL-Token SBTs to be derived from gateway tokens.