FiveM Server
Audit LogAn admin script that audits itself — Watchtower Admin
What a FiveM server audit log is
A FiveM server audit log records every privileged staff action — money and item grants, teleports, bans, ownership edits — as an append-only entry with the actor, the target, the time, and a reference to what changed. The best admin scripts enforce permissions on the server rather than by hiding menu buttons, keep the log where the person who wrote it cannot edit it, and log their own use so the auditor is audited too. Watchtower Admin is Vice Drip's version: in development, no runtime proof published, no purchase path.
The question is not what an admin can do. It is what happened, who did it, and whether the log can be edited by the person who would want to edit it.
Admin tools are the most powerful code on a server and the least audited. The question that matters isn't what an admin can do — it's what happened, who did it, and whether the log can be edited by the person who'd want to edit it. The second half of the problem is that a staff-corruption accusation is currently unanswerable in both directions: the owner cannot prove the money moved, and the accused staff member cannot prove it didn't, so the outcome turns on who is more trusted rather than on what occurred.
Status honesty: Watchtower Admin is in development. There is no runtime proof published — pending Shadow bench, so no performance claim on this page rests on a number. The price shown is a planned band pending the studio pricing lock, not an offer. There is no purchase path on this page.
Server-authorised, append-only, self-auditing, tamper-evident.
Four design commitments that decide whether a staff log is a record or a diary. Stated as our reasoning and our design intent — nothing here is a demonstrated capability yet.
Who audits the auditor?
Most admin logs are written by the admin tool into a table the admin tool owns, with a delete button next to each row. That means the one person with a motive to erase an entry — the staff member who made it — is also the one with the access. The design here is that the audit trail is not editable from inside the tool that writes it. Watchtower's own actions, including reading the log, are logged the same way as everyone else's.
A hidden button is not a permission
Menus that hide options from low-rank staff are checking permission on the client. The net event behind the button is still reachable, and a modified client will call it. Every privileged action is designed to be authorised on the server — source, permission, rate limit, argument types — before it does anything, regardless of what the menu showed.
Append-only, then searchable
An audit log is only useful if it can answer a question. 'Who gave this player $200,000 last Tuesday?' should be a query across the money ledger, not a scroll through a Discord webhook channel. The design intent is append-only entries that are indexed and searchable across products, so a dispute is replayed from the record rather than adjudicated from memory.
Tamper-evident, not tamper-proof
No resource can stop a database owner running DELETE. What an audit trail can do is make removal visible: sequential entry numbering, actor on every row, and cross-references to the ledger it describes, so a missing entry leaves a hole shaped like itself. We say tamper-evident and would treat 'tamper-proof' from any vendor as a claim to be disproved.
Why we are building it
We publish a standard that says claims should be checkable. An admin tool is where that standard gets tested on ourselves: a menu that can grant items and money without an immutable trail is the single largest unaudited surface most servers run. The design decision we think matters most is that it reads rather than writes — an oversight desk that can also move money is another money path to secure, and the whole point of the thing is to be the surface that watches the money paths, not one of them.
Designed to
- Designed so every privileged action writes an append-only audit entry into the same record the tool itself reads, which is what makes a staff-conduct complaint answerable in either direction.
- Designed so the audit trail is not editable from inside the tool that writes it. Tamper-evident by construction, never absolute — a claim of absolute is a claim nobody can keep.
- Designed for permission checks on the server, never on the menu — a hidden button is not a permission, and a client that can call the event does not care what the menu showed it.
- Designed as a read layer over each product's own audit tables rather than a second copy of them, so there is no central table to fall out of sync with the ledgers it is supposed to be evidence about.
- Designed to say when it cannot see something. A product you do not run, or one outside the caller's scope, should be reported as excluded from a search rather than quietly producing a shorter list.
What breaks in a typical admin script.
Failure modes of the mechanism, described generically. These are not claims about any named product — we have not audited anyone else's code, so we compare criteria and never rivals.
The log lives in a webhook
Staff actions posted to a chat channel are a notification, not a record. They cannot be queried, they can be deleted by anyone with channel permissions, and they say nothing about what the money ledger actually did.
Client-side permission checks
A menu that hides the 'give money' button from moderators has not removed the event that gives money. Anyone who can trigger the event directly has every permission the menu pretended to withhold.
The admin who edits the admin log
If the same rank that can grant items can also delete the grant entry, the log records only what staff chose to leave in it. The audit trail becomes a diary.
Actions without a ledger reference
'Admin X gave Player Y money' is only half a fact. Without a reference to the ledger row it created, you cannot check the log against the economy — or the economy against the log.
No search, only scroll
A log with ten thousand rows and no index answers nothing. When a dupe is suspected, staff need every money movement touching one player in one query, not a night of reading.
One tool per product
Banking has its logs, the garage has its logs, evidence has its logs, all in different shapes. The question 'what did this player do tonight?' spans all of them, and nothing joins them.
Open vs escrow — the disclosure
The intent for Watchtower is an escrowed core with the full config surface, locales, framework bridge glue and public exports shipping open. For an admin tool we consider the permission model part of what you must be able to read, and the file-level manifest that settles exactly what is open publishes with the release. Nothing ships today, so no manifest exists yet.
What is not proven
- It is not released and not purchasable. There is nothing to buy or download.
- No runtime proof published — pending Shadow bench. 'The auditor is itself audited' is the entire pitch and it is, today, an unproven claim about software you cannot inspect.
- No resmon figure — [MEASURED-PENDING]. A search across several products' history is a database-shaped cost, and we have not measured it.
- $39.99 is a planned target, not a commitment until the studio pricing lock.
- No release date.
- Runtime proof status, in our own words: no runtime proof published — pending Shadow bench.
Four questions an audit log exists to answer.
The dupe investigation
A player's balance doubled overnight. Staff search every money movement touching that account across products, find the two transfers that should have been one, and replay the sequence with timestamps.
The staff-abuse complaint
A player claims an admin spawned a car for a friend. The grant is either in the log with an actor and a time, or it is not — and if it is not, the absence is itself evidence, because the log is designed so that removal is visible.
The ownership dispute
Two players both claim a vehicle. The title history is read from the garage's record, the money that changed hands from the ledger, and the answer is a query rather than a staff argument.
The auditor's own review
Senior staff review what the admin team did this week — including what the audit tool itself was used for. Reads are logged, so 'who looked at whose records' is answerable too.
Request → authorise → execute → record → search → review.
How a privileged action becomes an auditable fact, in order. The client appears once, at step one, and decides nothing.
- 01RequestA staff member triggers an action from the tool. The client sends a request; it does not decide anything.
- 02AuthoriseThe server checks source, permission, rate limit and argument types. A failed check is itself logged — attempted actions matter as much as successful ones.
- 03ExecuteThe action runs against the owning product — a ledger transfer in MoneyTrail, a title change in the garage — through that product's own server-authoritative path, never by writing its tables directly.
- 04RecordAn append-only audit entry is written with actor, target, time, arguments and a reference to the row the action created. Designed so nothing in the tool can edit or delete it.
- 05SearchEntries are indexed so a dispute can be replayed across products in one query: by player, by admin, by time window, by amount.
- 06ReviewReads of the audit log are logged too. The auditor is audited by the same mechanism, which is the only honest answer to 'who watches the watchers'.
The criteria that decide an admin script.
No vendor column and no scores. We have not audited anyone else's code, so ranking rivals would be invented precision — and on the runtime row we would fail our own criteria today. Take these eight questions to every option you shortlist, ours included.
| Criterion | Why it matters for staff tools | What to ask |
|---|---|---|
| Server authority | An admin script is the most powerful code on the server. If its permission checks live in the menu, every player with a modified client is an admin. | Is every privileged event authorised on the server — source, permission, rate limit, argument types — independent of what the menu shows? |
| Framework support | Admin tools reach into identity, money, inventory and jobs — the exact places Qbox, QBCore and ESX differ. A bridge that is only tested on one framework is a bridge to one framework. | Which frameworks are tested targets per release, and which are inherited compatibility branches? |
| Escrow split | You are buying the tool that governs your staff. If the permission model is escrowed, you cannot verify it does what the seller says it does. | Which files ship open and which ship escrowed, as a file-level manifest, and is the permission model readable? |
| Dependencies | An audit tool that reads across products depends on those products exposing their records. Cfx advises researching a resource's dependencies before installing it. | Which products can it actually read, through what export or table, and what does it show when one of them is absent? |
| Data portability | The audit log is your server's institutional memory. If it lives in a format only the vendor's tool can read, replacing the tool means losing the history. | Is the audit schema documented, and can you query and export it with plain SQL? |
| Runtime proof | Search across products at scale is where an admin tool can get expensive. Ours currently reads: no runtime proof published — pending Shadow bench. | What was measured, on what hardware, at what player count and log size, on what date, by what method? |
| Support SLA | A broken admin tool blocks every other incident from being resolved. Its response window matters more than most. | Is there a written first-response window and a hotfix window for severity-1 issues? |
| Changelog | A silent change to what gets logged, or who can delete, changes the meaning of every entry after it. | Is there a public, dated changelog that names breaking changes to the audit schema or permission model? |
What to verify before buying a FiveM admin script.
Seven questions, useful even if you never buy from us. For platform facts — asset escrow, server-side events, the resource manifest — read the official Cfx documentation at docs.fivem.net rather than a seller's summary of it.
Ask who can alter the log, and prove it by trying.
Ask whether admin actions are logged immutably, and who can alter the log. Then, on a test server, try to delete an entry from the highest staff rank. If you can, the log records what staff chose to leave in it.
Ask whether permissions are checked server-side.
If the menu simply hides options, any client can call the event anyway. Ask the vendor to describe the server-side check for one specific privileged event, end to end.
Ask whether attempted actions are logged, not only successful ones.
A failed permission check is the most interesting entry in the log. A tool that only records successes cannot tell you who tried.
Ask what the log references.
An entry that names an actor and a target but not the ledger row it created cannot be reconciled against the economy. The log and the money should point at each other.
Ask for the escrow manifest at file level, then read the platform docs yourself.
Cfx documents how asset escrow works and what it protects; read that at docs.fivem.net before trusting any seller's summary. For an admin tool specifically, ask whether the permission model is in the open part.
Ask for the measured performance figure with its method and its date.
A number, a server, a player count, a log size and a date — not an adjective. Watchtower's reads: no runtime proof published — pending Shadow bench. Hold us to the same standard.
Ask how the tool logs its own use.
If reading the audit log is not itself logged, then the one surface that sees everything is the one surface nobody sees. That is the 'who audits the auditor' question, and a vendor should have an answer.
The same discipline applied across the catalogue lives in the Proof Center. When Watchtower ships, installation is walked through by the install concierge, and the server-side permission checks above are explained in our server security guide.
Staff accountability, without the overclaim.
What is a FiveM server audit log?
It is an append-only record of privileged actions on a FiveM server — item and money grants, teleports, bans, vehicle spawns, ownership edits — with the actor, the target, the time and a reference to what the action changed. The distinguishing property is that the person taking the action cannot quietly edit or delete the entry afterwards. Watchtower Admin is Vice Drip's version; it is in development, with no runtime proof published — pending Shadow bench.
What matters most in a FiveM admin script?
That privileged actions are logged where the person taking them cannot quietly edit the log, and that permissions are enforced server-side rather than by hiding buttons in a menu.
Who audits the auditor?
The same mechanism. Watchtower is designed so its own actions — including reading other players' records — write the same append-only entries as any other staff action, and so the log is not editable from inside the tool that writes it. Nobody has to trust the auditor blindly because the auditor's record is checkable too. That is design intent, not a demonstrated capability.
Is Watchtower a replacement for Discord webhook logs?
It is designed to be a record where a webhook is a notification. A webhook channel cannot be queried across products, can be deleted by anyone with channel permissions, and does not reference the ledger row an action created. You can keep the webhook for awareness; the audit log is what you replay the dispute from.
Can it catch a money dupe?
It is designed to search every money movement touching a player across products so a doubled balance can be traced to the specific transfers that produced it. Detection depends on the money ledger itself being append-only, which is MoneyTrail's job. Dupe-resistant is the honest phrase; nothing is dupe-proof.
Is Watchtower Admin available to buy?
No. It is in development with no release date and no runtime proof published — pending Shadow bench. The planned price is Planned · $39.99 — a target, not a commitment — pending the studio pricing lock. This page takes a preview-list email and nothing else.
Last verified: 2026-09-02 · Runtime proof: pending Shadow bench · No purchase path
Hear when the watchtower opens.
One email when Watchtower ships, with the measured numbers and the escrow manifest attached. No drip campaigns, no fake countdowns, no date we cannot keep.
Write to support@vicedrip.com with “Launch signal” in the subject. We reply once to confirm before adding you, then send one email at launch plus occasional release notes. Reply “unsubscribe” any time. How we handle your data.