Vitalik proposed the concept of SoulBound Token in early 2022 to solve the problem of user identity that the current NFT cannot solve. The current NFT, although with a certain unique personality representation, but this representation is match by the exchange, inevitably more inclined to commercial operation, the representation is more whether you can afford to buy the NFT, but not a true representation of the person behind the Token properties. soulBound that is, after the acquisition can not be removed, so as to achieve a true representation, so as to achieve a kind of equality. This is a way to achieve a kind of equality.

The problems that SoulBound has to solve, which Vitali has also presented in its article, are in fact very complex in every aspect, but in general terms the main ones are the following.

• How to achieve non-transferability of Tokens and be able to solve special cases (e.g. theft)

• How to agree on write access and read privacy

The idea of SoulBound came from the game, but it was also driven by the need to evolve Web3 to the point where NFT could not achieve pure representation of the user and represent fairness, and mixed in more with the attributes of money than the nature of things. Things in the real world are also, as long as they are invented by humans, very easy to exchange with money, but those that are deeply bound to people, those experiences, minds, souls are not transferable and replaceable. And we do have more and more scenarios among Web3 now, such as Governance voting, POAP distribution, user authentication, etc., that favor the erasure of such inequalities.

In the ETH ShangHai Hackathon, there is a project “Burn My Wallet” that makes good use of the SoulBound concept by Minting a SBT after the address is hacked. This Token cannot be transferred and is equivalent to a tag so that other applications can recognize it as a hacked address.

It seems inappropriate to implement a different quality of Token and remove the Transfer function directly, because once this address is stolen, then the rights represented by the Token are also stolen. In fact, this cannot be Transfer, and should be implemented as a Transfer under some strict constraints. vitalik cites the method of recovery by multiple friends of Relation, which is more towards the centralized social media approach and seems less feasible, as this method may become invalid due to the interruption of Relation. This issue, it seems, should be decided by the user + issuer, together, how to transfer this Token, such as introducing a double approval mechanism, because as we will analyze later, it is very important who the issuer of the SoulBound Token is, and this issue is expected to be solved by the issuer.

Secondly, Vitalik also gave some examples about the permission to write data and read data. It is true that a SoulBound data write access, should be a Token issuer and the user can write, if implemented as a way to accommodate all third-party write data, easy to cause write abuse, this data write access should be bound within the scope of the application. Read access is a bit more complex. There is no doubt that the user and the issuer can read the data, but who can read the data from third parties? This problem of disagreement will inevitably lead to two types of Tokens, one is an open SoulBound that can be read by anyone, and the other is a SoulBound with encryption or without informing the attribution, through an additional method of sharing data, while achieving privacy protection and logic operation.

There are already some SoulBound implementation solutions, among which there is a DAOU project that tries to solve the authentication problem of DAO organizations through SoulBound, they have implemented a kind of SoulBound, of course, it is still a simple version at the moment.

It implements a Soul mapping list, in which the data stored are business-related specific fields, such as url and score. user's Soul is stored in a Map. in addition, a Profile is maintained, and third parties can write Soul data to user addresses. This approach is equivalent to distinguishing between the issuer and the third party.

https://gist.github.com/0xanthonyx/d99ecea88fa555021bc44e6d7d3c3913

For the implementation of SoulBound, we still need to consider many realistic issues, in general, is to make this Token can represent the user's identity as much as possible, marked by what the user has done, what he has experienced, what achievements or negative comments, these data should be reflected in the SoulBound Token he holds. soulBound Token is more suitable to be the NFT Pass of each application, non-transferable and at the same time a representation of identity.

The implementation of SBT should be as simple as possible and can be conveniently applied. It is actually an on-chain space for applications and users, and the data stored on it characterizes the user's identity.

The issuer of SoulBound is important. Due to the non-transferable nature of SoulBound, it is not easy to remove once it is hit, so there should be a good segregation between different data ranges. We believe that a SoulBound Token should only allow the data inside it to be modified by the issuer of the project, and not by third parties. If a third party wants to give new features to this user, then they should issue a Token of their own. And the SoulBound Token issued by different project parties, like the current NFT, should be treated differently. The SBT issued by an authoritative project party has a very different meaning than the SBT issued by a malicious random.

It can be the same as NFT, which comes with the name and introduction of the SBT, telling the user about its issuer, but of course this information has to be verified by the user in the process of use. The application can still guide the user which SBTs are important and which ones are distributed haphazardly by treating different Tokens differently, similar to the current OpenSea approach.

