Runtime nativo de IA para estrategias de trading en Bitget
Desarrolla en Cursor, Claude Code o cualquier entorno de desarrollo de IA. Despliega desde GitHub en un runtime en la nube gestionado con control MCP de primer nivel, logs y selección de región.
Sección 01 · De un vistazo
De un vistazo
- Plataforma
- Bitget
- Tipo de plataforma
- Exchange de criptomonedas (enfocado en copy-trading)
- Clase de activo
- Cripto (spot, perpetuos USDT-M y coin-M, margen, copy trading)
- Productos compatibles
- Spot, futuros perpetuos USDT-M, futuros perpetuos coin-M, perpetuos USDC-M, margen aislado y cruzado, copy trading sobre perpetuos. Trading de demostración disponible contra la API de producción.
- Modelo de ejecución
- Runtime de estrategias en contenedores
- Origen del despliegue
- GitHub
- Lenguajes
- Cualquier lenguaje que se ejecute en un contenedor
- Integraciones habituales
- REST y WebSocket nativos de Bitget V2, CCXT, Hummingbot, conectores personalizados
- Integración con flujos de trabajo de IA
- Interfaz 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 Bitget
- Cuenta de exchange, acceso a la API, acceso al mercado, entorno de ejecución
- Afiliación
- TradingHost es independiente y no está afiliado a Bitget.
Sección 02 · Qué ofrece Bitget
Qué ofrece Bitget
Bitget ofrece spot, futuros perpetuos USDT-M, coin-M y USDC-M, margen cruzado e aislado, y una capa de copy-trading sobre perpetuos mediante APIs REST y WebSocket. Las estrategias se autentican con solicitudes firmadas con HMAC-SHA256 mediante tres cabeceras contra la API V2. Los detalles de los endpoints cambian con el tiempo, pero la estructura se mantiene; los límites de frecuencia exactos, los niveles de comisiones y las listas de símbolos se encuentran en la documentación de Bitget.
Mercados y patrones de estrategia
- Estrategias de futuros perpetuos USDT-M
- Estrategias de perpetuos coin-M y USDC-M
- Flujos de cuentas principales y seguidoras de copy-trading
- Trading de tasas de financiación y de base en perpetuos
- Estrategias de spot y margen (cruzado o aislado)
- Despliegues multiestrategia aislados por subcuentas
- Flujos de órdenes y posiciones en canales privados de WebSocket
- Despliegues validados mediante trading de demostración contra la API de producción
Interfaz de la API
- Áreas de producto
- Spot, futuros perpetuos USDT-M, perpetuos coin-M, perpetuos USDC-M, margen aislado y cruzado, y jerarquías de cuentas principales/seguidoras de copy-trading. El trading de demostración expone la misma interfaz V2 para validación contra la API de producción sin arriesgar capital real.
- Métodos de conexión
- REST para colocación de órdenes y consultas de cuenta. Canales públicos de WebSocket para datos de mercado y actualizaciones del libro de órdenes. Canales privados de WebSocket para eventos de cuenta, saldo, posición y órdenes. Bitget V2 es la generación actual de la API; los endpoints heredados de la V1 siguen documentados, pero las nuevas integraciones deben apuntar a la V2.
- Autenticación
- Clave API, secreto y frase de contraseña por estrategia. Las solicitudes privadas llevan tres cabeceras: ACCESS-KEY, ACCESS-TIMESTAMP y ACCESS-SIGN. La firma es un HMAC-SHA256 codificado en base64 de timestamp + método + requestPath + cuerpo. Bitget rechaza las solicitudes fuera de una ventana de frescura de timestamp de 30 segundos.
Para más detalles, consulte Bitget
Los endpoints específicos, los límites de frecuencia, las listas de símbolos, los niveles de comisiones y el historial de versiones se encuentran en la documentación de Bitget. Considéralos como la fuente de verdad.
Sección 03 · Desarrollar con IA
Desarrolle su estrategia para Bitget 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 Bitget V2
Control directo sobre el comportamiento específico de Bitget, las jerarquías de copy-trading y la lógica de ejecución de órdenes.
Hummingbot
Despliegues basados en frameworks utilizando la estructura de estrategia y el modelo de configuración de Hummingbot.
Conector personalizado
Tu propio motor de trading interno o integración propietaria con Bitget.
Compatibilidad de frameworks con productos de Bitget
La cobertura varía según el framework. CCXT abarca spot y perpetuos de Bitget; Hummingbot incluye un conector dedicado bitget_perpetual junto con el de spot. Las jerarquías de copy-trading son actualmente exclusivas de la API nativa; ningún framework las abstrae como una primitiva nativa. La API nativa de Bitget V2 cubre todo lo que ofrece Bitget, incluido el copy-trading.
✓ compatibilidad confirmada según la documentación oficial del framework. "no" indica que no está documentado oficialmente como compatible.
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
Bitget proporciona el exchange y el acceso a la API. TradingHost proporciona el entorno de producción donde se ejecuta tu estrategia conectada a Bitget.
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 Bitget.
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 estrategia existente, o haz un fork de un runtime de framework de TradingHost (CCXT o Hummingbot) para obtener una base funcional.
- PASO 03
Desplegar en un contenedor de TradingHost
Selecciona una región (EU o US-East), introduce las variables de entorno que requiera tu estrategia (clave API, secret y passphrase de Bitget, etc.) y despliega. TradingHost construye tu contenedor a partir del repositorio y ejecuta tu estrategia en una infraestructura gestionada de Kubernetes. Sin necesidad de instalar Docker en local.
- 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 Bitget
Detalles que te darán problemas al ejecutar una estrategia de Bitget en un runtime en la nube en contenedores, que no aparecen en la documentación de Bitget ni en los archivos README de los frameworks. Cada afirmación a continuación está citada o parafraseada de la propia documentación de Bitget; la guía de despliegue proviene de la experiencia de ejecutar estas estrategias en TradingHost.
01 · Autenticación de tres cabeceras
Se requieren ACCESS-KEY, ACCESS-TIMESTAMP y ACCESS-SIGN
Las solicitudes privadas de Bitget V2 llevan tres cabeceras: ACCESS-KEY (tu clave API), ACCESS-TIMESTAMP (marca de tiempo Unix actual en milisegundos) y ACCESS-SIGN (HMAC-SHA256 codificado en base64 de timestamp + método + requestPath + cuerpo, firmado con tu clave secreta). Se requiere una cuarta cabecera, ACCESS-PASSPHRASE, en cada solicitud firmada. Las estrategias que omitan cualquiera de las cuatro devolverán errores de firma no válida 40009. La frase de contraseña se establece al crear la clave y no se puede recuperar después; si se pierde, la única opción es generar una nueva clave.
02 · Ventana de 30 segundos
Se rechaza cualquier ACCESS-TIMESTAMP fuera de la ventana de frescura de 30 segundos
Bitget rechaza cualquier solicitud firmada cuyo ACCESS-TIMESTAMP difiera en más de 30 segundos de la hora del servidor de Bitget. Los contenedores con un desfase de reloj superior a 30 segundos verán cómo se rechazan las solicitudes firmadas en el servidor, independientemente de la validez de la firma. Los entornos de ejecución de TradingHost están sincronizados mediante NTP, por lo que el margen de 30 segundos es cómodo, pero si un contenedor sufre un desfase (por ejemplo, tras una partición de red prolongada), necesitará resincronizar su reloj antes de poder firmar solicitudes correctamente.
03 · De V1 a V2
V2 es la generación actual de la API; los endpoints de la V1 siguen documentados pero no deberían utilizarse para nuevas integraciones
Bitget publicó la interfaz de la API V2 para consolidar los endpoints de spot, USDT-M, coin-M y copy-trading bajo un único esquema de firma y ruta base. Los endpoints de la V1 siguen en la documentación por compatibilidad con versiones anteriores, pero el historial de notas de lanzamiento registra las depreciaciones frente a la V2. Las nuevas estrategias deberían apuntar directamente a los endpoints de la V2 para que la integración no herede un plazo de obsolescencia. Fije la versión de la API en su cliente para que una futura transición a la V3 sea una migración explícita y no una interrupción silenciosa.
FuenteBitget V2 release notes04 · Jerarquía de copy-trading
Las subcuentas principales y de seguidores heredan stpGroupId; las estrategias deben saber en qué lado se están ejecutando
Las posiciones de copy-trading de Bitget heredan el stpGroupId entre una cuenta de trader (principal) y sus seguidores. Una estrategia que se ejecute en una cuenta principal y abra una posición activará ejecuciones copiadas en cada cuenta de seguidor vinculada, ponderadas según la configuración del seguidor. Las estrategias que no deban copiarse tienen que ejecutarse en una cuenta que no sea de trader, o excluirse explícitamente a nivel de posición. El radio de impacto de una cuenta principal de copy-trading mal configurada es grande; el aislamiento de subcuentas y la delimitación de permisos por clave son los patrones de contención adecuados.
FuenteBitget API introduction05 · Delimitación de claves
Una clave delimitada por estrategia, nunca una clave maestra compartida entre estrategias
Las claves de API de Bitget permiten delimitar permisos (lectura, trading de spot, trading de futuros, retiros). Las estrategias nunca deberían necesitar permisos de retiro; aísle las claves con capacidad de retiro en una credencial gestionada manualmente por separado, fuera del entorno de ejecución del contenedor. El uso de claves por estrategia con solo los permisos que esa estrategia necesita limita el radio de impacto en caso de filtración. Bitget también admite listas blancas de IP por clave; fíjela si el rango de salida del entorno de ejecución es conocido y estable para la región seleccionada.
FuenteBitget API introduction06 · División de trading de demostración
El trading de demostración comparte la interfaz de la V2 pero emite claves y saldos independientes
Bitget expone el trading de demostración en la misma interfaz de endpoints de la V2 de producción; la estructura de las solicitudes es idéntica, pero el conjunto de claves, los saldos y las posiciones están aislados de producción. Un fallo silencioso habitual es subir a producción código validado en demo sin cambiar el conjunto de claves, o viceversa. Mantenga las credenciales de demo y producción en entradas de Secrets de TradingHost independientes; nunca reutilice una entre entornos.
FuenteBitget API introduction
Sección 06 · Diseñado para
Diseñado para
Los runtimes de TradingHost para Bitget son ideales para:
- Desarrolladores que crean estrategias en IDE de IA (Cursor, Claude Code)
- Traders sistemáticos de criptomonedas
- Desarrolladores cuantitativos
- Usuarios de CCXT y Hummingbot
- 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 Bitget.
No. El código de su estrategia se conecta a Bitget y envía instrucciones según su propia lógica, permisos de cuenta y método de integración. TradingHost proporciona el entorno de ejecución donde se ejecuta dicho código.
No. El acceso a la API de Bitget lo proporciona Bitget. Usted es responsable de su cuenta de Bitget, los permisos de la API, las credenciales y el cumplimiento de los términos de Bitget.
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, Cryptohopper y similares son propietarios de la lógica de la estrategia; TradingHost simplemente ejecuta su estrategia.
AWS y DigitalOcean le ofrecen capacidad de cómputo básica. Usted mismo debe encargarse de las actualizaciones del sistema operativo, la orquestación de contenedores, el envío de registros, la rotación de credenciales, la conmutación por error de región y la supervisión del tiempo de actividad. TradingHost le ofrece un entorno de ejecución gestionado y diseñado específicamente para estrategias de trading: despliegue nativo desde GitHub, control mediante MCP desde IDE de IA, y visualización de registros y estado de salud de forma nativa. Si prefiere gestionar la infraestructura usted mismo, AWS es una opción. Si prefiere el entorno de ejecución como un servicio gestionado, TradingHost es el camino más rápido.
Sí. TradingHost ejecuta estrategias en Python; elija el entorno de ejecución de framework que coincida con su pila tecnológica o despliegue su propio repositorio.
Sí. TradingHost es compatible con cualquier lenguaje que pueda ejecutarse dentro de un contenedor.
Sí. CCXT expone las interfaces de spot y perpetuos de Bitget a través de la clase unificada `bitget`. Los endpoints de copy-trading no son una primitiva nativa de CCXT, por lo que los flujos de copy-trading se ejecutan contra la API nativa V2 de Bitget. Consulte el entorno de ejecución del framework CCXT para ver todos los detalles de configuración.
TradingHost es independiente de la plataforma a nivel de entorno de ejecución: cualquier código que pueda autenticarse en Bitget puede ejecutarse dentro de un contenedor, incluida una estrategia alojada en una cuenta principal de copy-trading de Bitget. La implicación que debe tener en cuenta al diseñar su sistema es que cualquier posición que abra su estrategia activará ejecuciones copiadas en cada cuenta de seguidor vinculada, ponderadas según su configuración. Ejecute las estrategias aptas para copia en una subcuenta independiente de las estrategias no públicas, y aísle las claves de API por estrategia para limitar el radio de impacto.
Sí, si su proyecto está diseñado de esa manera. Puede ejecutar múltiples procesos o servicios de estrategia dentro de un solo 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 o Hummingbot 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 entornos de ejecución se detallan en la página de precios.
En su flujo de trabajo de secretos controlado por 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 de API, secreto ni frase de contraseña. 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. Utilice permisos delimitados (lectura, trading de spot, trading de futuros) y listas blancas de IP cuando corresponda.
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 registros, 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 operaciones. Consulte la interfaz de control MCP para ver todos los detalles.
Ambos. La interfaz de control MCP funciona igual de bien desde agentes basados en CLI (Claude Code CLI, clientes MCP personalizados, llamadas MCP programadas) que desde el propio IDE. El ciclo de despliegue nativo de GitHub también funciona sin herramientas de IA: un simple git push a su rama principal activa un nuevo despliegue.
El entorno de ejecución detecta el fallo y expone los registros y la información de estado pertinentes. Siempre que sea compatible, 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 registros y estado de salud.
El error 40009 de Bitget significa que la firma que envió tu estrategia no coincide con el HMAC-SHA256 esperado de timestamp + method + requestPath + body, firmado con tu secret. Las causas más comunes son la falta o incorrección de la cabecera ACCESS-PASSPHRASE, un ACCESS-TIMESTAMP fuera de la ventana de tolerancia de 30 segundos, firmar con el secret incorrecto (clave de prueba frente a producción) o firmar un cuerpo de solicitud canónico incorrecto (espacios en blanco adicionales, reordenamiento de claves). Fija una versión de un SDK contrastado o realiza pruebas unitarias de la ruta de firma contra la referencia de firmas de Bitget. Consulta la sección de notas operativas de arriba para obtener la guía completa.
TradingHost opera 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 más detalles sobre enrutamiento y proximidad.
No. TradingHost se centra exclusivamente en el entorno de ejecución (runtime) y el despliegue en producción. El backtesting corresponde a tu entorno de investigación, framework o AlgoBuilder.