Proposta de Tokenomics Haven 3.0 (leve)

Para ver a proposta completa, clique aqui.
Você também pode baixar uma versão em PDF da proposta completa em aqui.

visão global

Nos últimos meses, o Economics Working Group (EWG) trabalhou em estreita coordenação com os desenvolvedores do Haven para produzir uma proposta para uma implementação específica para o Vault Backed Shoring (VBS) proposta que foi aprovado por votação da comunidade em 7 de julho de 2022. 

No topo desta página há um link para a proposta completa em PDF de 32 páginas do EWG para a comunidade. Ele explica as circunstâncias que nos levaram até aqui, a teoria por trás do VBS, nossas fórmulas propostas e simulações dele em ação. É um documento levemente técnico e incentivamos todos a lê-lo da melhor maneira possível. No entanto, esta postagem de blog será uma versão resumida destinada a leitores mais não técnicos. 

O protocolo Haven está atualmente em um estado insalubre porque a proteção fornecida pelas configurações anteriores dos mecanismos de offshoring/onshoring do Haven era insuficiente. Nossa tokenomics anterior se concentrou em tentar manter o preço de mercado do xUSD para $1, mas o fez às custas do preço do XHV. Isso foi exposto por várias partes, o que causou uma inflação significativa e acabou levando a uma espiral de morte iminente do preço do XHV. Essa crise foi evitada pela decisão do EWG de interromper as conversões em junho de 2022 porque as ações dos usuários em geral e, em particular, das grandes baleias estavam a caminho de destruir o protocolo.

Nas semanas seguintes e após muitas horas de debate, o EWG chegou à conclusão de que era muito fácil beneficiar da liquidez ilimitada que as funções de escoramento ofereciam e ao mesmo tempo proteger-se do efeito negativo sobre o preço do XHV. Em nossas discussões, percebemos que todas as outras stablecoins algorítmicas se concentraram em manter o preço da stablecoin em vez do preço do ativo que suporta a stablecoin e, portanto, cometeram um erro fundamental. Digite VBS.

A VBS exige que um possível off/onshorer de XHV detenha uma quantia de garantia de XHV para realizar o off/onshore. Se um usuário quiser offshore x quantidade de XHV, ele deve reter separadamente y quantidade de XHV que será bloqueado durante a conversão. Vice-versa, se um usuário quiser onshore b quantia de xUSD, ele deve reter separadamente c quantia de XHV que será bloqueada pela duração da conversão. Números específicos serão abordados mais adiante.

O objetivo é fazer com que todos que desejam utilizar as funções off/onshore sejam expostos ao preço do XHV e, portanto, à saúde do ecossistema do Protocolo Haven. Por exemplo, se um usuário deseja colocar em terra seu xUSD offshore em uma data posterior, ele deve manter um saldo de XHV ou comprar XHV no mercado antes de concluir uma viagem de ida e volta. 

Juntamente com o VBS, propomos três outras mudanças que visam ajudar a proteger o protocolo e a sustentabilidade do projeto: 

• Tempos de bloqueio 
• Taxas de conversão
• Um limite para o valor que pode ser convertido em cada bloco 

Os tempos de bloqueio e as taxas de conversão são os mais simples, por isso os abordaremos brevemente antes de passar para o requisito de garantia VBS e o limite de conversão por bloco. 

Tempo de bloqueio

Os tempos de bloqueio fornecem um atraso na rapidez com que os fundos podem ser off/onshore e, em seguida, estar disponíveis para venda no mercado ou off/onshore. A garantia VBS necessária para uma conversão também será bloqueada pelo mesmo período de tempo em que os fundos convertidos são bloqueados.

Os tempos de bloqueio que estamos propondo são de 21 dias para ambos, offshore e onshore.

Taxas de conversão

