Docs di Nebula Protocol

Published in

Terra Network Italia

21 min readMar 2, 2022

Ecco la documentazione ufficiale di Nebula Protocol, dove scoprirete come Nebula ha creato il primo marketplace di cluster, ovvero asset che raccontano una storia.

Traduzione dell’originale a cura di Il_Mars_

Panoramica

Abstract

Gli investimenti passivi nella TradFi sono corrotti. I prodotti finanziari sono emessi, gestiti e controllati da istituzioni centralizzate e poco trasparenti. Inoltre, offrono poca flessibilità e varietà di prodotti.

Tuttavia, con le crypto e la DeFi possiamo cambiare le cose. La DeFi è componibile e guidata dalla community, il che apre le porte a nuovi prodotti, come gli indici, e a maggiore flessibilità.

Nonostante siano decisamente migliori delle controparti nella TradFi, crediamo che gli attuali protocolli di indici non abbiano ancora risolto questo problema. La maggior parte degli strumenti on-chain disponibili è ancora limitata in termini di opzioni offerte, meccaniche e composizione. Molti si limitano infatti a poche tipologie di asset e prevedono parametri di ribilanciamento poco flessibili.

Il mondo crypto sta vivendo un rapido sviluppo e cominciano a emergere diversi settori e narrative, di conseguenza queste opzioni non sono più sufficienti. Gli utenti necessitano di maggiore possibilità di scelta, maggiore flessibilità e maggiore libertà.

In breve

Nebula è un protocollo costruito sulla blockchain Terra che permette agli utenti di investire in storie e strategie che vengono rappresentate da strumenti che possono essere considerati panieri decentralizzati, ovvero i cluster. I cluster sono smart contract che gestiscono una strategia di investimento dinamica.

Questi cluster hanno due caratteristiche uniche:

Sono programmabili e possono essere aggiornati in modo da rispettare l’allocazione desiderata

Al contrario delle controparti della TradFi, che vengono gestite e modificate saltuariamente sulla base di parametri rigidi, è possibile modificare l’allocazione target dei cluster a ogni blocco per cambiare attivamente la loro composizione al fine di rimanere fedeli alla loro strategia o di modificarla. Non esistono limiti intriseci alla logica utilizzata o agli asset inclusi, perciò i cluster possono seguire un numero infinito di strategie.

Ribilanciamento continuo e decentralizzato

Mentre i prodotti strutturati tradizionali sono ribilanciati periodicamente da un’entità centralizzata, il ribilanciamento dei cluster per rispettare la loro composizione desiderata avviene di continuo e in modo organico tramite l’attività e le azioni degli utenti del protocollo. I cluster non necessitano di alcuna gestione attiva e sono alimentati dall’attività organica degli utenti di Nebula.

Queste caratteristiche offrono tre vantaggi agli utenti del protocollo:

Parametri determinati dalla community: la community determina quali sono i token inclusi nei cluster di Nebula e quali algoritmi sono utilizzati per il ribilanciamento di ogni cluster.
Incentivi di ribilanciamento in linea con gli interessi degli utenti: al contrario della TradFi, non c’è un’entità centrale che si intasca le fee. Il protocollo prevede incentivi economici che spingono i membri della community ad agire come rebalancer (“ribilanciatori”) in modo che i cluster mantengano il peg definito dall’algoritmo.
Ampia varietà di asset utilizzabili: il protocollo impone limiti minimi relativi agli asset che possono essere inclusi nei cluster. Questo offre alla community la massima flessibilità e un margine di manovra pressocché infinito per creare cluster che soddisfano le loro esigenze.

I cluster di Nebula permettono agli utenti partecipare passivamente a infinite storie e strategie algoritmiche semplicemente detenendo il token del cluster, che rappresenta una quota del sottostante (inventory) che può essere riscattata. La flessibilità offerta da Nebula è pensata per permettere ai cluster di adattarsi e crescere in tutte le condizioni di mercato e per offrire agli utenti la flessibilità e la possibilità di creare e definire opzioni specifiche a seconda delle loro esigenze.

