subHandles | ADA Handle

[IMPACT] Please describe your proposed solution.

Multiple Cardano-based organizations have requested from us a subHandle feature, to enable them to issue multiple subHandles associated with their root Handles, in order to assign these subHandles to all the different tasks wherein they need unique but related Handles, but without having to improvise a solution using hyphens, underscores or full stops. The need for subHandles include managing and tracking different corporate wallets, being transparent with their stakeholders (community, investors, etc.) by giving them a tool to easily locate DAO-related tokens and funds, simplifying payroll, monitoring funds in a smart contract, and identifying all company-related wallets. They also claimed that there will likely be other use cases that have not yet been accounted for, given the flexibility and options available for Handles on the Cardano blockchain.

A few projects have already improvised a similar solution using, as per above, hyphens, underscores and full stops. Examples of these improvised solutions, using a fictitious company name (ACME), are $acme, $acme.treasury, $acme.ispo and $acme.savings. This improvised solution achieves the desired end results but does so in an imperfect manner that has several inherent limitations. These limitations can lead to security and branding problems.

Given that it is virtually impossible for all brands to reserve all variations using hyphens, underscores and full stops, organizations cannot guarantee that cybersquatters won't purchase variations of their root Handles, such as $acme.janedoe and $acme.johndoe, creating a security and future-proofing problem.

Multiple organizations have also reached out to us to specifically request a solution to increase transparency with their stakeholders –such as investors, ISPO participants, developers, and the Cardano community– because as of today, all wallets associated with a specific company need to be set up with a unique Handle that, as per above, are not tied to a root Handle and thus prevents the community from easily tracking all wallets associated with a specific organization.

Last but not least, individuals have also expressed the desire to issue subHandles for family- and task-oriented wallets, and a few pool operators also expressed the wish to be able to issue subHandles for their delegators in order to build rapport, by allowing them to own john@pool and mary@pool, for example.

[IMPACT] Please describe how your proposed solution will address the Challenge that you have submitted it in.

SubHandles are the solution to this problem as they will enable projects to issue as many subHandles as they need from a single top-level root Handle. Each root Handle will have the option to mint any available subHandle.

There will be two formats of subHandles: NFT-based and Virtual. NFT-based subHandles will be nearly identical to all Handles that have been issued thus far. They will be minted in accordance with the NFT Metadata Standard (CIP-25).

Virtual subHandles, on the other hand, will exist as IPFS-hosted JSON-formatted datasets, that will be associated with unique Smart Contracts. These Smart Contracts will be set up in such a way that only the root Handle owner will have permission to make changes to Virtual subHandles.

The need for Virtual subHandles derive from concerns raised by ADA Handle partners who described the situation wherein, for example, an NFT-based subHandle such as john@acme were to be issued and delivered to a team member's wallet, and that wallet subsequently compromised, or even in the event that the team member were to leave the organization without returning the NFT-based subHandle. In either case, the organization could end up in the situation in which it would no longer be able to recover that specific NFT-based subHandle. With Virtual subHandles, a simple metadata edit would allow them to revoke the subHandle or reissue it, associating it with any new wallet address.

NFT-based and Virtual subHandles will coexist enabling organizations to issue any number of either. For example, john@acme and mary@acme could be issued as Virtual subHandles, whereas treasury@acme and savings@acme could be issued as NFT-based subHandles. Thus, it will be entirely up to each organization to decide which ones will be NFT-based subHandles and which ones will be Virtual subHandles.

The minting process of Virtual and NFT-based subHandles will be similar to how root Handles are presently issued, whereby visitors access https://adahandle.com/mint and follow the minting logic. However, UI and UX will be greatly improved. Presently, users authenticate access to the minting portal via email, and Handles are then paid for individually. The new minting portal will replace email authentication by a CIP-30 (https://cips.cardano.org/cips/cip30/) webpage-based communication bridge, that will detect all root Handles within a wallet and present visitors with the option to mint related subHandles, without any quantity limitations. Subsequently, all chosen subHandles are added to a checkout cart that presents the customer with a single payment address for all items within it.

Additionally, Virtual and NFT-based subHandles will be associated with the exact same image layouts as root Handles presently are. Thus, although, as per above, Virtual subHandles won't be minted as actual NFTs (i.e., a Native Asset), they will contain the same Handle image and layout that we are all used to.

These are a few examples of how NFT-based and Virtual subHandles will be displayed on platforms, wallets and DApps:

[IMPACT] What are the main risks that could prevent you from delivering the project successfully and please explain how you will mitigate each risk?

