Escrow FiveM: qué es y por qué protege tu compra

Si has mirado dentro de la carpeta de un script comprado y te has encontrado un archivo .fxap junto a código que no puedes leer, ya has conocido el asset escrow de FiveM. Es el sistema oficial de protección de recursos de Cfx.re y, aunque tiene fama de polémico entre desarrolladores, para el comprador es sobre todo una garantía: asegura que lo que pagaste es legítimo, que nadie puede revenderlo pirateado y que el creador tiene incentivos para seguir actualizándolo. Veamos cómo funciona de verdad, qué protege, qué no, y cómo comprar con criterio.

Qué es el asset escrow de FiveM

El asset escrow es el mecanismo de cifrado y autorización de recursos integrado en la plataforma de Cfx.re. Cuando un desarrollador publica un script protegido, su código se cifra y se distribuye junto a un archivo .fxap que forma parte del sistema de protección. Ese contenido cifrado no se puede leer ni ejecutar por su cuenta.

La autorización llega por otra vía: el Keymaster. Al comprar el script en una tienda con checkout de Tebex, recibes un asset grant vinculado a tu cuenta de Cfx.re. Cuando tu servidor arranca, se identifica con su licencia, el sistema comprueba que tu cuenta tiene el grant y solo entonces el runtime descifra y ejecuta el recurso en memoria. Sin grant no hay ejecución, por mucho que alguien copie la carpeta.

Por dentro, la carpeta de un recurso protegido tiene un aspecto reconocible: el fxmanifest.lua sigue siendo legible, verás archivos abiertos como la configuración o las traducciones en texto plano, y junto a ellos los archivos cifrados y el .fxap. No hay que hacer nada especial con ninguno de ellos: se instala como cualquier otro recurso, con su carpeta y su ensure en el server.cfg.

Dos consecuencias prácticas de este diseño:

• La protección no depende de ofuscadores caseros ni de “licencias” con IP que llaman a servidores del vendedor. Es infraestructura oficial de la plataforma, y no necesita que el vendedor mantenga ningún servicio propio encendido para que tu script funcione.
• El descifrado ocurre al cargar el recurso. En el día a día, el código corre como cualquier otro; no hay una capa de cifrado permanente lastrando cada función.

Qué protege el escrow

Contra los leaks

Sin escrow, cualquier comprador puede subir el script completo a un foro de leaks el mismo día del lanzamiento. Con escrow, la copia filtrada no funciona: le falta la autorización del Keymaster. Las versiones “crackeadas” que circulan requieren manipular el recurso, y esas manipulaciones son el vehículo habitual de backdoors que comprometen servidores enteros.

El valor de tu compra

Esto se menciona menos, pero te afecta directamente como comprador. Cuando un script se filtra masivamente, el desarrollador deja de ingresarlo y, tarde o temprano, deja de mantenerlo. Tu compra legítima se devalúa: te quedas con un producto huérfano mientras medio ecosistema usa la copia pirata. El escrow corta ese ciclo. Al mantener el valor comercial del producto, mantiene también el incentivo del creador para publicar actualizaciones, corregir errores y dar soporte durante años. Las actualizaciones gratuitas de por vida que ofrecemos solo son sostenibles porque el producto no se puede revender ni redistribuir.

Qué NO impide el escrow: los archivos abiertos

Aquí está el malentendido más extendido: escrow no significa que no puedas tocar nada. El desarrollador decide qué archivos se cifran y cuáles quedan abiertos, y lo declara en el manifiesto del recurso:

fx_version 'cerulean'
game 'gta5'

escrow_ignore {
    'config.lua',
    'locales/*.lua',
    'html/**/*'
}

Todo lo listado en escrow_ignore se distribuye como texto plano editable. En un script bien empaquetado, eso incluye como mínimo:

• La configuración (config.lua o equivalente): precios, posiciones, permisos, tiempos, activar o desactivar funciones.
• Las traducciones (locales): para adaptar los textos a tu comunidad.
• A menudo la interfaz (html): para retocar estilos y encajarla con la identidad visual de tu servidor.

