Protocol Input Ordering Checks Explained

What do the protocol checks observe?

Protocol checks read the order and repetition of client packets rather than aim or timing. FairPlay names checks for acknowledgement order, duplicate input, slot changes after an action, held slot integrity, multiple entity attacks in one moment, and an attack plus a block placement in the same tick. Together they show whether the client sent things in an order a normal client does not send.

Because these checks read transport-level order, network conditions can shape their evidence as much as the player does. Read every alert with the connection history in hand.

A useful habit is a short connection log for each staff review, with the ping range, any reconnects and the time of the alert. Without it, reviewers tend to guess whether a strange order came from the player or from the network.

Which cheat behavior do these checks target?

Many client-side tools depend on sending packets out of order, repeating an input to double an effect, switching slots in a loop, or attacking several entities in the same moment. Protocol checks look for those shapes in the stream the server receives.

The point is not to judge one packet. It is the pattern across packets that a normal client would not produce, such as the same input sent twice in a row or an attack that arrives with no matching position for the target.

What legitimate traffic can resemble these patterns?

Protocol evidence is noisy by nature. The server can receive several legal packets together, and a clean client can produce an order that looks wrong when the connection is poor.

• Lag spikes that release queued acknowledgements together, which looks like out-of-order replies.
• Two identical movement or input packets sent when a player taps a key quickly.
• Hotbar or auto-tool helpers that legitimate plugins and client mods use.
• Attack and block placement in the same tick during fast PvP or bridge play.
• Resource packs or client mods that change how the hotbar or input behaves.

How should staff read protocol alerts?

Each protocol check asks a narrow question. Use the table to pick the first question for the alert in front of you, and pull the matching context before deciding.

What is the safe review order?

Protocol alerts are easy to over-read, so reviewers should check transport conditions first and player behavior second. The steps below keep the order consistent. Do not treat a single protocol alert as a pattern. Two or three alerts from the same check across separate sessions say much more than one burst during a bad minute.

• Check the connection history for the player in the same window.
• Confirm the client brand and any installed mods or resource packs.
• Look at the surrounding play context, such as the fight, the bridge or the farm.
• Compare with the player's previous alerts from the same check, if any.
• Record the decision and the connection data used.

What should you tune only in staging?

Protocol checks depend on the client and protocol versions your players use, so test after any client version change or any change to your version bridge. The compatibility articles on this site cover the version side in more detail. Keep protocol alerts alert-only for longer than movement alerts, because they are tied to transport conditions that change week to week.

Read the per-check reference before editing settings. Do not copy values from another server, since client mix and connection quality differ across networks.

Before you enable any protocol action, run the checks on a staging server with a deliberately slowed test connection, so you can see how the alerts behave when packets bunch up.

What have we not verified?

We have not measured how often these checks fire on each client version, how they behave on high-latency connections, or how they compare with other protocol-level checks. This article describes what the checks are named to observe. It does not claim that a protocol alert identifies a cheat on its own.