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. In this article, we're popping the hood and showing you 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, your game receives the data for every block around you all at once, including buried ones you can't see, ores included. An X-ray cheat just has to read that data your game already holds and show you the hidden ore. With Nemesis, every ore in a chunk reaches you disguised as plain stone, and the server only sends the real block once it actually becomes visible to your 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 your latency doesn't create a visible lag the moment a block becomes visible, the server predicts ahead of time. It forecasts your trajectory and speed, lists every ore you could end up seeing, and sends it early into a secured zone of your client's memory. The switch from stone to ore then happens directly inside your 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 you, and only for a very short window.
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.
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, a classic move for anyone who wants to analyze it safely without risking their own machine. And enumeration of external processes, to know what's running alongside the game and flag known analysis or cheat tools.
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.
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 today because Paladium's players have the right to understand, at least broadly, what's running on their machine. Trust is earned by showing the work, not by promising it. We're also publishing it because 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.
Top comments (0)