Last updated 3 months ago
It is not possible to issue Soulbound Tokens (tokens that are not transferable) in Cardano.
This is the total amount allocated to Soulbound Tokens. 3 out of 4 milestones are completed.
1/4
Project Initiation, Smart Contracts & CIP
Cost: ₳ 30,000
Delivery: Month 1 - Apr 2024
2/4
AdaSouls - User Interface
Cost: ₳ 30,000
Delivery: Month 2 - May 2024
3/4
AdaSouls API & Notification System
Cost: ₳ 25,000
Delivery: Month 3 - Jun 2024
4/4
Project Closure Report
Cost: ₳ 15,000
Delivery: Month 4 - Jul 2024
NB: Monthly reporting was deprecated from January 2024 and replaced fully by the Milestones Program framework. Learn more here
We will create a smart contract that will manage the datums that represent each existing instance or collections of Soulbound Tokens. This way, any developer will be able to issue SBTs in Cardano.
No dependencies.
Project is already fully open source under the MIT Licence and will continue to be that way.
Introduction
Since May 2022, when Decentralized Society: Finding Web3's Soul was initially published, the Ethereum community has released 7 different Ethereum Improvement Proposals (EIPs) to explore the concepts introduced by this paper. And in just a few months, many other projects have followed, such as Solana and Algorand. On the contrary, Cardano community is not yet exploring these interesting and promising notions.
The blockchain space is a fast evolving ecosystem. If we don’t explore innovative solutions, we risk losing traction versus other networks that may implement these tools in a much more efficient and reliable way.
What is a Soulbound Token (SBT)?
The term soulbound originates from online multiplayer games. Certain collectible in-game items that are unusually powerful or require an impressive feat to acquire cannot be traded or given to any other player and are effectively tied to a player’s “soul”. Soulbound NFTs work the same way, acting as a badge or verification about whomever owns the token. Because these tokens are permanent and can’t be given away, they carry validity that can be verified using the blockchain.
Early internet verification depended on simple email accounts and passwords stored on individual servers. As the internet moved into “Web 2.0,” that system evolved to allow the use of a federated identity — a single credential, such as an account with Facebook, Twitter, or Google — to access various apps and domains. Those seeking a decentralized, next iteration of the internet, or “Web 3.0”, see proven verification through SBTs as the next method of identifying oneself online.
What is the potential of SBTs?
Because SBTs can never be transferred or given away, it can represent a wide range of individual-specific information or identification that would be difficult to represent online easily. While it allows for a personal ID to be verified to one’s digital wallet, where the tokens are held, it would be just as easy to have a verified college degree or medical records housed in the same way. This allows holders to identify themselves online easily or share important verifiable information with others.
Beyond indicating a verifiable achievement such as earning a degree, SBTs can also be used to build digital reputations. A user’s borrowing history or credit score could easily be represented as a SBT, giving companies a quick and efficient way to track economic data related to individuals. SBTs have an almost unlimited potential for representing different kinds of personal information, so it can be easily verifiable and shareable online.
What benefits do they bring to DAOs and Cardano projects?
As per this Vitalik’s tweet, whether you agree with it or not, there could be opportunities where it makes more sense to have non-transferable governance tokens. These tokens would be attached or linked to our wallet and can be issued by other individuals, organizations, companies, communities or DAOs (we will call them "Souls"). By having non-transferable SBTs, DAOs can ensure that the control stays in the hands of users who genuinely care about the project.
More use cases of SBTs
Although the concept of SBTs has been formulated so far, and the development of SBTs is still in its infancy, it finds potential use cases in specific domains.
Education history: one of the significant use cases of SBTs is issuing a person’s educational history. In a traditional learning system, when a student graduates, educational institutions issue a certificate that proves the completion of their courses. In the context of decentralized identity, the educational institution could be a Soul issuing the SBTs to its students, and the students themselves would be Souls on the receiving end. The SBT would contain a student’s credentials, authenticating their relevant qualifications and proving their university membership. SBTs can, thus, act as proof of attendance. If SBTs replace traditional degree-issuing processes and proof of attendance in the upcoming years, it can ensure that no one forges their educational details and qualifications. Because SBTs are non-transferable and cannot be sold to others. Also, it can be issued only by training providers and universities.
Job Applications: similar to its use case in the educational industry, SBTs can be leveraged to store work history and professional certificates. Companies can issue their employees’ work experience, projects they have worked on, details of their achievements and other information in the form of SBTs, which the employees’ can later produce while hunting for other jobs or during interviews. In this case, SBTs will act as proof of skill certificates.
Health Records: SBTs in the healthcare domain holds a person’s medical records. The primary benefit of introducing SBT for health records is that it can accelerate the process of switching doctors or healthcare providers. Theoretically, SBTs can replace the generally slow process of filling out paperwork, validating your medical history and the continuous task of approaching different people.
Governance: as we mentioned before, DeFi protocols and DAOs award early users with airdrop tokens for trusting and supporting the project. These tokens serve as voting rights. But, in the current scenario, any wealthy person or entity can buy these tokens from the early users, influencing voting rights without actually earning them. Often, people willing to spend a lot to buy governance rights often stand to benefit directly by influencing the vote. Giving non-transferrable SBTs to early users can ensure that the control stays in the hands of users who genuinely care about the protocol.
NFT Trading: SBTs can filter out bad apples who misuse the names of famous artists to sell NFT collections to unsuspecting buyers. So, how does this work? Legit NFT artists can tie SBT to their NFT collection and their Soul. NFT collectors can then compare the SBT of the NFT collection with that of the artist’s Soul. If the SBT matches, the buyers can purchase the NFT; if not, it can be confirmed as a counterfeit NFT. As such, SBTs help verify whether an NFT collection is legit.
Other than the use cases mentioned earlier, SBTs have practical applications in the following:
Proposed Solution
Introduction
In Cardano's blockchain, there is no easy implementation for Soulbound Tokens. Specifically, there is no way to prevent a user from transferring tokens from their wallet to another. Our innovative protocol addresses this problem by using tokens and smart contracts to link and verify a user's credentials with a specific wallet. This is done as part of what we call Soulbound Tokens Collections.
A collection of SBTs represents a particular group or category. Each SBT within a collection is intended for a specific purpose and is tied to certain credentials.
For example, we might have a collection called "University X: Engineering Graduates". The tokens within this collection would be tied to the credentials of individuals who have graduated from Engineering at University X. This could include information such as the graduate's name, graduation year, and other relevant data. Another collection example could be "Members of Chess Club Y", where the tokens would be associated with the credentials of the members of a specific chess club.
Smart Contracts
A central smart contract, called the "Master Contract", will be established. This contract will be in charge of managing the datums that represent each existing instance or collection of SBTs. Administrators will be able to configure authorized wallets to manage the datum and store details such as name, description, etc. A secondary contract and a specific minting policy will also be created for each collection.
Each collection will have a specific contract called a "Soulbound Token Contract". This contract will manage the datums created for each issued SBT, that we will also call "Credentials". Each datum will store the information of the wallet to which it is linked and other optional parameters such as name, email, registration date, etc. This datum will be accompanied by the SBT that each user can claim individually.
Issuance and Allocation of Tokens
Admins have the ability to create lists of wallets that will be pre-approved to receive SBT and will make this list available to the "Soulbound Token Contract", on a specific datum for that purpose. This means that a whitelist of wallets that are authorized to receive tokens is created. For example, if a group of students at a university is meant to receive tokens, administrators can include the wallet addresses of these students on a pre-approved list. It should be noted that there is a limit to the number of wallets that can be stored on a single datum, which restricts the number of wallets that can be pre-approved.
Administrators also have the option to create credentials directly for users, without waiting for the users to request them. In this case, these credentials will be in an 'approved' state from the moment they are created, and will be stored as a datum within the "Soulbound Token Contract".
Users who want to get credentials and SBTs can make a request by creating a credential. This implies the creation of a new datum in the "Soulbound Token Contract". Initially, this request will be in the 'on request' state. An alert mechanism will be implemented in the blockchain to detect new datums in the "Soulbound Token Contract", and through a webhook the administrators will be notified of the existence of new requests.
Once notified, administrators can review requests submitted by users. For each request, administrators have the option to approve or reject it. If approved, the credential changes its status to 'approved'.
After a user's token has been approved, the user has the option to claim their SBT. When claimed, the credential changes status to 'claimed'. At this point, the SBTs are minted and allocated to the user's wallet.
Alternatively, administrators can choose to directly send the SBT to the user's wallet. This means that, based on pre-approved credentials, administrators can mint the tokens and deliver them directly to users' wallets. This can be useful in situations where administrators want to speed up the token distribution process.
In addition to this, administrators have the ability to terminate or suspend a credential, either temporarily or indefinitely. This could be necessary in cases of fraud, disassociation of the user with the entity that represents the token, or any other circumstance that justifies the revocation of the credential.
Components
WEB PORTAL
Admin Interface:
User interface:
Credential Verification Portal: for external verification purposes, a portal will be created that allows third parties to verify the authenticity of a user's credentials without needing to directly interact with the blockchain. These are the features that it will have:
REST API
A REST API will be available to allow extensive interaction with the protocol. This will allow our portal to not be the only means of access to these features. The API will allow all types of queries and will make it easy to perform functions such as creating new collections of SBTs and assigning or rejecting credentials. The REST API in the project will act as a facilitator to interact with the blockchain and will not directly perform the creation or modification of data on the blockchain. This is because the creation and modification of data on the blockchain requires transactions to be signed by a private wallet.
The following details the process of using our REST API:
1) Wallet Connection: before performing any operation that modifies the blockchain, the user must connect their wallet through a wallet connector on the frontend
2) REST API Request: the frontend makes a request to the REST API to create or update data. The API prepares the necessary transaction but does not send it to the blockchain.
3) Transaction reception: the frontend receives the transaction prepared by the API
4) Transaction Signature: using the wallet connector, the user signs the transaction with his private wallet
5) Sending the Transaction: once signed, the transaction is sent to the blockchain through the frontend
Endpoints
Collections:
Input parameters: name, description, managing wallets
Note: the transaction must be signed and sent to the blockchain through the frontend
Input Parameters: Collection ID
Input parameters: Collection ID, data to update (name, description, managing wallets)
Credentials:
Input parameters: Collection ID, wallet address, other credential details (name, email, etc.)
Input Parameters: Collection ID.
Input parameters: Collection ID, Badge ID
Input parameters: collection ID, credential ID, data to update
Input parameters: Collection ID, Badge ID
Input parameters: Collection ID, Badge ID
Input parameters: collection ID, wallet address
Output parameters: Credential details and status ('on request', 'approved', 'claimed', etc.).
CARDANO IMPROVEMENT PROPOSAL (CIP)
In addition to all this, we propose the creation of a Cardano Improvement Proposal (CIP) on SBTs, so we can address this feature in a single and coordinated community effort. AdaSouls will be the first working implementation of this CIP.
PROOF OF CONCEPT
You can check the proof of concept of Soulbound Tokens in Cardano here.
What impact will this project have for Cardano?
We have seen a lot of projects exploring SBTs in the Ethereum ecosystem and 7 different EIPs around them in the past year. By introducing a new CIP and by starting to talk about these concepts in Cardano, we believe that new use cases (not only for DAOs) will be explored and new ideas will arise. In addition to this, if we implement a straightforward and easy to integrate standard, we might attract projects to our ecosystem that, right now, can only build these solutions in other blockchains.
How will we measure this impact?
To measure the success of the project, several key metrics will be considered:
It is important to define specific goals and targets for each metric and regularly track and analyze the data to assess the project's success over time. Additionally, considering qualitative factors such as user testimonials, case studies, and the impact of SBTs on various domains can provide a comprehensive understanding of the project's effectiveness.
How will we share the outputs and opportunities that result from your project?
We will share all our updates with the Cardano community, so everyone is up to date with what we are doing. We will put special emphasis in the Community and DAO projects, as they are the potential users of the tools we develop. This includes important projects in Cardano such as:
In addition to this and as 100% of the project deliverables and outputs will be open source, all our research and development activities will be available in GitHub for any community member to consult and use.
Our team has demonstrated in the past that can be trusted and that is capable of managing funds properly, as we have successfully delivered 3 proposals from Fund5 and Fund7:
In addition to this, we count with Full Stack Engineers, Plutus Devs and Senior Solidity Developers (with 5 years experience with EVM blockchains). These skills make our team best suited to deliver this project because:
We have demonstrated experience in all these technologies (please check personal websites and portfolio in the "Project Team" section).
How do we intend to validate if your approach is feasible?
The project aims to implement SBTs on the Cardano blockchain, allowing for the verification and issuance of credentials tied to specific wallets. The proposed solution involves the use of tokens and smart contracts to link and verify user credentials, creating collections of SBTs for different purposes.
Under this scope, we identify the following 3 main objectives:
Objective 1: Enable the creation and management of Soulbound Token collections
Measurement:
Objective 2: Facilitate the issuance and allocation of Soulbound Tokens to users
Measurement:
Objective 3: Provide a credential verification portal for third-party verification
Measurement:
It is important to regularly monitor and analyze these metrics to assess the progress and success of the objectives. By setting specific targets or benchmarks for each metric, you can track the performance and make adjustments to improve the system's effectiveness and user satisfaction.
Milestone 1: Project Initiation and Design
Milestone 2: Smart Contracts Design and Development
Milestone 3: REST API and Web Portal Development
Milestone 4: Integration and Notification System
Milestone 5: Testing, Deployment on Testnet and Gathering Feedback
Milestone 6: Final Adjustments, Deployment on Mainnet and Final Project Completion Report
The project team for the proposed work on building the AdaSouls platform and REST API in Cardano consists of Matias Falcone & Leobel Izquierdo. They will take care of project management and will undertake various aspects of the development, as their skills and experience perfectly align with the requirements of the project.
Matias Falcone
Leobel Izquierdo
If additional team members are recruited, specific skills such as front-end development, blockchain integration, documentation, and community management will be sought.
Milestone 1: Project Initiation and Design
Milestone 2: Smart Contracts Design and Development
Milestone 3: REST API and Web Portal Development
Milestone 4: Integration and Notification System
Milestone 5: Testing, Deployment on Testnet and Gathering Feedback
Milestone 6: Final Adjustments and Deployment on Mainnet
Total Duration: 24 weeks (6 months)
Total Cost: USD 60,000 | ADA = 0.37 | 162,162 ADA (as the costs exceed the cap for this challenge, we can only ask for 100,000 ADA)
The cost of the project represents value for money for the Cardano ecosystem in several ways:
The proposed costs are based on industry standards in Melbourne, Australia (where our team is based). You can find the average salary of a Full Stack Developer in Melbourne, Australia here, which is AUD 120,000 a year, or USD 6,600 a month more or less. Even taking all this into consideration, we have decided to apply a monthly salary of USD 5,000 to our budget calculation for both of our developers (USD 1,600 deduction per month per developer), so this can represent more value for money for the Cardano community.