Zcash Wallet Community Developer 2024 Q1

Community Grants Applications
1

Dear Zcash community. I’ve submitted a Grant Application to extend my ZWCD through 2024 and keep developing on behalf of the Zcash Community.

You can find the proposal submitted to ZCG here:

In this post I’ll try to add a Format-rich version. This submission builds on top of the previous one based on the collected experience and forecasted development work that I’ve been collecting from the various team updates.

I apologize for the wall of text in advance.

Applicant: Pacu

Do you have additional team members/collaborators? NO

One liner elevator pitch (max 140 chars)

A “floating” wallet developer that contributes to different Zcash wallet teams and supports ZCG to articulate community-funded efforts

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)

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

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

Applicant Background

Note to readers: following section is a refreshed update to the one presented previously back in July 2023. I’ve taken this approach because I consider it would favor readability, so that people don’t have to constantly refer to the past presentation. I apologize in advance to readers that don’t find this helpful.

I’m Pacu. I’m a Software Developer. I have a Master’s Degree in Software Engineering and I’ve been proudly working as a Zcash wallet developer for around four and a half years. The first four as part of ECC’s wallet team, and these last 5 or 6 months as a ZCG grantee as Zcash Wallet Community Developer. You might have seen me around in the forums, Zcon talks, community calls, or any might not know me well or at all! Anyhow, I’m pretty sure that most of you might have interacted with the code I worked on.

Disclaimer: I don’t like self-indulgence. The intent of this section is to recollect my participation and contributions to the Zcash space so you all can evaluate whether I have the necessary skills for the role I propose or not.

My overall experience

I always liked to work on stuff that people could take into their own hands. I’ve been developing software since 2008. First as a retro-porter at Gameloft where I learned to move around a myriad of code bases and game engines to fit popular games into low-end JavaME mobile phones, since then I’ve been dedicated to mobile-first applications. I’m not a “grasshopper” kind of developer, so in these last 16 years of experience I’ve had 3 or 4 jobs at most. Nonetheless I’ve been able to work in Corporations, Unicorns, freelance gigs and start ups; from publishing, to Investment Firms, Entertainment Corporations, Travel and Leisure companies and lastly decentralizing finance and fighting for the right to privacy. But always within the last mile of the software chain from the server to people’s fingertips. In my last big corp gig I worked with more than 60 developers serving millions of users in LATAM for the biggest online travel agency. I can say that I have the experience of walking into a bar and knowing that everyone there has your app on their phones. My hope is that we can achieve that with our Zcash applications.

My journey as a Zcash Dev

