FiveM drug dealer script: build a tense RP economy without making it exploitable

A strong FiveM drug dealer script should create decisions, not just a button that turns an item into cash. The best systems give players a chain of risk: sourcing, processing, finding buyers, moving product, managing heat and deciding whether the payout is worth the exposure.

Drug-dealer gameplay is popular because it naturally creates conflict between civilians, gangs, police and the wider server economy. It can also become one of the easiest systems to exploit if the client is allowed to choose the item, quantity, reward or delivery result. Treat the feature as an economy system with a roleplay layer, not as a collection of client events.

Before you write code, decide what your server is trying to encourage. Do you want short street-level interactions, longer supply chains, territory conflict, police investigations or a mixture? The answer determines whether your script needs simple NPC buyers or a full pipeline with suppliers, processing locations, deliveries, evidence and risk.

Design the loop in five understandable stages

A good first version can use five stages: acquire, process, find a buyer, complete the sale and manage the consequences. Each stage should have a clear input and output. If the player receives a raw item, processing should change it into a defined product. If a buyer asks for a product, the server should generate or validate that order. If police risk increases, the player should understand why.

Keep the economy believable

The payout should be meaningful without becoming the only profitable activity on the server. Set a baseline reward, add controlled variation, and consider a risk multiplier rather than huge random numbers. Your configuration should make it easy to balance the system after observing real play: minimum and maximum quantity, base payout, police requirement, cooldown, processing time, item requirements and the chance of a report.

A common mistake is to add a “bonus” for every risk event. If a player can force a police alert and then immediately sell for a larger reward, the optimal strategy may be to spam the same loop. Instead, use risk as a trade-off. A dangerous location could have better margins, but it should also have a longer cooldown, more evidence or a greater chance of a response.

Build an economy table before writing the UI. For example, list the item cost, processing loss, expected sale value, average time per run and expected police pressure. Compare that result with legal jobs on your server. The aim is not perfect mathematical balance on day one; it is a loop that can be tuned without rewriting the resource.

Never trust client-side sales

FiveM’s official security guidance explains that networked events can be triggered by clients and recommends validating money, inventory, position, state, experience, permissions and roles on the server.^[1] This matters especially for a drug system because the profitable operation is usually a server event such as “sell item”.

The client may request a sale, but it should not decide what was sold or how much the player earned. The server should retrieve the player object, verify the item exists in the configured product list, validate the player’s position or active order, check the cooldown, remove the item, calculate the reward and write the result. If any check fails, return without granting money.

RegisterNetEvent('dealer:server:completeSale', function(orderId)
    local src = source
    local player = QBCore.Functions.GetPlayer(src)
    local order = activeOrders[src]
    if not player or not order or order.id ~= orderId then return end
    if os.time() < order.cooldownUntil or not isWithinBuyerRange(src, order) then return end
    if not player.Functions.RemoveItem(order.item, order.quantity) then return end
    local payout = calculatePayout(order)
    player.Functions.AddMoney('cash', payout, 'dealer-sale')
    activeOrders[src] = nil
end)

This is deliberately a shape rather than a drop-in script. Framework exports and inventory functions differ between servers. The important point is the order of authority: the server owns the active order, the quantity, the item check and the payout.

Add evidence and cooldowns carefully

Evidence can make the loop more interesting without turning it into a frustrating punishment. A sale could create a short-lived dispatch marker, a shell casing equivalent, a phone lead or a vehicle description. Make the result readable and give police a fair chance to respond. Avoid hidden random alerts that feel arbitrary; explain enough that players can learn the risk.

Cooldowns should protect the economy and the server, not simply stop players from playing. Apply them per player, location or order type. Clear active state on disconnect and remove abandoned orders after a timeout. If multiple players can use one buyer, give the server a lock or order ownership so two callbacks cannot both pay for the same transaction.

Test the resource as an attacker and a roleplayer

Start with a normal run: acquire an item, process it, receive a buyer, travel to the location and sell. Then test the edges. Try changing the item name in the client request, changing the quantity, moving away from the location, triggering the event twice, selling after the order expires, disconnecting mid-process, restarting the resource and having two players target the same buyer. Also test a player with the wrong job, wrong gang, insufficient inventory or insufficient police presence.

Log rejected actions during development, but keep production logs useful rather than noisy. Record the reason for a rejected sale and the server-side order ID without logging private player data unnecessarily. Balance from observed outcomes: average time per successful run, payout distribution, police response frequency and how often players abandon the chain.

Use AI for structure, then review the risk

AI can help you turn a feature brief into a complete resource structure, but it cannot know your exact framework version, inventory exports, database conventions or economy balance unless you provide them. Give it the locations, item names, framework, dependency list, event diagram and acceptance tests. Ask it to explain every server-side trust boundary.

Stellar AI is useful for generating a first pass, reviewing an existing FiveM resource and turning errors into a testable repair plan. Keep the output on a development server until you have checked every reward event yourself.