Ir para o conteúdo principal
logotipo do Avana

Risk Framework

Como a Avana propõe, revisa e executa mudanças de risco no Hub e nos LP Collateral Spokes.

Visão Geral

O Avana Risk Framework define como mudanças de parâmetros são propostas, verificadas e executadas no Hub e nos LP Collateral Spokes. Cobre os controles usados quando o protocolo ajusta supply e borrow caps, configurações LT/LTV, inputs de taxa de juros, status de mercado e outros parâmetros que dependem de preços, utilização, profundidade do pool, concentração, volatilidade, comportamento de peg, circuit breakers, saúde da posição e estado relacionado.

Colateral LP não é uma classe de ativos homogênea. LPs estáveis, LPs de ativos correlacionados, pools ponderados, liquidez concentrada e outros designs de AMM podem ter, cada um, caminho de avaliação, caminho de liquidação e modo de falha específicos do Spoke. O framework existe para que essas diferenças se reflitam no processo de atualização, em vez de ficarem escondidas atrás de uma única configuração genérica de risco.

Três papéis permanecem separados ao longo desse processo: Avana Risk Initiator, Avana Risk Guardian e Avana Risk Defender. A parte que recomenda uma mudança rotineira não é a mesma que a verifica de forma independente, e o papel que pode agir durante uma emergência é intencionalmente mais estreito do que o caminho rotineiro.

Regra operacional: reducing risk should be easier than expanding it.

Princípios Centrais

Separação de Papéis

O framework atribui proposta, revisão e contenção de emergência a atores diferentes para que uma parte não controle o caminho completo sozinha.

Execução Restrita

Mudanças rotineiras de risco só executam quando permanecem dentro dos limites de política predefinidos e passam nas checagens de validação.

Consistência Pública

A atualização descrita publicamente deve ser a mesma que é realmente enfileirada para execução.

Consciência do Spoke

Cada Spoke de colateral LP carrega suas próprias regras de listing, premissas de oráculo, caminho de liquidação e perfil de risco.

Assimetria Defensiva

O processo é intencionalmente enviesado para que reduzir risco seja mais rápido e simples do que expandi-lo.

Papéis

Avana Risk Initiator

O papel que prepara e recomenda mudanças rotineiras de risco para o Hub e os LP Collateral Spokes.

  • Publicar a justificativa e classificar a atualização como defensiva ou orientada a crescimento
  • Enviar atualizações rotineiras para o caminho de execução com timelock
  • Recomendar mudanças de supply caps, borrow caps, LT/LTV, reserve factor e taxa de juros dentro de faixas aprovadas
  • Iniciar de-risking no nível do Spoke e onboarding de pools dentro de templates de Spoke pré-aprovados

Avana Risk Guardian

O revisor independente com autoridade de veto sobre mudanças rotineiras enfileiradas.

  • Verificar se a atualização enfileirada corresponde à divulgação pública
  • Checar se a ação permanece dentro dos limites de política aprovados
  • Rejeitar atualizações baseadas em premissas inválidas de oráculo, liquidez ou liquidação
  • Cancelar uma atualização enfileirada durante a janela de timelock quando ela cria instabilidade óbvia no nível do Spoke ou do Hub

Avana Risk Defender

O papel exclusivo de emergência usado para conter incidentes quando o caminho normal com timelock é lento demais.

  • Reduzir borrow caps ou supply caps a níveis defensivos
  • Congelar novos empréstimos em um Spoke ou congelar o uso de colateral para um pool, template ou Spoke
  • Desabilitar um adapter específico ou caminho de empréstimo quando condições predefinidas de falha forem atendidas
  • Bloquear a originação de nova dívida sob condições de emergência, sem ser usado para otimização rotineira ou ações de crescimento

Fluxo de Atualização

Mudanças rotineiras seguem um caminho fixo para que o protocolo distinga manutenção normal de parâmetros de contenção de emergência. A sequência padrão é aviso público, envio, checagens de limites, timelock, revisão do Guardian e execução se a proposta não for vetada.

