Proposal: Kryptik Wallet


Kryptik Wallet

Applicant name:


Pitch: A one-liner elevator pitch version of your proposal

A simple web wallet for ZCash that supports shielded transactions and secures assets with threshold cryptography.

Total Request (USD):

$20000.00 USD

Have you previously received a grant from Zcash Community Grants (formerly called ZOMG) or ZF?


Are you seeking or have you received funding from other sources for this proposed project?


Applicant background:

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.

Description of Problem or Opportunity:

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.

Proposed Solution: Describe the solution at a high level.

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.

Solution Format: What is the exact form of the final deliverable you’re creating?

The final deliverable will be a web wallet– deployed at– 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.

Hardware/Software total budget:

$0.00 USD

Please provide justification for the total hardware/software budget:


Services total budget (cloud, hosting, etc.):

$1000.00 USD

Please provide justification for the total services budget:

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.

Compensation total budget:

$1900.00 USD

Please provide justification for the total compensation budget:

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.

Do you require startup funding?


Milestone 1 - estimated completion date:


Milestone 1 - USD value of payout upon completion of deliverables:


Deliverable 1.1

Typescript library for basic Zcash utils such as transaction construction, serialization, and encoding. This library will also verify the validity of Zcash addresses

Deliverable 1.2

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).

Deliverable 1.3

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.

Deliverable 1.4

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.

Milestone 2 - estimated completion date:


Milestone 2 - USD value of payout upon completion of deliverables:


Deliverable 2.1

Allow users to share their transparent Zcash address with a simple QR code.

Deliverable 2.2

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.

Deliverable 2.3

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.

Deliverable 2.4

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.

Deliverable 2.5

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.

Deliverable 2.6

Enable users to view a list of transparent transactions and associated metadata. This will be formatted as a custom React component.

Milestone 3 - USD value of payout upon completion of deliverables:


Milestone 3 - estimated completion date:


Deliverable 3.1

Add the option to create a z-address. This will be formatted as a custom React component.

Deliverable 3.2

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.

Deliverable 3.3

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.

Deliverable 3.4

Enable shielded transactions. This deliverable will enable users to send payments from and to z addresses.

Total proposed USD value of grant:

$20000.00 USD

How was the project timeline determined?

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.

Application submission date:


1 Like

Thanks for taking the time to review our application. All feedback is welcome!
Here is a link to the public grant page.

Hi @kryptik - Welcome to the forum, and thank you for submitting your grant proposal! We will review it in the upcoming weeks and reach out if we have any questions.

In the meantime, if you have any questions for us, you can post them to this thread or DM us at @ZcashGrants.

Zcash Community - We want to hear your feedback on this grant! You can post your comments to this thread or DM us at @ZcashGrants if you’d like to provide feedback in private.



Hey welcome to the forums! Here are a few questions:

  • How did you first learn about Zcash?
  • How did you learn about the ZGC?
  • Do you plan on supporting other privacy coins?
  • Do you have any plans to support UA’s ?

Thank you and good luck!


Hey there, thanks for the welcome! I learned about ZCash during a lecture at Carnegie Mellon. The class on blockchain fundamentals was taught by Nicolas Christin (director of the CMU Secure Blockchain Initiative), who later became my research advisor. After a quick search, I found the ZGC and have finally circled back after two years of building in the wallet space.
We have considered a few other privacy coins, although our primary focus is Zcash, which we believe has the best ecosystem and adoption to date. And yes, we have also considered UA’s, which would help simplify things from a UX perspective. In the proposal, we differentiated between transparent and shielded addresses, but we may adopt a transparent+sapling UA scheme in practice.


Hi, I’m a bit confused by this section. Is Kryptik going to keep user funds in a third party wallet/node provider? If so, what is the purpose of having a k/n secret sharding if they have the full key anyway?



The RPC node only pulls blockchain data and pushes signed transactions. The RPC node (and our own servers) never have access to the user’s private key. Using a third party RPC node is common practice for many wallets. If you need more clarity on the key management scheme, we have published a deep dive here.

