Runtime nativo de IA para estrategias de trading en Ripio
Desarrolla en Cursor, Claude Code o cualquier IDE de IA. Despliega desde GitHub en un runtime gestionado en la nube con control MCP de primer nivel, logs y selección de región.
Sección 01 · De un vistazo
De un vistazo
- Plataforma
- Ripio
- Tipo de plataforma
- Exchange de criptomonedas (LATAM, 8 jurisdicciones)
- Clase de activo
- Cripto con cotización multi-fiat LATAM (BRL, ARS, MXN, EUR, USD)
- Productos compatibles
- Trading spot en pares filtrados por país (BTC_BRL, ETH_BRL, BTC_ARS, BTC_MXN, BTC_EUR y otros), stablecoins locales (wARS, wBRL, wMXN), Ripio Trade API v4
- Modelo de ejecución
- Runtime de estrategias en contenedores
- Origen del despliegue
- GitHub
- Lenguajes
- Cualquier lenguaje que se ejecute en un contenedor
- Integraciones habituales
- API v4 nativa de Ripio Trade (REST y WebSocket), CCXT, conectores personalizados
- Integración con flujos de trabajo de IA
- Superficie de control MCP para Cursor, Claude Code, GitHub Copilot y agentes de CLI
- Rol de TradingHost
- Runtime, despliegue, logs, comprobaciones de estado, selección de región, control MCP
- Rol de Ripio
- Cuenta de exchange, acceso a la API, acceso al mercado, lugar de ejecución
- Afiliación
- TradingHost es independiente y no está afiliado a Ripio
Sección 02 · Qué ofrece Ripio
Qué ofrece Ripio
Ripio ofrece trading spot en 8 jurisdicciones de LATAM con pares cotizados en múltiples monedas fiat (BRL, ARS, MXN, EUR, USD) y stablecoins locales (wARS, wBRL, wMXN). Las estrategias se autentican contra la API v4 de Ripio Trade y operan bajo límites de frecuencia escalonados según el estado de KYC. La disponibilidad de pares filtrados por país mediante el parámetro de consulta `countries` permite desplegar una misma estrategia para diferentes conjuntos de productos regionales. Los detalles específicos de los endpoints cambian con el tiempo. La estructura general es estable; los pesos exactos de los límites de frecuencia, las listas de pares y los tamaños mínimos se encuentran en la documentación de Ripio.
Mercados y patrones de estrategia
- Estrategias spot con cotización en BRL (BTC_BRL, ETH_BRL, USDC_BRL)
- Estrategias spot con cotización en ARS para pares en pesos argentinos
- Estrategias spot con cotización en MXN para pares en pesos mexicanos
- Trading de stablecoins locales (wARS, wBRL, wMXN)
- Estrategias de arbitraje entre monedas fiat de LATAM
- Descubrimiento de pares filtrados por país mediante el parámetro de consulta `countries`
- Suscripciones de WebSocket autenticadas por ticket para canales sensibles
- Planificación del uso de límites de frecuencia según el nivel de KYC por cuenta
Interfaz de la API
- Áreas de producto
- Trading spot en pares filtrados por país en Argentina, Brasil, México, España, Uruguay, Colombia, Chile y EE. UU. Los códigos de los pares utilizan la notación con guion bajo (BTC_BRL, ETH_BRL, BTC_ARS, BTC_MXN). Las stablecoins locales (wARS, wBRL, wMXN) permiten operar directamente con monedas digitales. Los valores de `min_amount`, `min_value` y `price_tick` deben consultarse para cada par.
- Métodos de conexión
- REST para colocación de órdenes, consultas de cuenta y descubrimiento de pares. Canales de WebSocket para datos de mercado en tiempo real. El acceso a canales sensibles de WebSocket requiere un ticket obtenido mediante POST `/v4/ticket` antes de la suscripción, no solo una clave de API.
- Autenticación
- Límites de frecuencia de API escalonados según el estado de KYC. Cuentas no verificadas: 1 solicitud por segundo (~86,400 diarias). Cuentas verificadas: 3.5 solicitudes por segundo (~302,400 diarias). Superar el límite del nivel devuelve un error HTTP 429 con la cabecera estándar retry-after.
Para más detalles, consulte Ripio
Los endpoints específicos, los pesos de los límites de frecuencia, las listas de pares, los niveles de comisiones y el historial de versiones se encuentran en la documentación de Ripio. Considéralos como la fuente de verdad.
Sección 03 · Desarrollar con IA
Desarrolle su estrategia para Ripio con IA
Elija un método de integración, haga un fork de una plantilla de TradingHost y desarrolle su estrategia en un IDE de IA. Cursor, Claude Code, GitHub Copilot y los agentes de IA basados en CLI funcionan con el mismo flujo de despliegue nativo de GitHub.
API nativa de Ripio
Control directo sobre el comportamiento específico de Ripio, incluyendo el descubrimiento de pares filtrados por país y el enrutamiento de órdenes en monedas fiat de LATAM.
CCXT
Interfaz común para Ripio y otros exchanges de criptomonedas. CCXT expone Ripio Trade a través de la clase unificada `ripio` para trading spot.
Freqtrade o Hummingbot
Ninguno de los dos frameworks incluye actualmente a Ripio como exchange con soporte nativo de primer nivel. La mejor opción es utilizar implementaciones personalizadas o basadas en CCXT.
Conector personalizado
Tu propio motor de trading interno o una integración propia con la API v4 de Ripio Trade mediante REST y WebSocket.
Compatibilidad de frameworks con productos de Ripio
La cobertura varía según el framework. Ripio solo ofrece trading spot a nivel de exchange (no hay perpetuos ni opciones nativas en Trade), por lo que la matriz es reducida por diseño. CCXT expone el mercado spot de Ripio Trade a través de su clase unificada `ripio`. Ni Freqtrade ni Hummingbot ofrecen soporte nativo de primer nivel para Ripio actualmente; el acceso a la API nativa permite llegar a todo lo que publica Ripio Trade v4.
✓ soporte confirmado según la documentación oficial del framework. "no" indica que no está documentado oficialmente como compatible. Los enlaces de flujos de trabajo dirigen a páginas de /workflows/ actualmente en desarrollo.
TradingHost no impone ningún framework. Simplemente ejecuta su proyecto.
Desarrollo con IA
Las plantillas de inicio anteriores se integran de forma natural con los IDE de IA. La interfaz de control MCP de TradingHost completa el ciclo: las herramientas de IA pueden inspeccionar despliegues, revisar registros y gestionar el entorno de ejecución junto a usted, sin intervenir nunca en la ruta de ejecución de las operaciones.
Sección 04 · Ejecutar en TradingHost
Ejecuta tu código en TradingHost
Ripio proporciona el exchange y el acceso a la API. TradingHost proporciona el entorno de producción donde se ejecuta tu estrategia conectada a Ripio.
En lugar de ejecutar el código de tu estrategia en un portátil, un ordenador de escritorio, un VPS genérico o un servidor configurado manualmente, realizas el despliegue desde GitHub en un entorno de ejecución de contenedores gestionado por TradingHost.
Tú
- Tu repositorio contiene tu código.
- Tu despliegue define cómo se ejecuta.
- Tu estrategia se conecta a Ripio.
TradingHost
- Mantiene el entorno de ejecución en línea.
- Muestra los logs y las comprobaciones de estado.
- Selección de región.
- Superficie de despliegue controlada.
Flujo de despliegue
- PASO 01
Conecta GitHub
Autoriza a TradingHost para acceder a tu cuenta de GitHub.
- PASO 02
Vincula un repositorio o empieza desde un framework
Vincula TradingHost a tu repositorio de estrategias existente, o haz un fork de un runtime de framework de TradingHost (CCXT) para obtener una base funcional con la API v4 de Ripio Trade.
- PASO 03
Desplegar en un contenedor de TradingHost
Selecciona una región (EU o US-East), proporciona las variables de entorno que necesita tu estrategia (clave de API de Ripio Trade, código de país, configuración de tickets de WebSocket) y despliega. TradingHost compila tu contenedor desde el repositorio y ejecuta tu estrategia en una infraestructura gestionada de Kubernetes. No se requiere instalar Docker localmente.
- PASO 04
Monitorear logs y estado de salud
Siga en tiempo real los logs, el estado de salud y el estado del runtime desde el panel de control de TradingHost. Se puede acceder a la misma interfaz mediante MCP desde cualquier AI IDE, de modo que Cursor, Claude Code o un agente de CLI pueden leer el estado del despliegue y gestionar el runtime junto con usted.
- PASO 05
Actualizar y redesplegar
Suba los cambios a su rama principal de GitHub y TradingHost realizará el redespliegue automáticamente.
Sección 05 · Notas operativas
Notas operativas para Ripio
Problemas con los que te toparás al ejecutar una estrategia para Ripio en un runtime en la nube basado en contenedores, que no aparecen en la documentación de Ripio ni en los archivos README de los frameworks. Cada afirmación a continuación es una cita o paráfrasis de la propia documentación de Ripio; la guía de despliegue proviene de la ejecución de estas estrategias en TradingHost.
01 · Límites de frecuencia según el nivel de KYC
Las cuentas no verificadas obtienen 1 rps; las verificadas obtienen 3.5 rps
Los límites de frecuencia de la API v4 de Ripio Trade se definen según el nivel de KYC en lugar de por familia de endpoints. Las cuentas no verificadas están limitadas a 1 solicitud por segundo (alrededor de 86,400 diarias). Las cuentas verificadas pasan a 3.5 solicitudes por segundo (alrededor de 302,400 diarias). Superar el límite del nivel devuelve un error HTTP 429. Una estrategia que se despliega en modo no verificado y luego se promueve a verificado puede cuadruplicar su frecuencia de consulta segura; por el contrario, una estrategia diseñada para el nivel verificado que se ejecute en una cuenta no verificada se topará con errores HTTP 429 desde el primer día. Define el nivel de KYC en la configuración de ejecución para que el presupuesto de límites de frecuencia sea explícito.
02 · Pares filtrados por país
El parámetro de consulta `countries` es la fuente de verdad para los pares negociables
Ripio opera en 8 jurisdicciones (AR, BR, MX, ES, UY, CO, CL, US) con niveles de cumplimiento específicos por país, y la disponibilidad de pares se filtra a través del parámetro de consulta `countries` en lugar de una lista global de símbolos plana. Un par que se negocia en Brasil puede no estar disponible en Argentina, y viceversa. Las estrategias que definen de forma estática (hardcode) una lista de símbolos basada en el conjunto de productos brasileños fallarán silenciosamente (no-op) al ejecutarse para una cuenta argentina. Descubra los pares al iniciar la estrategia mediante el endpoint filtrado por país en lugar de fijarlos en el código.
03 · Los códigos de pares usan guion bajo
BTC_BRL y ETH_BRL, no BTCBRL
Los códigos de pares de Ripio utilizan la notación con guion bajo: BTC_BRL, ETH_BRL, BTC_ARS, BTC_MXN, BTC_EUR. Esta convención difiere de Binance y de la mayoría de las plataformas globales donde los pares se concatenan (BTCBRL). CCXT normaliza el símbolo a BTC/BRL en su interfaz unificada, pero cualquier petición que consulte directamente la API nativa debe usar el formato con guion bajo. El código de una estrategia portado desde otra plataforma suele fallar silenciosamente con un error de par no encontrado hasta que se corrige el formato.
04 · Mínimos por par
`min_amount`, `min_value` y `price_tick` son específicos de cada par y deben consultarse
Los mínimos de par y los ticks de precio son específicos de cada par fiat. Los pares de BRL, ARS y MXN tienen sus propios valores de `min_amount`, `min_value` y `price_tick`, los cuales deben consultarse por par antes de colocar una orden. Una estrategia que use un único mínimo estático para pares de BRL y ARS abrirá posiciones con un tamaño inferior o superior al previsto de forma silenciosa según el país activo. Almacene en caché los campos específicos de cada par al iniciar la estrategia y vuelva a validarlos antes de cada orden en lugar de asumir un mínimo global.
05 · Autenticación de WebSocket mediante ticket
Los canales sensibles de WebSocket requieren un ticket obtenido de POST `/v4/ticket`
Los canales públicos de WebSocket (datos de mercado, libro de órdenes) están abiertos. Los canales sensibles (estado de la cuenta, eventos de órdenes) requieren un ticket obtenido mediante POST `/v4/ticket` antes de suscribirse, no solo una clave API. El ticket tiene un tiempo de vida (TTL) corto y debe renovarse periódicamente en estrategias de ejecución continua. Los contenedores que pierdan la conexión WebSocket y vuelvan a conectarse deben solicitar un ticket nuevo cada vez; reutilizar un ticket caducado provocará que la suscripción falle silenciosamente y las funciones de callback del estado de las órdenes dejen de ejecutarse.
06 · Stablecoins locales
wARS, wBRL y wMXN permiten operaciones directas con monedas digitales
Ripio emite las stablecoins locales wARS, wBRL y wMXN, que permiten operar directamente con activos digitales en los mercados de BRL, ARS y MXN. Estas difieren de USDT/USDC y pueden presentar características distintas de liquidez, liquidación y comisiones. Las premisas de las estrategias diseñadas para USDT no se trasladan automáticamente a wARS o wBRL. Valide la profundidad y el spread en los pares de stablecoins locales de forma independiente antes de definir el tamaño de su exposición real.
Sección 06 · Diseñado para
Diseñado para
Los runtimes de TradingHost para Ripio son ideales para:
- Desarrolladores que crean estrategias en IDE de IA (Cursor, Claude Code)
- Traders sistemáticos de criptomonedas
- Desarrolladores cuantitativos (quants)
- Usuarios de CCXT
- Equipos que migran de hosting VPS a despliegues en contenedores
Conectar GitHub y crear su primera estrategia es gratis.
Sección 08 · Preguntas frecuentes
Preguntas frecuentes
No. TradingHost es independiente y no está afiliado a Ripio.
No. El código de su estrategia se conecta a Ripio y envía instrucciones según su propia lógica, los permisos de su cuenta y el método de integración. TradingHost proporciona el entorno de ejecución (runtime) donde se ejecuta dicho código.
No. El acceso a la API de Ripio lo proporciona Ripio. Usted es responsable de su cuenta de Ripio, los permisos de la API, las credenciales y el cumplimiento de los términos de servicio de Ripio.
No. TradingHost es el entorno de ejecución en la nube donde se ejecuta el código de su estrategia. No proporcionamos señales, modelos de predicción de IA ni bots preconfigurados. Con TradingHost, usted escribe o genera la estrategia por su cuenta (a menudo con Cursor o Claude Code), la mantiene en GitHub como su propio código y utiliza TradingHost para ejecutarla en producción. Productos como 3Commas o Cryptohopper son dueños de la lógica de la estrategia; TradingHost ejecuta la suya.
AWS y DigitalOcean le ofrecen capacidad de cómputo pura. Usted debe encargarse de las actualizaciones del sistema operativo, la orquestación de contenedores, el envío de logs, la rotación de secretos, la redundancia regional y el monitoreo de disponibilidad. TradingHost le ofrece un entorno de ejecución administrado y diseñado específicamente para estrategias de trading: despliegue nativo desde GitHub, control mediante MCP desde IDE de IA, y paneles integrados de logs y estado de salud. Si prefiere gestionar la infraestructura usted mismo, AWS es una opción. Si prefiere el entorno de ejecución como un servicio administrado, TradingHost es el camino más rápido.
Sí. TradingHost ejecuta estrategias en Python; elija el entorno de ejecución de framework que se adapte a su stack tecnológico o despliegue su propio repositorio.
Sí. TradingHost es compatible con cualquier lenguaje que pueda ejecutarse dentro de un contenedor.
Sí. CCXT incluye una clase `ripio` unificada que cubre el trading spot en los pares de Ripio Trade. Coloque su estrategia de CCXT en un contenedor, conéctela a GitHub y TradingHost la ejecutará como cualquier otro proyecto de Python o Node. Consulte el entorno de ejecución del framework CCXT para ver los detalles de configuración.
Sí. Se accede a los pares fiat de Latinoamérica en Ripio (BTC_BRL, ETH_BRL, BTC_ARS, BTC_MXN, BTC_EUR, entre otros) a través de las mismas API REST y WebSocket que los pares globales. El código de la estrategia dentro de su contenedor se autentica con su clave API de Ripio Trade, y TradingHost es independiente de la plataforma a nivel de entorno de ejecución. Tenga en cuenta que la disponibilidad de los pares se filtra por país mediante el parámetro de consulta `countries`, por lo que se recomienda detectar los pares al iniciar la estrategia en lugar de definirlos de forma estática.
Sí, siempre que su proyecto esté diseñado de esa manera. Puede ejecutar múltiples procesos o servicios de estrategia dentro de un mismo entorno de ejecución, o separarlos en diferentes entornos para mayor aislamiento y claridad operativa. Consulte la página del entorno de ejecución de TradingHost para conocer el modelo multiestrategia.
El camino más rápido es hacer un fork de un entorno de ejecución de framework de TradingHost: CCXT para un proyecto listo para desplegar. O bien, conecte su propio repositorio de estrategias de GitHub. Vincular un repositorio de GitHub y crear una estrategia es gratis; los planes de los entornos de ejecución se detallan en la página de precios.
En su flujo de trabajo de secretos de GitHub. TradingHost las lee en tiempo de ejecución a través de los secretos del repositorio de GitHub, secretos de entorno o su propio proceso aprobado de gestión de secretos. TradingHost no necesita la custodia de su clave API ni de su clave secreta. Consulte la sección de secretos de la plataforma para conocer el modelo completo de gestión.
No. Las estrategias nunca deberían necesitar permisos de retiro. Limite el alcance de su clave API únicamente a operaciones de trading y lectura del estado de la cuenta, y mantenga la opción de retiros completamente desactivada en la clave.
Sí. TradingHost admite el control basado en MCP para IDE de IA, incluidos Cursor, Claude Code, GitHub Copilot y agentes de IA basados en CLI. Las herramientas de IA pueden inspeccionar despliegues, revisar logs, reiniciar estrategias y gestionar flujos de trabajo del entorno de ejecución. MCP es una interfaz de control y observabilidad, no la ruta de ejecución de las operaciones. Consulte la interfaz de control de MCP para obtener una visión completa.
Ambos. La interfaz de control de MCP funciona igual de bien desde agentes basados en CLI (Claude Code CLI, clientes MCP personalizados, llamadas MCP mediante scripts) como desde el interior de un IDE. El ciclo de despliegue nativo de GitHub también funciona sin ninguna herramienta de IA: un simple git push a su rama principal activa un nuevo despliegue.
El entorno de ejecución detecta la caída y expone los logs y la información de estado pertinentes. Siempre que sea posible, la estrategia afectada se puede reiniciar sin interrumpir otras estrategias que se ejecuten en el mismo contenedor. El código de su estrategia sigue siendo responsable de la gestión segura de errores, la protección contra órdenes duplicadas y los controles de riesgo. Consulte la sección de observabilidad para conocer la interfaz de logs y estado de salud.
Los límites de frecuencia de la API v4 de Ripio Trade están estructurados por niveles según el estado de KYC. Las cuentas no verificadas obtienen 1 solicitud por segundo; las cuentas verificadas obtienen 3,5 solicitudes por segundo. Superar el límite de su nivel devuelve un error HTTP 429. La solución consiste en ajustar la cadencia de solicitudes al nivel en el que se encuentra su cuenta, tratar dicho nivel como una configuración de tiempo de ejecución (runtime config) en lugar de una constante, y aplicar un retroceso (backoff) con aleatorización exponencial (exponential jitter) ante un error 429. Consulte la sección de Notas operativas anterior para ver la guía completa.
TradingHost se ejecuta en las regiones EU y US-East. Selecciona la región más cercana al motor de emparejamiento del que dependa tu estrategia. Consulta la página de regiones para obtener detalles sobre enrutamiento y proximidad.
No. TradingHost se centra en el tiempo de ejecución (runtime) y el despliegue en producción. El backtesting corresponde a su entorno de investigación, framework o AlgoBuilder.