Scaffold and tower detection: why rate limits punish your best bridgers

Scaffold is the check most likely to be badly implemented, because the naive version is so easy to write. Count the blocks a player places per second. If the number is high, flag them. It takes an afternoon, it produces alerts immediately, and it is wrong in both directions.

It is wrong on the false-positive side because a practised bridger on a good connection places blocks fast. Not "suspiciously fast", just fast. Speed bridging, ninja bridging and the various god-bridge techniques are all skills people have spent months learning, and they all look like throughput outliers to a counter. The players a rate limit catches first are the ones your server most wants to keep.

It is wrong on the false-negative side because a rate limit publishes its own threshold. Any scaffold worth worrying about is configurable, and the first thing its user does is turn the speed down until the alerts stop. A check that can be defeated by moving one slider is not a check.

What a human bridge actually looks like

The useful signal is not how many blocks go down. It is the relationship between where the player is looking, where they are standing, and where the block ends up.

A person bridging has to physically aim. The head turns first, the hand follows, and the two are never perfectly synchronised. Rotation leads placement by a variable margin. Spacing between placements wobbles. Occasionally a block goes somewhere slightly wrong and the player corrects, or misses entirely and has to recover. There is a rhythm, and the rhythm has noise in it.

Automated placement inverts that. The code decides where the block goes and then produces whatever rotation is required to justify it. That rotation arrives exactly on time, at exactly the angle needed, with none of the overshoot a hand produces. Spacing between placements is even. The correction events disappear, because there is nothing to correct.

So the question a scaffold check should ask is not "how fast" but "does the aim explain the placement, and does the sequence carry any human noise at all".

The patterns worth separating

Not all automated bridging looks the same, and lumping them together is where accuracy is lost.

• Straight-line scaffold is the easiest case. Placement is behind the player, rotation is pinned down and back, and the whole sequence is metronomic.
• Sneak and eagle patterns add a shift toggle at the block edge. The toggle timing is the tell: a person sneaks slightly early or late, a macro sneaks at the same offset every time.
• Tower is vertical and produces a different signature entirely. Jump timing, upward placement and the pillar's straightness are what matter, not horizontal spacing.
• Diagonal and staircase bridging are where naive checks generate most of their false positives, because the geometry is genuinely unusual and a human doing it well looks mechanical.

A single "scaffold" check that fires on all four will be tuned to whichever one your test server produced most often, and will be wrong about the rest.

Where the false positives actually come from

Three things, in roughly this order.

Latency bursts. A player whose packets arrive in a clump looks, to a rate counter, exactly like someone placing four blocks in one tick. The check has to reason about when actions were performed, not when they were received.

Skill. Covered above, and worth repeating because it is the one that costs you players. The better someone is at bridging, the more they resemble the thing you are trying to catch.

Unusual but legal geometry. Placing against an entity, bridging while falling, building across a corner. Each one is rare enough that it never appears in testing and common enough that it appears on your server in the first week.

What to do about it on your own server

Treat any placement check as the one most likely to be wrong, and configure it accordingly.

Run the aggressive variants alert-only first. Watch a week of your own traffic before you let them punish anyone, because the mix of builders on your server is not the mix on the vendor's test box. If a check has a toggle that the vendor ships disabled, there is usually a reason, and turning it on because you want more alerts is how you get an appeal thread.

When you do get a report, the thing worth looking at is not the violation count. It is whether the rotation data explains the placements. A staff member can read that in a few seconds and be right. A violation number tells them nothing.

How Sheriffguard approaches it

PlacementAnalysis works on the pattern rather than the raw rate: the relationship between rotation, position and where the block lands, across a sequence rather than a single event. The variants that are prone to false positives ship disabled, and every new detection lands alert-only so you can watch it against your own players before it is allowed to act.

That is also why mitigation matters more than punishment here. A cancelled placement costs a false positive almost nothing, a couple of blocks that did not go down. It costs a scaffold user the entire point of running one. Getting the response proportional means you can act on a signal long before you would be comfortable banning on it.