Minecraft anticheat guide
FairPlay Check Provenance and Default Damage Mitigations
How FairPlay sorts checks by behavior, what its fp, in, tg and gr provenance tags mean, and what the 4.0.7 default damage mitigations do for server owners.
Short answer: categories, provenance and default mitigations
Per FairPlay engineering notes, every check has a functional category that names the behavior it examines. A separate provenance tag records where the implementation's logic came from: fp for FairPlay-native or multi-source work, in for Intave-derived, tg for TotemGuard-derived, and gr for GrimAC-derived. The 4.0.7 notes also describe default damage mitigations that tighten as violation levels rise.
How checks are categorised
Functional category names describe the behavior and evidence a check examines. They do not describe where the code came from. The notes list FASTBREAK, SCAFFOLD and PROTOCOL as examples of final category names, and state that no interact or tick category exists.
Provenance is metadata. Changing a provenance label does not rename a check or its configuration file, so the names staff see stay stable when lineage is recorded or corrected.
What each provenance tag means
Lineage is recorded so readers can see which upstream designs shaped a check. The notes credit Intave, TotemGuard and GrimAC through these tags. TotemGuard is GPL-3.0, and its parity work was described as a semantic, clean-room process: its source was not copied, linked or used as a runtime dependency.
| Tag | Meaning per the notes | Note |
|---|---|---|
| fp | FairPlay-native or multi-source implementation | Scaffold placement checks are FairPlay-native. |
| in | Intave-derived implementation | The tag never means inventory. Inventory stays a functional category. |
| tg | TotemGuard-derived implementation | Protocol acknowledgement ordering sits in the protocol category. |
| gr | GrimAC-derived implementation | One fastbreak position check is a semantic port of a Grim position check. |
Rules that govern check ownership
The notes set ownership rules that limit how checks change between releases. Provenance claims are source-backed. They do not prove behavior in a running Minecraft server.
What default damage mitigations do
Stock punishment defaults reduce the damage a punishment prevents as violation levels rise. Per the 4.0.7 notes, the first level prevents half of the damage, the second prevents 90%, and the third level and above prevent all of it for a stock duration. The third level also turns on a hit-cancel action, and higher levels inherit the third-level mitigation.
Other punishments keep their earlier behavior in that release. Notifications, kicks, bans, block disabling, totem prevention and reach adjustments are unchanged.
| Violation level | Damage prevented | Damage remaining |
|---|---|---|
| 1 | 50% | 50% |
| 2 | 90% | 10% |
| 3 | 100% | 0% |
| 4 and above | 100% | 0% |
What the migration changes on upgrade
The punishment defaults carry a revision marker. On startup or reload, a profile at an older revision moves to the current defaults only where its entries exactly match previous stock values.
Custom percentages, thresholds and durations are preserved. The third-level hit-cancel action is added only when the stock third-level entry is migrated and that tier does not already define one. Explicit custom profiles are not forced to the new defaults, and running the migration again changes nothing.
Profiles at any older revision, including the legacy revision 0 profiles, follow the same rule. The notes call the migration idempotent, so a restart after the first run leaves the file as it was. Your own edits survive because the rewrite only targets exact matches.
Who should read the damage table closely
Server owners who never edited their punishment file receive the new stock values on upgrade. Owners with a tuned file keep their values, which means the table on this page may not match what players see on their server.
Staff who answer player questions should know which group their server falls into. A player who asks why a punishment feels softer than a neighbor's server may be on a different revision or a customized profile, and the config file is the place to check.
Upgrade checklist for server owners
Stock durations per level are set in the punishment defaults. Read them from your own config instead of copying them from this page.
cp <path-to-punishment-config> <backup-dir>/punishments-$(date +%F).ymlWhat has not been verified
The notes say the mitigation change was compiled and checked with isolated migration tests covering fresh defaults, a stock update, idempotence, a legacy profile, and preserved custom values. Full Maven and JUnit runs were not possible in that environment, and no Minecraft server smoke test was executed.
Treat runtime behavior on your server as pending until your own staging test confirms it.
FAQ
Does a provenance tag change how a check behaves?
No. Per the notes, provenance is source-lineage metadata. Behavior comes from the check's functional category and its single runtime authority.
Does the in tag mean the inventory category?
No. The in tag means Intave-derived. Inventory remains its own functional category.
Will upgrading overwrite my custom damage settings?
Only entries that exactly match previous stock values are rewritten. Custom percentages, thresholds and durations are kept, and custom profiles are not normalized.
Does the migration run on every restart?
It runs at startup or reload, but the notes describe it as idempotent. Once a file is at the current revision, later runs make no changes.
Should I copy the stock damage table into my config?
Compare the table first, decide which levels you want, and record the reason for any difference so later staff understand the choice.