ENS, as a decentralized domain name, does also play a certain role of user authentication, but it is more characterized by some personal information of users, such as resolving on-chain addresses, email addresses and related URLs. ENS also does not easily transfer, but it is indeed easy to transfer, at least giving users the freedom to transfer this option. We can understand ENS as a special case of SBT, a special way of storing data, a special way of use it.

SBT should be a common protocol for a wider range of applications, which agrees on how SBT is issued and how the data inside is modified, and it is up to the issuer to decide what data is stored inside, based on the needs of their different applications. Some applications need to store a score, some applications need to store other metrics or tags.

Since SBT has limited data storage, more data related to user identity should be obtained by means of Port3's "Social Data Oracle".

ERC721 can also be made non-tradable by simply removing the Transfer part. But ERC721 points to a metadata elsewhere, which may point to an IPFS file that contains the relevant data. This approach gives NFT flexibility, but relies on data under the chain, which is more unreliable. nft is more focused on property relations, and its metadata stores less important or oversized files, such as images of nft. The requirement is that we need to write data to Token, SBT is dynamic NFT, and there is an option that the Metadata URL pointed to is an API that can return data, in which case its reliability is not guaranteed. Therefore, if the data is not too complex, it is possible to write directly to the chain.

In terms of upgradability, if an SBT is not upgradable when the data structure is set, it will indeed cause problems, so the SBT should also be able to implement field upgrades. One way this can be achieved is to separate Token and data, deploy a data storage contract first, and then have SBTs point to the corresponding contract address. The data contract can be updated by the issuer, so that the flexible update of data fields on the chain can be done.

In addition, during the implementation of SBT, some basic functions should be consistent with ERC721, so that it can be easily understood by more developers and users, as well as quickly supported in ERC721-enabled applications.

To sum up, we can probably draw a picture of what a SoulBound Token looks like. It should be a Token that is not easily transferable, but written by the issuer, owned by the user, and capable of data permission control, and of course, depending on the scenario, can be implemented as an open read or a more private way in the future.

Port3 Network is a Social Data Gateway for Web3, aggregating data from both on and off-chain to drive various needs of Web3 application scenarios, such as smart airdrops, community management, SBT distribution, NFT whitelisting, etc. The job we do determines our proximity to SoulBound, and SoGraph.xyz, a part of Port3 Network, will build users' SBT Pass through the SoQuest system. We are actively exploring the latest developments in SBT, so let's look forward to the first version of Port3-implemented SBT in the near future.

Vitalik proposed the concept of SoulBound Token in early 2022 to solve the problem of user identity that the current NFT cannot solve. The current NFT, although with a certain unique personality representation, but this representation is match by the exchange, inevitably more inclined to commercial operation, the representation is more whether you can afford to buy the NFT, but not a true representation of the person behind the Token properties. soulBound that is, after the acquisition can not be removed, so as to achieve a true representation, so as to achieve a kind of equality. This is a way to achieve a kind of equality.

The problems that SoulBound has to solve, which Vitali has also presented in its article, are in fact very complex in every aspect, but in general terms the main ones are the following.

• How to achieve non-transferability of Tokens and be able to solve special cases (e.g. theft)

• How to agree on write access and read privacy

The idea of SoulBound came from the game, but it was also driven by the need to evolve Web3 to the point where NFT could not achieve pure representation of the user and represent fairness, and mixed in more with the attributes of money than the nature of things. Things in the real world are also, as long as they are invented by humans, very easy to exchange with money, but those that are deeply bound to people, those experiences, minds, souls are not transferable and replaceable. And we do have more and more scenarios among Web3 now, such as Governance voting, POAP distribution, user authentication, etc., that favor the erasure of such inequalities.

In the ETH ShangHai Hackathon, there is a project “Burn My Wallet” that makes good use of the SoulBound concept by Minting a SBT after the address is hacked. This Token cannot be transferred and is equivalent to a tag so that other applications can recognize it as a hacked address.

It seems inappropriate to implement a different quality of Token and remove the Transfer function directly, because once this address is stolen, then the rights represented by the Token are also stolen. In fact, this cannot be Transfer, and should be implemented as a Transfer under some strict constraints. vitalik cites the method of recovery by multiple friends of Relation, which is more towards the centralized social media approach and seems less feasible, as this method may become invalid due to the interruption of Relation. This issue, it seems, should be decided by the user + issuer, together, how to transfer this Token, such as introducing a double approval mechanism, because as we will analyze later, it is very important who the issuer of the SoulBound Token is, and this issue is expected to be solved by the issuer.

