tl;dr: If you have a zcashd instance restored from a Zec.rocks snapshot, confirm that the first word of your server’s seed phrase is not “odor”. If it is, urgently move all ZEC and rotate your wallet.dat to new keys immediately. To further validate key reuse, ensure that your zcashd wallet’s UFVK does not match the string below.
Two projects are currently known to have accidentally used this shared wallet: Zec.rocks Node Rewards, and Zcash.me.
Context
In 2024 Zec.rocks began publishing snapshots of zcashd’s data directories in order to speed up its multi-week sync process while quickly scaling Zcash servers within our infrastructure.
Shortly thereafter, we included these snapshots in our public Kubernetes Helm charts behind an optional flag, to speed up the initial blockchain sync for anyone that needs to get zcashd running quickly at scale.
All of our zcashd infrastructure-as-code was published for a singular use case: hosting light wallet servers for mobile wallet apps to connect to, not for holding a wallet balance on any zcashd server itself.
Inadvertently, a wallet.dat file slipped into these snapshots which was unused at the time. As an unfortunate result, any zcashd using this wallet.dat file in the future as an actual wallet would share the same keys / seed phrase.
Two years ago I was a new contributor to Zcash and unaware that zcashd could be started successfully with its wallet disabled. This was my oversight.
Security Disclosure
The keys and seed phrase will be identical between any users of Zec.rocks zcashd snapshots from 2024 that did not delete the wallet.dat before enabling zcashd’s wallet functionality. If you have assets stored in addresses derived from the wallet.dat files in those snapshots, anyone can transfer them.
Signatures from any keys generated by this wallet should not be trusted.
Any users of services that used this wallet should know that all transactions in and out of this wallet, and all associated memos, are publicly-discoverable. From our analysis of the memo content, the other project was thankfully only using this wallet for on-chain 2FA and account verification.
Identifiers
- zcash-stack Kubernetes Helm deployments of zcashd, < v0.0.22
- Any zcashd restored from zcashd-2024-03-31.tar
- sha256:64962348a2ba7254e587aafe57303f68d7352a516ba9c89dd5294fe2b2e8cb7a
- UFVK of the leaked seed in the wallet.dat, the seed starts with “odor”
- uview1fl9k4zu4p52u7mzkg3d93yyfh6xhqegcwh7nqadkl49d3gm47tl2cw50lguaveyg0yamm3lpymr4zfv56y4lqsfyacw49r2fz936z34pcy0wyt0vmdhp287gwh3vw4s3dcvd54wkju90548knm0hg6npsq8yasky705hxskp8c3h3s24h4dtwmxwmyt3ccf26qhcj3vwmglj652z7ug3py8k0rkl6x3wxrwjgs2ztu25280rr8jc47fc9ercw9azjud7m0cmahmf32tea8kdnyn0msgtq8lxneyucf5ht6dg779uk6mmaaweutx4h450slfffgjlf02p0k5kjydzgze0xhrdtv3kz6kncv9sfrn3rx7pmhk5yd22v8zxuz2wdk07q3c90yem3
If you restored zcashd from one of the above files, any Zcash addresses that your zcashd server generates can be instantly drained by anyone and you should rotate your wallet immediately.
Remediation
- Move all ZEC immediately into a fresh seed generated by a reputable wallet.
- Reinstall and sync zcashd from scratch into an empty data directory.
When validating any signature generated by a Zcash identifier/address, ensure that it is not part of the set of addresses that can be generated by the UFVK above.
The zcash-stack Helm charts are updated and no longer reference the zcashd snapshots mentioned above.
Zebra snapshots were never affected as it does not have wallet functionality.
Timeline of Compromise
September 15th, 2025 - The Zec.rocks Node Workshop began using keys generated by the unintentionally-disclosed wallet.dat as a hot wallet to reward participants. (the “Zec.rocks Reward Wallet”). The UFVK of this wallet was published for full transparency to allow anyone to view our payouts. Regrettably this wallet was generated by a zcashd that was restored from of the snapshots mentioned above.
December 3rd, 2025 - Hundreds of unexpected transactions began arriving into the Zec.rocks Reward Wallet. The memos indicated that our intentionally-disclosed UFVK may have been used by another project. Somewhat annoying, but we thought it was perhaps to be expected with a public UFVK. Tiny transfers also began moving out of our wallet, never stealing any of our funding, but we did not notice these outbounds due to zcashd’s RPC responses not being as accurate as expected.
January 15th, 2026 - We noticed that our UI for zcashd’s RPC was not showing our outbound transactions and began building a custom wallet for sendmany payouts.
January 18th, 2026 - We identified which project was causing strange deposits to arrive into our addresses, Zcash.me, and begin attempting to contact them, but admittedly could have been more aggressive on this front.
February 15th, 2026 - Using our new custom wallet, before our scheduled node operator reward payout, we noticed that funds had previously moved OUT of our seed, indicating a seed compromise rather than merely a shared UFVK. We were able to identify which project was sharing our keys, and attempted to make contact. We paused operator payouts and promptly moved our funding out of the wallet.
February 25th, 2026 - Contact was established with the other team and we coordinated to discover the issue: shared use of a zcashd snapshot which had a wallet.dat in it.
Outcome
There was no foul play at any point that we inadvertently shared wallets with Zcash.me. They have rotated to another wallet. All of our node reward funding is safe in new keys.
I apologize for this oversight that was entirely mine, back in 2024 I never expected anyone to actually use our snapshots for wallet functionality.
Safeguards are in place to ensure that no wallet.dat leaks into any future snapshots. But more importantly, zcashd is now completely removed from every Zcash project that I am working on.
Screenshot of the Shared Wallet Activity
