Product Docs Pricing Devlog About
Sign In Get Started
Real-Time Aimbot Detection: Signals and Thresholds
Back to Devlog

Real-Time Aimbot Detection: Signals and Thresholds

Kenji Watanabe

At 100ms intervals, crosshair angular velocity exposes motion human input cannot physically reproduce. That makes aimbot detection signal analysis rather than pattern matching. Published patterns invite aimbot authors to adapt; signals grounded in human limits are harder to fake.

Why basic heuristics break down

The obvious method is to search for "unnatural" accuracy: flag players over a headshot percentage or kick players whose kill-death ratio falls outside the normal distribution. It fails for two reasons.

First, genuine human outliers exist. In a sufficiently large player pool, someone will earn aimbot-like statistics legitimately. A 90th-percentile player on a server full of new users looks anomalous. Statistics alone create false positives that hurt trust more than cheaters.

Second, advanced aimbots imitate human statistics. They add variation, intentionally miss, and randomize click timing. Outlier detection catches poor aimbots. Good ones learned long ago to avoid that detection vector.

Harder signals sit lower in the stack: input timing, angular velocity during acquisition, crosshair movement relative to target movement, and frame behavior immediately around a confirmed hit.

Five signals we track

Angular velocity during acquisition

When a human snaps toward a target, the crosshair travels a curved path with changing acceleration, slowing near the target. Even humanized aimbots often show near-constant acceleration or recognizable deceleration. We sample crosshair angular velocity at 100ms intervals during targeting events, then compare acceleration with that player's session-baseline distributions. Human variance correlates with distance, target size, and prior session performance. Aimbot profiles are flatter.

Regularity in input timing

Human mouse input contains timing variance. Raw event intervals are irregular within ranges consistent with motor control. Aimbots polling at fixed intervals, often for performance reasons, create streams with unusually low inter-event variance. We calculate the coefficient of variation for timing intervals in each targeting sequence. Values below a physically plausible human-jitter threshold add to the confidence score. This is not a binary flag; it feeds a composite score.

Persistence of target lock

Humans lose lock when targets change direction unpredictably. Aimbots hold it more consistently because they receive target positions directly instead of processing visuals. We measure crosshair-to-target distance in frames after a direction change, predicted from velocity change. Humans show a lag before reacquiring. Aimbots correcting in zero or near-zero time stand out because unavoidable perceptual and motor latency is missing.

Click timing versus target position

Visual-to-motor latency makes humans fire slightly before or after optimal aim alignment. The delay is measurable and consistent within a player, though it differs between people. A shoot-on-lock aimbot fires with near-zero delay after alignment. We establish each player's click-to-aim-alignment baseline during low-suspicion windows, then flag sessions where timing moves toward zero at a statistically significant rate.

Targeting through walls

Some aimbots query target positions instead of screen position, snapping toward targets through walls before they enter line of sight. Server-side comparison of crosshair trajectory with occluder geometry detects this. Tracking a player's actual position through a wall the player cannot see through is a clear indicator. We weight this signal highly because legitimate explanations are rare.

Thresholds and confidence scores

No single signal independently causes a ban. Each adds to a composite confidence score for the player-session, with thresholds set per-game by the studio. Ranked competitive shooters justify more aggressive settings than casual battle royale games, where false positives carry greater social cost. Tashi's default has three tiers: below 0.4 is clean, 0.4 to 0.7 is flagged for manual review, and above 0.7 triggers automated session restriction pending review.

We will be direct about false positives: under the default thresholds, roughly 2-4% of flagged sessions prove clean after manual review. That cost is real. Studios using defaults will sometimes flag legitimate players, and the threshold is meant to be tuned. With a smaller player base and personal knowledge of top players, raise the confidence floor significantly. In a large anonymous competitive mode, 2-4% false flags may be acceptable for the return.

What we are not claiming

This method misses memory-injection cheats that spoof the input stream at the OS level before it reaches our SDK. Server-side analysis sees only what the client sends. Advanced kernel-level aimbots can provide clean input to the server while running aimbot logic locally. Detecting those needs a client-side component with kernel access. Server-only anti-cheat is not complete for competitive titles with high financial incentive to cheat. It is right for most indie multiplayer games, where attackers are opportunistic cheat users rather than aimbot developers targeting your game.

These five signals catch much commodity aimbot software because it is not built to evade per-player behavioral analysis. It is built to evade static accuracy thresholds. For a small-to-mid multiplayer title receiving accuracy complaints, server-side behavioral analysis addresses most of the issue without a client-side kernel component.