Builder必读：HIP-3市场如何识别与化解风险

HIP-3（Proposta de Melhoria Hyperliquid 3） desde que entrou na mainnet há três meses, o volume total de negociações de mercados personalizados construídos por terceiros já ultrapassou 130 bilhões de dólares. O que está por trás desse número? É a descentralização do poder: o poder de “listar” que antes era monopolizado por exchanges centralizadas foi transformado em um padrão aberto de interfaces. Builders só precisam fazer um staking de 50 mil HYPE tokens para implantar mercados perpétuos na base unificada de negociação e liquidação do Hyperliquid.

Porém, à medida que o poder é descentralizado, os riscos também se deslocam. Como identificar esses riscos e como detectar sinais de problema em tempo hábil na operação, tornando-se uma habilidade essencial para cada Builder.

Fundamentos da Arquitetura: Compreendendo as Fontes de Risco do HIP-3

Para identificar os riscos do HIP-3, primeiro é preciso entender seu design arquitetônico.

O HIP-3 é construído sobre a arquitetura de duas camadas do Hyperliquid. HyperCore é uma blockchain L1 customizada, otimizada para negociações de contratos, capaz de processar 200 mil ordens por segundo com finalidade determinística; HyperEVM é a camada de aplicação, capaz de rodar contratos inteligentes. A genialidade dessa arquitetura está no fato de que: matching, liquidação e compensação são fornecidos de forma unificada pelo protocolo, eliminando a necessidade de Builders construírem um sistema de negociação do zero.

Porém, justamente por isso, a delimitação de responsabilidades do Builder torna-se clara, porém frágil — clara no sentido de responsabilidades bem definidas (definir e operar o mercado), frágil porque a responsabilidade é totalmente terceirizada (o controle de risco está nas mãos do Builder).

O Builder precisa fazer um staking de 500k HYPE e assumir duas responsabilidades principais:

• Definição do mercado: determinar a fonte de preço do oráculo, especificações do contrato (alavancagem, unidade mínima de ordem, etc.), seleção dos ativos colaterais
• Operação do mercado: fornecer preços continuamente, ajustar a tabela de margens (limite de alavancagem), interromper o mercado quando necessário

Após o lançamento, o staking fica bloqueado por 30 dias até que seja possível solicitar o desbloqueio. Isso significa que qualquer má operação pode ser punida por votação de penalização pelos validadores — mas, antes disso, o Builder precisa identificar a existência de um problema.

Mecanismo de Precificação em Três Camadas: Como Avaliar a Saúde do Preço do Oracle

O aspecto mais crítico e também mais suscetível a riscos no HIP-3 é o mecanismo de feed de preços. O Builder precisa entender as três entradas de preço na interface setOracle:

oraclePx (obrigatório): calculado pelo servidor relayer do Builder, serve como âncora para a taxa de financiamento. markPx (opcional): até 2 conjuntos de preços externos enviados pelo Builder, usados como candidatos ao preço de marca. externalPerpPx (obrigatório): mediana ponderada de perp de CEX, usada para evitar que o mark price se desvie abruptamente.

O preço final de marca não é simplesmente o oraclePx, mas sim a mediana entre o preço do livro local (mediana entre melhor bid/ask/último trade) e o markPx. O que isso significa?

Significa que há múltiplos pontos de falha na formação do preço:

• Se o relayer ficar offline ou sofrer ataque DDoS, oraclePx será interrompido
• Se o algoritmo de cálculo do markPx tiver falhas, pode permitir arbitragem indevida
• Se o livro local for muito fino, a mediana pode distorcer o preço

As restrições do setOracle parecem rigorosas:

• Frequência de atualização: intervalo entre duas chamadas ≥ 2,5 segundos; se não atualizar em 10 segundos, volta ao preço local
• Limites de variação: o markPx pode variar até ±1% por atualização, e todos os preços são limitados a 10x o valor de abertura do dia

Porém, esses limites oferecem pouca proteção para ativos que não negociam 24/7 (como ações).

Riscos de Ativos Não 7×24H: Armadilhas de Precificação em Períodos de Fechamento

