> For the complete documentation index, see [llms.txt](https://docs.nexus.xyz/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://docs.nexus.xyz/api-reference/pt-br/guides/rate-limits.md). # Limites de requisições Quanto custa uma requisição, o que significam os cabeçalhos de limite de requisições, quais orçamentos são independentes entre si e o que acontece quando você excede cada um. A Exchange não orça seu tráfego em requisições por segundo. Ela orça em **peso por segundo**. Cada requisição recebe um custo: a maioria custa uma unidade e algumas custam mais. Um cliente que controla seu ritmo contando requisições é recusado enquanto seu próprio contador ainda parece saudável. Essa é a surpresa de integração mais comum com esta API. Esta página explica o modelo: quanto as coisas custam, quais orçamentos são separados e como ler os cabeçalhos. A definição **normativa** é o contrato OpenAPI, publicado em [`nexus-xyz/nexus-exchange-api`](https://github.com/nexus-xyz/nexus-exchange-api) e servido em `/openapi.json`. A seção "Rate limits" da descrição da API é a dona da semântica dos cabeçalhos, e cada operação traz seu próprio custo legível por máquina. Onde esta página e o contrato divergirem, o contrato está certo. ### Quanto custa uma requisição Seu orçamento é um **token bucket que se recarrega continuamente na taxa por segundo do seu nível**, com capacidade de exatamente um segundo de tokens. Essa capacidade tem duas consequências. A taxa sustentada e a tolerância de burst são o mesmo número, então não existe uma reserva de vários segundos para acumular ficando ocioso. E `remaining` nunca pode exceder `limit`. A maioria das requisições custa **1**. As exceções: | Custo | Aplica-se a | Por quê | | --------------------------------- | ----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | ----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | | **5** | `GET /account/summary`, `GET /fills`, `GET /orders/history`, `GET /account/portfolio-history`, `GET /positions/pnl`, `GET /account/activity`, `GET /stats/referrals` e os equivalentes em `/api/v1` de todos, exceto o último | Cada uma consolida ou varre um grande buffer por conta (execuções, histórico de ordens, a série temporal do portfólio, o feed de atividade mesclado), se desdobra pelas posições abertas ou agrega contagens de indicações de toda a plataforma a partir do backend de contas | | **`1 + floor(order_count / 40)`** | `POST /orders/batch` | Até 40 ordens custam o mesmo que uma; cada 40 adicionais somam uma unidade | | **1** | todas as outras operações que o contrato documenta | O padrão | Assim, um chamador Pro com `limit: 20` tem 20 leituras de ticker por segundo, **ou 4 leituras de `/fills`**, do mesmo orçamento no mesmo nível. Controle o ritmo pelo peso, não pela contagem de requisições. Duas propriedades de segurança limitam o pior caso. A cobrança de uma única requisição tem teto de um segundo de tokens, então um lote grande demais nunca fica permanentemente impossível de atender. Ele consome o segundo inteiro assim que o bucket se recarrega e passa, em vez de ficar em loop para sempre numa nova tentativa que nunca conseguiria pagar. E um corpo de lote que o servidor não consegue interpretar é cobrado pela unidade base em vez de ser recusado por causa do peso. Em vez de fixar a tabela acima no código, leia o custo no contrato: operações que custam mais de uma unidade trazem **`x-nexus-rate-limit-weight`**, e aquelas cujo custo depende do corpo também trazem **`x-nexus-rate-limit-weight-formula`**. **Para uma operação que o contrato documenta, a ausência do marcador significa peso 1.** Essa é a forma contra a qual construir um limitador do lado do cliente. A ressalva importa. O contrato lista as operações suportadas, e a regra vale para todas elas, mas não diz nada sobre outros caminhos que por acaso respondam. Uma rota que o contrato não lista não traz marcador, não é coberta pela regra e pode ser cobrada de forma diferente do que sua ausência sugere. Construa contra as operações que o contrato documenta, não contra caminhos encontrados por sondagem. São essas operações que os pesos, e esta página, descrevem. ### Quatro orçamentos, não um Há quatro classes de recurso independentes. Gastar uma não gasta as outras, e cada uma recusa à sua maneira: | Classe | Abrange | Cobrado de | | ---------------------------------- | -------------------------------------------------------------------------------- | -------------------------------------------------------------------------------------- | | **Requisições** | Toda operação REST que não seja uma escrita de ordem | Seus buckets de requisições por chave e por titular | | **Ações de negociação** | `POST` e `PATCH` sob `/orders`, marcados com `x-nexus-rate-limit-class: trading` | Um bucket de ordens dedicado, com o mesmo tamanho por segundo do bucket de requisições | | **Cancelamentos** | `DELETE` sob `/orders`, também marcado com `x-nexus-rate-limit-class: trading` | Um bucket de cancelamento **separado**, novamente com o mesmo tamanho por segundo | | **Plano de controle do WebSocket** | Conexões, assinaturas e frames de entrada do cliente | Tetos por nível. Veja [Tetos do WebSocket](#websocket-ceilings) | Uma escrita de ordem é cobrada do bucket de negociação **em vez do** bucket de requisições, não além dele. Por causa dessa divisão, um burst de polling não consegue sufocar o envio das suas ordens, e o fluxo de ordens não consegue sufocar suas leituras. Segue-se que **um `x-ratelimit-remaining` saudável na sua última leitura não diz nada sobre a sua folga para enviar ordens.** São reservas diferentes, então leia a reserva da qual você está prestes a gastar. `GET /account/rate-limit` informa cada orçamento separadamente em `buckets`, e `buckets.order` responde se você pode enviar uma ordem. #### Cancelamentos nunca compartilham um token com envios Cancelar é a única ação separada da negociação em um orçamento próprio. Um `DELETE` nos endpoints de ordens (cancelar uma, cancelar tudo ou cancelar por mercado) é cobrado do bucket de cancelamento em vez do bucket de ordens, então **uma chave que gastou toda a sua cota de envio enviando ordens ainda tem uma cota cheia e intacta para retirá-las.** Essa é a única assimetria deliberada do modelo. O envio pode esperar, e a redução de risco não pode. Um limitador que recusa seu cancelamento enquanto uma posição anda contra você transforma um controle de uso justo em prejuízo. Por isso a regra é incondicional. Esgotar o envio nunca pode recusar um cancelamento, porque os dois nunca consomem o mesmo token. Para um cliente, isso significa: * **Nunca deduza sua folga de cancelamento a partir de um `429` de envio.** Um bucket `order` vazio não diz nada sobre o `cancel`. Um cliente que recua em todas as chamadas de ordens após uma única recusa de envio limitou justamente a chamada que ainda deveria estar fazendo. * **Um bucket separado não é um atalho.** Cancelamentos são medidos na mesma taxa por segundo do nível que todo o resto, então um loop de cancelamentos ainda pode receber um `429`. Ele traz `bucket: cancel`, a única recusa que significa que seu canal de cancelamento está saturado. Respeite `retry-after` nesse caso. Edições são cobradas como envio, não como cancelamento. `PATCH` não diz se uma edição reduz ou aumenta a exposição, e uma edição que aumenta o tamanho é um envio em qualquer leitura. Então a garantia acima se aplica apenas ao método que sempre reduz risco. Se você precisa da garantia, cancele. `POST /orders/preview` também é uma ação de negociação, o que é fácil de passar despercebido. É uma escrita sob `/orders` e custa uma unidade da classe de negociação, o mesmo que enviar uma ordem. Pré-visualizar antes de cada ordem, portanto, reduz pela metade sua taxa efetiva de envio. Reserve duas cobranças da classe de negociação por ordem enviada dessa forma, ou pule a pré-visualização quando já souber o dimensionamento. Um chamador que apresenta uma chave HMAC passa por um bucket **por chave** e depois pelo bucket **por titular** do seu nível, e o teto efetivo é o que limitar primeiro. `GET /account/rate-limit` informa esse mínimo, e consultá-lo é gratuito. É a única operação que não consome tokens, então controlar seu próprio ritmo não pode limitar você. Se você acabou de ser promovido, observe que o teto próprio de uma chave é registrado quando a chave é criada (20/s por padrão), e uma mudança de nível não o reescreve. Uma conta Market Maker que ainda usa uma chave criada no padrão pode, portanto, ficar presa ao número da chave em vez do número do nível. Leia `/account/rate-limit` após uma promoção em vez de presumir o valor do nível, e crie uma chave nova se o mínimo informado não for o esperado. ### Lendo os cabeçalhos * Em **toda** resposta autenticada: `x-ratelimit-limit` e `x-ratelimit-remaining`. * **Somente em um `429`**, também: `x-ratelimit-reset` (segundos unix) e `retry-after` (segundos, nunca abaixo de 1). Não espere os dois últimos em uma resposta de sucesso. Um cliente que lê `x-ratelimit-reset` de um 2xx não lê nada. **`remaining` e `retry-after` usam unidades diferentes, de propósito.** `remaining` conta requisições de custo unitário, então `x-ratelimit-remaining: 10` significa dez requisições de peso 1 *ou* duas pesadas. `retry-after` é derivado do custo ponderado da requisição que foi recusada. Um limitador que lê `remaining` como "requisições do tipo que estou prestes a enviar" vai enviar demais em endpoints pesados e provocar seus próprios 429. Uma recusa é um `HTTP 429` com este corpo: ```json { "code": "RATE_LIMIT_EXCEEDED", "message": "Order placement rate limit exceeded", "bucket": "order", "tier": "Pro" } ``` Ramifique pelo `code` e depois pelo **`bucket`**. Ele é um de `key`, `owner`, `order`, `cancel`, `ip` ou `login` e, para os quatro primeiros, é a chave a consultar em `buckets` de `GET /account/rate-limit`. `ip` e `login` nunca aparecem ali. Ambos medem uma conexão em vez de uma conta, e `login` é recusado antes mesmo de uma conta ser estabelecida. O mesmo valor é enviado no cabeçalho `x-ratelimit-bucket`, então um proxy ou wrapper de novas tentativas pode lê-lo sem interpretar o corpo. A `message` nomeia qual reserva se esgotou (`Rate limit exceeded`, `API key rate limit exceeded`, `Order placement rate limit exceeded` ou `IP rate limit exceeded`). Ela é um **diagnóstico**. Seu texto não é estável, então não faça correspondência com ele no código. Diferente das recusas `403` por jurisdição, um `429` **pode** ser repetido: respeite `retry-after` e recue. Controlar o ritmo por `x-ratelimit-remaining` é melhor do que descobrir o teto batendo nele. O `GET /account/rate-limit` gratuito informa o mesmo estado sem gastar um token. Os campos de nível superior cobrem a classe de requisições, e `buckets` cobre todos os orçamentos: ```json { "tier": "pro", "limit": 20, "remaining": 17, "reset_at_ms": 1750000000123, "buckets": { "key": { "limit": 20, "remaining": 17, "reset_at_ms": 1750000000123 }, "owner": { "limit": 20, "remaining": 19, "reset_at_ms": 1750000000051 }, "order": { "limit": 20, "remaining": 20, "reset_at_ms": 0 }, "cancel": { "limit": 20, "remaining": 20, "reset_at_ms": 0 } } } ``` **`buckets` é indexado pelos mesmos rótulos que um `429` usa**, tanto no campo `bucket` quanto no cabeçalho `x-ratelimit-bucket`. Assim, uma recusa aponta direto para o estado que a causou: `buckets[error.bucket]`. Construa seu limitador em torno dessa consulta. `key` aparece apenas quando um bucket por chave limita você, e nem `ip` nem `login` aparecem nunca, porque ambos medem uma conexão em vez de uma conta. Os campos de nível superior `limit`, `remaining` e `reset_at_ms` são a classe de **requisições**, sem mudanças, então nada que os lê precisa mudar. Eles não respondem "posso enviar uma ordem". `buckets.order` responde. Em uma chave que acabou de chegar ao teto de envio cotando, os dois divergem completamente: `remaining: 20` ao lado de `buckets.order.remaining: 0`. Dois detalhes a tratar quando você usa tanto este endpoint quanto os cabeçalhos. `reset_at_ms` está em **milissegundos**, enquanto o cabeçalho `x-ratelimit-reset` está em **segundos** unix. E o nome do nível vem em minúsculas aqui (`pro`), mas não no corpo do `429` (`Pro`), então compare sem diferenciar maiúsculas de minúsculas em vez de comparar com um literal. Os três campos numéricos são `null` para um chamador `Unlimited`, que é agrupado em buckets por IP em vez de por conta. `buckets` volta como `{}`, porque nenhum orçamento no escopo da conta mede esse chamador. ### Níveis e tetos atuais Os níveis são multiplicadores sobre um único modelo, não modelos diferentes. **Pro** é o padrão para toda conta. Um administrador atribui **MarketMaker**. Solicite-o pelo seu contato na Nexus e veja o [Guia para market makers](https://docs.nexus.xyz/exchange/apis-and-rates/market-maker-guide). **Unlimited** existe para chaves de gateway que multiplexam muitos usuários e nunca é atribuído a uma conta de negociação. | Nível | Requisições | Ações de negociação | Conexões WS | Assinaturas WS | Frames de entrada WS | | ------------- | ------------ | ----------------------------------------- | ----------- | -------------- | -------------------- | | `Pro` | 20/s | 20/s | 5 | 50 | 10/s | | `MarketMaker` | 2.000/s | 2.000/s | 100 | 1.000 | 50/s | | `Unlimited` | por IP, 50/s | por IP, 50/s, o mesmo bucket das leituras | isento | isento | isento | Três limites se aplicam independentemente do nível, todos antes de você ter uma credencial. Leituras de dados de mercado não autenticadas são agrupadas **por IP do cliente a 50/s**. `POST /auth/login` é medido separadamente e de forma muito mais rígida, a **5/s por IP do cliente** em uma reserva própria. Uma tentativa de login custa um ecrecover sobre uma assinatura EIP-191, e qualquer pessoa que alcance o endpoint pode fazer o servidor pagar esse custo. O limite não é uma defesa contra adivinhação de segredo, já que a mensagem assinada é uma constante fixa e não há nada para descobrir por força bruta. É uma defesa de custo. Tráfego cujo IP de cliente não pode ser resolvido também não é admitido sem limitação. Leituras compartilham um bucket rígido de 5/s e logins compartilham um **segundo, separado**, então uma enxurrada que remove seu `x-forwarded-for` não consegue esgotar a reserva da qual o resto do tráfego não resolvível depende. Uma origem não resolvível recebe um teto baixo em vez de nenhum teto. Uma recusa de login traz `bucket: login`, que é a única recusa que significa que o próprio portão de login está saturado. É um teto por IP, então você o compartilha com todos atrás do seu NAT ou proxy de saída, e ele não diz nada sobre a sua conta. Ainda não há conta. Os cancelamentos têm seu próprio orçamento na taxa de Ações de negociação (mais 20/s para `Pro`, 2.000/s para `MarketMaker`). A tabela não dá a eles uma coluna própria porque os dois números são iguais por construção. `Unlimited` tem isenções mais estreitas do que o nome sugere. Suas escritas de ordens **e seus cancelamentos** **não** estão isentos de limite de requisições. Eles pulam tanto o bucket de negociação dedicado quanto o bucket de cancelamento e são cobrados do mesmo bucket por IP de suas leituras. Então nem a independência de classes acima nem a garantia de cancelamento valem ali, e o próprio polling de um gateway pode sufocar seu fluxo de ordens, justamente no nível cujo perfil de tráfego é o menos previsível. Os tetos de WS dos quais ele é isento são os *por conta*. O limite de conexões por IP abaixo continua valendo. **Esses números são padrões atuais, não um contrato.** Eles são configuração de implantação (alguns ainda constantes no código) e vão mudar à medida que o sistema de níveis for finalizado. Leia `/account/rate-limit` em vez de fixá-los no código. ### Tetos do WebSocket Os tetos do WebSocket são uma classe de recurso própria, independente do orçamento de requisições REST e do orçamento de ações de negociação. Esgotar um não afeta os outros. **Conexões** têm teto por conta de acordo com o nível (Pro 5, MarketMaker 100). Um **limite por IP separado, 5 por padrão,** se aplica primeiro, no momento do upgrade, e vale em todos os níveis, incluindo `Unlimited`, então um único endereço de origem não consegue alcançar sozinho o valor por conta. Uma conexão recusada ali recebe um `HTTP 429` (`ws_conn_limit_exceeded`) na requisição de upgrade em vez de um frame de fechamento. O token de stream de uso único é gasto de qualquer forma, então crie um novo antes de reconectar. **Assinaturas** têm teto no mesmo número duas vezes: por conexão *e* somando todas as conexões de uma conta. Abrir mais sockets, portanto, não compra mais assinaturas. Assinar de novo uma chave `(channel, market)` que você já tem a substitui no lugar e é gratuito. Exceder o teto retorna um frame `error` (`subscription_limit_exceeded`) em vez de um código de status, porque não há respostas HTTP depois que o socket está aberto. **Frames de entrada** (suas assinaturas, cancelamentos de assinatura e pings) são limitados à taxa sustentada por nível, com um **burst de 2×** tolerado acima dela, para que uma tempestade de reconexão e reassinatura não seja penalizada. Além disso, o servidor **descarta** frames acima do limite e envia um aviso `error` por janela de contabilização em vez de um por frame, para que uma enxurrada de entrada não se transforme em uma de saída. Uma enxurrada sustentada, isto é, frames descartados suficientes dentro de uma janela, fecha a conexão com o código **`1008`** (violação de política). O servidor não aplica um frame descartado e não avisa você. Se você não vir um ack `subscribed`, reenvie a assinatura depois de recuar em vez de presumir que ela teve efeito. ### Os orçamentos são por rede Cada rede é sua própria implantação, então **cada rede tem seus próprios buckets**. Gastar na testnet não reduz a folga na mainnet quando a mainnet for lançada, e o inverso também não. As credenciais também não atravessam redes. Uma chave fica vinculada à rede que a criou. Veja [Redes](/api-reference/pt-br/guides/networks.md). ### Onde a aplicação dos limites acontece hoje Uma limitação atual é visível de fora, e ela funciona a seu favor, não contra você. O processo do gateway mantém o estado do limitador **em memória**, não em um armazenamento compartilhado. Duas coisas decorrem disso. Primeiro, ele não é durável. Uma nova implantação zera seus buckets, e uma promoção de nível pode voltar brevemente ao nível base até ser reaplicada. Segundo, quando o gateway de uma rede roda mais de uma réplica, cada uma mantém seus próprios buckets, então o teto *agregado* que um cliente observa pode ser maior do que o valor por segundo publicado, dependendo de onde suas conexões caem. Não projete contando com essa folga. Trate o número publicado como o teto a que você tem direito e controle seu ritmo por ele. O excedente vem de onde a aplicação dos limites está hoje, não é distribuído de forma uniforme e desaparece quando os contadores forem para um armazenamento compartilhado. Um cliente construído para o valor publicado continua funcionando quando isso chegar. Um ajustado ao agregado observado vai começar a ver 429. ### Seu signatário consegue acompanhar? O cliente assina cada requisição autenticada antes de ela sair, então o signatário impõe um teto próprio abaixo dos orçamentos acima. Verifique esse teto antes de escolher um SDK. Ele depende muito mais do esquema e da biblioteca de criptografia do que da linguagem. A Exchange aceita dois esquemas de assinatura de requisições (veja [Autenticação](/api-reference/pt-br/guides/authentication.md#signing-a-request-with-the-key) e [Agentes](/api-reference/pt-br/guides/agent-keys.md)): * **HMAC** (`hmacAuth`). HMAC-SHA256 sobre a string canônica de cinco campos, com a chave sendo o segredo de API decodificado de hex. Um MAC simétrico leva microssegundos em qualquer linguagem. * **Chave de agente** (`agentAuth`). ECDSA secp256k1 sobre o `keccak256` da string canônica de seis campos, low-S, enviada como `r||s||v` de 65 bytes. É uma assinatura de curva elíptica, então seu custo depende de a biblioteca subjacente ser código nativo ou código interpretado puro. Medido pelo próprio caminho de assinatura de cada SDK, com um corpo fixo de `POST /api/v1/orders`, em uma thread. É a mesma chamada que o cliente faz em toda requisição, incluindo montar a string canônica, calcular o hash do corpo e codificar o resultado em hex, mas sem I/O de rede: | SDK | Esquema | Criptografia subjacente | p50 | p95 | Assinaturas/s | p50 em 5 execuções | | -------------------------------- | --------------- | --------------------------------- | -----: | -----: | ------------: | ------------------ | | Rust (`nexus-exchange-rs`) | HMAC | `hmac` + `sha2` | 0,9 µs | 0,9 µs | \~1.080.000 | 0,88–0,96 µs | | Rust (`nexus-exchange-rs`) | Chave de agente | `k256` | 79 µs | 91 µs | \~12.500 | 74–79 µs | | TypeScript (`nexus-exchange-ts`) | HMAC | Web Crypto (assíncrono) | 27 µs | 43 µs | \~29.000 | 24–35 µs | | TypeScript (`nexus-exchange-ts`) | Chave de agente | `@noble/curves` | 319 µs | 470 µs | \~2.900 | 293–645 µs | | Python (`nexus-exchange-py`) | HMAC | `hmac` da stdlib | 2,1 µs | 2,2 µs | \~460.000 | 1,96–2,25 µs | | Python, instalação padrão | Chave de agente | backend puro Python do `eth-keys` | 3,5 ms | 4,2 ms | \~280 | 3,43–4,11 ms | | Python + `coincurve` | Chave de agente | libsecp256k1 via `coincurve` | 97 µs | 110 µs | \~10.000 | 96–116 µs | A CLI assina pelo crate Rust, então herda as linhas do Rust em vez de ter números próprios. **No nível `Pro`, nenhum SDK e nenhum esquema é limitado pelo signatário.** 20 requisições por segundo deixam 50 ms por assinatura. A linha mais lenta, assinatura com chave de agente em uma instalação padrão do Python, usa 3,5 ms disso, então consegue assinar cerca de quatorze vezes a taxa Pro em um núcleo. Mesmo um chamador saturando os três buckets Pro ao mesmo tempo (requisições, ações de negociação e cancelamentos, 60 requisições assinadas por segundo) gasta cerca de um quinto de um núcleo assinando. O signatário de chave de agente do TypeScript tem mais de cem vezes essa folga, e o HMAC é praticamente gratuito em todos os SDKs. **No nível `MarketMaker`, o esquema e a biblioteca começam a importar.** Suas 2.000 ações de negociação por segundo, mais 2.000 cancelamentos separados, deixam 0,25–0,5 ms por assinatura em uma thread. * **Python com chave de agente:** uma instalação padrão assina cerca de 280 por segundo, aproximadamente um sétimo do teto de negociação. Instale o `coincurve` (`pip install coincurve`) no mesmo ambiente e o `AgentSigner` passa a rodar sobre a libsecp256k1, a cerca de 10.000 por segundo, sem mudança no seu código. O SDK não escolhe um backend de curva por conta própria; o `eth-keys` usa o `coincurve` sempre que consegue importá-lo, a menos que a variável de ambiente `ECC_BACKEND_CLASS` indique um backend diferente. O bench de Python imprime o backend que mediu, que é a forma mais rápida de confirmar que a troca funcionou. Ou assine com HMAC, que nunca é a restrição. * **TypeScript com chave de agente:** cerca de 2.900 por segundo supera o teto de negociação em um núcleo, mas não negociação e cancelamentos juntos. Um cliente que roda ambos na taxa máxima deve assinar com HMAC ou distribuir a assinatura entre worker threads. * **Rust e a CLI:** folgados em qualquer um dos esquemas. Por requisição, a assinatura acrescenta 0,3 ms no TypeScript e 3,5 ms em uma instalação padrão do Python com chave de agente. Isso é uma pequena fração de uma ida e volta do cliente medida em dezenas de milissegundos, mas perceptível no caminho do Python. É mais um motivo para instalar o `coincurve` se você negocia a partir do Python com uma chave de agente. #### Como isso se compara aos números publicados pela Paradex A Paradex publica uma tabela parecida: cerca de 5.000 assinaturas por segundo em Rust, 1.430 em Go, 50 em TypeScript e 8 em Python ou Java. Lidos ao pé da letra, os 20 ms por assinatura do TypeScript limitam uma thread a 50 assinaturas por segundo. Isso cobre um único orçamento de 20/s, mas só a assinatura usaria 40% do núcleo, e fica abaixo dos 60/s que um chamador Pro pode gastar somando requisições, ações de negociação e cancelamentos. Esses números não se transferem. A Paradex assina ordens com uma chave StarkNet, uma curva diferente e um hash diferente de ambos os esquemas aqui, e seus números não foram medidos no hardware abaixo, então uma proporção entre as duas tabelas é, no máximo, indicativa. O padrão se transfere. Um signatário de curva elíptica em código interpretado puro é o caso lento, e bindings nativos fecham a maior parte da diferença. A diferença aqui é que o caso lento (Python com seu fallback puro Python, cerca de 280 por segundo) ainda é mais de dez vezes mais rápido do que o nível Pro precisa. #### Metodologia * **Hardware.** Apple M2, 8 núcleos (4 de desempenho, 4 de eficiência), 8 GB, macOS 26.5 (build 25F84), na tomada e com o Modo de Pouca Energia desativado. O macOS não consegue fixar um processo em um núcleo, e a máquina não estava ociosa de outra forma (média de carga 4–14 durante as execuções), então leia a coluna p95 e a variação como limites superiores. * **Runtimes.** Rust 1.97 (perfil release), Node.js 22.23, Python 3.14 para as linhas de HMAC e de chave de agente padrão. A linha do `coincurve` roda em Python 3.13, porque o `coincurve` ainda não publica wheel para Python 3.14. A linha de chave de agente padrão mede o mesmo em 3.13 (3,5 ms), então o interpretador não explica a diferença. * **Fixture.** Idêntica nos três SDKs: `POST`, caminho `/api/v1/orders`, query vazia, um corpo de ordem limite de 155 bytes, um timestamp fixo. O signatário de agente emite um nonce novo a cada iteração, como faz em uma escrita real. Ambos os esquemas produzem assinaturas idênticas byte a byte entre os SDKs para essa fixture. * **Procedimento.** Dois segundos de aquecimento, depois cada assinatura é cronometrada individualmente (Rust 20.000, TypeScript 5.000, Python 3.000 ou 5.000) e p50 e p95 são extraídos das amostras. Assinaturas por segundo é o número de amostras dividido pelo tempo de relógio do loop cronometrado. Cada benchmark rodou cinco vezes, intercalado com os outros. A tabela mostra a execução mediana e a faixa de p50 nas cinco. O bench de Rust também roda o criterion, cuja estimativa de média coincidiu com o loop cronometrado (76–85 µs para a chave de agente). * **Rode de novo.** Cada SDK traz seu bench: `cargo bench --bench signing` no `nexus-exchange-rs`, `pnpm bench` no `nexus-exchange-ts` e `python bench/signing_bench.py` no `nexus-exchange-py`. O bench de Python imprime qual backend do `eth-keys` ele mediu. ### Projetando para os limites * **Use lotes em vez de loops.** `POST /orders/batch` cobra `1 + floor(n / 40)`, então 40 ordens em uma requisição custam um quadragésimo de 40 envios avulsos. * **Use stream em vez de polling.** Dados do livro de ofertas e de negociações pelo WebSocket não custam nada do seu orçamento de requisições e chegam antes: o frame de assinatura é um frame de entrada, e o stream que vem depois é gratuito. * **Orce as leituras pesadas pelo custo real.** `/fills`, `/orders/history`, `/account/summary` e `/account/portfolio-history` custam 5 cada. Consultar as quatro a cada segundo custa 20/s, que é o orçamento inteiro de um chamador Pro. * **Prefira uma leitura coerente.** `GET /account/state` retorna o resumo e todas as posições abertas juntos. É mais barato do que duas chamadas e livre da condição de corrida entre elas (veja [Portfólio e estado da conta](/api-reference/pt-br/guides/portfolio.md)). * **Faça cache do que não muda.** Os metadados de mercado de `GET /markets` não precisam ser buscados de novo a cada ciclo. * **Controle o ritmo pelos cabeçalhos e por `/account/rate-limit`.** Consultar esse endpoint é gratuito. Tentar de novo às cegas depois de um `429` não é. ### Relacionados * [Especificação OpenAPI](https://github.com/nexus-xyz/nexus-exchange-api): pesos por operação, classes e semântica dos cabeçalhos, normativos * [Redes](/api-reference/pt-br/guides/networks.md): como uma rede é selecionada e o que vincula uma chave a ela * [Portfólio e estado da conta](/api-reference/pt-br/guides/portfolio.md): os endpoints de leitura pesada e como lê-los em uma só chamada * [Limites de requisições e de conexão](https://docs.nexus.xyz/exchange/apis-and-rates/rate-limits): janela do HMAC, tempo de vida dos tokens, cota do faucet * [Guia para market makers](https://docs.nexus.xyz/exchange/apis-and-rates/market-maker-guide): como solicitar o nível MarketMaker * [Visão geral das interfaces](/api-reference/pt-br/readme.md) > **Status:** prévia de desenvolvimento na testnet. A mainnet não foi lançada. Todo teto nesta página é configuração atual, não um contrato congelado. Leia `/account/rate-limit` em produção em vez de fixar um número no código, e fixe uma versão publicada da especificação para que os pesos por operação contra os quais você constrói permaneçam fixos. O estado do limitador ainda não é durável entre reinicializações do gateway. Credenciais e saldos da testnet não têm valor no mundo real. --- # Agent Instructions This documentation is published with GitBook. GitBook is the documentation platform designed so that both humans and AI agents can read, navigate, and reason over technical content effectively. Learn more at gitbook.com. ## Querying This Documentation If you need additional information that is not directly available in this page, you can query the documentation dynamically by asking a question. Perform an HTTP GET request on the current page URL with the `ask` query parameter, and the optional `goal` query parameter: ``` GET https://docs.nexus.xyz/api-reference/pt-br/guides/rate-limits.md?ask=&goal= ``` `ask` is the immediate question: it should be specific, self-contained, and written in natural language. `goal` is optional and describes the broader end goal you are ultimately trying to accomplish on behalf of the user. GitBook uses it to tailor the answer towards what is most useful for that goal. The response will contain a direct answer to the question and relevant excerpts and sources from the documentation. Use this mechanism when the answer is not explicitly present in the current page, you need clarification or additional context, or you want to retrieve related documentation sections.