Il protocollo apre le porte a infinite possibilità di investimento dinamico e decentralizzato: fortemente espressivo, accessibile e profondamente democratico. Il protocollo si affida all’attività della community non solo per l’operatività, ma anche per definire il suo futuro tramite la governance. La governance dà forma al protocollo e ne definisce i futuri sviluppi con risoluzioni con consenso collaborativo.

Nebula è un progetto gestito e guidato unicamente dalla community di holder del token NEB, che lo mettono in staking per ottenere potere di voto. Nelle prime fasi, Nebula sarà supportato dal team di sviluppo, che lo guiderà nella transizione fino a quando diventerà completamente autonomo e nelle mani della community. Il team di Nebula non è in possesso delle admin key.

Token

Su Nebula Protocol sarà possibile utilizzare diversi token per diversi scopi:

TerraUSD (UST — native): stablecoin usata principalmente per il trading e per fornire liquidità nelle pool di Cluster Token.

Cluster Token (CT — CW20): quota negoziabile del sottostante del cluster.

LP Token (LP — CW20): token distribuito ai liquidity provider delle coppie CT-UST. Può essere messo in staking per ottenere le reward dell’LP.

Nebula Token (NEB — CW20): token di governance, usato anche per il meccanismo di incentivi.

Community

Cluster

Un cluster è un indice decentralizzato che traccia un’allocazione di asset programmabile. Ogni cluster viene implementato come uno smart contract che incentiva gli utenti a eseguire depositi/prelievi di ribilanciamento in modo che i bilanci del suo token siano in linea con l’allocazione target del cluster.

I cluster emettono quote negoziabili del suo sottostante (inventory) chiamate cluster token (CT), che vengono mintate quando gli utenti depositano asset nel cluster e possono essere poi restituite e bruciate per ottenere una parte degli asset detenuti dal cluster.

Nebula permette agli utenti di “investire in storie” detenendo e negoziando i vari cluster token. I cluster sono espressioni negoziabili di narrative grazie alla loro asset allocation dinamica e, se combinati, permettono agli utenti di costruire un portafoglio “espressivo” con diversi temi e strategie di investimento.

Vantaggi dei cluster

Massima flessibilità: Nebula è concepito per imporre meno limiti possibili alla definizione dei cluster. Questa quasi assenza di limiti riguarda sia gli asset che possono essere inclusi nei cluster, sia la logica e l’algoritmo che determina come avviene il ribilanciamento e la gestione della composizione dell’asset.
Minimizzazione del controllo centralizzato: i prodotti finanziari tradizionali si basano su vari intermediari che definiscono come sono strutturati, gestiti e modificati. Con Nebula, vogliamo dare questo potere decisionale in mano a chi davvero utilizza il protocollo, ovvero la community. Saranno i membri della community a prendere le decisioni.
Aumento dell’efficienza legata alla manutenzione/modifica dell’indice: invece di affidarsi a una controparte centralizzata per ribilanciare e modificare regolarmente i cluster, Nebula implementa vari incentivi e altri meccanismi che spingono la community a partecipare attivamente per garantire la salute del protocollo.

Definizione

Un cluster è un’istanza di uno smart contract, un’entità simile a un accouut che comanda un bilancio e può richiamare una serie ristretta di operazioni sulla chain Terra. Un cluster può essere descritto con i seguenti attributi:

nome, una breve denominazione che identifica il cluster
descrizione, una spiegazione della strategia del cluster
target, l’allocazione target del cluster in termini di asset e ponderazione
penalty function, un modello matematico che serve a valutare le operazioni di ribilanciamento
inventory (sottostante), il bilancio del cluster nei vari token Terra nativi o CW20
cluster token, il token associato che rappresenta la quota del sottostante
pricing oracle, un account o un contratto autorizzato ad aggiornare il prezzo degli asset
target oracle, un account o contratto autorizzato ad aggiornare l’allocazione target del cluster

Ciclo di vita del cluster

