Soulbound Tokens in Cardano

[GENERAL] Name and surname of main applicant

Matias Falcone

[GENERAL] Email address of main applicant

matias.falcone@gmail.com

Additional applicants

Manuel Padilla, manuelpad@gmail.com

[GENERAL] Please specify how many months you expect your project to last (from 2-12 months)

6

[GENERAL] Please indicate if your proposal has been auto-translated into English from another language.

No

[GENERAL] Does your project have any dependencies on other organizations, technical or otherwise?

No

[GENERAL] If YES, please describe what the dependency is and why you believe it is essential for your project’s delivery. If NO, please write “No dependencies.” .

No dependencies.

[GENERAL] Will your project’s output/s be fully open source?

Yes

[GENERAL] If NO, please describe which outputs are not going to be open source. If YES, please write “Project will be fully open source.”

Project will be fully open source.

[METADATA] Category of proposal

DAO

[IMPACT] Please describe your proposed solution.

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:

• Driver’s licenses can be issued as SBTs on the chain.
• SBTs can be utilized to prove lending credit. For instance, it can be issued to represent a loan you took, and when the loan is paid off, the issuer can revoke the SBT to send you proof of payment SBT.
• SBTs can be leveraged as a digital CV in web3 platforms adding to your credibility in the DeFi space.

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:

• Master Contract Management: allow administrators to set up and manage collections of SBTs
• Issuance of Tokens: facilitate the creation of lists of pre-approved wallets, the allocation of SBTs and the creation of credentials directly for users
• Credential Request Review: provide an interface to review and approve/reject user-submitted credential requests
• Credential Review/Revokation: provide an interface to review and suspend or revoke existing credentials

User interface:

• Request for Credentials: allow users to submit requests for credentials, which would include creating a datum in the Soulbound Token Contract
• Token Claim: once the badge request is approved, allow users to claim their SBT through this interface
• Status View: allow users to view the status of their credential and token (on request, approved, claimed)
• API/Webhook for Notifications: it is necessary to have an API or webhook that is in charge of notifying the administrators when a new datum is created in the Soulbound Token Contract. This will speed up the review and approval processes.

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:

• Selection of Verification Method: the user or the entity that wishes to verify the identity can do so through a provided web portal or directly through an API. It is important to note that the portal, under the hood, also uses the API to perform the verification.
• Wallet Connection: if it is a DApp, it may have a wallet connector functionality that allows the user to connect their wallet. By doing so, the DApp can access the public key of the user's wallet and the minting policy of the SBT that wants to validate, and can do the verification using the provided API.
• Provision of Necessary Data: for verification, two key pieces of information are needed: the public key of the wallet and the minting policy of the SBT of interest.
• Matching Collection Search: the API begins by querying the Master Contract for a collection that matches the provided minting policy. After finding the corresponding collection, it identifies the datum that this collection represents.
• Specific Soulbound Token Contract Identification: within the collection datum, the API finds the address of the specific Soulbound Token Contract associated with that collection.
• Credential Verification: the API checks against the specific contract, looking for a credential associated with the public key of the provided wallet. Checks if the credential exists, and if it is in 'approved' and 'claimed' status.
• Search Optimization through Synchronized Database: although the search for credentials could be done directly on the blockchain, the API uses an intelligent database that is synchronized with the blockchain network. This makes searching for data much more efficient, as it is performed as an SQL query against the database instead of searching the blockchain datum by datum.
• Verification result: finally, the API returns the verification result, indicating whether the credential is valid or not.
• Any entity or user can carry out this verification through the portal or the API or even by their own means by exploring the network and reading the corresponding datums.

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:

• POST /collections: prepare a transaction to create a new SBT collection.

Input parameters: name, description, managing wallets

Note: the transaction must be signed and sent to the blockchain through the frontend

• GET /collections: list all SBT collections created.
• GET /collections/{collection_id}: gets details of a specific collection.

Input Parameters: Collection ID

• PUT /collections/{collection_id}: prepares a transaction to update the details of a specific collection.

Input parameters: Collection ID, data to update (name, description, managing wallets)

Credentials:

• POST /collections/{collection_id}/credentials: prepares a transaction to create a new credential within a specific collection.

Input parameters: Collection ID, wallet address, other credential details (name, email, etc.)

• GET /collections/{collection_id}/credentials: list all the credentials within a specific collection.

Input Parameters: Collection ID.

• GET /collections/{collection_id}/credentials/{credential_id}: gets the details of a specific credential within a collection.

Input parameters: Collection ID, Badge ID

• PUT /collections/{collection_id}/credentials/{credential_id}: prepares a transaction to update or modify the details of a specific credential.

