Licencias para estrategias como binario compilado: el espacio de diseño

Los creadores de estrategias quieren monetizar sin regalar el código fuente. Los compradores quieren hacer backtests con sus propios datos y operar con su propio broker. Esas dos exigencias chocan de verdad, y la mayoría de las soluciones actuales resuelven mal el conflicto. Este artículo describe el espacio de diseño que exploramos antes de fijar el licenciamiento por binario compilado como base del marketplace de PineForge.

El problema en términos sencillos

Un creador ha construido algo que funciona. Ha pasado meses afinando parámetros, corrigiendo casos límite y validando fuera de muestra. Quiere venderlo. El comprador quiere ejecutarlo con sus datos, comprobar que el backtest coincide con lo que afirma el creador y enchufarlo a su propia tubería de ejecución.

En el momento en que el creador entrega el código fuente, la monetización se acaba. El comprador puede ejecutarlo sin límite, modificarlo con libertad y revenderlo a otros. El creador ha cobrado una sola venta. Cada comprador posterior es un cliente potencial perdido.

En el momento en que el creador retiene el código fuente, el comprador pierde la capacidad de verificar, afinar o confiar en la estrategia. Se suscribe a una caja negra. Si el servidor del creador cae, su trading se detiene.

Dos soluciones habituales intentan navegar esto. Ambas tienen modos de fallo bien documentados.

Patrón 1: vender el código fuente

El creador vende el script Pine directamente. Una compra única entrega el archivo .pine.

La ventaja para el comprador es real: acceso total, verificabilidad total, control total. Puede hacer backtest con cualquier dato, ajustar parámetros y ejecutarlo de forma independiente del vendedor para siempre.

La desventaja para el vendedor también es real. Una vez transferido el código, no queda palanca continua. La protección contra piratería es tan fuerte como la buena voluntad del comprador. La estrategia puede volver a publicarse en otras plataformas, modificarse y venderse como derivado, o compartirse sin más. Los ingresos quedan limitados al número de compradores honestos de primera vez.

Este modelo encaja con creadores que priorizan la simplicidad frente a ingresos recurrentes. No encaja con quienes tienen estrategias lo bastante valiosas como para protegerlas en un horizonte de varios años.

Patrón 2: vender señales

El creador ejecuta la estrategia por su cuenta y publica señales — entrada, salida y tamaño de posición — en un feed que consumen los suscriptores. El código nunca sale del control del creador.

La ventaja para el vendedor: protección total del código, ingresos por suscripción continua, ninguna transacción única que transfiera todo el valor.

La desventaja para el comprador es grave. No puede hacer backtest de la estrategia con sus propios datos. Debe confiar en el rendimiento histórico que declara el creador. Depende por completo de la infraestructura del creador — vacaciones, caídas del servidor o cierre del servicio dejan al comprador sin nada. Tampoco puede afinar parámetros; recibe lo que el creador configuró.

Los servicios de señales funcionan para compradores sin capacidad técnica para ejecutar estrategias por su cuenta. Para compradores técnicos que quieren entender qué ejecutan y verificarlo de forma independiente, el modelo no sirve.

Patrón 3: vender el binario compilado

El tercer patrón es el que sustenta el marketplace de PineForge. La estrategia Pine se compila a una biblioteca compartida (.so en Linux, .dylib en macOS). El creador distribuye el binario, no el código. El comprador ejecuta el binario contra sus propios datos OHLCV en su propia máquina, mediante el runtime open source de PineForge.

Así se atienden ambos lados de la tensión:

Para el creador: el código nunca sale de su máquina. El binario se compila desde su script Pine, pero revertir un .so compilado a Pine legible exige un esfuerzo considerable — y aun así el resultado es salida a nivel ensamblador, no Pine idiomático. La lógica central de la estrategia queda materialmente protegida.

Para el comprador: el backtest corre en local con sus datos. La ejecución usa su propia integración con el broker. El runtime open source es auditable — un comprador consciente de la seguridad puede leer el código que mueve su dinero, aunque no pueda leer la estrategia en sí. El backtest no depende del servidor del vendedor.