Concezione (Ideation)

Ogni cluster nasce da un’idea. Ecco uno scenario tipico:

Un membro della community trova un’opportunità unica e un caso d’uso interessante per un cluster di Nebula e crea un post nel forum di Nebula dove spiega la sua idea e chiede feedback critici alla community.
Una volta che l’idea dell’utente è stata affinata a seguito del dibattito, si sottopone alla governance una proposal (poll) per la creazione di questo cluster.

Votazione (Voting)

La community vota per approvare o meno la creazione del cluster proposto. Se il poll ottiene abbastanza voti e passa, la creazione del cluster avviene automaticamente in seguito all’esecuzione del poll e il cluster viene inizializzato con la procedura seguente:

Impostazione della configurazione del cluster secondo le specifiche del poll.
Creazione di un nuovo token CW20 da usare come cluster token, che può essere mintato solamente dal nuovo cluster.
Creazione di una coppia su Astroport per il nuovo cluster token (cluster token — UST).
Registrazione del nuovo cluster nel protocollo in modo che possa ricevere le reward dello staking.

Attivazione (Active)

In seguito all’approvazione e all’inizializzazione, ha inizio la fase di attivazione, durante la quale il cluster diventa pienamente operativo.

Gli utenti possono cominciare a mintare/bruciare, negoziare ed effettuare operazioni di ribilanciamento nel cluster. Ciò significa che la supply del cluster token e il sottostante del cluster possono essere modificati con depositi e prelievi.
Il cluster può effettuare aggiornamenti per allinearsi alla strategia tramite il recomposition oracle.

Capolinea (End-of-Life)

Un cluster può essere decommissionato tramite un governance poll, che ne sancisce l’effettivo capolinea ed effettua il delisting da Nebula Protocol. L’operazione è irreversibile e l’unico modo per “riattivare” un cluster decommissionato è ricomincare da capo e proporre la creazione di un nuovo cluster con la stessa configurazione.

Una volta che il cluster è stato disabilitato:

le operazioni CREATE relative al cluster vengono disattivate. Ciò significa che non è più possibile mintare cluster token.
Le operazioni REDEEM possono essere effettuate solamente come prelievi pro-rata.
Il pricing oracle e il recomposition oracle non effettuano più aggiornamenti.
Il cluster viene rimosso da ogni LP pool e dalle campagne di incentivi per l’arbitraggio. Di conseguenza, non ottiene più le reward associate al cluster.

Siccome non è più possibile mintare nuovi cluster token ed è possibile effettuare solo prelievi pro-rata, la composizione degli asset del cluster decommissionato (allocazione) è considerata congelata. Gli utenti che ancora detengono i cluster token sono invitati a scambiarli con gli asset sottostanti per evitare di detenere capitale fermo.

Aggiornamenti dell’allocazione target

I cluster possono aggiornare la loro allocazione target con un ribilanciamento diretto per modificare la composizione del sottostante e la ponderazione degli asset nell’allocazione al fine di mantenere una narrativa in linea con l’andamento del mercato.

Target oracle

Ogni cluster designa un account come proprio target oracle. Il target oracle è un account privilegiato che è autorizzato ad aggiornare la composizione target di asset del cluster. Se il cluster non richiede un target oracle, questo valore deve essere impostato in modo che corrisponda al contract addess della governance di Nebula. In questi casi, gli aggiornamenti dell’allocazione target possono essere effettuati solamente tramite una votazione nella governance.

In alternativa, come target oracle di un cluster è possibile indicare un account utente fidato o uno smart contract. Se un cluster necessita di modificare il proprio target oracle per qualunque ragione, occorre passare per una votazione nella governance.

Ricomposizione

Con un aggiornamento dell’allocazione target è possibile non solo modificare la ponderazione degli asset dell’allocazione, ma anche introdurre nuovi asset nel cluster. Questo, insieme all’impostazione a 0 del peso di un asset del cluster (che corrisponde alla rimozione dell’asset dal paniere), è chiamata target recomposition (ricomposizione).

