Multiactivos perp pode virar uma categoria independente? Essa pergunta ninguém consegue responder agora.
Mas dá para inferir, a partir de três desafios de design, se o Hertzflow conseguirá superá-los após o lançamento na mainnet.
Primeiro desafio: o pool de LP deveria ser isolado?
A volatilidade das criptomoedas não está na mesma escala das taxas de câmbio. BTC cair 15% em um dia é comum; USDJPY cair 1,5% em um dia já é considerado um grande movimento.
Ao colocar tudo no mesmo pool de LP, quando as posições cripto são liquidadas em massa, o motor de liquidação consome a liquidez do LP; a posição em FX ainda mal se mexe. Assim, o pool de LP fica “amarrado” à volatilidade das criptos.
A proposta do @Hertzflow_xyz é isolar em camadas: cada ativo roda seu próprio pool, e os LPs escolhem que riscos querem assumir. A direção está certa.
Mas o isolamento gera um novo problema. FX e ouro têm volatilidade diária menor e volume de negociação historicamente mais baixo. Com pools independentes, a liquidez pode ficar mais fina: grandes ordens entram com alto slippage ou até são recusadas.
Por isso, é necessário definir, para diferentes classes de ativos, um limite mínimo de profundidade diferenciado; ou então oferecer aos LPs pools de baixa volatilidade com divisão de taxas mais alta para atrair liquidez; até permitir, em certa medida, empréstimo de liquidez entre pools.
Além disso, a camada agregadora de Vault pode sofrer com atraso de rebalanceamento em condições extremas. A base da estratégia depende dos pools isolados: quando o pool de cripto “explode”, a instrução de rebalanceamento consegue executar imediatamente? Ou vai ficar travada na cadeia? É preciso fazer testes de estresse para validar.
Segundo desafio: a liquidação entre ativos deveria se conectar (ser interligada)?
A documentação enfatiza o isolamento do mercado, mas mesmo na mesma conta ainda pode existir checagem de risco em nível de conta.
Quando o BTC é liquidado, isso aciona uma checagem obrigatória na posição de ouro ou provoca redução de alavancagem por efeito dominó? Se houver ligação, é preciso oferecer ao trader uma chave de “garantia independente” claramente definida para a margem. Se não houver ligação, é necessário garantir que o estouro de um pool não afete indiretamente outros pools via oráculos compartilhados ou via motor de liquidação.
Atualmente, a documentação pública não deixa explícita a implementação final do isolamento de risco em nível de conta e em nível de posição. Após o lançamento na mainnet, é necessário concluir com base no comportamento real dos contratos.
Usuários da testnet relataram que, ao fazer fechamento com alta alavancagem, o preço de liquidação mostrado na interface e o preço realmente executado divergem em 2 a 3 segundos. A causa é que o front-end faz polling e não consegue acompanhar os eventos na cadeia.
Na mainnet, é obrigatório otimizar para nível de milissegundos; caso contrário, a experiência de usuários de alta alavancagem desaba.
Cenários extremos de “dupla pancada” precisam ser planejados com antecedência. Em 5 de agosto de 2024, o Nikkei despencou 12%: no dia, o BTC caiu de 60 mil para 49 mil; o USDJPY caiu de 146 para 141.
Se naquele dia estivesse rodando um perp multiactivos, a capacidade de throughput da liquidação, a frequência de atualização do oráculo e a capacidade de recompor liquidez dos LPs em tempo real precisam aguentar. A recomendação é tratar primeiro os ativos de alta volatilidade e adicionar mecanismos de circuit breaker (melhorando a segurança com gatilhos de interrupção).
Terceiro desafio: o oráculo consegue atender tantas dessas tantas (muitas) em conjunto?
O Hertzflow usa verificação cruzada com múltiplos oráculos, principalmente a Pyth.
Mas a frequência de atualização de FX, ações e commodities, as regras de feriados/fechamento, e o tratamento de saltos anormais diferem totalmente das criptomoedas.
Durante a testnet, a falha do Pyth já foi acionada e levou a manutenção. O que precisa ser feito é: definir pesos específicos para cada classe de ativo, ajustar dinamicamente os intervalos de confiança e alternar automaticamente para fontes de backup.
Alavancagem, pra valer (sem exagero). A divulgação no site diz 1000x como máximo; o GitBook fala em 500x; e, na prática, o limite muda conforme os diferentes ativos e modos. O parâmetro final na mainnet segue o oficial.
Para ativos não criptos, reduzir o limite é obrigatório: FX em 100x a 200x é razoável; só cripto pode permitir um valor mais alto. Caso contrário, o atraso do oráculo sob alta alavancagem vira um “amplificador de desastre”.
Hard gates antes do lançamento na mainnet
Primeiro: até o início de agosto de 2026 ainda não há relatórios públicos de auditoria de terceiros. Cobrir 100% dos módulos essenciais — liquidação, rebalanceamento, limites de saque, papéis de permissões e funções — é o limite mínimo. Esse é um dos hard gates mais rígidos antes da mainnet.
Segundo: quando a utilização for alta ou o trader estiver com lucro flutuante grande, os saques têm um limite. É necessário mostrar de forma mais transparente o saldo disponível em tempo real, e simular um cenário de estresse como “lucro coletivo dos traders ao mesmo tempo + saque simultâneo”.
Terceiro: mesmo que os números da testnet estejam ótimos, a profundidade na fase inicial da mainnet pode não ser suficiente. Incentivos para LP nos primeiros tempos — incluindo divisão de taxas mais alta e mineração de profundidade com prazo — é o que determina se, após o lançamento, haverá liquidez de verdade ou se a história termina e o dinheiro vai embora.
Voltando ao problema inicial: multiactivos perp pode virar uma categoria independente?
A demanda é real. Quem faz trading macro precisa naturalmente acompanhar vários mercados ao mesmo tempo. Um único terminal que gerencia todas as posições com mais eficiência é algo concreto.
Mas a questão é se dá para controlar, ao mesmo tempo, a liquidação e os LPs para conviver com diferentes volatilidades. Essa é a linha de vida ou morte. Antes de rodar ao vivo na mainnet, se esses ajustes não estiverem prontos, o risco é muito maior do que a eficiência aparente.
Por outro lado, se funcionar, não define apenas o Hertzflow — define o padrão para toda a categoria.
https://testnet.hertzflow.xyz
@Hertzflow_xyz
Mas dá para inferir, a partir de três desafios de design, se o Hertzflow conseguirá superá-los após o lançamento na mainnet.
Primeiro desafio: o pool de LP deveria ser isolado?
A volatilidade das criptomoedas não está na mesma escala das taxas de câmbio. BTC cair 15% em um dia é comum; USDJPY cair 1,5% em um dia já é considerado um grande movimento.
Ao colocar tudo no mesmo pool de LP, quando as posições cripto são liquidadas em massa, o motor de liquidação consome a liquidez do LP; a posição em FX ainda mal se mexe. Assim, o pool de LP fica “amarrado” à volatilidade das criptos.
A proposta do @Hertzflow_xyz é isolar em camadas: cada ativo roda seu próprio pool, e os LPs escolhem que riscos querem assumir. A direção está certa.
Mas o isolamento gera um novo problema. FX e ouro têm volatilidade diária menor e volume de negociação historicamente mais baixo. Com pools independentes, a liquidez pode ficar mais fina: grandes ordens entram com alto slippage ou até são recusadas.
Por isso, é necessário definir, para diferentes classes de ativos, um limite mínimo de profundidade diferenciado; ou então oferecer aos LPs pools de baixa volatilidade com divisão de taxas mais alta para atrair liquidez; até permitir, em certa medida, empréstimo de liquidez entre pools.
Além disso, a camada agregadora de Vault pode sofrer com atraso de rebalanceamento em condições extremas. A base da estratégia depende dos pools isolados: quando o pool de cripto “explode”, a instrução de rebalanceamento consegue executar imediatamente? Ou vai ficar travada na cadeia? É preciso fazer testes de estresse para validar.
Segundo desafio: a liquidação entre ativos deveria se conectar (ser interligada)?
A documentação enfatiza o isolamento do mercado, mas mesmo na mesma conta ainda pode existir checagem de risco em nível de conta.
Quando o BTC é liquidado, isso aciona uma checagem obrigatória na posição de ouro ou provoca redução de alavancagem por efeito dominó? Se houver ligação, é preciso oferecer ao trader uma chave de “garantia independente” claramente definida para a margem. Se não houver ligação, é necessário garantir que o estouro de um pool não afete indiretamente outros pools via oráculos compartilhados ou via motor de liquidação.
Atualmente, a documentação pública não deixa explícita a implementação final do isolamento de risco em nível de conta e em nível de posição. Após o lançamento na mainnet, é necessário concluir com base no comportamento real dos contratos.
Usuários da testnet relataram que, ao fazer fechamento com alta alavancagem, o preço de liquidação mostrado na interface e o preço realmente executado divergem em 2 a 3 segundos. A causa é que o front-end faz polling e não consegue acompanhar os eventos na cadeia.
Na mainnet, é obrigatório otimizar para nível de milissegundos; caso contrário, a experiência de usuários de alta alavancagem desaba.
Cenários extremos de “dupla pancada” precisam ser planejados com antecedência. Em 5 de agosto de 2024, o Nikkei despencou 12%: no dia, o BTC caiu de 60 mil para 49 mil; o USDJPY caiu de 146 para 141.
Se naquele dia estivesse rodando um perp multiactivos, a capacidade de throughput da liquidação, a frequência de atualização do oráculo e a capacidade de recompor liquidez dos LPs em tempo real precisam aguentar. A recomendação é tratar primeiro os ativos de alta volatilidade e adicionar mecanismos de circuit breaker (melhorando a segurança com gatilhos de interrupção).
Terceiro desafio: o oráculo consegue atender tantas dessas tantas (muitas) em conjunto?
O Hertzflow usa verificação cruzada com múltiplos oráculos, principalmente a Pyth.
Mas a frequência de atualização de FX, ações e commodities, as regras de feriados/fechamento, e o tratamento de saltos anormais diferem totalmente das criptomoedas.
Durante a testnet, a falha do Pyth já foi acionada e levou a manutenção. O que precisa ser feito é: definir pesos específicos para cada classe de ativo, ajustar dinamicamente os intervalos de confiança e alternar automaticamente para fontes de backup.
Alavancagem, pra valer (sem exagero). A divulgação no site diz 1000x como máximo; o GitBook fala em 500x; e, na prática, o limite muda conforme os diferentes ativos e modos. O parâmetro final na mainnet segue o oficial.
Para ativos não criptos, reduzir o limite é obrigatório: FX em 100x a 200x é razoável; só cripto pode permitir um valor mais alto. Caso contrário, o atraso do oráculo sob alta alavancagem vira um “amplificador de desastre”.
Hard gates antes do lançamento na mainnet
Primeiro: até o início de agosto de 2026 ainda não há relatórios públicos de auditoria de terceiros. Cobrir 100% dos módulos essenciais — liquidação, rebalanceamento, limites de saque, papéis de permissões e funções — é o limite mínimo. Esse é um dos hard gates mais rígidos antes da mainnet.
Segundo: quando a utilização for alta ou o trader estiver com lucro flutuante grande, os saques têm um limite. É necessário mostrar de forma mais transparente o saldo disponível em tempo real, e simular um cenário de estresse como “lucro coletivo dos traders ao mesmo tempo + saque simultâneo”.
Terceiro: mesmo que os números da testnet estejam ótimos, a profundidade na fase inicial da mainnet pode não ser suficiente. Incentivos para LP nos primeiros tempos — incluindo divisão de taxas mais alta e mineração de profundidade com prazo — é o que determina se, após o lançamento, haverá liquidez de verdade ou se a história termina e o dinheiro vai embora.
Voltando ao problema inicial: multiactivos perp pode virar uma categoria independente?
A demanda é real. Quem faz trading macro precisa naturalmente acompanhar vários mercados ao mesmo tempo. Um único terminal que gerencia todas as posições com mais eficiência é algo concreto.
Mas a questão é se dá para controlar, ao mesmo tempo, a liquidação e os LPs para conviver com diferentes volatilidades. Essa é a linha de vida ou morte. Antes de rodar ao vivo na mainnet, se esses ajustes não estiverem prontos, o risco é muito maior do que a eficiência aparente.
Por outro lado, se funcionar, não define apenas o Hertzflow — define o padrão para toda a categoria.
https://testnet.hertzflow.xyz
@Hertzflow_xyz