Input parameters: collection ID, credential ID, data to update

• POST /collections/{collection_id}/credentials/{credential_id}/validate: prepares a transaction to validate a specific credential.

Input parameters: Collection ID, Badge ID

• POST /collections/{collection_id}/credentials/{credential_id}/revoke: prepares a transaction to revoke a specific credential.

Input parameters: Collection ID, Badge ID

• GET /collections/{collection_id}/credentials/search: gets the details and status of the credential associated with a specific wallet address within a collection.

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.

[IMPACT] How does your proposed solution address the challenge and what benefits will this bring to the Cardano ecosystem?

The DAOs Challenge focuses on these points:

• Creation of tools that offer superior features to those offered on other chains: by developing a powerful and reliable REST API, we offer a very strong an innovative solution for managing SBTs, something that has not yet been seen in other blockchains.
• Creation of Effective Collaboration Management Platforms to Organize Community Intentions and Actions: as we have mentioned before, SBTs can be utilized to facilitate governance in DAOs and, as a consequence, foster effective collaboration to organize community intentions and actions.
• Creation of additional not yet existing tools to give Cardano a distinct advantage: again, the proposed REST API does not exist in other blockchains.
• Creation of tools for prospective organizations to use in evaluating the features available in Cardano DAO's
• DAO community collaboration: already mentioned
• DAO creation: we may attract new DAOs to Cardano's ecosystem if it is interested in SBTs and they hear of our innovative REST API
• DAO operation: can be enhanced by the introduction of SBTs and all its innovative use cases
• DAO governance: already mentioned

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.

[IMPACT] How do you intend to measure the success of your project?

To measure the success of the project, several key metrics will be considered:

1. Adoption and Usage: The number of DAOs, organizations, institutions, and individuals actively using the Soulbound Tokens (SBTs) system can indicate the level of adoption. Tracking the growth in the number of collections created, credentials issued, and SBTs claimed can provide insights into the project's popularity and usage.
2. Transaction Volume: Monitoring the number of transactions within the SBT ecosystem can reflect the level of activity and engagement.
3. User Feedback and Satisfaction: Gathering feedback from users, including administrators, individuals, and third-party verifiers, can provide valuable insights into their satisfaction with the system. Conducting surveys, interviews, or implementing feedback mechanisms within the web portal and API can help gauge user sentiment and identify areas for improvement.
4. Credential Verification Requests: Monitoring the number of verification requests made through the Credential Verification Portal can indicate the external demand for validating SBTs. Higher verification requests imply that the system is being recognized as a trusted source for credential verification by external entities.
5. Integration and Partnerships: Tracking the number of partnerships or integrations with external platforms, DAOs, institutions, or organizations can demonstrate the project's growth and acceptance within the broader ecosystem. Collaborations with universities, companies, or decentralized applications (DApps) that leverage SBTs can expand the user base and increase visibility.
6. Community Engagement: Evaluating the level of engagement within the Cardano community regarding SBTs can be valuable. Monitoring discussions, forums, social media channels, and developer contributions can indicate community interest, active participation, and the potential for future developments and improvements.

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.

[IMPACT] Please describe your plans to share the outputs and results of 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:

• ADAO
• ADAPlaces
• ALDEA
• Adapulse
• Black Doge Club
• Bloom
• Boss DAO
• CETF
• CHROMA Token
• CTimelines
• Camelcoin
• Cardano 4 Climate
• Cardano Doctrinal Gold
• Cardano Link
• Cardano Media Taiwan
• Catalyst Swarm
• Crypto College
• Cryptobus.FM
• Deentra
• DirectEd Development Foundation
• EpochSec
• FIRE Token
• FreeLoaderz
• Gimbalabs
• IDO DAO PASS
• Innovatio
• LATAM Cardano Community
• Lido Nation
• Lovelace Academy
• Osmium DAO
• Paideia
• Project Catalyst
• Raqoon.io
• Rare Bloom
• RatsDAO
• SANADA
• Simple Cardano
• StripperCoin
• Summon Platform
• Sustainable ADA
• Syyx
• The Alexandria Project
• The Cardano Lounge
• The Monet Society
• Token Allies
• TosiDrop
• TurtleDAO
• Veritree
• Voteaire
• Wada
• WrappedGloveCoin
• Zero to Haskell
• Zombie Chains DAO
• adafilms
• cNFT meme-DAO
• cNFTcon
• slfdrvn.io

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.

[CAPABILITY/ FEASIBILITY] What is your capability to deliver your project with high levels of trust and accountability?

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:

• Fund5 / Project ID 500003: ALDEA Catalyst
• Fund5 / Project ID 500004: ALDEA WIKI
• Fund7 / Project ID 700019: ALDEA NFT - Community Marketplace

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:

• Some of our smart contracts will be deployed in Milkomeda using Solidity
• Some of our smart contracts will be deployed in Cardano using Plutus
• Our frontend will be built using Nuxt.js and integrated with the blockchain using web3 and ethers libraries
• Our REST API will be built using Node.js

We have demonstrated experience in all these technologies (please check personal websites and portfolio in the "Project Team" section).

[CAPABILITY/ FEASIBILITY] What are the main goals for the project and how will you 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:

1. Number of Soulbound Token collections created: This metric measures the success of enabling the creation of collections. It can be measured by counting the total number of collections created within a specific time period.
2. Number of managing wallets assigned to collections: This metric indicates how many managing wallets have been assigned to different collections. It measures the effectiveness of managing and distributing responsibilities among administrators.
3. Feedback from administrators: Conduct surveys or interviews with administrators to gather their feedback on the usability, functionality, and effectiveness of the tools provided for creating and managing Soulbound Token collections. This qualitative feedback can provide insights into the success of achieving this objective.

Objective 2: Facilitate the issuance and allocation of Soulbound Tokens to users

Measurement:

1. Number of pre-approved wallets: Measure the number of wallets that have been pre-approved to receive Soulbound Tokens. This metric reflects the success of streamlining the token issuance process and ensuring the authenticity of the recipients.
2. Number of credential requests submitted by users: Track the number of credential requests submitted by users. This metric indicates the level of interest and engagement from users in obtaining Soulbound Tokens.
3. Approval rate of credential requests: Measure the percentage of credential requests that are approved by administrators. This metric reflects the efficiency and effectiveness of the review process and the alignment between requested credentials and the intended purpose.
4. Time taken to approve/reject credential requests: Measure the average time taken by administrators to review and approve/reject credential requests. This metric evaluates the speed and responsiveness of the system in addressing user requests.
5. Number of claimed Soulbound Tokens: Measure the number of tokens that have been successfully claimed by users. This metric reflects the successful allocation of tokens to users after their credential requests are approved.

Objective 3: Provide a credential verification portal for third-party verification

Measurement:

1. Usage statistics of the verification portal: Track the number of visits, unique users, and page views on the credential verification portal. This metric indicates the level of engagement and adoption of the portal by third-party verifiers.
2. Feedback from third-party verifiers: Gather feedback from external entities or users who have utilized the verification portal to validate credentials. Conduct surveys or interviews to understand their satisfaction with the portal's functionality, ease of use, and accuracy of verification.
3. Response time of the verification portal: Measure the average time taken by the verification portal to respond to verification requests. This metric evaluates the efficiency and performance of the portal in retrieving and validating data from the blockchain.
4. Accuracy of verification results: Track the percentage of verification results that accurately determine the validity or invalidity of credentials. This metric reflects the reliability and correctness of the verification process performed by the portal.
5. Integration with external systems: Measure the successful integration of the verification portal with other systems or platforms through APIs. This metric indicates the flexibility and compatibility of the portal with different verification workflows.

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.

[CAPABILITY/ FEASIBILITY] Please provide a detailed breakdown of your project’s milestones and each of the main tasks or activities to reach the milestone plus the expected timeline for the delivery.

Milestone 1: Project Initiation and Design

• Task 1.1: Define the objectives and scope of the project.
• Task 1.2: Define the roles.
• Task 1.3: Create a project schedule.
• Task 1.4: Design the system architecture.
• Deliverable: Project initiation and architecture design document.
• Duration: 3 weeks
• Cost: USD 7,500

Milestone 2: Smart Contracts Design and Development

• Task 2.1: Design the smart contracts.
• Task 2.2: Define the structure of the datums.
• Task 2.3: Code smart contracts.
• Task 2.4: Perform unit tests of the contracts.
• Deliverable: Repository with the Smart Contracts coded and tested.
• Duration: 5 weeks
• Cost: USD 12,500

Milestone 3: REST API and Web Portal Development

• Task 3.1: Set up the API development environment.
• Task 3.2: Develop the REST API.
• Task 3.3: Perform API unit tests.
• Task 3.4: Set up the web development environment.
• Task 3.5: Develop the user and administrator interface.
• Deliverable: Repository with the REST API and Web Portal developed and tested.
• Duration: 5 weeks
• Cost: USD 12,500

Milestone 4: Integration and Notification System