Procedura

Alcune osservazioni relative alla procedura:

se l’asset è già presente nell’allocazione target, ma il suo peso è impostato su 0, si tratta di un asset che in precedenza faceva parte dell’allocazione target attiva del cluster.
Se si rimuove un asset dal target, il peso dell’asset in questione dovrà essere uguale a 0 e dovrà rimanere nella lista degli asset riconosciuti per tutta la vita del cluster.
Se il peso target di un asset è 0, il cluster rifiuta tutte le operazioni CREATE che coinvolgono tale asset.

Ribilanciamento

Affinché il cluster rimanga allineato alla sua allocazione target, è necessario modificare il sottostante, o ribilanciarlo, a seguito della modifica dei prezzi degli asset che lo compongono.

Al contrario dei panieri della finanza tradizionale, Nebula ribilancia i suoi cluster con una procedura decentralizzata. Ogniqualvolta la composizione di un cluster si discosta dalla composizione target, gli utenti possono effettuare un’operazione di ribilanciamento.

Operazioni

Esistono due operazioni di ribilanciamento: “CREATE” e “REDEEM”, che corrispondono al mint e al burn dei cluster token. Gli utenti sono incentivati tramite sconti o reward in token NEB a mintare o bruciare cluster token depositando e rimuovendo asset in modo da ridurre la divergenza del cluster dall’allocazione target.

Nota: a causa dell’asimmetria introdotta dalla penalty function, le operazioni CREATE e REDEEM non sono necessariamente operazioni direttamente inverse.

Notazione

Nota sulla penalty function

Le penalty function (funzione di penalità) hanno diverse proprietà:

la penalità aumenta all’aumentare dello squilibrio.
la penalità aumenta proporzionalmente alle dimensioni del cluster. La creazione di uno squilibrio di $1'000 in un cluster equilibrato del valore di $10'000 deve comportare una penalità maggiore rispetto alla stessa operazione in un cluster del valore di $10'000'000.
spezzare un’operazione di ribilanciamento in operazioni più piccole comporta una penalità equivalente o più severa.
deve esserci una soglia minima di squilibrio necessaria per avere diritto alle reward (CREATE) o allo sconto (REDEEM), in quanto queste ricompense diluiscono il valore del cluster token per i token holder.
l’aumento intenzionale dello squilibrio volto a raccogliere le reward legate al ribilanciamento deve sempre tradursi in una perdita netta.

Allocazione di capitale

L’allocazione di capitale A di un cluster è definita dal suo sottostante di token in termini nozionali (unità di UST). Per un determinato cluster, la sua allocazione di capitale sarà la seguente:

“A” = allocazione di capitale

Squilibrio nozionale

Lo squilibrio nozionale X di un cluster è definito come il doppio della quantità di UST che deve essere riallocata (scambio di un asset sottostante in un altro asset) per ribilanciare il cluster, ovvero quando

Per calcolare X, occorre prima determinare l’allocazione di capitale target di un cluster perfettamente bilanciato con lo stesso valore totale.

Calcolare il target weight vector nello spazio nozionale:

In seguito moltiplicare per il valore nozionale totale del cluster:

Ora calcolare X aggiungendo la differenza del cluster dall’allocazione di capitale target per ogni asset del sottostante:

Per comodità, nel contesto dell’operazione di ribilanciamento, X0 e X1 si riferiscono allo squilibrio nozionale del cluster, rispettivamente prima e dopo il ribilanciamento.

Nota: le funzioni penalità (p) e le reward (r), abbreviate come penalty function Y, sono modificate con un input E, la media mobile esponenziale (EMA) del valore totale del cluster. L’EMA è utilizzata come indicatore di lag e come protezione da forme di manipolazioni e modifica di parametri soglia.

La notazione c (con accento circonflesso) è usata per indicare un parametro soglia modificato, che è stato moltiplicato per il valore di E fornito nel contesto.

Operazione CREATE / mint

