Unstoppable. ECC Update

Hi Zeeps,

What does it take to be unstoppable?

My friend Bruce summarizes it perfectly:

“Empty your mind, be formless. Shapeless, like water. If you put water into a cup, it becomes the cup. You put water into a bottle and it becomes the bottle. You put it in a teapot, it becomes the teapot. Now, water can flow or it can crash. Be water, my friend.” — Bruce Lee

Lately, there’s been anxiety about a potential Binance delisting. I’ve criticized efforts to appease centralized exchanges before, but I get the concern—especially for those in regions where Binance is the only on- and off-ramp. The concern is valid.

But Zcash is unstoppable private money.

Any action a centralized exchange takes will become nothing more than a stone that we will soon flow over and around.

This would be a test, no doubt. It wouldn’t be our first test, and certainly not our last. And how much of a challenge these tests prove to be based on how much momentum and software we have built. And we must build faster than those attempting to thwart our path. Relentlessly build. Relentlessly flow.

That’s why the NEAR Intents DEX, Maya DEX, and bridges like red·bridge are so important. Unstoppable means that gatekeepers won’t matter; we will simply flow over and around them. Conformity is a brittle container. Unstoppable private money will not conform to their whims. We determine the path.

At ECC, we are committed to building a new system, outside the old system, as I wrote about a little over a year ago, a full stack of integrated and decentralized privacy-preserving capabilities. Many of you are also building that stack, building truly unstoppable private money.

Today, we released the ECC Q2 2025 quarterly roadmap. We update these every three months, adapting to market signals, emerging opportunities, and our unique ability to complement the Zcash ecosystem’s work. This quarter, we’re focusing on Zallet, a new Rust-based wallet to accelerate community innovation, rolling out a beautiful and fresh UX for Zashi that kills a lot of existing friction, and leaning into DEXs for seamless cross-chain payments.

These efforts aren’t just tick boxes—they’re steps toward a future where no single point of control can stop us. Every line of code, every DEX, every bridge, every wallet brings us closer to a world where privacy and financial freedom are unstoppable.

We can’t stop and fret and unnecessarily waste time with the gatekeepers. We build. We ship. Us, and you. Hand in hand.

No weakness. Together, we are water. We are flow. We are force. We are unstoppable.

Here’s how ECC contributed to building unstoppable Zcash this week:

ECC Roadmap

ECC released its quarterly roadmap this week. In this one, we included descriptions to augment the graphic and an accompanying blog that describes our engineering priorities.

Zashi

Zashi Design

  • Progressed on Multi-Account Support designs
  • Prepared designs for Crash Reporting opt-in/opt-out
  • Finalized Wallet Status Widget designs, making additional tweaks based on Product/Dev input
  • Resumed work on Crosschain Payments designs

Q&A and Dev Support

  • Testing Firebase & Zashi internal builds (focus on Wallet Status Widget)
  • Social Media Management
  • Content Creation
  • User Support
  • Community Engagement

Zashi iOS

Zashi 1.5.2 :rocket:

  • Removed Firebase Crashlytics from the project & crash reporting system with it
  • Released 1.5.2 to production

Zashi 1.5.3

  • Prepared next build, preventing sending screen from getting stuck due to failed biometrics check
  • Updated Send feedback button title

Zashi 2.0: Wallet Status Widget

  • Implemented Widget UI for the Home Screen states
  • Implemented Widget bottom sheet UI for all states
  • NetworkMonitor dependency implemented and adopted to drive Disconnected state
  • Implemented SyncError state and reporting of the issue
  • Adopted 0.15.0 FFI preview in the SDK for the progress reporting change
  • Progress reporting adopted in the widget to show restoring/syncing %
  • Implemented Remind me in 2 days, 2 weeks & ‘in a month’ logic for Wallet Backup and Shielding of transparent funds

Analytics Update:

  • Unique Installs: 7.26k
  • Total Downloads: 8.68k
  • AppStore Rating: 4.9*

Zashi Android

Zashi 1.5.2 :rocket:

  • Finished Zashi 1.5.2 and production SDK 2.2.11 releases
  • Removed the Security Warning screen from the Zashi FOSS app
  • Released one more Zashi FOSS 1.5.2 just for the GitHub Releases and F-Droid

Zashi 2.0

  • Prepared the Estimate Wallet Birthday Height feature in the SDK
  • Tested and supported exposing more lightwalletd gRPCs over Tor and exposing the scan vs recovery progress split across the FFI tasks in the SDK
  • Updated design of the Home Screen
  • Updated designs of the Wallet Status Widget
  • Implemented business logic for the Wallet Status Widget and the new bottom sheets
  • WIP: working on details and new requirements for the Wallet Status Widget
  • Removed wallet status message from app bars
  • Added possibility to use light colors for any elements in dark mode and vice-versa
  • Added a few simple tools that streamline the implementation of UI and make it a lot faster to implement

Refactoring:

  • removed code duplicity in using local preferences and improved reusability and extensibility greatly
  • created a single source of truth for creating and submitting proposals, which improved reusability and extensibility (Flexa handling is the only thing that duplicates some code, but that will be done in the future)
  • improved single responsibility principle & moved a lot of code from god classes to new logical classes, which improved reusability and extensibility
  • made various minor improvements needed to work with status messages simply