Originalmente, propusemos um modelo em que as taxas dinâmicas seriam usadas como medida para proteger o sistema. No entanto, isso era insustentável por uma série de razões. Em vez disso, sugerimos 1,5% para Offshore e 1,5% para Onshore. As taxas podem parecer altas, mas com o tesouro sendo esgotado e fundos limitados por meio de uma porcentagem muito reduzida em volume para conversões uma vez que o VBS é implementado, temos que garantir que o projeto receba fundos suficientes para sustentar seus custos operacionais.

O atual xUSD < > xAssets taxas de conversão são 0,5% por conversão, dos quais 0,4% são queimados e 0,1% são divididos igualmente entre mineradores e a carteira de governança.

Para garantir que o protocolo receba receita suficiente por meio de conversões, gostaríamos de fazer as seguintes alterações:

• xUSD < > xTaxas de conversão de ativos serão aumentadas para 1,5%
• 1.2% seria enviado para a carteira de governança
• 0,3% iria para os mineradores (aumento de 0,05%)

As taxas serão revisadas regularmente.

VBS

A questão principal é exatamente qual a quantidade de garantias que deve ser exigida para desempenhar uma função de escoramento? Existem três fatores principais a serem considerados:

• O valor que um usuário deseja off/onshore
• A saúde atual do ecossistema XHV antes do off/onshore
• A inflação potencial/saúde futura do ecossistema XHV após o off/onshore

Por meio da análise de dados históricos e modelagem de possíveis cenários futuros, percebemos rapidamente que os índices de exigência de garantias na proposta inicial não forneceriam proteção adequada. O objetivo final é ter um sistema que seja fácil de usar, requer poucas garantias quando o sistema está saudável, mas protege contra inflação severa quando o protocolo está em perigo. 

Considerando nosso atual estado insalubre, isso é desafiador e, como estamos abrindo novos caminhos, nossa proposta atual é conservadora para proteger o protocolo. Podemos refinar as fórmulas para serem mais fáceis de usar no futuro, uma vez que tenhamos alcançado alguma estabilidade. 

Existem três componentes principais usados em nossos cálculos de garantia VBS:

• Market Cap Ratio - A relação entre o valor de XHV e xAssets em circulação
• Spread Ratio – Uma medida da “distância” entre o valor de mercado XHV e o valor de mercado xAssets
• Slippage – O impacto que uma transação terá no estado do ecossistema

As fórmulas específicas estão em discussão entre a comunidade e podem ser encontradas no documento da proposta. Abaixo, vamos resumi-los da maneira mais não técnica possível e fornecer exemplos.

O requisito total de garantia VBS é:

Valor de mercado ou Spread Ratio VBS + Slippage VBS

O cálculo da primeira parte depende inicialmente se é um off/onshore:

• Offshore - Índice de Capitalização de Mercado 
• Onshores – O maior do Market Cap Ratio e do Spread Ratio 

O Market Cap Ratio usará duas funções separadas que cobrem intervalos separados do market cap ratio. Estamos propondo que abaixo de 0,9 mcap ratio, use uma fórmula menos agressiva para facilitar o uso do sistema e acima de 0,9 use uma fórmula mais exponencial que faz com que a exigência de garantias aumente acentuadamente. 

O Spread Ratio é necessário como proteção extra para onshoring apenas porque, à medida que as pessoas estão em terra, a oferta de XAT aumenta, diminuindo o mcap ratio, reduzindo a exigência de garantias e criando maior possibilidade de inflação.

Para onshore, usamos o pior de dois valores de VBS entre mcap e spread ratio, o que significa que obtemos proteção em toda a faixa de market cap ratio.

A tabela abaixo mostra os valores VBS para uma faixa de taxas de mcap e spread, e seus valores VBS calculados correspondentes. A última coluna mostra o valor real de VBS usado para Onshores, que é o VBS mais alto dos dois, Mcap e Spread VBS.

Deslizamento

Para evitar que o índice de capitalização de mercado aumente muito rapidamente (piore) por meio de conversões únicas e grandes, temos que adicionar a derrapagem na forma de VBS ao VBS inicial, que é derivado do estado inicial do protocolo. Isso limitará as baleias a converter grandes quantidades com liquidez infinita.

