Mergulho Profundo no HIP-3: Uma Perspectiva Centrada no Construtor

Hyperliquid Improvement Proposal 3 (HIP-3) [1] apresenta uma mudança fundamental na forma como os mercados de perpétuos são criados e escalados no Hyperliquid. Ao abrir o processo de listagem de mercados para desenvolvedores terceiros, o HIP-3 transforma a listagem de uma ação discricionária controlada pela plataforma em uma interface baseada em regras no nível do protocolo.

Desde sua implantação na mainnet, os mercados criados por desenvolvedores geraram mais de US$ 13 bilhões em volume de negociação em aproximadamente três meses, demonstrando que o HIP-3 pode melhorar materialmente a escalabilidade e a flexibilidade da expansão de mercados. No entanto, essa mudança não apenas descentraliza o poder; ela também redistribui responsabilidades. Riscos que anteriormente eram absorvidos ou mitigados pelas operações centralizadas da plataforma agora recaem diretamente sobre os desenvolvedores.

Como resultado, a questão central sob o HIP-3 não é mais se um mercado pode ser lançado, mas se ele pode ser operado com segurança ao longo do tempo. Este relatório analisa o HIP-3 a partir de uma perspectiva centrada no desenvolvedor, com foco em como os mercados são definidos e operados, os riscos que os desenvolvedores enfrentam e como esses riscos — em particular os riscos relacionados a oráculos — podem ser mitigados.

0x0 Contexto

A arquitetura do Hyperliquid [2] se diferencia desse modelo ao desacoplar a infraestrutura de execução e risco da definição de mercado. Seu design de camada dupla consiste em:

• HyperCore, uma blockchain Layer 1 desenvolvida especificamente para negociação de derivativos, fornecendo matching, liquidação e liquidação financeira unificados.
• HyperEVM, uma camada de aplicação compatível com EVM que permite lógica extensível e interação com desenvolvedores.

Como a execução e a liquidação são impostas de forma uniforme no nível do protocolo, novos mercados podem reutilizar a mesma infraestrutura principal sem reimplementar a lógica crítica de segurança. No entanto, a precificação não pode ser totalmente padronizada. Entradas de oráculos, design de alavancagem e operações em tempo real inevitavelmente variam por mercado, tornando a precificação a interface primária onde a descentralização encontra o risco.

Apesar dessa arquitetura, o processo de listagem dos mercados de perpétuos nativos do Hyperliquid, também chamados de perps operados por validadores, ainda se assemelha à abordagem tradicional de CEX. A listagem de novos contratos é amplamente conduzida pela equipe central, enquanto os delistings são determinados por votação dos validadores.

O HIP-3 foi introduzido para descentralizar esse processo de listagem, permitindo mercados de perpétuos implantados por desenvolvedores. Ele formaliza a separação entre definição de mercado e execução imposta pelo protocolo, permitindo que os desenvolvedores definam e operem mercados, enquanto o protocolo impõe limites rígidos de execução e risco. Assim, o HIP-3 representa um marco fundamental em direção a um processo de listagem de perps totalmente descentralizado.

0x1 Responsabilidades do Desenvolvedor: Definição e Operação

Sob o HIP-3, os desenvolvedores assumem responsabilidade total pelo gerenciamento do ciclo de vida do mercado. Nesta seção, primeiro descrevemos o fluxo de lançamento do mercado e, em seguida, nos concentramos nos controles operacionais que determinam mais diretamente a estabilidade do mercado em produção.

0x1.1 Fluxo de Lançamento do Mercado: Definição e Operação

No HIP-3, lançar um mercado não é uma ação única. Como ilustrado no fluxo completo de lançamento de mercado abaixo, é um processo que abrange duas fases distintas: definição do mercado (etapas 1 a 4) e operação do mercado (etapa 5).

Durante a fase de definição do mercado, um desenvolvedor deve primeiro fazer stake de 500.000 HYPE na mainnet. Após atender ao requisito de staking, o desenvolvedor pode implantar uma DEX de perpétuos, que forma um domínio de negociação independente com seu próprio sistema de margem, livros de ordens e configurações controladas pelo implantador. No nível da DEX, o desenvolvedor seleciona um ativo de cotação para ser usado como garantia em todos os mercados daquela DEX. O ativo de cotação selecionado deve manter o status permissionless, pois perder esse status desativará a DEX correspondente. O desenvolvedor então define os parâmetros centrais do mercado, incluindo especificações de oráculos, parâmetros de contrato como símbolo e limites de alavancagem, e tabelas de margem. Os primeiros três mercados podem ser implantados diretamente, enquanto mercados adicionais exigem a aquisição de slots por meio de um leilão holandês.

