Please describe your proposed solution.
We’re building a cross-browser Cardano light wallet with a popup format that supports switching networks and unifying all of them within the same tool from the same account. In addition, it allows users to choose their own trusted endpoints and explore different use cases as add-ons.
The light wallet type, the user-friendly 'popup' format, and the quick installation will make it easy for beginning users to adopt the wallet. While the ability to easily add new use cases/plugins, customize endpoints, mint NFTs in-wallet, testnet support and dapps connector integration, combined with the quick and easy UX of a lite-wallet, will attract more advanced users and developers.
<u>Development path</u>
The development started as a cross-desktop wallet[0], and with the imminent arrival of smart contracts, the project evolved towards the creation of a wallet to be used from the browser to facilitate interaction with web3.
With the advent of the Alonzo hardfork, we expanded the vision and capabilities of the wallet, adapting the initial proposal[1] to a modular and progressive wallet where starting from a basic wallet functionality with a friendly extension user experience we built new functionalities such as support for switching between different networks, the first wallet on Cardano to allow for in-wallet NFT minting, the possibility of choosing your trusted endpoints, and enabling users to easily add new use cases in the form of add-ons..
[0] https://github.com/jimcase/C64-Minter
[1] https://cardano.ideascale.com/c/idea/352588
Please describe how your proposed solution will address the Challenge that you have submitted it in.
Strengths of C64: Expanding what’s possible with a Cardano Lite-Wallet
Wallets are the gateway to the blockchain, anything you want to register on the blockchain needs a wallet, or to be more precise, an interface that allows you to securely perform actions involving your private keys.
Initially, we start by creating a wallet to randomly generate a new private key(seed phrase), or use an existing one instead.
In any case, we can always hold more than one private key in the same app, making C64 multi-account style.
Once we have a private key, we will encrypt it with a spending password and store it securely on the client side. This means that the private key is never exposed to the outside world and if someone accesses your device they will not be able to decrypt the key without your spending password. This allows users to persist their own data and not need to enter the recovery phrase with each new action.
Well, now that we are efficient in managing and storing our key data, let's continue to set up the wallet.
From the private key we can generate the corresponding public key and also generate public addresses that everyone can use to send any asset.
In case we do not have funds yet, we will need someone to send us some assets, for example a few ADA.
To do this, we will share one of the generated public addresses, whichever one the user chooses.
After someone sends Ada to the provided public address and we finally receive the payment, we will see an interface where we will be able to check the activity and transaction history associated to the current wallet.
For each transaction we will see:
- The total amount of Ada received, the senders and receivers involved, the size of the transaction, the network fee and the hash of the transaction(with external link to carcanoscan).
- In case tokens are included, a list of tokens received will be displayed.
- In case matadata is included, the original content will be displayed in .json format.
All the properties above can be copied to the clipboard by clicking on them.
In addition to all transaction activity we will have another Tab to show the assets in hold.
Starting with an horizontal list with a thumbnail and animated display of the NFTs.
In addition to the NFTs, a list of all native tokens will be displayed.
Both NFTs and native tokens can be opened in detail. There we can see more detailed information related to the selected token. We will be able to consult:
- The token name or assetName.
- The type of token. Fungible or non fungible.
- The asset fingerprint.
- The policyId.
- The last time it was minted.
At this point we have already all keys and addresses needed to start performing actions, and an explorer to carry out and visualize them.
Then, we can build and serialize a transaction, where we will dynamically obtain the total cost of the network fee with each change we make in real time.
Among these changes we can have:
- The number of outputs we want to send assets.
- The number of inputs we need to include.
- The total amount of assets for each output.
- The use of certificates, for example, staking certificates.
- The inclusion and editing of plain text as metadata following the CIP-20[0]- Metadata as a list of strings.
To get an estimated dynamic fee, we will use a mirror transaction as a draft, where we will be simulating the transaction until we get the final result.
This is where a critical component comes into play when dealing with and building transactions. This is called the CoinSelection algorithm, which calculates and manages the UTXO needed to perform and cover the costs of a given transaction in the most efficient way possible, while avoiding the generation of dust.
There are several ways to perform this task, as detailed in CIP-2[1], where the following approaches stand out:
- Largest first. Here, the largest UTxO entry is always selected first.
- Random-Improve. Divided into two phases, UTxOs are randomly selected until the costs are efficiently covered, given a constant, e.g., that the selected UTxOs cover 2x the total assets to be sent.
Now that we can have transactions, we can perform all kinds of actions. For example,
In addition to sending common transactions we can participate in the staking mechanism and earn rewards delegating through a specific Staking Pool.
To look for the sustainability of the project, the delegation will be linked to the Ada Booster stake pool until a maximum of stake is reached. This maximum value will be determined during the development phase.
Lets go further with the transactions. We can create native tokens with a simple transaction, no smart contracts needed.
The wallet will provide a tool to mint native tokens(gaining sovereign). In particular, it will be possible to create NFTs without the need of third party tools or websites, all from your wallet.
In addition, thanks to a previous proposal from fund5, we can mint NFTs 100% on-chain without the need for services such as IPFS, guaranteeing lifetime accessibility. Is there anything so important that deserves so much? Community will decide.
To get up to date data directly from the blockchain we need to request it from the endpoints.
From the wallet we can add our own endpoints or from any other trusted source.
In this way, we are totally sovereign of where our information goes at all times.
In addition, we can mitigate bottlenecks when the network is saturated by not using a public service.
We can continue expanding the possibilities of the wallet's internal functionalities. But we will not stay only in our world, from C64 we will be able to interact with any web3 platform to provide relevant information and new utilities.
For example, we could provide a financial analysis website our transaction history so that they can calculate a profit report on it. We can think in many other use cases where imagination has no limits.
The solution detailed above covers everything we will need to complete the final MVP. This does not end here, it is a matter of making incremental progress in conjunction with Catalyst funding rounds or other suitable means of funding.
We will continue to work on the roadmap of the project to ensure its long-term sustainability in the best possible way.
An important point of sustainability will be to increase the traction of the community and to work on marketing and branding to differentiate the C64 Wallet from competing Cardano lite-wallets.
This, coupled with the interoperability with other wallets in the ecosystem, will promote adoption.
<u>Insights for Future Development</u>
This NFT minting tool was our first example of the capabilities;, we can take advantage of more feature of Cardano native assets to develop more innovative features in the future..
Other tools and features not covered in this proposal but considered in future updates:
- Minting of native tokens.
- Transactions with multiple outputs.
- Multi-sig accounts[2].
- Encryption of any common data.
- Compatibility with all wallets, eg. Daedalus and Yoroi.
- Integration of third party tools such as: Adahandle[3], ArgusNFT[4] and other projects.
- Integration and support with hardware wallets.
- Milkomeda integration.
- Integrate Identity systems like third party Atala Prism projects.
[0]https://cips.cardano.org/cips/cip20/
[1]https://cips.cardano.org/cips/cip2/
[2]https://cips.cardano.org/cips/cip1854/
[3]https://adahandle.com/
[4]https://argusnft.com/
[5]https://www.milkomeda.com/
What are the main risks that could prevent you from delivering the project successfully and please explain how you will mitigate each risk?
<u>Technical Risks </u>
There aren't technical blocking problems or evidences, since Cardano protocol already provides all features detailed in this proposal for a browser wallet.
<u>Team Risks </u>
There are always risks to working on projects where multiple people need to contribute for a successful outcome. However, our team has worked well together many months already on this project, and are committed to the vision of building a Cardano lite wallet with innovative and useful functionality, so we don’t see our team as a factor that risks the completion of the project..