Secondly, Vitalik also gave some examples about the permission to write data and read data. It is true that a SoulBound data write access, should be a Token issuer and the user can write, if implemented as a way to accommodate all third-party write data, easy to cause write abuse, this data write access should be bound within the scope of the application. Read access is a bit more complex. There is no doubt that the user and the issuer can read the data, but who can read the data from third parties? This problem of disagreement will inevitably lead to two types of Tokens, one is an open SoulBound that can be read by anyone, and the other is a SoulBound with encryption or without informing the attribution, through an additional method of sharing data, while achieving privacy protection and logic operation.

There are already some SoulBound implementation solutions, among which there is a DAOU project that tries to solve the authentication problem of DAO organizations through SoulBound, they have implemented a kind of SoulBound, of course, it is still a simple version at the moment.

It implements a Soul mapping list, in which the data stored are business-related specific fields, such as url and score. user's Soul is stored in a Map. in addition, a Profile is maintained, and third parties can write Soul data to user addresses. This approach is equivalent to distinguishing between the issuer and the third party.

https://gist.github.com/0xanthonyx/d99ecea88fa555021bc44e6d7d3c3913

For the implementation of SoulBound, we still need to consider many realistic issues, in general, is to make this Token can represent the user's identity as much as possible, marked by what the user has done, what he has experienced, what achievements or negative comments, these data should be reflected in the SoulBound Token he holds. soulBound Token is more suitable to be the NFT Pass of each application, non-transferable and at the same time a representation of identity.

The implementation of SBT should be as simple as possible and can be conveniently applied. It is actually an on-chain space for applications and users, and the data stored on it characterizes the user's identity.

The issuer of SoulBound is important. Due to the non-transferable nature of SoulBound, it is not easy to remove once it is hit, so there should be a good segregation between different data ranges. We believe that a SoulBound Token should only allow the data inside it to be modified by the issuer of the project, and not by third parties. If a third party wants to give new features to this user, then they should issue a Token of their own. And the SoulBound Token issued by different project parties, like the current NFT, should be treated differently. The SBT issued by an authoritative project party has a very different meaning than the SBT issued by a malicious random.

It can be the same as NFT, which comes with the name and introduction of the SBT, telling the user about its issuer, but of course this information has to be verified by the user in the process of use. The application can still guide the user which SBTs are important and which ones are distributed haphazardly by treating different Tokens differently, similar to the current OpenSea approach.

ENS, as a decentralized domain name, does also play a certain role of user authentication, but it is more characterized by some personal information of users, such as resolving on-chain addresses, email addresses and related URLs. ENS also does not easily transfer, but it is indeed easy to transfer, at least giving users the freedom to transfer this option. We can understand ENS as a special case of SBT, a special way of storing data, a special way of use it.

SBT should be a common protocol for a wider range of applications, which agrees on how SBT is issued and how the data inside is modified, and it is up to the issuer to decide what data is stored inside, based on the needs of their different applications. Some applications need to store a score, some applications need to store other metrics or tags.

Since SBT has limited data storage, more data related to user identity should be obtained by means of Port3's "Social Data Oracle".

ERC721 can also be made non-tradable by simply removing the Transfer part. But ERC721 points to a metadata elsewhere, which may point to an IPFS file that contains the relevant data. This approach gives NFT flexibility, but relies on data under the chain, which is more unreliable. nft is more focused on property relations, and its metadata stores less important or oversized files, such as images of nft. The requirement is that we need to write data to Token, SBT is dynamic NFT, and there is an option that the Metadata URL pointed to is an API that can return data, in which case its reliability is not guaranteed. Therefore, if the data is not too complex, it is possible to write directly to the chain.

In terms of upgradability, if an SBT is not upgradable when the data structure is set, it will indeed cause problems, so the SBT should also be able to implement field upgrades. One way this can be achieved is to separate Token and data, deploy a data storage contract first, and then have SBTs point to the corresponding contract address. The data contract can be updated by the issuer, so that the flexible update of data fields on the chain can be done.

In addition, during the implementation of SBT, some basic functions should be consistent with ERC721, so that it can be easily understood by more developers and users, as well as quickly supported in ERC721-enabled applications.

To sum up, we can probably draw a picture of what a SoulBound Token looks like. It should be a Token that is not easily transferable, but written by the issuer, owned by the user, and capable of data permission control, and of course, depending on the scenario, can be implemented as an open read or a more private way in the future.

Port3 Network is a Social Data Gateway for Web3, aggregating data from both on and off-chain to drive various needs of Web3 application scenarios, such as smart airdrops, community management, SBT distribution, NFT whitelisting, etc. The job we do determines our proximity to SoulBound, and SoGraph.xyz, a part of Port3 Network, will build users' SBT Pass through the SoQuest system. We are actively exploring the latest developments in SBT, so let's look forward to the first version of Port3-implemented SBT in the near future.