Durante un’operazione CREATE, l’utente deposita asset nel cluster e riceve in cambio cluster token appena mintati. La quantità di cluster token mintati dipende dalla qualità dell’operazione CREATE, che corrisponde all’entità della correzione dello squilibrio.

Un’operazione CREATE contiene due argomenti:

asset_amount: C, elenco delle quantità degli asset da depositare
min_tokens: tokensmin, (facoltativa) quantità minima di cluster token da ricevere

L’utente specifica la quantità di ogni asset da usare nell’operazione con asset_amounts e il cluster determina la quantità di cluster token da distribuire all’utente. L’operazione è interrotta se la quantità è inferiore a min_tokens.

Se non viene indicata una quantità minima di token (min_tokens), l’operazione CREATE viene eseguita senza protezione al ribasso sulla quantità di cluster token ricevuti.

Il numero di token ricevuti è:

Esempio operazione CREATE:

Operazione REDEEM / burn

In un’operazione REDEEM, l’utente brucia i cluster token (li rimuove dal circolante) e preleva gli asset dal cluster. La quantità di cluster token bruciati dipende dalla qualità dell’operazione REDEEM, che corrisponde all’entità della correzione dello squilibrio.

Un’operazione REDEEM contiene due argomenti:

asset_amounts: -R, (facoltativa) elenco delle quantità degli asset da prelevare
max_tokens: tokensmax, quantità massima di cluster token da bruciare

Gli utenti possono specificare la quantità desiderata di ogni asset da prelevare in asset_amounts e il cluster calcola il numero di cluster token che vengono bruciati nell’operazione. L’operazione viene interrotta se la quantità supera max_tokens.

Se non vengono indicate le quantità degli asset da prelevare (asset_amounts), l’operazione REDEEM viene considerata un prelievo pro-rata del sottostante del cluster e viene utilizzato il valore di default seguente:

Il numero di token bruciati è pari a:

Esempio operazione REDEEM:

Penalty function

Nota: la sezione descrive la penalty function di default prevista da Nebula. A seconda delle necessità, è possibile configurare i cluster affinché utilizzino funzioni di penalità alternative.

La penalty function Y offre un modello per valutare un’operazione di ribilanciamento e incentiva gli utenti a effettuare depositi CREATE e prelievi REDEEM utilizzando importi che permettano al sottostante di riavvicinarsi all’alloccazione target. La funzione traduce la variazione dello squilibrio nozionale del sottostante del cluster in seguito al ribilanciamento in una penalità (o ricompensa).

La funzione y restituisce una penalità o una ricompensa in base a due curve separate, a seconda dell’aumento o meno dell’equilibrio nozionale finale. Se l’operazione aumenta lo squilibrio nozionale, ovvero se X0 < X1, viene calcolata una penalità usando la funzione p. In caso contrario, viene usata la funzione r per stabilire una ricompensa. Queste funzioni traducono un dato squilibrio X nel tasso di penalità o ricompensa per unità di squilibrio.

Calcoliamo Y, la penalità/ricompensa nozionale (quantità in UST) derivante dall’operazione calcolando l’area sotto la curva y, utilizzando il suo integrale definito rispetto allo squilibrio nozionale tra gli squilibri iniziale e finale del cluster.

Funzione p

Se lo squilibrio del cluster aumenta a seguito del ribilanciamento, calcoliamo la penalità teorica Y prendendo in considerazione l’area sotto la curva p tra i due squilibri (evidenziata), come illustrato qui di seguito.

Parametri

Funzione r

Se lo squilibrio del cluster diminuisce a seguito del ribilanciamento, calcoliamo la ricompensa teorica Y prendendo in considerazione l’area sotto la curva r tra i due squilibri (evidenziata), come illustrato di seguito.

Parametri

Partecipanti

Quando interagiscono con Nebula Protocol, gli utenti possono ricoprire vari ruoli, descritti qui di seguito.

Trader

I trader detengono o comprano/vendono i cluster token e li includono nel loro portafoglio per esporsi passivamente alle strategie di trading espresse dalla combinazione dei cluster.