Para ativos como BTC, que negociam 24/7, o Builder pode confiar em fontes contínuas de preço de CEX/DEX. Mas e para ações e outros ativos que fecham em determinados horários, como fazer a avaliação durante o período de fechamento?

Atualmente, a abordagem é: usar o último preço de fechamento + uma mecânica de precificação baseada na pressão do livro interno. Especificamente, o preço de marca é limitado a oscilar dentro de ±1/max_leverage do última fechamento (por exemplo, com alavancagem 10x, ±10%).

Qual o problema? Quando o mercado externo tem baixa liquidez, o livro interno é muito fino. Com ordens de grande volume entrando, pode ocorrer uma falsa volatilidade durante o fechamento, especialmente se posições longas estiverem concentradas.

Em 14/12/2025, o mercado XYZ100-USDC do trade.xyz (que espelha o NASDAQ100) foi manipulado: um atacante criou 398 posições short (cerca de 10M USDC), manipulando o preço para baixo, levando a liquidações em massa de posições longas em curto período, com aproximadamente 13M USDC de posições longas sendo forçadas a fechar.

A raiz do problema está em:

• Ausência de um preço de referência externo durante o fechamento
• Livro interno insuficiente para suportar movimentos além do limite de volatilidade
• Uma vez iniciada a liquidação, o feedback de preço pode amplificar a queda

Risco de Oráculo: Como Detectar Ameaças de Centralização e Desalinhamento

O servidor relayer do Builder é uma fonte centralizada natural. Vazamento de chave privada, ataque DDoS, erro de algoritmo — qualquer um desses pode interromper ou manipular o feed de preços.

Quatro sinais-chave para identificar riscos de oráculo:

1. Atraso ou interrupção do feed

   • Monitoramento: timestamp da última chamada setOracle na cadeia
   • Alerta: se passar >10 segundos sem atualização, o sistema recorre ao preço local, aumentando risco de desalinhamento
   • Ações: trocar relayer de backup, emitir alerta de saúde

2. Desalinhamento de preço

   • Indicadores:
     • Desvio entre oraclePx e o mid do perp na CEX
     • Diferença entre markPx e oraclePx
     • Divergência entre livro local e mercado externo
   • Detecção: se ≥2 desses indicadores ultrapassarem limites simultaneamente, considera-se desalinhamento
   • Ações: reduzir gradualmente a alavancagem máxima, ativar mecanismos de clamp mais rígidos

3. Gap de abertura em ativos não 7×24H

   • Monitoramento: diferença entre preço interno e preço de abertura no período de fechamento
   • Fontes de referência: Blue Ocean ATS (negociação pós-mercado) ou cotações CFD de fim de semana
   • Alerta: se risco de gap >5%, emitir aviso antecipado

4. Liquidez falsa

   • Monitoramento: profundidade do livro e relação de absorção (impact_ratio = volume de compra ativa / volume de ordens pendentes)
   • Detecção: rápida subida e desaparecimento súbito da profundidade
   • Ações: reduzir limite de OI, limitar novas posições

Armadilhas de Parâmetros: Onde os Builders mais se Equivocam

Muitos Builders pensam que definir parâmetros fixos resolve tudo, mas na verdade a capacidade de ajustar dinamicamente esses parâmetros é o maior teste de operação.

Riscos principais na configuração de parâmetros:

1. Alavancagem excessiva Para mercados com baixa liquidez, definir uma max leverage alta aumenta a probabilidade de ativar o ADL (auto de-leverage). Quando posições crescem rapidamente e a maioria das posições está perto do limite de lucro/prejuízo, qualquer movimento de preço pode desencadear uma cascata de liquidações.

2. Ajuste repentino da tabela de margens Alterar as margens de manutenção de um dia para o outro equivale a mudar a margem de todos os usuários instantaneamente. Muitos podem passar de “seguro” para “liquidador” de repente, causando uma onda de liquidações em massa. Essas mudanças devem ser comunicadas com antecedência e feitas de forma gradual.