Leilão holandês: Cada rodada dura 31 horas, o preço inicial é sempre 2× o preço final anterior (último preço vencedor / preço mínimo).

Assim que os mercados estão ativos, o desenvolvedor entra na fase de operação do mercado. Essa fase envolve a atualização contínua dos preços do oráculo via interface setOracle, a manutenção de configurações de alavancagem e margem, o monitoramento de liquidez e open interest, e a execução de ações de emergência, como interromper a negociação e liquidar posições quando necessário.

Na prática, as falhas mais graves no HIP-3 ocorrem não durante a definição do mercado, mas durante a operação prolongada em condições de mercado tensionadas. Importante destacar que a responsabilidade do desenvolvedor não termina imediatamente após a interrupção dos mercados. O unstaking só é possível após a liquidação de todos os mercados, e o stake permanece sujeito a slashing durante o período obrigatório de unstaking.

0x1.2 Áreas de Foco Críticas: Precificação e Solvência

Os desenvolvedores enfrentam duas áreas de foco acopladas entre a definição e a operação do mercado: configuração de oráculo e formação de preço, e solvência do mercado sob pressão. Essas duas áreas estão intimamente acopladas, pois falhas de precificação podem rapidamente se propagar em estresse de solvência por meio dos controles de risco no nível do protocolo.

1. Configuração de Oráculo e Formação de Preço

O Hyperliquid define dois preços:

• Preço do Oráculo: uma mediana ponderada dos preços médios à vista das principais exchanges externas, projetada para ser independente dos dados de mercado internos do Hyperliquid e usada principalmente para ancorar o financiamento.
• Preço de Marcação: um preço de risco interno derivado de múltiplos insumos, incluindo o preço do oráculo e dados de mercado local, usado para PnL (lucro e perda) não realizado e controles de risco.

Em resumo, o preço do oráculo ancora o financiamento, enquanto o preço de marcação impulsiona verificações de margem, liquidações e gatilhos de TP (Take Profit) e SL (Stop Loss).

No HIP-3, os papéis do preço do oráculo e do preço de marcação não mudam, mas o mecanismo de cálculo muda:

a) Entradas para setOracle

• oraclePx (obrigatório): mesma definição do HyperCore.
• markPx (opcional): 0–2 candidatos de preço de marcação calculados externamente.
• externalPerpPx (obrigatório): um valor de referência para evitar desvios repentinos no preço de marcação.

Os desenvolvedores geralmente implantam nós relayer para alimentar preços: oraclePx é calculado a partir de múltiplas fontes externas, markPx é calculado pelo relayer com um algoritmo personalizado, e externalPerpPx a partir da mediana ponderada dos preços médios de perps de múltiplas CEXs.

b) Preço de marcação real

• Calcular o mark local: mediana(melhor oferta de compra, melhor oferta de venda, última negociação).
• Pegar o mark local e o markPx (0–2 valores) juntos e calcular a mediana para obter o novo preço de marcação.

c) Restrições de setOracle

• Frequência de atualização: pelo menos 2,5s entre chamadas; se markPx não for atualizado por 10s, reverte para o preço de marcação local.
• Limites de amplitude: markPx pode mudar no máximo ±1% por atualização; todos os preços são limitados dentro de 10× o preço do início do dia.

Por que o Tipo de Ativo é Importante para a Precificação no HIP-3?

No HIP-3, mercados de perpétuos podem ser lançados para qualquer tipo de ativo. Esses ativos geralmente podem ser divididos em ativos 24/7 (negociáveis a qualquer hora) e ativos não-24/7 (negociáveis apenas durante horários específicos de mercado, sem negociação à vista fora desses horários). A diferença nos horários de negociação determina fundamentalmente como os preços são obtidos e mantidos.

Para ativos 24/7 (por exemplo, BTC), preços relativamente estáveis podem ser obtidos continuamente agregando dados de CEXs, DEXs ou serviços de oráculo confiáveis.

Para ativos não-24/7 (por exemplo, ações), liquidez suficiente e preços de mercado externos confiáveis só estão disponíveis durante o horário oficial de negociação. Para manter esses ativos sendo negociados continuamente no HIP-3, um mecanismo de precificação separado deve ser usado durante o horário fora do mercado.

