A Bitcoin user receives payment, sends a portion to an exchange, and pays a service provider from the remainder. Three separate transactions on a public ledger, each one potentially linkable to the user’s identity if sufficient time, wallet behavior, and address reuse combine to inform a chain analyst. The question is not whether this is possible—blockchain analysis firms prove every day that it is—but whether a privacy wallet can make the linkage meaningless. Wasabi Wallet’s privacy score interface claims to quantify how resistant a transaction has become to surveillance, but the number displayed depends entirely on what the score actually measures and whether that measurement reflects the real exposure.
Most Bitcoin users do not understand their own privacy exposure because blockchain transparency and address reuse are presented as normal. CoinJoin technology—a method of combining multiple transactions into a single obfuscated output—is often described as a solution without explaining what problem it solves and when the solution remains incomplete. A transaction mixed through Wasabi Wallet may receive a high privacy score, yet still be correlated to a user through timing, change address behavior, or information available to a counterparty outside the blockchain. Understanding the score therefore requires understanding not just the algorithm, but the constraints that no algorithm can remove.
How Wasabi Wallet calculates privacy scores
The privacy score in Wasabi Wallet is built on a discrete measurement: the number of theoretically indistinguishable outputs that could be the true destination of a transaction. When a user participates in a CoinJoin round, their bitcoin is combined with inputs from other participants, producing multiple outputs of equal or similar value. From the perspective of an external observer, each output becomes a candidate for where the user’s funds went. The privacy score is a logarithmic function of this count—higher numbers mean exponentially more plausible alternatives.
The calculation follows a simple principle: if 100 participants create 100 outputs in one mixed transaction, each output has a 1-in-100 chance of being the true destination from a statistical standpoint. Wasabi’s algorithm assigns a score proportional to the logarithm base 2 of this denominator. A score of 1 means roughly 2 plausible destinations (minimal privacy), while a score of 8 means roughly 256 plausible alternatives. The score is deterministic—given the same transaction structure, the same address will always receive the same score—and it is transparent in the sense that users can see which transactions contributed to the final score.
However, this calculation rests on a critical assumption: that all outputs in a CoinJoin round are genuinely indistinguishable to the analyst. That assumption fails in several real-world scenarios. Output values can be unequal if participants contribute different amounts or if fees create fractional differences. Timing patterns—when outputs move, to which addresses, and at what intervals—can reveal intent even if the immediate source is obscured. A user’s change address, if reused or identified through external observation, can directly link a transaction back to their wallet.
The wasabi wallet implementation also distinguishes between «anonymity set» and «privacy score,» though they measure related concepts. The anonymity set is the raw count of plausible outputs. The privacy score normalizes this count into a friendlier integer for non-technical users. A score of 5 typically indicates 32 potential destinations; a score of 10 suggests over 1000. But because the score depends on transaction structure rather than the blockchain’s future or the analyst’s real capabilities, a high score should never be read as immunity from investigation.
What the privacy score does and does not measure
The score measures one specific dimension of privacy: the statistical difficulty of directly linking a transaction output to a user’s input in the moment of mixing. It does not measure whether the wallet itself has been compromised, whether the user’s device contains malware, whether the recovery phrase has been exposed, or whether the user has connected their wallet to a service that already knows their identity. A user with a perfect privacy score who then sends mixed bitcoin to a named exchange account has nullified the privacy benefit through their own behavior.
The score also does not account for correlated payments. If a user receives 5 bitcoin to their non-mixed address, immediately mixes it to a score of 8, and then pays an invoice for exactly 4.99 bitcoin, the timing and amount create a probabilistic link that can survive even high-anonymity mixing. Bitcoin’s transparent ledger means that flow analysis can trace value movement across addresses and transactions, regardless of mixing. The privacy score protects against one type of attack—direct input-output matching in a single transaction—while leaving many others intact.
Change address handling illustrates another limitation. When a user sends 10 bitcoin and the output includes 1 bitcoin in change, the CoinJoin round may obscure which output received the primary payment. But if the change address is subsequently exposed, reused, or linked to the user through external data, the entire transaction becomes traceable. Some wallets including Bitcoin privacy implementations attempt to manage this through change address rotation and strategic consolidation, yet the user remains responsible for understanding the consequence of each action.
The privacy score is also a snapshot. It reflects the transaction’s appearance at the time of mixing, not its vulnerability to future analysis. Suppose a user mixes 1 bitcoin in a round with 100 participants, achieving a score of 6.6. If the user later consolidates multiple mixed outputs into a single payment, the act of consolidation may reduce the effective privacy of all inputs, because the consolidation itself reveals that those outputs belong to the same wallet. Privacy, in this sense, is not a property of a single transaction but of a user’s entire behavioral pattern.
Privacy score thresholds and real-world surveillance resistance
Wasabi Wallet typically suggests a minimum privacy score of 5 for transactions intended to achieve meaningful privacy. A score of 5 means roughly 32 plausible destinations—difficult for a casual observer to distinguish but not insurmountable for a well-funded analyst with time-series data, side-channel information, or access to exchange deposit addresses. Scores above 8 are considered strong, while scores below 3 are barely better than unmixed transactions.
These thresholds should be understood as sliding scales of effort rather than binary privacy boundaries. An adversary with resources to run full nodes, monitor mempool activity, and correlate timing patterns with known addresses can attempt deanonymization even at score 10. Conversely, a user who fails to reuse addresses or expose personal information may maintain practical privacy even at score 4, because no analyst can effectively connect the transaction to their identity. The score is a necessary but insufficient condition for privacy.
The practical threshold also depends on the user’s threat model. A user concerned about accidental exposure to casual blockchain surveillance—a friend or competitor checking their balance—should aim for a score of 5 or higher. A user with a higher-stakes concern, such as resistance to determined investigation by an adversary with legal authority or sophisticated analysis tools, may need to combine a high privacy score with operational security measures: avoiding change address reuse, spacing transactions across days or weeks, and never consolidating outputs in ways that obviously belong to a single user.
Financial regulatory bodies such as FinCEN have increasingly focused on cryptocurrency transaction tracing, which means that privacy scores may become less relevant if centralized exchanges or regulated services are required to report incoming and outgoing addresses. In those scenarios, the anonymity set no longer matters because the counterparty already knows the user’s identity. This is why wallet choice alone cannot deliver privacy—the user’s interaction with regulated infrastructure, service providers, and counterparties determines how much the technical privacy measures actually help.
How transaction consolidation and change address behavior affect the score
A user who receives multiple payments to different addresses and then consolidates them into a single transaction for spending has made a critical privacy decision. Consolidation proves that all inputs belong to the same wallet, even if each input was initially mixed. CoinJoin technology cannot retroactively change this fact—the ledger shows what it shows. Wasabi Wallet attempts to mitigate this risk through change address rotation and suggestions about when to avoid consolidation, but the tool cannot override the consequences of the user’s choice.
Change address behavior is so important because the change output is the user’s own output in a transaction. If a user spends 10 bitcoin and receives 1 bitcoin back as change, that 1 bitcoin provably belongs to the same wallet as the original 10, regardless of mixing. Some analysis assumes that the largest output in a transaction is change (the «change heuristic»), though this fails when amounts are chosen to be equal or when the user structures the transaction differently. Even with careful change management, an extended sequence of transactions can reveal patterns through cluster analysis—a method that uses multiple transaction features to group addresses together.
Privacy in Bitcoin also depends on address reuse practices. A user who receives payments to the same address multiple times has essentially broadcast to everyone that those transactions are related. Wasabi Wallet encourages users to generate new addresses for each incoming payment, a basic but often-neglected practice. However, newly generated addresses can still be linked together if the user sends funds from one to another in a traceable pattern, or if external services provide information about the user’s identity (an exchange, payment processor, or shipping address tied to a pseudonym).
Advanced users have another tool: PayJoin transactions. In a PayJoin, both the sender and receiver contribute inputs to the transaction, making it harder for an analyst to determine which inputs belong to which party. This is fundamentally different from CoinJoin, which combines multiple independent users. A PayJoin can make consolidation of multiple addresses appear as a normal two-party transaction, though it requires cooperation from the receiving party and is not yet widely supported. For most users, the simpler rule applies: avoid consolidating mixed outputs unless necessary, and generate new change addresses to receive payments.
Limitations of open-source wallets and the role of code transparency
Wasabi Wallet’s open-source codebase is often cited as evidence of security and trustworthiness. The ability for anyone to audit the code is valuable, but it does not automatically mean the code is audited, nor that security flaws do not exist. GitHub repositories can host code that is transparent yet complicated, and transparency alone does not reveal whether a closed-source coordinator (the service that orchestrates CoinJoin rounds) is honestly implementing the protocol it claims to follow.
The CoinJoin coordinator is a critical dependency. Wasabi uses a centralized coordinator to gather inputs, calculate outputs, and produce the final transaction. Even if the wallet software is audited and sound, a compromised or malicious coordinator could potentially deanonymize users by tracking which inputs belong to which participants. Wasabi’s current model includes Blind Signatures, a cryptographic method intended to prevent the coordinator from linking inputs to outputs. However, the coordinator remains a single point of failure in the mixing process and a potential target for legal demands to log transaction data.
Users who value absolute privacy may prefer decentralized CoinJoin implementations, though these remain in early stages and often lack the user interface polish of centralized alternatives. The trade-off between convenience and the number of trusted intermediaries is not always obvious. A user-friendly wallet that requires trusting a coordinator is more likely to be adopted and used correctly than a perfectly decentralized solution that requires technical expertise and has higher barriers to participation.
Security standards from NIST and frameworks from OWASP both emphasize that security depends on the complete system—the application, the device, the network, the user’s practices, and the external services involved. A privacy wallet is only one component. Device-level encryption, hardware wallet integration (Ledger, Trezor, Coldcard support), and a strong PIN or passphrase are all necessary controls. A user can undermine the privacy score by entering their recovery phrase into a phishing website, by using a device infected with keylogging malware, or by storing their backup in a cloud service accessible to the platform provider.
When privacy scores fail to predict real-world privacy
The most important limitation of any privacy score is that it cannot predict human behavior or external factors. A user with a transaction privacy score of 10 who then posts «just received my payment, now I’m sending it to Kraken» on social media has made the score irrelevant. An employed user who mixes bitcoin and then pays rent to a landlord they know has likely eliminated the privacy benefit, because the landlord can eventually correlate the payment timing and amount to the user’s Bitcoin transaction.
Similarly, privacy scores do not account for wallet compromise, backdoors in the operating system, or attacks on the hardware wallet supply chain. The Electronic Frontier Foundation has documented numerous examples of attackers targeting the key storage layer rather than the blockchain, because the blockchain is often the hardest part to break. A user’s private key—whether stored on a hardware device, in encrypted wallet software, or in memory—is more vulnerable than the transaction structure.
Statistical privacy also has an expiration date in practical terms. As more users adopt CoinJoin wallets, large CoinJoin rounds become more common, making the score less distinctive. Conversely, if adoption remains low, a user participating in small rounds might stand out precisely because few other users are mixing. An analyst can also observe the direction of value flow before and after mixing, potentially narrowing the true destination through economic logic rather than statistical calculation.
The regulatory environment adds another layer of risk that the privacy score cannot capture. If cryptocurrency regulators require exchanges and custodians to implement mandatory transaction tracking or if regulations require privacy wallet providers to report user activity, the technical privacy of individual transactions becomes less relevant than the institutional vulnerability of the service provider. Wasabi Wallet’s non-custodial design means the users hold their own keys, but the coordinator itself may face legal demands or regulatory pressure that affects service availability.
Best practices for interpreting and acting on your privacy score
A user checking their privacy score in Wasabi Wallet should interpret it as one data point, not as a complete privacy guarantee. A score above 5 indicates that a transaction has reasonable statistical protection against direct input-output analysis, assuming the user has not made other privacy mistakes. A score of 8 or higher suggests strong protection, though not immunity. A score below 3 should prompt the user to either mix again or reconsider whether they have achieved their privacy goal.
The score should inform decisions about what happens next. If a user has achieved a score of 8 but then immediately sends the mixed output to a known exchange account, they have gained nothing. Conversely, if the user keeps the mixed bitcoin in a hardware wallet and spends it carefully over weeks—generating new addresses, avoiding consolidation of multiple outputs, and not revealing personal information—then even a score of 5 can provide meaningful privacy in practical terms.
Users should also understand that the privacy score is specific to one transaction. Over time, a user who makes multiple transactions from the same wallet can be clustered together through address analysis, change address observation, and value flow patterns. The long-term privacy of a Bitcoin wallet depends on spending discipline, address rotation, and resistance to the temptation to consolidate funds for convenience. Tools like Wasabi Wallet make these practices easier, but they cannot eliminate the need for the user to think carefully about each transaction.
A final best practice is to distinguish between privacy at the transaction level and privacy as a lifestyle. Mixing bitcoin through CoinJoin is one tool. Avoiding repeated addresses, spacing transactions across time, not consolidating funds unnecessarily, using Tor or a VPN for wallet connections, and never linking pseudonymous bitcoin activity to personal information all matter equally. The privacy score quantifies one dimension of transaction obfuscation; it does not measure whether the user has constructed a coherent privacy practice that survives scrutiny.
Frequently asked questions
What does a privacy score of 8 in Wasabi Wallet actually mean?
A score of 8 means approximately 256 plausible outputs that could be the destination of your transaction, based on the CoinJoin round structure. This makes direct input-output matching statistically difficult, but does not protect against timing analysis, change address observation, or consolidation of your outputs later. The score measures transaction obfuscation, not complete immunity from investigation.
Can I use Wasabi Wallet and still lose privacy if I consolidate my mixed outputs?
Yes. Consolidating multiple CoinJoin outputs into a single transaction proves that all those outputs belong to the same wallet, even if each was initially mixed. This consolidation can undermine the privacy benefit of mixing. Wasabi Wallet warns against this practice, but the tool cannot prevent you from choosing to consolidate. The privacy score only reflects the mixing itself, not what you do with the mixed bitcoin afterward.
Is open-source code enough to trust a privacy wallet like Wasabi Wallet?
Open-source code is necessary but not sufficient. The code can be audited, but that does not mean it has been audited or that no vulnerabilities exist. The wasabi wallet coordinator, the devices and operating systems you use, your backup procedures, and your own behavior all matter. Even perfectly transparent code cannot protect you from phishing, malware, or sending mixed bitcoin directly to an exchange that already knows your identity.