Liquidity Provider

I liquidity provider depositano i cluster token e UST in una o diverse pool di liquidità riconosciute da Nebula Protocol e mettono in staking le loro posizioni LP per guadagnare reward in NEB.

Ribilanciatori (rebalancer)

Invece di lasciare la gestione e il ribilanciamento dei cluster e degli indici nelle mani di terze parti centralizzate, Nebula implementa svariati meccanismi di incentivi nel protocollo per spingere la community e gli utenti a contribuire al mantenimento dell’asset allocation del cluster. Questo garantisce maggiore trasparenza e una gestione del cluster più efficiente.

I ribilanciatori si occupano del ribilanciamento e delle operazioni di minting e burning nei cluster. Gli utenti sono incentivati a occuparsi del ribilanciamento in due modi:

I ribilanciatori che avvicinano la composizione del cluster all’allocazione target possono beneficiare di uno sconto offerto dal protocollo sui cluster token al momento del minting o sugli asset sottostanti al momento del burn. L’importo delle reward che guadagnano è determinato dalla funzione di penalità del cluster.
Nelle prime fasi dopo il lancio del protocollo, oltre allo sconto gli utenti riceveranno anche ricompense in token NEB per incentivare ulteriormente i ribilanciamenti.

Arbitrageur

Nota: il ruolo del ribilanciatore è spesso collegato al ruolo di arbitrageur in quanto entrambe le operazioni possono essere eseguite insieme in un’unica transazione.

Gli arbitrageur acquistano e vendono cluster token su diversi mercati e protocolli di liquidità eliminando le differenze tra il prezzo di mercato e il net asset value (NAV) del cluster.

Nebula Protocol incentiva varie strategie di arbitraggio su diversi protocolli come Astroport con campagne di incentivi che prevedono ricompense in token NEB per i trade che soddisfano determinati requisiti. Potete trovare tutti i possibili scenari di arbitraggio nella sezione “Marketplace”.

Votanti (voter)

I votanti mettono in staking i loro token NEB per acquisire potere di voto e controllare la governance. Inoltre, accumulano ricompense in NEB mentre i loro token sono in staking e votano e partecipano alla governance. Maggiori informazioni sulla governance di Nebula sono disponibili nella sezione “Governance”.

Ruoli privilegiati (Privileged Roles)

I seguenti ruoli dispongono di un accesso privilegiato a componenti centrali di Nebula o richiedono un’interazione diretta con il team di sviluppo del protocollo (ad es. l’integrazione con la web app). Di conseguenza, questi ruoli sono assegnati democraticamente tramite la governance.

Cluster Manager

I cluster manager sono entità o organizzazioni responsabili della gestione di vari punti di operazione per un cluster. Sebbene tutti i componenti dei cluster possano essere interamente decentralizzati, la governance potrebbe decidere di affidarsi a terza parti fidate affinché controllino determinati aspetti.

Ecco alcuni esempi di compiti di competenza dei cluster manager:

detenzione delle chiavi (spesso multisig) che controllano il recomposition oracle
gestione dei bot che implementano uno schema di riallocazione degli asset del cluster
monitoraggio dell’attività del cluster e formulazione di proposte alla governance relative ad aggiornamenti dei parametri

Marketplace

Oltre a modulare gli incentivi in token NEB relativi al ribilanciamento che permettono il corretto funzionamento dei cluster, Nebula gestisce anche un marketplace decentralizzato di cluster token, sfruttando Astroport come automated market maker (AMM) per le pool di liquidità.

Sebbene si preveda che i cluster token saranno disponibili su diversi exchange, il cluster market di default di Nebula è considerato il marketplace di base riconosciuto dal protocollo. Nei primi giorni in seguito al lancio del protocollo, Nebula fornirà incentivi in token NEB per spingere gli utenti a fornire liquidità e mantenere l’allineamento di prezzo tra un’unità di cluster token e gli asset che compongono il sottostante del cluster.

Meccanismi

Liquidità per i cluster token