Tomando os mercados de perps de ações na trade.xyz como exemplo:

• Durante o horário de mercado, preços estáveis de oráculo são fornecidos por serviços de oráculo externos como o Pyth.
• Durante o horário fora do mercado, os preços são ajustados com base no último preço de fechamento do ativo, combinado com a pressão interna de compra/venda do livro de ordens. O preço de marcação é restrito a flutuar dentro de ±1 / max_leverage do último preço de fechamento (por exemplo, Tesla: alavancagem de 10× → ±10%).

2. Solvência do Mercado sob Pressão

O Hyperliquid adota dois mecanismos, liquidação e ADL (auto-deleveraging), para manter a solvência do mercado. No HIP-3, tanto a liquidação quanto o ADL seguem amplamente o design do HyperCore. A principal diferença é uma restrição no nível do protocolo: o HLP (Hyperliquidity Provider), que serve como o cofre do protocolo, não pode assumir posições arriscadas em mercados HIP-3. Como resultado, o buffer intermediário do cofre que pode absorver posições entre a liquidação do mercado e o ADL no HyperCore está ausente no HIP-3.

Dada a importância desse caminho de liquidação para ADL durante condições de mercado tensionadas, revisamos a liquidação e o ADL em detalhes abaixo. Toda a mecânica de solvência discutida aqui assume margem isolada, o único modo de margem atualmente suportado nos mercados HIP-3.

a) Liquidação

A liquidação é acionada quando o valor líquido da posição (valor da posição isolada) é insuficiente para atender ao requisito de margem de manutenção, tornando-a liquidável. Todas as verificações relacionadas à liquidação são baseadas no preço de marcação, não em um preço de execução específico.

A fórmula do preço de liquidação é definida a seguir:

Onde:

• side: 1 para posições compradas, -1 para posições vendidas
• l é a taxa de margem de manutenção

O valor de MAINTENANCE_LEVERAGE é determinado pelo nível de margem correspondente à posição. Desse nível, obtém-se a taxa de margem de manutenção mmr:

Quando os níveis de margem estão configurados, aplica-se o mmr do nível que corresponde ao valor nocional da posição no preço de liquidação.

• margin_available (isolada): isolated_margin - maintenance_margin_required

Assim que uma posição se torna liquidável, o sistema primeiro tenta fechá-la via ordens de mercado no livro de ordens. Se a execução conseguir trazer o risco de volta a limites seguros, qualquer margem restante é devolvida ao trader.

No entanto, em casos de profundidade insuficiente no livro de ordens ou lacunas de preço, o preço médio real de execução pode ser significativamente pior que o preço de marcação, resultando em um ''déficit de liquidação''.

O valor da posição isolada refere-se ao valor líquido de uma posição isolada ao preço de marcação atual, representando a margem alocada a essa posição após contabilizar o PnL não realizado.

b) ADL (auto-deleveraging)

Em cenários extremos, o mecanismo de ADL (auto-deleveraging) atua como última salvaguarda.

O ADL é acionado quando o valor de uma posição isolada torna-se negativo. O sistema classifica as contrapartes lucrativas por PnL e alavancagem, então reduz ou fecha forçosamente essas posições ao preço de marcação anterior (o preço de marcação registrado anteriormente antes do ADL ser acionado). Usando os lucros do lado vencedor para compensar o déficit, o protocolo permanece solvente e não incorre em dívidas ruins.

O índice de classificação é calculado como:

Aqui, notional_position refere-se ao valor de mercado absoluto da posição ao preço de marcação vigente, calculado como |tamanho_da_posição| × preço_de_marcação. account_value denota o patrimônio da conta ao preço de marcação, ou seja, o valor da garantia mais o PnL não realizado.

Exemplo:

• Antes do ADL ser acionado, o preço de marcação do sistema = 3.000.
• Devido às restrições do setOracle, o novo preço de marcação só pode ser atualizado para 2.970 (−1%).
• No entanto, o lado de oferta de compra do livro de ordens está muito raso. Após as ordens de mercado de liquidação atingirem o livro, o preço médio real de execução = 2.910 (−3% em relação a 3.000).
• As perdas nas posições compradas são liquidadas a 2.910, potencialmente empurrando o valor da posição isolada abaixo de zero e criando um déficit, o que aciona o ADL.
• O ADL então seleciona posições do lado oposto (vendas lucrativas) e as reduz/fecha forçosamente ao preço de marcação anterior = 3.000, transferindo o déficit para ''o lado vencedor ganhar passivamente menos''.

