Última verificación: 14 de agosto de 2026. Desde las oleadas de sanciones de Cfx.re en 2025, comprar el recurso equivocado ya no cuesta el precio del script. Puede costar el servidor.
El 8 de agosto de 2025, Cfx.re anunció « two-week suspensions to all servers who are confirmed to have used leaked assets without authorization », precisando que todo servidor reincidente sería eliminado de forma definitiva. El 16 de octubre de 2025 llegó el balance: los equipos habían « suspended hundreds of accounts and servers associated with stolen assets, and permanently banned those confirmed to be in violation ».
Eso cambia la pregunta. Elegir un script FiveM era una decisión de presupuesto. Ahora es una decisión de riesgo, y la mayor parte de ese riesgo es visible antes de pagar, siempre que se sepa dónde mirar.
Esta página enumera siete comprobaciones. Cada una lleva menos de cinco minutos, cada una se hace antes de la transacción, y cada una termina con una pregunta concreta para el vendedor o un comando concreto que ejecutar. Nada de esto te pide que nos creas, y casi todo puede volverse contra nosotros.
Valen para cualquier recurso de pago, script, MLO, vehículo o pack de ropa. Escribimos « script » porque es la palabra que usa la comunidad, pero el escrow también cifra modelos y las sanciones afectan a los assets en general.
Precisión de vocabulario, porque los tres se confunden constantemente: un script open source te deja leer y modificar todo el código; un script escrow está cifrado por el sistema oficial de Cfx.re y solo expone lo que el vendedor decidió dejar abierto; un leak es una copia redistribuida sin autorización, sea cual sea su estado técnico. Los dos primeros son decisiones comerciales. El tercero es lo que hace que baneen un servidor.
Por qué « lee las reseñas » no es un método
Todas las guías de compra del sector acaban en los mismos tres consejos: lee las reseñas, desconfía del código ofuscado, compra a un vendedor de confianza. El primero se manipula, el segundo es imposible en un recurso escrow por construcción, y el tercero es circular. Ninguno es una comprobación. Una comprobación tiene una entrada, un procedimiento y un resultado que pasa o falla.
1. ¿Es el vendedor un creador acreditado por Tebex?
Cfx.re lo escribe sin ambigüedad: solo los creadores acreditados por Tebex son revendedores autorizados de assets de FiveM y RedM. No es un sello de calidad, es una regla de autorización, y decide si tienes algún recurso.
Tres cosas que verificar, en este orden:
- El pago pasa por Tebex. Ni una transferencia por Discord, ni un PayPal entre amigos, ni una dirección cripto.
- La entrega llega a tu Cfx.re Portal, no en un
.zippor mensaje privado. Un recurso entregado en archivo comprimido no pasó por el sistema escrow, diga lo que diga el vendedor. - El vendedor tiene un hilo de release en forum.cfx.re con un historial fechado. Un vendedor activo desde hace años deja un rastro público. Sin rastro, o empieza o cambió de nombre tras un incidente.
Fuera de ese circuito no hay recurso que perder: no hay ninguno
Es el punto que la mayoría de compradores entiende demasiado tarde, y no exige confiar en nadie, se deduce del funcionamiento.
Una compra fuera de Tebex no produce ninguna entrega en el Portal, por tanto ningún entitlement asociado a tu cuenta Cfx.re. No tienes un recurso mal comprado: tienes una carpeta de archivos, y nada que acredite que puedes ejecutarla. No hay recurso que reclamar porque no existe ningún registro de la transacción del lado de la plataforma.
Adopta muchas formas. Tiendas montadas fuera de Tebex. Anuncios en marketplaces generalistas de servicios. Y sobre todo servidores de Discord dedicados a la reventa, a menudo junto a cheats y otras herramientas ilegales, donde primero se paga y luego se espera.
No pretenderemos medir la frecuencia de las estafas en ese circuito, y desconfiamos de los artículos que lo afirman sin demostrarlo. El razonamiento basta: en una transacción sin registro, sin plataforma y sin identidad verificada, lo único que garantiza la entrega es la buena voluntad del vendedor. No te precipites porque una oferta caduque en dos horas. Es exactamente el momento en que nadie verifica nada.
Esta primera comprobación sostiene las seis siguientes. En un recurso escrow no puedes leer el código: todo lo que no puedes verificar tú mismo se traslada a la responsabilidad del vendedor. Por eso va primera y no última.
2. ¿Es legítimo el asset, y qué arriesga tu servidor?
Es el capítulo que las guías de compra se saltan, porque resulta incómodo de escribir para un vendedor.
« No sabía que era un leak » no es una categoría reconocida. Las sanciones de 2025 apuntaron a servidores confirmados como usuarios de assets no autorizados, y un recurso descifrado es detectable en el servidor con independencia de la intención del comprador. Tu buena fe no es una propiedad técnica del archivo.
Cinco señales que descartan una oferta antes incluso de mirar el código:
- Un pack de treinta o cuarenta scripts premium por menos de veinte euros. La aritmética no cuadra. Los bundles legítimos existen, pero agrupan el catálogo de un solo estudio, no una muestra de los lanzamientos de pago del mercado.
- Una entrega por archivo comprimido en lugar de por el Portal.
- Un script premium conocido revendido bajo otra marca, a menudo con el archivo de configuración original intacto.
- Ningún changelog. Un recurso mantenido tiene un historial de versiones. Uno copiado tiene una fecha de descarga.
- Un vendedor que se niega a indicar la cuenta Cfx.re a la que se vinculará la compra.
3. ¿Qué podrás seguir modificando después de pagar?
En un script escrow el código está cifrado por el sistema oficial de Cfx.re. Pero el desarrollador elige qué deja legible, con la directiva escrow_ignore de su fxmanifest.lua.
La consecuencia lo es todo, y casi nadie la formula: lo que queda abierto es una decisión del vendedor, no una propiedad del escrow. Dos scripts escrow al mismo precio pueden estar separados por un abismo en cuanto a adaptación. Si un ajuste no está expuesto en un archivo de configuración abierto, es inaccesible para siempre, ni por ti ni por tu desarrollador.
De ahí la pregunta que hay que hacer antes de pagar, la que separa a un vendedor serio de un revendedor:
¿Qué contiene tu
escrow_ignore?
Cuatro cosas deberían figurar en él, y la cuarta es la que nadie reclama:
- La configuración, si no ningún ajuste es modificable.
- Los archivos de traducción, si no no puedes adaptar ni una palabra a tu universo.
- Los archivos de bridge, si no no puedes conectarlo a tu framework.
- El esquema SQL de instalación. Es el que te dice qué tablas creará el recurso en tu base de datos, y por tanto qué hará allí. Leerlo antes de instalar lleva dos minutos.
Un vendedor que no sabe responder, o que responde de forma evasiva, acaba de decirte algo importante.
No volvemos a explicar aquí el mecanismo del escrow. Mantenemos una página fechada sobre el estado del Asset Escrow en FiveM Enhanced, que trata otra cuestión, la de su disponibilidad.
4. ¿Se puede detectar una backdoor antes de arrancar el recurso?
Esta comprobación solo se aplica al código que puedes leer: los recursos open source y los archivos que un vendedor dejó fuera del escrow. En un recurso totalmente cifrado no sirve de nada, y todo vuelve a la primera comprobación. Cualquier guía que te pida « inspeccionar el código » de un script escrow describe algo imposible.
Una backdoor no rompe nada necesariamente, y ese es el problema
Uno se imagina un script que destruye la base de datos o vacía las cuentas bancarias. En la práctica, una backdoor que se nota ha fracasado. Las que duran no rompen nada.
Hemos visto servidores ejecutando recursos comprometidos, y la frecuencia es claramente mayor en scripts procedentes de un leak que en recursos comprados a un creador con tienda oficial. Se repiten dos familias.
La extracción de datos. La más conocida: el recurso lee tu base de datos y envía lo que pueda ser explotable. Nada falla, nada alerta, y el servidor funciona perfectamente mientras sus datos salen.
Los eventos dejados abiertos para permitir el cheat. Esta es menos conocida y más taimada. El recurso incorpora eventos explotables que permiten a un cheat hacer cosas indetectables en tu servidor. No siempre es negligencia: a veces se hace en colaboración con creadores de cheats, cuya herramienta parece entonces más potente que la de la competencia. Lo que se vende no es el script, es la puerta.
La consecuencia práctica es simple: la reputación del creador no es un detalle accesorio. Unas cuantas búsquedas sobre su nombre, su historial y sus hilos públicos suelen bastar para saber con quién hablas.
Tres patrones que buscar en el código legible
Un evento de servidor que escribe sin comprobar quién lo llama. Cualquier cliente puede disparar un evento de red registrado. Si el manejador confía en sus argumentos, cualquier jugador puede pasarle cualquier cosa.
RegisterNetEvent('shop:giveItem', function(item, amount)
MySQL.update('UPDATE users SET money = money + ?', { amount })
end)La señal es la ausencia de validación de source y la ausencia de control en servidor sobre la legitimidad de la petición. Es también exactamente la forma que adopta un evento dejado abierto a propósito.
Una llamada HTTP a un host que no es el del vendedor. Las verificaciones de licencia existen y son normales. Una verificación de licencia hacia un dominio sin relación con el vendedor, que envía más que un identificador, no lo es.
Una cadena decodificada y ejecutada al cargar. Un recurso legítimo no tiene razón alguna para construir código en ejecución desde una cadena codificada.
Un barrido rápido de tu carpeta resources, antes de arrancar nada:
grep -rn "PerformHttpRequest|load(|assert(load|_G[" resources/La comunidad describe además un síntoma recurrente que conviene saber nombrar: código que reaparece al final de client.lua, config.lua o server.lua después de haberlo borrado. Si ocurre, el recurso no es algo que reparar, es algo que retirar.
5. ¿Cuánto cuesta realmente el script en rendimiento?
Las fichas de producto anuncian 0.00 ms por docenas. La cifra suele ser cierta y casi siempre irrelevante, porque está medida en reposo: recurso cargado, nadie dentro, nada ocurriendo. Es el equivalente a anunciar un consumo con el motor apagado.
Un recurso se mide en tres estados:
| Estado | Lo que mides |
|---|---|
| En reposo | El script está cargado, nadie lo usa |
| En uso | Un jugador interactúa activamente con él |
| En pico | El peor caso realista, varios jugadores a la vez |
Las referencias, tomando las convenciones de trabajo de la comunidad y no una norma oficial: a 60 Hz, el presupuesto de un frame entero es de 16,67 ms para todo lo que corre. Un recurso sano se mantiene entre 0,00 y 0,05 ms en reposo. Por encima de 0,10 ms conviene mirar de cerca. Por encima de 0,5 ms en reposo, algo va mal, y eso antes de que ningún jugador lo haya tocado.
Para medirlo tú mismo: F8, y luego resmon 1.
Cómo es una medición honesta
Ya que pedimos tres estados, aquí están los nuestros sobre avenida_interact, con el banco de pruebas correspondiente. Sin el protocolo, una cifra no significa nada.
El banco: 100 puntos de interacción fijos, 100 puntos de interacción con NPC y ventana de diálogo, y la detección vinculada a 50 modelos de entidad distintos. Eso representa un servidor ya avanzado, no una escena de demostración.
| Situación | Medición | Por qué |
|---|---|---|
| Jugador en reposo, ninguna interacción a la vista | 0,00 ms | Nada que evaluar |
| Jugador en coche, el cliente evalúa si debe mostrar algo | 0,01 ms | Durante una fracción de segundo, mientras comprueba |
| Un punto de interacción mostrado en 3D en el mundo | 0,08 ms | Coste de renderizado, mientras siga visible |
| Ventana de diálogo con NPC abierta | 0,06 ms | El punto 3D se libera al abrir en lugar de seguir mostrándose |
Esta última cifra es la más instructiva, y es una decisión de diseño más que una medición: abrir un diálogo libera el punto 3D en lugar de dejarlo vivo detrás de la ventana. El coste baja en el momento en que el jugador mira a otro lado. Es el tipo de compromiso que una medición en tres estados hace visible, y que un 0.00 ms en reposo oculta por completo.
core_interact. Hay un punto de interacción mostrado en 3D en la escena, y la lectura indica 0,08 ms, el valor medido en el banco de pruebas. Captura del 14 de agosto de 2026.Un punto ciego que casi todas las guías comparten: un script puede ser ligerísimo en cliente y aun así aplastar tu base de datos. Cuenta también las consultas SQL por acción. Un recurso que consulta la base en cada frame de una interacción no aparecerá en la cifra de cliente, y es el que duele con sesenta jugadores. También por eso el esquema SQL abierto, en la comprobación 3, no es un detalle.
6. ¿Es real la compatibilidad con frameworks o solo está anunciada?
« Compatible con ESX y QBCore » no significa nada en sí, porque ninguno de los dos es una sola cosa.
Cuatro preguntas que hacer:
- ¿Qué ESX? Legacy y 1.2 no son intercambiables.
- ¿Qué QBCore?
qb-corey Qbox han divergido, y la respuesta depende de la versión. - ¿Y vRP? La pregunta parece secundaria vista desde Europa, pero no lo es. Brasil es el primer mercado de FiveM fuera del ámbito anglosajón en número de jugadores, y la mayoría de sus servidores funcionan con vRP, no con ESX ni QBCore. Un vendedor que nunca ha oído esa pregunta no ha mirado más allá de su propio mercado.
- ¿Están los exports y los eventos expuestos en un archivo sin cifrar?
La cuarta es la prueba real. Un vendedor que expone el bridge te dice que espera que adaptes. Un vendedor que no lo expone te pide que adaptes tu servidor a sus decisiones.
Y la buena pregunta siguiente es la del fallback: ¿qué hace el recurso cuando no hay ningún framework conocido? Una compatibilidad seria prevé un modo autónomo que no depende de nada, no solo dos ramas para los dos frameworks más extendidos.
Sobre la pregunta que la gente teclea justo antes de darle a comprar, si un script de QBCore funciona en Qbox, la respuesta honesta es: en gran medida sí, no de forma sistemática. Las dependencias y algunos exports difieren. Quien responde que sí sin matices está vendiendo, no aconsejando.
7. ¿Qué pasa después de la compra?
Tres trampas de posventa que ninguna página suele reunir.
El error de entitlement. Tarde o temprano te encontrarás con You lack the required entitlement to use this resource, y es muy frecuente. Significa que la clave de servidor en uso fue generada por una cuenta Cfx.re distinta de la que hizo la compra. Un servidor funciona con una sola clave, y puedes comprobar cuál con sv_licenseKey en la consola. La forma clásica de caer es la precipitación: se compra con la cuenta que se tiene a mano, no con la que generó la clave. La buena noticia es que tiene arreglo: una transferencia de propiedad desde el Portal Cfx.re corrige el error. Pero esa transferencia normalmente solo es posible una vez, así que conviene no gastarla por descuido.
El reembolso. Para un contenido digital, el derecho de desistimiento se extingue en cuanto empieza la ejecución con tu consentimiento, lo que para un script significa la primera descarga. Las políticas observadas en este mercado van de catorce días sin justificación a estrictamente no reembolsable. Lo que importa es que la política esté escrita y leída antes de pagar.
La suscripción. En un recurso vendido por suscripción, la expiración retira el asset de la cuenta y el script deja de arrancar. Nada se rompe, nada se borra, simplemente se detiene.
Lo que hemos visto sobre el terreno
No escribimos esta página desde un despacho de estudios. La escribimos porque cometimos prácticamente todos los errores que describe.
Nuestro equipo empezó montando su propio servidor, entre amigos. Ninguno de nosotros sabía realmente cómo funcionaba un servidor FiveM, y menos aún qué se arriesgaba. Aprendimos como todo el mundo, con tutoriales de puesta en marcha encontrados en internet.
Compramos para ganar tiempo
La comunidad creció más rápido que nuestra capacidad de desarrollo. Cada semana traía peticiones para las que no teníamos horas. Comprar scripts no era una comodidad, era la única manera de aguantar el ritmo sin hacer esperar a nuestros jugadores.
Es exactamente la situación en la que menos se verifica. Es también exactamente aquella en la que más habría que verificar.
Lo que acabamos entendiendo
Tres cosas, que se repetían con tanta regularidad que acabaron estructurando esta página.
Rendimientos que no tenían nada que ver con lo anunciado. Recursos vendidos como los más optimizados del mercado nos costaban milisegundos que no podíamos permitirnos. La cifra anunciada no era falsa. Estaba medida en condiciones que no se parecían a nada.
Scripts anunciados como adaptables a cualquier servidor, e imposibles de adaptar al nuestro. A menudo sin mala voluntad del vendedor: nada estaba expuesto en configuración. Cuando pedíamos una modificación, no estaba prevista, y no teníamos forma de hacerla nosotros mismos.
Recursos publicados y luego abandonados. Esos no se rompen el día de la compra. Se rompen más tarde, cuando FiveM evoluciona y ya nadie mantiene nada al otro lado. En ese momento no has comprado un script, has alquilado un plazo.
Lo que eso cambió en nuestra forma de construir
Nuestros scripts exponen su configuración, sus traducciones, sus bridges y su esquema SQL en claro. No es un favor comercial, es la respuesta directa a lo que sufrimos: no queríamos vender lo que habíamos odiado comprar.
No escribimos esta página para vender. La escribimos porque nadie nos la dio.
La checklist en siete líneas
- ¿El pago pasa por Tebex, con entrega en el Cfx.re Portal? Es imperativo.
- ¿Tiene el vendedor un historial de releases fechado en forum.cfx.re? Debe existir.
- ¿Es plausible el precio para lo que se vende? Un pack de treinta scripts premium por veinte euros no lo es.
- ¿Qué contiene el
escrow_ignore? Config, locales, bridges y el esquema SQL. - ¿Hay mediciones de resmon en tres estados, con el protocolo? Pide las tres y el banco de pruebas.
- ¿Qué versiones exactas de framework, qué fallback sin framework, y es legible el bridge? Números de versión, no nombres.
- ¿Qué cuenta Cfx.re será propietaria del asset, y cuál es la política de reembolso escrita? Antes de pagar, no después.
Preguntas frecuentes
¿Pueden banearme por un leak comprado de buena fe? Las sanciones de 2025 apuntaron a servidores confirmados como usuarios de assets no autorizados. La intención no es una propiedad técnica de un archivo, y por eso la verificación debe hacerse antes de la compra y no después de la suspensión.
¿Se puede modificar un script escrow? Únicamente las partes que el desarrollador dejó fuera del cifrado mediante escrow_ignore. Todo lo demás está cerrado de forma definitiva. Pregunta qué contiene esa directiva antes de comprar, no después.
¿Existe un script a 0,00 ms? En reposo, muchos. En uso, no. Una cifra sin estado de medición ni protocolo anunciados no te dice nada.
¿Cómo saber si un script contiene una backdoor? En código legible, buscando los tres patrones descritos arriba. En un recurso escrow es imposible, y la pregunta pasa a ser la reputación del creador. Ten en cuenta además que una backdoor no rompe nada: extrae datos, o deja una puerta abierta a un cheat.
¿Son los scripts gratuitos compatibles con todos los frameworks? No más que los de pago. La pregunta es idéntica en ambos casos: qué versión de framework, qué fallback sin framework, y si el bridge es legible.
¿Tebex reembolsa? Tebex cobra el pago, el vendedor fija la política. Va de catorce días a nada en absoluto, y el derecho de desistimiento sobre un contenido digital se extingue en la primera descarga.
¿Dónde encontrar scripts gratuitos fiables? Las verdaderas organizaciones de referencia, en GitHub: esx-framework, qbcore-framework, overextended para ox_lib y ox_inventory, y citizenfx. Empezar en otro sitio para un recurso gratuito es la forma más común de acabar con una backdoor.
Qué dan estas comprobaciones sobre nuestros propios scripts
Esta página vale sobre todo si puede volverse contra nosotros. Así que aquí está dónde se verifica cada criterio en Avenida, y lo que todavía no cumplimos.
Lo que está abierto. Nuestro escrow_ignore expone la configuración, las traducciones, los bridges, el changelog y el esquema SQL de instalación. Puedes por tanto leer lo que el recurso creará en tu base de datos antes de instalarlo, y ajustar el comportamiento sin pedirnos permiso. Solo la lógica interna queda protegida. Un caso concreto: las 368 correcciones de zona del estudio de tatuajes viven en un archivo de config que puedes seguir corrigiendo tú.
La compatibilidad. Nuestros scripts detectan ESX, QBCore y vRP, y recurren a un modo autónomo cuando no hay ningún framework presente, apoyándose en las natives del juego. Un modo personalizado conecta cualquier otra cosa, y los sistemas de inventario, notificación e interacción más extendidos vienen preconfigurados. Los archivos de bridge son legibles, así que esta afirmación es verificable y no solo declarativa: la ficha de la barbería enumera sus siete bridges y dice qué te cuesta cada objetivo, vRP incluido.
El reembolso. Nuestra política está escrita, y es estricta: sin reembolso por norma, con una excepción si el script no es funcional y el problema no se resuelve en siete días hábiles. Lo asumimos en lugar de ocultarlo. Un producto digital entregado, funcional y usado durante semanas no se devuelve, y la energía que no gastamos en arbitrar peticiones improcedentes la dedicamos a hacer evolucionar los scripts.
El rendimiento. Cada ficha de producto lleva ya su medición en reposo y las condiciones en que se tomó, que era justo la carencia que este artículo señalaba al publicarse. Lo que aún falta son los estados en carga y bajo presión en el mismo sitio: pídenoslos para cualquier recurso, y exígenoslo mientras no estén en las fichas.
Ver cómo se verifican estos criterios en el catálogo.Historial de esta página
- 19 de agosto de 2026. Dos afirmaciones de la última sección habían envejecido y se han corregido: vRP es un objetivo detectado y no una rama personalizada, y la medición en reposo ya se publica en cada ficha de producto.
- 14 de agosto de 2026. Publicación inicial. Verificación de los anuncios de Cfx.re del 8 de agosto y del 16 de octubre de 2025, y de la documentación de Asset Escrow.
Fuentes oficiales
Todas las afirmaciones factuales de esta página proceden de la documentación y las comunicaciones oficiales de Cfx.re, el editor de FiveM. Las mediciones de rendimiento son nuestras, con su protocolo.
- Asset Security Update, foro Cfx.re: los anuncios de sanciones del 8 de agosto y del 16 de octubre de 2025.
- Documentación de Asset Escrow: formatos cifrados y directiva
escrow_ignore. - What’s a leaked asset then?: la discusión de referencia sobre la definición.
¿Una duda sobre un script antes de comprar, sea nuestro o de otro? Lo más sencillo es unirte a nuestro Discord. También respondemos sobre scripts que no vendemos.
