A soundness flaw in Zcash's Orchard shielded pool could have let someone counterfeit unlimited ZEC, undetected. It threatened the money supply, not anyone's privacy. BTC Medusa uses ZK proofs too, but only to run our billing meter. Your privacy is guarded by different math entirely, and a broken proof can't touch it.
What actually happened
Days ago, the Zcash project disclosed and patched a soundness vulnerability in the Orchard shielded pool, the cryptographic machinery behind its private transactions. The flaw had reportedly gone unnoticed for close to four years.
A "soundness" bug in a zero-knowledge system is about as serious as it gets. A sound proof system guarantees that a valid proof can only be produced for a true statement. When soundness breaks, someone can produce a convincing proof for something false, and every honest node will accept it. In Orchard's case, the false statement that mattered was roughly "this shielded transaction is balanced," the rule that stops coins from being conjured out of nothing.
In plain terms: an attacker who found this before the maintainers did could have minted counterfeit ZEC out of thin air, and because the pool is shielded, no one would have been able to see it happening on-chain. The response was an emergency hard fork to close the hole.
The bug put the money supply at risk. It did not leak a single user's privacy.
That distinction is the whole point of this post, so hold onto it.
"You use ZK proofs too. Aren't you exposed to the same thing?"
It's the first question a careful Bitcoiner should ask, and we'd rather answer it head-on than hope nobody notices. Yes, BTC Medusa uses zero-knowledge proofs. No, a soundness bug like Orchard's could not deanonymize you or expose your wallet. To see why, you have to look at what each piece of cryptography is actually responsible for.
What guards your privacy: the VOPRF
When you scan a coin, your wallet doesn't send us the coin. It first scrambles it with a secret random value that never leaves your device, producing something that looks like pure noise: α = k · H(input). We apply our key to that noise and send it back. Your wallet removes the scramble and reads the result. We never see the question or the answer.
This is a Verifiable Oblivious Pseudorandom Function, and it rests on plain, decades-old elliptic-curve math, the same family of assumptions securing Bitcoin keys themselves. There is no circuit to get subtly wrong. A completely broken proof system, anywhere in the world, could not reverse that blinding. On top of it, Tor hides your network identity on a separate layer.
The line that matters
Your privacy is protected by k · H(x) being irreversible to us, not by any proof being correct. Break every proof in the system and we still cannot tell which coin you scanned, what the result was, or who you are.
What the ZK proof does: it runs the meter
So where do our zero-knowledge proofs live? In billing. They do one mundane job: prove that a query was paid for and hasn't already been spent, so customers can't cheat the meter or replay a token they've already used. It's an accounting and anti-fraud tool, nothing more.
Now play out the worst case. Suppose our proof system had an Orchard-class soundness bug. What could an attacker do? At most, sneak some scans past the paywall without paying, the same class of failure Zcash just hard-forked to fix. That's a revenue problem for us. It is not, and cannot become, a privacy problem for you, because the proofs were never standing between an attacker and your data in the first place.
Zcash put zero-knowledge proofs in charge of money. We put them in charge of billing.
Why we designed it this way on purpose
This separation isn't luck. It's the core design decision behind BTC Medusa. We assume our own server is malicious, that we are actively trying to deanonymize our users, and we build so that even under that assumption there is nothing in our logs worth stealing. Privacy comes from information never reaching us, not from a promise that some component behaves.
The Orchard incident is a useful, if uncomfortable, reminder of why that matters:
- Complex cryptography hides complex bugs. A flaw can sit undiscovered for years. So the safe assumption is that any single component might fail, and nothing critical should depend on just one.
- What you put a proof in charge of is a design choice. Zcash chose to make ZK proofs load-bearing for the money supply. We chose to keep them out of the privacy path entirely.
- The code is the proof, not our word. You don't have to trust this explanation. The blinding, the protocol, and the billing logic are all open and auditable.
None of this is a victory lap at Zcash's expense. Shipping a fix for a four-year-old soundness flaw, transparently and fast, is exactly what a serious project should do, and the people who found and patched it deserve credit. The lesson for the rest of us isn't "ZK proofs are bad." It's "be precise about what your proofs are responsible for."
See exactly why we can't see you.
Don't take our word for it. Read the protocol, the threat model, and the cryptographic spec, then download and run it yourself.