First I started as an iOS Developer contractor for ECC and then as a full-time iOS Engineer, where I built the iOS Zcash SDK (GitHub - Electric-Coin-Company/zcash-swift-wallet-sdk: iOS light client Framework proof-of-concept) and the first ECC reference wallet using SwiftUI (https://github.com/zcash/zcash-ios-wallet), shipped publicly as NightHawk Wallet by Nighthawk Apps. I didn’t do this by myself. I had my ECC colleagues who helped me all the way. It is necessary to understand a lot of how Zcash works to effectively develop a mobile SDK that can be a “drop-in” kind of tool for developers around the world. This led me to have a good understanding of the Zcash light-client protocol, and “the protocol” itself. I worked back to back with Kevin Gorham, my Android counterpart, since I started the SDK as a “port” from the Android PoC which also let me actively contribute every now and then to that codebase as well. Later on I would have to onboard other great developers to our codebase. So I did end up learning a lot of Kotlin along the way.

Wallets are an interdisciplinary work. Inevitably, I ended up picking up some Rust Lang skills which helped me be a more effective contributor all across the tech stack by contributing to the Rust backend: LibRustZcash (Pull requests · zcash/librustzcash · GitHub). One of my most cherished PRs is this one that implements the principles of autoshielding; I had a great collaboration with ECC’s Core Team to guide me through this implementation which ended up being the backbone for “shielding by default” in our native mobile platforms (https://github.com/zcash/librustzcash/pull/341).

Security and Testing were always priorities for our team. Taylor Hornby and Larry Ruane co-created a set of RPCs in lightwalletd that let developers create a local ZIP-307 compliant synthetic compact blockchain and write integration tests that can reproduce blockchain edge cases. I kind of became the “darksidewalletd guy”. We called this suite “Darksidewalletd Tests” and their first implementation was carried out on ZcashLightClientKit (zcash-swift-wallet-sdk/Tests/DarksideTests at main · Electric-Coin-Company/zcash-swift-wallet-sdk · GitHub). This helped our team to develop on solid grounds knowing that our SDK would react properly to chain re-orgs. Working on these tests also had me working a bit in Go Lang (Pull requests · zcash/lightwalletd · GitHub) when I caught bugs in Lightwalletd itself.

Going down memory lane, one of my earliest work in tandem with @earthrise was finding a safe native library for BIP-39 for the Swift programming language. We conducted a survey of existing implementations of BIP-39, forked the one that best suited our SWOT analysis and created MnemonicSwift. GitHub - Electric-Coin-Company/MnemonicSwift: MnemonicSwift provides a Swift implementation of BIP39 using CriptoKit and even got it listed in the Bitcoin wiki page. BIP 0039 - Bitcoin Wiki

Building a Legacy

One of the goals I always had is to build a legacy. Projects that others can take over to the finish line. This entails setting up code conventions, contributing guidelines, abiding by industry standards, setting up coding guidelines, and more. Carter Jernigan and I worked hard on

making that possible over the past year. The last wallet project I worked on at ECC is the

Secant wallet. It has a lot of that. It is being actively developed by ECC and Nighthawk Apps in

different forks. It was designed to be iterative, fast-paced, testable, rock-solid, and more

importantly, end-user-facing. We aimed to base Secant on tech stacks that would be not only

relevant in the present but also future-proof. We developed Secant in the open since day

one. Anyone following the commits will be able to see its many iterations, different faces, and

phases. Secant in its two forms, is actively built by great developers in two teams with different

product plans and design approaches that will get ZEC into the hands of thousands and

hopefully millions of users across the globe.

Ecosystem Outreach work

One of the things I enjoyed a lot was working with the different teams on the Zcash Ecosystems. Whenever I was given a chance I tried to reach out to other teams to know about their work, and think about how I could make the SDK more useful to them. In May 2020, the wallet team co-hosted and also participated in the “Protect Privacy” Gitcoin hackathon (buidlbox). One of the teams participating ended up becoming the Nighthawk Apps team! They had the bravery and the talent to take the ECC Reference Wallet down to the finish line to be launched at the Apple and Google Stores (and also Fdroid!). Since then I’ve been collaborating very frequently with Nighthawk Apps and their team. Our work together, ended up creating the “Light-Client Working Group” or “Zcash Mobile Dev Calls” which have been held bi-weekly for quite some time now (see GitHub - zcash/lcwg: Light Client Working Group project management repository)

Another great partner and supporters of the Zcash cause are the folks at Unstoppable wallet. They have amazing multi-coin native applications for Android and iOS. It took me less than a day to draft a PoC integration to their iOS wallet. That is how modular their code is, pretty awesome. Obviously they took the baton and implemented the whole thing themselves and I helped occasionally as you can see in a few PRs (Pull requests · horizontalsystems/unstoppable-wallet-ios · GitHub.

I had the chance to briefly work with Paul and the EDGE wallet team, but to be honest, they mostly did everything and I just provided some guidance and incorporated their feedback into our codebase. They are an awesome team and are fully committed to the values of financial privacy that Zcash embraces. I hope if I get this grant I can collaborate with them more.

One of my latest collaborations was with ZingoLabs, to bring darksidewalletd tests to their Zingo wallet by creating a PoC in Rust on how they could leverage this powerful tool (Pull requests · zingolabs/zingolib · GitHub). I use Zingo Lib for some personal projects of mine and for educational purposes when teaching in college. Zancas and team are very engaged with the whole idea of integration tests for wallets and it seems they plan to take it to the next level.

RFP and ZIP collaboration

Like many other Zcash developers I contributed to ZIPs and RFPs of great relevance to the Ecosystem like ZIP-317: Proportional Transfer Fee Mechanism or ZIP-316: Unified Addresses and Unified Viewing Keys and ZIP-315: Best Practices for Wallet Handling of Multiple Pools. I also helped draft the Zcash UniFFI Library RFP

Seminars and talks

Although these appearances were not a part of my job, I participated in many twitter spaces, conferences and podcasts related to Zcash and privacy.

Hello decentralization Conference: In February 2021 I participated in a workshop session at “Hello Decentralization” where I did a “code along” session where attendees could build a Point of Sale proof of concept app with ZcashLightClientKit and Swift UI. The session was called “We accept Zcash! building a PoS App with Zcash Viewing keys”. The site of the conference unfortunately is down. I could find this link (Hello Decentralization // 22nd - 26th February, 2021 - Crowdcast) and the repository with the code-along material can be found here (GitHub - zcash-hackworks/we-accept-zcash-ios: A Proof-of-Concept on how to build a Small iOS App that lets you accept Zcash as payment).

Zcon3: “The once and future ECC wallet”. In this talk we covered the past, current and future roadmap for ECC Wallet.

Zcon4:

  • Zcash wallet workshop with Adi from NightHawk and Joel Valenzuela from Digital Cash podcast
  • Presented speakers and forwarded questions from the audience to them in a few talks as well.

Podcast Appearances: “Hacia Afuera” podcast. A podcast about latin american professionals making great contributions from the region to all the world. Link: Ep 80 - Francisco Gindre (Electric Coin Company) - Zcash - Hacia Afuera con Omar Espejel | Podcast on Spotify

Research and Education

Unrelated to blockchain but relevant to the tech stack we use here, I taught Introduction to Programming with C from 2009 to 2018 as an assistant professor in different private universities in Buenos Aires.

Teaching gives people a unique experience where one can learn differently, because “those who teach learn twice”. I like creating documentation, presentations and classes that aim to be appealing and motivating to students.

Back in my undergrad college days I also worked in research and development and published different papers about soft computing and text mining. This helped me polish formal aspects of written English and also technical and scientific writing that definitely helped me grasp the protocol and all the ZIPs Zcash has.

When I say that I’ve dedicated these last 4 years to Zcash and the privacy space, I really mean it. I graduated from the Software Engineering Master Degree program of the National University of La Plata with a Thesis that studied Privacy Coin mobile wallets and their architecture. I described a framework of software patterns based on reverse engineering requirement analysis of existing non-custodial privacy coin wallet applications. (link in Spanish) https://doi.org/10.35537/10915/137845

This work derived into a research paper on wallet software design patterns presented at the Pattern Languages of Programs conference of 2022 an early draft can be found here. According to conference chairs, the paper will be listed in the ACM Library soon.

I’m currently also working as an Assistant Professor in the “Introduction to Blockchain” course at the Faculty of Informatics of the National University where I use tools such as Zingo-cli to explain how Zcash works.

Zcash Wallet Community Developer

During Zcon4 I started a new journey in my career. I became a ZCG Grantee and was honored with the duty of working as a wallet developer for the Zcash ecosystem. Although some milestones seemed quite ambitious, I achieved all the proposed goals and presented my progress to ZCG synchronously in conference calls and through the forums to the whole community in this thread.

A summary of the achievements:

User Facing Development

Although all milestones are thought in terms of how to make wallets better, there are some parts of being ZWCD that impact users more directly than others.

Native support for ZIP-321 Zcash Payment URIs for Android and iOS/MacOS

I created two distinct Native Swift and Kotlin Libraries that:

Remarks:

  • The Kotlin variant is a really good candidate to be turned into Kotlin multi-platform supporting javascript and even iOS for kotlin multi platform wallets!
  • Found a nasty bug in Swift Compiler on Decimal handling. :confused: which is, following their tradition, completely known and ignored by Apple

Developer Tooling

General Purpose, Reusable Darksidewalletd Datasets:

“Darksidewalletd” is a development tool that lets developers create synthetic compact blockchains. These blockchains are totally controlled by the devs and can be shaped specifically to exercise specific scenarios for the wallets, such as chain reorgs that can cause transactions being unmined, tx reverted and all sorts for state changes that the wallets need to adjust to in order to keep the users’ funds spendable. I worked with Zingo Labs to ideate and create test scenarios that can help wallet developers benchmark, test and bugfix their wallets. These scenarios are not set in stone. Each one of them has scripts that can be ran to modify them and update them as needed, they can evolve as the protocol evolves. GitHub - zingolabs/darksidewalletd-datasets

  • 151 coinbases: This is a darksidewalletd dataset composed of 151 blocks of 1 transparent coinbase to the legacy t-address of zcashd and 150 shielded coinbases to sapling address.
  • SECOND FLUSH OF ENTHUSIASM: A user gets onboarded into ZEC at a given time (block 1) and creates a wallet. User forgets about it until a later time it realizes it can accept a Zcash payment instead of fiat, so User intends to receive ZEC.
  • Advanced ReOrg Tests: This is a set of tests originated as part of integration testing of the ECC Mobile SDKs

Python API to interact with Zcash node RPCs:

Part of this work ended up in creating python scripts that could use Zcashd RPCs to handle nodes in Regtest mode. As tests built up, this python starter to take the shape of an API which is expressed in this python file.

Advanced Re Org Test implementation on Zingo-lib

Zingo Viridians took the darksidewalletd work I had done and took it even further, grouping all the implemented test cases into a rust cratehttps://github.com/zingolabs/zingolib/tree/dev/darkside-tests .

Bringing Supporting Regtest/LocalNetwork testing back to Mobile SDKs

Originally, the mobile SDKs had a suite of tests that allowed us to have a “canary” that would warn developers of regressions when changes were introduced into the codebase, mostly around chain re-orgs and the consistency of the internal state of the wallet SDKs. Due to various types of resource constraints these tests stopped working and were left unmaintained when Spend Before Sync. Given their importance it is one of my goals to bring them back to the place they deserve. It was originally intended to “just enable them back”, but given the experience we gained in the Zingo Lib integration, it was recognized as more beneficial to actually get them to work fully on a the new datasets that were not reliant on mainnet, because the original darksidewalletd tests would only prove that the wallet synced properly sapling blocks of version 4 transactions. This is a more ambitious effort that goes across many repositories and layers of the wallet stack. These changes are still in-flight but yet bring enhancements on their own, like the ability of providing custom checkpoints.

This is an extract of the last forum update for milestone 5.

task link
CI enhancements for Swift SDK Implement darkside counterpart for `z_getsubtreesbyindex` method · Issue #464 · zcash/lightwalletd · GitHub
Librustzcash regtest support (ongoing) Add regtest support to `Parameter` for Mobile SDKs by pacu · Pull Request #1054 · zcash/librustzcash · GitHub
Custom Checkpoints for Regtest mode
On Zcash Swift SDK [#1330] Ability to provide custom checkpoints on Testing environments by pacu · Pull Request #1331 · Electric-Coin-Company/zcash-swift-wallet-sdk · GitHub
Support for Spend Before Sync on Darksidewallet [WIP] - Creates cached state for SubTreeRoots in darksidewalletd by pacu · Pull Request #468 · zcash/lightwalletd · GitHub

Light Client Working Group

With great support of @decentralistdan we held 13 meetings of the Light Client Working Group, a venue that gathers Wallet developers together to share their work and tackle problems specific to the Zcash wallet ecosystem, you can see all the notes in this repository

The Reboot

LCWG had lost most of its momentum, so we decided it was time for a fresh start. @aquietinvestor, @decentralistdan and I brainstormed a new format to bring the excitement back. We organized the working group in a way that it would reduce the amount of “status updates” and focus on Work initiatives. We identified three initiatives we wanted to work on and people volunteered to lead each one of those, while teams would have to commit some resources to carrying them forward:

  • LCWG working Initiatives:
    • ZIP-315 support on the wide wallet ecosystem
      • Appointed Lead: Pacu (ZWCD)
    • ZIP-317 Implementation across the ecosystem
      • Appointed Lead: DecentralistDan (ZF)
    • Decentralize Core Development, Zcashd, lightwalletd and other tooling
      • Appointed Lead: Zancas (Zingo Labs)

Code Reviews and small contributions:

Over the course of the last grant I’ve reviewed almost thirty pull requests from many teams like NightHawk Apps, Zingo Labs and ECC. Most of them were requested directly and others were ad-hoc. I watch many of the core repositories of the Zcash ecosystem and I get PRs and activity feeds in my inbox. Every day I “get to work” I go through my notifications to see what I’ve missed (ZEC has many night owl contributors!) and things I consider worthy of ZWCD’s attention I’d review and comment if needed.

Tutorials

Created a tutorial on how to run zcashd in regtest mode using docker. This info was outdated and scattered around several places, now it’s updated and in a single location.

Community and Ecosystem Activities:

User support

The community part of the grant title was also endured. During the last grant period I worked with other community members to help them in certain circumstances that troubled them. Such as outages in ZecWallet Lite, users having issues with wallets not syncing among others. I have to give a massive shout out to @autotunafish from ZF for being present for every user needing help.

Office Hours

Another side of the ZWCD was this concept of office hours where I allocated a fixed amount of hours to meet people that wanted to get some help, assessment or counseling from someone from the Zcash development ecosystem. This kind of thing is often done by “Dev Rel” people in other development ecosystems.

  • RedDev <> ZCWD: We went over some overall concepts of the ZAVAX bridge. His team is working on implementing the Zcash <> AVAX bridge in a similar way the BTC <> AVAX bridge was done for V1 and then iterating to build up a more seamless experience for the user. We met recurrently over several weeks brainstorming and revisiting the proposed designed that were recently presented to ZCG as detailed on their last forum update
  • Chainsafe <> ZCWD: Met with Chainsafe Team reps to go over various topics and doubts on their Zcash SDK proposal we channeled their inquiries through the Light Client Working Group and resulted in them presenting a grant for a Javascript Zcash SDK
6 Likes
2

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)
  • 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)
  • 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)
  • 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)
  • 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)
  • 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)
  • 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)