El patrón no es nuevo para PineForge. El ecosistema MetaTrader 4/5 funciona así desde que MQL5 Market arrancó hacia 2012. Las estrategias MetaTrader compilan a binarios .ex5, distribuidos con bloqueo por cuenta y límite temporal vía el marketplace. Los compradores hacen backtest en local en el probador de estrategias de MetaTrader; el código permanece con el desarrollador. Es un modelo probado a escala.

Aplicamos el mismo playbook a Pine, con dos añadidos: más granularidad en los mandos de licencia (abajo) y un runtime open source para que cualquiera pueda auditar la parte que ejecuta sus operaciones.

Las dimensiones de la licencia

Un binario compilado sin marco de licencias es solo un archivo que se puede copiar. La capa de licencia es lo que hace viable el modelo comercial.

Las herramientas para vendedores de PineForge exponen seis dimensiones de licencia:

Acotada en el tiempo. La licencia tiene fecha de caducidad — días, semanas o meses desde la compra. Al expirar, el binario deja de ejecutar estrategias. El comprador puede renovar. El vendedor obtiene ingresos recurrentes. Es la dimensión más habitual; casi toda estrategia del marketplace la usará.

Acotada a la máquina. La licencia va ligada a una huella de hardware. El comprador puede ejecutar la estrategia en la máquina registrada, pero no en una segunda ni en una instancia en la nube. Así se limita el valor de compartir el binario — la máquina del destinatario no tendrá licencia válida. Los vendedores más preocupados por piratería a escala que por el uso casual pueden activarla.

Acotada al broker. La licencia especifica contra qué integraciones de broker puede ejecutarse la estrategia. Un vendedor asociado a APIs concretas puede limitar la ejecución a esas integraciones, evitando usos en venues no soportados o indeseados.

Acotada al símbolo. La licencia restringe los tickers que la estrategia puede operar. Un creador que diseñó y validó su estrategia en BTC/USDT puede distribuir una licencia que solo permita ese símbolo. Evita que un comprador aplique una estrategia optimizada para un activo a otro totalmente distinto, obtenga resultados inesperados y culpe al creador.

Acotada al rango de entradas. El comprador puede afinar parámetros, pero solo dentro de rangos que autoriza el vendedor. Una estrategia con ventana de lookback podría permitir valores entre 10 y 50 barras, pero no por debajo de 10 (donde el creador sabe que hubo sobreajuste fuerte) ni por encima de 50 (donde pierde sentido). El vendedor publica los rangos; el runtime los hace cumplir.

Revocable. El servidor de licencias puede responder 403 en el siguiente chequeo periódico, y entonces el binario deja de ejecutar. Si un comprador incumple — comparte el binario, lo ejecuta en hardware no autorizado — el creador puede revocar sin reembolso ni proceso legal largo. La revocación es la opción nuclear; los vendedores deberían reservarla para incumplimientos claros.

Lo que deliberadamente no hacemos

Nada de teatro de ofuscación tipo DRM. El .so es un binario compilado de verdad. Con tiempo y herramientas adecuadas, un ingeniero puede invertir su lógica. No decimos lo contrario. La licencia es el contrato, no el formato del binario. La protección viene de los términos aceptados por el comprador y del cumplimiento en el runtime, no de la imposibilidad del desensamblado. Pretender que el binario es irrompible sería deshonesto.

Nada de llamadas al servidor en cada backtest. La verificación de licencia es periódica, no por llamada. El runtime cachea una licencia válida en local y consulta el servidor según un calendario (configurable por licencia, por defecto diario). Los backtests funcionan sin red durante la vigencia. No llamamos a casa en cada barra. Eso haría el backtest dependiente de la red y añadiría latencia sin mejora real de seguridad — quien puede interceptar un chequeo puede interceptar cien.

