There's an arcade game where you stand over a row of holes with a mallet. A mole pops up, you hit it, and another appears somewhere else. You can get very good at it. You never run out of moles.
Building a racing game around the assumption that every player's computer can be made trustworthy risks turning security into that job. Find a cheat. Detect it. Block it. Wait for the next version.
We want immediate steering and precise drift timing. We also want to avoid making a deeply intrusive anti-cheat system the foundation of fair play. That helped lead us to mixed authority: keep ordinary movement responsive on your computer, and give the server ownership of important parts of the race.
The appeal of letting your computer drive
Classic KartRider is a natural reference for us. The attraction of that style of locally controlled racing is easy to understand: your kart belongs to your hands. A drift doesn't have to wait for a distant machine to answer.
But there are two separate decisions hidden inside a discussion about “P2P netcode.” Peer-to-peer describes how computers exchange information. Authority describes whose answer the game accepts. A server can forward messages while still trusting everything a player reports. A peer-to-peer design can include checks of its own.
The approach we wanted to move away from was giving each player's computer the final word on both its movement and the resources it claims to have earned. That trust decision matters more than whether a message travels directly to another racer or passes through a server.
The problem with taking everyone's word for it
Your computer is under your control. A modified game can make claims that an ordinary game would never make: more boost than it earned, a movement that its inputs don't justify, a different outcome from the same rules.
If the rest of the race accepts those claims as truth, detecting the modified game becomes a major part of defending the rules. The question shifts from “was this action valid?” to “can we prove this player's machine is running exactly what we intended?”
That puts pressure on anti-cheat to inspect more deeply. Some systems operate at the operating system's kernel level, with privileges well beyond those of an ordinary game. Riot's explanation of Vanguard's security architecture describes using a kernel driver to validate memory and system state, and acknowledges the security and privacy concerns that choice raises.
That is a substantial thing to ask someone to install for a race. It brings responsibility for security, compatibility, support, and player trust alongside the job of catching cheats.
P2P does not inherently require a kernel driver. Nor does choosing a server make anti-cheat unnecessary. Our concern is the dependence: the more decisive state we accept from a player's computer, the more we have riding on keeping that computer honest.
A bigger mallet still leaves you playing
Strong anti-cheat can make cheating harder and reduce its impact. It doesn't provide a permanent guarantee that every connected player is honest.
Riot's 2026 Vanguard update discusses continuing enforcement against internal and kernel cheats alongside new defensive measures. Even a dedicated anti-cheat operation keeps adapting as attackers change their approach.
That's the whack-a-mole problem. It isn't that detection is useless. It's that detection is ongoing work, and a successful bypass can matter before it gets caught. More access to a player's machine doesn't turn that process into a finished task.
We'd rather reduce how much damage a false claim can do in the first place. Where the server can own a rule, it can check that rule without first identifying the particular cheat that tried to break it.
Split the responsibility
In our mixed model, your computer drives your kart and reports its physical state. The server compares that movement with its own continuation from previously accepted state and inputs. Ordinary disagreement is tolerated; larger deviations are limited or refused.
That tolerance matters. A late update, a predicted contact, or a recovery happening a little differently shouldn't make you fight a correction through every corner.
The server also maintains the drift and boost state that determines what you earn and spend. Your computer predicts those changes so the response is immediate, but a reported boost balance doesn't become true just because your computer says it is.
The server manages the shared race lifecycle too: the start, room membership, race timing, standings, and bots. Keeping standings there gives the race a common organizer; it does not make every client-influenced movement used to calculate them trustworthy.
The useful distinction is between predicting something for responsiveness and having the final say over it. Your computer can show a boost immediately while the server independently tracks whether that boost was available.
Who gets the final say?
Local responsiveness and shared rules have different owners.
Drive now.
- Responds to steering and drift immediately
- Determines your local contact response
- Reports physical movement for checking
- Predicts boost feedback while awaiting confirmation
Keep the ledger.
- Independently tracks drift and boost resources
- Limits or refuses large movement deviations
- Owns the start, timing, membership, and bots
- Calculates standings from accepted trajectories
Client → movement + inputs
Server → accepted state + resource corrections
Why not give the server everything?
Full server authority is a valid choice, and we support it. It can still use local prediction, so it doesn't require delayed steering. The cost is that when the local prediction and the server disagree, the server's movement wins and the player gets corrected.
For private races, we chose a different balance. Mixed authority leaves ordinary local movement alone more often while retaining checks and server-owned resources. It preserves more of the direct driving feel we want without delegating every important decision to each player's computer.
That also means accepting limits. Server simulation costs resources, latency still exists, and a movement check needs enough tolerance to avoid treating ordinary disagreement as misconduct.
What mixed authority doesn't solve
Mixed authority is still a trust mode. Small, persistent movement advantages can stay inside its allowance. Human contact responses remain locally determined. A server-owned boost balance doesn't make the entire race cheat-proof, and server-owned standings still depend on the trajectory the server accepts.
That's why mixed rooms are join-by-code, intended for trusted groups. Publicly listed rooms use server authority. We are not presenting mixed authority as a shortcut to fully enforced competitive racing.
Even stronger server ownership doesn't automatically identify someone using assistance to choose otherwise valid inputs. Validation, detection, and moderation address different parts of the problem. None becomes universally unnecessary because we picked a networking model.
The race we want to build
Choosing mixed authority lets us put responsiveness and enforcement in different places deliberately. Your computer handles the immediate act of driving. The server owns resources and shared race rules, and checks how far reported movement strays.
It leaves work to do, and trust to be honest about. But it gives us a way to reject some false claims through the rules themselves, instead of making every defense depend on finding one more mole on somebody else's computer.
We want to spend more of our effort making the next corner worth taking. Deciding what the server owns is part of making that possible.