3. Uso indevido do haltTrading O Builder pode usar haltTrading para interromper o mercado, cancelar ordens e liquidar ao preço de mark. Mas essa ferramenta é de duplo uso: se mal utilizada, pode beneficiar atacantes, pois ao cancelar ordens e liquidar ao mark, podem garantir lucros não justificados.

4. Modo cross-margin (risco futuro) Atualmente, o HIP-3 suporta apenas posições isoladas. Se no futuro for suportado o modo cross-margin, o risco de baixa liquidez de um mercado pode se propagar para outros mercados mais líquidos. Até que haja uma solução oficial, Builders não devem tentar essa abordagem.

Sistema de Monitoramento de Risco em Múltiplos Níveis: Uma Estrutura Completa de Alertas

Como os riscos estão por toda parte, o Builder precisa de um sistema de monitoramento em múltiplas dimensões e camadas, em tempo real.

Monitoramento do lado de preços

Nível 1 (Alerta de feed anômalo):

• Indicador: intervalo entre chamadas setOracle > 5 segundos
• Ação: verificar saúde do relayer, trocar relayer de backup se necessário
• Saída: alerta com informações de todos os relayers

Nível 2 (Desalinhamento de preço):

• Indicador: desvio entre oracle e CEX perp > 2% por mais de 5 segundos
• Ação: reduzir OI via setOpenInterestCaps
• Ação adicional: diminuir gradualmente o max leverage na tabela de margens

Nível 3 (Desalinhamento prolongado):

• Indicador: desalinhamento por mais de 30 segundos
• Ação: ativar mecanismo de clamp para limitar movimentos
• Decisão final: o Builder decide se interrompe o mercado via haltTrading

Monitoramento do lado do livro

Sinal de profundidade falsa:

• Indicador: profundidade real dentro de ±2% do preço, com spread aumentado
• Alerta: impacto na relação de absorção (impact_ratio) aumenta rapidamente
• Ação: reduzir limite de OI, impedir novas posições

Detecção de ordens falsas:

• Sinal: profundidade desaparecendo repentinamente após rápida ascensão
• Ações: reduzir OI ao nível atual (sem aumento), ou parar o mercado se o desalinhamento for grave

Monitoramento de posições

O objetivo aqui não é “prever preço”, mas identificar se o mercado mudou de negociação baseada em fluxo para uma disputa de posições.

Sinal de excesso de OI:

• Cálculo: OI nominal / volume de 24h
• Detecção: aumento rápido indica risco de volatilidade extrema
• Ações: emitir alerta, reduzir alavancagem

Sinal de lucros e perdas majoritários:

• Indicadores: preço médio de abertura dos maiores detentores, tamanho das posições, relação de P/L
• Alerta: posições majoritárias com lucros ou perdas próximos do limite (ex: +20% de lucro)
• Significado: qualquer choque externo será amplificado por liquidações em cascata
• Ações: reduzir alavancagem antecipadamente

Validação de Risco: Tornando o Feed de Preços Auditável e Recalculável

Monitorar não basta; o Builder deve tornar o feed de preços “auditável” e “recalculável”.

Construção de um sistema de prova de preço:

1. Divulgação do algoritmo e fontes de dados

   • Mostrar toda lógica de setOracle, incluindo parâmetros
   • Listar todas as fontes de dados e seus pesos
   • Divulgar frequência de atualização e limites de volatilidade

2. Geração de provas verificáveis off-chain

   • Para cada setOracle, gerar uma prova contendo:
     • Inputs: respostas e timestamps das fontes
     • Cálculos intermediários
     • Resultado final (oracle price)
   • Assinar e gerar hash dessa prova (proofHash)

3. Publicação periódica do MerkleRoot

   • Agrupar todos os proofHash em uma Merkle Tree
   • Publicar o MerkleRoot na cadeia periodicamente (por hora/dia)
   • Permitir que qualquer usuário verifique a validade de uma determinada leitura

4. Ferramentas de verificação open-source

   • Permitir que usuários insiram timestamp ou tx hash
   • Verificar assinatura, timestamps, MerkleRoot
   • Recalcular o preço do oracle e compará-lo ao on-chain

Essa abordagem garante que, mesmo que o relayer seja comprometido, os usuários possam verificar a integridade do feed de preços e fornecer evidências de possíveis manipulações.