The biggest challenge (unsolved so far) is how to synchronize the wallet in a practical way with only the browser. Could you elaborate on your approach?

1 Like

Just to clarify, are you referring to synchronizing wallet data from the blockchain (e.g. latest transactions, balance, etc)?

Yup, exactly: Trial decryption and witness update.

1 Like

Right now, we are considering both of these challenges from a UX perspective. The browser has resource constraints, but the browser is still capable of achieving anything any other computing environment can. The challenge is doing this in an efficient manner.
Our current approach to trial decryption is offloading the search to a web worker on initialization. This will kick off a search for associated shielded transactions while keeping the main thread free for other tasks. The search space for recently generated wallets will be small, while the search space for old imported wallets may be large and can be constrained by asking the user to specify a historical cut-off date (e.g., only search for tx in the past 200 days). Discovered transactions will be saved locally or to the server.
We are still refining our ideas for witness updates. Our current approach is to reference existing witness update code and port it to typescript (with extensive testing). While this task is difficult, our team has experience designing complex software with cryptographic interactions between multiple parties. Please let us know if you have any feedback on any of these ideas or specific design considerations.

@hanh, your work on warp sync will also be a major source of inspiration, allowing us to jumpstart the dev process.

I don’t know much about wallet development, but I have a few questions.
All the syncing, trial decryption, transaction creation and signing will be made on client side (web browser)?
Previous attempts of running a light wallet on the web browser proved to be really slow and had little user adoption.

If the wallet will run directly on the browser, why use SWORD key management at all? Why not just store the private keys in local storage? Maybe this is a huge no no for wallet development, I don’t know … But since the user can (and probably will) store k of n shares to avoid denial of shares, it’s not that different than storing the private keys. Or is it?

@james_katz Many web wallets store keys in local storage. This forces a vulnerable one-wallet-per-device setup. SWORD allows many wallets per device, as each wallet is decrypted and can only be unlocked with k of n secret shares. Currently, one-time codes are used to authenticate users and decrypt the correct local wallet when a user session is active. The paper does a thorough job of motivating the need for SWORD.
As mentioned above, trial decryption can run on multiple threads with web workers, and we can make parallel async HTTP requests using typescript. This will help accelerate the syncing phase. Persisting discovered transactions and recording the block height of the last searched transaction will minimize subsequent sync times after initialization.
Transaction creation and signing will be done on the client, and shielded transactions will require an interaction between the client and third-party RPC. Our goal is to create/sign transactions in ten seconds or less.
Both synchronization and transaction creation are solvable engineering challenges that require an equally considerate approach to UX. All compute-intensive operations will be nonblocking (delegated to a separate thread). When combined with clear progress updates, this will enable a smooth flow for the end user.
If you have any further questions, please let us know! Every question is a chance to further refine and consider our approach.

1 Like

@james_katz Also, there is support for multithreaded WASM code. This will help accelerate proof creation!

1 Like

MG slice (Major Grants)

(4) Major Grants SHOULD be restricted to furthering the Zcash cryptocurrency and its ecosystem (which is more specific than furthering financial privacy in general) as permitted under Section 501(c)(3).

ZCG has invested a lot of resources in four wallet teams whose primary focus has been on applications for ios/android distribution. Zcash needs resources invested in better other distribution channels. Browser focused wallets are a logical area for zcash investment.

Invest in methods to allow users to use zcash how/when/where they choose to use zcash.

Nice application, good team, good directional plan, good value.

I support this project.

@kworks Thank you for your support! We share your belief that the ZCash ecosystem would benefit from a web wallet. With a simple and secure wallet UX, we can help make ZCash more accessible.

If anyone has any additional comments, feel free to share. We are happy to answer any questions and discuss technical implementation.

Thanks to everyone who has provided feedback so far. We look forward to continued discussions about our proposal and beginning work on a Zcash web wallet (if accepted).

Hi there! Is there an ETA on the proposal review? Community feedback has slowed down.