Minecraft anticheat guide
FairPlay Scaffold Packet and Tool Order Checks
How FairPlay's packet and tool order checks for scaffolding compare action sequences with network timing, and what staff should verify first.
What do the packet and tool order checks watch?
Packet and tool order checks watch the order in which a player's actions reach the server. Four FairPlay checks sit here: ScaffoldPacketOrder, ScaffoldPong, ScaffoldFastToolSwitch and ScaffoldInteractBelow. They look at whether sneak, placement, tool switch and interaction events arrive in an order that normal play rarely produces.
Which action orders do they target?
These checks target sequences that are hard to produce by hand. The sequence matters more than any single event, so each check watches a pair or a short chain of actions.
What legitimate actions can resemble these checks?
Normal play can produce unusual sequences, especially on slow connections. Hotbar scrolling, opening a chest under a bridge and quick sneak taps all create short chains that look unusual in order.
How should staff read order alerts?
Order alerts depend heavily on the network. Before you read a packet order alert, check the player's connection at the same time, and whether they connect through a proxy or a translation layer. Then look at whether the same order repeats across bridges.
What should you tune only in staging?
Order checks rely on the timing of network events, so they are sensitive to the test network itself. Tune them only on staging, using a controlled connection with and without added latency. Test hotbar scrolling, interactions below the bridge and Bedrock or proxy connections. Compare alert output before and after each change.
How do network paths change action order?
The path a player's actions take shapes their order. A direct connection to your server keeps events close to the order the player produced them. A proxy adds another hop, and a Bedrock player connected through a translation layer adds a conversion step. Each hop can bunch or reorder events, so the same hand movement can arrive in different sequences depending on the path.
Set up a controlled test before reading any order alert. Use the same account and the same bridge for every run, and change only the path or the latency. Keep the results next to the staff notes so reviewers can see which path produced which alert.
What should a packet order review record?
Record the event order you observed, the path the player used and the network state at the time. A log that shows only the alert will not help the next reviewer. Write the sequence in plain words, such as sneak start, placement and sneak stop, and note any tool switch between them.
Avoid drawing conclusions from one unusual sequence. Ordinary play can produce short unusual chains, so a repeat test on a stable connection carries more weight than a single alert.
When you test a proxy path, confirm that the proxy settings match the ones your players use. A test through a different proxy setup proves little about the players you actually serve. Record the proxy name or version used in each run so later reviews can match results to the right path. Treat a path you have not tested as unknown until the same bridge has been run through it, and say so in the staff notes.
What have we not verified?
No detection rate, error rate or staging result for these checks is given here. The descriptions reflect what each check compares. Verify behavior on your own proxy, client and version setup before relying on a packet order alert.
FAQ
Does a packet order alert need a network fix first?
Check the network first. Look at latency and the connection path for the same time before reading the alert as a player action.
Why does a Bedrock player trigger a packet order alert?
Bedrock players connect through a translation layer, which can change the order of actions the server receives. Test Bedrock sessions on staging.
Is opening a chest under a bridge suspicious?
No. It is ordinary play. The check compares that interaction with placement order, so review it in context.