Propuesta inicial para el desarrollo de Haven 3.0

​

Es importante señalar que esta propuesta es una proyecto de recomendación.
Aún no se ha tomado ninguna decisión sobre nuestra tokenómica y nada está escrito en piedra.

Todo lo presentado en este documento son ideas para ser discutidas más adelante con la comunidad, y una vez que se haya llegado a un acuerdo, haremos otro anuncio.

Desde que las conversiones fueron en pausa, los miembros del Grupo de trabajo económico (EWG) han estado ocupados trabajando en soluciones para devolver la red Haven a un estado completamente funcional sin abrir la comunidad Haven a un mayor riesgo de hiperinflación como ha estado sucediendo con los titulares del ecosistema Terra.

Este trabajo hubiera sido más difícil y hubiera tomado más tiempo sin la participación de la comunidad.
Las ideas presentadas por muchos de nuestros miembros y recopiladas por xVoluntariov en este documento, han brindado al equipo del EWG una base sobre la cual trabajar, lo que finalmente nos llevó a la propuesta que se presenta aquí.

Creemos que hemos llegado a una solución viable y nos gustaría abrir debates en nuestro #havenómica canal para recibir comentarios de la comunidad.
Estas discusiones serán importantes para refinar el modelo y eventualmente encontrar una solución funcional.

Para algunos, las medidas aquí propuestas pueden parecer duras e injustas, pero debemos recordar que el protocolo se encuentra actualmente en mal estado; debemos asegurarnos de que no empeore y darle tiempo al protocolo para que se recupere.

Vale la pena recordarles a todos que la Bóveda nunca tuvo la intención de usarse como una herramienta comercial; Alentamos a todos a operar con XHV y xUSD en los intercambios, lo que impulsará la adopción y aumentará la liquidez.

El camino de desarrollo de Terra dio una pista, tratando de usar los grupos de Bitcoin para una moneda estable algorítmica con respaldo híbrido antes de que se vuelvan demasiado grandes para que su mecanismo de estabilidad maneje choques exógenos extremos.

Pero Haven es diferente; el aspecto de privacidad impide el uso de cadenas de bloques públicas, garantías y monedas estables con fines de respaldo.

El problema clave con los modelos algorítmicos de monedas estables hasta ahora es que el diseño de la tokenómica significa que el precio de la moneda estable se mantiene en detrimento del precio del activo nativo.
En el caso de Haven, esto significa comprar xUSD barato para acuñar en XHV y luego vender el XHV en el mercado. Esto crea una supresión constante del precio de los activos nativos y, si el precio de los activos nativos disminuye indefinidamente, puede provocar una espiral mortal y una pérdida total de confianza en la moneda estable.

De manera un poco contraria a la intuición, un diseño de tokenómica que no prioriza el precio de la moneda estable y, en cambio, protege el precio del activo nativo tiene una mayor longevidad como ecosistema y, por lo tanto, una mayor confianza en el valor de la moneda estable.

Entonces, al equipo de EWG se le ocurrió una idea novedosa; Haven se está duplicando en "ser su propio banco" y requerirá garantías en forma de XHV para usar la función de apuntalamiento.

La nueva idea se puede resumir en una frase:

Para Onshore/Offshore, debe tener el valor equivalente de XHV desbloqueado en su bóveda.

Llamamos a esta idea apuntalamiento respaldado por bóveda, o VBS. Su objetivo es proporcionar límites de liquidez para el uso de la función de apuntalamiento, determinados por cada usuario.

Con este nuevo requisito de garantía, que bloqueará tanto la garantía como las monedas acuñadas durante un período prolongado, los usuarios de apuntalamiento estarán constantemente expuestos y vinculados a la volatilidad de la garantía base mientras cambian activamente los números de suministro del protocolo.

No podrán utilizar la función de apuntalamiento si venden su garantía XHV y no mantienen XHV en sus bóvedas, lo que les impide "optar por salirse" por completo del sistema volátil mientras la comunidad paga la posición opuesta con una mayor inflación.

En resumen, el apuntalamiento respaldado por bóveda está destinado a funcionar como un freno de velocidad y un requisito para la apariencia en el juego para los usuarios de la función de apuntalamiento.

