You have no idea what you're talking about in this regard and it shows. What you're suggesting essentially amounts to a complete rewrite of the cast server to introduce logic that has never been there before. You're asking a small development team to rethink how everything should work. Let me give you one simple example so that you hopefully see why this makes no sense on so many levels. Suppose you've just hit someone with a rifle bullet. In the current state of things, the game sends a packet to the cast server which then forwards it to the room's host. Upon receival of that packet, the host processes it and sends a packet to the cast server that will be broadcast to all playing users in the room, notifying them of that bullet hit with information on how much damage was dealt. This is obviously a very flawed design that leaves a pretty large attack surface, so let's think of a way we could partially solve this. Maybe the host should verify that the player who fired the bullet was actually aiming at the target (and is within their line of sight)? This is definitely not an option because it would mean that hit registration now depends on the host's simulation of the game. If the host sees something slightly different the hit won't register and it's going to make the gameplay feel terrible at best for everyone else. The fact movement packets are not handled by the host but only by the cast server itself is pretty much incontrovertible evidence of this. So then maybe the cast server should handle hit registration? Surely if the cast server is the only source of truth and maintains a simulation of the game, it can take all of these decisions and the host becomes a non-factor. Another way to phrase this: you've just asked a very small team to tackle one of the most complex issues in game development using an engine that doesn't support networking. Even though there's been quite a bit of literature on the subject ever since Quake 3 pioneered it, these days it's more than unlikely you wouldn't use something like Unreal Engine that already has a battle-tested server authoritative networking model. The first roadblock you hit if you want to make the cast server simulate the game is that all MV servers run on Linux, and Gamebryo is a Windows-only engine. So you'd need to recompile the cast server for Windows, which will result in a ton of side effects on the deployment infrastructure. The second roadblock you hit is a programming issue: you would have to refactor the all the code that deals with simulating the game into a different library that the cast server can link to. You then have to implement a snapshot delta system and set up tooling that allows you to compare what's happening on the server with what's happening on the client. And you also have to rewrite a significant portion of the game client to account for these changes. You can't let a single cast server handle every single room (think of it as running one MV client per room in a single process) so you need a fleet of cast servers now. Every time you join a game you may have to connect to a different one, which means even more rewrites on the client and server side. I've barely scratched the surface here but if you still think doing away with cheating on MV is a viable endeavor I don't know what to tell you. It's just unimaginable levels of delusion. You can always implement these soft file integrity checks but it only takes one person with half a brain and too much free time on their hands will bypass these and release a public cheat that can completely ruin the game. I would assume the devs figured out how deep rooted these issues are and settled with a more pragmatic approach - a report system and an anticheat they already have a wrapper for.