Analytics Update:

  • Total Install Base: 3.707k
  • Total Installs (incl. Open Beta): 17.208k
  • PlayStore Rating: 4.519*

Zcash Core

  • Cut the release candidate for zcashd v6.2.0. This update to zcashd alters several previously deprecated RPC interfaces disabled by default; in addition, it adds a notice that must be explicitly acknowledged via a configuration flag that zcashd is being deprecated and that a migration will be required in the future.
  • Zallet sync via the Zaino integration has been merged! In addition, Zallet now has support for async wallet operations; this paves the way for the z_sendmany implementation, which is now in progress. In addition, encrypted key-store functionality is complete, z_getnewaccount support has been merged, and an initial implementation of zcashd wallet.dat migration via the Blockchain Commons ZeWIF stack is in progress.
  • Some improvements to wallet sync reporting have been made available to the light client SDKs.

Other

ECC released its transparency report for Q3 2024.

Thanks to the NEAR community, Zcashers can earn yield on their ZEC by contributing liquidity to the NEAR Intents DEX.

This announcement was also a big deal. If it had been implemented, we would have been forced to collect PII on Zashi users (likely even Zallet) or shut it down, which is what we would have done. This would have also affected DEXes. Fortunately, there was good bipartisan support to overturn the rule. Hard-fought win.

@Alex_ZF from the Zcash Foundation, @aquietinvestor from Shielded Labs, and I meet every other week to drive collaboration and information sharing between the organizations primarily responsible for core development. This week, we discussed the funding governance ZIPs and the process for assessing community sentiment.

We also met with @_jon from Qedit to coordinate ZSA go-to-market initiatives. While unlocking ZSAs in the protocol is coming soon, we still need issuers.

Don’t forget to review and weigh in on the governance-related ZIPs. Polling will begin April 17th.

That’s all for this week.

Building unstoppable,

Onward.

18 Likes

Would love to see support for connecting to light wallet servers hosted as Tor hidden services as a part of this endeavor. That solves a big problem with hosting your own light wallet server: getting it to work behind a home router, and without a domain name.

With actual Tor support (hidden services, never exiting the tor network to resolve a domain or connect to it), a domain name and SSL cert are not needed.

2 Likes

Can this tag be built and pushed to Docker Hub so that we do not have to maintain our own fork to try it? Thanks.

https://hub.docker.com/r/electriccoinco/zcashd/tags

2 Likes

For users who want to try a different onramp method, see ZKP2P. You can buy any token on Base (e.g. USDC) and then use an atomic swap protocol to move the funds over to Zcash. It supports 18 different fiat onramps.

Tl;dr - you use an existing fiat service to onramp into a cryptocurrency wallet. No additional KYC needed for centralized exchange.

DEXs and atomic swap protocols are great, but do not directly solve the fiat onramp problem.

3 Likes

We are evaluating whether or not to enable onion address support in Arti, which is currently documented as “not yet as secure as C-Tor and shouldn’t be used for security-sensitive purposes”.

But if all you need is NAT traversal, a simpler and more efficient option that works with any existing wallet is Tailscale. I finally hit “Publish” on a small blog post describing this approach:

6 Likes

Arti’s README likely needs to be updated. The ways in which it’s not as secure as C Tor are related to Vanguards, PoW DDOS resistance, and, generally, features focused on hiding hidden services’ server locations IIRC but I might be wrong about that. If your threat model does not include trying to hide your light wallet server’s location, I do not think those concerns apply. @bdavila is this accurate, can the README be updated? (thanks!)

Love Tailscale! It’s a great option, though I do look forward to users not needing an MITM to traverse NAT.

(leaving the related Github issue here for further discussion: Integrate Tor support into Zashi by using Arti · Issue #70 · Electric-Coin-Company/zashi · GitHub )

1 Like

We typically don’t publish release candidates (RCs) to Docker Hub or APT. Looking through the release history, there has only been a single RC (v5.3.0-rc1) ever published on Docker Hub.

The final v6.2.0 release is expected later this week, assuming all RC testing goes well. Once the release tag is pushed to the repository, we proceed with publishing the Gitian signatures, signed binaries (.tar.gz), the APT packages, and the Docker image.

I don’t see a strong reason to maintain a fork just for this. RCs are usually available for a very short period and are primarily intended for internal testing. Moreover, this release is just a maintenance update, especially considering that the current version (v6.1.0) is about to reach its end-of-support (EOS) stage and the project is being deprecated.

While the Dockerfile (zcash/contrib/docker/Dockerfile at master · zcash/zcash · GitHub) depends on the APT package, if you’re set on building your own image based on the RC, you’d need to either modify the logic to compile from source directly, or generate the .deb packages yourself using the Debian packaging scripts (zcash/contrib/debian at master · zcash/zcash · GitHub).

Another workaround—if you really want to deploy the RC version, though I wouldn’t recommend it—is to compile the RC from source, then take the latest stable Docker image and manually replace the binaries located in bin/zcash-*.

1 Like

Yes, this is what we are doing to confirm that our Helm charts work with the new required config line.

Also working towards a live “nightly.unsafe.zec.rocks” endpoint of zaino+zebra, but for zcashd it matters less and less. Thanks for the response.