• Task 4.1: Integrate the web portal with the REST API.
• Task 4.2: Integrate the web portal with the smart contracts.
• Task 4.3: Develop the alert mechanism and webhook.
• Task 4.4: Integrate the notification system with the web portal and the REST API.
• Deliverable: Repository with integrated Web Portal, REST API, Smart Contracts and Notification System.
• Duration: 3 weeks
• Cost: USD 7,500

Milestone 5: Testing, Deployment on Testnet and Gathering Feedback

• Task 5.1: Deploy contracts on the testnet network.
• Task 5.2: Perform integration tests on the testnet network.
• Task 5.3: Open the system in testnet to a group of selected users.
• Task 5.4: Collect and analyze user feedback.
• Deliverable: Link to website. Repository with the Portal. Testnet integration test report. User feedback report.
• Duration: 4 weeks
• Cost: USD 10,000

Milestone 6: Final Adjustments and Deployment on Mainnet

• Task 6.1: Make adjustments based on user feedback.
• Task 6.2: Deploy contracts on the mainnet network.
• Task 6.3: Perform integrity tests on the mainnet.
• Deliverable: System deployed on the mainnet network. Link to the website.
• Duration: 4 weeks
• Cost: USD 10,000

[CAPABILITY/ FEASIBILITY] Please describe the deliverables, outputs and intended outcomes of each milestone.

Milestone 1: Project Initiation and Design

• Deliverables: A comprehensive project initiation and architecture design document. This will include project objectives, identification of roles, project schedule, and system architecture design.
• Intended Outcomes: Establishing a clear direction for the project, setting expectations, and planning resources required for the project. The architecture design will serve as the blueprint for the development phase.
• Measures of Progress: The completion of the project initiation and architecture design document.

Milestone 2: Smart Contracts Design and Development

• Deliverables: A repository containing smart contracts that are coded and tested. This includes the design of smart contracts, definition of data structures, code, and results of unit tests.
• Intended Outcomes: Creation of robust smart contracts that fulfill the requirements of the project and are free from critical vulnerabilities.
• Measures of Progress: The completion of smart contract code, unit test results, and the final repository with all the code and documentation.

Milestone 3: REST API and Web Portal Development

• Deliverables: A repository containing the developed REST API and Web Portal with unit test results. This includes API endpoints, user and administrator interface designs.
• Intended Outcomes: Creation of a functional API and Web Portal that interact efficiently with the blockchain through smart contracts.
• Measures of Progress: The completion of API development, web portal development, and unit tests for both.

Milestone 4: Integration and Notification System

• Deliverables: A repository with an integrated Web Portal, REST API, Smart Contracts, and Notification System. Includes alert mechanisms, webhooks, and integration documentation.
• Intended Outcomes: Ensuring seamless interaction between different components (Web Portal, API, Smart Contracts) and enabling real-time notifications.
• Measures of Progress: Successful integration of components and functionality of the notification system.

Milestone 5: Testing, Deployment on Testnet, and Gathering Feedback

• Deliverables: Link to the website on testnet, repository with the Portal, Testnet integration test report, user feedback report.
• Intended Outcomes: Testing the application on the testnet to identify and fix issues before deploying to mainnet. Also, collecting user feedback for further improvements.
• Measures of Progress: Successful deployment on testnet, completion of integration tests, and gathering feedback from users.

Milestone 6: Final Adjustments and Deployment on Mainnet

• Deliverables: The final system deployed on the mainnet network with a link to the website.
• Intended Outcomes: A fully functional application deployed on the mainnet, ready for real-world use.
• Measures of Progress: Successful deployment on the mainnet and passing integrity tests.

What will be measured to track the project's progress

• Completion of deliverables for each milestone
• Achieving the intended outcomes as mentioned above
• Time taken compared to the initial schedule
• Quality of documentation and code produced
• User feedback and results from testing phases

How will it be measured

• Regular progress reports and meetings
• Code and documentation reviews
• User feedback forms and analysis
• Testing results and analysis

[RESOURCES & VALUE FOR MONEY] Please provide a detailed budget breakdown of the proposed work and resources.

Milestone 1: Project Initiation and Design

• Task 1.1: Define the objectives and scope of the project: USD 1,500
• Task 1.2: Define the roles: USD 500
• Task 1.3: Create a project schedule: USD 2,000
• Task 1.4: Design the system architecture: USD 1,000
• Project Management: USD 2,500
• Deliverable: Project initiation and architecture design document.
• Duration: 3 weeks
• Cost: USD 7,500

Milestone 2: Smart Contracts Design and Development

