Proposta inicial para desenvolvimento Haven 3.0

​

É importante notar que esta proposta é uma rascunho de recomendação.
Nenhuma decisão sobre nossa tokenomics ainda foi tomada e nada está definido.

Tudo o que é apresentado neste documento são ideias a serem discutidas ainda mais com a comunidade e, assim que houver um acordo, faremos outro anúncio.

Desde que as conversões foram pausado, membros do Economics Working Group (EWG) têm estado ocupados trabalhando em soluções para retornar a rede Haven a um estado totalmente funcional sem abrir a comunidade Haven a um risco maior de hiperinflação, como vem acontecendo com os detentores do ecossistema Terra.

Este trabalho teria sido mais difícil e teria levado mais tempo sem a participação da comunidade.
As ideias apresentadas por muitos de nossos membros e reunidas por xVoluntáriov dentro esse documento, deram à equipe do EWG uma base para trabalhar, o que acabou nos levando à proposta que está sendo apresentada aqui.

Achamos que encontramos uma solução viável e gostaríamos de abrir discussões em nosso #havenomics canal para obter feedback da comunidade.
Essas discussões serão importantes para refinar o modelo e, eventualmente, chegar a uma solução funcional.

Para alguns, as medidas aqui propostas podem parecer duras e injustas, mas temos que lembrar que o protocolo está atualmente em mau estado; devemos garantir que não piore e dar tempo ao protocolo para se recuperar.

Vale lembrar a todos que o Vault nunca foi planejado para ser usado como uma ferramenta de negociação; incentivamos todos a negociar XHV e xUSD em exchanges, o que aumentará a adoção e aumentará a liquidez.

O caminho de desenvolvimento da Terra deu uma dica, tentando usar pools de Bitcoin para uma stablecoin algorítmica apoiada por híbridos antes que eles se tornassem grandes demais para seu mecanismo de estabilidade lidar com choques exógenos extremos.

Mas Haven é diferente; o aspecto de privacidade evita o uso de blockchains públicos, colaterais e stablecoins para fins de apoio.

O principal problema com os modelos algorítmicos de stablecoins até agora é que o design da tokenômica significa que o preço da stablecoin é suportado em detrimento do preço do ativo nativo.
No caso do Haven, isso significa comprar xUSD barato para cunhar em XHV e depois vender o XHV no mercado. Isso cria uma supressão constante no preço do ativo nativo e, se o preço do ativo nativo diminuir indefinidamente, pode resultar em uma espiral de morte e uma perda completa de confiança na stablecoin.

Um pouco contraintuitivo, um design de token que não prioriza o preço da stablecoin e, em vez disso, protege o preço do ativo nativo tem maior longevidade como ecossistema e, portanto, maior confiança no valor da stablecoin.

Assim, a equipe do EWG teve uma nova ideia; O Haven está dobrando em “ser seu próprio banco” e exigirá garantias na forma de XHV para usar a função de escoramento.

A nova ideia pode ser resumida em uma frase:

Para Onshore/Offshore, você precisa ter o valor equivalente de XHV desbloqueado em seu cofre.

Chamamos essa ideia de Vault Backed Shoring, ou VBS. Destina-se a fornecer limites de liquidez para utilização da função de escoramento, determinados por cada usuário.

Com esse novo requisito de garantia, que bloqueará tanto a garantia quanto as moedas cunhadas por um período prolongado, os usuários de escoramento estarão constantemente expostos e vinculados à volatilidade da garantia base enquanto alteram ativamente os números de fornecimento do protocolo.

Eles não poderão usar a função de escoramento se venderem suas garantias XHV e não detiverem XHV em seus cofres, impedindo-os de “optar por fora” completamente do sistema volátil enquanto a comunidade paga a posição oposta com o aumento da inflação.

Resumindo, o Vault Backed Shoring destina-se a funcionar como um freio de velocidade e um requisito de skin no jogo para usuários da função de escoramento.