NOTA: VBS solo será necesario para los participantes que utilicen las funciones de apuntalamiento (XHV <-> xUSD), no para las transferencias estándar de XHV o xAsset.

Ejemplo de onshoring:

Para convertir 100 xUSD en XHV, debe tener al menos $100 de XHV en la bóveda, desbloqueada.
Este valor de $100 de XHV (conocido como garantía) se bloqueará durante la conversión junto con los fondos que se están convirtiendo.

Si el precio actual de XHV es $0.50, esto significa que debe tener al menos 200 XHV (desbloqueados) en su bóveda para obtener 100 xUSD en tierra.
Después de una conversión exitosa usando este ejemplo, tendrá 400 XHV bloqueados por un período de tiempo (vea los tiempos de bloqueo propuestos más abajo).

Ejemplo de deslocalización:

Para convertir 100 XHV en xUSD, debe tener al menos la misma cantidad de XHV (100 en este caso) en la bóveda, desbloqueada.
Esto significa que solo puede deslocalizar un máximo de 50% del XHV que se encuentra en la bóveda, siempre que ninguno de los XHV esté bloqueado.

Tiempos de bloqueo propuestos para VBS

Tanto los fondos como el requisito de garantía estarán bloqueados para 21 días.

Si el usuario no tiene suficiente garantía para el onshore en una sola conversión, VBS ralentiza el proceso de onshore al requerir que un onshore pase por varios ciclos de onshore, y cada onshore tarda 21 días en completarse.

Para ilustrar esto, aquí hay un par de escenarios que muestran cuántos ciclos y cuánto tiempo llevaría cargar en tierra la cantidad total de xUSD almacenada en una bóveda.

El primer ejemplo usa una cantidad inicial de 10k XHV y el segundo ejemplo usa una cantidad inicial de 100k XHV.
Ambos ejemplos utilizan una garantía 1:1, lo que significa que lo máximo que puede en tierra en un momento dado es la cantidad máxima de XHV desbloqueado que tiene en la bóveda.
En la Parte 2 de la propuesta, veremos que la garantía cambiará según el estado del protocolo.

Es fácil ver que cuantas más garantías desbloqueadas tenga en la bóveda, menos ciclos necesitará para convertir completamente todos sus xUSD nuevamente a XHV.

Los siguientes dos escenarios utilizan un precio de XHV creciente y decreciente, respectivamente.

A partir de esto, podemos ver que con un precio en aumento en XHV, se requieren menos ciclos en tierra, pero termina con menos XHV en general de lo que tendría si hubiera podido en tierra todos los xUSD en una conversión.

Por el contrario, a medida que el precio de XHV disminuye, se necesitan más ciclos en tierra para convertir todo el xUSD, pero termina con más XHV.
Aunque parece que esto está inflando el protocolo, estos escenarios no tienen en cuenta el estado del protocolo, lo que evitará el tipo de inflación que se ve arriba.
Esto nos lleva a la siguiente parte de la propuesta.

La primera parte de la propuesta describía la idea novedosa en torno a VBS y cómo se implementaría.

Sin embargo, VBS por sí solo no necesariamente detendrá la inflación, especialmente porque el precio de XHV disminuye con el tiempo, solo prolongará el tiempo requerido para inflar el protocolo.

Por lo tanto, se requieren otras medidas para contrarrestar la inflación descontrolada y la manipulación de ballenas.

Relación de capitalización de mercado

Como muchos miembros de la comunidad ya habrán notado a través de discusiones en nuestro canal de havenomics, una de las mejores maneras de medir la salud del protocolo es usando una proporción de la capitalización de mercado de activos costa afuera totales combinada (TOAMcap) y la capitalización de mercado de XHV (XHVMcap ).

Esto se calcula simplemente como:

Cuanto menor sea el número, más saludable será el protocolo y viceversa.
Aunque se trata de un dato subjetivo, se considera que una relación muy buena es cuando XHVmcap es 10 veces mayor que TOAMcap, es decir 0.1 utilizando la fórmula anterior.

En el momento de escribir este artículo (23 de junio de 2022), la oferta en circulación de XHV es de ~28,3 millones con una capitalización de mercado de $16 millones (utilizando el precio de KuCoin de $0,567).
La capitalización de mercado de activos totales se sitúa en ~$16 millones.
Entonces, la relación mcap que tenemos ahora es casi exactamente 1, lo que se considera un mal ratio y por tanto un mal estado del protocolo.

Combinando la relación mcap con VBS

Se puede llegar a un estado no saludable del protocolo de las siguientes maneras:

• caída continua en el precio de XHV
• conversiones únicas muy grandes
• demasiada deslocalización
• demasiado onshoring, lo que puede conducir a una presión de venta en el mercado abierto
• cualquier combinación de los puntos anteriores

Si combinamos el estado del protocolo (relación mcap) con nuestro modelo VBS, podemos limitar aún más el mecanismo de apuntalamiento para garantizar que el sistema no oscile demasiado hacia un estado no saludable.

La forma en que proponemos hacer esto para Onshores y Offshores es diferente.

EN TIERRA

Para Onshores, aumentaremos la garantía necesaria a medida que aumenta la relación mcap, lo que significa que necesita tener más XHV en su bóveda por la misma cantidad de xUSD cuando el protocolo tiende a fallar.

Supongamos que la proporción es de 0,5, el protocolo se dirige hacia un estado no saludable. Esto significa que ya no podrá utilizar una garantía 1:1 para incorporar su xUSD.
Un cálculo dinámico para esta proporción podría haber llegado a una garantía de 1:3, lo que significa que necesitaría tener 3 veces más XHV en su bóveda que la cantidad de XHV que está tratando de transportar en tierra.

Para visualizar mejor esto, usemos el mismo escenario anterior: comenzando con una cantidad de XHV de 10k con un precio constante, pero esta vez con una garantía de 1:3.

Con una garantía 1:1 del ejemplo anterior, habríamos necesitado 7 onshores para convertir completamente todos los xUSD a XHV.
Con una garantía de 1:3, como se indicó anteriormente, el número de onshore ha aumentado a 17, lo que requiere un año completo para convertir todos los xUSD a XHV.

Comparemos también el mismo escenario, pero con una cantidad inicial de XHV de 100k.

Anteriormente, con una garantía de 1:1, se habrían necesitado 4 costas (84 días) para convertir todo el xUSD.
Con una garantía de 1:3, ha aumentado a 9 en tierra, o 189 días.

Por supuesto, estos escenarios son bastante poco realistas en el mundo real; es imposible predecir las fluctuaciones del mercado y de los precios, los fundamentos, el sentimiento, las tácticas de conversión, etc.

La conclusión que podemos sacar de esto es que a medida que el estado del protocolo empeora, también lo hace la cantidad de garantía necesaria para convertir xUSD a XHV, lo que a su vez aumenta la cantidad de ciclos y el tiempo necesario para incorporar la cantidad total.

COSTA AFUERA

Para Offshore, el concepto actual es mantener la garantía en 1:1, pero aumentaremos las tarifas a medida que aumente la relación mcap. Además, también agregaremos tarifas de deslizamiento para conversiones más grandes que harían que el estado del protocolo fuera bueno o malo a peor.

NOTA: La razón por la que no estamos considerando tarifas para Onshores, aparte de las tarifas de conversión estándar, es porque se cree que esto desvincularía xUSD, lo que podría crear una espiral descendente del precio en el mercado abierto.

Costa afuera - Tarifas de conversión

Creemos que lo mejor para el protocolo es quemar la mayoría de las tarifas para mantener la inflación bajo control, pero también dejar suficientes tarifas para el costo operativo del proyecto, más los salarios.
A los efectos de esta propuesta, estamos asumiendo un mínimo de 0,5% en comisiones para la tesorería, y cualquier excedente se quemará.
Las cifras exactas se acordarán en una etapa posterior.

Para calcular las tarifas de conversión, utilizaremos una simple operación de exponenciación entre la relación mcap y un número que es 2 o muy cercano a él, +/- algunos decimales.
Si el número es demasiado alto, el cálculo se volverá exponencial demasiado rápido, lo que lo haría inutilizable.

