Authoritative Server
An authoritative server is the single source of truth for match state. Clients send inputs rather than outcomes; the server checks them against the game’s rules, decides what happened and tells every player. Because the server settles results, not a player’s game, it is the foundation of fair competition and of most server-side anti-cheat.
Also called
server authoritative, server-authoritative model, authoritative game server
,
What Does Server-Authoritative Mean Compared to Client-Authoritative?
Server-authoritative and client-authoritative describe who has the final say over a piece of game state. On a server-authoritative system, a client asks and the server decides. On a client-authoritative one, the client decides and the server passes the result on, sometimes after a check.
Few games sit entirely on one side. Many netcodes let the developer set authority per object or per component:
Photon Fusion gives a dedicated server “full and exclusive” state authority over all objects, while its Shared mode initially gives each client authority over the objects it spawns, and that authority can move between clients (Photon docs).
Mirror syncs component data from the server to clients by default, and lets a component sync from its owner’s client instead. Its documentation notes that the server can still verify that data before passing it on (Mirror docs).
Unreal Engine’s character movement can be set to accept a client’s position once the server has simulated the move and found no error, which its documentation describes as useful for short bursts of movement that are hard to sync (Unreal Engine API).
So an authoritative server usually means a split, decided system by system. Every game draws the line differently, but a common pattern looks like this:
System | Often decided by | Why |
|---|---|---|
Match result, score, damage | Server | Changes other players’ outcome |
Inventory, currency, unlocks | Server and backend | Has value beyond the match |
Player movement | Server, with the client predicting | Other players see it, and the player feels any delay |
Shared physics objects | Server, or one client in some netcodes | Visible to everyone, and costly to simulate |
Camera, interface, cosmetic effects | Client | Affects only that player |
The question behind each row is the same: who gains if the machine deciding it reports something false?
What Does an Authoritative Server Check Before It Accepts an Input?
Clients send intents rather than results: move forward this tick, fire in this direction, buy this item. For each one, the server runs a short loop:
Receive the intent, and note which player sent it and when.
Check it against the rules: is it possible, allowed and on time?
Apply it to the match state, or reject it.
Send the result to every client that needs it.
Step 2 is mostly game code. Some engines check movement or similar actions for you, but whether a request makes sense in a particular game is usually up to the developer. Typical checks:
Rate: how often an action can happen, such as fire rate or a cooldown.
Reach: whether the target is close enough. Minecraft’s Bedrock dedicated server exposes this as a setting: with server-authoritative block breaking turned on (it is off by default), the server checks that a player could break a block when their client says they did, within a configurable range (Microsoft Learn, updated 25 June 2025).
Consistency: whether the action matches the player’s state. The same server can also compare the direction of a player’s attack with where they are looking, within a set threshold.
Ownership: whether the player holds the item or controls the character.
Movement: whether a position could be reached at the player’s speed. How strict that check should be, and what players see when it corrects them, is covered under rubberbanding.
Shots add one more step: the server judges a hit against where targets were when the player fired, which is lag compensation.
A rejected input is also information. Logging which rule rejected which input, per match, turns validation into evidence that the review step of anti-cheat can use.
What Does Server Authority Cost?
Authority has trade-offs in time, compute and hosting, and each can be managed.
Time. A decision made on the server reaches the player one round trip after their input. Waiting for it would make every action feel late, so many netcodes have the client predict the result and correct it when the server answers. Unity’s Netcode for Entities, for example, describes its model as server authoritative architecture with client prediction (Unity docs). Client-side prediction hides the round trip; it does not remove it. A longer round trip usually means larger corrections, and more of them.
Compute. The server runs every system it decides. Checking a purchase takes little. Shared physics can be one of the heavier systems to simulate, so some games keep physics that decides nothing on a client and keep anything that decides the outcome on the server.
Hosting. Authority protects the match best when no player controls the machine it runs on. On a listen server, one player’s game holds the authority, along with its memory and files. A dedicated server moves the authority to a machine nobody plays on, and that machine has to run somewhere.
How Do You Add Server Authority to an Existing Game?
Adding authority late usually means moving code: logic that ran on a client moves to the server, and the client learns to send intents and accept corrections. An order that often keeps the risk low:
Results and economy first: match results, rewards and currency. They are what cheaters target, and they rarely depend on how the game feels frame to frame.
Movement next, with prediction, so players feel little change.
Shared physics last, where it decides the outcome.
Bloody Bastards, a mobile game with more than 40 million downloads, moved its whole match to the server at once. It ran peer-to-peer, with the host’s device trusted to report match results, and its studio describes cheating as widespread. Tibith moved it to headless, server-authoritative dedicated servers on Edgegap, where the server runs the physics and clients render the result, using fractional vCPU to right-size each server. The studio says: “Literally no hackers have been able to cheat since version 5.0.0” (Tibith Ltd, 2026).
Because every authoritative decision is a round trip, where the server runs matters as much as what it decides. Independent replays of a AAA publisher’s live traffic measured a 58% reduction in average round-trip time with dedicated servers placed near its players, compared with public-cloud relay placement (Edgegap platform data, page updated 30 September 2026).
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.
Edgegap's Take (just our opinion, take it with a grain of salt!)
Decide Who Owns Each System Before Production, Then Track What the Server Rejects
Authority is easiest to decide before gameplay code exists. Write it down as a table in the design document: for each system, which machine decides, what a client may report, and how strict the check is. Revisit it at each milestone, because new features add new rows.
Once players are in, count rejected inputs per rule, per week. A rule that never rejects anything may be checking too little. A sudden spike often points to a bug in a recent build or a new cheat, and either is worth knowing before players report it.
Full authority does not need a heavyweight server. On Edgegap, fractional vCPU sizing helps keep a headless authoritative server cost-effective for many kinds of games, and a game server built to host several rooms can share one deployment. Placing servers near players helps keep the round trip each decision adds short.
Philip Coté, CTO
,
