Reading a ban wave from the outside
The first twenty-four hours of a scare are almost entirely noise. Here is how the real signal separates out, and what a vendor should be doing while it does.
By Lethal Research
A scare in this niche tends to follow the same pattern. Someone posts that they were banned, three people say the same thing within an hour, and a screenshot with no context starts circulating. Within a few hours there is a confident consensus about the cause, and it is wrong more often than it is right. The goal is to read those first hours without panicking and without dismissing the reports, because both mistakes are expensive. It also helps to know what a vendor should visibly be doing while the picture is still unclear.
Why are the first hours mostly noise?
Bans happen all the time at a low rate, for reasons unconnected to any product, such as reports from other players, manual review and unrelated policy enforcement. Other causes include payment and account issues, shared-machine history and plain user error. Because that background rate never stops, the first few reports fit a real detection just as well as they fit nothing at all. What separates the two is not the reports themselves but their structure.
| Signal | Points towards a real detection | Points towards a false alarm |
|---|---|---|
| Timing | Reports cluster tightly in a window of hours, not spread across days. | A steady trickle at roughly the usual background rate, noticed only because someone started counting. |
| Correlation with a change | Onset lines up with a game patch, an anti-cheat update, or a specific product build. | No identifiable change on any side. The trigger is a forum thread, not an event. |
| Commonality | Affected users share something specific and narrow: one build, one firmware version, one title. | Affected users share only that they use products in this category at all. That is not a common cause. |
| Ban character | Consistent type, consistent message, consistent timing relative to session. Frequently applied retroactively in a batch. | Mixed ban types and messages, and durations that look like ordinary enforcement rather than one action. |
| Unaffected control group | Users on a different build or version of the same product are conspicuously fine. | No pattern at all in who is and is not affected. |
| Independent confirmation | The same clustering is reported by people with no connection to each other or to one vendor. | Everything traces back to one thread, one screenshot, or one person aggregating reports. |
No single row is conclusive. A real detection usually shows most of the real-detection signs within a day, while a false alarm rarely shows more than one.
A ban screenshot only proves that somebody has a ban screenshot. It does not establish a date or a cause, and it does not say which product was in use or whether the account was already flagged. It does not even show that the image belongs to the person posting it. Screenshots are easy to reuse, and they are a standard tool for creating a scare about a competitor. On their own they deserve almost no weight, and they only become useful as part of a cluster that also shows timing, commonality and a control group.
What should a vendor do in the first day?
This is the part to judge a vendor on, because it happens in public and under commercial pressure to say nothing. The correct sequence is not complicated, but it is expensive.
- 1Acknowledge within hours that reports exist, before any cause is known. Saying 'we are aware and investigating' is not an admission, but silence looks like one.
- 2Stop selling the affected product while the situation is unclear. Whether a vendor keeps taking money for a product that might be detected is the clearest test there is, and most vendors fail it.
- 3Move the status row off green to updating, investigating or risky. Leaving it green while a scare is live permanently destroys the value of the board, which is the vendor's most valuable asset.
- 4Collect structured data rather than screenshots: build version, firmware version, game, timestamp, ban type and session history. Publish a summary of what has been collected, even before any conclusion exists.
- 5Publish what is known and what is not known, separately and explicitly. Most of the first update should fall into the not-known part, and admitting that is what makes the known part believable.
- 6Follow up on a stated schedule, because an update promised in twelve hours and delivered in twelve hours is worth more than a confident answer in two.
Stop using the affected product on any account you care about until the picture is clear. The pause costs you a few days, and you can reverse it. Do not buy into the affected product while its status is unclear, and be sceptical of any discount that appears during a scare. Do not create a new account to test it, because that only adds a second data point to whatever is happening. Keep your own record of what you ran, which version and on which dates. If you later need to know whether you were in an affected group, that record is the only thing that will tell you.
How do ban scares usually end?
Scares end in one of three ways, roughly from most to least common. Most fade away because the cluster does not survive closer inspection: the reports were the background rate plus extra attention, and nothing identifiable ever correlates. Some turn out to be narrower than the panic assumed, affecting one build or one title rather than a whole category. A minority are exactly what they looked like. In those cases, the useful information almost always arrived within about twenty-four to forty-eight hours, as a clean correlation and a visible control group.
The same discipline makes all three endings readable. Keep the question open for a day, give structure more weight than volume, and notice which vendors behaved well while nobody knew anything. That last point is the most lasting thing you will get out of a scare, and it is worth more than being first to a conclusion.
We do not claim that our products cannot be detected, that we will always spot a detection early, or that our board has never been wrong. What we will do is follow the six first-day steps described for vendors, including the part where we stop taking money. That is a commitment about process, and it is the only kind of commitment anyone in this market can honestly make.
The guides behind this post
DMA setup for PUBG, a game whose publisher names DMA in public
6 min readPUBG runs Zakynthos, Krafton's own anti-cheat, and Krafton's 2026 roadmap puts DMA detection first. Krafton says it banned about 260,000 accounts for DMA cheating in 2025, and no other publisher covered here has said that about this hardware. This store sells no DMA cheat for PUBG, only an external one at /products/pubg, though every firmware tier lists the game.
Open the guideBan types explained: HWID, account, IP, shadowban and flags
10 min readHWID bans are tied to hardware identifiers, account bans to the account record, IP bans to the connection, and shadowbans to matchmaking, not access. A spoofer only touches the hardware layer, and a machine can be flagged without being banned yet.
Open the guideRead next
Questions about this? Ask on Discord
All posts