Isolamento de Riscos: Estratégias Customizadas por Ativo

Diferentes ativos têm perfis de risco distintos, e os limites de monitoramento também devem variar.

Ativos 7×24H (BTC, ETH):

• Vantagens: fontes externas contínuas
• Monitoramento principal: estabilidade do relayer, desvios entre oracle e CEX
• Limites: mais relaxados (desalinhamento >3%)

Ativos não 7×24H (ações):

• Desvantagens: ausência de preço externo durante o fechamento
• Monitoramento principal: risco de gap na abertura, volatilidade falsa no período de fechamento
• Limites: mais restritivos (desalinhamento >1%)
• Fontes de referência: cotações pós-mercado, CFD de fim de semana
• Tratamento especial: reduzir max leverage antes de períodos de maior risco (ex: última hora de pregão, primeiras 30 minutos de abertura)

Liquidação e ADL: Compreendendo o Círculo Vicioso em Situações Extrema

A liquidação em si não é o risco, mas o que ela pode desencadear: uma cascata de liquidações que amplificam a queda de preço.

O HIP-3 mantém a lógica de liquidação do HyperCore: quando o valor de uma posição não cobre a margem de manutenção, ela é liquidada. O sistema tenta fechar a posição ao preço de mark, usando ordens do livro. Mas, se o livro for insuficiente, o preço de liquidação pode se desviar significativamente do mark, criando um “gap de liquidação”.

Quando esse gap ocorre, o mecanismo de ADL (auto de-leverage) é acionado:

• Seleciona posições vencedoras para reduzir
• Executa liquidações ao preço de mark
• Usa os lucros dessas posições para cobrir o gap

Porém, o acionamento do ADL indica que o mercado está em estado extremo. Uma vez ativado, os lucros dos vencedores são reduzidos, o que pode abalar a confiança e gerar mais riscos.

Como o Builder pode prever a ativação do ADL?

• Monitorar concentração de posições, volume de OI, profundidade do livro
• Sinal: aumento rápido na relação OI / profundidade
• Ações: reduzir alavancagem, limitar novas posições antes que o cenário se agrave

Responsabilização e Certificação: Uma Abordagem de Verificação e Sanções

O grande diferencial do HIP-3 é: descentralizar o poder, mas formalizar a responsabilidade.

Quem viola as regras pode ser penalizado por votação de validadores:

• Penalidades podem chegar a 100% do stake em casos graves, como falhas prolongadas ou ataques
• Penalidades menores (até 20%) para problemas menores ou desempenho ruim

O stake penalizado é destruído, não recompensando o prejuízo, criando um forte incentivo à operação responsável.

Para que esse sistema funcione, é preciso:

1. Monitoramento completo: detectar rapidamente qualquer anomalia
2. Provas verificáveis: rastrear a origem do problema
3. Processo transparente: votação clara e eficiente

Conclusão: De “Implantar” para “Operar Estavelmente”

O HIP-3 substitui a necessidade de aprovação centralizada por interfaces abertas, e o volume de mercados construídos por terceiros demonstra a viabilidade dessa abordagem. Mas o custo da abertura é que a responsabilidade de risco recai mais sobre o input e a operação do Builder.

Para que um mercado funcione de forma segura, o Builder deve dominar:

• Como entender as fontes de risco
• Como montar sistemas de monitoramento em tempo real
• Como criar provas verificáveis de preços
• Como agir preventivamente diante de sinais de risco

O sucesso a longo prazo depende de sua capacidade de implementar soluções confiáveis de oráculos, ajustar parâmetros de forma dinâmica e manter uma vigilância contínua do mercado.

HIP-3 não é apenas para facilitar a listagem, mas para estabelecer um padrão de operação, monitoramento e responsabilização. E esse padrão só será sustentável se o Builder tiver uma compreensão profunda dos riscos e uma execução rigorosa.

Se você estiver desenvolvendo normas de entrada de mercado, modelos de parâmetros, sistemas de alerta ou auditorias de risco, equipes especializadas como a BlockSec podem oferecer consultoria técnica aprofundada e serviços de auditoria.