Find out what is SBT-Auth and learn to create your own system
Soul Bound Token, SBT: A token which belongs to a specific address or attached to your specific address. You cannot transfer or sell it! You can only revoke this token, or give it back to the account who issued it.
Concept of soulbound items, once picked up, cannot be transferred or sold.
Purpose of soulbound items, it keeps the interest and excitement.
POAP is an excellent example of an NFT that works better if it could be soulbound. The very first time I implemented Soul Bound Token is by using EIP4973, here’s the code. And there are other ways, this is a great repo that I found, it contains everything around Soul Bound Token in my opinion.
There are lots of applications that we can build using Soul Bound Tokens, so one of them is:
Two-Step Authentication Using Soul Bound Tokens
Motivation:
On-chain verification is becoming indispensable across web3 (particularly in DeFi, DAO, and governance) as it is needed not only by the government for regulatory purposes, but also by protocols to whitelist users fulfilling certain criteria. This created the necessity of building on-chain verification of the addresses for token transfers (like stablecoin providers checking for blacklisted entities for the destination address, limited utility tokens for a DAO community, etc). Finally, the existing proposals are based on a trusted entity creating on-chain/off-chain signatures to manage a whitelist and are thus not decentralized protocols. To make it the best way in a decentralized community that will do good for all type of customers, Using Can’t Be Evil Licenses by a16z for this community to follow few sets of rules and regulations which is selected by the creator.
Applications and Users for the Platform:
- Anywhere where user data is stored.
- Wherever there’s a need to distinguish user.
- Covers the bulk of KYC instances towards retail customers:
- Finance: open a transaction account, purchase, sell or exchange cryptocurrencies
- Tax & Accounting: obtain advice on accounting or tax matters, register as beneficiary
- Legal: obtain legal advice, representation or support
- Telecom: acquire a mobile plan (pre-paid or post-paid)
- Real Estate: enter into rental agreement.
And yeah you can call this project as token gateway. A lot of projects/protocols already use token gateway for allowing different kind of users for access of different things.
Now let’s start with creating our own SBT-Auth system and test it out!
(A) Local Set-up
You can clone the tutorials repo from here: Github and then progress to the SBT-Auth folder
(B) Installation
Once the code is set-up on your local system, you need to make sure you must install all the dependencies using npm i or yarn install depending on your personal preference.
(C ) Understanding the Code
Licensing is important in the NFT space.
The NFT License helps define the rights of both owners of ERC-721 non-fungible tokens (NFTs) as well as artists and creators working with NFTs. The NFT License is designed to balance two concerns:
- Protecting the hard work and ingenuity of creators
- Granting users the freedom and flexibility to fully enjoy their non-fungible tokens
We may meet with some legal misconceptions by continuing this road.
“you own the NFT. And since you DONT OWN THE COPYRIGHT, usage is licensed to you…”
The real question is: How do we want to define ownership in blockchains that are built in the Open Source enviroment? a16z solves this problem by introducing Can’t Be Evil licenses, open-sourced licensing , here is the github repository. There are six licenses and in this project i’ve used PUBLIC(CBE_CC0) license, just to implement it, Projects can choose any one or more than one license as per their use-case.
Sign-Up
New Users:
Users will be signing up with their name and a information. Users will be minting a Soul Bound NFT that will be later using as a verifying proof. Smart Contract will create a hash using addressOfUser, nameOfUser, informationOfUser. And the hash is mapped with the Soul Bound NFT tokenID.
Sign-In
Existing Users:
If users have already signed up then they will be able to access the platform. If not they will be redirected to sign-up. In the smart contract, we are using a Soul Bound KYC proof to verify so that no user can bypass the SBT.
Another check Approach:
We can provide the hash to the users. And while sign-in, we’ll demand the hash as an input to sign-in. And then we’ll check whether the user’s tokenID has the same hash mapped or not!
I haven’t implemented it yet, but the function should look like this:
(D) Deploying the Smart Contract: SBKYC.sol
To deploy and for the purposes of our demo, we will be deploying the smart contract on BuildBear → buildbear.io
Creating a Private Testnet on BuildBear 🐻❄️ (why BuildBear, you ask? Have a look over here: Where Localhost Fails and Win Web3 Hackathons, using BuildBear Testnet’s Analytics)
We have secured our RPC from BuildBear and have updated our .env file for the RPC endpoint.
We have updated our hardhat.config.js to the following:
To deploy your smart contract run the command npx hardhat run scripts/deploy.js --network buildbear
Once you have run the above command, the smart contract should have been deployed and your terminal will provide you with the address on which the smart contract has been deployed, as following:
(E) Interacting with our Smart Contract
💡 BONUS, you can interact with mine, thanks to BuildBear!!! (More on the benefits on BuildBear here, here and here)
Copy the address that is produced and then go to your private version of the BuildBear Explorer. You can visit mine at BuildBear | Explorer. My contract was deployed at 0x563e58726B6eDa7bfC1e13F645af4D1C11DAC702 and hence my contract is available at here.
Let’s start working on the Soul Bound KYC contract. For that go to the contracts tab on the above-mentioned page, over there you will see the option of Read Contract and Write Contract. To find the details about the contract like the owner and balance, you can go to Read Contract. But we will first go to Write Contract page and create our own user.
I create my account using the signup function of the smart contract.
You can view this transaction using this link. This transaction was successful which means I have successfully created the account and now I can use this account to sign in.
In the transaction, you can go to the “Trace” tab and analyse the entire transaction you did step-by-step. It displays all functions you called, and the event then called due to it.
We can verify if the account has been created by signing in to the contract. For that let's go to the Read Contract tab again. Over there just enter the address with which you created the account and you will be able to sign in.
This was a basic tutorial on creating your own Authorisation system using Soul Bound Tokens. I hope you were able to understand and create your own system.
With BuildBear I was able to share my transactions with you and allow anyone, including you to interact with the contract. Yes, you can actually propose a transaction in my contract listed over here →
Use my private faucet over here to get as many native coins as you need and please do not hesitate to send me a transaction →
https://ethindia.faucet.buildbear.io/Straight_Nien_Nunb_04eaabb2
In case you face any difficulties while implementing the smart contract, let us know in the comments and we will help you in figuring it out. For any other feedback or suggestions please feel free to reach me in the comments section.
To learn more about BuildBear, read here docs
Get the above Github code from here.
If you appreciate what we are doing, please follow us on Twitter and Join the Telegram group if you haven’t done yet.
And please give us a clap 👏 if you like our work and please do share this article.
Thank you.
Author: