Segurança
Revisão de segurança
Uma revisão interna do código-fonte dos contratos. Nenhum terceiro auditou os contratos ainda, e esta página não substitui essa auditoria.
O que foi revisado
O código-fonte do Exchange e do seu módulo de administração, as bibliotecas que ele liga, a lógica de ordens, pagamentos e liquidações, depósitos e saques, chaves de sessão, o executor em lote, os proxies de depósito, o staking, o token e suas recompensas. O código foi lido como está no commit e456c4d (2026-11-06). Os serviços fora da cadeia, os aplicativos e os scripts de implantação ficaram fora do escopo.
Resultado
A revisão não encontrou nenhum defeito de gravidade crítica ou alta no código dos contratos. Cada caminho que move fundos foi lido linha a linha e se sustentou. O código adicionado mais recentemente (o staking, o token e o fechamento pela carteira) é o que teve menos revisão; foi lido por inteiro, e a contabilidade do staking também foi testada como descrito abaixo.
O que se sustentou
- Controle de acesso. Toda função que altera o estado verifica quem a chama antes de mudar qualquer coisa. O módulo de administração não pode ser usado sozinho. A propriedade não pode ser renunciada, e só o proprietário pode atualizar um contrato.
- Assinaturas. As mensagens tipadas levam a cadeia e o contrato verificador, rejeitam assinaturas maleáveis, usam cada nonce uma única vez e só depois de a assinatura ser verificada, e expiram. Uma chave de sessão não pode assinar uma mensagem destinada à carteira, a carteira não pode assinar uma operação, e revogar todas as chaves de uma vez funciona.
- Fluxo de valor. A contabilidade entre o caixa do pool, o pool rastreado, a fila de pagamentos e o balde lateral permanece consistente. Não há aritmética sem verificação, as conversões para tipos menores são verificadas e cada arredondamento vai no sentido que o projeto fixa. As taxas têm teto, e um saque reduz o saldo antes de a ação na Hyperliquid ser enviada.
- Reentrada. Toda função que move fundos é protegida contra reentrada, e o estado é gravado antes das chamadas externas. O hook do token roda com uma quantidade fixa de gás, então quem chama não consegue forçar seu adiamento.
- Endereços de depósito. Um proxy de depósito só pode enviar ações da HyperCore pelo Exchange, e seu dono só pode retirar dele tokens EVM e HYPE nativo. A derivação do endereço não mudou.
- Padrões de código. Sem
selfdestruct,tx.origin,.transfer,.sendnemcallcode. As únicas delegatecall vão para o módulo de administração e para as bibliotecas ligadas. - O token que queima. BACK entra em staking no momento em que é cunhado e queima 7 dias depois, na meia-noite UTC seguinte. Nada começa a contar até o LP contábil alcançar $500,000 pela primeira vez. O dia de vencimento de cada lote, o percurso preguiçoso pelos lotes de uma conta, o cronograma global, os mints reexecutados e o início da contagem regressiva estão de acordo com este projeto, que Recompensas e resgates descreve.
Como a contabilidade do staking foi testada
Escreveu-se um modelo separado, só a partir das regras publicadas, sem ler a aritmética do contrato. Sequências aleatórias de mints (com reexecuções tardias), o início da contagem regressiva, distribuições, resgates e saltos no tempo (até um segundo antes da meia-noite, exatamente à meia-noite, em dias, e até 150 dias parado) rodaram contra o contrato e contra o modelo e foram comparadas a cada passo. Em 76,800 chamadas, e mais 38,400 com longas pausas, não houve nenhuma diferença: os saldos vivos e a oferta coincidiram exatamente, as recompensas coincidiram dentro da poeira de arredondamento, nenhuma conta conseguiu resgatar mais do que o reservado, e cada resgate pagou exatamente o valor pendente. Dois bugs colocados de propósito foram detectados.
Achados
| Gravidade | Achado | Situação |
|---|---|---|
| Média (garantia) | Os analisadores estáticos e os fuzzers (Slither, Aderyn, Medusa, Echidna, Halmos, Gambit) rodaram pela última vez antes de o token ser reescrito. O código novo tem a suíte de testes, a campanha de invariantes com a duração padrão e o modelo acima. | Serão executados de novo antes da auditoria externa. |
| Média (projeto, divulgado) | No lançamento, todas as proteções de preço na cadeia estão desligadas: as execuções usam o ponto médio do melhor preço de compra e de venda bruto da Hyperliquid, com alavancagem alta. A proteção vem dos limites do relayer, dos keepers e da sentinela, tudo fora da cadeia. | Divulgado; veja Riscos. |
| Baixa | O consentimento de taxa de builder de uma chave de sessão não é apagado quando a chave é registrada de novo com o tipo de assinatura antigo, nem quando é revogada; assim, um builder indicado depois poderia ganhar até a taxa consentida antes. O teto das taxas de builder limita isso. | Será corrigido antes da implantação em produção. |
| Baixa | A fila de mints adiados não tem como pular uma entrada. Se uma entrada falhasse em toda reexecução, os mints seguintes ficariam esperando atrás dela. Uma mudança nos custos de gás na HyperEVM, ou um bug numa atualização futura, poderia causar isso. | A recuperação é uma atualização pelo timelock. |
| Média (econômica, divulgada) | Desde 2026-11-08, uma perda cunha sobre toda a sua base de cunhagem: os ganhos não são compensados com perdas posteriores e nenhum teto limita uma conta. Um trader pode manter posições opostas e cunhar sobre a perna perdedora aconteça o que acontecer com o mercado. Esta revisão leu o código antes dessa mudança. |
Divulgado. As taxas, a queima depois da contagem regressiva e a parte que os outros tokens vivos levam de cada distribuição são os únicos freios; veja Riscos. |
| Baixa | O guardião pode pausar a negociação, retirar um mercado para sempre, trocar o keeper de mercado e o keeper fora do horário, autorizar ou remover relayers, e aumentar a quantidade de gás das leituras de preço. Ele não pode mover fundos nem tirar a pausa. | Por projeto; veja Riscos. |
| Info | O saldo e a oferta do token são exatos o tempo todo, mas o evento de um token queimado só é registrado quando a conta é tocada de novo; por isso, ferramentas que somam eventos mostram tokens queimados como vivos. | Leia os saldos, não os eventos. |
| Info | Momento das recompensas: um mint logo antes de uma distribuição recebe uma parte proporcional, o primeiro detentor leva o que não estava alocado e, depois de uma longa inatividade, os lotes vencidos dividem as distribuições feitas nesse intervalo. Nunca se paga mais do que foi distribuído. | Documentado; solvente nos testes. |
| Info | A string de versão do Exchange indica uma versão anterior à de sua interface. | Será corrigido antes da implantação em produção. |
| Info | Uma função do proxy de depósito nunca é chamada. | Mantida, porque o código do proxy fixa todos os endereços de depósito. |
| Info | O proprietário pode creditar uma conta com um excedente da Hyperliquid que ninguém reivindicou. | Uma suposição de confiança; atrás do timelock em produção. |
O que não foi coberto
- Os contratos lens somente de leitura, a biblioteca de administração de mercados e a biblioteca de limites foram só percorridos, não revisados linha a linha.
- A suíte de testes completa e as verificações do layout de armazenamento, da interface, do tamanho dos contratos e do código do proxy de depósito não foram executadas de novo para esta revisão. Confiou-se nos resultados da última execução completa.
- Testes com fork contra a Hyperliquid, os scripts de implantação além das verificações de papéis, os serviços fora da cadeia e os aplicativos.
- A regra de cunhagem do token depois da mudança de
2026-11-08(sem compensação de ganhos, sem teto), o comportamento de gás do hook do token e se os precompiles da Hyperliquid se comportam como os testes supõem.
Manter esta página honesta
Esta é uma revisão em um momento específico. Ela não diz nada sobre mudanças feitas nos contratos depois do commit acima. Os contratos são atualizáveis atrás de um timelock, então o que está implantado em cada momento deve ser conferido com os endereços dos contratos.