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<member communityid="163" id="162244">pool</member> and mary<member communityid="163" id="162244">pool</member>, for example.
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:
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.