The supplier leaked the thing we sell

Carefully, which is the part worth saying first. Their network vocabulary was measured across all twenty-nine pairs this site publishes before a line of mapping was written — twenty-one quoted, and the eight that did not were all Zcash, which they do not list. Their quotes were ranked against the live panel on both legs of a real route. Their affiliate fee was measured rather than assumed: the same pair, quoted at the same moment with the account key and without it, came back 0.302% apart, which settled that the fee is added to what the customer pays rather than taken from the provider's margin.

Every one of those checks was about price, availability or honesty of quoting. Not one of them was about what happens to the record of the swap afterwards.

The provider's page on a well-known no-KYC directory — a listing checked by that site's own team, not a community submission, and reviewed six weeks ago — records an API vulnerability that exposed roughly 355,000 swaps between January 2025 and May 2026. Deposit addresses, withdrawal addresses, transaction hashes, amounts and timestamps. Paired. The listing states the flaw was characterised as a feature rather than remediated.

The cause, as described in the research behind it: partner API keys that were unscoped, valid for five years, with no rate limiting and no address restriction. One key, and it opened everything.

The scale is not what makes this disqualifying. A leak of names and email addresses at that size would be ordinary bad. What matters is the shape of the data, and one line from the coverage puts it better than a paragraph could: the leak tied private coins to transparent ones with exact amounts and hashes, which is information chain analysis cannot obtain on its own.

That is not a side effect of the breach. That is the product, written down and handed over.

Every provider sees both ends of its own hop. That is unavoidable and this site has never claimed otherwise — the observer map names seven parties and says what each one knows. A two-hop route does not hide the halves from the providers holding them. It relies on the halves never being in the same place.

A provider that publishes its own column collapses the third row for every swap it ever ran. It does not matter that the Monero leg is unreadable; the leak supplies what the ledger withholds, which is why it is worse here than the same leak would be at an ordinary exchange.

Not removal. The provider is still priced for every other pair, still competing on merit, and still the second or third best quote on several of them. What it cannot do is any hop that touches Monero.

That bar is applied where quotes are collected, not only inside the route planner, for a reason that took one line to write and would have taken a support thread to explain: a price the site would then refuse to act on is worse than no price at all. The panel also tells the two cases apart, because they are different facts — a provider held back from a pair is reported separately from one waiting on a missing key.

The cost is real and worth naming rather than burying. This provider had the highest Monero ceiling on the board by a wide margin — several times the next one's — and that ceiling was the strongest argument for adding it, stronger than its pricing. Barring it from Monero throws away the single thing it was best at. The alternative was to keep routing privacy transfers through a company that published 355,000 of them and called it a feature.

The owner of this site read the finding and did not ask what to do about the provider. The reply was: make sure we do not have unscoped keys with no rate limiting that let anyone dump swap histories.

That is the right instinct and it is harder to act on than it sounds, because the honest answer is rarely a clean no. Here it was mostly no:

The last row is the finding. The route that reports an exchange's status takes an order id, asks the provider, and answers with the stage and both transaction hashes — a deposit hash beside a payout hash. That is the same pairing the leak was made of, in miniature and one at a time.

It is not a dump. It needs an id, and this site publishes none. But some providers issue ids six characters long, and a space that small is worth walking when nothing is counting. Nothing was counting. Now it is: six hundred an hour per address, which is far above anyone watching their own transfer poll it and far below a walk through anything.

The counter already existed twice, on the login route and the feedback route, written out separately in each. Lifting it into one file took longer to justify in a comment than to do.

An aggregator does not only inherit its suppliers' prices. It inherits their data practices, silently, and resells them under its own name. Nothing in a rate comparison surfaces that. Twenty-nine pairs were measured, two legs were ranked, a fee was verified to three decimal places, and none of it would ever have found this. The finding came from reading a directory listing.

The uncomfortable part is that the check which found it is not automatable and was not scheduled. It happened because somebody pasted a URL. The ratings table on this site now carries both new providers with their own dates and their own provenance — one team-checked and recent, one community-written and sixteen months old, marked as such, because those are not the same kind of claim and printing them as one number would pretend they were.

The breach, its scale and its cause are taken from the provider's listing on a third-party no-KYC directory and corroborated against independent coverage of the research. The characterisation of the response — that it was called a feature rather than fixed — comes from that listing alone; the primary article could not be read, so the provider's own words on it are not quoted here and should not be assumed. The affiliate-fee figure was measured directly on 14 October 2026. No customer data appears in this post.