1 Like
3

@pacu at the most recent meeting, the @ZcashGrants Committee voted to approve the newly edited 3-month proposal and has requested that you provide monthly updates via the forum in this thread.

4 Likes
4

@ZcashGrants Thank you very much for honoring me to continue representing the community in our developer ecosystem.

6 Likes
5

Public Github Project that I will use to manage this grant is ZWCD 2024 Q1 · GitHub

2 Likes
6

Hello Community! I’m reporting updates on Milestone 1 of the grant.

Milestone 1 - Jan 15th to Feb 15th

Github: 2024 Q1 Milestone 1 Milestone · GitHub

Deliverable 1.1

ZIP-315 LCWG Initiative Lead

ZIP-315 specifies “Best Practices for Wallet Handling of Multiple Pools”. It has been in draft state for a long time. Working on 315 to its completion is very important to achieve the demands of the Zcash community. Currently the different Zcash wallets handle themselves in their own particular manner. Although diversity is always welcome, divergence in things like unified addresses, change management, shielding, pool migration and support of the different pools has led to increased UX friction, perception of loss-of-funds among other problems that are detrimental to the Zcash ecosystem and its users.

For all of this, we’ve set finalizing 315 as one of the Light Client Working Group work initiatives.

Status: delivered (ongoing)

Achievements:

  • Review of the current draft and suggest improvements and changes
  • Collect all specified requirements into a list to create a compliance matrix
  • Track all TODOs and start addressing them