NOTA: O VBS só será necessário para os participantes que usam as funções de escoramento (XHV <-> xUSD), não as transferências padrão XHV ou xAsset.

Exemplo de onshoring:

Para converter 100 xUSD em XHV, você precisa ter pelo menos $100 no valor de XHV no cofre, desbloqueado.
Este valor $100 de XHV (conhecido como garantia) será bloqueado durante a conversão junto com os fundos que estão sendo convertidos.

Se o preço atual do XHV for $0.50, isso significa que você precisa ter pelo menos 200 XHV (desbloqueado) em seu cofre para onshore 100 xUSD.
Após a conversão bem-sucedida usando este exemplo, você terá 400 XHV bloqueado por um período de tempo (veja os tempos de bloqueio propostos mais abaixo).

Exemplo de offshoring:

Para converter 100 XHV em xUSD, você precisa ter pelo menos a mesma quantidade de XHV (100 neste caso) no cofre, desbloqueado.
Isso significa que você só pode offshore no máximo 50% do XHV mantido no cofre, desde que nenhum dos XHV esteja bloqueado.

Tempos de bloqueio propostos para VBS

Tanto os fundos quanto o requisito de garantia serão bloqueados para 21 dias.

Se o usuário não tiver garantias suficientes para onshore em uma única conversão, o VBS retarda o processo de onshoring exigindo que um onshorer passe por vários ciclos de onshoring, e cada onshore leva 21 dias para ser concluído.

Para ilustrar isso, aqui estão alguns cenários mostrando quantos ciclos e quanto tempo levaria para onshore a quantidade total de xUSD mantida em um cofre.

O primeiro exemplo está usando uma quantidade inicial de 10k XHV e o segundo exemplo está usando uma quantidade inicial de 100k XHV.
Ambos os exemplos usam uma garantia de 1:1, o que significa que o máximo que você pode em terra a qualquer momento é a quantidade máxima de XHV desbloqueado que você tem no cofre.
Na Parte 2 da proposta, veremos que a garantia mudará com base no estado do protocolo.

É fácil ver que quanto mais garantias desbloqueadas você tiver no cofre, menos ciclos você precisará para converter totalmente todo o seu xUSD de volta para XHV.

Os próximos cenários estão usando um preço XHV crescente e decrescente, respectivamente.

A partir disso, podemos ver que, com um preço crescente em XHV, menos ciclos Onshore são necessários, mas você acaba com menos XHV geral do que teria se tivesse conseguido onshore todo o xUSD em uma conversão.

Por outro lado, à medida que o preço do XHV diminui, são necessários mais ciclos Onshore para converter todo o xUSD, mas você acaba com mais XHV.
Embora isso pareça estar inflando o protocolo, esses cenários não levam em consideração o estado do protocolo, o que impedirá o tipo de inflação visto acima.
Isso nos leva à próxima parte da proposta.

A primeira parte da proposta descrevia a nova ideia em torno do VBS e como ela seria implementada.

Por si só, no entanto, o VBS não necessariamente interromperá a inflação, especialmente porque o preço do XHV diminui com o tempo, apenas aumentará o tempo necessário para inflar o protocolo.

Portanto, outras medidas são necessárias para combater a inflação descontrolada e a manipulação de baleias.

Índice de Capitalização de Mercado

Como muitos membros da comunidade já devem ter notado através de discussões em nosso canal havenomics, uma das melhores maneiras de medir a saúde do protocolo é usando uma proporção da capitalização de mercado combinada do Total Offshore Assets (TOAMcap) e a capitalização de mercado XHV (XHVMcap ).

Isso é simplesmente calculado como:

Quanto menor o número, mais saudável o protocolo e vice-versa.
Embora seja um ponto de dados subjetivo, uma razão muito boa é considerada quando XHVmcap é 10 vezes maior que TOAMcap, ou seja, 0.1 usando a fórmula acima.

