Reach and hitbox checks: a distance number is not a reach check

The simplest reach check in Minecraft is one line: measure the distance between the attacker and the victim when the hit arrives, and flag anything over about three blocks. Almost every anticheat has shipped some version of it. It is also the single largest source of combat false bans, and the reason is worth understanding even if you never write a check yourself.

The two positions were never true at once

When an attack packet arrives at your server, it describes something the attacker did in their past. Their client decided the hit was valid using the world as it looked to them, which is your server's state delayed by their latency and smoothed by interpolation.

Meanwhile the victim has kept moving. By the time the packet is processed, the victim is somewhere else. If you measure the distance now, you are measuring between an attack from 80 milliseconds ago and a position from this tick. The two were never simultaneously true.

On a lightly loaded server with local players, the error is small enough to hide. Add a player on a 150ms connection, a victim strafing at full speed, and a tick that ran long, and the same honest hit measures well past any sane threshold. That is your false ban, and no amount of threshold tuning fixes it, because the number being compared is meaningless.

Rewinding is the actual requirement

A reach check has to reconstruct where the victim was from the attacker's point of view at the moment the attack was made. That means keeping a short history of every player's position and rewinding to the right point when a hit arrives.

Getting that right involves a few unglamorous details:

The rewind target is the attacker's perceived time, which is not simply "now minus ping". Ping is noisy and asymmetric, and treating it as a fixed offset reintroduces the error you were removing.
Position history has to be sampled at least per tick, and interpolated between samples, because the client saw a smoothed path rather than discrete steps.
The window has to be bounded. A player who can make the server rewind arbitrarily far can use that as its own exploit.

An anticheat that does this well will produce far fewer reach alerts than one that does not, which is worth remembering when you are comparing alert volumes between products. More alerts is not more detection.

A hitbox is a box, not a point

The second common error is measuring to the victim's feet, or their centre, and comparing against a single number.

Players are boxes. A hit that lands on the corner of a box is geometrically further from the attacker's eye than one that lands in the middle, and both are legal. Measuring centre to centre makes tall or wide targets look like reach, and measuring closest-point makes genuine reach look legal. The distance you actually want is from the attacker's eye position along their look vector to the point where that ray enters the victim's box.

That is a raytrace, not a subtraction. Once you are doing it, two more checks come almost free:

Direction. Does the attacker's rotation actually point at the target? An attack that lands on someone behind them is not a reach problem, it is an aim problem, and it is a much stronger signal.

Occlusion. Does the ray pass through a solid block on the way? Hitting through a wall is not something latency explains.

Yaw and pitch alone will not give you either of these. A check that only asks "were they roughly facing the victim" inside a generous cone is easy to satisfy while doing something obviously wrong.

What to ask a vendor

Three questions separate a real implementation from a threshold:

Do you rewind the victim's position to the attacker's perceived time, and how do you estimate that time?
Do you raytrace against the hitbox, or measure between positions?
Do you check occlusion, and what happens when the ray passes through a block?

An anticheat that cannot answer these is running the one-line version, whatever the marketing says. You will find out on your own server, in your own appeals channel.

How Sheriffguard approaches it

AttackRaytrace works from the packet stream rather than from server-side combat events, which is what makes the timing reconstruction possible in the first place: the check sees the attack, the rotation and the movement that preceded it as an ordered sequence, not as a callback after the server has already resolved the hit. Reach, hitbox and rotation are raytraced against a rewound view of the target rather than compared as distances.

The related combat checks, including the aura and automation patterns, each escalate on their own violation counter rather than pooling into a single number, so a player who trips one check repeatedly is treated differently from one who trips several once. That distinction is most of the difference between an anticheat you can leave enabled and one your staff learn to ignore.