Grim simulates every movement a player could make, then watches for the impossible one

The core idea is enumerate every legal move, then flag the rest

The claim that distinguishes Grim from threshold based anticheats is in the Movement Simulation Engine section: a 1:1 replication of the player's possible movements.

That framing changes the logic of a check. Instead of asking whether a speed looks too fast, the engine simulates what a legitimate player could do in that situation and compares. The README states the systems are designed to be secure and mathematically impossible to bypass, giving the reasoning that the prediction engine knows all possible movements, so there is no leftover to exploit.

Whether that holds in practice is a different question, and the repository description itself calls Grim a bypassable anticheat, which is an unusual thing for an anticheat to say about itself. Read those together: the theoretical claim is that the simulation is complete, and the operational claim is that cheats exist anyway.

The scope of the simulation is broad and specific. The README lists basic walking, swimming, knockback, cobwebs and bubble columns, plus riding entities from boats to pigs to striders. Accuracy was, in the words of the README, built upon covering edge cases to confirm it.

So the cost model is inverted relative to a conventional anticheat. Rather than enumerating cheats and checking for them, this enumerates legitimate behaviour, which is expensive to keep correct and cheap to run once correct.

The description also lists reach, timer and speed categories along with antiknockback percentages. Those are the author's own framing of what the checks cover, and the repository is written in Java with the platform split into separate build outputs.

Version differences are handled in the simulation, not ignored

The section on client version compatibility is the part that most directly reduces false positives, and it is unusually detailed.

All four combinations of old and new are supported regardless of the technical changes between versions: 1.13+ clients on 1.13+ servers, 1.12 and below clients on 1.13+ servers, 1.13+ clients on 1.12 and below servers, and 1.12 and below clients on 1.12 and below servers.

The collision order is said to depend on the client version and to be correct, which matters because the order of collision resolution is exactly what a movement simulation walks through, and getting it wrong makes every downstream check wrong.

Bounding box differences are enumerated. A single glass pane is a plus shape for 1.7 to 1.8 players and a star for 1.9 and above. 1.13 and above clients on 1.8 servers see the plus shaped glass pane hitbox because of ViaVersion. Waterlogged blocks do not exist for 1.12 and below players. Blocks that do not exist in the client's version use ViaVersion's replacement block, and block data that cannot be translated to previous versions is replaced correctly. All vanilla collision boxes are said to be implemented.

This is the part of the README to read if you are deciding whether a mixed version server can run Grim without false bans. Every one of those items is a case where a naive implementation would flag a legitimate player.

It also explains the ViaVersion constraint below. If ViaVersion's block substitution is part of the simulation, then running it on the proxy where Grim cannot see it produces wrong predictions.

Running checks on the Netty thread is the scaling decision

The Fully asynchronous and multithreaded design section makes one architectural claim that matters more than the rest for a server operator.

All movement checks and the overwhelming majority of listeners run on the Netty thread. The stated consequence is that the anticheat can scale to many hundreds of players, if not more, with thread safety described as carefully thought out. The README credits the next core for allowing this design.

On a Minecraft server, the Netty thread handles network I/O, so putting movement checks there means they happen on the packet arrival path rather than being scheduled onto the main server thread and delayed. The consequence is that a check either runs immediately or the thread is blocked, and it means anticheat cost does not land as a tick time spike.

The other three subsections support the same goal.

Full world replication: the anticheat keeps a replica of the world for each player, built by listening to chunk data packets, block places and block changes. Chunks are compressed to 16 to 64 kb per chunk using palettes on all versions. The README states that with this cache the anticheat can safely access world state, and that because the replica is per player, a multithreaded design works. The world is recreated for each player, which is what allows lag compensation, and the README notes that sending players fake blocks with packets is safe and does not lead to falses, and that client side blocks cause no issues with packet based blocks.

Latency compensation: world changes are queued until they reach the player, so breaking blocks under a player does not false the anticheat, and everything from flying status to movement speed is latency compensated.

Inventory compensation: the player's inventory is tracked to prevent ghost blocks at high latency and other errors.

Install paths, proxies, and the feature complete declaration

Requirements are short. Java 17 or higher, and a Spigot, Paper, Folia or Fabric server environment, with details on the wiki for both.

Downloads come in two flavours and the README is explicit about which is which. Latest updates are recommended from Modrinth, with GitHub artifacts also available through nightly.link as a Bukkit zip and a Fabric zip labelled bleeding edge. Major releases only are struck through on the README for Hangar and SpigotMC, meaning those channels are no longer current.

That distinction is the one to internalise. Modrinth is what most operators want, and the nightly.link builds exist for testing against a server that has already moved.

The proxy rules are the most likely source of a broken setup. If you use Geyser, Floodgate must be installed on the backend server where Grim runs, so Grim can access the Floodgate API. If you use ViaVersion, it must be on the backend server only, and Grim does not support having it on the proxy even if it is also installed on the backend.

Two declarations in the README deserve attention. The project is considered feature complete for the 2.0 open source branch, and if you want a bug fix or enhancement and cannot sponsor the work, pull requests are welcome. A premium version is planned, offering additional subscription based paid checks such as heuristics.

Read those together carefully. The open branch is finished, new non sponsored work goes through pull requests, and the advanced detection is planned as a paid feature rather than as part of the open source product. That is a direct statement about what the free version will and will not grow into.

The default branch is 2.0, releases are v2.3.73 on 2026-03-09 and v2.3.72 on 2025-10-03, and the last push was on 2026-10-15. The repository has a SECURITY.md and a CONTRIBUTING.md, and there is a separate GrimAPI repository for the plugin API used to integrate Grim into your own plugins.

Building from source, and the GPL question

Compiling is three steps:

git clone https://github.com/GrimAnticheat/Grim.git
cd Grim
./gradlew build

The final jars land in `<platform>/build/libs` folders, which matches the repository layout with separate `bukkit/`, `common/` and `fabric/` directories alongside `buildSrc/`, `libs.versions.toml` and Gradle files using the Kotlin DSL, including `build.gradle.kts`, `settings.gradle.kts` and `testlibs.versions.toml`.

The licence is GPL-3.0, and that deserves a sentence of care rather than a scare. The repository identifies the licence as GPL-3.0; consult qualified counsel about its application to a particular commercial deployment.

That reasoning is the kind of question to put to your own counsel for a commercial server, and it is worth doing before you adopt rather than after.

The alternative approach is worth naming too. A conventional anticheat uses thresholds and heuristics on observed values, which is cheap to write, cheap to run, and produces false positives on unusual but legal movement. Grim's simulation approach inverts that, buying precision with implementation cost and a permanent maintenance obligation to track every Minecraft version change. On a server with a mixed client base and an active player community, that is usually the trade you want. On a private server of friends, it is a lot of machinery.

Editorial conclusion

Adopt Grim if you run a Paper, Folia or Fabric server where movement cheats are your main problem and your player base is on a mixed set of client versions, since the simulation engine's version handling is the reason it produces fewer false positives than simpler checks. Do not adopt it expecting comprehensive coverage of cheats that are not movement based, and read the licensing consequences carefully, because GPL-3.0 applies to the plugin rather than to your server. Verify first which build channel you take, since Modrinth is recommended while the nightly.link artifacts are labelled bleeding edge, and check your proxy setup, because ViaVersion on the proxy is explicitly unsupported.

Frequently asked questions

Official sources

1. GrimAnticheat/Grim on GitHub
2. License: GPL-3.0
3. Project website
4. README
5. Releases