Remarks:

  • This ZIP will be somewhat influenced by the outcome of the ZIP-320 aka “exchange addresses”, so its completion will be tied to it.

Details of the tasks

(all tasks of the milestone can be found here 2024 Q1 Milestone 1 Milestone · GitHub )

task link
Extracted requirements [ZIP-315] Condense all specified requirements into a table to track wallet compliance. · Issue #785 · zcash/zips · GitHub
Reviewed and suggested comments https://github.com/zcash/zips/pull/607
TODOs collected [ZIP-315] TODO's documented on DRAFT · Issue #786 · zcash/zips · GitHub

Deliverable 1.2

Wallet Response to exchange requirements

ZWCD was appointed by the Zcash Community Grants committee (ZCG) to help out with an ecosystem outreach about “Exchange Addresses”.

This is an ongoing task that will last until the selected approach from ZIP-320 is implemented and deployed in both wallets and exchange (Binance)

Status: on track

Achievements:

  • We’ve defined a workgroup that includes authors from both alternatives described on ZIP-320 (Hahn for TEX addresses and Daira and Kris for UAs), Jason McGee from ZCG and myself to carry on this initiative
  • With the help of many actors from the ecosystem such as ZCG, ZF and ECC we’ve created an outreach campaign to communicate ZIP-320 as well as gather sentiment and feedback about it.
  • We are gradually communicating with partners from our ecosystem.
  • Zcash’s proposal has passed Binance revision and will not be delisted on Feb 29th.
  • ECC is working on decoupling librustzcash dependencies that will enable faster development of any of both variants of ZIP-320