Nada de repartos de ingresos sorpresa. El take rate del marketplace es un porcentaje fijo publicado antes del lanzamiento. Los vendedores en la lista de espera conocen las condiciones antes de publicar. Hemos visto marketplaces que revelan su comisión solo cuando el producto ya está en vivo — lo consideramos mala fe y no lo haremos.

Preguntas abiertas que seguimos tratando

Compromiso de la clave de licencia. Si la máquina del comprador está comprometida y extraen su clave, ¿qué ocurre? Opciones: (a) revocar y reemitir al comprador legítimo, con disrupción; (b) mantener rotación de claves por comprador donde cada instancia de máquina tenga una clave derivada distinta, de modo que comprometer una máquina no comprometa a todos. Nos inclinamos por (b), pero la implementación exige gestión de claves no trivial.

Valores por defecto definidos por el vendedor junto a los rangos. La dimensión de rango permite publicar los límites de cada parámetro. ¿Deberían los vendedores poder publicar también valores por defecto — el valor inicial que ve el comprador al configurar la estrategia? Probablemente sí: un vendedor que sabe que su estrategia rinde mejor con lookback de 20 barras no debería obligar a descubrirlo a prueba y error. Los defaults serían orientativos, no obligatorios.

Informes de «demo backtest» publicados por el vendedor. Antes de comprar, los compradores deberían ver evidencia de que la estrategia funciona — no solo las afirmaciones del vendedor. El plan actual es permitir galerías de informes de backtest (mismo esquema que la galería en /gallery) con sus datos y ventana OHLCV. El informe se verificaría como producido por el motor PineForge con las entradas declaradas. Los compradores ven listas de operaciones reales, Sharpe real, sparklines reales — no una captura de marketing. Es la versión honesta de «véalo antes de comprar».

La alineación open-core

Una preocupación con marketplaces de binarios compilados es que la seguridad del dinero del comprador depende por completo del ejecutor del binario — que en muchos casos es una caja negra propietaria. Si ejecutas un .ex5 en MetaTrader, confías en el runtime de MetaQuotes y en su garantía de que no ejecutará comportamiento no declarado.

El runtime de PineForge tiene licencia Apache-2.0 y está disponible públicamente en ghcr.io/pineforge-4pass/pineforge-engine:latest. El codegen (la parte que compila Pine a C++) es propietaria — ahí está el negocio. Pero el ejecutor — el código que realmente corre el binario contra tu OHLCV y produce listas de trades — es open source.

Así, un comprador exigente puede auditar el ejecutor antes de confiarle el backtesting. No puede auditar el código de la estrategia (ese es el punto), pero sí el contenedor que lo ejecuta. La división es deliberada: lo que toca dinero real abierto; lo que es foso competitivo cerrado.

Calendario del marketplace

La beta arranca en Q4 2026 con onboarding manual de vendedores — una cohorte pequeña de creadores revisados, listados revisados por el equipo y un flujo de compra ágil para compradores. Correremos la beta con transacciones reales y catálogo limitado para detectar problemas de integración antes de escalar.

El marketplace self-serve completo abre en 2027. Entonces los vendedores podrán listar de forma independiente, fijar sus dimensiones de licencia, publicar informes demo de backtest y gestionar el catálogo sin intervención del equipo.

Son fechas honestas, no aspiracionales. El motor y el codegen existen hoy. El servidor de licencias, el panel del vendedor y el flujo de compra del comprador son desarrollo de 2026.

Dónde seguir

• Únete a la lista de espera de vendedores — si construyes estrategias que querrías listar, apúntate y te contactaremos cuando abra el onboarding beta.
• Prueba el runtime hoy — backtest_pine vía el servidor MCP es el mismo ejecutor que usarán las estrategias del marketplace. Si tu estrategia funciona bien en el flujo MCP, funcionará bien en el marketplace.
• Consigue acceso anticipado — el tier gratuito da 100 transpilaciones al mes para construir y validar estrategias antes del lanzamiento del marketplace.