Engineering write-ups on detection, false positives and the parts of anticheat work nobody puts on a feature list. Written for people who run servers, not for a keyword crawler.
Every vendor claims no performance impact. Here is where the time really goes, how to measure it on your own server with your own players, and which work can leave the box entirely.
Read it →Counting blocks per second flags skilled builders and misses a tuned scaffold. What separates automated placement from fast human bridging is geometry and rhythm, not throughput.
Read it →Most reach false bans come from comparing two positions that were never true at the same moment. A correct check needs a rewound world, a real hitbox and a raytrace, not a threshold.
Read it →A click cap is the easiest check to write and the easiest to defeat. What separates a human hand from a macro is variance, not speed, and the same is true of aim.
Read it →Most anticheats wait for a player to fly, reach or aimbot. There is an older trick that identifies the client on join, by asking it to render text only a cheat client knows how to translate.
Read it →A false ban costs more than a missed cheater. Here is where false positives actually come from: lag compensation, edge-case physics, and thresholds tuned on someone else's server.
Read it →Detection-count marketing tells you nothing. A checklist for evaluating any Minecraft anticheat: packet-level vs event-level, mitigation design, reversibility, platform support and what happens when the vendor's servers go down.
Read it →Folia's regionised threading forbids reading world state off the owning region thread, which is exactly what movement, scaffold and reach checks do. Here is the failure mode, the approach that does not work, and the one that does.
Read it →