The transparency of Bitcoin poses risks for businesses: competitors can track revenue, assess customer numbers, and identify supplier addresses. For instance, in May 2025, Arkham Intelligence revealed 87% of Strategy's reserves without the company's consent.
Along with the team from the Bitcoin mixer Mixer.Money, we explore what data leaks occur when accepting BTC payments, why having a unique address for each order isn't enough, and how to create a system that prevents competitors from reconstructing a company's financial picture.
What Clients and Competitors See
Once a business's Bitcoin addresses become known—through a KYC exchange, payment processor, or clustering—an observer gains access to total revenue, customer counts, average transaction sizes, counterparties, and activity patterns. They essentially have a complete financial profile of the company.
The scenario unfolds like this: a competitor sends a test payment to the store's address. If the address is static, all incoming transactions are immediately visible: the number of payments, amounts, and frequency. Essentially, this is a ready-made financial report without a single request.
The first step to protection is generating a separate address for each invoice. Payment processors like BTCPay Server do this automatically through xpub derivation.
The BIP32 standard defines hierarchical deterministic (HD) wallets. From a single master key, a tree of child keys is deterministically derived. An extended public key (xpub) can generate new addresses without access to private keys. BTCPay Server stores only the xpub and creates a new address for each invoice. Private keys remain offline—on a hardware wallet like Ledger, Trezor, or Coldcard.
In the blockchain, bc1q…aaa and bc1q…bbb appear independent, and without the master key, they cannot be linked. Clients do not see each other's payments, and competitors do not see the revenue.
However, isolated addresses only create an illusion of privacy. The problem arises at the next step.
The Consolidation Problem
Eventually, a business needs to spend or consolidate its revenue. At this point, it creates a transaction with multiple inputs, and confidentiality collapses.
Example. Client A paid to bc1q…aaa, client B to bc1q…bbb, and client C to bc1q…ccc. Three independent UTXOs on three unrelated addresses. The business creates a consolidating transaction: three inputs, one output to bc1q…ddd. Now all three addresses are linked in the blockchain.
This method is known as the heuristic of common ownership of inputs: if multiple addresses are used as inputs in a single transaction, they all belong to one owner—spending requires the private key for each. This principle was described by Satoshi Nakamoto in the Bitcoin white paper (section 10).
“Poorly planned UTXO consolidation can negate all efforts to ensure privacy and reveal the entire balance of a company on the blockchain,” note the experts at Mixer.Money.
Consolidation is driven by transaction fee economics. The cost of a Bitcoin transaction depends not on the amount but on the size in vbytes. Each additional input increases the size.
The challenge is compounded by the fact that commercial analytics services are quite accurate. According to research from Delft University of Technology, clustering algorithms from Chainalysis correctly group up to 95% of addresses associated with specific services.
Protection Strategies
While it’s impossible to completely eliminate address linking in on-chain transactions, it is feasible to reduce data exposure.
Coin control involves manually selecting UTXOs when creating a transaction. The idea is to combine only UTXOs from a single source, limiting cross-linking. This tool is supported by Sparrow Wallet, Trezor Suite, and Ledger Wallet. This method requires discipline—each UTXO must be labeled upon receipt.
Lightning Network allows off-chain payments and does not create a separate UTXO for each client. The consolidation problem for payment flows disappears. However, the protocol has not yet gained widespread adoption and requires additional technical knowledge—opening and closing channels. Additionally, Lightning is not suitable for large sums.
Each of these solutions addresses part of the problem: Lightning handles micropayments, while coin control reduces cross-linking. For on-chain revenue that has already accumulated across different addresses, a tool is needed to sever the connection between inputs and outputs.
Mixing Revenue
CoinJoin is a protocol where multiple users combine inputs into a single transaction with multiple outputs. The coordinator cannot steal funds or link inputs to outputs.
This method has a weak point: CoinJoin transactions are easily identifiable on-chain. AML services automatically increase the risk score of such assets, and exchanges often block funds after mixing.
Mixers like Mixer.Money operate differently: users send BTC to the service and receive different coins back. In the “Full Anonymity” mode (4-5% fee, processing up to 10 hours), liquidity comes from cryptocurrency exchanges: clients receive Bitcoin that has recently been withdrawn from trading platforms, with a different history.
In “Full Anonymity” mode, the service operates as follows:
- The company’s Bitcoins go to a premixer and are split into random parts.
- The coins are sent to investors—independent traders who trade on major international exchanges. The platform utilizes funds from over 100 investors across various platforms worldwide.
- The business receives clean Bitcoins from withdrawals from other exchanges to two new addresses.
For on-chain analytics, such a transaction appears as a regular withdrawal from an exchange to a personal wallet. The fact of mixing is not recorded. The service does not require registration and supports access via Tor. There is a free test—when sending 0.001 BTC, the client receives it back without a fee.
“Even if a competitor knows that a company accepts Bitcoin, they won't be able to determine the revenue. Coins that have gone through the 'Full Anonymity' mode have exchange histories and are not linked to each other or the store's addresses,” explain the team at Mixer.Money.
After mixing, it is crucial not to combine the received UTXOs with non-anonymized coins, or else the connection will be restored. ForkLog has discussed how to maintain privacy after mixing in a separate article.
Closed Cash Register
A combination of tools addresses the main vectors of data leakage.
BTCPay Server generates a unique address for each order. A competitor sending a test payment sees only their transaction.
Lightning Network is for micropayments. The network does not create separate UTXOs and does not require consolidation. For businesses with frequent small payments (like coffee shops or online stores), this is the primary channel.
Coin control with labeling is for on-chain payments. Each UTXO is labeled upon receipt: “client A, order 1234.” When spending, only UTXOs from a single source are combined.
Mixing through Mixer.Money is for consolidating accumulated revenue. The frequency depends on the turnover. In “Full Anonymity” mode, the company receives coins with exchange histories that are not linked to each other or the store's addresses.