Proposta di tokenizzazione Haven 3.0 (leggera)

Per visualizzare la proposta completa, fare clic su Qui.
Puoi anche scaricare una versione PDF della proposta completa da Qui.

Panoramica

Negli ultimi mesi, l'Economics Working Group (EWG) ha lavorato in stretto coordinamento con gli sviluppatori di Haven per produrre una proposta per un'implementazione specifica per il Vault Backed Shoring (VBS) proposta che è stato approvato con votazione comunitaria il 7 luglio 2022. 

Nella parte superiore di questa pagina c'è un collegamento alla proposta PDF completa di 32 pagine dall'EWG alla comunità. Spiega le circostanze che ci hanno portato qui, la teoria dietro VBS, le nostre formule proposte e le simulazioni in azione. Si tratta di un documento leggermente tecnico e incoraggiamo tutti a leggerlo al meglio delle proprie capacità. Tuttavia, questo post sul blog sarà una versione riepilogativa destinata a lettori più non tecnici. 

Il protocollo Haven è attualmente in uno stato non integro perché la protezione fornita dalle precedenti configurazioni dei meccanismi di offshoring/onshoring di Haven era insufficiente. La nostra precedente tokenomica si è concentrata sul tentativo di mantenere il prezzo di mercato di xUSD verso $1, ma lo ha fatto a scapito del prezzo di XHV. Ciò è stato denunciato da varie parti che hanno causato un'inflazione significativa e alla fine ha portato a un'imminente spirale di morte del prezzo dell'XHV. Questa crisi è stata scongiurata dalla decisione dell'EWG di interrompere le conversioni nel giugno 2022 perché le azioni degli utenti generali e, in particolare, delle grandi balene erano in procinto di distruggere il protocollo.

Nelle settimane successive e attraverso molte ore di dibattito, l'EWG è giunto alla conclusione che era troppo facile beneficiare della liquidità illimitata offerta dalle funzioni di shoring e allo stesso tempo essere tutelati dall'effetto negativo sul prezzo dell'XHV. Nelle nostre discussioni, ci siamo resi conto che tutte le altre stablecoin algoritmiche si erano concentrate sul mantenimento del prezzo della stablecoin piuttosto che del prezzo dell'asset che supportava la stablecoin e quindi avevano commesso un errore fondamentale. Inserisci VBS.

VBS richiede che un aspirante off/onshorer di XHV detenga un importo collaterale di XHV per eseguire l'off/onshore. Se un utente desidera offshore x importo di XHV, deve detenere separatamente y importo di XHV che sarà bloccato per la durata della conversione. Viceversa, se un utente desidera onshore b importo di xUSD, deve detenere separatamente c importo di XHV che sarà bloccato per la durata della conversione. Numeri specifici saranno trattati più in basso.

Lo scopo è quello di far sì che tutti coloro che vogliono utilizzare le funzioni off/onshore siano esposti al prezzo XHV e, quindi, alla salute dell'ecosistema del Protocollo Haven. Ad esempio, se un utente desidera effettuare l'onshore del proprio xUSD offshore in un secondo momento, deve conservare un saldo XHV o acquistare XHV sul mercato prima di poter completare un viaggio di andata e ritorno. 

Accanto a VBS, proponiamo altre tre modifiche volte a proteggere il protocollo e la sostenibilità del progetto: 

• Tempi di blocco 
• Commissioni di conversione
• Un limite all'importo che può essere convertito in ogni blocco 

I tempi di blocco e le commissioni di conversione sono i più semplici, quindi li tratteremo brevemente prima di passare ai requisiti di garanzia VBS e al tetto di shoring di conversione per blocco. 

Tempi di blocco

I tempi di blocco forniscono un ritardo nella velocità con cui i fondi possono essere off/onshore e quindi essere disponibili per essere venduti sul mercato o off/onshore. Anche la garanzia VBS richiesta per una conversione sarà bloccata per lo stesso periodo di tempo per cui i fondi convertiti sono bloccati.

I tempi di chiusura che proponiamo sono di 21 giorni sia per l'offshore che per l'onshore.

Commissioni di conversione

Inizialmente, abbiamo proposto un modello in cui le tariffe dinamiche sarebbero state utilizzate come misura per proteggere il sistema. Tuttavia, questo era insostenibile per una serie di motivi. Suggeriamo invece 1.5% per gli offshore e 1.5% per gli onshore. Le commissioni possono sembrare alte, ma con la tesoreria esaurita e fondi limitati a causa di una percentuale di volume notevolmente ridotta per le conversioni una volta implementato VBS, dobbiamo assicurarci che il progetto riceva fondi sufficienti per sostenere i suoi costi operativi.

