Paladium is one of the biggest Minecraft servers in France, running since 2015, with more than 700,000 unique players and up to 6,000 concurrent connections. Like any server that grows, we've had to deal with cheating at scale. Nemesis is our answer to that problem, built in-house rather than bought off the shelf. This article pops the hood and breaks down how it works.
Cheating on Minecraft
Minecraft trusts the client by default. When a player's game reports a position, the server just records it, without really asking whether that movement was even possible. Combat works the same way: the client says it hit someone, and the server applies the damage. Speed, reach, attack speed, all of it rests on whatever the client chooses to report.
And the game is written in Java, a language with no built-in security model. Its code can be opened and modified directly. You can also leave the files untouched and inject code into an already-running session instead. Or skip the game process entirely and run something external that reads what's happening and acts on the player's behalf.
Two ways to look at the problem
Anti-cheat boils down to two questions.
Is what the player is doing physically possible? The server continuously watches speed, reaction time, and precision, checking that all of it stays within what a human being can actually do.
Can the player's machine be trusted? We continuously check the integrity of the running game, to make sure no cheat is showing the player information they shouldn't have, even without touching a single movement.
Most servers don't have the ability to interact with the client the way we do. Paladium runs its own launcher, and that changes everything. So Nemesis can answer both questions, not just the first one.
From a simple mod to hardware
Cheating ranges from very simple to very advanced.
- Modified client. The most common route: extra mods bolted on for an advantage, built with the exact same tools as any legitimate mod.
- Injection. The game files on disk are never touched. A library gets loaded into an already-running session on the fly, the same injection technique used by perfectly legitimate mods.
- Native cheats. Low-level code outside Java itself, wired into the game through the bridge Java provides for native code (JNI). Harder to write, and harder to catch with the usual Java-side detection tools.
- External memory reading. A fully separate program that reads and writes the game's memory directly from outside, without ever running inside it, just like any regular user-mode application.
- Kernel driver. The same idea, but from a system driver running with the same privileges as the OS itself, invisible to most conventional security software.
- Dedicated hardware. A card physically plugged into the machine that reads memory straight off the bus, what's known as DMA, without ever executing a single line of code on the targeted computer.
The philosophy
One philosophy runs through all of Nemesis, server side and client side alike: block first, worry about punishment later. It plays out in stages. First, we try to stop the cheat from working at all: make the movement impossible, drop the packet, kill the effect rather than just flag it. If a cheat runs too deep to be cleanly blocked, the game closes instead of continuing to run in a state we can no longer vouch for. A sanction only comes as a last resort, once none of that was enough. The goal is to avoid punishing a player who was simply curious enough to try a public cheat found online, without doing anything specifically targeted at Paladium.
Our anti X-ray protection is a concrete example of this blocking philosophy on the server side. Normally, a player's game receives the data for every block around them all at once, including buried ones they can't see, ores included. An X-ray cheat just has to read that data the game already holds and show the hidden ore. With Nemesis, every ore in a chunk reaches the client disguised as plain stone, and the server only sends the real block once it actually becomes visible to the player's eyes. There's nothing for the cheat to read: the information doesn't exist on its end yet.
There's an extra technical wrinkle behind that. So latency doesn't create a visible lag the moment a block becomes visible, the server predicts ahead of time. It forecasts the player's trajectory and speed, lists every ore they could end up seeing, and sends it early into a secured zone of the client's memory. The switch from stone to ore then happens directly inside the game, at the right moment, with no perceptible delay. And on the security side, even if an X-ray cheat managed to dig through that zone, it would only ever see the ore right around that player, and only for a very short window.
Our autoclicker protection follows the same blocking logic, this time on the client side, for every click that counts in combat. A click isn't just counted or timed after the fact, it has to be proven the moment it happens. We identify the origin of that click at the lowest level possible, to tell a real move on the mouse apart from a click generated or injected by a script. That click then gets signed and tied precisely to the attack it triggers, before being sent to the server alongside the hit. For every hit landed, the server checks that this signature is valid and matches that exact attack. If it's missing, doesn't match, or arrives too late, the attack gets cancelled before it's even applied, the same way an impossible movement would be.
That signature only holds for that one click, on that one target, at that one instant. There's no way to precompute it ahead of time or replay it for a different hit.
What we watch on the server side
This part runs entirely server side, without asking anything of the client, and answers the first question from earlier: is what the player is doing physically possible?
The principle is simple. From every packet the player sends, the server builds a digital twin of their client and simulates it in parallel to check it's actually following the game's rules. This isn't just movement math, it's a real end-to-end simulation.
Concretely, it's an actual game running in parallel, minus the rendering. Ping, TPS (ticks per second), movement, interactions, all of it gets simulated. Think of it as a second server, with every player on it, continuously comparing each player to their own clone. This layer often acts as a safety net for whatever the client missed, but to keep false positives down, despite an already very low error rate, it still goes through manual review before a sanction in the vast majority of cases.
What we watch on the client side
That leaves the second question from earlier: can the player's machine be trusted? Here we're no longer just looking at the packets the game sends, we're looking at its actual state while it runs.
Going back to the spectrum from earlier, here's a simplified example for each level:
- Modified client. Everything running inside the game should match something we know and expect. An unknown or modified mod on a player's machine is a signal.
- Injection. We look at what's actually loaded into the game's process, not just what was launched at startup. Code that shows up after the fact, without going through normal loading, is a signal.
- Native cheats. When the game talks to native code, we monitor that exchange. A call that has no business being there is a signal.
- External memory reading. We keep an eye on who's reading the game's memory from outside. If an access doesn't legitimately come from the game itself, that's a signal.
- Kernel driver / dedicated hardware (DMA). Kernel driver or a card physically plugged into the machine, same fight either way: whoever's behind it has full control over the memory the game runs in, which gives us plenty to detect anything touching it. That runs through several checks, including encrypted copies and integrity hashes that reveal at any moment whether a region was modified, or even simply read, try/catch blocks that react to the slightest suspicious access, and honeypots: zones deliberately exposed to trap anyone poking around.
These are deliberately simplified examples. In reality, Nemesis ships more than 40 distinct detection vectors, updated daily. And it's almost never black and white. Most of the time, a detection is a score built up from multiple signals, with hundreds of micro-factors feeding into each one.
How It Works
Everything we just described on the client side, the mods, the injection, the native calls, the memory, has to be checked by something reliable, something that can hold up to analysis over time. That's the job of a dedicated virtual machine.
In practice, it's not a single program running, it's a two-stage system. A primary VM, itself polymorphic, changes the moment the game launches and keeps evolving throughout the session through a stream of derivations. Its only job is to load and run a second VM, generated completely from scratch every time, that only the primary VM knows how to interpret. Once that second VM is in place, Nemesis's checks run as code packed inside what we call a stub, a small loader that's polymorphic too.
Before running any check, that stub re-verifies that the environment hasn't been compromised in the meantime. It then decrypts the real code, runs it, and immediately wipes it from memory, never leaving it in clear for more than a few milliseconds, before sending the result back to the server if needed.
To give a sense of the style, without showing the actual instructions (that part stays ours). None of this ever exists in clear text in reality. These are compiled instructions, never text you could read directly, and the instruction set itself changes on every execution. The example below is deliberately kept readable and commented to illustrate the logic, with made-up instruction names for the occasion:
; --- Primary VM ---
IMM R0, secondary_vm_blob ; puts the address of the secondary VM's encrypted blob into R0
SPAWN R1, R0 ; spins up a VM from that blob and hands off control to it
; --- Secondary VM (a different instruction set, unique to this VM) ---
UPK R2, R1 ; unpacks the stub embedded in the received blob
XQT R2 ; starts running the stub
; --- Stub ---
KFETCH R3, slot_a ; fetches one key fragment, source 1
KFETCH R4, slot_b ; fetches one key fragment, source 2
KFETCH R5, slot_c ; fetches one key fragment, source 3
KFETCH R6, slot_d ; fetches one key fragment, source 4
KFETCH R7, slot_e ; fetches one key fragment, source 5
KMERGE R8, R3, R4, R5, R6, R7 ; recombines the 5 fragments into a single key
DECRYPT R9, payload, R8 ; decrypts the real payload with that key
EXEC R9 ; runs the decrypted code
WIPE R9 ; immediately wipes the result from memory
All of this travels over our own communication protocol, which we call NemesisLink. At connection time, several key exchanges take place between the client and the server. From there, every message first gets encoded, then encrypted using a set of derivation keys computed from the actions actually performed in game. That means the key shifts with context, not just with time. The payload encryption itself runs on AES-GCM, executed directly through the CPU's hardware AES-NI instructions.
There's also a whole side dedicated to protecting Nemesis itself, not just to catching cheats. Multi-layered anti-debug, so nobody can attach a debugger and watch it run. Anti-VM, to spot when the game is running inside a virtual machine instead of a real one. And enumeration of external processes, to know what's running alongside the game and flag known analysis or cheat tools.
What we watch for duplicate accounts
A ban that gets wiped out just by making a new account is worthless. This section answers that exact question: how do you tell that two different accounts are actually the same player? Detection relies on a score that aggregates a large number of vectors, hardware and software, cross-referenced together rather than judged one by one.
On the hardware side, the idea is to tie a sanction to the machine, not just the account. There's first a real list of classic identifiers: the disk, the motherboard, and about a dozen other components in total. Nothing exotic, it's the kind of HWID most serious anti-cheats already use.
Then there's a more advanced layer, currently being tested with a subset of players, built on a real academic research concept: PUF (Physically Unclonable Function). Even two strictly identical components off the same production line are never perfectly identical at the physical level. Manufacturing tolerances create micro-variations that are invisible to the eye but measurable electrically. For RAM, that translates into two approaches known in the literature: measuring how long a memory cell naturally takes to decay once refreshing stops, or measuring micro-latencies in read and write access. In both cases, the result depends directly on the real electrical properties of that specific stick's transistors, impossible to reproduce elsewhere in software. Same logic applies to microphones. Every microphone has a slightly different frequency response, due to manufacturing tolerances in its membrane and capsule. By capturing a short audio sample and analyzing that response curve, you get a signature unique to that exact microphone unit, even against a strictly identical model off the same production line. In both cases, it's a fingerprint that doesn't change when you reinstall Windows or make a new account, it's literally etched into the hardware. RAM and microphones are only the visible tip of this research. Behind it, we're digging into the deepest workings of a machine, doing real research work, to invent identifiers that genuinely don't exist anywhere else.
Small fun fact: one of these tests ended up frying a graphics card, a dev card where that risk was expected and accepted going in. We test for real, under real conditions, on paths that are barely documented, if at all. That's exactly the kind of work that pushes Nemesis to the highest level it can reach. And to be clear, there was never the slightest risk to players in any of this: nothing like this ever reaches production before going through a whole series of test stages.
On the network side, we don't just compare two identical IP addresses. Correlation happens through geolocation and a probability score. Accounts that regularly connect from geographically consistent areas carry more weight in the score than a simple IP coincidence. We also detect non-residential IPs, typically VPNs or proxies used to mask a connection. And there's everything else stacked on top: an account's username and skin history, its creation date, whether it's already connected to other servers, and even playstyle itself, since the same player tends to keep their habits from one account to another. Taken individually, none of these signals is enough, but stacked together, they push the analysis a long way. An account that checks too many of these boxes gets automatically flagged, placed under watch, subjected to deeper manual analysis, and can end up under invisible restrictions or random tests, without ever knowing it.
We're confident enough in this system that we've actually turned off IP bans. We only sanction by hardware fingerprint now, which guarantees the best level of security without ever penalizing an entire household or a player who inherits an IP their provider reassigned.
From detection to sanction
This is the part players experience most directly, let's be honest about that. As covered above, the system blocks before it sanctions, and a detection doesn't ban anyone automatically by default. Before a vector earns the right to sanction without human involvement, it goes through a validation phase that can last several months: tuning, testing against real cases, long-term observation. The bar is strict, at least one full consecutive month without a single false positive before any automation. And nothing is set in stone. For maintenance, updates, and security reasons, detections get pulled, temporarily disabled, or added, on a schedule that isn't always predictable. The system changes almost every day without any of it showing on the outside.
The delay between detection and sanction ranges from near-instant to about 24 hours, depending on the severity of the case combined with a random factor. That randomness stops cheat developers from correlating the timing of a sanction with whatever triggered it. A fixed delay after the same type of action would tell them exactly what got caught. Near-instant sanctions are reserved for cases that pose a direct risk to other players' experience, for example a cheater about to kill or loot another player. In that case, protecting that other player in real time outweighs protection against correlation. The real condition is more complex than this simplified example: plenty of factors come into play to keep security intact regardless, but the goal is always to find the right balance.
The result: over more than a year of real-world use, a false positive rate close to zero. We're not claiming perfection, nobody honestly can. But at the slightest doubt, a case goes to human review instead of automation. It's slower, and we accept that trade-off. A wrongly banned player costs far more in trust than the time spent double-checking.
And if a sanction gets appealed, we don't just take our own word for it. Every detection log is kept, and anonymized. They preserve the technical context of the case, what triggered the detection and under what conditions, detached from the player's identity. When an appeal comes in, we pull the case back up entirely from those logs, replay what the system saw, and re-verify every step, with a human in charge. If the detection holds up, the sanction stands. If something's off, it gets reversed.
By the numbers
Over the last six months:
- 8,900 detections, across all vectors combined (several can involve the same player).
- 1,124 automatic sanctions, applied without human involvement.
- 2,020 total bans for cheating, since the system went live.
- An average detection time of 193 seconds.
On the engineering side, across Nemesis as a whole: 1,500+ commits, for more than 57,000 lines of code in total.
What's next
The direction for what comes next: a program completely separate from the game itself, with a component running at kernel level, meaning the same privilege level as the OS. It's the path the most advanced anti-cheats on other games have taken (Vanguard at Riot, EasyAntiCheat, BattlEye), for a simple reason. At that level, you see the machine's real state without depending on what Windows or a user-mode program is willing to show you, and the component can be active before the game even launches.
A program separated from the game at that privilege level removes constraints that are inherent to any check running in the same process as whatever it's monitoring. Right now, this is a research and development effort. It won't push detection quality any higher, that's already where it needs to be. What it will mainly do is make the long-term engineering work simpler, built to last.
Transparency
We're publishing this article because trust is earned by showing the work, not by promising it, and Paladium's players have the right to understand, at least broadly, what's running on their machine. There's another reason too: very few projects at this depth get documented publicly, and we think the engineering behind Nemesis is worth sharing with anyone who cares about this kind of work, on Minecraft or elsewhere. We're proud of what we built. We believe Nemesis is, today, the best Minecraft anti-cheat out there. That's an opinion, and we own it. And we felt it was worth telling that story, even in part.
We don't intend to stop here. In the medium term, we plan to set up an external audit program: people outside Paladium who will come verify what we're claiming here, on a regular basis. In the long term, we're also thinking about opening more of this up to a wider audience. Nothing concrete to announce yet, just an intention: making this subject more accessible and more shared.
Thanks
Thanks to Paladium for the trust and for the opportunity to lead a project like this from day one.
This article isn't an incitement to cheat, nor a provocation aimed at anyone. We're simply documenting what we built, because we love this work and wanted to share it.