Un buen vendedor diseña el script para que todo lo que un propietario de servidor necesita ajustar viva fuera del cifrado. Si un producto protege hasta el archivo de configuración, es un empaquetado mal hecho y una señal para desconfiar. La lógica interna (la que garantiza que el script funcione y no sea explotable) es lo que queda cifrado.

Hay otra vía de personalización que el escrow tampoco cierra: la integración con el resto de tu servidor. Un script protegido bien diseñado expone exports y eventos documentados, de modo que tus propios recursos pueden comunicarse con él sin leer una sola línea de su código cerrado. Puedes conectar tu sistema de notificaciones, tu inventario o tu HUD a través de esas interfaces públicas. Por eso la documentación importa tanto: define qué puntos de conexión tienes disponibles y convierte un recurso cerrado en una pieza combinable con las demás.

La crítica de los desarrolladores: cuándo tiene sentido lo abierto

Seamos justos con la otra postura, porque tiene argumentos sólidos. Muchos desarrolladores de servidores prefieren código 100% abierto: quieren auditar lo que ejecutan en su máquina, adaptar la lógica a sistemas propios y no depender de la infraestructura de nadie. Para servidores grandes con programadores en plantilla, esa flexibilidad vale dinero.

Por eso el escrow no es la respuesta universal:

• Si tu servidor tiene desarrolladores propios y necesitas integrar cada sistema en profundidad, busca productos open source o versiones sin cifrar cuando existan.
• Para bases de framework, librerías y utilidades compartidas, lo abierto es el estándar del ecosistema, y con razón: son piezas que todo el mundo necesita auditar y extender. En nuestra guía de scripts gratis para FiveM repasamos los imprescindibles de ese mundo.
• Para scripts de gameplay terminados (trabajos, sistemas de economía, mecánicas completas), el escrow con configuración abierta cubre a la mayoría de comunidades: ajustas lo que necesitas ajustar y el mantenimiento corre a cargo del creador.

No es escrow contra open source como bandos irreconciliables: es elegir la herramienta según cuánta personalización profunda necesita tu proyecto. Muchos servidores maduros combinan ambos, incluyendo recursos standalone que funcionan con cualquier framework.

Cómo saber qué es editable antes de comprar

Como las ventas a través de Tebex son finales, este trabajo hay que hacerlo antes del pago. Cuatro comprobaciones rápidas:

1. Lee la página del producto. Una tienda seria indica qué archivos están abiertos: busca menciones a “config abierta”, “locales editables” o “UI abierta”.
2. Revisa la documentación pública. Si puedes leer la guía de configuración antes de comprar, sabrás exactamente qué parámetros existen y qué margen de personalización tienes.
3. Pregunta al soporte. Un vendedor con soporte real te responde en minutos qué incluye el escrow_ignore de su producto. El silencio también es una respuesta.
4. Confirma la compatibilidad. Verifica que el script soporta tu framework (QBCore, ESX, Qbox o standalone) sin ediciones de código cerrado, porque esas no podrás hacerlas.
5. Prueba en desarrollo antes de producción. Los grants pertenecen a tu cuenta de Cfx.re, así que puedes generar una segunda licencia con esa misma cuenta y montar el script primero en un servidor de pruebas. Configúralo con calma ahí y llévalo a producción cuando esté ajustado.

En Cube Resources, todos los scripts protegidos se entregan con la configuración, los locales y la interfaz fuera del escrow, con documentación pública y soporte 24/7 por Discord y tickets para resolver cualquier duda antes y después de comprar.

El escrow de FiveM, bien usado, alinea los intereses de todos: tú ejecutas software legítimo y mantenido, y el creador puede vivir de mantenerlo. Si buscas scripts protegidos con configuración realmente abierta y probados en nuestro propio servidor de roleplay, explora el catálogo completo o entra directamente a la sección de tu framework, como QBCore.