Para ilustrar esto, considere el siguiente ejemplo, donde estamos simulando varios niveles de relaciones mcap con 4 niveles diferentes de exponentes: [1.6], [1.8], [2] y [2.2]
También estamos estableciendo un mínimo (0.5%) y un máximo (80%) en las tarifas, con 0.5% yendo a la tesorería y el resto se quema.

A medida que aumenta la proporción y empeora el estado del protocolo, las tarifas para cualquier offshore se incrementarán en consecuencia.
La idea detrás de las altas tarifas no es castigar a los usuarios, sino disuadirlos de cambiar el protocolo hacia un mal estado y protegerse contra la inflación descontrolada quemando una gran parte de la tarifa.
 

Costa afuera - Tarifas de deslizamiento

Las tarifas de deslizamiento son una medida adicional para capturar grandes conversiones que empeorarían el estado del protocolo con una sola conversión.

Agregaríamos tarifas de deslizamiento a las tarifas de conversión estándar como se calculó anteriormente. Básicamente, las tarifas de deslizamiento son las tarifas después de un aumento potencial en la relación que se agrega a las tarifas de conversión estándar.

Aquí hay un ejemplo en el que la relación está en buen estado antes de una costa afuera, pero después de una sola conversión por parte de una ballena, la lleva a un mal estado.

Otras Consideraciones

¿Es suficiente el ratio Market Cap para calcular el estado del protocolo?
La respuesta es no.

Hay algo más a considerar que aún no hemos mencionado; la untado relación entre TOAMcap y XHVMcap.

El estado del protocolo en el que nos encontramos ahora, es decir, no es saludable, significa que no tendremos muchas conversiones en el sistema porque es demasiado costoso o requeriría demasiada garantía.
Sin embargo, esto podría cambiar tan pronto como el precio de XHV suba a un nivel en el que el índice de capitalización de mercado se vuelva favorable para los terrestres.

A medida que la gente comienza a operar en tierra y el precio de XHV aumenta, el diferencial entre TOAMcap y XHVMcap se amplía más rápidamente, lo que incentiva más operaciones en tierra, inflando la oferta.
Esto podría continuar hasta que todo el xUSD se haya convertido a XHV y el suministro circulante de XHV se haya inflado considerablemente.

Para contrarrestar esto, podríamos calcular la relación de diferencial entre los dos límites máximos frente al precio de XHV, y si el diferencial se vuelve demasiado grande, podríamos aplicar restricciones similares a las conversiones, incluso cuando la relación de capitalización de mercado esté en buen estado.

El siguiente gráfico de simulación muestra cómo podría calcularse esto.
Cuando el índice de capitalización de mercado es bajo (estado saludable: línea azul), pero el índice de diferencial es alto (línea verde), podríamos aumentar la garantía para los Onshore y aumentar las tarifas para los Offshore.

En resumen, proponemos las siguientes medidas

DESLOCALIZACIÓN

1. VBS con garantía 1:1, más tiempo de bloqueo (21 días propuestos).
2. Relación Mcap para determinar las tarifas en función del estado del protocolo.
3. Las tarifas de deslizamiento dependen del tamaño de la costa afuera y del estado del protocolo después de una costa afuera potencial.
4. Tarifas de relación de distribución.
5. Se aplica a conversiones XHV -> xUSD.

APOYO

1. VBS con tiempo de bloqueo (21 días propuestos).
2. Garantía mínima de 1:1 y máxima de 1:3 o 1:4 (por discutir).
3. Garantía a determinar por el estado del protocolo.
4. Colateral a ser determinado por el índice de distribución.
5. Tarifas de conversión básicas.
6. Se aplica a las conversiones xUSD -> XHV.

El punto clave de esta propuesta es que las discusiones y los comentarios de la comunidad deben centrarse en la nueva idea, VBS.
Realmente nos gustaría saber qué piensa y si ve algún problema evidente en este modelo.
 

Hay un trabajo de desarrollo significativo con lo que estamos proponiendo y mientras el equipo de desarrollo analiza esto, queremos tomarnos el tiempo para escuchar los comentarios de la comunidad sobre esta propuesta, en particular el enfoque novedoso de VBS.

Los miembros pueden debatir esto de forma más eficaz en el #havenómica canal.​