Remarks:

  • This work effort has brought unprecedented cross-team collaboration from the most relevant teams of our ecosystem

Deliverable 1.3

Attend Zeboot

Status: Delivered

Zeboot was an incredibly productive event.

All the notes and remarks can be found on this free2z page

Quote:

Zeboot had some journeys packed with workshops and presentations, but there was a lot happening on the sidelines too. Lunch breaks, ad-hoc gatherings and meetings that went for long hours into the night. Those conversations were not logged into these diaries. They will remain as private as the memos on our blockchain. What I can surely disclose is that I left Zeboot with the impression that it was not much about what ECC had to announce. It was about ECC opening up to the community and the different actors of the Zcash ecosystem, listening to what they had to say and including that feedback into their vision for the months ahead.

Of course, there is a great deal of optimism in these last sentences. Our present is rough and the challenges ahead do not seem to be any softer. My optimism lies in the fact that the community was asking for changes and that’s what I mostly noticed during Zeboot: changes being made. Only time will tell if they were “the right ones” or not, but I have the feeling that these changes are the first of many.

Deliverable 1.4

Fixed time-boxed Allocations

Status: delivered;

Achievements:

Details of the tasks

(all tasks of the milestone can be found here 2024 Q1 Milestone 1 Milestone · GitHub )