No momento da redação deste artigo (23 de junho de 2022), a oferta circulante de XHV é de ~ 28,3 milhões com uma capitalização de mercado de $16 milhões (usando o preço KuCoin de $0,567).
A capitalização de mercado do Ativo Total é de ~$16 milhões.
Portanto, a proporção mcap que temos agora é quase exatamente 1, que é considerado uma proporção ruim e, portanto, um estado não saudável do protocolo.

Combinando a proporção mcap com VBS

Um estado não saudável do protocolo pode ser alcançado das seguintes maneiras:

• queda contínua no preço do XHV
• conversões muito grandes e únicas
• muito offshoring
• excesso de onshoring, o que pode levar à pressão de venda no mercado aberto
• qualquer combinação dos pontos acima

Se combinarmos o estado do protocolo (mcap ratio) com o nosso modelo VBS, podemos limitar ainda mais o mecanismo de shoring para garantir que o sistema não vá muito para um estado não saudável.

A forma como nos propomos fazer isso para Onshores e Offshores são diferentes.

EM TERRA

Para Onshores, aumentaremos as garantias necessárias à medida que a taxa de mcap aumentar, o que significa que você precisa ter mais XHV em seu cofre para a mesma quantidade de xUSD quando o protocolo tende a um estado ruim.

Vamos supor que a proporção esteja em 0,5, o protocolo está caminhando para um estado não saudável. Isso significa que você não poderá mais usar uma garantia 1:1 para onshore seu xUSD.
Um cálculo dinâmico para essa proporção poderia ter chegado a uma garantia de 1:3, o que significa que você precisaria ter 3 vezes mais XHV em seu cofre do que a quantidade de XHV que você está tentando onshore.

Para melhor visualizar isso, vamos usar o mesmo cenário de antes: iniciar o valor de XHV de 10k com um preço constante, mas desta vez com uma garantia de 1:3.

Com uma garantia de 1:1 do exemplo anterior, precisaríamos de 7 onshores para converter totalmente todo o xUSD para XHV.
Com uma garantia de 1:3, como acima, o número de onshores aumentou para 17, exigindo um ano inteiro para converter todo o xUSD para XHV.

Vamos também comparar o mesmo cenário, mas com uma quantidade inicial de XHV de 100k.

Anteriormente, com uma garantia de 1:1, seriam necessários 4 onshore (84 dias) para converter todo o xUSD.
Com uma garantia de 1:3, aumentou para 9 onshores, ou 189 dias.

Claro, esses cenários são bastante irreais no mundo real; é impossível prever flutuações de mercado e de preços, fundamentos, sentimento, táticas de conversão, etc.

A conclusão que podemos tirar disso é que, à medida que o estado do protocolo piora cada vez mais, o mesmo acontece com a quantidade de garantias necessárias para converter xUSD em XHV, o que, por sua vez, aumenta o número de ciclos e o tempo necessário para onshore o valor total.

OFFSHORES

Para Offshores, o conceito atual é manter o colateral em 1:1, mas aumentaremos as taxas à medida que o índice mcap aumentar. Além disso, também adicionaremos taxas de derrapagem para conversões maiores que levariam o estado do protocolo de bom ou ruim a pior.

NOTA: A razão pela qual não estamos considerando taxas para Onshores, além das taxas de conversão padrão, é porque acredita-se que isso desvincule xUSD, o que poderia criar uma espiral descendente do preço no mercado aberto.

Offshore - Taxas de conversão

Acreditamos que é do interesse do protocolo queimar a maioria das taxas para manter a inflação sob controle, mas também deixar taxas suficientes para o custo operacional do projeto, mais os salários.
Para os fins desta proposta, estamos assumindo um mínimo de 0,5% em taxas para o tesouro, com qualquer excedente sendo queimado.
Os números exatos serão acordados posteriormente.

Para calcular as taxas de conversão, usaremos uma simples operação de exponenciação entre a razão mcap e um número que seja 2 ou muito próximo a ele, +/- algumas casas decimais.
Se o número for muito alto, o cálculo se tornará exponencial muito rapidamente, o que tornaria isso inutilizável.

