Hi Zeeps,
I’ve heard so many Zcash narratives over the years. Some bearded VC in a suit said ZEC would soon be at zero, some years ago. Some South African troll from another project has often declared Zcash dead. It has been labeled a science project, a testnet, and a potential Bitcoin sidechain.
But 3 million blocks in, some have started to wake up, realizing that privacy is necessary for commerce, and that Zcash is the answer. But many more are in for a shock. The old crypto guard thought the answer to a free economy was Bitcoin. Don’t get me wrong, Bitcoin is nice and all, but it’s not unstoppable private money. And it’s unstoppable private money that will shock the world, and the world order.
To make this happen, we builders need to capitalize on the current environment and momentum to SHIP, WHAT MATTERS, FASTER.
Talk and hope for unstoppable private money doesn’t make it happen. We make it happen in the code we write that delivers on that promise. We ship.
There are many things we could ship. But only a few really matter for driving outcomes - things like adoption, utility, and price appreciation. We prioritize those things that will have the most significant impact on outcomes, in the shortest amount of time. We ship, what matters.
We are time poor. Tick tock. We don’t have 10 years to drive mass adoption. We don’t have 5. We must mobilize and leverage our resources well. There is no time for complacency. No time for lazy. We must continually optimize our time, reputation, liquidity, distribution, and financial resources to allow us to move more quickly. We ship, what matters, faster.
Now, I can only speak for ECC. But I challenge everyone who build, and those who support the builders in the Zcash ecosystem, to take a hard look at where our resources are flowing. Are we shipping the things that matter for delivering unstoppable private money?
ECC’s commitment is to build a Zcash-fueled no-friction user experience for everyone, everywhere, without limitation. To deliver unstoppable private money - from Zashi to the Zcash protocol, and through ever-increasing unlocks driven by interoperability with collaborative ecosystems like Flexa, NEAR, and Maya.
How are we doing?
In the last 18 months, we focused on delivering a best-in-class wallet called Zashi. You’ve told us that you love it. Love to see it.
And since its introduction, the growth in the shielded pool has gone parabolic. Shocker.
We also recently ran a community survey, similar to one we ran 18 months ago, to help inform the Zashi product direction. Here’s a summary of the NPS data.
There are a few takeaways from this data, but take a look at the shift in scores over time. The average NPS for holding and transacting in ZEC has gone from abysmal (-60) to reasonable (36 for Zashi users). A 96-point swing in 18 months is remarkable, and yet we still have work to do.
Zcash users are also increasing their usage of ZEC as shown below. But this is just the beginning. Shock comes when we move beyond the majority of users using ZEC at least sometimes, to when the majority is moving ZEC between each other frequently.
What are the Zashi capabilities needed to drive even more adoption? According to the survey respondents:
- DEX support
- Stablecoin support
- Off ramps
- Cross-chain payments
These are areas that will be added to Zashi in Q3 and Q4 this week, thanks to NEAR Intents, Maya, and other partners. The proof will be in the numbers.
We also need to make a few process changes in order ship, what matters, faster. As we collectively worked on an all-up Zash roadmap at the recent Z|ECC Summit (will soon publish) we recognized the coordination complexity of the Network Upgrade process as Zcash core development has become more decentralized. ECC will soon propose a change to the process to reduce the friction and coordination requirements.
Additionally, ECC changed how it manages core work to reduce distractions and time slicing while increasing focus. We have also added a new core team member (welcome Schell!) to help shoulder the workload and optimize our developer relations. And the Zashi team will also revisit our design process to minimize rework and iterations that impact our developer workload.
But ECC cannot do this alone. I urge you Zeeps, to think hard, ruthlessly prioritize and cut the superfluous, reduce timeliness, and dig deep. Ship, what matters, faster. Ship shock.
Here’s what we’ve done to ship shock this week:
Zashi
What we did:
- Updated and finalized requirements and designs for Swap or Pay with NEAR based on Z|ECC Summit testing.
- Updated and finalized requirements and designs for Tor opt-in/out logic.
- Implemented updated Tor opt-in/out flow both on the SDK and Zashi side. (iOS 0.8.6 (1) ready for testing, Android on the way)
What’s up next:
- Test Tor opt-in/out flow on iOS and Android, catch and fix any issues.
- Start implementing changes and additional requirements for Swap or Pay with NEAR v1 on Android.
- Discuss, finaliz,e and put in place a product process, determine design priorities for this quarter, and kick it off!
iOS Analytics
- Unique Installs: 8.87k
- Total Downloads: 10.7k
- AppStore Rating: 4.9*
Android Analytics
- Unique Installs: 3.83k
- Total Downloads: 20.6k
- PlayStore Rating: 4.227*
Zcash Core
Welcome, Schell Scivaly, to the ECC core team!
What we did:
- Zcashd deprecation: specified and implemented the string encoding of wallet seed fingerprints and reviewed zcash_script PRs.
- NU7: ZSAs - reviewed Qedit’s updates to ZIPs 227 and 230 to distinguish issuance keys from issuer identifiers (zips#1048), and made some further improvements (zips#1053); NSM - reviewed the PR implementing burning for ZIP 233 (librustzcash#1567).
- Core libraries: Draft fix for a bug restoring fees in wallet recovery: librustzcash#1862; improvements to Zallet’s robustness to abrupt shutdown (zcash/wallet#185); investigated libraries that could be used to reduce boilerplate in error handling code.
- Research: While examining how to complete the FROST key generation section of ZIP 312 (which interacts with the Quantum resilience proposal), we identified an issue that would have made it difficult to support hardware wallets in the latter. Daira-Emma sketched out the changes needed to add another “qsk” key (based on a suggestion by Str4d). This allows a post-quantum hardware wallet to only compute a proof for a very simple circuit, and makes the “qk” key provide intermediate authority between full-viewing and spending, allowing it to also be used for receive authorization to address a problem with Qedit’s transaction controls proposal.
What’s up next:
- Review the implementation of NU6.1 ZIPs (key rotation and one-time lockbox disbursement).
- Continue with Schell’s onboarding.
- Complete the implementation of P2SH multisig.
- Ensure that zcashd is in a fully releaseable state.
- Cut the Zallet alpha release in a week or two.
That’s all for this week.
Shipping shock,
Onward.