SBTs in a nutshell
The original idea of SoulBound Tokens was described by Vitalik in this artile. There are special types of valuables in the world that cannot be transferred. For example licenses, certificates, documents.
In most cases, these are “rights” given by one party to another without permission to transfer these “rights” to other persons without the consent of the issuer.
SoulBound Token is basically a non-fungible non-transferable token. It can be
- issued by one address to another
- held by its owner
- watched by anyone else
The problem of on-chain reputation
Since the very creation of cryptocurrencies there was a problem of on-chain identification. Anyone can create an address (in Ethereum or Bitcoin) and one person can own as much addresses as he/she wants.
Sometimes it is necessary to prove the ownership of some asset or even address as a whole.
For example, a KYC-compliant exchange might request proof of ownership of an address.
Another example is an online store that accepts cryptocurrency payments to one deposit address — it often creates an “invoice” and waits for you to send the funds. However it may have problems identifying the origin of the funds transfer if two users would create the similar order at the same time. Without a proof of identity it is not possible to verify who of the two users has just sent the transaction.
This is how https://ezzocard.com/ is accepting USDT payments. It creates an invoice and then waits for the user to deposit USDT.
And then it waits for the user to click the “Paid” button. Once the button is clicked the service checks if deposit is received and processes the order. Ezzocard is using one-time deposit addresses exactly because it would be impossible to distinguish one users deposit from another due to the lack of on-chain identification possibilities.
This is not a big issue for a centralized service like Ezzocard that can create as much on-time addresses as it needs but a smart-contract has permanent address and therefore any decentralized service would have problems doing so.
Sometimes it is necessary to identify yourself on-chain and attach personal data to an address
There are some projects that attempt to solve this problem in Ethereum infrastructure. For example CIVIC is acting as a party that confirms identities of its customers.
Another attempt to solve this problem comes from name services — ENS on Ethereum, DexNS on Callisto, or built-in names on EOS.
All this come to a simple idea that a user can create an “anonymous” account easily but the user needs to perform some action to turn this into a “augmented” account and then receive a proof that this action was performed successfully.
SBT is a digital certificate
SBTs are made to be exactly the proof that an event has occurred and that this particular address has participated in that event. The SBT may be issued simply as a badge or may contain important information as a certificate.
An SBT can be awarded to an address, just like a medal can be awarded to a person.
Example : Bob has won a tournament. He was awarded a special SBT alongside the prize.
Alice may come across Bob’s address and realize that this might be the address of the winner.
Problem1 : Is this really the address of a winner? — Bob’s address has an SBT issued by the tournament organizers so this might be a proof.
Problem2 : Is the SBT issued by the real tournament organizer? — Alice can then take a look at the organizer’s address. There may be another SBT issued by a company that verifies on-chain identities, and this could be taken as proof of a link between the tournament organizer and the address Alice is looking at.
Problem3 : Alice wants to send Bob a message. — Bob might issue himself his own SBT and record his email onto it. Therefore anyone who wants to message the owner of this address can take a look at Bob’s personal SBT and find a email there.
Problem4 : Alice meets a person that pretends to be the Bob. How can she know this is really the Bob who owns the address with tournament SBT? — Bob’s self-issued SBT might contain a “secret” that only Bob knows. A crypto example can be a hash of a word. If a person you meet knows the pre-image of the hash then this person is the owner of the address.
As it was illustrated, SBTs can effectively solve a number of problems. However this requires a wide infrastructure and overall support of SBTs by network participants.
There should be at least 3 SBT smart-contracts in the described system:
- Identity verification company that issues SBTs
- Tournament organizer’s SBT
- Bob’s self-issued SBT
Systems of reputation
SBTs can be awarded for any achievement as a proof. Over time, SBTs can be accumulated at an address and create a “history” of its owner’s achievements.
A good example is Mentee network. A project that introduces a social network where “mentors” and “mentees” can connect with each other.
Reputation plays significant role in such projects. The proof of Mentor’s reputation however is not directly connected to the Mentor’s achievements but rather to the achievements of thier mentees.
The service must mint SBT to both Mentor’s and Mentee’s addresses.
- Mentor’s SBT must contain a link to his Mentee’s addresses.
- Mentee’s SBT must contain a link to the Mentor’s address.
In this case a person might have a look at Mentor’s address and then browse the addresses of their Mentees and if these addresses have any significant achievements (represented by a number of SBTs) then their reputation is linked to the Mentor.
Negative value SBTs
It is also possible to issue negative value SBTs. Blockchain explorers are marking addresses as “phishing” or “suspicious” in some cases. The same could be done with SBTs as a person can not transfer it away and the SBT can only be revoken by the issuer.
Hack investigation organizations might issue their SBTs on suspicious addresses. Any types of sanctions or “negative karma” might be implemented similarly.