Best Bitcoin Dust Attack Detection Tools for Exchanges and Wallet Teams

Dust used to be a privacy problem. Somebody sprayed specks at thousands of addresses, waited for one of the recipients to consolidate that speck with real coins, and learned that both addresses belonged to the same person. Annoying, cheap to ignore if you never spent it.

That is not the shape of the problem any more. Between 17 and 24 August 2026, roughly 12,000 unsolicited small deposits arrived at Kraken from a wallet that Arkham Intelligence had labeled as belonging to HTX, an exchange under United Kingdom and European Union sanctions. Kraken automated sanctions screening did exactly what it was built to do and locked customer accounts. Those customers had done nothing except receive coins they never asked for. Access was later restored, a disputed sum stayed segregated, and HTX denies sending them at all.

Read that last sentence again, because it is the whole buying decision. The amounts and the transactions are exact, and anyone with a node can recompute them. The label that triggered the freeze is inference, and the party it names disputes it. Any tool you buy in this category is selling you both of those things bundled into one invoice, and they have wildly different reliability.

You are buying two products, and only one of them is a measurement

Split the category before you shortlist anything.

The first product is arithmetic over the chain. Which outputs are below the dust threshold, which transactions created many of them at once, where did those coins go next, was the speck ever spent alongside real funds. All of that is exact, reproducible, and cheap. Two people running the same query on the same block get the same answer or one of them has a bug.

The second product is attribution. Which cluster does the sending address belong to, is that cluster sanctioned, what is the risk score. This is inference built on address clustering and observed behavior. It is genuinely valuable and it is genuinely uncertain, and the Kraken episode is what it looks like when the uncertainty lands on a real customer.

Vendors price these together. Your engineering team should not treat them together. Build the arithmetic in house where it is verifiable, and buy attribution from someone whose name an examiner recognizes, knowing what it is.

The five dust limits, and why one number is wrong

Nearly every write-up on this topic says the Bitcoin dust limit is 546 satoshis. That was true for legacy outputs and has not been the whole story since SegWit. Bitcoin Core computes the threshold in GetDustThreshold in src/policy/policy.cpp, based on how many bytes the output plus the input that eventually spends it will occupy, multiplied by a fixed dustRelayFee of 3,000 satoshis per kilovirtualbyte.

Thresholds are the Bitcoin Core defaults at a dustRelayFee of 3,000 satoshis per kilovirtualbyte. The right hand column comes from fetching every transaction of blocks 964,592 and 964,100 and taking the smallest output of each type.

Taproot is the row worth arguing about. A Taproot output can be spent with one BIP340 signature, which is smaller than the P2WPKH spend the formula assumes, so on pure arithmetic its limit should be under 330. Bitcoin Core kept the P2WPKH computation deliberately rather than lower the dust level further, a decision recorded in pull request 22779. That means 330 is a policy choice, and any tool that derives thresholds from first principles will quietly disagree with the network about Taproot and the other address types.

Nobody actually sends dust

Here is the measurement that should change how you write the rule. We fetched all 5,987 transactions of block 964,592, mined 29 August 2026 at 15:38:20 UTC, and all 5,635 transactions of block 964,100, and checked every output against the threshold for its own script type.

Zero. Out of 12,958 spendable outputs across the two blocks, not one was below its dust limit. The smallest Taproot output in either block was 330 satoshis against a 330 threshold. The smallest legacy output was 546 against a 546 threshold. Values stack up on the floor and never go under it, which is what you would expect from a rule that default nodes enforce by refusing to relay.

So a detection rule written as value below threshold will fire on essentially nothing. The real signal is a transaction that produces many outputs sitting exactly at their thresholds, sent to addresses with no relationship to each other.

What a real spray looks like on chain

On 28 August 2026 at 23:13:55 UTC, transaction ad3501200064d4ae96b13c77c668777f88fc40baad065c49a0b5cca3981674bb spent 21 native SegWit inputs into 21 outputs. Twenty were poison and one was change.

The amounts are the giveaway: 546 satoshis to three legacy addresses, 540 to five P2SH addresses, and 330 to twelve SegWit script hash addresses. Those are not round numbers somebody liked. They are the exact Bitcoin Core threshold for each recipient script type, computed per output. Whoever built this reads policy.cpp more carefully than most compliance tooling does.

Two of the twenty went to cold addresses carried on widely published exchange reserve lists. That has a second order effect worth knowing about: a reserve dashboard that counts transactions or active addresses rather than value now reports those cold wallets as active, five times in five days, when zero satoshis of consequence moved.

