FiveM Chain of
Custody ScriptEvidence that holds up in court RP — ChainLock Evidence
What a FiveM chain of custody script is
A FiveM chain of custody script records who collected a piece of evidence, when, where, and every hand it passed through, so a case holds up in court roleplay. The best systems append each step — collected, transferred, tested, presented — to a history nobody can quietly rewrite, and chain the item to the MDT case, lab results and K9 finds instead of storing bags in an isolated inventory. ChainLock Evidence is Vice Drip's version: in development, no runtime proof published, no purchase path.
Chain of custody is not a feature of an evidence script. It is the entire product.
Evidence systems fail in the one moment they exist for: the argument about what happened. If an item's history can be edited, or lives only in the officer's memory of collecting it, then the evidence proves nothing and the scene collapses into two players asserting different pasts at each other. Chain of custody isn't a feature of an evidence script — it is the entire product.
Status honesty: ChainLock Evidence 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-authoritative, append-only, tamper-evident, shared.
Four design commitments that decide whether an evidence record means anything when the defense comes swinging. These are stated as our reasoning and our design intent — nothing here is a demonstrated capability yet.
Server authority: a client that can forge an evidence event can forge an alibi
Every custody event — collect, transfer, test, present — is a client-reachable endpoint. If the client decides the outcome and the server merely records it, a modified client can place an item in a bag it never touched, or remove one it did. The design here is that the server validates source, permission, rate limit and argument types before a single row is written; the client only asks.
Append-only history: amended means visibly amended
A custody record that can be edited in place proves nothing, because the person with the most reason to change it usually has the access to do so. Each step is designed to be added to the chain, never overwritten. A correction is a new entry that references the old one, so the timeline shows both the mistake and the fix.
Tamper-evident, not tamper-proof
No script can make data impossible to change — a database administrator can always run a query. What a chain of custody can do is make change visible: gaps in sequence, entries with no actor, timestamps out of order. We say tamper-evident on purpose and would treat any vendor saying tamper-proof as a red flag.
Shared record, not a private table
An evidence system that keeps its own inventory forces officers to narrate the record to each other over voice while the database holds a different story. The design intent is that the custody chain hangs off the same case the MDT opens, and a K9 find or a lab result lands in the chain rather than in a separate list.
Why we are building it
We already argue publicly that a ledger which can't survive a crash isn't a ledger (see /guides/stress-test-fivem-economy-scripts). Evidence is the same problem wearing different clothes: an append-only record whose value is precisely that nobody can quietly change it. We would rather build that correctly than ship a nice-looking item list.
Designed to
- Designed as an append-only chain: collected, moved, tested, presented — each step added, none overwritten.
- Designed to share the record with the MDT rather than keeping a private table nobody else can read.
- Designed so that who touched an item, and when, is a question with an answer.
- Designed to be server-authoritative end to end — a client that can forge an evidence event can forge an alibi.
What breaks in a typical evidence 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.
Evidence as inventory clutter
When a shell casing is just an item in a slot, it has a quantity and a name and nothing else. No collector, no scene, no time. The moment someone asks where it came from, the answer is a player's memory, and memories disagree.
Editable history
If an admin, or the officer who bagged it, can rewrite a custody entry in place, the chain is decorative. The dispute becomes an argument about who changed what, which is exactly the argument the system was bought to end.
Client-decided custody events
A net event that trusts its arguments lets a modified client insert, move or delete evidence. Court RP then depends on whether the defense knows how to open a developer console.
An isolated evidence locker
Evidence in one resource, the case in another, the K9 find in a third, the lab result in chat. Three tables that never reference each other cannot tell one story, so officers tell it out loud and the scene stalls.
Restarts that lose the sequence
A custody chain kept in memory, or written in a batch on resource stop, has gaps after every restart. A gap is indistinguishable from tampering, so the whole chain becomes suspect.
No presentation state
Most systems stop at storage. Without a recorded 'presented in court' step, the courtroom cannot verify that what is on the table is what was bagged, and the trial reverts to assertion.
Open vs escrow — the disclosure
The intent for ChainLock is an escrowed core with the full config surface, locales, framework bridge glue and public exports shipping open. The exact file-level manifest publishes with the release rather than being summarised in advance. Nothing ships today, so no manifest exists to publish yet. ForgeCore, the bridge underneath it, is free and fully unescrowed.
What is not proven
- It is not released and not purchasable — nothing on this page can take money.
- No runtime proof published — pending Shadow bench. An append-only chain is a claim about behaviour under pressure, and nobody outside the studio has pressured it yet.
- No resmon figure — [MEASURED-PENDING].
- The $29.99 planned price is a target, not a commitment until the studio pricing lock.
- No release date exists to publish.
- Runtime proof status, in our own words: no runtime proof published — pending Shadow bench.
Four people who touch the chain.
The arresting officer
Bags contraband at the scene. The collect entry names the officer, the case, the location and the time — so the arrest report and the evidence agree without anyone typing it twice.
The K9 handler
A find is designed to flow straight into the chain as its first custody event, with the handler as the actor. The dog's alert becomes a record instead of a claim.
The detective
Sends an item for testing. The transfer to the lab and the result coming back are two more entries on the same chain, each with an actor and a timestamp.
The defense attorney
Reads the timeline looking for a gap. If custody passed cleanly, the case holds. If it did not, the defense has a real argument — which is the point of court RP.
Collected → logged → transferred → tested → presented → audited.
The custody state machine, in order. Every state is designed as an appended entry, so the history of an item is the list of states it passed through.
- 01CollectedAn item enters the chain with an actor, a case reference, a location and a server timestamp. Designed to be validated server-side before the entry exists.
- 02LoggedThe entry is attached to the open case so the MDT sees it immediately, rather than a private locker only the evidence script can read.
- 03TransferredCustody moves — locker to detective, detective to lab. Each hand-off is a new entry naming both parties; nothing about the previous entry changes.
- 04TestedA lab result is appended to the chain, referencing the item, so the result and the sample cannot be separated later.
- 05PresentedThe item is presented in court RP. The presentation is itself an entry, closing the loop from scene to verdict.
- 06AuditedThe full chain is readable across products — designed so a dispute is replayed from the record instead of adjudicated from memory.
The criteria that decide an evidence 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 evidence | What to ask |
|---|---|---|
| Server authority | Custody events are client-reachable endpoints. A client that can write its own custody entry can write its own alibi. | Does every custody event validate source, permission, rate limit and argument types on the server before it writes? |
| Framework support | Evidence touches inventory, jobs and identity — three of the places frameworks differ most. A mismatch is a rewrite, not a config change. | Which of Qbox, QBCore and ESX Legacy are tested targets, and which are inherited compatibility branches? |
| Escrow split | Custody policy — who may transfer, who may present, what counts as a gap — is department procedure. If that logic is escrowed, you adopt someone else's procedure. | Which exact files ship open and which ship escrowed, as a file-level manifest? |
| Dependencies | An evidence script depends on an MDT to attach to, an inventory to collect from, and a framework bridge. Cfx's own guidance is to research dependencies before installing. | What must be installed, at what version, and what breaks when one of those goes unmaintained? |
| Data portability | Custody history is the record a whole department's court RP rests on. If the schema is opaque, migrating off means losing every case. | Is the schema documented, and can you export the custody chain yourself with plain SQL? |
| Runtime proof | A performance claim without a method, player count and date is a marketing number. Ours currently reads: no runtime proof published — pending Shadow bench. | What was measured, on what hardware, at what player count, on what date, by what method? |
| Support SLA | A broken custody chain is a live incident during a trial scene. Response time is part of the product. | Is there a written first-response window, and what is the escalation path when the first diagnosis is wrong? |
| Changelog | A silent change to what counts as a valid transfer alters every case after it. A dated changelog is the only way to correlate a break with a change. | Is there a public, dated changelog with version numbers, and does it call out breaking changes? |
What to verify before buying a FiveM evidence script.
Six questions, useful even if you never buy from us. For platform facts — asset escrow, the resource manifest, server-side events — read the official Cfx documentation at docs.fivem.net rather than a seller's summary of it.
Ask whether a custody entry can be edited or deleted, and by whom.
The answer should be that entries are appended, never rewritten, and that corrections are new entries referencing old ones. If admins can silently rewrite the chain, it is a list with a nicer name.
Ask what the MDT actually sees.
'Integrates' means nothing. Ask which table, which export or which event the evidence and MDT systems share. If the answer is none, officers will narrate evidence over voice — the failure you are buying to fix.
Ask how custody events validate their arguments.
Every collect, transfer and present call is reachable from a client. The vendor should be able to describe the server-side checks on source, permission, rate and argument types for each one.
Ask what happens to the chain on a resource restart.
Entries should be persisted as they happen, not batched on stop. A gap after every restart is indistinguishable from tampering and poisons the whole record.
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 first at docs.fivem.net, then ask which files you will be able to open and patch.
Ask for the measured performance figure with its method and its date.
A number, a server, a player count and a date — not an adjective. ChainLock's reads: no runtime proof published — pending Shadow bench. Judge us by the same standard.
The same discipline applied across the catalogue lives in the Proof Center. When ChainLock ships, installation is walked through by the install concierge, and the net-event checks above are explained in our server security guide.
Chain of custody, without the overclaim.
What is a FiveM chain of custody script?
It is an evidence system whose core feature is the custody record: who collected an item, when, where, and every hand it passed through — collected, transferred, tested, presented — stored as an append-only history rather than an editable item list. The chain is what makes evidence hold up in court roleplay. ChainLock Evidence is Vice Drip's version; it is in development, with no runtime proof published — pending Shadow bench.
What does chain of custody mean in a FiveM evidence script?
That every action on an item is appended to a history rather than overwriting it, so who collected, moved, tested or presented a piece of evidence is answerable later. If entries can be silently edited, there is no chain — only a list.
Does an evidence script need to integrate with an MDT?
It needs to share a record with one, or officers end up narrating evidence to each other over voice while the database holds a different story. Ask any vendor which table or export the two systems actually share. ChainLock is designed to attach custody to the same case CaseLink MDT opens.
Is ChainLock tamper-proof?
No, and we would not say so about any script. A database administrator can always run a query. ChainLock is designed to be tamper-evident: sequence gaps, entries with no actor and out-of-order timestamps are visible, so a changed record looks changed. That is the strongest honest claim a custody system can make.
How do K9 finds and lab results enter the chain?
By design, a K9 Trace find becomes the first custody entry for the item with the handler as the actor, and a lab result is appended to the same chain referencing the sample. That is design intent for products still in development, not a demonstrated capability.
Can I buy ChainLock Evidence now?
No — it is in active development with no release date and no runtime proof published — pending Shadow bench. The planned price is Planned · $29.99, a target rather than 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 chain is ready to hold.
One email when ChainLock 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.