1

Aviso Público

O Risk Initiator publica a mudança pretendida, por que ela é necessária e o escopo que se espera afetar.

2

Submission

O Risk Initiator coloca a mudança proposta no caminho de execução usado pelo framework.

3

Validation

Checagens do framework confirmam que a atualização permanece dentro das restrições predefinidas e dos limites de política aprovados.

4

Timelock

Se a validação passar, a mudança entra em uma janela de timelock em vez de executar imediatamente.

5

Revisão do Guardian

Durante o timelock, o Risk Guardian revisa o payload exato enfileirado e pode cancelá-lo se necessário.

6

Execution

Se a mudança sobreviver à revisão, ela executa automaticamente após o timelock expirar.

7

Caminho de Emergência

Se condições de emergência forem atendidas, o Risk Defender pode usar um caminho defensivo separado com autoridade mais estreita.

Classes de Parâmetros

Mudanças de parâmetros não carregam todas o mesmo risco, então o framework as agrupa por quanta autoridade devem exigir e quão rápido devem poder se mover.

Mudanças Defensivas

Estas são as mudanças rotineiras mais rápidas porque reduzem a exposição do protocolo.

  • Reduzir borrow caps
  • Reduzir supply caps
  • Reduzir LTV ou limiar de liquidação
  • Congelar empréstimo ou uso de colateral
  • Apertar configurações do Spoke

Mudanças Rotineiras Delimitadas

Estas seguem a rota padrão Initiator -> Guardian -> timelock dentro dos limites aprovados.

  • Aumentos modestos de tetos
  • Ajustes modestos de parâmetros dentro de faixas aprovadas
  • Adicionar novos pools dentro de um template de Spoke existente

Mudanças no Nível da Governança

Estas estão fora do framework rotineiro e exigem um caminho de decisão de nível mais alto.

  • Criar uma nova família de Spoke
  • Habilitar um novo primitivo de LP
  • Adicionar um novo modelo de oráculo
  • Habilitar um novo liquidation adapter
  • Expandir materialmente a superfície de risco além das premissas pré-aprovadas

Divulgação Pública

Toda atualização rotineira deve ser publicada antes do envio em um formato que permita a developers, usuários e revisores comparar o aviso com a ação exata que depois é enfileirada.

Padrão mínimo de divulgação

  • Spoke afetado
  • Pools ou templates afetados
  • Parâmetros atuais
  • Parâmetros propostos
  • Motivo da atualização
  • Se a atualização é defensiva ou orientada a crescimento
  • Timing esperado de envio
  • Janela esperada de timelock
  • Dependências ou premissas relevantes

Divulgação consistente facilita revisar uma proposta quanto a scope creep, premissas desalinhadas ou simples erros de execução.

Ações de Emergência

Ações de emergência são para contenção, não para tuning rotineiro. Devem ser usadas raramente, mantidas o mais estreitas possível e estruturadas para que o protocolo possa voltar ao caminho padrão assim que o risco imediato for compreendido. O Risk Defender só deve agir quando uma condição de falha definida ou altamente provável torna a rota normal com timelock insegura.

Triggers de emergência

  • Inconsistência de oráculo
  • Degradação do caminho de liquidação
  • Comportamento anormal do pool
  • Falha de dependência de wrapper
  • Comprometimento no nível do adapter
  • Instabilidade súbita no nível do Spoke

Divulgação pós-ação obrigatória

  • The trigger
  • A ação tomada
  • A duração pretendida
  • O caminho de volta à operação normal

A autoridade de emergência existe apenas para casos de falha definidos ou altamente prováveis em que esperar o caminho normal com timelock é inseguro. Não é um caminho para crescimento ou otimização rotineiros.

Recomendação, revisão e contenção de emergência permanecem separadas porque colateral LP é um conjunto de mercados com estruturas e modos de falha diferentes, e não uma lista intercambiável de ativos.