Proposta iniziale per lo sviluppo Haven 3.0

​

È importante notare che questa proposta è a progetto di raccomandazione.
Nessuna decisione sulla nostra tokenomica è stata ancora presa e nulla è scolpito nella pietra.

Tutto ciò che viene presentato in questo documento sono idee da discutere ulteriormente con la community e, una volta raggiunto un accordo, faremo un altro annuncio.

Da quando le conversioni sono state messo in pausa, i membri dell'Economics Working Group (EWG) sono stati impegnati a lavorare su soluzioni per riportare la rete Haven a uno stato completamente funzionale senza aprire la comunità Haven a un ulteriore rischio di iperinflazione come è successo ai detentori dell'ecosistema Terra.

Questo lavoro sarebbe stato più difficile e avrebbe richiesto più tempo senza il contributo della comunità.
Le idee portate avanti da molti dei nostri membri e raccolte da xVolontariov in questo documento, hanno fornito al team EWG una base su cui lavorare, che alla fine ci ha portato alla presentazione della proposta qui.

Pensiamo di aver trovato una soluzione praticabile e vorremmo aprire discussioni nel nostro 1TP3 Thanomics canale per ottenere feedback dalla community.
Queste discussioni saranno importanti per perfezionare il modello e alla fine trovare una soluzione funzionale.

Ad alcuni, le misure qui proposte possono sembrare dure e ingiuste, ma dobbiamo ricordare che il protocollo è attualmente in pessimo stato; dobbiamo assicurarci che non peggiori e dare al protocollo il tempo di riprendersi.

Vale la pena ricordare a tutti che il Vault non è mai stato concepito per essere utilizzato come strumento di trading; incoraggiamo tutti a negoziare XHV e xUSD in borsa, il che aumenterà l'adozione e aumenterà la liquidità.

Il percorso di sviluppo di Terra ha fornito un suggerimento, cercando di utilizzare i pool di Bitcoin per una stablecoin algoritmica supportata da ibrido prima che diventassero troppo grandi per il loro meccanismo di stabilità per gestire shock esogeni estremi.

Ma Haven è diverso; l'aspetto della privacy impedisce l'utilizzo di blockchain pubbliche, collaterali e stablecoin a scopo di supporto.

Il problema chiave con i modelli algoritmici delle stablecoin finora è che il design tokenomics significa che il prezzo delle stablecoin è supportato a scapito del prezzo dell'asset nativo.
Nel caso di Haven questo significa acquistare xUSD a buon mercato da coniare in XHV e quindi vendere XHV sul mercato. Ciò crea una soppressione costante del prezzo dell'asset nativo e se il prezzo dell'asset nativo diminuisce indefinitamente, può provocare una spirale mortale e una completa perdita di fiducia nella stablecoin.

Leggermente controintuitivamente, un design tokenomico che non dà priorità al prezzo della stablecoin e protegge invece il prezzo dell'asset nativo ha una maggiore longevità come ecosistema e quindi una maggiore fiducia nel valore della stablecoin.

Quindi il team di EWG ha avuto un'idea nuova; Haven sta raddoppiando l'"essere la propria banca" e richiederà garanzie sotto forma di XHV per utilizzare la funzione di shoring.

La nuova idea può essere riassunta in una frase:

Per Onshore/Offshore, devi avere il valore equivalente di XHV sbloccato nel tuo caveau.

Chiamiamo questa idea Vault Backed Shoring, o VBS. Ha lo scopo di fornire limiti di liquidità per l'utilizzo della funzione di shoring, determinati da ogni utente stesso.

Con questo nuovo requisito di garanzia, che bloccherà sia la garanzia che le monete coniate per un periodo prolungato, gli utenti shoring saranno costantemente esposti e collegati alla volatilità della garanzia di base mentre cambiano attivamente i numeri di fornitura del protocollo.

Non saranno in grado di utilizzare la funzione di shoring se vendono le loro garanzie XHV e non detengono XHV nei loro depositi, impedendo loro di "rinunciare" completamente al sistema volatile mentre la comunità paga la posizione opposta con l'aumento dell'inflazione.

In breve, Vault Backed Shoring è concepito per funzionare sia come freno di velocità che come requisito per la skin nel gioco per gli utenti della funzione di shoring.

