The idea is interesting but IMO the proposal has many drawbacks:
Hi @conradoplg, thanks for the feedback. Are there any specific examples that lead to your perception of a ‘confusing UI’? Early feedback has been very positive, with users pointing to the UI as a key reason for adoption.
Also, our team has created and delivered several open-source grants, all on time. We have lots of experience building wallet software and are confident in our estimates.
Finally, a compromised web server does not mean a compromised wallet. Keep in mind that Kryptik is noncustodial. If the server went down, it would be similar to the interface for a mobile app or Ledger Live going down. Users can always port their recovery phrase to another interface. We hope this makes sense. If you have any questions, please let us know. Of course, there are additional attack vectors with a web-based wallet, but this approach is focused on increasing accessibility for the ZCash ecosystem (while doing our best to secure user assets/privacy).
Have you thought about looking into the internet computer as a possible option for / database storage as part of the key?
I don’t think ZCash has a web wallet. Typically, we use YWallet nowadays. Could you explain the additional benefits of having a web wallet? Also, where would the front end be hosted? We don’t even have a proper wallet to start with. It would be quite exciting if you could integrate ZCash into the Dfinity ecosystem as well. I believe this would allow it to tap into a new use case within the DApp space. I’m just unsure how that’s feasible. I’m aware that ‘t’ addresses are possible, but I’m not familiar with ‘shielded’ ones and unsure if they would work. However, since you mentioned that this is feasible on the web, perhaps it is indeed possible. I would love to hear your thoughts.
Took me a bit to find where the seed phrase was displayed. The wallet also does not explain to the user that they can/should write down the seed phrase. There are also some weird design choices like bright green on dark gray (“Buy ETH” link).
Does the team have any experience in making Rust code work in browsers through WASM or porting?
If I can see the seed phrase, then any Javascript being served by Kryptik can see it too. If the server is compromised, it can serve malicious Javascript that can get the seed phrase and send it anywhere.
I get that there is a tradeoff, but the upside (usability) doesn’t seem big enough IMO. If we want to fund another wallet then I’d love for it to be one with stellar design and usability.
Thanks for the feedback. We’re always looking to iterate and improve our design. Seedphrase prominence and color schemes are two areas to focus on as we refine the onboarding process (lots of room for improvement).
And yes, we do have experience compiling from Rust to Web Assembly. Rust is quite popular at our universities, so we’ve had a fair amount of exposure.
Finally, we agree with you: if we want to fund another wallet, it should have stellar design and usability. We believe we can offer both for a relatively low cost (other wallets often ask for multiples of the amount we requested).
Again, thank you for taking the time to share your feedback; very helpful!
Correct; to our knowledge, ZCash does not have a web wallet. Designing for security on the web can be difficult; however, many ecosystems offer a web wallet to help onboard new users and increase accessibility. This is especially important for ZCash, which can be quite complex.
Kryptik is currently hosted with Vercel. All code is open source and licensed under the permissive Apache 2.0 license. Kryptik supports 10+ networks allowing users to interact with multiple blockchains from a single interface. In addition, we use threshold cryptography to allow many wallets on a single device and enable trustless synchronization across devices. For more on our sync feature, you can watch this demo.
While integrating ZCash on ICP is not the focus of our grant, we believe it is possible, albeit challenging. Many of the same considerations discussed above (Rust->WASM, sync times, proof generation, etc.) would apply.
And yes, we are considering using a decentralized storage system to host shards. ICP would be a great option and is aligned with our idea of decentralizing as much of the wallet stack as possible.
Are you making this mobile first and a PWA? And how fast do you think you can get zcash wallet sync, I know they have a new update coming up that will allow it to sync even faster. Also how do you prevent the browser from leaking user info? And how does it allow for sending a transaction without having access to the whole private key, as you mention the key would be stored on mobile + desktop + server.
P.S if you can port ZEC to ICP canisters the DFinity foundation will give you the grant. This would have to be similar to how they did ckBTC Internet Computer Loading. However, I’ve been wanting ZEC in canisters for a while, even if it is just T addresses. This will allow many use cases as it would allow liquidity within the ecosystem of apps. Tipping is already a big use case in many apps. Similar to how twitter wants to do tipping using micro transactions.
The wallet is a PWA. The software is written in Typescript to help with type safety. We described a bit of our syncing approach in the thread above. If you have any further questions, please let us know. A lot of our approach has been influenced by this article on syncing.
SWORD (our key management system) creates shards of the user’s seed phrase. On authentication, the shards are recovered on the client’s local device, giving the user full access to the private key.
And noted! We’ll ping you separately about the ZEC to ICP port.
@kryptik, thank you for your grant submission, the @ZcashGrants Committee has voted to reject this proposal due to concerns around security, primarily due to private key management.
The committee also referenced other wallet grants that have been rejected for similar reasons that can be seen at the below links:
Thanks to the committee for the decision and the community for feedback during the review stage. We want to point out that dizzy wallet was focused on Discord, while zecweb used a custodial model that drew concern from the community. Both were fundamentally different than the project we proposed.
As it stands today, the ZCash ecosystem needs much better wallet options, especially when it comes to accessibility and synchronization. We are optimistic that these solutions will be developed and that ZCash will continue to enable privacy-preserving payments.