Al fine di garantire un’ottima esperienza di trading, il marketplace di default per i cluster token deve fare in modo che le pool di asset dispongano di sufficiente liquidità, ovvero che il mercato disponga di una quantità sufficiente di capitale per un’attività di trading sostenibile. Per farlo, Nebula Protocol distribuisce token NEB come incentivo agli utenti che forniscono liquidità nelle pool Cluster Token — UST.

Per farlo, gli utenti possono fornire liquidità alle pool su Astroport e mettere in staking il token CT-UST LP ricevuto per guadagnare una parte dei nuovi token NEB emessi a ogni blocco. I token LP messi in staking possono essere prelevati in qualsiasi momento senza periodi di blocco e possono essere utilizzati immediatamente per prelevare la liquidità dalle pool. È importante sottolineare che con questa operazione si è esposti a “impermanent loss” e quindi gli utenti potrebbero ritrovarsi con meno liquidità di quella depositata inizialmente.

Reward

Una volta messi in staking, i token CT-UST LP accumulano ricompense a ogni blocco. Le reward per gli staker di token LP provengono dalle nuove emissioni di token NEB, che rispettano il programma di distribuzione del token NEB (seguirà annuncio). La supply sarà inflazionistica fino al raggiungimento del cap, a seguito del quale non verranno più emessi token NEB.

A ogni cluster token è associato un peso, che determina la quantità di token NEB che gli viene assegnata rispetto all’emissione totale di ogni blocco. Gli utenti che mettono in staking i token CT-UST LP guadagnano token NEB da ognuna delle cluster token staking pool alla quale contribuiscono.

La quantità di token NEB che ogni utente che mette in staking token CT-UST LP può ricevere dipende da vari fattori, alcuni dei quali possono essere modificati dalla governance:

il peso del singolo cluster per il calcolo delle reward
la quota di token CT-UST LP dell’utente rispetto al valore totale della staking pool
programma di distribuzione del token NEB

In linea generale, gli utenti possono aspettarsi di accumulare continuamente le reward in token NEB proporzionalmente alle dimensioni del token CT-UST LP depositato. Inoltre ricevono le reward da ogni cluster in cui forniscono liquidità.

Arbitraggio

Un altro aspetto che il marketplace di default di Nebula punta a preservare è l’allineamento di prezzo tra un’unità di cluster token e gli asset che compongono il sottostante del cluster, chiamato NAV (net asset value). Siccome i cluster di Nebula sono ribilanciati di continuo dagli utenti che effettuano operazioni CREATE/REDEEM a ogni blocco, il prezzo del cluster token dovrebbe convergere verso il NAV teorico, con un margine di errore minimo. Poiché i cluster token possono essere scambiati 1:1 con gli asset sottostanti, potrebbero nascere opportunità di arbitraggio.

Oltre al profitto generato dall’arbitraggio, Nebula Protocol distribuirà ricompense in token NEB agli utenti che effettuano queste operazioni. Le due sezioni successive descrivono ogni possibile scenario di arbitraggio.

Prezzo di mercato > prezzo NAV

Se il prezzo di mercato del cluster token (CT) è superiore al prezzo derivato dal suo NAV, gli utenti sono incentivati ad abbassare il prezzo aumentando la pressione in vendita del cluster token su Astroport. Gli utenti con UST possono

acquistare quantità appropriate di asset su Astroport
effettuare operazioni CREATE per mintare nuovi token CT
vendere questi token CT su Astroport per UST intascando un profitto (se l’arbitraggio ha successo)

Prezzo di mercato < prezzo NAV

Se il prezzo del cluster token CT è inferiore al prezzo derivato dal suo NAV, gli utenti sono incentivati ad aumentare il prezzo aumentando la pressione in acquisto del cluster token su Astroport. Gli utenti con UST possono

acquistare cluster token su Astroport
riscattare gli asset del sottostante del cluster bruciando i cluster token
vendere gli asset su Astroport per UST, intascando un profitto (se l’arbitraggio ha successo)

