FiveM Asset Escrow Explained: Grants, License Keys, and Fixes

What Asset Escrow actually does

Asset Escrow is the protection system Cfx.re built together with Tebex for paid FiveM resources. When a developer publishes through escrow, the core code of the resource is encrypted before it ever reaches you. Your server can run the files, but you cannot open them, read them, or modify them. The goal is simple: developers can sell scripts without shipping their source, and buyers get a resource that installs like any other.

Escrow can encrypt Lua scripts along with YFT, YDD and YDR asset files, which is why you increasingly see protected vehicle and clothing packs, not just scripts. NUI content is not supported for encryption, so the HTML, CSS and JavaScript behind a script's interface always ships readable. On the server side, escrow requires artifact 4960 or newer, and in practice current resources expect far more recent builds — keeping your artifacts updated is not optional.

• Encrypts Lua, YFT, YDD and YDR files
• Cannot encrypt NUI content (HTML, CSS, JavaScript)
• Requires server artifact 4960 or newer — realistically much newer

How purchases and grants work

When you buy an escrowed resource, the purchase is granted to the Cfx.re account you were logged into at Tebex checkout. Not your email, not your Discord, not your forum name — the Cfx.re account active in the browser at that moment. This one detail causes more support tickets than anything else in the escrow system, so check which account you are signed into before you pay.

After purchase, the resource appears under Granted Assets on portal.cfx.re, and a download link is also sent to you by email. The portal is the canonical source: re-downloading from it always gives you the latest version of the resource, which makes it your update mechanism as well. If a developer announces an update, you do not wait for a new email — you log into the portal and pull the files again.

Before you check out on any Tebex store, open portal.cfx.re in another tab and confirm you are logged into the right account. If you run multiple servers under different accounts, be deliberate about which one gets the grant, because the resource will only run under keys from that account. Thirty seconds of checking here saves a support ticket later.

License keys and the entitlement check

Owning a grant is only half of the equation. An escrowed resource will only start on a server whose license key was created on the same Cfx.re account that owns the grant. When the server boots the resource, it checks whether the key's account holds the entitlement. If it does not, the resource refuses to start and the console prints the error every escrow buyer eventually meets: You lack the required entitlement.

The mismatch almost always comes from split ownership. A team member bought the script on their personal account while the server key lives on the owner's account. Or the purchase went through while logged into an old or secondary Cfx.re account. Or a hosting panel generated the key under an account nobody controls directly. In every case the code is fine — the accounts simply do not line up.

To fix it, first check which account your server's license key was created on, then check which account shows the script under Granted Assets on portal.cfx.re. If they differ, the cleanest solution is to create a new license key on the account that owns the grant and update your server config. If the grant sits on the wrong account entirely, contact the seller and ask whether it can be moved.

• Error text: You lack the required entitlement
• Cause: key account and grant account differ
• Fix: create the key on the account that owns the grant
• Prevention: buy and generate keys from one Cfx.re account

What you are allowed to edit

Escrow is not all-or-nothing. In fxmanifest.lua, the developer lists files under escrow_ignore, and everything listed there ships unencrypted and is yours to edit freely. By convention that covers config.lua, the locales folder for translations, and install templates such as SQL files or item definitions for ox_inventory or qb-inventory. A well-built escrowed script exposes everything a server owner legitimately needs — prices, permissions, locations, language strings — through those open files. Iconix releases follow the same convention, with config and locales always left open.

Everything not listed is encrypted, and the rule there is absolute: do not edit, rename, re-save or repack those files. Escrow verifies the protected files at load time, and any modification, however small, breaks that verification and the resource stops loading. If you need behaviour the config does not cover, ask the developer for a config option or an exposed event rather than trying to work around the encryption.

The classic errors and their fixes

Failed to verify protected resource is the other error you will meet. It means the encrypted files no longer match what escrow expects — usually because someone edited or repacked them, but often because the files were corrupted on the way to the server. The fix is always the same: delete the resource folder completely and re-download a fresh copy from portal.cfx.re. Do not try to patch individual files; a clean folder is faster and reliable.

The most common corruption source is FTP. Uploading in text or ASCII mode silently mangles the encrypted .fxap file, because the client rewrites line endings inside a binary file. Use SFTP instead, or force your FTP client into binary transfer mode. If your host offers a file manager that accepts zip uploads, zipping the resource locally and extracting it on the server avoids the problem entirely.

• You lack the required entitlement: key and grant on different accounts
• Failed to verify protected resource: delete the folder, re-download fresh
• Corrupted .fxap after upload: switch to SFTP or binary mode
• Escrow resource on an old artifact: update to a current server build

A workflow that avoids all of this

Treat your Cfx.re account like server infrastructure. Pick one account that owns your license keys and make every purchase while logged into it. If several people buy scripts for the server, either share that responsibility deliberately or accept that grants will end up scattered across personal accounts — which is exactly how entitlement errors are born. Write down which account owns which keys and which grants.

For updates, make the portal your habit. Back up your config.lua and locales, delete the old resource folder, download fresh from Granted Assets, then merge your settings back in and diff the new config against your backup for options added since your version. Upload over SFTP, restart, and watch the console on first boot. Escrow adds a few rules, but once your accounts are in order it behaves predictably.