Bitcoin is pseudonymous, not anonymous
Every Bitcoin transaction lists the addresses it spends from and the addresses it pays to. Anyone with a block explorer can read it. Anyone with a clustering algorithm can group those addresses into entities. Once one address is connected to a real-world identity, the entity around it inherits that identity — and every transaction in the cluster does too.
The job of a mixer is to cut that thread. Mixero takes a deposit that points to your wallet and returns coins that do not. The underlying idea is less exotic than the literature sometimes makes it sound; what matters is how carefully each step is performed.
The pool, illustrated
Mixero keeps a CoinJoin pool that is constantly being topped up by incoming deposits from unrelated orders. When you deposit, your coins are added to the pool. Your payout is composed from earlier, unrelated UTXOs that were already sitting there. The coins you receive have never been in your wallet before, and the coins you sent in are not the coins forwarded to your destinations.
Why the link genuinely breaks
Chain analysis depends on connecting outputs to a specific set of inputs. When Mixero pays you, the payout transaction includes inputs deposited by other users in earlier sessions. There is no transitive path on the blockchain from your deposit to your payout — they sit on different transactions, with different counterparties, often hours apart. The cluster the analyst was trying to build collapses.
Randomisation that earns its keep
Three things are randomised on every Mixero order: which UTXOs leave the pool to fund your payout, the relative sizes of each output within the shares you specified, and (if you choose) the delay before the payout is broadcast.
Amount randomisation
If you ask for two payouts of 0.4 BTC and 0.6 BTC, Mixero doesn't produce two clean transactions of exactly those sizes. Each payout is composed from several smaller UTXOs and a residual amount so the final balance matches your split while intermediate values look unremarkable on the chain.
Delay randomisation
The delay control lets you specify a window — for example, "between two and six hours" — within which payouts must arrive. The exact moment inside that window is drawn at random. There is no fixed offset between deposit and payout that can be used as a fingerprint.
Even a small delay is worth it. Instant payouts can leave a same-block fingerprint. Anything from 30 minutes to several hours removes it completely.
The deposit, step by step
When you start an order, Mixero generates a fresh deposit address used only for your session. It is not recycled, not stored long-term, and not derived from any deterministic series tied to other users. The address is included in your PGP-signed letter of guarantee, so you have proof Mixero committed to it before any coins moved.
Once your deposit reaches the required network confirmations, the order enters the active queue. The required confirmation count is small enough to keep waits short and large enough to make double-spend attempts impractical.
The payout, step by step
At payout time, Mixero composes one or more transactions that draw from the pool's UTXO set and pay your destination addresses. Each destination receives the share you specified at the start of the order. If you ask for the maximum of eight destinations, the cluster around each output ends up smaller — and harder to cross-reference later.
What happens after the session
When the guarantee window closes, the order is finalised. The link between your deposit address and your destinations — held only in memory while the session was active — is purged. The pool moves on with the next round of deposits, the addresses you used become indistinguishable from any other entry on an explorer, and you walk away with coins that do not point at the wallet you came from.
