FiveM Scripts & Resources
FiveM scripts, in short
FiveM scripts are server-side resources — Lua code, configuration, and NUI interfaces — that add systems like banking, jobs, policing, property, and events to a GTA V roleplay server running the FiveM framework. You install them into your server's resources folder, start them in server.cfg, and they run against a framework such as Qbox, QBCore, or ESX Legacy. Vice Drip builds FiveM resources for those frameworks and publishes each one's build status, escrow split, and proof state; nothing in the catalog is cleared for sale yet.
This is the hub for the premium FiveM scripts New Origins Studio is building. Every resource below shows the status it actually has, links to its own page, and carries a planned price rather than a purchase path. If you came here to buy FiveM scripts today, the honest answer is that you cannot — from us. What you can do is take the eight criteria on this page to whoever you do buy from.
Four things we do differently.
None of these is a performance claim, because we have no performance results to publish. They are disclosure practices and architecture decisions — the parts of a script store that can be verified before anything ships.
Open-vs-escrow disclosure, at file level
Escrow opacity is the loudest complaint in this market, so we answer it with a split rather than a slogan. The two free resources ship 100% unescrowed. Paid resources are escrowed-core: the full config surface, locales, framework bridge glue and the public exports API ship open; core logic ships escrowed. The exact file-level manifest publishes with each release, and until it does, this page says so.
Measured-claims-only
No performance number appears here unless it was measured, dated, and filed with a method. Right now none has been: no runtime proof is published across the portfolio and every resmon figure reads [measured-pending]. Our internal idle and active targets exist, but a target printed as a result is a lie with a decimal point in it.
One bridge, not three codebases
Every resource talks to your framework through a single module — ForgeCore (vf_core) — which is free and fully open. Qbox with ox_lib is the native target; QBCore is reached through a compatibility adapter and ESX Legacy through a bridge adapter. Nothing we ship calls qb-core, qbx_core or es_extended directly, so the framework you picked stays a decision you can revisit.
Install support as a written model
Support is a defined pipeline, not a promise to be nice: intake with secrets stripped, S1-S4 triage, a diagnosis grounded in your actual log and the docs, automatic escalation to a human on low confidence or anything touching money, and nothing marked fixed without a fresh debug-level log. It covers live products; in-development resources get a pre-purchase compatibility check only.
Every resource, with its real status.
Statuses and descriptions below come straight from the product truth model, not from marketing copy. Prices marked Planned are targets pending the studio's pricing lock — they are not offers, and no entry on this page has a checkout path.
Foundation scripts
Category page →The shared layer everything else depends on: the framework bridge and citywide announcements. Both are free and ship with no escrowed files.
ForgeCore
The free, fully open framework bridge every Vice Drip resource runs through — Qbox (native, on ox_lib), QBCore, and ESX Legacy resolved at start-up from one module. For owners who audit the layer under their economy before trusting it. No escrowed files. Staged; no runtime proof published — pending Shadow bench.
FREE
View docs →CityPulse
A free, fully open announcement and broadcast layer — permission-gated, rate-limited, config-routed citywide alerts and Discord recaps of moments other resources commit. For owners who want the city to notice what just happened. Qbox, QBCore, and ESX Legacy through ForgeCore. No escrowed files; no runtime proof published — pending Shadow bench.
FREE
View docs →Economy & ownership scripts
Category page →Banking, jobs, vehicles, housing, realty, business, and the oversight desk that audits them. The failure mode here is silent ledger drift, not a crash.
MoneyTrail
A banking system built as a ledger, not a pile of balances — integer cents, append-only history, and balances you can recompute. For owners who want money disputes settled by a query. Two dated integrity tests published; performance [measured-pending]. Qbox, QBCore, and ESX Legacy through ForgeCore. Escrowed core, open config. In build; no runtime proof published — pending Shadow bench.
Planned · $39.99
Get launch signal →ShiftWorks
Civilian jobs — route, zone, and yield archetypes — with server-validated tasks, diminishing-returns payouts, and daily caps that feed the economy instead of inflating it. For owners who need a legal loop that competes with crime. Qbox, QBCore, and ESX Legacy through ForgeCore. Escrowed core, open config. In build; no runtime proof published — pending Shadow bench.
Planned · $24.99
Get launch signal →TitleLock Garage
Vehicles with ownership, history, and recovery records — persistence that survives restarts, shared keys, transfers, and impound fees, with an adapter mode for the tables you already run. For owners tired of vanished-car tickets. Qbox, QBCore, and ESX Legacy through ForgeCore. Escrowed core, open config. In build; no runtime proof published — pending Shadow bench.
Planned · $24.99
Get launch signal →ClosingTable
Real-estate roleplay with real closings — listings, offers, open houses, and commissions routed to an audited agency treasury and conserved to the cent. For owners who want realty to be a profession. Designed for Qbox, QBCore, and ESX Legacy through ForgeCore; escrow split publishes at release. In development; no runtime proof published — pending Shadow bench.
Planned · $39.99
Join preview →CleanTitle Housing
Property ownership that holds up — a recorded title, a move-in receipt, a guest list, rent history, and an open house you can host, with the interiors you already run. For owners who want property to mean ownership. Designed for Qbox, QBCore, and ESX Legacy through ForgeCore; escrow split publishes at release. In development; no runtime proof published — pending Shadow bench.
Planned · $39.99–44.99
Join preview →MainStreet
Player-owned businesses that create server nights — crews, payroll, and revenue that reconcile against the same audited money path as everything else. For owners who want a business to be an operator's job, not a shop menu. Designed for Qbox, QBCore, and ESX Legacy through ForgeCore; escrow split publishes at release. In development; no runtime proof published — pending Shadow bench.
Planned · $39.99
Join preview →Watchtower Admin
The oversight desk that audits itself — one search across every Vice Drip ledger to replay a dispute, with every admin action written to the same append-only record. Tamper-evident, never absolute. For owners who want staff trusted because they can prove it. Designed for Qbox, QBCore, and ESX Legacy through ForgeCore; escrow split publishes at release. In development; no runtime proof published — pending Shadow bench.
Planned · $39.99
Join preview →Crime scripts
Category page →A drug economy and a gang layer built as sinks and pressure rather than faucets. Designed to create heat, not to print currency.
Heatline
A crime economy tuned to create heat, not runaway cash — reconfigurable supply chains, live street pricing with floors and ceilings, anti-inflation sinks, and server-validated timing and position. For owners who want crime the whole city reacts to. Qbox, QBCore, and ESX Legacy through ForgeCore. Escrowed core, open config. In build; no runtime proof published — pending Shadow bench.
Planned · $34.99
Get launch signal →TurfLedger
Gang legacy without staff chaos — identity, ranks, a presence-and-dwell turf state machine, reputation, and an audited treasury, so rivalry has a log instead of a ticket queue. For owners who want feuds that last seasons. 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.
Planned · $27.99
Join preview →Police & law scripts
Category page →MDT, evidence chain-of-custody, EMS, K9 and aerial recon, built to share one case record instead of five disconnected ones.
CaseLink MDT
One case record that dispatch, evidence, EMS, and K9 all write to — the suspect's history, the custody chain, and the medical report in one file. For law factions that lose the thread between scene and court. Designed for Qbox, QBCore, and ESX Legacy through ForgeCore; escrow split publishes at release. In development; no runtime proof published — pending Shadow bench.
Planned · $44.99
Join preview →ChainLock Evidence
Chain of custody that survives the defense — every transfer appends a row that is never edited afterward, and every item chains into the CaseLink case. For owners whose court scenes collapse on a screenshot. Designed for Qbox, QBCore, and ESX Legacy through ForgeCore; escrow split publishes at release. In development; no runtime proof published — pending Shadow bench.
Planned · $29.99
Join preview →LifeLine EMS
Patient care reports tied to the call that created them — dispatch, triage, treatment, and hospital handoff as one continuous record that attaches to the case. For owners who want medical roleplay with consequence. Designed for Qbox, QBCore, and ESX Legacy through ForgeCore; escrow split publishes at release. In development; no runtime proof published — pending Shadow bench.
Planned · $29.99
Join preview →K9 Trace
A bounded, non-weaponized K9 search tool with every find handed into the evidence custody chain. For police factions that want K9 to mean procedure. Designed for Qbox, QBCore, and ESX Legacy through ForgeCore; escrow split publishes at release. In development; performance [measured-pending]; no runtime proof published — pending Shadow bench.
Planned · $19.99–24.99
Join preview →SkyWatch Recon
Audited, throttled, explicitly non-combat aerial recon — an infrastructure tool with receipts, not a drone arms race, designed to hand sightings to the case record. For owners who want overwatch without an exploit surface. Designed for Qbox, QBCore, and ESX Legacy through ForgeCore; escrow split publishes at release. In development; no runtime proof published — pending Shadow bench.
Planned · $34.99
Join preview →Event scripts
Category page →Set pieces and cinematic co-op — the resources that exist to produce the clip somebody posts.
SkyForge Shows
Beat-synced firework and light shows staged over a venue for holidays and finales — the moment a crowd records. For owners who want a recurring server event without guessing its client cost. Designed for Qbox, QBCore, and ESX Legacy through ForgeCore; escrow split publishes at release. In development; performance [measured-pending]; no runtime proof published — pending Shadow bench.
Planned · $29.99–34.99
Join preview →Sidekick Lite
A small companion that follows, sits, stays, and emotes — scoped narrow on purpose so it earns its place with clips, not client cost. For owners who want a wholesome beat without another heavy resource. Designed for Qbox, QBCore, and ESX Legacy through ForgeCore; escrow split publishes at release. In development; performance [measured-pending]; no runtime proof published — pending Shadow bench.
[price-pending]
Join preview →Veilbreakers: Daemon Protocol
A server-authoritative possession and exorcism loop — expose the host, run the rite, cast out the daemon, slay what remains, and every case leaves a receipt on the MDT. Co-op; v1 is one daemon, one scene; a configurable lexicon names no real faith. Designed for Qbox, QBCore, and ESX Legacy through ForgeCore. In development · not yet released · not for sale; no runtime proof published — pending Shadow bench.
Planned · $39.99
Learn more →Looking for one framework in particular? The framework hubs carry the dependency and migration detail this page summarises: Qbox scripts, QBCore scripts, and ESX scripts.
The categories where the engineering argument is the whole product.
Some categories are decided by a property you cannot see in a feature list — whether a record can be rewritten, whether the server or the client decided an amount, whether an event survives its second run. Each page below takes one of those, explains the mechanism, and gives you the questions to ask any seller.
Evidence · justice
Chain of custody
Why an editable custody row makes an evidence system decorative, the six-state custody flow, and the eight criteria that decide any evidence script.
Read it →Admin · oversight
Server audit log
Who audits the auditor. What an admin action has to record before it can settle a staff-corruption dispute in either direction.
Read it →Money · integrity
Banking script security
Race-condition dupes, crash drift, and client-sized amounts — plus the two integrity tests we ran on our own banking build, with dates.
Read it →Police · Qbox
Qbox MDT
What an MDT owes the rest of the justice chain, and what running one on Qbox and ox_lib actually requires.
Read it →Events · cinematic
Supernatural scripts
Investigation before confrontation, server authority over the outcome, and the second-run question that decides whether event content was worth buying.
Read it →Realty · ownership
Property management
Leases, tenants, commissions and the audit trail behind them — the difference between a housing menu and a property system.
Read it →Eight criteria worth checking.
There are no vendor scores in this table and there never will be. We do not run other sellers' code, so rating them would be invented precision dressed as research — the exact thing this store exists to refuse. What is useful is the criteria themselves, and the question that tests each one.
| Criterion | Why it matters | How to test it |
|---|---|---|
| Server authority | A resource that lets the client decide an outcome can be driven by anyone who can fire a net event. This is the difference between a bug report and an economy wipe. | Ask which side validates the mutation, and whether every net event checks source, permission, rate limit and argument types. |
| Framework support | "Supports QBCore" can mean a maintained adapter or a single untested branch. The difference decides whether you bought a resource or an integration project. | Ask for the tested framework and artifact versions, in writing, per release — not a logo row. |
| Escrow split | Escrowed files cannot be read, patched or audited. How much ships open decides how much of your server is a black box you cannot debug at 2am. | Ask for a file-level manifest naming exactly which files are escrowed and which are not. |
| Dependencies | Every dependency attaches a second maintainer's release cadence and uptime to your server. It is also the most common reason an install fails on day one. | Read fxmanifest.lua for declared dependencies, then grep for exports of resources you do not already run. |
| Data portability | Your economy lives in your database. If a resource writes rows only its own escrowed code can interpret, leaving costs you the data, not just the license. | Ask for the schema. Tables you can read with plain SQL are the difference between migrating and starting over. |
| Runtime proof | A screenshot of a resmon graph is not a measurement anyone can reproduce. A performance claim with no method, client spec, player count or date is a marketing number. | Ask what was measured, on what hardware, at what player count, on what date — and whether the log is available. |
| Support SLA | The failure you actually care about happens on a Saturday night with a full server. A stated window is the only part of support you can hold anyone to. | Ask for first-response and hotfix windows in hours, and what the seller counts as a severity-1. |
| Changelog | A dated public changelog is the cheapest available signal of whether a resource is maintained or quietly abandoned. | Look for dated entries and a version string you can compare against the copy you installed. |
Our own answers to all eight live in the Proof Center — including the rows where the answer is currently “not proven.”
What to verify before buying.
Cfx.re's own platform documentation is the neutral source for how FiveM resources, manifests, dependencies and asset escrow actually work, and it is where the platform's guidance on installing third-party and paid community resources lives — research what a resource depends on, and take care with paid community assets. Check any seller's claim, ours included, against docs.fivem.net rather than against a store page.
- 01
Read fxmanifest.lua before you install: declared dependencies, the lua54 flag, and which files the manifest lists as escrowed.
- 02
Ask which framework and artifact versions were actually tested for the release you are buying — and ask for it in writing.
- 03
Ask for the escrow manifest at file level before purchase, not after.
- 04
Ask how any performance figure was measured: method, hardware, player count, date. No method means no measurement.
- 05
Ask what happens to your database rows if you uninstall, and whether the schema is documented.
- 06
Ask for the support window in hours, then check whether the changelog's most recent dated entry backs it up.
- 07
Read the license terms: what you may modify, whether you may run it across multiple servers, and what happens on a refund.
- 08
Cross-check every technical claim — ours included — against the platform documentation rather than a store page.
Longer form, with the failure cases: how to vet a FiveM script seller and FiveM asset escrow, explained.
FiveM scripts, without the overclaim.
What are FiveM scripts?
FiveM scripts (more precisely, FiveM resources) are folders of Lua code, configuration, and optional NUI web interfaces that a FiveM server loads at start-up. Each one adds a system to a GTA V roleplay server — a bank, a job, an MDT, a housing market. They run server-side, client-side, or both, and most of them run against a framework such as Qbox, QBCore or ESX Legacy that supplies shared player, job and money state.
How do you install a FiveM script?
You place the resource folder inside your server's resources directory, add an ensure line for it in server.cfg, install anything its manifest declares as a dependency, import any SQL it ships, then restart the server and read the console for errors. Order matters: the framework and its database layer start before anything that depends on them. The platform documentation at docs.fivem.net is the authoritative reference for manifests and start-up order.
Do FiveM scripts need a framework?
Not always — standalone resources exist and depend on nothing but the server itself. Anything touching money, jobs or identity almost always does need one, because that state has to live somewhere shared. Vice Drip resources reach your framework through one free, fully open bridge module rather than binding to a framework's internals, which is what keeps a later framework change a decision instead of a rebuild.
What makes a FiveM script premium?
Not the price. The properties that separate a premium FiveM resource from an expensive one are server-side authority, an honest escrow split, declared dependencies, a readable database schema, measured performance rather than claimed performance, a support window stated in hours, and a dated changelog. Those are the eight criteria in the table above, and they are checkable before you spend anything.
Is anything in the Vice Drip catalog available to buy right now?
No. Nothing in the catalog is cleared to sell: there is no Buy button, no checkout path and no purchase on this site for any script. 2 foundation resources are free and fully unescrowed; every other entry shows a build status and a planned price that is a target, not a commitment, until the studio's pricing lock. Verified 2026-07-23.
How large is the Vice Drip catalog, and how much of it is proven?
19 resources have a public entry today, spanning foundation, economy, crime, law-and-order and event categories. Proven is a separate question, and the honest answer is that no runtime proof is published: no resource has a published capture of its core loop completing on a live FiveM server, and no resmon figure has been measured. The engineering that is verifiable today is architectural — server authority, append-only audit, and a single open bridge — and it is verifiable by reading code, not by trusting a graph.
Status honesty: no runtime proof is published across the portfolio — no resource has completed its core loop on a live FiveM server, and no resmon figure has been measured. Every performance cell reads [measured-pending]. Nothing on this page is on sale: there is no Buy button, no checkout and no purchase path. Planned prices are targets pending the studio pricing lock. We publish no reviews, ratings, install counts or revenue figures, and we make no next-generation Rockstar-title compatibility claim.
Last verified: 2026-07-23