Para ilustrar isso, considere o exemplo a seguir, onde estamos simulando vários níveis de razões de mcap com 4 níveis diferentes de expoentes: [1.6], [1.8], [2] e [2.2]
Também estamos definindo um mínimo (0,5%) e um máximo (80%) em taxas, com 0,5% indo para o tesouro e o restante sendo queimado.

À medida que a proporção aumenta e o estado do protocolo piora, as taxas para quaisquer offshores serão aumentadas de acordo.
A ideia por trás das altas taxas não é punir os usuários, mas desencorajá-los de mover o protocolo para um estado ruim e proteger contra a inflação descontrolada queimando uma grande parte da taxa.
 

Offshore - Taxas de derrapagem

As taxas de derrapagem são uma medida adicional para capturar grandes conversões que piorariam o estado do protocolo com uma única conversão.

Adicionaríamos taxas de derrapagem às taxas de conversão padrão, conforme calculado acima. Basicamente, as taxas de derrapagem são as taxas após um aumento potencial na proporção que é adicionada às taxas de conversão padrão.

Aqui está um exemplo em que a proporção está em um bom estado antes de um offshore, mas após uma única conversão por uma baleia, ela o leva a um estado ruim.

outras considerações

O índice Market Cap é suficiente para calcular o estado do protocolo?
A resposta é não.

Há algo mais a ser considerado que ainda não mencionamos; a espalhar relação entre TOAMcap e XHVMcap.

O estado do protocolo em que estamos agora, ou seja, não saudável, significa que não teremos muitas conversões passando pelo sistema porque é muito caro ou exigiria muitas garantias.
No entanto, isso pode mudar assim que o preço do XHV subir para um nível em que o índice de capitalização de mercado se torne favorável para onshore.

À medida que as pessoas começam a onshore e o preço do XHV aumenta, o spread entre TOAMcap e XHVMcap aumenta mais rapidamente, o que incentiva mais onshore, inflando a oferta.
Isso pode continuar até que todo o xUSD tenha sido convertido em XHV e o suprimento circulante de XHV tenha sido bastante inflado.

Para combater isso, poderíamos calcular a proporção de spread entre os dois limites em relação ao preço do XHV e, se o spread se tornar muito grande, poderíamos aplicar restrições semelhantes às conversões, mesmo quando a proporção de capitalização de mercado estiver em bom estado.

O gráfico de simulação abaixo mostra como isso pode ser calculado.
Quando o índice de capitalização de mercado é baixo (estado saudável – linha azul), mas o índice de spread é alto (linha verde), poderíamos aumentar a garantia para Onshore e aumentar as taxas para Offshore.

Para recapitular, propomos as seguintes medidas

OFFSHORING

1. VBS com garantia 1:1, mais tempo de bloqueio (21 dias propostos).
2. Razão Mcap para determinar as taxas com base no estado do protocolo.
3. As taxas de derrapagem dependem do tamanho do offshore e do estado do protocolo após um potencial offshore.
4. Taxas de proporção de spread.
5. Aplica-se a conversões XHV -> xUSD.

LOCALIZAÇÃO

1. VBS com tempo de bloqueio (21 dias propostos).
2. Garantia mínima de 1:1 e máxima de 1:3 ou 1:4 (a ser discutida).
3. Garantia a ser determinada pelo estado do protocolo.
4. Garantia a ser determinada pelo índice de spread.
5. Taxas básicas de conversão.
6. Aplica-se a conversões xUSD -> XHV.

A principal lição desta proposta é que as discussões e o feedback da comunidade devem centrar-se na nova ideia, VBS.
Nós realmente gostaríamos de saber o que você pensa e se você vê algum problema gritante neste modelo.
 

Há um trabalho de desenvolvimento significativo com o que estamos propondo e enquanto a equipe de desenvolvimento avalia isso, queremos ter tempo para ouvir o feedback da comunidade sobre esta proposta, em particular a nova abordagem do VBS.

Os membros podem discutir isso de forma mais eficaz no #havenomics canal.