#grvt Quando leio a documentação oficial do GRVT, o que mais me faz parar para observar com atenção é a arquitetura do seu Risk Engine. A maior parte dos motores de risco de contratos de derivativos é basicamente um conjunto de lógica de liquidação com um price oracle; o GRVT, porém, o divide em três camadas: Pre-trade Risk Check, Position Monitoring e Settlement Validation. Essas três camadas não operam em série; elas funcionam de forma independente, e qualquer camada que identifique um problema aciona a ação correspondente de controle de risco.
O Pre-trade Risk Check ocorre antes da correspondência das ordens. Quando você envia uma solicitação de abertura de posição, o Risk Engine primeiro valida se o seu Unified Balance é suficiente para cobrir a margem inicial, se o valor nocional excede o limite máximo do nível da conta e se, para esse par de negociação, a concentração de posições atual não está alta demais. Se qualquer item não atender aos critérios, a ordem é rejeitada diretamente, sem entrar na fila de matching. Testei na rede de testes uma abertura cujo valor nocional excedia o limite da conta, e o sistema bloqueou na fase de submissão, sem esperar pela liquidação.
O Position Monitoring roda em tempo real, acompanhando a taxa de margem de manutenção e os múltiplos de alavancagem de cada conta. O gatilho de liquidação do GRVT não é uma única linha de preço; ele combina um valor ponderado entre o preço de referência (marcado) e o preço do oracle, para evitar que instabilidades do oracle isolado causem liquidações equivocadas. Na documentação, diz-se que usam dupla fonte de oráculo com Pyth e Chainlink, tomando a mediana ponderada; quando o desvio ultrapassa um limite, é feito um check de divergência de preços, e a liquidação dos pares relacionados fica pausada até o preço voltar a convergir.
A Settlement Validation acontece na liquidação final da negociação: ela verifica se o estado na blockchain é consistente com os registros do engine de matching fora da cadeia. Se houver divergências, o sistema aciona o processo de Reconciliation, congelando as contas relacionadas até que a diferença seja resolvida. Esse mecanismo não é comum em contratos de derivativos; é mais típico de clearing em mercados financeiros tradicionais.
A vantagem das três camadas de validação é interceptar o risco em múltiplos pontos de entrada, em vez de esperar a linha de liquidação para tratar. O custo é que cada camada adiciona latência e sobrecarga de computação. Na documentação do GRVT, o objetivo do Pre-trade Check é concluir em 10 milissegundos; o Position Monitoring é cálculo em fluxo em tempo real; e a Settlement Validation é processamento assíncrono em lote.
Pessoalmente, acho que se esses SLAs forem mantidos após o lançamento na mainnet, essa arquitetura de controle de risco em três camadas é bem sólida para contratos de derivativos.@grvt_io
O Pre-trade Risk Check ocorre antes da correspondência das ordens. Quando você envia uma solicitação de abertura de posição, o Risk Engine primeiro valida se o seu Unified Balance é suficiente para cobrir a margem inicial, se o valor nocional excede o limite máximo do nível da conta e se, para esse par de negociação, a concentração de posições atual não está alta demais. Se qualquer item não atender aos critérios, a ordem é rejeitada diretamente, sem entrar na fila de matching. Testei na rede de testes uma abertura cujo valor nocional excedia o limite da conta, e o sistema bloqueou na fase de submissão, sem esperar pela liquidação.
O Position Monitoring roda em tempo real, acompanhando a taxa de margem de manutenção e os múltiplos de alavancagem de cada conta. O gatilho de liquidação do GRVT não é uma única linha de preço; ele combina um valor ponderado entre o preço de referência (marcado) e o preço do oracle, para evitar que instabilidades do oracle isolado causem liquidações equivocadas. Na documentação, diz-se que usam dupla fonte de oráculo com Pyth e Chainlink, tomando a mediana ponderada; quando o desvio ultrapassa um limite, é feito um check de divergência de preços, e a liquidação dos pares relacionados fica pausada até o preço voltar a convergir.
A Settlement Validation acontece na liquidação final da negociação: ela verifica se o estado na blockchain é consistente com os registros do engine de matching fora da cadeia. Se houver divergências, o sistema aciona o processo de Reconciliation, congelando as contas relacionadas até que a diferença seja resolvida. Esse mecanismo não é comum em contratos de derivativos; é mais típico de clearing em mercados financeiros tradicionais.
A vantagem das três camadas de validação é interceptar o risco em múltiplos pontos de entrada, em vez de esperar a linha de liquidação para tratar. O custo é que cada camada adiciona latência e sobrecarga de computação. Na documentação do GRVT, o objetivo do Pre-trade Check é concluir em 10 milissegundos; o Position Monitoring é cálculo em fluxo em tempo real; e a Settlement Validation é processamento assíncrono em lote.
Pessoalmente, acho que se esses SLAs forem mantidos após o lançamento na mainnet, essa arquitetura de controle de risco em três camadas é bem sólida para contratos de derivativos.@grvt_io