Absolute privacy.
Absolutely Bitcoin.
Open your wallet. Scan your UTXOs. Instantly see the KYC information associated with each one, without revealing anything about yourself to anyone.
↓
Privacy in Bitcoin is eroding. Every time you receive coins from an exchange, a peer, or a merchant, invisible metadata follows. KYC tags, chain analysis labels, risk scores, all silently associated with your UTXOs. Most wallet users have no idea what information is already attached to the coins they hold. And by the time they find out, it is too late.
BTC Medusa was built to change that. The idea is simple. Open your Bitcoin wallet, tap scan and instantly see the KYC provenance of every UTXO you own. Which exchange touched it. Has it been flagged? The goal is to make privacy tangible, to give every Bitcoiner the awareness and tools they need to start making informed decisions about how they hold, spend, and protect their coins.
But making something this simple required a tremendous amount of cryptographic innovation. Normally, letting a service scan your UTXOs is the opposite of privacy. It is something you would never do, especially if you run your own node and value your sovereignty. A naive implementation would hand your entire financial history to a third party on a silver platter.
This is precisely why we designed the system the way we did. Every layer of BTC Medusa was engineered under the assumption that even we, the server operator, are adversarial. The cryptography ensures that we cannot learn which UTXOs you are querying, which tokens you are spending, how many you have left, or who you are. You get full visibility into your own coins while giving up absolutely nothing.
BTC Medusa does not ask you to trust its server. The entire protocol is designed under the strongest possible adversarial assumption: a fully malicious server operator. We know our server has full control of its software, database, and network stack. It can observe every API request, including timing, payloads, and (absent transport privacy) IP addresses. Given all this, we assume you believe that we will try and modify responses, inject fake data, and collude with exchanges, chain analysis firms, or law enforcement. Because of this, we take all the necessary steps to make sure we can't do any of this.
We also consider external observers: network-level adversaries such as ISPs and state actors who can monitor traffic between your wallet and our server, and on-chain analysts who can see payment transactions on the blockchain.
Under this maximal threat model, any adversary learns nothing beyond three things: that a valid token spend occurred, the public nullifier (which is cryptographically unlinkable to any pack or user), and the global current-month parameter. They cannot see your UTXOs, cannot see your queries, cannot link your spends, and cannot identify you.
BTC Medusa operates on a simple paid subscription model, and it is deliberately designed to give back. If your monthly subscription costs $10, then $2 of that goes directly to the open-source wallet developer whose wallet you are using. This is not a marketing gesture; it is a structural funding mechanism for open-source Bitcoin wallets that have historically struggled to sustain development.
Your monthly subscription gives you 50 tokens, each of which lets you privately scan one UTXO. These tokens are derived cryptographically upon your initial signup, blind-signed by our server using a Verifiable Oblivious Pseudorandom Function, and stored locally in your wallet. The server never learns which tokens you hold, how many you have left, or when you use them.
The payment flow itself is built for privacy from the ground up. When you subscribe, you pay to a BIP-352 silent payment address. Each payment generates a unique, unlinkable on-chain output. An observer looking at the blockchain cannot tell that two different subscribers paid the same service. Once your payment confirms, your wallet privately requests a fresh pack of 50 blind-signed tokens from the server.
We chose silent payments because the address is just a single static string that can be hard-coded into our software. Your wallet could also have its own silent payment address that gets paid to in the same transparent manner. However, since silent payment implementation is still very new and is currently not supported by most hardware wallets, we implemented a novel workaround: we essentially open a hot wallet whose seed is derived from your XPub and other information, allowing us to still receive payments to our silent payment address with any currently available hardware wallet. Once native silent payment support becomes available in hardware wallets, we will be the first to implement it.
Authentication during issuance is handled through the public key used to sign the UTXO you sent us. You sign, we verify, and the issuance proceeds. No accounts, no emails, no identity. Just a cryptographic handshake between your wallet and our server.
Not everyone pays with on-chain Bitcoin. If you subscribe through a fiat payment method, a small measure of privacy is given up: we know who you are and that you are interested in our product. But that is where our knowledge ends. We have no way of knowing whether you ever actually use one of the tokens you purchased to query a UTXO, and of course, we have no idea what that query even is. The entire token-spending protocol is cryptographically decoupled from the payment step. Your identity at checkout tells us nothing about your activity after checkout. The privacy level remains at its highest where it matters most: at the point of use.
Lightning payments are coming soon, which will offer an additional layer of payment privacy for those who want it.
All communication between your wallet and BTC Medusa happens over Tor by default. Our server is hosted as a native .onion hidden service, meaning traffic never exits the Tor network. There is no exit node involved. Your wallet embeds an Arti Tor client directly into its native library: no external software to install, no SOCKS proxy to configure. You toggle a checkbox and the wallet handles everything.
With Tor, both sides achieve mutual anonymity: your wallet does not know the server's real IP, and the server does not know yours. The connection is encrypted end-to-end by the Tor protocol itself, so no TLS certificate authority is needed, which eliminates the CA trust chain as an attack surface entirely. This is dramatically more secure than a clearnet HTTPS connection where your IP address is logged with every request.
As a fallback for environments where Tor is blocked (corporate networks, restrictive jurisdictions), BTC Medusa supports Oblivious HTTP (OHTTP, RFC 9458) as a fallback transport layer. With OHTTP, a relay sits between your wallet and our server: the relay sees your IP but cannot read the request content, and the server sees the request content but not your IP. The relay URL is fully configurable so you can point to a third-party relay you trust. The trust assumption is explicit and transparent, and Tor remains the default.
After stressing how you can privately obtain a pack of tokens (where we have no idea who you are), the natural question is: how can you privately spend those tokens? Every time you spend a token to query a UTXO, we must have no visibility into who is spending the token, what token is being spent, or what the query is asking.
This is where the double-blinded query becomes the heart of the protocol. You want to ask a simple question: "What is the KYC information for this address?" But you do not want anyone, including us, to see what you are asking. So you blind the query before sending it. You take your input (the transaction outpoint you are interested in), multiply it by a secret random value only your wallet knows, and send us the result. What we receive is a mathematically scrambled point that looks like random noise.
We then apply our server's secret key to your blinded query and return the result. This is the key insight: we are able to give you a blinded answer to your blinded query without ever knowing what the original query was. Your wallet then divides out its secret blinding factor, and what remains is the decryption key you need, derived from our server's private key applied to your original input, yet obtained without our server ever seeing that input. This is the essence of what a double-blinded query is.
The cryptographic primitive that makes this possible is called a Verifiable Oblivious Pseudorandom Function (VOPRF). The "oblivious" part means the server evaluates the function on your input without learning the input. The "verifiable" part means your wallet can cryptographically verify that the server actually applied its real secret key and did not return garbage or a wrong answer. This verifiability is critical: it prevents a malicious server from silently returning incorrect data to targeted users, which would be an invisible form of censorship.
The server proves correctness through a DLEQ (Discrete Log Equality) proof, a Chaum-Pedersen proof that demonstrates the same secret key was applied to your blinded point as the one that corresponds to the server's published public key. Your wallet verifies this proof locally before trusting any result.
A privacy protocol is only as strong as its weakest link. BTC Medusa systematically addresses every attack vector, from token forgery to timing correlation, through a set of interlocking cryptographic constraints. Each property exists because removing it opens a concrete, exploitable attack. There is no redundancy; every component is load-bearing.
All issued Pedersen commitments are published on a public, append-only sparse Merkle tree called the bulletin board. When your wallet generates a zero-knowledge proof to spend a token, it proves membership in this tree without revealing which leaf it belongs to. The Merkle authentication path is a private witness, so the server never sees it. With N active packs on the board, each spend is 1-in-N anonymous. With a thousand active subscribers, the server cannot distinguish your spend from any of the other 999.
Every token produces a unique, deterministic nullifier: Poseidon(r, pack_id, token_index). The server records nullifiers to prevent double-spending, but it cannot determine which pack a nullifier came from. Different tokens from the same pack produce statistically independent nullifiers, so the server cannot tell if two spends originated from the same subscription. The blinding factor r and the Poseidon preimage resistance ensure the nullifier is opaque.
A malicious server might try to correlate when a pack was issued with when tokens are spent. If you issue a pack at 2:32 PM and spend a token at 2:33 PM, a naive system would let the server guess it is the same user. BTC Medusa defeats this through a growing anonymity set and transport privacy. With hundreds of active packs, any given minute likely contains multiple issuances and spends from different users. Tor transport eliminates IP-based correlation entirely because the server sees only a Tor circuit ID that changes with each connection. Even with timing, the server has at best a probabilistic guess that degrades rapidly as the user base grows.
Subscription payments use BIP-352 silent payments. Each payment generates a unique, unlinkable on-chain output. An on-chain observer cannot tell that two payments went to the same service. The server can detect its own incoming payments using its scan key, but it cannot link a payment to subsequent API usage because issuance happens over a different Tor circuit, the pack's blinding factor is generated locally, and the Pedersen commitment published to the board is perfectly hiding.
At the core of the token economy is the Pedersen commitment: C = r · G_PED + q · H_PED, where r is a random blinding factor known only to your wallet and q is your token quota (pack size). This commitment is published on the bulletin board and is what ties your tokens to the global state.
The Pedersen commitment is perfectly hiding: even an adversary with unlimited computational power cannot determine your quota q from the commitment C alone. It is also computationally binding: finding a different (r', q') pair that produces the same commitment requires solving the discrete logarithm between two Nothing-Up-My-Sleeve (NUMS) generators, which is infeasible. The generators G_PED and H_PED are derived through hash-to-curve with fixed domain separation tags, ensuring nobody, including us, knows the discrete log relationship between them.
Inside the zero-knowledge circuit, the commitment is re-derived from the private witnesses (r, q) and checked against the board leaf. This prevents a malicious wallet from hijacking another user's commitment. You must know the blinding factor r that was used when the commitment was originally published, and only the legitimate owner ever had it.
The BTC Medusa zero-knowledge circuit (Groth16 on BN254) enforces exactly eight constraints, totaling approximately 18,000 to 20,000 R1CS constraints. Each one exists because removing it creates a specific, exploitable vulnerability. Together they prove, in zero knowledge, that you hold a legitimate, unexpired, server-signed token from a committed pack on the bulletin board, and that your OPRF query point derives from that token.
| # | Constraint | Attack if Removed | Severity |
|---|---|---|---|
| 1 | Pedersen Commitment Derivation | Hijack another user's board entry and drain their tokens | CRITICAL |
| 2 | Base-Point Derivation | Inject a known-DL point, forge signatures, fabricate unlimited tokens | CRITICAL |
| 3 | Board Membership (Merkle) | Spend from phantom packs that were never issued or paid for | CRITICAL |
| 4 | Range Check | Claim astronomical quota via finite field overflow | HIGH |
| 5 | Nullifier Binding | Double-spend the same token unlimited times | CRITICAL |
| 6 | DLEQ Signature Verification | Fabricate tokens without server interaction, no payment needed | CRITICAL |
| 7 | Alpha Binding | Prove with one token but query unrelated data (credential laundering) | HIGH |
| 8 | Expiration Check | Use expired tokens forever, gaining lifetime access from one payment | HIGH |
This is the most expensive constraint at approximately 6,000 R1CS constraints, and it is the most important. It verifies, inside the zero-knowledge circuit, that the server's blind signature on your token is genuine. Without it, a malicious wallet could set the signature to any arbitrary point, fabricating unlimited tokens without ever contacting the server or paying for a subscription.
The circuit recomputes the Fiat-Shamir challenge using Poseidon (not SHA-256, which would cost 25,000 additional constraints) and verifies it against the server's hardcoded public key. To forge a valid proof, an attacker would need to either extract the server's secret key (break discrete log on BabyJubJub) or find a Poseidon collision (break 128-bit security). Neither is feasible.
The alpha binding constraint enforces that the OPRF query point submitted with your proof was actually derived from the token being spent: alpha = rho · P_i. Without this, a wallet could generate a valid proof using one token but query for a completely different UTXO, effectively decoupling authentication from the actual lookup. This would allow credential laundering: prove with token A, but query for someone else's data using token B's slot. The constraint eliminates this by binding the authentication point to the exact token in the proof.
The expiration check proves that expiration_month >= current_month by decomposing the difference into 254 bits. If the token is expired, the subtraction wraps to a massive field element that cannot pass the bit decomposition, so the proof fails. Critically, the expiration month is a private witness: the server never learns when your pack expires. It only learns that the pack is currently valid. For yearly subscriptions, 12 separate packs are issued at purchase time with staggered expiration months. One payment interaction, no monthly check-in. The tokens are use it or lose it. Based on user feedback and need, more token options will be available in the future.
After everything (the zero-knowledge proofs, the OPRF blinding, the Tor transport, the Pedersen commitments, the nullifier derivation), this is what the server's view reduces to: a stream of anonymous tuples arriving over Tor circuits it cannot trace. It cannot link successive spends to the same user, cannot determine which pack was spent, cannot see what UTXO was queried, and cannot learn your IP address. The only information it gains is that a valid, non-expired token was consumed, which is exactly what it needs to maintain the token economy, and nothing more.
| Information | Leaked? | Why |
|---|---|---|
| Which UTXO you're querying | NO | OPRF blinding hides the input |
| Which board leaf is yours | NO | Merkle path is a private witness |
| Your blinding factor r | NO | Private witness, never transmitted |
| Your pack ID | NO | Private witness, part of leaf hash |
| Which token index you spent | NO | Private witness, feeds nullifier |
| When your pack expires | NO | Expiration is a private witness |
| Your IP address | NO | Tor hidden service / OHTTP relay |
| A valid spend occurred | YES | By design; maintains token economy |
| The nullifier value | YES | Public input, but unlinkable to any user |
| The current month | YES | Global parameter, same for everyone |
Don't trust us. Verify.
Every cryptographic primitive, every circuit constraint, every protocol flow is open source and fully auditable. The code is the proof.
Get Started
It is our hope that BTC Medusa will be natively integrated into all major Bitcoin wallets. For our initial launch, we are offering a standalone download that implements our software as a plug-in to Sparrow Wallet on the desktop.