Arquitetura
A Hypercall usa um modelo de execução híbrido: matching off-chain para velocidade, com liquidação e gerenciamento de contas on-chain para segurança.
Limites de Confiança
Off-Chain (Backend da Hypercall)
Responsabilidades:
- Matching e execução de ordens
- Gerenciamento do livro de ofertas
- Verificações de margem pré-negociação
- Orquestração de liquidações
- Dados de mercado e precificação
- Streams via WebSocket
Premissa de confiança: Os usuários confiam que o backend da Hypercall irá:
- Fazer o matching das ordens de forma justa (prioridade preço-tempo)
- Aplicar as verificações de margem corretamente
- Monitorar contas e acionar liquidações quando necessário
- Fornecer dados de mercado precisos
Limitações: As operações off-chain não são totalmente verificáveis criptograficamente no Mainnet Alpha. Os usuários precisam confiar no operador do backend para matching, ingestão de dados de mercado, verificações de margem e emissão de comandos RSM.
Caminho adiante: A Hypercall está trabalhando em direção à descentralização do RSM e a garantias mais fortes de trustlessness. O roadmap especificará como os compromissos de estado, os papéis dos signatários, os caminhos de disputa e os controles do operador se tornarão mais verificáveis ao longo do tempo. O Mainnet Alpha é a primeira fase, com restrições, e não o modelo de confiança final.
On-Chain (Smart Contracts)
Responsabilidades:
- Propriedade da conta e controle do manager
- Depósitos e saques
- Leilões de liquidação (transferência de posições)
- Comandos RSM (operações de gerenciamento de risco)
- Publicação de preços de settlement
- Integração com a Hyperliquid (ordens de perpétuos via ActionCaster)
Premissa de confiança: As operações on-chain são verificáveis criptograficamente. Os usuários podem verificar o código e o estado dos contratos.
Segurança: A propriedade da conta não pode ser alterada sem uma transação on-chain. A liquidação requer leilão on-chain.
Fluxo de Execução de Ordens
1. Envio de Ordem
Ação do usuário: Enviar ordem via POST /order com assinatura EIP-712.
Validação do backend:
- Verificação de assinatura (EIP-712)
- Verificações de margem pré-negociação (baseadas em cenários)
- Admissão da ordem (tier, vencimento, limites de taxa)
Resultado: A ordem é aceita (ACKED) e enfileirada para matching, ou rejeitada com o motivo.
2. Matching de Ordens
Processo: As ordens são combinadas no livro de ofertas usando prioridade preço-tempo.
Execução: Quando as ordens são combinadas, execuções (fills) são criadas e as posições são atualizadas no banco de dados do backend.
Não é on-chain: Os matches individuais de ordens não são registrados on-chain. O estado da conta é sincronizado via atualizações do margin root.
3. Atualizações de Posições
Processo: As posições são rastreadas no banco de dados do backend e atualizadas em tempo real.
Acesso do usuário: Consulte posições via GET /portfolio ou pelo canal portfolio do WebSocket.
Sincronização on-chain: O margin root (compromisso criptográfico com o estado da conta) é atualizado on-chain periodicamente e em eventos críticos.
4. Settlement
Liquidação no vencimento: As opções vencem no horário de vencimento do contrato e são liquidadas em dinheiro com base no preço de settlement. Na mainnet, o SPCX vence às 16:00 ET; a testnet atualmente vence às 08:00 UTC.
Preço de settlement: TWAP de 30 minutos do preço de índice do Oracle da Hyperliquid, publicado on-chain via SimpleOracle.setExpiryPrice().
Processo:
- O oracle calcula o TWAP de 30 minutos encerrado no vencimento
- O preço de settlement é publicado on-chain
- O valor intrínseco é calculado para cada posição
- Os saldos em dinheiro são atualizados
- As posições são encerradas
Gerenciamento de Contas
Criação de Conta
Processo: As contas são criadas no primeiro depósito ou quando solicitadas explicitamente.
On-chain: O contrato da conta é implantado como um BeaconProxy (padrão de proxy mínimo eficiente em gas).
Manager: Cada conta tem um manager (EOA) que controla a conta e pode autorizar agentes.
Depósitos e Saques
Depósitos:
- USDC: Transferido para a Exchange via HyperCore
- ERC20s de opções: Depositados via contrato da Exchange
Saques:
- Devem passar por verificações de risco off-chain (margem suficiente após o saque)
- Executados on-chain via contrato Account
- Assinatura do manager necessária
Limite de confiança: Depósitos e saques são on-chain e verificáveis.
Liquidação
A liquidação usa uma máquina de estados com um período de carência antes do leilão:
| Estado | Descrição | Duração |
|---|---|---|
| Healthy | Patrimônio > MM exigida | - |
| PreLiquidation | Patrimônio < MM, período de carência ativo | 60 segundos |
| InLiquidation | Leilão holandês em andamento | Até ser preenchido |
| Liquidated | Posições transferidas | - |
Liquidação Parcial vs Total
| Tipo | Condição | Comportamento |
|---|---|---|
| Parcial | ≤ 5 posições | Liquida posições específicas até a conta ficar saudável |
| Total | > 5 posições | Liquida a conta inteira |
Mecânica do Leilão
Leilão solvente (Patrimônio > 0): Preço inicial = patrimônio × (1 - penalidade), decrescente ao longo do tempo. Liquidadores fazem lances para assumir as posições.
Leilão insolvente (Patrimônio < 0): O fundo de seguro fornece um bônus para incentivar liquidadores a absorver posições subaquáticas.
On-chain: A execução do leilão e a transferência de posições acontecem on-chain via contrato Exchange.
Veja Liquidação para detalhes completos.
Integração com a Hyperliquid
Perpétuos HIP-3
As contas da Hypercall podem executar ordens de perpétuos na Hyperliquid via ActionCaster:
Fluxo: Contrato Account → ActionCaster → Hyperliquid L1
Casos de uso:
- Hedge de delta de posições em opções
- Margem cross-venue (posições em perpétuos contam para a margem de portfólio)
Cross-Margin
As posições em perpétuos do HyperCore foram projetadas para serem incluídas nos cálculos de margem de portfólio, permitindo estratégias de hedge eficientes em capital. A Margem de Portfólio está desabilitada para usuários em geral no Mainnet Alpha.
Comandos RSM
RSM (Risk & Settlement Manager): Componente do backend que emite comandos on-chain para gerenciamento de risco.
Os comandos incluem:
- Ordens reduce-only (fechamento forçado de posições)
- Pagamento de dívida (saque forçado para cobrir saldo negativo)
- Execução de settlement
On-chain: Os comandos RSM são assinados pelo signatário do RSM e executados via contrato Account. Os usuários podem verificar o endereço do signatário do RSM e todas as execuções de comandos on-chain.
Roadmap de descentralização: O signatário atual do RSM é controlado pelo operador. Trabalhos futuros do roadmap publicarão como esse papel será descentralizado ou tornado mais minimizado em termos de confiança.
O Que Você Pode Verificar
On-Chain (Verificável)
- Propriedade da conta (endereço do manager)
- Implantação do contrato da conta
- Depósitos e saques
- Leilões de liquidação e resultados
- Preços de settlement (o oracle publica on-chain)
- Ordens na Hyperliquid (execução on-chain)
- Comandos RSM (execução on-chain)
Off-Chain (Confiança Necessária)
- Justiça do matching de ordens
- Cálculos de margem
- Precisão do rastreamento de posições
- Precisão dos dados de mercado
- Momento do acionamento das liquidações
Modelo de Segurança
Princípio-chave: Operações críticas (propriedade da conta, depósitos, liquidação, preços de settlement) são on-chain e verificáveis. A eficiência operacional (matching, verificações de margem) é off-chain.
Trade-offs: O matching off-chain oferece velocidade e eficiência, mas hoje requer confiança no operador do backend. As operações on-chain oferecem verificabilidade, mas são mais lentas e mais caras. O roadmap de descentralização do RSM é o caminho deste modelo Mainnet Alpha em direção a garantias mais fortes de trustlessness.
Veja também:
- Settlement & Vencimento - Processo e ciclo de vida do settlement
- Liquidação - Máquina de estados e mecânica da liquidação
- Contratos - Documentação dos smart contracts