TurfLedger

What it is

Gang identity and rank permissions, a presence-and-dwell territory claim state machine, reputation, and an audited treasury through the ForgeCore society bridge, with a Heatline tie-in hook. Turf history is a record, so "they took our block" is answered by the log, not by staff. For owners who want rivalry to last seasons without a moderation burden. Designed for Qbox, QBCore, and ESX Legacy through ForgeCore. Escrow split publishes at release. Spec in studio review; no runtime proof published — pending Shadow bench.

The problem it exists for

On most servers, territory is a color on a map and an argument in a Discord. Who controls a block is decided by whoever screenshots first, turf wars resolve in staff tickets instead of gameplay, and a gang's history — the feuds, the takeovers, the two months they held the docks — evaporates when the players who remember it stop logging in. Territory can't mean anything if nothing keeps score.

Why we're building it

Gangs are the content players build identities around, and turf is the part that decays fastest: control with no record, feuds with no dates, reputations that live in screenshots. We're building it the way we build everything else — as a ledger. A claim is an entry, a takeover is an entry, and the history of a block is a fact you can look up rather than a story staff have to referee.

What it's designed to do

Design intent, not shipped behaviour — none of this has been built yet.

• Designed so a turf claim is a record: who took it, from whom, when, and what it cost — not a color change with no memory.
• Designed around pressure rather than paperwork — control that has to be maintained through play, not asserted through tickets.
• Designed to track rivalries as history: feuds with dates and outcomes, so a gang's reputation is something the server can cite instead of something it half-remembers.
• Designed to plug into the crime economy (Heatline) so turf matters to income, and to leave the audit trail that turns 'he took our turf' into a lookup instead of an adjudication.

What is not proven

The section every product page should have and almost none do.

• In development and not purchasable — authored in the studio repo, with no runtime proof published pending the Shadow bench.
• No resmon figure — [MEASURED-PENDING].
• The $27.99 planned price is a target, not a commitment until the studio pricing lock.
• No release date exists to publish.

What we're building toward

A turf map flipping colors as a rivalry card slaps down: Red Wake vs. Black Tide.

Current status, stated exactly

• resmon [measured-pending]
• spec — in studio review
• escrow manifest — at release
• framework support — decided at build, published at release
• open-vs-escrowed manifest — published at release, file by file

What to verify before buying any crime resource

This applies to every product in this category, ours included, whenever it arrives. Hold TurfLedger to exactly these when it launches — and if it fails one of them, don't buy it.

• Ask what record a takeover leaves. If turf is a state with no history, every dispute lands on staff — which is the workload the script was supposed to remove.
• Ask whether claims and captures are validated server-side. A turf event a client can fire is a turf map any client can repaint (see /guides/fivem-server-security-net-events).
• Vet the seller the way you'd vet any seller — unedited footage, escrow manifest, measured figures with methods and dates (see /guides/how-to-vet-fivem-script-sellers).

Universally: ask for the measured resmon figure with its method and date, the exact list of which files ship open versus escrowed, a dated changelog, and the refund window. Four answers. Any of them missing is an answer too.