• Task 2.1: Design the smart contracts: USD 1,500
• Task 2.2: Define the structure of the datums: USD 500
• Task 2.3: Code smart contracts: USD 4,500
• Task 2.4: Perform unit tests of the contracts: USD 2,000
• Project Management: USD 4,000
• Deliverable: Repository with the Smart Contracts coded and tested.
• Duration: 5 weeks
• Cost: USD 12,500

Milestone 3: REST API and Web Portal Development

• Task 3.1: Set up the API development environment: USD 500
• Task 3.2: Develop the REST API: USD 4,000
• Task 3.3: Perform API unit tests: USD 1,000
• Task 3.4: Set up the web development environment: USD 500
• Task 3.5: Develop the user and administrator interface: USD 2,500
• Project Management: USD 4,000
• Deliverable: Repository with the REST API and Web Portal developed and tested.
• Duration: 5 weeks
• Cost: USD 12,500

Milestone 4: Integration and Notification System

• Task 4.1: Integrate the web portal with the REST API: USD 1,500
• Task 4.2: Integrate the web portal with the smart contracts: USD 1,500
• Task 4.3: Develop the alert mechanism and webhook: USD 1,000
• Task 4.4: Integrate the notification system with the web portal and the REST API: USD 1,000
• Project Management: USD 2,500
• Deliverable: Repository with integrated Web Portal, REST API, Smart Contracts and Notification System.
• Duration: 3 weeks
• Cost: USD 7,500

Milestone 5: Testing, Deployment on Testnet and Gathering Feedback

• Task 5.1: Deploy contracts on the testnet network: USD 1,000
• Task 5.2: Perform integration tests on the testnet network: USD 2,500
• Task 5.3: Open the system in testnet to a group of selected users: USD 1,500
• Task 5.4: Collect and analyze user feedback: USD 1,500
• Project Management: USD 3,500
• Deliverable: Link to website. Repository with the Portal. Testnet integration test report. User feedback report.
• Duration: 4 weeks
• Cost: USD 10,000

Milestone 6: Final Adjustments and Deployment on Mainnet

• Task 6.1: Make adjustments based on user feedback: USD 2,000
• Task 6.2: Deploy contracts on the mainnet network: USD 1,000
• Task 6.3: Perform integrity tests on the mainnet: USD 3,500
• Project Management: USD 3,500
• Deliverable: System deployed on the mainnet network. Link to the website.
• Duration: 4 weeks
• Cost: USD 10,000

Total Duration: 24 weeks (6 months)

Total Cost: USD 60,000 | ADA = 0.2843 | 211,044 ADA

[RESOURCES & VALUE FOR MONEY] How does the cost of the project represent value for money for the Cardano ecosystem?

The cost of the project represents value for money for the Cardano ecosystem in several ways:

1. Innovative Solution: The project introduces a novel protocol for implementing Soulbound Tokens (SBTs) on the Cardano blockchain, addressing a current gap in the ecosystem. By investing in the development and implementation of this solution, Cardano can stay at the forefront of blockchain technology and offer unique features to its users.
2. Enhanced Utility: The introduction of SBTs brings added utility to the Cardano ecosystem by enabling the verification and validation of various credentials and information on the blockchain. This can have significant benefits across domains such as education, job applications, health records, governance, NFT trading, driver's licenses, lending credit, and more. These use cases enhance the overall value proposition of Cardano, attracting more users and applications to the network.
3. Differentiation: By implementing SBTs and providing the necessary infrastructure through web portals, credential verification portals, and REST APIs, Cardano sets itself apart from other blockchain networks. It offers a comprehensive solution that combines blockchain technology with user-friendly interfaces, making it easier for individuals and organizations to leverage SBTs for various purposes. This differentiation can attract users and projects to choose Cardano over other platforms.
4. Community Collaboration: The proposed Cardano Improvement Proposal (CIP) for SBTs demonstrates a community-driven approach to developing and implementing new features. By involving the Cardano community in the discussion and development process, the project fosters collaboration, knowledge sharing, and collective decision-making. This community involvement adds value by ensuring that the solution meets the needs and expectations of various stakeholders within the Cardano ecosystem.
5. Long-Term Value: The introduction of SBTs and the associated infrastructure can create long-term value for the Cardano ecosystem. As more users and projects adopt SBTs for verification, the network effect can amplify the value of the ecosystem. SBTs can become a standard and trusted method for identity verification, reputation building, and information sharing on the Cardano blockchain. This can attract further adoption, partnerships, and growth, ultimately benefiting the entire ecosystem.

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.

[IMPORTANT NOTE] The Applicant agreed to Fund10 rules and also that data in the Submission Form and other data provided by the project team during the course of the project will be publicly available.

I Accept