Every multiplayer game has to answer the same question:
How much should the client be trusted?
The answer is usually somewhere between "not at all" and "only when the server can verify it."
That approach has worked well for years, but while working on GameSecure I found myself asking a different question.
Instead of making either the client or the server responsible for every verification, could gameplay evidence be processed through an independent validation pipeline before the game decides how to respond?
That question led me to design the architecture below.
The diagram isn't meant to replace traditional anti-cheat techniques. Instead, it shows how gameplay verification can become a separate system that operates alongside the game itself.
The Client Doesn't Decide
From the player's perspective, nothing changes.
The player launches the game and connects to the multiplayer server as usual.
Behind the scenes, however, a lightweight SDK inside the client receives verification instructions from the game server.
Rather than embedding every verification rule directly into the game, the server can describe what information should be collected for the current session.
The SDK simply follows those instructions and produces a verification result.
At this point, no cheating decision has been made.
Only evidence has been collected.
Building a Verification Package
Once the server receives the SDK's response, it combines that information with additional session identifiers before creating a verification package.
The package contains everything required to verify a specific gameplay event while remaining tied to the correct player and match.
Instead of evaluating the package immediately, the server forwards it into an independent validation network.
The server's responsibility is to prepare the evidence—not to determine the outcome.
Independent Verification
Every verification package is processed by multiple validation nodes.
Each validator independently evaluates the task and produces its own result.
Because multiple validators examine the same package, the system is designed around agreement rather than a single authority.
The objective isn't to eliminate trust entirely, but to avoid depending on one machine to make every verification decision.
Returning Confidence Instead of Punishment
One design decision I intentionally made was separating verification from enforcement.
The validation network doesn't ban players.
It doesn't kick them from matches.
It doesn't decide moderation policy.
Instead, it returns a suspicion level that reflects how confidently the verification pipeline believes a gameplay event deserves attention.
What happens next is entirely controlled by the game developer.
One game might simply record the event for later review.
Another might increase monitoring.
Another could move the player into a separate matchmaking pool.
Others may choose temporary or permanent account actions.
The anti-cheat supplies evidence.
The game decides the response.
Why Separate Those Responsibilities?
I think anti-cheat systems often become tightly coupled with punishment systems.
Combining those responsibilities works, but it also means detection logic and moderation policy become intertwined.
Keeping them separate makes each component easier to reason about.
The verification pipeline focuses on producing reliable evidence.
The game focuses on deciding what should happen with that evidence.
Different games have different communities, different moderation standards, and different tolerances for false positives.
A single enforcement policy rarely fits every game.
Still an Ongoing Experiment
This architecture is still evolving.
Some components are already functioning, while others are still being refined as I continue experimenting with distributed validation, networking, and system design.
Whether this ultimately becomes a practical production solution remains an open question.
For me, that's part of what makes the project interesting.
Sometimes the most valuable software projects aren't the ones that immediately solve a problem—they're the ones that encourage you to question assumptions that have existed for years.
If you've worked on multiplayer networking, distributed systems, or game security, I'd be interested to hear how you would approach this problem differently.
Top comments (0)