The two new subHandle formats –NFT-based and Virtual– pose different risks. NFT-based subHandles are issued and delivered to wallets, as a regular NFT, and although they were minted by an authorized wallet that, at the time of minting, held the root Handle, the holder of the root Handle relinquishes total control of the subHandle once it's no longer within their wallet. This is true for any NFT and Native Asset on the Cardano blockchain, being that the blockchain is permission-less and decentralized. However, organizations might run into security issues if the NFT-based subHandle were lost or stolen. Therefore, organizations should choose wisely before issuing an NFT-based subHandle. ADA Handle will, as a palliative solution to NFT-based subHandles that are lost, create a "Verification" solution that will allow root Handle owners to authorize or deauthorize any given NFT-based subHandle. This solution will give projects the option to consult from a list and determine whether a subHandle attempting to interact with it is "verified."

Virtual subHandles, on the other hand, do not pose the same security risks for organizations as NFT-based subHandles do, since the root Handle owner can, at any time, revoke the association of subHandles from wallets. Therefore, in the event that a team member were to leave the organization or in the event that a wallet were to get compromised, the root Handle owner could either assign a new wallet to the subHandle in question or revoke it entirely, and because the subHandle only existed in a virtual format, it would immediately cease to exist. However, this Virtual subHandles pose a secondary problem wherein DApps, wallets and projects will all need to adopt this new Virtual subHandle Standard. The Virtual subHandle mechanics are being designed to be as easy to adopt as it was for projects to adopt NFT-based Handles. However, we understand that these additional steps pose a significant adoption risk. We have reached out to multiple partners to present them with this solution and they have unanimously stated that integrating Virtual subHandles to their platforms will be quick and straightforward.

[FEASIBILITY] Please provide a detailed plan, including timeline and key milestones for delivering your proposal.

Phase 1: Private TestNet

