The thing you cannot add later
Nothing in this post is built yet. It is the next thing, and the reason it is next is worth writing down.
The cheat that anti-cheat does not catch
Real-money trading is someone playing the game as a job. They farm loot, and they sell it to a player who would rather pay than play. Nothing about it looks like cheating from inside a raid. There is no aimbot to detect, no wallhack, no impossible movement. Someone is just looting, efficiently, for eleven hours a day.
You cannot catch that by watching one player. You catch it by looking at the economy from above and asking which accounts are outliers. Items of a given rarity entering the world per hour, per account. A farming crew is a spike in a distribution, and it shows up there long before any client-side detection would find it.
That query needs a record. Right now there isn't one.
What is happening today, unrecorded
Containers open. Items move into inventories. Corpses get stripped. Players extract carrying things. All of that works, and none of it is written down anywhere.
Which is the actual urgency. It is not that the journal is hard, or valuable in some abstract way. It is that every raid played before it exists is an audit gap that cannot be backfilled. There is no version of adding this later that recovers the history. The events either got recorded when they happened or they are gone.
That is an unusual property for a feature. Most things can be added when they become the priority. This one has a cost that accrues quietly in the meantime.
The ordering that has to be right
The design is genuinely boring: append a line to a file when something moves. One decision in it matters.
The write has to happen before the client is told the item moved, not after.
Get that backwards and there is a window: the server tells you the item is yours, then dies before recording it. On restart the item is in your inventory and still in the container. It has been duplicated, and duplication is permanent. The item exists now, forever, and no later fix removes it.
So the order is validate, move the item, write the journal, then acknowledge. Those last two cannot swap places, and the comment saying so goes next to the code rather than in a design document nobody reads while editing.
There is a second question that looks the same and is not. Writing to disk properly on every single entry is too slow to sit inside a tick, so entries get buffered and flushed on a timer. That means a hard crash loses the last fraction of a second of the log.
Which is fine, and it is worth being precise about why. Losing a few entries costs some history for one raid. Losing the order of entries makes the whole file useless for the only queries it exists to answer. Durability is negotiable here. Ordering is not.
Who the log is allowed to know about
The journal records who did what. It deliberately does not record who they are.
Player identity inside a raid is a temporary number that means nothing outside that raid and is not the same number next time. That is not incidental: an attacker who can correlate identities across raids can reliably queue an account alongside a second account they control and hand gear over. Ephemeral IDs make that luck rather than logistics.
So the journal stores the temporary number, and connecting it to an account happens elsewhere, in a service the game server cannot reach. The game server never learns who you are.
This is the easiest part of the whole design to quietly break. Writing the account ID straight into the log would make every aggregate query simpler, and it would undo the reason the indirection exists in the first place.
What it does not do
It is not anti-cheat. It finds patterns after the fact, and it stops nothing while a raid is running.
It also has a consequence worth naming before it exists rather than after: a journal is a record of what players did, and once accounts exist it becomes joinable to actual people. How long any of it is kept is a question that should be answered before there is anything to keep.