L'attuale xUSD < > xAssets commissioni di conversione sono 0,5% per conversione, di cui 0,4% vengono bruciati e 0,1% sono equamente suddivisi tra i miner e il portafoglio di governance.

Per garantire che il protocollo riceva entrate sufficienti attraverso le conversioni, vorremmo apportare le seguenti modifiche:

• xUSD < > xAssets Commissioni di conversione da aumentare a 1,5%
• 1.2% verrebbe inviato al portafoglio di governance
• 0.3% andrebbe ai minatori (aumento da 0.05%)

Le tariffe saranno riviste regolarmente.

VBS

La domanda principale è esattamente quale importo di garanzia dovrebbe essere richiesto per svolgere una funzione di shoring? Ci sono tre fattori chiave da considerare:

• L'importo che un utente desidera off/onshore
• L'attuale stato di salute dell'ecosistema XHV prima dell'off/onshore
• L'inflazione potenziale/la salute futura dell'ecosistema XHV dopo l'offshore/onshore

Attraverso l'analisi dei dati storici e la modellazione di potenziali scenari futuri, ci siamo subito resi conto che i coefficienti dei requisiti di garanzia nella proposta iniziale non avrebbero fornito una protezione adeguata. L'obiettivo finale è avere un sistema che sia facile da usare, richieda poche garanzie quando il sistema è integro ma protegga da un'inflazione grave quando il protocollo è in pericolo. 

Considerando il nostro attuale stato malsano, questo è impegnativo e poiché stiamo aprendo nuovi orizzonti, la nostra attuale proposta è conservatrice per proteggere il protocollo. Possiamo perfezionare le formule per essere più user-friendly in futuro una volta raggiunta una certa stabilità. 

Ci sono tre componenti chiave utilizzati nei nostri calcoli delle garanzie VBS:

• Market Cap Ratio – Il rapporto tra il valore di XHV e xAssets in circolazione
• Spread Ratio – Una misura della "distanza" tra la capitalizzazione di mercato di XHV e la capitalizzazione di mercato di xAssets
• Slippage: l'impatto che una transazione avrà sullo stato dell'ecosistema

Le formule specifiche sono in discussione all'interno della comunità e possono essere trovate all'interno del documento di proposta. Di seguito li riassumeremo nel modo più non tecnico possibile e forniremo esempi.

Il requisito di garanzia totale VBS è:

Market Cap o Spread Ratio VBS + Slippage VBS

Il calcolo della prima parte dipende inizialmente dal fatto che si tratti di un off/onshore:

• Offshore – Rapporto capitalizzazione di mercato 
• Onshore: il maggiore tra Market Cap Ratio e Spread Ratio 

Il Market Cap Ratio utilizzerà due funzioni separate che coprono intervalli separati del Market Cap Ratio. Proponiamo che al di sotto di 0,9 mcap ratio, venga utilizzata una formula meno aggressiva per consentire un uso più semplice del sistema e al di sopra di 0,9 utilizziamo una formula più esponenziale che provoca un forte aumento del requisito di garanzia. 

Lo Spread Ratio è richiesto come protezione aggiuntiva per l'onshoring solo perché come persone a terra, l'offerta di XHV aumenta, diminuendo il rapporto mcap, riducendo il requisito di garanzia e creando maggiori possibilità di inflazione.

Per l'onshore, utilizziamo il peggiore dei due valori VBS tra mcap e spread ratio, il che significa che otteniamo protezione sull'intera gamma del market cap ratio.

La tabella seguente mostra i valori VBS per un intervallo di rapporti mcap e spread e i corrispondenti valori VBS calcolati. L'ultima colonna mostra il valore VBS effettivo utilizzato per Onshores, che è il VBS più alto dei due, Mcap e Spread VBS.

Slittamento

Per evitare che il coefficiente di capitalizzazione di mercato aumenti troppo rapidamente (peggiori) a causa di conversioni singole e di grandi dimensioni, dobbiamo aggiungere lo slippage sotto forma di VBS al VBS iniziale, che deriva dallo stato iniziale del protocollo. Ciò limiterà le balene a convertire quantità molto grandi con liquidità infinita.