0x2 Cenário de Risco do Desenvolvedor

No HIP-3, o risco não é mais abstrato ou puramente teórico para os desenvolvedores. Por meio do staking e do slashing governado por validadores, falhas operacionais e configurações incorretas podem se traduzir diretamente em penalidades econômicas. Como resultado, entender como o slashing é acionado e quais tipos de comportamento do desenvolvedor podem levá-lo torna-se central para o modelo de risco do desenvolvedor. Portanto, esta seção primeiro explica o mecanismo de slashing como estrutura de responsabilidade e, em seguida, analisa as duas principais fontes de risco do desenvolvedor no HIP-3.

0x2.1 Mecanismo de Slashing e Responsabilização

O HIP-3 impõe responsabilização por meio de staking e slashing governado por validadores. O slashing é estritamente baseado em resultados. O Hyperliquid não distingue entre comportamento malicioso, erros operacionais, comprometimento de chave privada ou falha de dependência de terceiros.

Requisito de stake: Na mainnet, os desenvolvedores devem manter 500k HYPE em stake. Mesmo que um desenvolvedor interrompa todos os seus mercados, deve continuar mantendo esse stake por 30 dias (a responsabilidade não desaparece imediatamente porque a negociação é interrompida).

Se as ações de um desenvolvedor resultarem em estado inválido, tempo de inatividade prolongado ou degradação significativa de desempenho, o slashing pode ser acionado. Dependendo da gravidade, o slashing pode variar de redução parcial do stake até queima total do stake. Esse design torna os desenvolvedores economicamente responsáveis pelo comportamento completo em tempo de execução de seus mercados.

A porcentagem de slashing é decidida por votação dos validadores, com limites superiores de referência:

• Estado inválido / tempo de inatividade prolongado: até 100%
• Tempo de inatividade curto: até 50%
• Degradação de desempenho: até 20%

Os tokens cortados são queimados, não redistribuídos.

No HIP-3, o risco do desenvolvedor origina-se principalmente de duas fontes: configuração incorreta de parâmetros internos e dependências externas de oráculos. As seções a seguir examinam essas duas fontes em detalhes e explicam como elas podem se traduzir em resultados de slashing.

0x2.2 Riscos por Configuração Incorreta de Parâmetros Internos

Os riscos de configuração incorreta incluem alavancagem excessiva em mercados de baixa liquidez, design inadequado da tabela de margem, mudanças repentinas de parâmetros que tornam grandes números de posições liquidáveis, e uso inadequado de controles de emergência, como interrupção da negociação.

Esses riscos são amplamente determinísticos e evitáveis. Com cuidado suficiente, revisão e disciplina operacional, a maioria dos erros de configuração interna pode ser evitada. Embora importantes, eles não são os riscos estruturalmente mais desafiadores no HIP-3.

1. setOracle

Os preços do oráculo geralmente vêm dos servidores relayer do desenvolvedor, o que introduz risco de centralização. Se a chave privada vazar ou o relayer sofrer DDoS, o preço do oráculo do mercado pode ser manipulado maliciosamente ou permanecer divergente por um longo tempo.

2. haltTrading

O desenvolvedor pode cancelar todas as ordens no mercado via haltTrading e fechar posições ao preço de marcação atual. Esta operação deve ser usada com cautela. Por exemplo, se o mercado for detectado sendo manipulado maliciosamente por um atacante e haltTrading for chamado para fechar ao preço de marcação, pode realizar diretamente o lucro não realizado do atacante (onde o atacante poderia, de outra forma, ter dificuldade em encontrar ordens opostas suficientes) e também pode levar a dívidas ruins.

3. setMarginTableIds & InsertMarginTable

• InsertMarginTable: define uma nova tabela de margem, especificando requisitos de margem e alavancagem máxima para uma classe de ativos.
• setMarginTableIds: vincula um mercado a um marginTableId especificado.

Para um mercado de baixa liquidez / market-making insuficiente, definir a alavancagem máxima muito alta aumenta a probabilidade de acionar o ADL.

Trocar repentinamente o marginTableId é equivalente a modificar a taxa de margem de manutenção das posições dos usuários, o que pode transformar muitas contas de seguras para liquidáveis ao mesmo tempo, desencadeando liquidações em cascata.

4. setMarginModes

