Unfortunately, decisions made by four of Bootstrap’s board members forced every person at ECC to exit the company, very quickly.
What you see on social media is speculation is the absence of full disclosure. It is not so simple.
I wish we hadn’t been forced to move so quickly. But we had no choice.
This is a serious matter. It is not a game. And as you see, the consequences, severe.
More information will be shared and decisions will need to be made.
For now we are regrouping, assessing things, supporting zcashd, supporting zashi users, and planning to release a new wallet based on the Zashi code base to allow users to migrate safely.
We do not currently have access to our systems but are able to fully support the Zcash protocol. We are supporting Zashi in Discord.
If you see issues or gaps that we need to address, please share them via DMs so that we can see them. Most of us are currently working from the same location and mobilizing as fast and as responsibly as we can.
Thank you for your support, patience, and encouragement. This has been difficult and it means a great deal.
It often happens that company boards/management are not prepared for explosive scaling. The rise in the price of ZEC has created new stressful conditions, and it is unfortunate that the board was not prepared for them. Conflicts are possible in such conditions. Since I like to dig into various corporate reports, I couldn’t help but notice that the last transparency report was six months ago. This is already a sufficient signal of internal disagreements.
It is evident that Bootstrap cannot violate 501c3 regulations and is not prepared to take on more funds than it could spend without generating a profit. However, it is also evident that Bootstrap was created to serve the mission of Zcash, as it is commonly referred to, and without this goal, the organization itself would be meaningless.
I wish you the best in finding a swift and effective way out of this situation. And I’m confident that ultimately you will be able to take advantage of this opportunity and bring the Zcash governance structure to greater stability and decentralization, as the community would like to see.
ECC also currently pays for the hosting of z.cash, although it had been planned in any case to transfer that domain to the community.
ECC. I do not know why those are down.
Str4d’s seeder is run by him personally and is unaffected.
The zcash org has been managed by the Zcash core developers on behalf of the Zcash community, and that is unchanged. The same applies to the zcash-hackworks org. Some repos under those orgs (mainly the less strongly depended on or infrequently modified ones) are primarily managed by individual developers.
Similarly, the zkcrypto org was always independent of ECC.
(This answer applies to Zcash-related credentials in general, not just the Zashi app.)
It has not previously been our practice, in general, to publish who holds particular credentials for GitHub, Google Play, Apple developer accounts, etc. Doing so would paint a target on specific developers’ backs, and I don’t believe it is necessary for decentralization or transparency to the Zcash community. The holders of those credentials are the same people who held them before, and I will say that I think we made correct and foresighted security decisions about how those credentials were set up.
The Zcash core developers. We are now all at the new company headed by Josh. Note that, as documented in the COPYING file, copyright in zcashd is held by “The Zcash developers” (i.e. the Zcash core developers and other contributors), and the Bitcoin developers for code that is a derived work of Bitcoin Core — not by ECC specifically. We have just published zcashd v6.11.0, which was necessary because the end-of-service date of zcashd v6.10.0 is January 21st.
For a security patch to zcashd, there would be no change.
For a security patch to Zashi, to avoid potential legal liability, we would have to ask the leadership of ECC for permission to make a release. Clearly it would be in the Zcash community’s interest for them to agree. My personal opinion is that it would be difficult for them to justify refusing to allow a release to fix a security bug.
Other changes to Zashi cannot, as far as I currently understand, occur unless and until there is an agreement with ECC.
How to support migration from Zashi to a new wallet without any loss of metadata is something that the developers at the new company have been discussing in detail over the past couple of days. It is complicated because of the way app data on mobile platforms is tied to particular apps, and also because of security deficiencies in how sharing between apps works on both iOS and Android, when there are potentially malicious apps on the device that could intercept a sharing action or read from the shared filesystem. There are a couple of possible approaches we’ve discussed that can do this securely. Ideally, to reduce complexity and improve UX of the migration process, we would be allowed to make a change to Zashi to support full export of all wallet metadata.
In my personal opinion, that is another change that would clearly be in the interests of the Zcash community. However, I’m not a lawyer and I’m not able to discuss any potential legal constraints.
@aaal
The distinction Daira @daira draws here is the entire lesson.
Protocol (zcashd) → Keys held by Builders. (Sovereign). Product (Zashi) → Keys held by Legal. (Permissioned).
One is an invariant; the other is a permission slip.
This structure preserves resilience where it matters most (the Core). However, a product layer where security patches require “leadership permission” introduces Administrative Latency that the market will eventually arbitrage.
The correct way to view this lesson is that wallets should never, ever become essential infrastructure. If you’re in a situation where people are arguing over who controls a wallet, you’ve already made a terrible mistake.
If the ecosystem holds its breath because one repository is locked, then we have inadvertently centralized the application layer.
You are absolutely right that a wallet should never be a choke point. The “terrible mistake” is structural: treating a single interface as if it were critical infrastructure.
The Protocol is the infrastructure. The Wallet is just a client.
The only robust solution is redundancy. When users have multiple sovereign alternatives, “who owns the keys” to one wallet becomes a localized failure, not an existential risk for the network.
Wallets are critical infrastructure; what this has made clear to me is that in addition to source code being available, data portability, backup and restore functionality need to be prioritized highly. There’s a social problem in that these kinds of features aren’t very sexy and in the happy path case might go almost entirely unused: they’re not features that draw in new users, but they can become critical functionality at a moment’s notice.
A week ago many people were opposed to data portability in Zashi due to its alleged privacy concerns.
I need to be able to export my UFVK to my accountant. I can currently only do that by entering my Zashi seed phrase in YWallet. Hopefully all of this whiplash will lead to less micromanagement of users’ rights to choose what to do with their own data.
@Matthewdgreen As we move into a tachyon-ian future the competing tensions placed on the user for storage that’s both available AND private become even tougher. Passkeys/WebAuthn don’t seem to help in this specific scenario as they are domain/app locked . Any thoughts?
Does the move to a for-profit company with the wallet being privacy focused put the developers of it at risk? One of the things I liked about ECC and the core team being under a non-profit was that it seemed to lessen the potential of liability ( I’m not a lawyer, so could be wrong ).
The pendulum has certainly swung the other way with regards to the current administration towards crypto in the US but that’s only guaranteed for as long as the election cycle lasts. I don’t want to see another Samurai happen to our core team members and I also don’t want governments to go after this new company as a roundabout way to hurt Zcash.
OTOH there are already several wallets out there like Unstoppable that support Shielded Zcash so it might not be as big of a deal as I’m imagining.
@emersonian Just FYI, the UFVK is available through Zashi’s ‘Advanced Settings’ > ‘Export Private Data’ option. The resulting .db file contains the UFVK, among other wallet data.
There was never an objection in principle (at least not from any of the Zcash core or Zashi developers, to my knowledge) to data portability in Zashi. There was a well-founded concern about problems with achieving that data portability on iOS and Android without introducing serious security vulnerabilities.
You can already do this with a Zashi wallet: “… → More → Advanced Settings → Export Private Data” and then query the SQLite database with SELECT ufvk FROM accounts.
I don’t know what other concerns have been made, but my own were that allowing UFVKs to be directly exported is a privacy risk because UFVKs are a permanent viewing capability; thus any export mechanism that exposes it needs to be restricted to the same degree as the seed phrase. That is the case for the mechanism above (“Export Private Data” is gated behind the same biometric auth as displaying the seed phrase).
I don’t even think that we had particular privacy concerns about viewing key export and import; my memory is that it’s been a requested feature for a long time, it was just not prioritized because of product concerns about how to explain the future to naive users. Zashi was initially conceived as a “consumer grade” wallet and viewing key import and export more of a power user feature. Personally, it’s absolutely a feature I want from my wallet, under an advanced settings screen or whatever.
Zashi with the pay out in other crypto, or receive payment in other crypto with near intents along with the most user friendly experience in crypto is what gave us our shot. It’s not coincidence that price rise followed these features.
Wallet isn’t critical for infrastructure, but it is for the shielded pool which is part of the infrastructure around privacy.
This is also why having multiple quality wallets matters: resilience.
If the ecosystem depends on a single wallet and that wallet has issues, technical, organizational, or otherwise, users are stuck. For most people, the wallet is the chain.
Multiple wallets with different teams, different codebases, different infrastructure = redundancy. If one goes down, users have alternatives.
If the Rust guts could be made into a Tauri harness, it’s possible that we could have a variety of great wallets fairly trivially. So … it probably makes sense to enable more custom wallets based on the rust crate guts.
It shouldn’t be nearly as hard to make a new wallet as it was in the past IMHO. If the native side was solid, an API/SDK could be exposed to build arbitrary frontends pretty easily.
Am I missing something or is the tauri-harness idea awesome? White-label reference implementation in the new wallet would be the move from where I’m sitting.
. Any thoughts?