AIP-12: Tratamento da inadimplência do recente depeg do stkBNB
Last updated
Last updated
Como muitos de vocês sabem, em 2 de dezembro, houve um exploit no Ankr BNB (aBNBc) que causou uma queda temporária no preço do stkBNB, devido ao dumping de aBNBc em pools compartilhados com stkBNB em outros protocolos, o que permitiu ao explorador drenar stkBNB e posteriormente vendê-lo em outros pools. O Alpaca Guard funcionou como planejado e conseguiu salvar uma notável % de posições da liquidação. No entanto, devido à extensão e duração do depeg, algumas posições LYF nos pares stkBNB-BNB ainda foram liquidadas e a plataforma incorreu em dívidas incobráveis.
Você pode ler mais detalhes do nosso tweet aqui: https://twitter.com/AlpacaFinance/status/1598685838686138368
A inadimplência total deste incidente é de 1.587,87 BNB, o que representa ~0,2% do TVL do lending no momento do evento.
Você pode ver o detalhamento das liquidações aqui: https://docs.google.com/spreadsheets/d/1KA3NXXrnWvo4MaDx-BOWdvEU8c_alBhclYCVEksbFSk/edit#gid=1119361929
Estamos colocando isso em discussão para ativar o Plano de Seguros, para que os holders de xALPACA possam votar se o evento se enquadra nas condições a serem cobertas pelo Plano de Seguros. Como lembrete, você pode ler mais sobre como nosso Plano de Seguro funciona aqui.
O que o Plano de Seguro Alpaca cobre
Ele cobrirá qualquer evento de déficit pelo qual o código ou a infraestrutura da Alpaca Finance seja responsável, incluindo: dívida inadimplente para lenders, risco de contrato inteligente, exploits, falha de design econômico, falha grave de integração do oráculo, etc.
Neste caso específico para stkBNB, onde o depeg aconteceu devido a eventos em uma sequência de protocolos externos (ankr exploit → stkbnb wombat pool), e nosso mecanismo de liquidação e Oracle Guard ainda funcionaram como pretendido, pode-se argumentar que o código ou infraestrutura da Alpaca Finance não foi responsável.
Em última análise, cabe aos holders de xALPACA decidir se este evento se enquadra nas condições de cobertura, tendo em mente que a ativação justa do Plano de Seguro Alpaca é o que dá aos credores e usuários de nossa plataforma confiança para usá-lo, o que acaba gerando toda a receita do protocolo entrando na Governança.
Observe que discutimos com Ankr, pStake e Binance se eles podem fazer alguma coisa para cobrir as perdas do stkBNB, e nenhum deles deu uma resposta positiva. Portanto, neste ponto, o Plano de Seguro é a única via para cobrir a inadimplência.
Para resumir o ponto principal, se o Plano de Seguro cobrir isso, 50% da receita do protocolo que vai para a Governança será usada para cobrir essa dívida incobrável até que seja paga aos empréstimos do BNB. A ALPACA bloqueada na governança não será tocada e os 50% restantes da receita do protocolo ainda serão pagos à Governança durante esse período.
Quanto a eventuais prejuízos às posições LYF que foram liquidadas, infelizmente, uma vez que o protocolo funcionou conforme concebido durante a liquidação, não se enquadra nas condições de cobertura do Plano de Seguros. Portanto, essa discussão e a votação subsequente seriam apenas para cobrir a dívida incobrável acima mencionada para empréstimos.
Esta proposta será um simples voto de SIM ou NÃO.
O voto SIM ativaria o plano de seguro e começaria a direcionar 50% da receita do protocolo indo para a Governança para cobrir a dívida incobrável até que o valor total seja pago, enquanto o voto NÃO não ativaria o plano de seguro.
A comunidade votou para ativar o plano de seguro.
O reembolso será feito por meio de um contrato inteligente que pode ser rastreado aqui.
Para ver o valor restante a ser pago, Vá em "Contratct" -> "Read as Proxy" e visualize o valor restante
A dívida total a ser paga é de 1.587,87 BNB * 242 USD / BNB= 384.264 USD