NOTA: VBS sarà richiesto solo per i partecipanti che utilizzano le funzioni di shoring (XHV <-> xUSD), non XHV standard o trasferimenti xAsset.

Esempio di onshore:

Per convertire 100 xUSD in XHV, devi avere almeno $100 di XHV nel caveau, sbloccato.
Questo valore $100 di XHV (noto come collaterale) sarà bloccato per la durata della conversione insieme ai fondi convertiti.

Se il prezzo corrente di XHV è $0.50, significa che devi avere almeno 200 XHV (sbloccato) nel tuo caveau per portare a terra 100 xUSD.
Dopo la conversione riuscita utilizzando questo esempio, avrai 400 XHV bloccati per un periodo di tempo (vedi i tempi di blocco proposti più avanti).

Esempio di delocalizzazione:

Per convertire 100 XHV in xUSD, devi avere almeno la stessa quantità di XHV (100 in questo caso) nel caveau, sbloccato.
Ciò significa che puoi portare in mare aperto solo un massimo di 50% dell'XHV contenuto nel caveau, a condizione che nessuno degli XHV sia bloccato.

Tempi di blocco proposti per VBS

Sia i fondi che il requisito di garanzia saranno bloccati 21 giorni.

Se l'utente non detiene abbastanza garanzie per l'onshore in un'unica conversione, VBS rallenta il processo di onshoring richiedendo a un onshorer di eseguire più cicli di onshore e ogni onshore richiede 21 giorni per essere completato.

Per illustrare questo, ecco un paio di scenari che mostrano quanti cicli e quanto tempo ci vorrebbe per portare a terra l'intero importo di xUSD detenuto in un caveau.

Il primo esempio utilizza un importo iniziale di 10.000 XHV e il secondo esempio utilizza un importo iniziale di 100.000 XHV.
Entrambi gli esempi utilizzano una garanzia 1:1, il che significa che il massimo che puoi a terra in un dato momento è la quantità massima di XHV sbloccato che hai nel caveau.
Nella parte 2 della proposta, vedremo che la garanzia cambierà in base allo stato del protocollo.

È facile vedere che più garanzie sbloccate hai nel deposito, meno cicli saranno necessari per convertire completamente tutti i tuoi xUSD in XHV.

I prossimi due scenari utilizzano rispettivamente un prezzo XHV crescente e decrescente.

Da ciò, possiamo vedere che con un prezzo in aumento in XHV, sono necessari meno cicli onshore, ma si finisce con meno XHV complessivi di quanto avresti se fossi stato in grado di onshore tutto xUSD in una conversione.

Al contrario, poiché il prezzo di XHV diminuisce, sono necessari più cicli Onshore per convertire tutto xUSD, ma si finisce con più XHV.
Sebbene sembri che stia gonfiando il protocollo, questi scenari non tengono conto dello stato del protocollo, che impedirà il tipo di inflazione visto sopra.
Questo ci porta alla parte successiva della proposta.

La prima parte della proposta descriveva la nuova idea su VBS e come sarebbe stata implementata.

Da solo, tuttavia, VBS non fermerà necessariamente l'inflazione, soprattutto perché il prezzo di XHV diminuisce nel tempo, allungherà solo il tempo necessario per gonfiare il protocollo.

Pertanto, sono necessarie altre misure per contrastare l'inflazione incontrollata e la manipolazione delle balene.

Rapporto di capitalizzazione di mercato

Come molti membri della comunità avranno già notato attraverso le discussioni nel nostro canale Havenomics, uno dei modi migliori per misurare lo stato di salute del protocollo è utilizzare un rapporto tra la capitalizzazione di mercato combinata di Total Offshore Assets (TOAMcap) e la capitalizzazione di mercato XHV (XHVMcap ).

Questo è semplicemente calcolato come:

Più basso è il numero, più sano è il protocollo e viceversa.
Sebbene sia un dato soggettivo, si considera un rapporto molto buono quando XHVmcap è 10 volte quello di TOAMcap, cioè 0.1 usando la formula sopra.

Al momento in cui scriviamo (23 giugno 2022), l'offerta circolante di XHV è di ~28,3 milioni con una capitalizzazione di mercato di $16 milioni (utilizzando il prezzo KuCoin di $0.567).
La capitalizzazione di mercato del Total Asset è di ~$16 milioni.
Quindi il rapporto mcap che abbiamo in questo momento è quasi esattamente 1, che è considerato un cattivo rapporto e quindi uno stato malsano del protocollo.