Why this got cheap in the last year

That transaction paid 1,125 satoshis in total fees at 0.52 satoshis per virtual byte. Twenty addresses poisoned for about 56 satoshis each.

It would not have relayed a year ago. Bitcoin Core carried a default minimum relay feerate of 1,000 satoshis per kilovirtualbyte, or 1 satoshi per virtual byte, and 0.52 is under that floor. Release 30 cut the default to 100. The dust feerate that sets the thresholds was deliberately left at 3,000, so the constraint on how small an output can be held firm while the constraint on how cheaply you can broadcast dropped by a factor of ten. Spraying got roughly ten times cheaper. Dust did not get smaller.

If your last review of dust volumes predates that change, redo it. The economics moved underneath the assumption.

The vendor landscape, honestly

We checked pricing pages first-hand on 29 August 2026.

Where the screening vendors genuinely beat us: attribution. They employ people who do nothing but map clusters to real entities, and we do not do that at all. If your obligation is to screen deposits against sanctions lists, you need one of them, and the honest reading of the Kraken episode is that their labels are useful and fallible at the same time. Mapping that obligation to a specific control you can evidence is its own discipline, and teams running formal programs usually want software that tracks obligations and maps them to controls rather than a spreadsheet.

Where we beat them: you can see the arithmetic. Every output row carries its value and its script type, so the threshold logic is yours to write and audit, and a finding you produce can be handed to anyone with a node to verify independently. That is the difference between an alert you can explain to a regulator and an alert you can only escalate.

What to check before you buy

Ask a shortlisted vendor to run these against a block you choose:

Does it use the per script type threshold or a flat 546? A flat rule over-flags SegWit change and misses nothing useful. This one question separates tools built on Bitcoin policy from tools built on a blog post.

Can it group by transaction? Single small outputs are noise. Twenty near-threshold outputs from one transaction to unrelated addresses is the actual event. If the product only scores addresses, it cannot see the shape.

Does it exclude unspendable outputs? OP_RETURN outputs have a threshold of zero and are never dust. In the two blocks we measured they were about 45 percent of all outputs, so a scanner that does not filter them is discarding half its input or, worse, counting it.

Can you see the address list behind a label? Usually the answer is no, and that is the risk the Kraken customers absorbed. At minimum, know whether you can.

Can you reproduce a finding without the vendor? If an alert cannot be recomputed from raw chain data, you cannot defend it, and you cannot tell a false positive from a real one.

Questions we get asked

How do I detect a dusting attack? Group outputs by transaction, count how many sit at or barely above the dust threshold for their own script type, and flag transactions sending many of those to unrelated addresses. Value alone will not work, because outputs below threshold do not relay and therefore effectively do not exist on chain.

Is a dusting attack dangerous? Receiving dust cannot move your coins or expose your keys, so the direct risk is zero. The indirect risks are real: spending it links your addresses for whoever sent it, and if the sender carries a sanctions label your exchange may freeze the deposit while screening reviews it.

What is the bitcoin dust limit in satoshis? There are five. 546 for legacy P2PKH, 540 for P2SH, 294 for native SegWit P2WPKH, and 330 for P2WSH and Taproot, at the Bitcoin Core default dustRelayFee of 3,000 satoshis per kilovirtualbyte. Unspendable outputs such as OP_RETURN have a threshold of zero.

Does the dust limit change when fees are high? No. It is set by a fixed dustRelayFee constant, not by market fee rates and not by the minimum relay fee. Bitcoin Core release 30 cut the default minimum relay feerate by 90 percent and left the dust feerate untouched.

Should I consolidate dust to clean it up? Consolidating is exactly what the sender is waiting for, because it proves the addresses share an owner. Leaving it alone costs nothing. If you must clear it, spend it on its own rather than mixed with unrelated funds.

Where to start

If you are building this in house, the shortest path is to query outputs directly with their script types and write the threshold rule yourself, which is what Bitcoin dust attack detection and dust limit data is built for. Teams already running a screening pipeline usually pair it with crypto AML data for the deposit side and transaction tracing for the follow-the-coins question after an alert fires. The same script type detail that makes dust rules correct is the detail most address APIs do not return at all, which is worth checking before you assume your current provider can do this.

BitcoinDatabase provides informational on-chain data and analytics. It is not legal, compliance, investment or trading advice, and nothing here is a determination about any person or entity.