O HIP-3 atualmente permite apenas margem isolada e pode suportar margem cruzada no futuro. Em uma DEX que hospeda mercados de alta liquidez e baixa liquidez, a margem cruzada pode permitir contágio de risco onde perdas em mercados ilíquidos se propagam para mercados líquidos. Portanto, até que a equipe oficial forneça uma solução madura, não é recomendado que os desenvolvedores introduzam margem cruzada.

0x2.3 Riscos por Dependências Externas de Oráculos

Para ativos 24/7, o risco principal está na precisão e estabilidade dos serviços de oráculo externos, bem como nos riscos de centralização dos servidores relayer discutidos anteriormente. Qualquer interrupção, atraso ou manipulação nessas dependências externas pode afetar diretamente a integridade da precificação e os controles de risco posteriores.

Para ativos não-24/7, a superfície de risco é significativamente mais ampla e está concentrada principalmente em como os preços do oráculo são obtidos ou calculados durante os horários fora de negociação.

Tomando a trade.xyz como exemplo, durante os períodos fora do mercado, os preços são derivados de uma combinação do último preço disponível do oráculo externo e preços internos de mercado. Nos finais de semana, os mercados de perpétuos de ações frequentemente sofrem com liquidez severamente reduzida — os livros de ordens ficam rasos e os formadores de mercado reduzem as cotações — enquanto nenhum preço de oráculo externo está disponível para fornecer ancoragem. Mesmo que um limite máximo de movimentação de preço seja imposto (por exemplo, 1 / max_leverage), essa restrição ainda pode ser muito frouxa para ativos de baixa volatilidade. Movimentos de preços dentro desse intervalo ainda podem acionar liquidações em grande escala ou até eventos de ADL.

Em 14 de dezembro de 2025, o mercado XYZ100-USDC na trade.xyz — um contrato perpétuo rastreando o NASDAQ-100 — foi manipulado. Um atacante vendeu a descoberto 398 XYZ100 (aproximadamente US$ 10M USDC em exposição nocional), causando grave desvio de preço. Um grande número de posições compradas foi liquidado, e as próprias liquidações empurraram os preços ainda mais para baixo, resultando em aproximadamente US$ 13M USDC em liquidações do lado comprado.

Por outro lado, durante os horários fora de negociação, a ausência de um preço de oráculo contínuo e ancorado externamente força os mercados a depender de uma faixa de precificação interna restrita formada pelo "último preço externo + livro de ordens interno" (por exemplo, a trade.xyz limita a flutuação máxima a 1/max_leverage).

O risco mais crítico surge na transição de reabertura do mercado. Os mercados externos podem fornecer repentinamente um preço de referência claro e autoritativo. Se esse preço apresentar uma lacuna significativa em relação à precificação interna fora do horário, o sistema enfrenta dois caminhos desfavoráveis: ou os preços permanecem limitados, resultando em uma divergência severa entre o valor justo externo e os preços negociáveis, ou o sistema muda rapidamente de volta para a ancoragem externa, acionando reprecificação abrupta. Ambos os cenários podem concentrar a pressão de liquidação em uma janela de tempo curta e, em casos extremos, levar a um surto de eventos de ADL.

0x3 Controles de Risco do Desenvolvedor

A disciplina de configuração sozinha não pode eliminar o risco. As estratégias de mitigação mais eficazes concentram-se em reduzir a exposição a falhas de dependência de oráculos.

0x3.1 Selecionando Oráculos Estáveis

Para ativos negociados não-24/7, como ações, o principal desafio está na precificação durante os horários fora do mercado. Durante esses períodos, referências de preços estáveis e ancoradas externamente são escassas, tornando os mercados mais suscetíveis à manipulação ou deriva endógena sob liquidez reduzida.

Atualmente, as abordagens da indústria geralmente se dividem em duas direções:

• Suspender atualizações de oráculo e restringir negociações durante os horários fora do mercado. Por exemplo, o protocolo Lighter aceita apenas ordens de redução de posição quando o mercado subjacente está fechado. Protocolos como o Ostium reduzem ainda mais a alavancagem máxima durante os horários fora do mercado e liquidam forçosamente posições que excedem os novos limites.
• Adotar um ''mecanismo de precificação interna'', como visto na trade.xyz, onde o protocolo continua operando fora do horário confiando em algoritmos internos de liquidez e precificação quando os dados externos não estão disponíveis.