task link
Regtest support on Librustzcash Add regtest support to `Parameter` for Mobile SDKs by pacu · Pull Request #1054 · zcash/librustzcash · GitHub
Ad-hoc PR review of Zashi [#1028] Runtime switch of lightwalletd servers by LukasKorba · Pull Request #1044 · Electric-Coin-Company/zashi-ios · GitHub
DSL for non-linear sync tracing IDEA: DSL for non-linear sync tracing and debugging
LCWG 68 [#78] LCWG Call #68 notes by pacu · Pull Request #79 · zcash/lcwg · GitHub
LCWG 69 [#78] Call #69 notes by pacu · Pull Request #81 · zcash/lcwg · GitHub
LCWG 70 [#82] LCWG call notes #70 by pacu · Pull Request #83 · zcash/lcwg · GitHub
Wrap up Regtest support on librustzcash Add regtest support to `Parameter` for Mobile SDKs by pacu · Pull Request #1054 · zcash/librustzcash · GitHub
Adhoc PR review on Zashi [#1028] Runtime switch of lightwalletd servers by LukasKorba · Pull Request #1044 · Electric-Coin-Company/zashi-ios · GitHub

Deliverable 1.5

ZIP-NNN: Best Practices For Wallet EOS / EOL

This deliverable consists of creating a draft ZIP that describes best practices for wallet maintainers in the event of an End of Service / End of Life event of some or all versions of their wallet applications.

ZIP PR: Draft a ZIP to provide best practices for Wallet App EOS/EOL by pacu · Pull Request #782 · zcash/zips · GitHub

Status: delivered (pending review and approval)

Achievements:

  • Specification of EOS/EOL events and taxonomy
  • Best practices for anticipating, planning and executing an EOS/EOL on a wallet application or a subset of its versions.

Remarks:

  • This is something that will avoid many of the issues that ZecWallet faced during the time it was not maintained.
3 Likes
7

Great work on the darksidewalletd stuff, that’s super underrated and it’s going to pay off by making sure users don’t encounter weird edge-case bugs.

:100: I noticed that too in my audit, it would be great to have those tests back.

All of your milestones look important to me but ZIP 315 is great to see (it’s super important for users having a consistent experience and good privacy) and it will be amazing to get Ledger integrated with the wallets once it’s available!

Thanks for putting in all the effort that you do!

2 Likes
8

Hello Again Community! I’m reporting updates on Milestone 2 of the grant.

Milestone 2 - Feb 15th to Mar 15th

Github: ZWCD Q1 2024 - 2 Milestone · GitHub

Main:

  • ZIP-320 Wallet Response to exchange requirements. Coordination and ecosystem outreach
  • ZIP-321 Request initiated transactions (NH, Zashi, Edge, Unstoppable)
  • Fixed time-boxed Allocations (see table)

Secondary:

  • FROST: Human Computer Interaction aspects of FROST & Demo (ongoing)

Deliverable 2.1

ZIP-315 Initiative Lead.

Status: pending ZIP editors review

As mentioned in the Milestone 1 update, I reviewed the ZIP draft and pointed out TODOs and requirements extracted. They are pending review from the ZIP editors. Time that would have been spent in this task was dedicated to others that had a higher priority.

Deliverable 2.2

ZWCD was appointed by the Zcash Community Grants committee (ZCG) to help out with an ecosystem outreach about “Exchange Addresses”.

This is an ongoing task that will last until the selected approach from ZIP-320 is implemented and deployed in both wallets and exchange (Binance)

Status: on track

Achievements:

  • We communicated with several partners across the ecosystem and consulted them for feedback on the two alternatives: UAs and TEX addresses.
  • Binance decided that they would only implement the TEX approach due to policies they have on including third party libraries on their front-end.
  • TEX address support is already implemented on Ywallet (Kudos to @hahn)
  • ZIP-320 is finalized, merged to main branch of the zips repository and waiting for ZIP editors to upgrade its status to final
  • Coordinated with ECC for them to release SDK with TEX address support as soon as possible. Developers like EDGE, Unstoppable and NightHawk have an API ready version of the SDKs for them to prepare for the next release from ECC after Zashi is launched. According to Andrea (ECC’s project manager) the TEX support release of the SDKs will be somewhere in April 2024.
  • @aquietinvestor and myself have begun contacting different Zcash partners (both supporting shielded or transparent ZEC) to inform them of ZIP-320 and what are the implications for them.
  • Added TEX support for Swift Payment URI library

Details of the github tracked tasks

(all tasks of the milestone can be found here ZWCD Q1 2024 - 2 Milestone · GitHub )

task link
TEX support for Swift Payment URI library [#40] Support for verifying TEX address charset by pacu · Pull Request #41 · pacu/zcash-swift-payment-uri · GitHub

Deliverable 2.3

ZIP-321 Request initiated transactions (NH, Zashi, Edge, Unstoppable)

For this deliverable I worked on the ECC Android and iOS SDKs to add support for initiating transactions from ZIP-321 payment requests based on the new Transaction proposal API of the SDKs.

Originally, the SDKs had a sendToAddress function that would receive an address, an amount, a memo and it would attempt to perform a transaction to a recipient. The Proposal API lets wallets propose a transaction, review it and then submit it to the network. This accommodates well to ZIP-317 fee requirements where fees depend on the composition of the transaction itself so to know whether a user can afford to make a transaction, it has to be accounted its inputs and outputs so that fees can be estimated beforehand since the user might think that it has sufficient funds to make a transaction and maybe it is not the case for the variable fees.

I exposed functionality present long ago in Librustzcash (thanks to @nuttycom) and combined the Proposal API so that users of the SDKs can make a proposal from a Payment URI (for example to send a message to ZecPages).

Status: Delivered

Achievements:

  • Exposed the API for the Swift (iOS) SDK and added darksidewalletd tests
  • Exposed the API for the Android SDK (android does not support darksidewalletd tests as iOS does :frowning: )

Remarks

  • iOS functionality was merged
  • Android is pending review and waiting to be merged

Details of the tasks

(all tasks of the milestone can be found here ZWCD Q1 2024 - 2 Milestone · GitHub )

task link
Implement Transaction proposal for ZIP-321 URIs for Kotlin SDK [#397] Add ZIP 321 URI parser by pacu · Pull Request #1409 · Electric-Coin-Company/zcash-android-wallet-sdk · GitHub
Implement Transaction proposal for ZIP-321 URIs for Swift SDK [#1379] Fulfill Payment from a valid ZIP-321 request by pacu · Pull Request #1390 · Electric-Coin-Company/zcash-swift-wallet-sdk · GitHub

Deliverable 2.4

Human Computer Interaction and software engineering aspects of self-custody with FROST & Demo

This is an ongoing task of research and development of what are the pieces needed to support self-custody with FROST. For that I created a report which scoped is to introduce the reader to the problem of self-custody on hot wallets and propose a sovereign key custody pattern that allows users to increase safety of their daily transactions by splitting the spend authority to several devices within a threshold scheme that takes away individual spend authority to internet connected wallets making them less vulnerable to capture by adversaries without sacrificing versatility or requiring dedicated companion hardware.

Status: delivered (ongoing)

Achievements:

  • Studied the current demo on the FROST book
  • Studied the self custody proposal presented by ZF engineers
  • Studied existing literature on self-custody challenges and key custody patterns
  • Proposed a new pattern called “Shared custody with Self” that uses FROST to allow users to use ZEC without having complete spend authority within a single device, maximizing recoverability and security and minimizing risks of loss-of-funds due to malicious actors or user error.
  • Missing pieces for “FROST on mobile” are identified and detailed on the report.

Remarks:

  • ZF’s FROST team will review the report and we will keep iterating on the design.

Details of the tasks

(all tasks of the milestone can be found here ZWCD Q1 2024 - 2 Milestone · GitHub )

task link
FROST: Human Computer Interaction aspects of FROST (ongoing) FROST: Human Computer Interaction aspects of FROST (ongoing) · Issue #99 · pacu/zwcd · GitHub

Deliverable 2.5

Fixed time-boxed Allocations

Status: delivered

Achievements:

  • LCWG #71
  • Review RFP Docs
  • LCWG call notes #72
  • Arborist Call #70
  • Review possible RFP for zcash_address port to swift, kotlin/java, js
  • [Office Hours] ZAVAX Bridge
    • March 5th. 1hr.
    • Topics discussed:
      • use of FROST on ZAVAX validators
      • potential creation of a Metamask SNAP
    • March 12th. 1hr
    • Topics Discussed:
      • Quick research of Zcash metamask snap feasibility and things needed to achieve it.
  • [Office hours] My First Zcash Chapter 6
    • 2024-02-28 1hr chapter review
    • Attended community call March 13th 1hr
    • Wrote 80% of chapter 6 4hrs
    • attended community call March 20th 1hr
  • Ad-hoc PR reviews

Details of the github tracked tasks

(all tasks of the milestone can be found here ZWCD Q1 2024 - 2 Milestone · GitHub )

task link
LCWG #71 [#84] LCWG call #71 notes by pacu · Pull Request #85 · zcash/lcwg · GitHub
LCWG call notes #72 LCWG #72 call notes · Issue #86 · zcash/lcwg · GitHub
Ad-hoc PR reviews https://github.com/Electric-Coin-Company/zcash-swift-wallet-sdk/pull/1382
[Zashi-iOS audit] Issue E: Copying of the seed phrase should be discouraged · Issue #1097 · Electric-Coin-Company/zashi-ios · GitHub
Consider disabling zcash: URI scheme · Issue #1096 · Electric-Coin-Company/zashi-ios · GitHub
7 Likes
9

Hello! I just wanted to give a quick update. I’ve been a little bit back on some of my scheduled milestones and advancing on others from the continuing grant.

I apologize for the delays.

Doing detailed milestone reports as the ones I’ve been doing takes time so I’ve been prioritizing getting time-sensitive things done first and then worrying about the administrative stuff (and getting paid :sweat_smile:).

You’ll have a milestone report in the next few days once I add some tests to this juicy frost-poc-sdk I’ve been working on GitHub - pacu/frost-mobile-sdk: Proof-of-Concept of a FROST mobile SDK using Uniffi

Thanks for the confidence and support the Zcash community gives me every day. :heart::zebra:

5 Likes
10

Hello! As promised, I’m delivering the update for this grant. I took a small break the second half of April from some of my tasks (except for ZIP-320 outreach) plus some things that took me more time than I thought.

Milestone 3 - March 15th to April 15th

Github: ZWCD Q1 2024 - 3 Milestone · GitHub

Deliverable 3.1

ZIP-315 Initiative Lead (Ogoing)

Status: ZIP editors are reviewing the ZIP.

As mentioned in the Milestone 1 update, I reviewed the ZIP draft and pointed out TODOs and requirements extracted. They are pending review from the ZIP editors.

Time that would have been spent in this task was dedicated to others that had a higher priority.

ZIP-320 Ecosystem Outreach (Ongoing)

ZWCD was appointed by the Zcash Community Grants committee (ZCG) to help out with an ecosystem outreach about “Exchange Addresses”.

This is an ongoing task that will last until the selected approach from ZIP-320 is implemented and deployed in both wallets and exchange (Binance)

Status: on track

Achievements:

  • We have reached out to important exchanges (this was achieved with great help of ECC leadership leveraging existing relations with them).
  • May 31st was defined as soft-date to anyone asking about a “timeline”
  • Ongoing conversations with Binance about the TEX implementation and deployment.
  • ECC is working on implementing and releasing support for TEX addresses on their SDKs after ZconV

Deliverable 3.2

Human Computer Interaction and software engineering aspects of self-custody with FROST & Demo

This is an ongoing task of research and development of what are the pieces needed to support self-custody with FROST. For that I created a report which scoped is to introduce the reader to the problem of self-custody on hot wallets and propose a sovereign key custody pattern that allows users to increase safety of their daily transactions by splitting the spend authority to several devices within a threshold scheme that takes away individual spend authority to internet connected wallets making them less vulnerable to capture by adversaries without sacrificing versatility or requiring dedicated companion hardware.

Status: delivered (ongoing)

Achievements:

  • Reviewed the UniFFI approach taken in the Eiger grant and used it as template
  • Adopted UniFFI as solution for multi platform SDK for FROST as analyzed in milestone 2.4
  • Found a possible solution to a problem ECC has been having with XCFramework deployment and GitHub repo bloat which will be implemented in the Swift Deployment of this tool
  • Got integration tests working with ed25519 curve flavor of FROST (is simpler because it has no randomizer)

Got integration tests to build with the red-pallas curve feature enabled and found an issue with UniFFI which I reported to the maintainers.

Details of the tasks

(all tasks of the milestone can be found here ZWCD Q1 2024 - 3 Milestone · GitHub )

task link
FROST: Human Computer Interaction aspects of FROST (ongoing) FROST: Human Computer Interaction aspects of FROST & Mobile PoC (ongoing) · Issue #114 · pacu/zwcd · GitHub
Frost-mobile-sdk first publication First PoC: Trusted KG, round 1, 2, aggregation and verification of signature by pacu · Pull Request #2 · pacu/frost-mobile-sdk · GitHub

Deliverable 3.3

ZAVAX Bridge wallet support preparations Review Designs to move out of BLS in favor of FROST

Given that the ZavaX bridge wallet work was not needed yet, I met with Red.Dev to repurpose this milestone to work they could use at the moment. They mentioned that they had found that BLS signatures as implemented in Avanlanche did not support Threshold signatures so they could use an architecture design review on how FROST would accommodate to the requirements of the ZavaX bridge.

ZCG approved that change for the milestone.

Status: delivered

Sign off from Red.Dev:

“Hi ZCG Committee, Pacu asked me to contact you and confirm to you that he has done the work exactly as he describes here. #118 Huge help, and a pleasure to work with. Thanks to ZCG for approving this work for him as it has helped push the ZavaX project forward.”

Summary of what was carried out: (transcription from [ZAVAX Bridge] Review Designs to move out of BLS in favor of FROST · Issue #118 · pacu/zwcd · GitHub)

  • Research on BLS requirements
  • Review of ZavaX architecture docs
  • BLS to FROST: note that signer warden is a Coordinator
  • [Meta] replace Wardens with Guardians
  • Rename HW wallet model for a generic term
    • This change is intended to remove brand specific on hardware wallet used for self-custody
  • users won’t specifically authorize the fees, it will only verify them and authorize/ reject the transaction
  • replace wallet brands for a generic term, plus fee changes:
    • We remove wallet names because transparent addresses for funding the bridging address of the users can be done from any wallet that allows the user to send t-funds. According to ZIP-317, fees are subject to the amount of inputs and outputs used in a transaction so the users won’t specifically authorize the fees, it will only verify them and authorize/ reject the transaction
  • Changes to architecture README
  • renamed wardens to guardians, added FROST as terms to use, added references to ZIP-317 fees
  • Add FROST reference to the learning list
  • add FROST DKG to Maintain guardians Sequence
    • This adds the DKG sequence from the FROST book to the mainting guardians sequence. A follow up commit must updete the graphics and the steps of the communication diagrams. This illustrates how DKG is carried out with frost. ZavaX consensus engine acts as FROST DKG monitoring party which can call an abort sequence if any errors or misbehaviors occur
  • Renaming .wsd files that mentioned wardens to reference guardians
  • Rename user story file that referenced wardens
  • Remove reference to hardware wallet brand
  • Add FROST to wallet bridge migration sequence
    • a ZavaX Agent initiates the process by calling the ZavaX Consensus Engine with the transaction plan for migrating to a new bridge wallet. The ZCE will act as a FROST coordinator to notify potential Guardians that will be part of the signature. A minimum of t >= threshold is required to sign this transaction.
    • The ZA initiating the operation may or may not be a participant although it would be highly likely that it is. For enhanced security the ZCE could choose to exclude the initiating ZA. Although, this would be less useful as t and n total signers are larger since the percentage that a single signer represents would decrease.
    • The ZCE will be also responsible of halting or restarting the signature scheme when any signer misbehaves and to report success or failures to the initiating ZA.
    • ZA finally submits the signed transaction to Zebra
  • Rename Ledger entity to HW Wallet removing branding
  • Change refs to Zcash wallet brands to generic name
  • adding FROST signature sequence to Bridge ZEC.z
    • This change adds one extra step to the Maintain guardians FROST signature sequence that includes a broadcast message from the ZCE acting as a coordinator to poll for potential signers from the “current guardians” set. At least t guardians must respond to reach the threshold.
    • Bridge ZEC.z sequence diagram also reproduces this sequence; all the steps are the same since a ZA initiates a transaction signature sequence.
  • Diagram Review with Red.Dev Team

Deliverable 3.4

Fixed time-boxed Allocations

Status: delivered

Again, I apologize for the delays in reporting the update.

3 Likes