Reward

Oltre al profitto legato all’arbitraggio, Nebula Protocol incentiva con token NEB gli utenti che effettuano queste operazioni. Tutti gli utenti che effettuano un’operazione di arbitraggio con successo vengono ricompensati a intervalli definiti con una porzione di token NEB proveniente dalla campagna di incentivi. La ricompensa è porporzionale al contributo dell’utente.

Governance (DAO)

La governance è il processo democratico con cui la community può sottoporre e accettare le proposte di cambiamento relative a Nebula Protocol. Non esistono admin key con accesso privilegiato. In seguito al bootstrapping iniziale dei contract, il Gov contract sarà il possessore di tutti i contract di Nebula Protocol e tutti i cambiamenti dovranno passare per la governance secondo la procedura descritta in questa sezione.

Token Nebula

Il token Nebula (NEB) è il token di governance di Nebula Protocol. Solamente gli utenti che hanno messo in staking i propri NEB possono partecipare alle votazioni e il potere di voto di ogni utente dipenderà dalla quantità di NEB in staking. Per ogni votazione, gli utenti possono decidere di allocare al massimo una quantità di token pari alla quantità totale dei loro NEB in staking. Di conseguenza, gli utenti con più NEB in staking avranno più influenza nella governance.

Sebbene a ogni votazione gli utenti ricevano 1 voto per ogni NEB in staking, il voto non influisce sul bilancio di token in staking degli utenti.

Poll

Le nuove proposte di governance di Nebula sono chiamate “poll”. Chiunque può creare un poll pagando un deposito iniziale di token NEB. Se il poll non raggiunge il quorum, il deposito in NEB viene distribuito agli staker di NEB proporzionalmente alla quantità di token in staking.

I poll consistono in descrizioni testuali della proposta (con eventualmente link a risorse/discussioni esterne) e includono un messaggio eseguibile che codifica le istruzioni da eseguire in caso di accettazione. Il messaggio viene eseguito con i privilegi del Gov contract di Nebula, che ha il potere di richiamare ogni funzione definita da altri smart contract del protocollo.

Una volta sottoposti, la community può esprimere il proprio voto sino al termine del periodo di voto. In caso di raggiungimento del quorum e delle condizioni relative alla soglia (descritte in seguito), il poll viene ratificato e i suoi contenuti vengono automaticamente applicati dopo un determinato periodo di tempo. Questi cambiamenti entrano in vigore senza che si debba aggiornare il core dei contract di Nebula Protocol.

Nota: i token NEB in staking utilizzati per i poll in corso non possono essere prelevati fino al termine del periodo di voto. Inoltre, il numero di NEB utilizzati in una proposal non può essere modificato una volta che è stato espresso il proprio voto.

Procedura

Viene creato un nuovo poll con un deposito iniziale che corrisponde al proposal_deposit.
Il poll entra nella fase di voto. Gli utenti con NEB in staking possono votare sì, no o astenersi e possono decidere quanti NEB utilizzare per votare.
Il periodo di voto termina dopo che è stato creato un determinato numero di blocchi (voting_period).
I voti vengono contati e vengono accettati se vengono raggiunti il quorum (partecipazione minima dei NEB in staking) e la soglia (rapporto minimo tra i sì e i no).
Se il poll viene accettato, i suoi contenuti vengono eseguiti al termine di effective_delay blocchi, altrimenti scade automaticamente e non è più considerato valido.
Se il poll viene accettato, il deposit_amount viene restituito al creatore del poll. In caso contrario, viene trattenuto nel contract della governance e ripartito tra gli staker di NEB.

Se avete apprezzato la traduzione di questo articolo e volete rimanere aggiornati su tutte le novità dell’ecosistema Terra, potete seguirmi qui su Medium e su Twitter. Non dimenticatevi di lasciare un clap e di seguire anche Terra Network Italia su Twitter e qui su Medium, dove troverete tantissimi altri articoli, traduzioni, tutorial e news. Grazie per la lettura e per il supporto!