Runtime nativo de IA para estratégias de trading na MEXC
Desenvolva no Cursor, Claude Code ou em qualquer IDE de IA. Faça deploy a partir do GitHub em um runtime de nuvem gerenciado com controle MCP de primeira classe, logs e seleção de região.
Seção 01 · Visão rápida
Visão rápida
- Plataforma
- MEXC
- Tipo de plataforma
- Exchange de criptomoedas
- Classe de ativos
- Cripto (spot, perpétuos USDT-M e coin-M)
- Produtos suportados
- Spot, futuros perpétuos USDT-M, futuros perpétuos coin-M. O trading de futuros é proibido para usuários nos EUA, Reino Unido e várias jurisdições restritas.
- Modelo de runtime
- Runtime de estratégia em container
- Origem do deploy
- GitHub
- Linguagens
- Qualquer linguagem compatível com containers
- Integrações comuns
- APIs nativas MEXC Spot v3 e Contract v1 (REST e WebSocket), CCXT, conectores personalizados
- Integração com fluxo de IA
- Superfície de controle MCP para Cursor, Claude Code, GitHub Copilot e agentes de CLI
- Papel da TradingHost
- Runtime, deploy, logs, health checks, seleção de região, controle via MCP
- Papel de MEXC
- Conta na exchange, acesso à API, acesso ao mercado, ambiente de execução
- Afiliação
- A TradingHost é independente e não possui afiliação com a MEXC.
Seção 02 · O que MEXC oferece
O que MEXC oferece
A MEXC oferece trading spot em mais de 2.000 pares por meio da API Spot v3 e futuros perpétuos USDT-M e coin-M através da API Contract v1 em um domínio de documentação separado. O trading de futuros é proibido nos EUA, Reino Unido e diversas outras jurisdições restritas. As estratégias se autenticam com HMAC-SHA256 na API Spot v3 usando assinaturas hexadecimais em letras minúsculas. Os detalhes dos endpoints mudam com o tempo. A estrutura geral é estável; os limites exatos de requisições, faixas de taxas e listas de símbolos estão disponíveis diretamente na documentação da MEXC.
Mercados e padrões de estratégia
- Estratégias de spot em mais de 2.000 pares de trading
- Estratégias de futuros perpétuos USDT-M (excluindo jurisdições restritas)
- Estratégias de perpétuos coin-M
- Trading de taxa de financiamento (funding rate) e arbitragem de base em perpétuos
- Market making de spot para altcoins de baixa liquidez (long-tail)
- Deploys de múltiplas estratégias isoladas por subcontas
- Streams de ordens e saldos via canais privados de WebSocket
- Captura programática de novas listagens
Superfície da API
- Superfícies de produtos
- A Spot v3 cobre trading spot e gerenciamento de conta. A Contract v1 cobre futuros perpétuos USDT-M e coin-M em um domínio de documentação separado. O trading de futuros não está disponível para usuários em jurisdições restritas, incluindo EUA e Reino Unido; o bloqueio geográfico é aplicado no envio de ordens, e não apenas na criação da conta.
- Métodos de conexão
- REST para envio de ordens e consultas de conta. Streams de WebSocket para dados de mercado em tempo real, profundidade de livro (depth) e trades. WebSocket User Data Streams para eventos de conta, saldo e ordens. Os endpoints de WebSocket para spot e contratos são separados.
- Autenticação
- Chave de API e segredo por estratégia. As requisições privadas são assinadas com HMAC-SHA256 a partir de uma string de parâmetros ordenada, com saída em formato hexadecimal minúsculo. O recvWindow padrão é de 5000 ms e possui limite máximo de 60000 ms. As permissões são definidas por chave (leitura, trading, saque). As estratégias nunca devem precisar de permissão de saque. Liberação de IP (IP whitelisting) disponível; chaves sem IP liberado expiram automaticamente após 90 dias.
Para detalhes específicos, consulte MEXC
Endpoints específicos, pesos de limites de requisições, listas de símbolos, faixas de taxas e histórico de versões estão disponíveis na documentação da MEXC. Considere-os como a única fonte de verdade.
Seção 03 · Desenvolva com IA
Desenvolva sua estratégia para MEXC com IA
Escolha um método de integração, faça um fork de um starter de framework da TradingHost e desenvolva sua estratégia em uma AI IDE. Cursor, Claude Code, GitHub Copilot e agentes de IA baseados em CLI funcionam com o mesmo fluxo de deploy nativo do GitHub.
API nativa da MEXC
Controle direto sobre comportamentos específicos da MEXC, acesso à API de contratos e lógica de execução de ordens.
Hummingbot
Deploys baseados em framework usando a estrutura de estratégia e o modelo de configuração do Hummingbot.
Conector personalizado
Seu próprio motor de trading interno ou integração proprietária com a MEXC.
Suporte de frameworks para produtos MEXC
A cobertura varia de acordo com o framework. O CCXT abrange spot e contratos da MEXC; o Hummingbot oferece um conector apenas para spot; o Freqtrade não lista a MEXC como uma exchange suportada. O acesso à API nativa da MEXC alcança tudo o que a MEXC oferece, incluindo a API de contratos em seu domínio separado.
✓ suporte confirmado de acordo com a documentação oficial do framework. "não" indica que não há suporte documentado oficialmente.
A TradingHost não impõe nenhum framework. Ela executa o seu projeto.
Desenvolva com IA
Os starters de framework acima combinam perfeitamente com AI IDEs. A interface de controle MCP da TradingHost fecha o ciclo: as ferramentas de IA podem inspecionar deploys, analisar logs e gerenciar o runtime junto com você, sem nunca interferir no caminho de execução das ordens.
Seção 04 · Execute na TradingHost
Execute seu código na TradingHost
A MEXC fornece a exchange e o acesso à API. A TradingHost fornece o ambiente de produção onde sua estratégia conectada à MEXC é executada.
Em vez de executar o código da estratégia em um notebook, computador desktop, VPS genérico ou servidor configurado manualmente, você faz o deploy a partir do GitHub em um runtime de container gerenciado pela TradingHost.
Você
- Seu repositório contém seu código.
- Seu deploy define como ele é executado.
- Sua estratégia se conecta à MEXC.
TradingHost
- Mantém o runtime online.
- Exibe logs e health checks.
- Seleção de região.
- Superfície de deploy controlada.
Fluxo de deploy
- PASSO 01
Conecte o GitHub
Autorize a TradingHost a acessar sua conta do GitHub.
- PASSO 02
Vincule um repositório ou comece a partir de um framework
Aponte a TradingHost para o repositório da sua estratégia existente ou faça um fork de um runtime de framework da TradingHost (CCXT ou Hummingbot) para obter uma base funcional.
- PASSO 03
Implante em um contêiner da TradingHost
Escolha uma região (EU ou US-East), forneça as variáveis de ambiente que sua estratégia precisa (chaves de API da MEXC, etc.) e faça o deploy. A TradingHost constrói seu container a partir do repositório e executa sua estratégia em uma infraestrutura gerenciada de Kubernetes. Não é necessário instalar o Docker localmente.
- PASSO 04
Monitore logs e integridade
Acompanhe logs em tempo real, a integridade e o estado do runtime diretamente pelo painel da TradingHost. Essa mesma interface pode ser acessada via MCP a partir de qualquer AI IDE — assim, o Cursor, o Claude Code ou um agente de CLI podem ler o estado do deploy e gerenciar o runtime junto com você.
- PASSO 05
Atualize e faça o redeploy
Faça push das alterações para a branch principal do seu GitHub e a TradingHost realiza o redeploy de forma automática.
Seção 05 · Notas operacionais
Notas operacionais para MEXC
Problemas práticos que surgem ao rodar uma estratégia para a MEXC em um runtime de nuvem em container, que não estão na documentação da MEXC nem nos READMEs dos frameworks. Cada afirmação abaixo foi extraída ou parafraseada da própria documentação da MEXC; as orientações de deploy são baseadas na execução dessas estratégias na TradingHost.
01 · Mercados restritos
Usuários dos EUA e do Reino Unido são proibidos de negociar futuros e vários pares de spot
A MEXC impõe restrições de jurisdição no momento do envio da ordem, e não apenas na criação da conta. Um runtime baseado nos EUA que tente acessar os endpoints de contrato retornará erros de acesso negado, independentemente do status de verificação da conta. Se a sua estratégia visa futuros da MEXC, faça o deploy a partir de uma região da TradingHost cuja geografia de saída seja consistente com o seu contrato de usuário e sua própria postura de conformidade; containers em regiões restritas serão recusados na borda da exchange.
02 · Limites duplos de requisições
Os limites de requisições por IP e UID operam de forma independente
A MEXC impõe dois limites distintos de requisições para cada chamada assinada: um limite baseado em IP e outro baseado em UID. Os endpoints de spot geralmente possuem um limite de 500 requisições a cada 10 segundos por endpoint; as conexões de WebSocket são limitadas a 100 mensagens por segundo, com um máximo de 30 inscrições por conexão. Exceder qualquer um desses limites retorna erros 429. Estratégias que compartilham um IP de saída entre várias subcontas podem atingir o limite de IP muito antes que qualquer UID individual se aproxime de sua cota; dimensione seu modelo de concorrência com base no menor dos dois limites.
03 · Limite de ordens em lote
Corte de março de 2025: endpoint de ordens em lote (spot) reduzido para 5 ordens por segundo
A MEXC publicou um ajuste de limite de taxa (rate-limit) em 25 de março de 2025, reduzindo a cota do endpoint de ordens em lote de spot para 5 ordens por segundo, abaixo do teto anterior que era mais alto. Integrações legadas de market-making dimensionadas com base no teto antigo agora excedem o novo limite e recebem erros 429. Reajuste o ritmo de envio de ordens de acordo com o limite atual e trate os comunicados da MEXC como uma fonte de monitoramento contínuo, e não como uma leitura única.
04 · Ciclo de vida das chaves
Chaves de API: limite de 30 por conta, expiração automática em 90 dias se não houver whitelist de IP
A MEXC permite até 30 chaves de API por conta. Chaves criadas sem uma whitelist de IP expiram automaticamente após 90 dias; chaves com whitelist de IP não expiram. Ambientes de execução em nuvem (runtimes) não possuem IPs de saída únicos e estáveis por padrão, portanto, o padrão correto na TradingHost é usar a faixa de IPs de saída publicada para a região selecionada como o alvo da whitelist, ou aceitar o ciclo de rotação de 90 dias e automatizar a rotação de chaves no seu fluxo de trabalho de gerenciamento de segredos. Contas master também têm um limite de 30 subcontas.
05 · Formato de assinatura
Assinaturas HMAC devem ser hex em minúsculas; recvWindow padrão de 5000 ms, máx de 60000 ms
A MEXC aceita assinaturas HMAC-SHA256 apenas em formato hexadecimal com letras minúsculas (lowercase hex). SDKs que geram hex em maiúsculas ou base64 recebem rejeições de assinatura inválida que parecem erros de chave secreta incorreta. O recvWindow padrão é de 5000 ms e tem limite máximo de 60000 ms; um contêiner com desvio de relógio (clock drift) maior que o recvWindow é rejeitado. Os runtimes da TradingHost são sincronizados via NTP, então o padrão de 5000 funciona perfeitamente. Não aumente o recvWindow a menos que esteja enfrentando rejeições reais, e nunca como um substituto para corrigir a sincronização de tempo.
06 · Divisão de domínio de contratos
A API de contratos (Contract API) fica em um domínio de documentação separado com um pool de limites de taxa distinto
A MEXC publica a API Contract v1 em mexcdevelop.github.io/apidocs/contract_v1_en/, um domínio de documentação diferente do spot v3. Os endpoints de contratos ficam atrás de um pool de limite de taxa separado: o esgotamento da cota de spot não limita as requisições de contratos e vice-versa. Uma estratégia que precise de ambos deve ser projetada para gerenciar dois limites de taxa independentes, e não um único compartilhado.
Seção 06 · Indicado para
Indicado para
Os runtimes da TradingHost para a MEXC são ideais para:
- Desenvolvedores criando estratégias em IDEs de IA (Cursor, Claude Code)
- Traders sistemáticos de cripto
- Desenvolvedores quantitativos
- Usuários de CCXT e Hummingbot
- Equipes migrando de hospedagem VPS para implantação em contêineres
Conectar o GitHub e criar sua primeira estratégia é grátis.
Seção 08 · Perguntas frequentes
Perguntas frequentes
Não. A TradingHost é independente e não é afiliada à MEXC.
Não. O código da sua estratégia se conecta à MEXC e envia instruções de acordo com a sua própria lógica, permissões de conta e método de integração. A TradingHost fornece o ambiente de execução (runtime) onde esse código é executado.
Não. O acesso à API da MEXC é fornecido pela própria MEXC. Você é responsável por sua conta na MEXC, permissões de API, credenciais e conformidade com os termos da MEXC.
Não. A TradingHost é o ambiente de execução em nuvem (runtime) onde o código da sua estratégia roda. Nós não fornecemos sinais, modelos de previsão de IA ou bots pré-configurados. Com a TradingHost, você mesmo escreve ou gera a estratégia (geralmente usando o Cursor ou o Claude Code), mantém o código no GitHub e usa a TradingHost para executá-lo em produção. Produtos como o 3Commas, Cryptohopper e similares são proprietários da lógica da estratégia; a TradingHost apenas executa a sua estratégia.
A AWS e a DigitalOcean fornecem computação bruta. Você mesmo precisa lidar com atualizações de sistema operacional, orquestração de contêineres, envio de logs, rotação de segredos, failover de região e monitoramento de tempo de atividade (uptime). A TradingHost oferece um runtime gerenciado e construído especificamente para estratégias de trading: implantação nativa do GitHub, controle via MCP a partir de IDEs de IA, além de interfaces de logs e integridade (health) prontas para uso. Se você prefere operar a infraestrutura por conta própria, a AWS atende. Se você quer o runtime como um serviço gerenciado, a TradingHost é o caminho mais curto.
Sim. A TradingHost executa estratégias em Python; escolha o runtime de framework que corresponda à sua stack ou faça o deploy do seu próprio repositório.
Sim. A TradingHost suporta qualquer linguagem que possa ser executada dentro de um contêiner.
Sim. O CCXT expõe as interfaces de spot e de contratos da MEXC por meio da classe unificada `mexc`. Consulte o runtime do framework CCXT para ver os detalhes completos de configuração.
Não. A MEXC proíbe a negociação de futuros para usuários nos EUA, Reino Unido e diversas outras jurisdições restritas. A restrição é aplicada no momento do envio da ordem, e não apenas na criação da conta, portanto, um contêiner com saída (egress) nos EUA receberá erros de acesso negado dos endpoints de contratos, independentemente do status de verificação da conta. A elegibilidade é determinada pela MEXC, não pela TradingHost. Escolha uma região da TradingHost cuja geografia de saída seja consistente tanto com o seu contrato de usuário quanto com a sua própria postura de conformidade.
Sim, se o seu projeto for projetado dessa forma. Você pode executar múltiplos processos ou serviços de estratégia dentro de um único runtime, ou separá-los em runtimes diferentes para obter isolamento e clareza operacional. Consulte a página de runtimes da TradingHost para conhecer o modelo multiestratégia.
O caminho mais rápido é fazer um fork de um runtime de framework da TradingHost: CCXT ou Hummingbot para um projeto pronto para deploy. Ou conecte seu próprio repositório de estratégia do GitHub. Vincular um repositório do GitHub e criar uma estratégia é gratuito; os planos de runtime estão listados na página de preços.
No seu fluxo de trabalho de segredos controlado pelo GitHub. A TradingHost lê as chaves em tempo de execução por meio de segredos do repositório do GitHub (repository secrets), segredos de ambiente (environment secrets) ou do seu próprio processo aprovado de gerenciamento de segredos. A TradingHost não precisa da custódia da sua chave de API e segredo. Consulte a seção de segredos da plataforma para conhecer o modelo completo de tratamento.
Não. As estratégias nunca devem precisar de permissões de saque. Use permissões com escopo limitado (leitura, negociação) e whitelist de IP onde for apropriado.
Sim. A TradingHost suporta controle baseado em MCP para IDEs de IA, incluindo Cursor, Claude Code, GitHub Copilot e agentes de IA baseados em CLI. As ferramentas de IA podem inspecionar implantações, revisar logs, reiniciar estratégias e gerenciar fluxos de trabalho do runtime. O MCP é uma interface de controle e observabilidade, não o caminho de execução das operações. Consulte a interface de controle MCP para obter uma visão completa.
Ambos. A interface de controle MCP funciona igualmente bem a partir de agentes baseados em CLI (Claude Code CLI, clientes MCP personalizados, chamadas MCP via script) e de dentro de uma IDE. O ciclo de implantação nativa do GitHub também funciona sem qualquer ferramenta de IA: um git push comum para a sua branch principal (main) aciona um novo deploy.
O runtime detecta a falha e expõe os logs e informações de integridade (health) relevantes. Onde houver suporte, a estratégia afetada pode ser reiniciada sem interromper outras estratégias em execução no mesmo contêiner. O código da sua estratégia ainda é responsável pelo tratamento seguro de erros, proteção contra ordens duplicadas e controles de risco. Consulte a seção de observabilidade para conhecer as interfaces de logs e integridade.
A MEXC aplica dois tetos de limite de taxa independentes: um limite baseado em IP e um limite baseado em UID. Os endpoints de spot geralmente têm um limite de 500 requisições por 10 segundos; o endpoint de ordens em lote foi reduzido para 5 ordens por segundo em março de 2025. As conexões WebSocket são limitadas a 100 mensagens por segundo, com um máximo de 30 inscrições por conexão. Dimensione sua concorrência com base no menor limite entre IP e UID, e reajuste o ritmo de envio de ordens de acordo com o limite de lote atual. Consulte a seção de Notas operacionais acima para obter a orientação completa.
O TradingHost é executado nas regiões EU e US-East. Escolha a região mais próxima do matching engine utilizado pela sua estratégia. Consulte a página de regiões para obter detalhes de roteamento e proximidade.
Não. O TradingHost é focado em runtime de produção e deploy. O backtesting deve ser feito na sua stack de pesquisa, framework ou AlgoBuilder.