A derrapagem é calculada de forma diferente para offshore e onshore.

Para Offshore, tomamos o aumento percentual do Índice de Capitalização de Mercado com base em quanto está sendo convertido.
Para Em terra, tomamos o aumento percentual do Proporção de Espalhamento.

As fórmulas específicas estão detalhadas no documento da proposta. Devido às onshores já exigirem requisitos adicionais de VBS em comparação com offshores, o deslizamento offshore VBS será mais significativo. Para mostrar como esses números podem ser, incluímos uma tabela abaixo com nossa sugestão. Assim como no Market Cap Ratio, usamos um múltiplo diferente quando o sistema está em um estado íntegro (3x quando mcap ratio < 0,1) comparado a um estado não saudável (10x quando mcap ratio > 0,1). 

Limite de escora de conversão por bloco

A proteção fornecida pelas medidas VBS acima deixa um vetor de ataque onde um usuário sofisticado pode dividir uma grande conversão em muitas conversões menores que são processadas dentro do mesmo bloco. Isso evitaria Slippage e quaisquer alterações no Market Cap ou Spread Ratios e os apresentaria com um VBS mais favorável do que o sistema foi projetado para fazer. 

Nossa solução proposta para isso é um limite por bloco na quantidade de XHV que pode ser off/onshore. Este limite será dinâmico e dependerá do valor de mercado do XHV. A fórmula específica descrita no documento da proposta foi escolhida para limitar o impacto nos usuários regulares. Abaixo está uma tabela de qual seria o limite em vários valores de mercado de XHV.

Simulação

Para ajudar a contextualizar, criamos três simulações no documento da proposta. Incluímos um abaixo e aceitamos sugestões de cenários que podemos modelar. Você encontrará detalhes de como propor a simulação no documento da proposta. 

E se o VBS já estivesse em vigor quando o XHV atingiu um mínimo de $0,42 em junho de 2022, e nossa baleia xUSD começou a onshoring tanto quanto o sistema permitia?

A maior suposição aqui é uma garantia inicial de 500k XHV.

Como você pode ver, nos últimos 126 dias, a baleia só poderia ter encalhado 76k XHV, devido ao mau estado em que estamos, e um VBS alto correspondente.

Isso supondo que a baleia não teria comprado ou vendido nenhum XHV durante esse período e que o preço permanecesse dentro dessa faixa.

Em suma

Para recapitular, estamos propondo as seguintes medidas para a tokenomics Haven 3.0:

Medidas genéricas de escoramento

• 21 dias de bloqueio para todas as conversões XHV < > xUSD
• VBS mínimo = 1
• Sem VBS máximo
• Limite de escoramento por bloco
• Taxas de 1,5% para todas as conversões XHV < > xUSD
• Taxas de 1,5% para conversões xUSD <> xAssets, com 1,2% indo para a carteira do governo e 0,3% para mineradores
• Os tempos de desbloqueio de conversão xAssets permanecem em 48 horas
• VBS aplicável apenas a conversões XHV < > xUSD

Medidas específicas offshore

• VBS variável com base na relação de capitalização de mercado de XHV e xAssets
• Slippage Variável VBS com base no aumento do Market Cap Ratio
• Funcionalidade máxima offshore

Medidas específicas em terra

• VBS variável com base no pior (maior) VBS entre o Market Cap Ratio VBS e o Spread Ratio VBS
• Slippage Variável VBS com base no aumento do Spread Ratio
• Funcionalidade máxima em terra

Esta é de longe a proposta mais complexa que publicamos até hoje, e também a mais complexa tokenomics que estamos tentando implementar.

Os membros do Grupo de Trabalho de Economia estarão disponíveis para responder a quaisquer perguntas que você possa ter, mas por favor, reserve um tempo para ler e reler a proposta para obter um bom entendimento. Muitas perguntas já terão sido respondidas nesta proposta.

Obrigado a todos por sua incrível paciência e apoio durante esses tempos difíceis.