Anticheat on Anarchy Servers: Exploit Protection vs Combat

What does anticheat mean when cheating is partly allowed?

On an anarchy server, an anticheat has two jobs that are often confused. The first is protection: stopping packets, items, and movement that crash the server, flood its network threads, or break world loading for everyone. The second is fairness: flagging reach, killaura, aim, and movement that give one player an edge in fights. An anarchy owner may choose to allow the second kind of cheating. The first kind still harms every player who connects, so most owners keep it on.

Split the anticheat into two layers

Write down which layer each check belongs to before you change any setting. A check that protects stability can stay on while a fairness check is disabled or set to alert-only. The table shows a common split. Your rules decide the final column, not this article.

Write the rule before the config

Players on an anarchy server argue about what is legal. A written rule removes most of that argument, and it tells staff which alerts to ignore.

• List the cheats that are allowed by name, such as killaura or reach, and the ones that are not, such as crash exploits and duplication.
• State what staff will do with an alert from each protection layer and each fairness layer.
• Publish the rule where players can read it before they join.
• Review the rule after the first month, when real alerts show what players actually do.

Keep protection and fairness separate in your logs

If both layers write to one alert channel, staff lose time sorting crash attempts from legal combat. Send protection alerts to a channel that staff read every day. Send fairness alerts to a log that staff review in batches. Use the same case fields for both so a player can be compared across sessions.

layer: <protection or fairness>
check: <check name>
player: <name>
window: <start> to <end>
rule reference: <rule number>
action: <none, alert, block, punish>
reviewer: <name>

Test the split on staging before going live

A no-rules server can break in new ways when one layer is off. Test the following on a staging copy with the exact plugin set you plan to run.

• Confirm that protection checks still block a known crash packet sequence from a test client you control.
• Confirm that a disabled fairness check produces no alerts for a legal fight.
• Confirm that an alert-only fairness check writes a log entry with the fields above.
• Confirm that staff permissions or bypass groups do not switch off a protection layer by accident.

What we have not verified

Keep a short record of every protection incident, including the packet type or plugin involved, the time, and the server version. When the same crash pattern returns after an update, the record shows whether a plugin or the server core changed. Share the record with plugin authors and your host only after removing player data. Owners who run no-rules servers often learn more from three well-documented incidents than from a long list of alerts with no context.

A rule that allows cheating does not cover every exploit. An exploit that duplicates items, corrupts a world, or disconnects other players harms people who did not choose to take that risk, and most rule sets treat it differently from a combat advantage.

We have not tested any anticheat against crash exploits on a no-rules server, and this article does not claim that any configuration blocks them. Check protection behavior with your own tests, and keep an incident plan for a server crash.