Essas duas abordagens refletem uma troca fundamental entre segurança e experiência do usuário. A primeira abordagem prioriza controles rígidos de risco, mas degrada significativamente a continuidade de negociação e a experiência do usuário. A segunda preserva a negociação contínua, mas, devido à falta de referências externas, aumenta o risco de que os preços internos divirjam do valor fundamental do ativo.

Durante os períodos fora do mercado, a precificação do protocolo deve evitar degenerar completamente em um preço puramente interno. Em vez disso, introduzir âncoras de referência externas pode reduzir os riscos de descolamento e lacunas. As possíveis referências incluem:

• Blue Ocean ATS. Como plataforma de negociação após o horário/noturna, pode fornecer um grau de referência de preço contínua durante os fechamentos (mais oportuna que o "último fechamento"), ajudando a gerar preço de oráculo no período de fechamento ou servindo como linha de base de monitoramento para detecção de descolamento.
• Cotações de CFD de fim de semana da IG. As cotações de CFD de fim de semana podem fornecer um sinal de preço alternativo refletindo ''expectativas do mercado de fim de semana'', adequado como âncora externa ou comparação de monitoramento durante fechamentos para ajudar a detectar antecipadamente a direção e magnitude provável de uma ''lacuna de abertura''.

A característica comum dessas fontes é sua capacidade de fornecer sinais de preço durante os horários fora do mercado. No entanto, elas não compartilham a mesma estrutura de mercado que o mercado à vista subjacente e, portanto, são mais adequadas como âncoras, referências ou sinais de alerta antecipado, em vez de substitutos incondicionais.

0x3.2 Verificação de Preço

No HIP-3, os preços do oráculo são obtidos de servidores relayer operados pelo desenvolvedor, o que levanta preocupações em torno da centralização. Para mitigar isso, os desenvolvedores são incentivados a implementar uma estrutura de verificação de preços que permita a qualquer usuário ou instituição verificar a correção e a imparcialidade dos preços fora da cadeia — semelhante ao RedStone, que agrupa preços junto com fontes de dados e provas criptográficas.

1. Transparência de Dados

• Especificação do algoritmo: divulgar publicamente algoritmos de precificação e lógica de cálculo.
• Lista de fontes de dados: todas as fontes devem ser públicas, imunes à manipulação pelo desenvolvedor, e documentadas com interfaces e parâmetros detalhados.
• Regras de envio de preços: permissões, condições de acionamento, frequência de atualização e restrições de volatilidade para setOracle.

2. Provas de Preço

Para cada chamada setOracle, gerar uma prova correspondente contendo:

• Entradas: respostas brutas (ou normalizadas) de cada fonte de dados no timestamp de amostragem.
• Cálculo: valores intermediários reproduzíveis em cada etapa de cálculo.
• Saídas: o preço do oráculo enviado na cadeia.

Cada prova é serializada em um proofHash, que então é assinado pelo oracleUpdater.

3. Compromissos na Cadeia

• Manter uma lista sequencial de entradas proofHash em uma árvore de Merkle.
• Periodicamente (por exemplo, a cada hora ou diariamente) publicar o MerkleRoot na cadeia.

4. Verificação

• Fornecer ferramentas de código aberto ou uma página web onde os usuários insiram um intervalo de tempo ou um hash de transação setOracle
• Verificar assinaturas, timestamps e MerkleRoot, etc.
• Recalcular preços do oráculo usando o algoritmo público para comparação.

0x3.3 Monitoramento de Risco

A verificação de preços torna o setOracle recalculável e auditável, estabelecendo se os feeds de preços são confiáveis. No entanto, não pode proteger contra deterioração do mercado em tempo real. Interrupções de feed, divergência de preços e degradação de liquidez — quando combinadas com grande open interest (OI) — podem facilmente escalar anomalias localizadas em riscos sistêmicos como liquidações em cascata ou até eventos de ADL.

Portanto, anomalias de mercado devem ser detectadas e convertidas em sinais observáveis o mais cedo possível, e tratadas dentro de uma janela de tempo para conter o risco dentro de limites gerenciáveis.

Para tornar o monitoramento acionável em vez de fragmentado, organizamos os sinais em três camadas, cada uma mapeada para um modo de falha distinto e prioridade de resposta.