Combinando il rapporto mcap con VBS

Uno stato malsano del protocollo può essere raggiunto nei seguenti modi:

• continuo calo del prezzo XHV
• conversioni singole molto grandi
• troppa delocalizzazione
• troppo onshoring, che può portare a pressioni di vendita sul mercato aperto
• qualsiasi combinazione dei punti precedenti

Se combiniamo lo stato del protocollo (rapporto mcap) con il nostro modello VBS, possiamo limitare ulteriormente il meccanismo di shoring per garantire che il sistema non oscilli troppo verso uno stato malsano.

Il modo in cui proponiamo di farlo per l'onshore e l'offshore è diverso.

ONSHORES

Per Onshores, aumenteremo le garanzie necessarie all'aumentare del rapporto mcap, il che significa che devi avere più XHV nel tuo deposito per la stessa quantità di xUSD quando il protocollo tende a uno stato negativo.

Supponiamo che il rapporto sia a 0,5, il protocollo si sta dirigendo verso uno stato malsano. Ciò significa che non sarai più in grado di utilizzare una garanzia 1:1 per onshore il tuo xUSD.
Un calcolo dinamico per questo rapporto potrebbe essere arrivato a una garanzia 1:3, il che significa che avresti bisogno di avere 3 volte più XHV nel tuo caveau rispetto alla quantità di XHV che stai cercando di portare a terra.

Per visualizzare meglio questo, utilizziamo lo stesso scenario di prima: iniziare un importo XHV di 10k con un prezzo costante, ma questa volta con un collaterale 1:3.

Con una garanzia 1:1 dell'esempio precedente, avremmo avuto bisogno di 7 onshore per convertire completamente tutti gli xUSD in XHV.
Con una garanzia 1:3, come sopra, il numero di onshore è aumentato a 17, richiedendo un anno intero per convertire tutti gli xUSD in XHV.

Confrontiamo anche lo stesso scenario, ma con un importo XHV iniziale di 100k.

In precedenza, con una garanzia 1:1, ci sarebbero voluti 4 onshore (84 giorni) per convertire tutto xUSD.
Con una garanzia 1:3, è aumentata a 9 onshore, o 189 giorni.

Naturalmente, questi scenari sono abbastanza irrealistici nel mondo reale; è impossibile prevedere le fluttuazioni del mercato e dei prezzi, i fondamentali, il sentiment, le tattiche di conversione, ecc.

La conclusione che possiamo trarre da ciò è che, man mano che lo stato del protocollo peggiora sempre più, aumenta anche la quantità di garanzie necessarie per convertire xUSD in XHV, il che a sua volta aumenta il numero di cicli e il tempo impiegato per l'onshore dell'intero importo.

OFFSHORE

Per Offshores, il concetto attuale è di mantenere il collaterale a 1:1, ma aumenteremo le commissioni all'aumentare del rapporto mcap. Inoltre, aggiungeremo anche commissioni di slippage per conversioni più grandi che porterebbero lo stato del protocollo da buono o cattivo in peggio.

NOTA: Il motivo per cui non stiamo prendendo in considerazione commissioni per Onshore, diverse dalle commissioni di conversione standard, è perché si ritiene che ciò abbasserebbe xUSD, il che potrebbe creare una spirale al ribasso del prezzo nel mercato aperto.

Offshore – Commissioni di conversione

Riteniamo che sia nell'interesse del protocollo bruciare la maggior parte delle commissioni per tenere sotto controllo l'inflazione, ma anche lasciare commissioni sufficienti per il costo operativo del progetto, più gli stipendi.
Ai fini di questa proposta, assumiamo un minimo di 0,5% di commissioni per il tesoro, con l'eventuale bruciato in eccedenza.
Le cifre esatte saranno concordate in una fase successiva.

Per calcolare le commissioni di conversione utilizzeremo una semplice operazione di esponenziazione tra il rapporto mcap e un numero che è 2 o molto vicino ad esso, +/- qualche decimale.
Se il numero è troppo alto, il calcolo diventerà esponenziale troppo rapidamente, il che lo renderebbe inutilizzabile.

