Desync
Desync is when a player's local view of a match stops matching the server's authoritative state. The player sees an opponent in one place while the server has them somewhere else, so shots miss, characters teleport, and positions snap back. It is a problem of divergence rather than speed, which distinguishes it from lag.
Also called
desynchronization
,
What Are the Two Kinds of Desync?
Players use one word for two different failures, and the fixes do not overlap. Two papers presented at GDC 2001 still describe both: Yahn Bernier's work on latency compensation at Valve, and Paul Bettner and Mark Terrano's 1500 Archers on a 28.8 on lockstep at Ensemble Studios.
Replication desync happens in games with an authoritative server. The client predicts what will happen, the server disagrees, and the client is corrected. Players see a character snap back or a shot pass through someone.
Determinism desync happens in lockstep games, where every machine runs the same simulation and only inputs are sent. The machines compare checksums of their state, and when the numbers stop matching there is no authoritative copy to fall back on. The session stops.
The second kind has its own error message. "A desync has occurred" is the exact phrase players search, often for popular games like Madden NFL 26 or College Football 26.
Knowing which kind your game has is most of the work.
In Practices - Insights from Edgegap's Blog
Article's key insights
Desync is a disagreement, not a delay: Lag means information arrives late. Desync means two machines hold different versions of the same world, which is a separate failure with separate fixes.
There are two distinct kinds: Replication desync, where an authoritative server corrects a client that guessed wrong, and determinism desync, where peer simulations diverge and the session stops outright.
Rubberbanding has two levers: How often the client mispredicts, which latency drives, and how visible each correction is, which netcode drives. Pull either one and players see less of it.
Tick rate is neither lever: Raising it does not make predictions more accurate, and on a connection already dropping packets it makes the artifacts worse.
"A desync has occurred" is a checksum failing: Lockstep games compare state hashes every turn, so one divergent float or one unsynchronized random call ends the session.
Why Does Rubberbanding Happen?
Rubberbanding is a replication desync being corrected on screen. It comes from two things multiplied together: how often the client guesses wrong, and how visible each wrong guess is.
The first is set by latency. Every millisecond between client and server is time the client spends simulating on its own guess. At a 60 Hz simulation rate, a client 30 ms from its server runs about two frames ahead of confirmation. At 180 ms it runs about eleven. Same code, same engine, roughly five times the exposure. Jitter and packet loss compound it, because a lost input means the server advances without the player's action at all.
The second is set by netcode. Rollback rewinds to the last confirmed frame when the server disagrees, resimulation replays the player's inputs forward from there, and presentation smoothing blends what is left across a few frames instead of teleporting. Done well, most corrections land so close to where the player already was that nobody notices.
Neither lever replaces the other. Good netcode at 200 ms still produces visible corrections. A short route behind a game with no prediction still feels unresponsive.
Why Doesn't a Higher Tick Rate Fix Desync?
Studios looking for an infrastructure fix usually reach for tick rate first. It is the wrong lever.
Tick rate sets how often the server resolves and broadcasts the world. Raising it gives finer timing for hit registration. It does nothing for prediction accuracy, because accuracy depends on the simulation code and on which inputs reached the server, not on how often the server talks. On a connection already dropping packets, a higher rate means more packets to drop, and corrections arriving more often.
The infrastructure lever that moves desync is latency. A server placed closer to the players in a match shrinks the problem the netcode has to solve, without shipping a patch. Edgegap's desync explainer works through both levers in full.
Can a Server Stop Desync?
A dedicated server changes both kinds, for different reasons.
For replication desync, it is the recovery path. When a client drifts too far, the server can stop sending deltas, the usual approach of transmitting only what changed, and push the full state instead. The client's divergent copy is overwritten. That costs bandwidth, which is why it stays the exception, but it turns a broken session into a momentary hitch.
For determinism desync, it changes the architecture. Lockstep sessions end on a mismatch because no machine has the standing to overrule the others. With an authoritative server in the middle, there is a source of truth by construction.
What a server does not do is shorten the distance to players on its own, or make prediction unnecessary. It gives you a state you own, can instrument, and can correct.
A word from our sponsor (ourselves!)
Most lag comes from distance, not from code. Edgegap's Edge Cloud is a distributed network with up to 615+ locations available on demand, so each match runs at the best available location for its players. Independent replays of live studio traffic measured a 58% drop in average round-trip time compared with public cloud.
When Is Desync a Cheat?
Sometimes the player reporting desync is the one causing it, and peer-to-peer games are the most exposed. When one player's machine hosts the match, there is no neutral party to confirm what anyone did, as Edgegap's guide to P2P's hidden costs covers. Players also search for how to trigger a desync on purpose, and on some platforms the word names an exploit.
In October 2025, Roblox developer loleris reported a "desync" exploit spreading across games on the Roblox Developer Forum. The exploiter's position still reached the server but stopped replicating to other players, so "the server sees you as in the ring, but all other clients see you as somewhere far away." Roblox staff reproduced it and shipped a fix.
The lesson is about where authority sits. A server in the loop only helps if it is the one deciding the outcome. Anything a client is trusted to report, from its own position to a match result, is something a client can falsify.
That does not take a heavyweight server. Bloody Bastards, a mobile game with more than 40 million downloads (Tibith Ltd, 2026), ran peer-to-peer with the host trusted with match results. The case study describes cheats as rampant, along with desync issues traced to that setup. Tibith moved to small, headless authoritative servers on Edgegap and reports no successful cheating since version 5.0.0. For a game that would not otherwise need a full dedicated server, a referee can be built on something as light as Edgegap's LightNet, a low-level Unity networking library, though the referee's rules are still the developer's to write.
Edgegap's Take (just our opinion, take it with a grain of salt!)
Edgegap's Take
When a player reports desync, the word tells you very little. The symptom tells you who owns the fix.
A session that stops with "a desync has occurred" is a simulation bug. No server, region or tick rate fixes it, because the two machines did different math.
A character snapping back is a prediction gap. Lower latency makes it smaller, and better reconciliation makes it less visible.
A player who is invisible or unhittable is an authority gap. Something the client was trusted with should have been decided on a server.
Sort the reports by symptom before assigning the work, and each one reaches the team that can actually fix it.
,