• O monitoramento do lado do preço detecta falhas no feed do oráculo e descolamento que podem invalidar os controles de risco na fonte, por isso é tratado como a prioridade mais alta e é tipicamente tratado via failover do relayer, limites de open interest e reduções de alavancagem.
• O monitoramento do lado do livro de ordens captura retirada de liquidez e profundidade falsificada que amplificam o slippage de liquidação e o risco de déficit, portanto as intervenções focam em limitar a exposição incremental e forçar a desalavancagem quando a fragilidade aumenta.
• O monitoramento do lado da posição rastreia a acumulação rápida de open interest e a concentração unilateral que tornam os mercados vulneráveis a cascatas, e geralmente tem prioridade mais baixa do que os sinais de preço e liquidez, servindo principalmente como uma camada de aviso antecipado que informa limites mais rígidos e alertas elevados.

As seções a seguir detalham cada camada, juntamente com os pontos de monitoramento correspondentes e as ações recomendadas.

1. Monitoramento do Lado do Preço

a) Falha no Feed do Oráculo

Métricas:

• Usar observáveis na cadeia para julgar se o feed está paralisado:

Limiares:

• Nível 1: ( ∆t > 5s ) — o processo do relayer pode estar travado ou bloqueado
• Nível 2: ( ∆t > 15s ) — os preços na cadeia podem estar severamente descolados e cada vez mais orientados pelo mercado

Ações:

• Nível 1: realizar verificações de integridade do relayer, alternar para relayers de backup e emitir alertas com diagnósticos de integridade
• Nível 2: chamar setOpenInterestCaps para reduzir o limite de OI

b) Descolamento de Preço

Métricas:

• Sinal A (d1): desvio entre o preço de marcação e o preço do oráculo.

• Sinal B (d2): desvio entre o preço médio do livro de ordens e o preço do oráculo.

• Sinal C (d3): desvio entre o preço de marcação e o preço médio.

• Sinal D (ext_diff): desvio entre o preço do oráculo e o preço de referência externo.

Lógica de Limiar:

• Nível 1: pelo menos 2 de A, B, D excedem os limiares.
• Nível 2: pelo menos 3 de A, B, C, D excedem os limiares por X segundos.

Ações:

• Nível 1: reduzir o limite de OI via setOpenInterestCaps.
• Nível 2: atualizar gradualmente as tabelas de margem para reduzir a alavancagem máxima por níveis, e ativar mecanismos de limitação nos relayers.
• Nível 3: alertas persistentes sob condições de Nível 2. O desenvolvedor então avalia se deve invocar haltTrading.

2. Monitoramento do Lado do Livro de Ordens

a) Retirada de Liquidez

Métricas:

• depth_band(±x%): liquidez do livro de ordens disponível dentro de ±x% do preço médio.
• spread = bestAsk - bestBid: spread de preço para medir o alargamento do spread.
• aggressiveVolume_Δt: volume de taker dentro de Δt (agregado por lado da negociação).
• impact_ratio: indicador de fragilidade do mercado (valores mais altos indicam maior vulnerabilidade ao impacto de preço).

Padrões de Risco:

• depth_band diminui enquanto spread e impact_ratio aumentam.

Ações:

• Nível 1: definir OI cap = OI atual via setOpenInterestCaps, limitando posições incrementais.
• Nível 2: forçar a desalavancagem via setMarginTableIds, enquanto liquida posições de alta alavancagem e alto risco.

b) Liquidez Falsificada

Padrões de Risco:

• Picos repentinos em depth_band seguidos de colapso em uma janela de tempo curta.

Ações:

• Nível 1: chamar setOpenInterestCaps para definir OI cap = OI atual.
• Nível 2: se combinado com descolamento grave, considerar interromper o mercado.

3. Monitoramento do Lado da Posição

O monitoramento do lado da posição não tenta prever a direção do preço. Em vez disso, identifica transições de atividade de negociação equilibrada para acumulação unilateral de posições. Quando o OI acumula rapidamente, as posições tornam-se altamente concentradas e o PnL do lado majoritário atinge extremos, mesmo choques exógenos menores podem desencadear cascatas de liquidação ou eventos de ADL.

Como resultado, as ações do lado da posição geralmente têm prioridade mais baixa do que as intervenções do lado do preço e do livro de ordens.

a) OI Excessivo de Curto Prazo

Métricas:

• OI_notional: nocional do open interest.
• Volume_24h_notional: volume nocional de 24 horas.

Uma razão em rápido aumento indica uma mudança de giro ativo para acumulação especulativa de posições e frequentemente precede volatilidade acentuada.

Ações:

• Nível 1: acionar alertas quando os limiares são excedidos.

b) PnL do Lado Majoritário

O lado majoritário refere-se ao lado (Comprado ou Vendido) com mais detentores de posição dentro da janela de observação.