Per illustrare ciò, si consideri il seguente esempio, in cui si simulano vari livelli di rapporti mcap con 4 diversi livelli di esponenti: [1.6], [1.8], [2] e [2.2]
Stiamo anche fissando un minimo (0,5%) e un massimo (80%) in commissioni, con 0,5% che andranno al tesoro e il resto bruciato.

Con l'aumento del rapporto e il peggioramento dello stato del protocollo, le commissioni per eventuali offshore aumenteranno di conseguenza.
L'idea alla base delle commissioni elevate non è quella di punire gli utenti, ma di scoraggiarli dal spostare il protocollo verso uno stato negativo e di proteggere dall'inflazione incontrollata bruciando gran parte della tariffa.
 

Offshore – Commissioni di slippage

Le commissioni di slippage sono una misura aggiuntiva per catturare grandi conversioni che peggiorerebbero lo stato del protocollo con una singola conversione.

Aggiungeremmo le commissioni di slippage alle commissioni di conversione standard calcolate sopra. Fondamentalmente, le commissioni di slippage sono le commissioni dopo un potenziale aumento del rapporto che viene aggiunto alle commissioni di conversione standard.

Ecco un esempio in cui il rapporto è in buono stato prima di un offshore, ma dopo una singola conversione da parte di una balena, lo porta in cattivo stato.

altre considerazioni

Il Market Cap ratio è sufficiente per calcolare lo stato del protocollo?
La risposta è no.

C'è qualcos'altro da considerare che non abbiamo ancora menzionato; il differenza rapporto tra TOAMcap e XHVMcap.

Lo stato del protocollo in cui ci troviamo ora, cioè malsano, significa che non avremo molte conversioni attraverso il sistema perché o è troppo costoso o richiederebbe troppe garanzie.
Questo, tuttavia, potrebbe cambiare non appena il prezzo dell'XHV sale a un livello in cui il rapporto di capitalizzazione di mercato diventa favorevole per l'onshore.

Quando le persone iniziano ad andare a terra e il prezzo di XHV aumenta, lo spread tra TOAMcap e XHVMcap si allarga più rapidamente, il che incentiva più a terra, gonfiando l'offerta.
Ciò potrebbe continuare fino a quando tutto il xUSD non sarà stato convertito in XHV e l'offerta circolante di XHV sarebbe stata notevolmente gonfiata.

Per contrastare ciò, potremmo calcolare il rapporto di spread tra i due cap rispetto al prezzo XHV e, se lo spread diventa troppo ampio, potremmo applicare restrizioni simili alle conversioni, anche quando il rapporto di capitalizzazione di mercato è in buono stato.

Il grafico di simulazione seguente mostra come questo potrebbe essere calcolato.
Quando il rapporto di capitalizzazione di mercato è basso (stato sano - linea blu), ma il rapporto di spread è alto (linea verde), potremmo aumentare il collaterale per l'onshore e aumentare le commissioni per l'offshore.

Ricapitolando, proponiamo le seguenti misure

OFFSHORING

1. VBS con garanzie 1:1, più Lock time (21 giorni proposti).
2. Rapporto Mcap per determinare le tariffe in base allo stato del protocollo.
3. Le commissioni di slippage dipendono dalle dimensioni dell'offshore e dallo stato del protocollo dopo un potenziale offshore.
4. Commissioni per il rapporto di diffusione.
5. Si applica alle conversioni XHV -> xUSD.

ONSHORING

1. VBS con tempo di blocco (21 giorni proposti).
2. Garanzia minima di 1:1 e massima di 1:3 o 1:4 (da discutere).
3. Garanzie da determinare in base allo stato del protocollo.
4. Garanzie da determinare in base allo spread ratio.
5. Commissioni di conversione di base.
6. Si applica alle conversioni xUSD -> XHV.

Il punto chiave di questa proposta è che le discussioni e il feedback della comunità dovrebbero essere incentrati sulla nuova idea, VBS.
Ci piacerebbe davvero sapere cosa ne pensi e se vedi problemi evidenti in questo modello.
 

C'è un lavoro di sviluppo significativo con ciò che stiamo proponendo e mentre il team di sviluppo si occupa di questo, vogliamo prenderci il tempo per ascoltare il feedback della comunità su questa proposta, in particolare il nuovo approccio di VBS.

I membri possono discuterne in modo più efficace nel 1TP3 Thanomics canale.​