The goal of this phase is to give our team a private environment for testing, to prevent us from exposing too early all the solutions for subHandles. This private TestNet will give us a secure environment to develop without most of the inherent security risks associated with the public TestNet. This private TestNet will share resources with our other Fund9 proposal: Personalization (https://cardano.ideascale.com/c/idea/416681).

• Acquire servers and infrastructure.
• Spin up cluster and deploy private TestNet.
• Set up wallets and policy ID.
• Integrate existing ADA Handle minting engine.
• Integrate with wallets via the CIP-30 bridge.
• Authenticate root Handle ownership.
• Mint NFT-based subHandles.
• Issue Virtual subHandles.
• Integrate new IPFS CDN.
• Global speed tests with new IPFS CDN.
• Data-parsing logic with subHandles.
• Checkout cart with multiple subHandles.
• Disaster Recovery Plan updates.

Phase 2: Public TestNet

The goal of this phase is to port the code from our private TestNet to Cardano's public TestNet, in order to allow the community and partners to start testing the subHandles, so that we can ingest additional feedback to correct and improve the solution. During this phase we will also execute third-party security audits.

• Port over from Private TestNet.
• Coordinate integration with subset of partners.
• Mint NFT-based subHandles.
• Issue Virtual subHandles.
• Extensive testing with wallets.
• CIP-30 bridge testing.
• Website UI and UX upgrades.
• Community-focus group.
• Public TestNet launch.
• Feedback and adjustments.
• Load and queue testing.
• Security audit.

Phase 3: Marketing Efforts

The purpose of this phase of the project is to gain traction with the new subHandle standard so that our partners understand and implement the new NFT-based and Virtual subHandles, and also to gain community support. During this phase we will focus our undivided attention on explaining the subHandle Standard and will assist everyone with implementation. We will offer continuous support to all partners, DApps and the Cardano community. We will also use the opportunity to ingest additional feedback and implement the final touches to the new minting portal.

• API documentation update.
• Demonstration videos.
• Integration examples.
• Engagement with all partners.
• Communication efforts to speed up adoption.
• Social-media outreach, including AMAs.
• Roadmap with dates.
• Feedback & adjustments.

Phase 4: MainNet Launch

The purpose of the 4th and final phase is to port the code from the public TestNet onto MainNet. This will require upgrading our MainNet infrastructure, extensively testing our Disaster Recovery Plan, and implementing load and queue testing. Once all tests are executed on MainNet infrastructure (measuring thrice and cutting once), we'll determine the launch date. Our goal is to have zero downtime on the ADA Handle platform prior to launch.

• Infrastructure upgrade.
• Disaster Recovery Plan testing.
• Load and queue testing.
• Confirmation of schedule maintenance window.
• Confirmation of schedule launch date.
• Follow-up pre-launch security audit.
• Launch.

[FEASIBILITY] Please provide a detailed budget breakdown.

• Infrastructure Upgrade: U$8,500 (Split costs with subHandles)
• IPFS CDN Contract (first year): U$6,250
• Security Audit: U$12,500 (Split costs with subHandles)
• Web & Graphic Design: U$48,800 (488 hours @ U$100)
• Project Management: U$28,350 (405 hours @ U$70)
• Programming & Development: U$142,000 (1,200 hours @ U$120)

Total (5-6 months): U$246,400

[FEASIBILITY] Please provide details of the people who will work on the project.

PapaGoose – Master Platform Engineer (25+ years experience)

With a wide-ranging career that includes a decade of fintech experience, PapaGoose has become a specialist in enabling developers to self-serve over the entire application lifecycle. Providing workflows, standards, and automations, from concept origin, through application and security design, to infrastructure management, including production deployment and maintenance cycles.

Recently exited TradFi, in favor of blockchain and now guides projects in the Cardano community. Currently holding an executive position at Kora Labs - with the intent to build out a standard for NFT-based digital identity.

Conrad Cordeiro – InfoSec and Infrastructure Engineer (15+ years experience)

Information Security and Infrastructure management are Conrad's expertise. For over 15 years he's been supporting companies from the financial sector and for the last 10 years running his own business in New York. Hedge funds and private-equity firms were his main focus before transitioning to Cardano.

Conrad operates BLADE, a top 10 Cardano stake pool, on MainNet and TestNet, with over 60M ADA staked. Conrad was elected as a SundaeSwap Scooper and selected as a Milkomeda C1 validator. Conrad is a Co-Founder at ADA Handle and works full-time in implementing The Handle Standard.

Goose – Co-Founder @ ADA Handle / CEO @ Kora Labs

With a near decade-long stint in commercial lending in Silicon Valley Goose has sourced, structured, and executed a number of high profile loans to some of the largest tech companies in the world. Managing relationships with financial institutions, credit agencies, and competing financiers in order to provide the most cost-efficient, desirable and prompt loan lifecycles for clients has primed Goose for the fast-paced, community-focused, and technologically cutting-edge product management lifecycle that Web 3 has to offer. 

BigIrishLion – Master Platform Engineer

BigIrishLion has over 12 years of experience with web and software development with projects ranging from video game sites to archery training mobile applications.

He is a server-less evangelist and is proficient with Amazon Web Services and Google Cloud Platform.

[FEASIBILITY] If you are funded, will you return to Catalyst in a later round for further funding? Please explain why / why not.

Our goal is to have ADA Handle become self-sufficient, capable of funding its entire operation based on the sale of Handles and subHandles. This goal includes the migration of the Handle Standard to Cardano's sidechains and forks. However, when we launched the public sale of ADA Handle in March 2022, our financial planning was done assuming $ADA priced at or above U$1.00. Since then, our entire team has quit their day jobs to focus 100% on Cardano and ADA Handle but markets have deteriorated and our budget, that was initially calculated with $ADA at U$1.00, has now been cut by half, which is why we are applying to Project Catalyst Fund9. Should we get funded and should markets improve, we do not expect to need further funding. However, given the uncertainty and given that we are 4 team members, working full-time while living in the USA, we might need to.

[FEASIBILITY] Are you or any member of your team working on any other proposals in this Fund9?

[FEASIBILITY] Are you or your team working on any other proposals from previous Funds?

[AUDITABILITY] Please describe what you will measure to track your project's progress, and how will you measure these?

The tools, tactics and strategies we will use to monitor the key metrics for this proposal are:

• Our internal ERP software (ERPNext) with its Project Management framework that will allow us to monitor phase workflows.
• Daily standup meetings with the entire team to track individual progress and assist with specific tasks.
• Weekly & monthly reports to demonstrate what the team accomplished and determine the next tasks.
• External third-party audit that will check our work throughout the entire process.

[AUDITABILITY] What does success for this project look like?

• All DApps, wallets and the community adopt the new subHandle Standard.
• Organizations working on Cardano minting and issuing subHandles, utilizing them for authentication, organization and transparency.
• The minting portal and smart contracts work precisely as designed, without hitting any major headwinds.
• The new checkout cart working flawlessly, allowing multiple Handles and subHandles to be purchased.

[AUDITABILITY] Please provide information on whether this proposal is a continuation of a previously funded project in Catalyst or an entirely new one.

This proposal is not a continuation and was not previously funded by Catalyst. It is an entirely new proposal.