Métricas:

• avgEntry_major: preço médio de entrada das posições do lado majoritário.
• size_major: tamanho total da posição do lado majoritário.
• equity_major: patrimônio total do lado majoritário.

O PnL do lado majoritário e sua razão são definidos da seguinte forma:

Ações:

• Nível 1: alertar quando o limiar for violado.
• Nível 2: se persistir, considerar chamar setOpenInterestCaps para reduzir o limite de OI.

0x4 Conclusão

A narrativa central do HIP-3 é simples. Ele transforma as listagens de mercado de um processo discricionário controlado por poucos em uma capacidade de nível de protocolo que qualquer desenvolvedor qualificado pode invocar uma vez que os requisitos sejam atendidos. Ao fazer staking, os desenvolvedores podem lançar suas próprias DEXs de perps no HyperCore, listar um conjunto inicial de mercados sem custo e adquirir slots adicionais por meio de leilões. Isso transforma a expansão de mercado de esperar por aprovação para escalonamento permissionless baseado em regras.

O que também é igualmente claro é que o HIP-3 não elimina o risco. Ele o reposiciona e reformula. Responsabilidades anteriormente absorvidas pelos controles de risco no nível da plataforma agora são amplamente assumidas pelos desenvolvedores por meio de seus insumos e qualidade operacional. Isso inclui precificação e cadência de atualização do oráculo via setOracle, a seleção e restrições de markPx, design de alavancagem em níveis por meio de tabelas de margem, faixas de precificação fora do mercado para ativos não-24/7, e controles poderosos como haltTrading, que pode conter perdas ou amplificá-las. Sob liquidez reduzida, configuração incorreta ou falha operacional pode ser amplificada em cascatas de liquidação, perdas de lacunas e, em última análise, eventos de ADL. A questão não é mais ''Um mercado pode ser listado?'' mas sim ''Ele pode permanecer estável após a listagem?''

No nível do protocolo, o Hyperliquid aborda essa redistribuição de risco convertendo permissões em permissões responsáveis. O staking, combinado com o slashing governado por validadores, estabelece consequências econômicas claras para a má operação do desenvolvedor. Restrições de precificação e alavancagem, incluindo limitações, intervalos de atualização, limites de volatilidade e requisitos de margem isolada, visam manter os riscos de cauda mais perigosos dentro de limites gerenciáveis. Nessa estrutura, a proposta de valor do HIP-3 torna-se clara: escalabilidade por meio de abertura, segurança por meio de restrições, e sustentabilidade de longo prazo por meio de verificabilidade e responsabilização.

O HIP-3 não torna as listagens mais livres. Torna-as mais padronizadas, implantáveis, operáveis e sujeitas a slashing. Se essa padronização pode operar em escala depende, em última análise, da qualidade real do design de oráculos, parâmetros de alavancagem e risco, e monitoramento em tempo de execução. Se você está projetando regras de acesso a mercado, modelos de parâmetros, sistemas de alerta ou fluxos de trabalho de emergência sobre o HIP-3, ou se precisa de suporte de auditoria e segurança contínua, sinta-se à vontade para entrar em contato com a BlockSec pelo e-mail [email protected].

Referências

[1] https://hyperliquid.gitbook.io/hyperliquid-docs/hyperliquid-improvement-proposals-hips/hip-3-builder-deployed-perpetuals

[2] https://hyperliquid.gitbook.io/hyperliquid-docs

Sobre a BlockSec

A BlockSec é uma provedora completa de segurança blockchain e conformidade cripto. Desenvolvemos produtos e serviços que ajudam os clientes a realizar auditorias de código (incluindo contratos inteligentes, blockchain e carteiras), interceptar ataques em tempo real, analisar incidentes, rastrear fundos ilícitos e cumprir obrigações de AML/CFT, ao longo de todo o ciclo de vida de protocolos e plataformas.

A BlockSec publicou múltiplos artigos de segurança blockchain em conferências de prestígio, reportou vários ataques de dia zero em aplicações DeFi, bloqueou múltiplos hacks para resgatar mais de 20 milhões de dólares, e protegeu bilhões em criptomoedas.

• Site oficial: https://blocksec.com/

• Conta oficial no Twitter: https://twitter.com/BlockSecTeam

• 🔗 Serviço de Auditoria BlockSec : Enviar uma solicitação

• 🔗 Phalcon Security APP: Agendar uma demonstração

• 🔗 Phalcon Compliance