A simple web wallet for ZCash that supports shielded transactions and secures assets with threshold cryptography.
Our primary team consists of Jett Hays and Jaylem Brar. We are laser-focused on building high-quality software expressed through intuitive design.
Jett Hays is the president of the CMU Blockchain Club, where he helps members build decentralized applications.
JJ has been a lecturer for the Blockchain at Berkeley fundamentals course and a Web3 consultant for companies like Paypal. This experience has helped him better understand blockchain fundamentals and the software skills required to improve them.
Together, we have released an early version of the Kryptik Wallet that supports 10+ blockchains. Our work has received support from organizations, including Carnegie Mellon and the Solana, Near, and Web3 foundations.
All wallet code is open source and can be viewed here.
Wallets are the connection point between users and the decentralized web. Simple and secure wallets are crucial to accelerating the adoption of blockchains. However, ZCash does not have a strong web wallet. Previous web wallets– Jax and Safepay– have been sunset within the past few months. The absence of a web wallet forces ZCash users to install proprietary applications or purchase complex hardware wallets.
Kryptik will also provide first-class web support for shielded transactions, which have long been missing from Zcash web applications.
We will integrate ZCash within the Kryptik web wallet. Our solution will support both transparent and shielded addresses. Once complete, Kryptik will provide users with a simple way to access the power and privacy of Zcash from the browser.
Our primary audience will be retail Z-cash users, although Zcash devs will benefit from our open-source typescript code that will facilitate Zcash interactions.
The final deliverable will be a web wallet– deployed at kryptik.app– that supports ZCash. Key management software will be released as past the hd-seedloop repository.
Technical Approach: Dive into the how of your project. Describe your approaches, components, workflows, methodology, etc. Bullet points and diagrams are appreciated!
Users will access their wallets using the latest web authentication standard, WebAuthn. This will enable a seamless login process using device-level credentials like FaceId. In addition, wallets will be protected using SWORD– a threshold cryptography scheme we developed with support from Carnegie Mellon.
SWORD distributes shares of an encryption key to a group of shareholders; k of n shares are required to reconstruct the original secret. The encryption key creates an encrypted version of the wallet. Whenever a user wants to regain access to their wallet, the shares are reassembled, and the wallet is decrypted. SWORD is in production and is used to secure over $50,000 of user funds.
The Kryptik wallet is based on an open-source key manager that derives hierarchical deterministic accounts from a single seed. This allows Kryptik to offer multi-currency support and streamline the wallet experience. We will update this package with routines for generating Zcash addresses and signatures (both transparent and shielded).
Finally, the key management system will be wrapped in a beautiful interface that will allow users to send and receive ZCash assets. Addresses can be shared with a simple QR code, and payments can be made via a secure flow that auto-checks the validity of recipient addresses and balances. As mentioned above, we plan to support both t and z addresses.
All code will be written in typescript. The interface will be created using React and Nextjs.
Dependencies: What external entities is your project dependent on? What involvement is required from ZF, ECC, and/or other external organizations? Who would have to incorporate your work in order for it to be usable?
Our project will initially rely on a shared third-party node (interacted with via an RPC interface). No involvement from external organizations is required for this grant. We will also reference the Zcash wallet checklist when designing the UX.
Execution risks: What obstacles do you expect? What is most likely to go wrong? Which unknown factors could jeopardize success? Who would have to incorporate your work in order for it to be usable?
Relying on a third-party node provider could cause issues. If the node is too expensive or latency is too high, we may need to set up our own node. In addition, the UTXO model of ZCash will add complexity to our key management system, which has only been used for account-based systems (although we will recognize the best practice of persisting a single address for each context). Finally, we will need to make design decisions for how to best communicate the privacy features of ZCash (i.e., address labeling, default fees, etc.).
Unintended Consequences: What are the negative ramifications if your project is successful? Consider usability, stability, privacy, integrity, availability, decentralization, interoperability, maintainability, technical debt, requisite education, etc.
Web wallets are important for adoption and ease of use. While we want to provide users with a powerful day-to-day wallet, Kryptik should not be users’ go-to wallet for large sums of money. An unintended consequence of our success may be users forgoing strong hardware backups.
Evaluation plan: What metrics for success will you share with the community once you’re done? In addition to quantitative metrics, what qualitative metrics will you commit to report?
If successful, Kryptik will provide users with a simple way to access the power of ZCash from the browser. We can quantify this objective by user count. We could also add a cumulative transaction count (number of Zcash transactions Kryptik users have created). However, we are concerned about the privacy implications of this metric. We would appreciate feedback from the community on how to preserve user privacy while quantifying proposal success. We would also like to collect qualitative feedback from early users on the usability of our ZCash implementation, with an emphasis on perceived simplicity and privacy.
The services budget will be used to host the wallet for two years ($500), while the remaining amount will be spent on RPC services. We are also strongly considering running our own node, but we believe that may be out of the scope of this grant.
The compensation budget will be split between Jett Hays and Jaylem Brar. Jett and Jaylem will each receive $9500 over the course of the entire project.
Typescript library for basic Zcash utils such as transaction construction, serialization, and encoding. This library will also verify the validity of Zcash addresses
Add support for Zcash address generation to the hd seedloop typescript package. Success will be validated by unit tests (assisted by the library from deliverable 1.1).
Add support for Zcash signatures to the hd seedloop typescript package. Once complete, seedloops should be able to construct valid signatures for a given address and transaction. Success will be validated by unit tests.
Add support for Zcash account serialization and recovery. Once complete, the seedloop should be able to be serialized and encrypted, while persisting the state of Zcash accounts. This can be verified using unit tests.
Allow users to share their transparent Zcash address with a simple QR code.
Enable users to generate new transparent addresses from within the wallet. Once complete, there will be a display of existing Zcash t-addresses, with the option to genrate a fresh address. This will be formatted as a custom React component.
Enable users to view their cumulative balances across t-addresses. There will also be a sub-view that shows how much money belongs to each address. This will be formatted as a custom React component.
Enable users to make payments between t addresses. Once complete, users will be able to select the sender address from the available t-addresses with a balance, and send to any other t address. The transaction amount and recipient address will both be validated before the payment is made.
Deployment. The Zcash features listed in deliverables 2.1 through 2.4 will be pushed to the production branch of the Kryptik wallet and will be accessible from the Kryptik web wallet interface.
Enable users to view a list of transparent transactions and associated metadata. This will be formatted as a custom React component.
Add the option to create a z-address. This will be formatted as a custom React component.
Fetch and display z-address balances. This will be formatted as a custom React component and will be made distinct from balances associated with transparent addresses.
Add the option to create and share viewing keys for shielded transactions. Users will be presented with the option to create viewing keys in a special privacy section and within the details of each shielded transaction. This will be formatted as a custom React component.
Enable shielded transactions. This deliverable will enable users to send payments from and to z addresses.
The project timeline was determined based on previous proposals that we have completed (all of which have been on time). Each milestone deadline accounts for initial design, development. and testing.