Lo slippage è calcolato in modo diverso per offshore e onshore.

Per Al largo, prendiamo l'aumento percentuale del Rapporto di capitalizzazione di mercato in base a quanto viene convertito.
Per A terra, prendiamo l'aumento percentuale del Rapporto di diffusione.

Le formule specifiche sono dettagliate nel documento di proposta. A causa degli onshore che richiedono già requisiti VBS aggiuntivi rispetto agli offshore, lo slippage VBS offshore sarà più significativo. Per mostrare come potrebbero apparire questi numeri, abbiamo incluso una tabella di seguito con il nostro suggerimento. Come con il Market Cap Ratio, utilizziamo un multipler diverso quando il sistema è in uno stato sano (3x quando il rapporto mcap < 0,1) rispetto a uno stato non sano (10x quando il rapporto mcap > 0,1). 

Limite di conversione per blocco

La protezione fornita dalle misure VBS di cui sopra lascia un vettore di attacco in cui un utente sofisticato potrebbe suddividere una conversione di grandi dimensioni in molte conversioni più piccole che vengono elaborate all'interno dello stesso blocco. Ciò eviterebbe lo slippage e qualsiasi modifica alla capitalizzazione di mercato o agli spread ratio e presenterebbe loro un VBS più favorevole di quello per cui il sistema è progettato. 

La nostra soluzione proposta a questo è un limite per blocco sulla quantità di XHV che può essere off/onshore. Questo limite sarà dinamico e dipenderà dalla capitalizzazione di mercato di XHV. La formula specifica delineata nel documento di proposta è stata scelta per limitare l'impatto sugli utenti abituali. Di seguito è riportata una tabella di quale sarebbe la capitalizzazione a varie capitalizzazioni di mercato XHV.

Simulazione

Per aiutare a contestualizzare questo, abbiamo creato tre simulazioni nel documento di proposta. Ne abbiamo incluso uno di seguito e accogliamo con favore suggerimenti per scenari che possiamo modellare. Troverai i dettagli su come proporre la simulazione nel documento di proposta. 

E se VBS fosse già in atto quando XHV ha raggiunto un minimo di $0.42 nel giugno 2022 e la nostra balena xUSD ha iniziato a onshore quanto il sistema gli avrebbe consentito?

L'ipotesi più grande qui è una garanzia iniziale di 500k XHV.

Come puoi vedere, negli ultimi 126 giorni, la balena ha potuto atterrare solo a 76k XHV, a causa del cattivo stato in cui ci troviamo, e un corrispondente VBS alto.

Ciò presuppone che la balena non avrebbe acquistato o venduto alcun XHV durante quel periodo e che il prezzo fosse rimasto all'interno di questo intervallo.

In sintesi

Per ricapitolare, proponiamo le seguenti misure per la tokenomica Haven 3.0:

Misure di puntellazione generiche

• 21 giorni di blocco per tutte le conversioni XHV < > xUSD
• VBS minimo = 1
• Nessun VBS massimo
• Tappo di puntellazione per blocco
• Commissioni 1.5% per tutte le conversioni XHV < > xUSD
• Commissioni di 1.5% per conversioni xUSD < > xAssets, con 1.2% per il portafoglio gov e 0.3% per i minatori
• xAssets i tempi di sblocco della conversione rimangono a 48 ore
• VBS applicabile solo alle conversioni XHV < > xUSD

Misure specifiche offshore

• VBS variabile basata sul Market Cap Ratio di XHV e xAssets
• Slippage VBS variabile basato sull'aumento del Market Cap Ratio
• Massima funzionalità offshore

Misure specifiche a terra

• VBS variabile basata sul VBS peggiore (più alto) tra il Market Cap Ratio VBS e lo Spread Ratio VBS
• Slippage VBS variabile in base all'aumento dello Spread Ratio
• Funzionalità massima a terra

Questa è di gran lunga la proposta più complessa che abbiamo pubblicato fino ad oggi, e anche la tokenomica più complessa che stiamo cercando di implementare.

I membri del gruppo di lavoro sull'economia saranno disponibili per rispondere a qualsiasi domanda tu possa avere, ma ti preghiamo di dedicare del tempo a leggere e rileggere la proposta al fine di ottenere una buona comprensione. Molte domande avranno già avuto risposta in questa proposta.

Grazie a tutti per la vostra incredibile pazienza e supporto durante questi tempi difficili.​