Description of Problem or Opportunity:
What problem or opportunity will your project address or solve? Provide context for the problem or opportunity and clearly present how your project will add value to the Zcash ecosystem.
Zcash is one of the most reputable projects of the crypto space, not only has the most advanced Zero-Knowledge Cryptography, furthermore it spawned a novel concept in the crypto space (not without controversy): a Dev Fund to provide self-sustainability to the project and committee that its community elects to distribute a portion of this fund in the form of grants. This fund allowed several teams to grow and orbit the Zcash ecosystem delivering a lot of value in different grants such as ZecWallet, Nighthawk Wallet, ZecPages, Z-Go, Free2Z, Global Ambassadors Program, Zcash Media, Z-Faucet, Ziggurat, Zcash Block explorer, Lightwalletd.com, Y-wallet, Zingo!, Zcash Ecosystem Security Lead, and many others.
Although the mentioned above are successful cases, there is room for improvement in terms of Developer Experience and general direction of the developments and cooperation between grant recipients.
Wallet teams are resource constraint and need support
Bear market and current ZEC prices have conditioned our ability to properly support different wallet teams financially with the resources they need to properly fulfill both their own and the whole ecosystem’s goals. Nonetheless, wallets remain crucial for Zcash to achieve mass adoption and be an instrument for financial privacy and freedom for people around the world.
Scarce re-usability of grant-funded developments
The different grants that ZF and ZCG have given out regarding wallets or tooling produce good outcomes, but often they don’t end up being beneficial to the whole developer and user community in terms of providing building bricks for other developments. Teams usually don’t have either the motivation and resources to prioritize generalizing their developments. Tooling for the wide Zcash Dev ecosystem comes out of exceptional efforts from ZF and ECC where it should be the norm that all grants allocate a portion of their work for the benefit of the wide ecosystem.
To put this in terms of specific cases we can go back in time and see a pattern repeatedly. ZecWallet was, if not the first, one of the first light-client wallets for Zcash. It was a breakthrough, great work of a brilliant developer we shall forever be grateful to. ZecWallet and ZecWallet-Lite surfaced many great features only available in the desktop terminal into people’s hands like utxo-shielding, BIP-39 compliance, multi-account support, fiat price conversion through trusted server (lightwalletd) and blaze-sync. However, for one reason or another, other developers were not able to build on top of that without forking the code. When needing these functionalities, other teams had to either adapt them or in the worst case, code them again from scratch.
This ends up not only being inefficient in terms of operations and resource allocation, but also it creates copies of duplicate functionality where one implementation does not benefit the other. For example, when shielding was implemented in librustzcash, ZecWallet users did not benefit from any of the updates the ECC Core and Wallet teams did there. An opportunity of building cohesion into ZEC UX was missed. Zingo Labs had to allocate a great portion of their resources to “bring back” the ZecWallet codebase to the common Zcash tooling. Thanks to the great effort they put into using Librustzcash and Lightwalletd (instead of insisting on the use of ZecWallet forks) they could start contributing to the tools used by everyone else.
Also, this lack of cohesion creates a high entry barrier for new developers, because it’s hard for newcomers to see what building blocks to grab to achieve their goals within the Zcash Ecosystem.
Teams competing over basic wallet functionality
In the months to come the Zcash Ecosystem will have three different Zcash-centric or Zcash-only wallets: Ywallet, Zingo!, Nighthawk and Secant (ECC’s mobile Wallet). This is huge! However, if we compare them, they implement core protocol features differently. To this date, the first two support Orchard in their own way while NH and Secant (by extension Unstoppable and EDGE) don’t. Moreover in the syncing front, there are three different algorithms competing against each other: Blaze Sync, Warp Sync, linear (or vanilla) sync, with or without filtering. This provides a heterogeneous and rough user experience where syncing the same keys on each wallet might bring different outcomes (because of heuristics mostly). And yet there’s a fourth diner coming to the table: DAGSync.
Blaze Sync and WarpSync are both works derived or sustained from the Dev Fund, but surprisingly not available to all Zcash developers. How could we expect each new development team to craft their own or port an existing syncing mechanism?
Will DAGSync escape such logic? I bet it will because my experience working at ECC tells me that the core team will go the extra mile.
We are all technologists here. We love nerding out, getting into the weeds, exploring rabbit holes just for the sake of it. That’s fine, but users shouldn’t have to download 3 wallets to know what works. This is also a risk because loading the same seed backup in different wallets is not a safe practice.
One thing I’ve learned from all of these years of “coding the last mile” is that one has to live with this hard truth: Users don’t care how things work under the hood. If they have to, then you are probably in trouble.
Zcash wallet developers should have their basics covered, so that they can focus on what their audiences need.
Zcash wallet users should expect a uniform base experience over the core principles of the project, and tailored and hand-knitted UX over specific user cases of their choosing.
Proposed Solution: Describe the solution at a high level.
Please be specific about who the users and stakeholders are and how they would interact with your solution. E.g. retail ZEC holders, Zcash core devs, wallet devs, DeFi users, potential Zcash community participants
The section above describes the overall picture that led me to write this grant proposal. Although it does not cover them all. Resolving these issues would require more than a single person. Hence, I propose an initial step towards addressing these points that is more suited to the current market conditions, that is more focused on delivering specific and tangible value quickly to the developer community.
I propose to continue in the role of a Zcash Wallet Community Developer that can work to fill in the gaps on the different wallet teams and their articulation within the Zcash ecosystem. This would be a full-time role split between different tasks that support the Zcash Wallet Developer teams and the community.
- Wallet Development and Testing
- Part-time Wallet development for the different Zcash teams
- Provide wallet related Code Reviews
- Developing general-purpose wallet integration testing tooling
- Ecosystem Outreach
- Moderate, expand and steer Light Client Working Group
- Attend Arborist Calls and the Zcash Ecosystem Spaces
- Office Hours of Technical support to Dev Teams requesting Grants or proposing RFPs
- Attend conferences and other events that are relevant to the role (funding will be evaluated independently with ZGC and ZF with different grants if more funds needed)
- Collaboration with ZCG
- Consulting sessions with ZGC on RFP or grant proposals
- RFP drafting and assessment
Zcash wallet ecosystem development forecast for 2024
The following list contains most of the themes/tasks/efforts that I’ve been able to track that are relevant to ZWCD’s role for 2024. This list is currently changing and evolving as our ecosystem does, so it should not be considered exhaustive or definitive.
List 1: Development projects that are currently ongoing, continuing on, or starting in 2024
- Wallet developer ecosystem response to Exchanges announcing delistings
- Note: this is a “developing story”. In which capacity ZWCD will be involved depends on the outcome of the solution requirement analysis itself.
- encumbers a collective effort from all developers from Core to each one wallets that support Shielded Zcash.
- ZIP specification for the solution that will be developed
- Development of the solution on the wallet level
- Coordination of the many teams involved and the Exchange counterparts.
- The Zeebot and Workshops
- Shall ZCWD be there? Yes
- Do we know where is it and when? Not yet! But somewhere on Earth and around the end of January, beginning of February 2024.
- Zcon5:
- Shall ZCWD be there? Yes
- Do we know where is it? Not yet!
- ZIP-321 request adoption:
- Integration of ZIP-321 libraries into native mobile wallets.
- Development of kotlin multi-platform target for Javascript clients (JS SDK, Brave and react-native clients)
- FROST:
- PoC and demo of the soon to be released libraries
- Tooling for Mobile and Desktop Applications. Frost Mobile SDKs?
- Decentralizing Core:
- [Tentative] Sunsetting GoLang Lightwalletd in favor of Zebra integration in RustLang
- Regtest and other testing tooling Support for Zebra and its integration with wallets
- Tooling:
- Regtest Support of Mobile SDKs (ongoing)
- ZSAs
- Development, wallet integration, tooling and documentation
- ZAVAX Bridge support
- Development, tooling and wallet integration
- Hardware Wallet (ledger) Support other wallets
- Integration to other wallets besides Zondax’s ZecWallet version
- DAGSync and other wallet ecosystem improvements
- R+D of better sync or (no sync at all solutions)
- ZEC In the Browser:
- Brave Wallet Support
- ZcashSDK for Javascript
- ZEC to PoS:
- Wallet implications of Zcash moving to Proof of Stake
- Draft a ZIP to define Mortem and Post Mortem best practices for wallets:
- This is a totally undesirable ZIP but someone has to do it. It can’t happen that a wallet is no longer maintained and that Zodlers are left hanging to dry.
- Research what other projects do in this matter
- Collect best practices and case studies
- Draft a document that instruct wallet developers how to deal with:
- Communications of End of Support / End of Life of a Zcash wallet
- Common migrations paths
- Suggested timelines
- Pre-mortem, Mortem and Post Mortem support
- Tombstone releases
Transitioning from ZCWD to Zcash Wallet Ecosystem Lead
As the reader might have appreciated, the list above is quite extensive and fills up any individual’s plate pretty easily. As it was stated previously, it would be ideal that this is not a single person effort, but a team/organization effort instead. Expectations on this grant are mostly limited to the resources available. It would be desirable that a multi-disciplinary team is appointed instead of a single person. This would:
- reduce risks of the role being vacant because any circumstance that might cause the ZWCD not longer be able to carry on its work (as it happened with Zcash Ecosystem Security Lead),
- adjust to post ZIP-1014 reality. If proposals to continue with a developer funding schemes that comes directly from the protocol, or a Zenate as @GGuy proposed, it would be good that this role can grow into an Organization being capable of engaging inside the Zcash community and other sibling projects Zcash connects to (Eg: Filecoin, Namada, Aleo, ThorChain or Avalanche). An organization could be better suited to receive grants from other platforms as well than a single developer.
Solution Format: What is the exact form of the final deliverable you’re creating?
E.g. code shipped within the zcashd and zebra code bases, a website, a feature within a wallet, a text/markdown file, user manuals, etc.
Similarly to the Zcash Ecosystem Security Lead, the deliverables will be established on a monthly basis, agreed between the involved teams and ZCG, then informed to the whole community.
I have contacted many teams within the Zcash ecosystem like ZF, ECC, Zingo Labs, Nighthawk Apps and Red Dev to have a rough estimate on things that I could continue to contribute to if I remained within this role that ended in December and continued from January to November 2024.
There are many projects and initiatives in flight in our ecosystem. Many of them depend on one or more teams. I have made an effort to attempt to forecast this work and outlined it in the Schedule and Milestones sections.
The outline is right in the spirit of most of the detailed tasks, but it will have to be refined and specified as-we-go, since all of these are moving pieces within a complex distributed, decentralized and global ecosystem like ours. Also I’m considering the case of new teams arriving (Yay!) and applying for grants and serving them as a welcoming person of reference with Office Hours and other meetings. Also I believe that newcomers should be prioritized if they need guidance to foster a broader community.
The initial grant application covered 5 months of full-time work from August 1st 2023 to December 31st 2023 with the possibility to extend to the whole year 2024. This presentation is the extension of that original grant through 2024, plus some tweaks based on the experience I’ve collected these past months.
Technical Approach: Dive into the how of your project.
My methodology has been similar to a Staff member of the teams I contribute to, where they would hand me well scoped tasks over their github repositories or other public means that the Zcash community or anyone can oversee. I’ve also been interacting more over community channels like the forums and R&D discord to communicate with other teams as needed.
Work dynamic will be similar to the one of the previous Grant with some changes due to the nature of the work that needs to be carried out.
What has changed over the last 5 or 6 months?
Well.. basically pretty much everything! And that’s really good for Zcash!
The main difference I foresee in terms of this grant is that when previously we had well defined tasks in terms of scope and time based on things that were previously developed and needed to be made, wrapped up or extended, we now have
- Ecosystem responses that are either time-sensitive with tight deadlines like the “avoid delisting initiative”
- Ongoing initiatives that have high-impact on the wallet ecosystem and would require collaboration and support from ZWCD but they mainly depend mainly on other teams:
- FROST
- ZSAs
- PoS
- HW wallet support
- Bridges w/ other Coins (ThorChain and ZAVAX bridge)
- NU6
- Initiatives that solely depend on ZWCD:
- Tooling development
- Library and SDK development and maintenance
- Community Activities
- LCWG and Office Hours
For this, the milestones would be structured in terms of main and secondary tasks. The main task will be the one that will be the most important and would take precedence before the rest of the items of the milestone unless there’s a blocker that makes it not fruitful to be worked on and the time would be better spent on something else.
List 1 can serve as a Backlog of possible tasks that ZWCD will contribute to advancing on its own or by supporting other teams leading them to avoid either being “blocked” or acting as “bottleneck” given the current “single-person” nature of the role.
Example:
Milestone X:
- Main: Task A, Ongoing, long thing that depends on Team Q delivering some API.
- Secondary: Task B
Milestone X+1:
- Main: Task A, Ongoing, long thing that depends on Team Q delivering some API.
- Secondary: Task C
Milestone X+2:
- Main: Task D, a task depending on Team R
- Secondary: Task C
If the main task is blocked by the time Milestone X is underway, the work could be swapped like this:
Milestone X:
- Main: Task B
- Secondary: Task C
Milestone X+1:
- Main: Task A, Ongoing, long thing that depends on Team Q delivering some API.
- Secondary:
Milestone X+2:
- Main: Task D, a task depending on Team R
- Secondary: Some other task with no deps.
This reflects how ZCG and myself agreed on managing emerging blockers and priority changes that naturally happen in decentralized and distributed software engineering projects like Zcash. Managing a pool of possible tasks avoids being in a “deadlock” that would make the grant progress to be stalled by dependencies in other projects.
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?
The nature of the work done should not need any further integrations beyond having my PRs accepted by the organizations I’m helping. It wouldn’t require involvement from ECC or ZF besides their regular business as usual community outreach.
I would need special involvement from ZF to set up some administrative things like calendars or Conference Call Venues for LCWG.
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?
Risk: One risk could be that the workload is too much for a single person and that I’m spread too thin to be effective.
Mitigation: During this (hopefully if the community wants so) first half of the grant, it has been the case that some milestones were too varied and I noticed I suffered a lot from context switching. I’ve come to manage it, but for this following chapter I will try to be more dedicated to a main objective within one (or more) milestone, and a secondary one. This will not only help me be more effective but also be more present with the teams I’m committing to work with.
Risk: The opposite would be that teams can’t organize to delegate manageable pieces of work that I can deliver without causing them more overhead than the off-load that would mean that I could take on those tasks for them. Adding people to teams does mean that they have to dedicate some time to accommodate the new team members so they can be productive and on par with the rest of the team.
Mitigation: A way to help avoid this risk would be to create such onboarding processes as part of my work so they can use those processes for augmenting their teams and onboarding new team members or receiving open source contributions from independent developers. An example of this could be how Zingo Viridians and I worked together in shaping up darksidewalletd integration tests. The datasets and tests I worked on were documented in a way that they would be helpful for the team to keep working on them as if one of the Viridians had worked on that and not some external person. Also being my work for “general purpose” it included documentation and examples that internal development wouldn’t invest on.
Risk: Teams depended on are “off schedule” -that being late or early- in terms of the milestone forecast
Mitigation: This has happened in the past part of the grant. And ZCG and I could resolve this by anticipating work of future milestones or bringing in other work that was not originally included in the grant but that it was found to be of importance for the ecosystem. I have also worked with teams to define, scope and delimit the work I’ll be performing with them, and will continue to do so, to be fair to all teams I’m collaborating with. As it was done previously when needed, any deviations from the estimations that might affect my milestones, will be brought up to ZCG for advice.
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
An unintended consequence could be that the role becomes a single point of failure or a centralization point. The focus of this role should be supporting and empowering teams to align their particular developments with the interest of the general Zcash developer community and grow this role into a team of people that can outlive the interest of a single person.
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?
It would be a mix between completed pull requests and feedback from the development teams that require my services as community developer. Quoting the Zcash Ecosystem Security Lead grant proposal, Zcash community project developers should be asked how useful my outreach and support has been, and they should rate me as helpful, polite, and be willing to recommend working with me to other Zcash projects.
Compensation total budget / total proposed USD value of grant:
Total Request: 153900 USD = 150000 USD (10 milestones) USD + 200 USD in hardware tools + 3700 in [tentative] travel expenses (11 months in calendar, 10 months of work)
Please provide justification for the total compensation budget:
I’ve averaged the annualized compensation of a principal software engineer
Total Request: 153900 USD = 150000 USD (10 milestones) USD + 200 USD in hardware tools + 3700 in [tentative] travel expenses (11 months in calendar, 10 months of work)
Startup funding:
200 USD for ledger device + (if held) 3000 Zeboot expenses (flight + accommodation)
Payment schedule assuming January 1st
February 1st:
15,000 USD
March 1st: (assumes progress approval)
15,000 USD
… so on
Nov 1st: (assumes progress approval)
15,000 USD
Please provide justification for the total compensation budget:
I’ve averaged the annualized compensation of a principal software engineer
Total Request: 153900 USD = 150000 USD (10 milestones) USD + 200 USD in hardware tools + 3700 in [tentative] travel expenses (11 months in calendar, 10 months of work)
Startup funding:
200 USD for ledger device + (if held) 3000 Zeboot expenses (flight + accommodation)
Payment schedule assuming January 1st
February 1st:
15,000 USD
March 1st: (assumes progress approval)
15,000 USD
… so on
Nov 1st: (assumes progress approval)
15,000 USD
Schedule and Milestones: What is your timeline for the project? Include concrete milestones and the major tasks required to complete each milestone:
Do you require startup funding?
Yes.
The proposal entails providing community support and sustaining a presence within the ecosystem to build up and strengthen the role. Since some activities could consume the whole time allocation they will be time-boxed to estimate their impact in the overall schedule and milestones.
| Time-boxed Activity | time slot (hours/month) |
|---|---|
| Arborist call (two bi-weekly) | 3 |
| Light Client working group (two bi-weekly calls + administrative) | ~6 |
| ZIP-315 LCWG Initiative Lead | ~3 |
| Community Forums (depending on activity) | ~6 |
| R&D Discord (depending on activity) | ~6 |
| Office Hours (per request but in fixed scheduled) | 8 hours |
| Pull Request Reviews | ~6 |
| total | 15 to 35 hours |
I spoke with ZF, Zingo and NightHawk Apps about their upcoming timelines and development support needs. I also factored in known seasonal elements and recent ecosystem announcements, like Grant updates from RedDev on the Zavax Bridge, and QEDIT for ZSAs and from ECC to create this “grocery shopping list” of possible milestones.
These milestones are tentative and subject to change given the long term nature of the grant and the many dependencies. I completed the form to reflect the time period of the whole grant.
As it was stated before, the different milestones will vary depending on the teams’ priorities and other teams like Eiger, Ywallet or ZC Grantees requesting additional support. As is has been done in the previous grant, this situation has been anticipated and ZCG, myself and the different involved teams have worked to make the best use of my full dedication to Zcash development.
- Milestone 1: (January 2024)
- ZIP-315 LCWG Initiative Lead:
- State of the Wallet Ecosystem research
- Locate pending items, coordinate needed efforts to complete 315
- Main:
- Wallet Response to exchange requirements
- Secondary:
- ZIP-NNN: Best Practices For Wallet EOS / EOL
- Mobile SDK Support for latest Darksidewalletd Tests
- ZIP-321 Request initiated transactions (NH, Zashi, Edge, Unstoppable)
- Fixed time-boxed Allocations (see table)
- ZIP-315 LCWG Initiative Lead:
- Milestone 2: (February 2024)
- ZIP-315 Initiative Lead (Ogoing):
- Coordination and review of assigned tasks to teams
- Locate pending items, coordinate needed efforts to complete 315
- Main:
- Attend Zeboot
- FROST: Human Computer Interaction aspects of FROST & Demo (ongoing)
- Secondary:
- ZIP-321 Request initiated transactions (NH, Zashi, Edge, Unstoppable)
- Fixed time-boxed Allocations (see table)
- ZIP-315 Initiative Lead (Ogoing):
- Milestone 3: (March 2024)
- ZIP-315 Initiative Lead (Ogoing):
- Coordination and review of assigned tasks to teams
- Locate pending items, coordinate needed efforts to complete 315
- Main:
- FROST: Human Computer Interaction aspects of FROST & Mobile PoC (ongoing)
- Secondary:
- ZAVAX Bridge wallet support preparations.
- Zingo Labs: Darksidewalletd Crate PR reviews and collab
- Fixed time-boxed Allocations (see table)
- ZIP-315 Initiative Lead (Ogoing):
- Milestone 4: (April 2024)
- NYCSwift + Time off.
- Main:
- ZAVAX Bridge wallet support
- Secondary:
- Zingo Labs: Darksidewalletd Crate PR reviews and collab
- Fixed time-boxed Allocations (see table)
- Milestone 5: (May 2024)
- ZIP-315 Initiative Lead (Ogoing):
- Coordination and review of assigned tasks to teams
- Locate pending items, coordinate needed efforts to complete 315
- Main:
- Development Support for Orchard adoption and ZIP-315 compliance on Mobile SDK powered wallets
- Secondary:
- ZAVAX Bridge support
- Fixed time-boxed Allocations (see table)
- ZIP-315 Initiative Lead (Ogoing):
- Milestone 6: (Jun 2024)
- Zcon5 preparations, draft possible presentation/workshop
- Main:
- ZSAs
- Secondary:
- To determine from backlog
- Fixed time-boxed Allocations (see table)
- Milestone 7: (Jul 2024)
- Attend Zcon5
- ZSAs
- Fixed time-boxed Allocations (see table)
- Milestone 8: (Aug 2024)
- Main:
- Hardware Wallet (ledger) Support other wallets
- Secondary:
- To determine from backlog
- Fixed time-boxed Allocations (see table)
- Main:
- Milestone 9: (Sep 2024)
- [Tentative] Time Off 2 weeks
- Main:
- Hardware Wallet (ledger) Support other wallets
- Secondary:
- To determine from backlog
- Fixed time-boxed Allocations (see table)
- Milestone 10: (Oct 2024)
- Main:
- Hardware Wallet (ledger) Support other wallets
- Secondary:
- To determine from backlog
- Fixed time-boxed Allocations (see table)
- Main:
- Milestone 11: (Nov 2024)
- Main:
- Wallet implications of Zcash moving to Proof of Stake
- Secondary:
- To determine from backlog
- Fixed time-boxed Allocations (see table)
- Main: