12188 | Terra Classic Market Module 2.0 (versione senza zecca)

Fonte da:

• https://validator.info/terra-classic/governance/12188
• https://github.com/Market-Module-2-0/proposal/blob/main/proposal-nomint.md

Il modulo di mercato Terra Classic 2.0

Versione senza menta

Un motore di deflazione netta che può aprirsi senza ipermetropie, che si autoalimenta quando l’offerta si riduce e che non può essere ingannato da prezzi stantii.

Si basa sulla bozza originale di “Terra Classic Market-Module 2.0“, ma incorpora dei meccanismi per evitare il mint/burn, che ha suscitato le preoccupazioni di diversi membri della comunità.

Se vuoi un breve riepilogo non tecnico, vai all’Appendice 1 (Riepilogo) e all’Appendice 2 (Domande e Risposte).

---

1. Contesto e obiettivi

Il 2022 ha insegnato due dure lezioni:

• La capacità illimitata uccide: l’aumento del pool_base e l’accorciamento del periodo di recupero del pool (PRP) permettono ai trader di guadagnare più velocemente di quanto il mercato possa assorbire, distruggendo la LUNC.
• L‘ancoraggio a 1 dollaro è letale: valutare gli UST a 1 dollaro mentre venivano scambiati a pochi centesimi costringeva all’iperinflazione.

Oggi ( 25 giugno 2025 ) ci troviamo con circa 6,50 T LUNC e 6 B USTC; i consumi sono appena ≈ 1,3 B LUNC / mese (0,02 %). La comunità vuole che il modulo di mercato (MM) torni al più presto per ripristinare il flusso di utenze e tariffe, ma non accetterà che una continua diminuzione dell’offerta netta.

---

2. Come il modulo di mercato storicamente coniato

2.1 base_pool – la “riserva virtuale di SDR”

Quando scambi USTC → LUNC (o viceversa), il modulo finge di interagire con un pool SDR virtuale. Il calcolo effettivo prevede:

1. Convertire l’importo USTC nel suo valore SDR utilizzando i prezzi correnti di Oracle.
2. Determinare la quantità di LUNC da coniare in modo che la curva costante-prodotto virtuale rimanga bilanciata
3. Aggiornamento del “debito” SDR creato dallo swap

Semplificando, quando scambi USTC → LUNC il modulo si presenta come un AMM SDR/LUNC il cui lato è un pool virtuale di dimensione base_pool:

ΔLUNC_out ≈ ( SDR_spent / SDR_pool_after ) × LUNC_pool_before

Un pool di base più ampio consente a un singolo swap di fornire più LUNC prima che il prezzo si muova.

2.2 PRP – il timer di ricarica

Dopo uno swap, il modulo ricorda un deficit d di SDR (quanto si è svuotato il pool virtuale di SDR). Ad ogni blocco “ricarica” una frazione fissa:

d_next = d_current × ( 1 – 1 / PRP )

Ogni blocco ripristina 1/PRP del deficit. Quindi:

• PRP breve → ricarica veloce → può essere stampato di nuovo pochi minuti dopo
• PRP lungo → ricarica lenta → bisogna aspettare ore o giorni

La capacità totale di scambio al giorno (se i commercianti la svuotano completamente ogni volta) è approssimativamente:

swap_cap_day ≈ 2 × base_pool / ( PRP / 14 400 )
(14 400 ≈ blocchi al giorno su Terra Classic).

Questa formula deriva dalla quantità di SDR che può essere esaurita e ricaricata al giorno mantenendo gli swap fattibili.

---

3. Approccio senza mentalizzazione (basato sull’epoch)

Attualmente la tassa di combustione sulla catena viene suddivisa per il 10% nel Community Pool, per il 10% nell’Oracle Pool e per l’80% nella combustione.
Per evitare il conio di token, si propone di reindirizzare il 60% in un pool temporaneo di “liquidità del modulo di mercato”. Sebbene questo riduca il consumo immediato della tassa al 20%, ogni 30 giorni si verificheranno altri consumi (vedi sotto).

Al primo blocco H₀ di ogni periodo di 30 giorni, per ogni token separatamente (USTC e LUNC):

• Ogni token (USTC e LUNC) che ha raggiunto il pool di liquidità del modulo di mercato viene spostato in un pool di swap distinto per il modulo di mercato. Questo è l’ammontare di quel token disponibile per gli utenti per lo swap.
• Si tratta dell’equivalente del 75% delle tasse bruciate il mese scorso per ogni gettone.
• Invece di usare il conio e la combustione quando si scambia attraverso il modulo del mercato, i gettoni vengono semplicemente presi e aggiunti a questo pool.
• All’inizio del periodo successivo di 30 giorni, tutti i residui nelle vasche vengono bruciati.

---

4. Base_pool e PRP adattativi per l’epoca

Vogliamo le esplosioni quando la volatilità sale, ma dobbiamo comunque rientrare nella quota mensile.

4.1 Scegliere un fattore di esplosione

Default F = 0,07 → in un solo giorno può essere utilizzato al massimo il 10% del saldo corrente del pool di liquidità.

cap. giornaliero desiderato = pool_balance × F

4.2 Risolvere per base_pool

Riorganizzazione della formula del tappo giornaliero:

base_pool_raw = desired_daily_cap × PRP / ( 2 × 14 400 )

4.3 PRP a scala di fornitura

PRP = max( 14 400 , 14 400 × ( S / 1 T ) )

6,5 T di fornitura → PRP ≈ 93 600 blocchi (6,5 giorni).
Quando l’offerta diminuisce, la ricarica diventa più veloce: il rubinetto si restringe mentre il serbatoio si svuota.

4.4 Morsetti finali

base_pool = min( base_pool_raw, 0.00010 × supply_value_in_SDR, 5 000 000 SDR ) // tetto assoluto

---

Esempio per la prima epoca (oggi)

Articolo	Valore
tax_30d (B₀)	1,0 B LUNC
reindirizzato alla piscina = 0,6 × B₀	600M LUNC ≈ 24.400 SDR
PRP (fornitura di 6,5 T)	93 600 blocchi
cap_giornaliero_desiderato (ad esempio F = 0,1)	60M LUNC (a seconda del saldo attuale)
base_pool_raw	≈ 7,9 k SDR
base_piscina dopo i morsetti	7,9 k SDR
Utilizzo della piscina al giorno (max)	2 × 7,9 k / 6,5 ≈ 2,45 k SDR ≈ 60,4 M LUNC

60,4 M > 60 M, quindi F, non la pinza PRP, è il freno attivo.

---

5. Ingresso dei prezzi in tempo reale e protezioni anti-manipolazione

Componente	Regola
Periodo di votazione del prezzo	5 blocchi ≈ 30 s
Prezzo USTC	prezzo_uusd(USTC) = mediana ponderata per il potere di voto in questo periodo
Auto-uccisione del quorum	Se una delle due attività ha un prezzo di voto < 50 % VP per 25 blocchi → MM.enabled=false fino al ripristino del quorum
Pinza di sicurezza TWAP	Ogni swap fallisce se il prezzo del peg differisce > 10 % da un Oracle-TWAP a 45 blocchi (alimentato dagli stessi oracoli)
Percorso stabile→stabile	Disattivato nel codice (ErrStableSwapDisabled)

---

6. Freni assoluti e governance

• La super-maggioranza può chiudere la MM in qualsiasi momento.

---

7. Bruciature

Al termine dei 30 giorni, tutte le rimanenze del pool vengono bruciate. A seconda del comportamento di swap degli utenti, questa operazione può essere simile a quella che si sarebbe verificata senza questo approccio, oppure più vicina a uno dei due token (vedi riepilogo nell’Appendice 1).

---

8. Scenari

8.1 Toro-pieno (ritorni di utilità)

Esempio che mostra calcoli separati per entrambi i token:

LUNC in uno scenario di crescita normale

• I proventi fiscali di LUNC raggiungono i 2 miliardi di euro al mese entro l’epoca 3, mentre i proventi di USTC raggiungono i 560 mila euro al mese.
• PRP ancora > 3 giorni, base_pool limitata dalla franchigia.

Scenario a.) Gli utenti si scambiano equamente tra LUNC e USTC.

Epoca	Tassa LUNC	Imposta USTC	Piscina LUNC prima	Piscina USTC prima	Piscina LUNC dopo	Piscina USTC dopo
1	1.3 B	360 K	720 M	216 K	720 M	216 K
2	1.6 B	450 K	840 M	270 K	840 M	270 K
3	2.0 B	560 K	1.20 B	336 K	1.20 B	336 K
Bruciato					2.76B	822 K

In questo scenario, vengono bruciate le stesse quantità di LUNC e USTC che vengono bruciate senza la MM aperta.

Scenario b.) Gli utenti scambiano principalmente (80%) da USTC a LUNC, con un prezzo ipotizzato per semplicità: 200 LUNC/USTC (in realtà, questo prezzo sarebbe fluttuante).

Epoca	Tassa LUNC	Imposta USTC	Piscina LUNC prima	Piscina USTC prima	Piscina LUNC dopo	Piscina USTC dopo
1	1.3 B	360 K	720 M	216 K	144 M	3.1 M
2	1.6 B	450 K	840 M	270 K	168 M	3.63 M
3	2.0 B	560 K	1.20 B	336 K	240 M	5.14 M
Bruciato					552 M	11.87 M

In questo scenario, verrebbero bruciati 2,2 B LUNC in meno rispetto a quando la MM è aperta. A sua volta, verrebbero bruciati 11 M USTC in più.

Scenario c.) Gli utenti scambiano principalmente (80%) da LUNC a USTC, prezzo ipotizzato per semplicità: 200 LUNC/USTC (in realtà, questo prezzo potrebbe fluttuare).

Epoca	Tassa LUNC	Imposta USTC	Piscina LUNC prima	Piscina USTC prima	Piscina LUNC dopo	Piscina USTC dopo
1	1.3 B	360 K	720 M	216 K	754.5 M	43.2 K
2	1.6 B	450 K	840 M	270 K	882 M	54 K
3	2.0 B	560 K	1.20 B	336 K	1.254 B	67.2 K
Bruciato					2.89 B	164.4 K

In questo scenario, si brucerebbero 130 M LUNC in più rispetto a quando la MM non è aperta. A sua volta, verrebbero bruciati 660 K USTC in meno.

8.2 Flash-crash e interruzione di oracolo

• USTC crolla a $0,004 (80 LUNC/USTC); due validatori top offline.
• Dopo 30 s il quorum < 50 % → MM si chiude.
• I proventi fiscali crollano per entrambi i token nell’epoca successiva.

LUNC in uno scenario di crisi

• Il gettito fiscale di LUNC crolla a 0,2 miliardi al mese.
• I proventi dell’imposta USTC crollano a 56 K/mese

Scenario a.) Gli utenti si scambiano equamente tra LUNC e USTC.

Epoca	Tassa LUNC	Imposta USTC	Piscina LUNC prima	Piscina USTC prima	Piscina LUNC dopo	Piscina USTC dopo
1	0.2 B	56 K	120 M	33.6 K	120 M	33.6 K
2	0.2 B*	56 K	120 M	33.6 K	120 M	33.6 K
3	0.2 B	56 K	120 M	33.6 K	120 M	33.6 K
Bruciato					360 M	100.8 K

In questo scenario, vengono bruciate le stesse quantità di LUNC e USTC che vengono bruciate senza la MM aperta.

(*) MM viene interrotto a metà di questa epoca a causa di un’interruzione dell’oracolo e non viene più ripreso. Da quel momento in poi non si verificano più scambi

Scenario b.) Gli utenti scambiano principalmente (80%) da USTC a LUNC, prezzo ipotizzato per semplicità: 80 LUNC/USTC (come definito nello scenario di incidente).

Epoca	Tassa LUNC	Imposta USTC	Piscina LUNC prima	Piscina USTC prima	Piscina LUNC dopo	Piscina USTC dopo
1	0.2 B	56 K	120 M	33.6 K	24 M	1.2 M
2	0.2 B*	56 K	120 M	33.6 K	48 M	900 M
3	0.2 B	56 K	120 M	33.6 K	120 M	33.6 K
Bruciato					192 M	2.13 M

In questo scenario, verrebbero bruciati 150 M LUNC in meno rispetto a quando la MM non è aperta. A sua volta, verrebbero bruciati 2 M USTC in più.

(*) MM viene interrotto a metà di questa epoca a causa di un’interruzione dell’oracolo e non viene più ripreso. Da quel momento in poi non vengono effettuati altri scambi.

Scenario c.) Gli utenti scambiano principalmente (80%) da USTC a LUNC, prezzo ipotizzato per semplicità: 80 LUNC/USTC (come definito nello scenario di incidente).

Tralasciamo questo scenario perché sarebbe improbabile che le persone passino da LUNC a USTC in un’ipotetica caduta dei prezzi di USTC.

Anche in caso di disastro, il galleggiante continua a ridursi per entrambi i token in modo indipendente.

---

9. Politica di spread-fee per gli swap MM

Condizioni	Tassa applicata	Note
MM disattivato (senza scambi)	—	Nessuna tassa, nessuna combustione; il percorso è inerte.
MM abilitato e indennità > 0	0,35% del nozionale	Raccolta nell’asset di uscita (LUNC su scambi USTC→LUNC, USTC su LUNC→USTC).
Indennità esaurita (tetto massimo dell’epoca)	—	Lo scambio viene rifiutato; nessuna tassa, nessuna bruciatura.

Motivazione

• Livello fattibile – Lo 0,35% è abbastanza basso da mantenere l’arbitraggio redditizio rispetto ai tipici spread del CEX (≈ 0,10 – 0,25%), pur recuperando i costi dell’oracolo e del guardiano.
• Nessuna doppia tassazione – La tassa sulle scottature dello 0,50% a livello di catena non si applica a questi swap in-modulo; la commissione sullo spread la sostituisce.
• Contabilità – Le tariffe vengono indirizzate per il 50% alla masterizzazione e per il 50% al pool Oracle.
• Percorso da stabile a stabile – Disattivato completamente (§ 4.4), in modo che la commissione si applichi sempre e solo alle compravendite LUNC ↔ USTC.

---

10. Compatibilità del modulo Oracle

La riattivazione del MM con prezzi dinamici richiede l’aggiornamento dell’attuale infrastruttura di Oracle:

1. Alimentazione del prezzo USTC – USTC deve essere aggiunto alla serie di voti dell’oracolo. Il MM attualmente assume un prezzo fisso di 1 dollaro; questa logica deve essere rimossa e sostituita con l’inserimento del prezzo in tempo reale da parte dei validatori.
2. Espansione del fornitore di dati – Il fornitore esistente supporta fonti limitate. Per garantire prezzi accurati e resistenti alle manipolazioni, è necessario integrare altri fornitori di dati (ad esempio, CEX multipli, aggregatori).
3. Messa a bordo dei validatori – Tutti i validatori devono essere guidati nell’aggiornamento dei binari e delle configurazioni dei loro feeder oracle per supportare USTC. La documentazione e il coordinamento del rollout saranno necessari per evitare cadute del quorum.
4. (Opzionale) Revisione dell’alimentatore – Una riscrittura completa del binario dell’alimentatore non è strettamente necessaria, ma è fortemente consigliata. L’alimentatore attuale è obsoleto e non supporta le API moderne, la logica di fallback e la corretta gestione degli errori.

Queste modifiche devono essere implementate prima della riapertura del MM. Senza di esse, i prezzi immessi non saranno validi o saranno assenti, innescando i meccanismi di spegnimento automatico.

---

11. Tabella di marcia

1. Code merge for testnet & review – ≈ 500-1000 Linee di Codice (logica del pool, manopole adattive, kill-switch).
2. Testnet pubblica – inietta picchi di prezzo, cadute del quorum, esplosioni di combustione 10×.
3. Aggiornamento di Mainnet (in due fasi)

• Distribuisci il modulo inattivo
• Si attiva al limite dell’epoca successiva dopo che il pool si è riempito durante l’epoca.

1. 90 giorni post-mortem – modifica del 60% di reindirizzamento o F solo tramite hard fork (aggiornamento della catena).

---

12. Cosa otteniamo

• Riapertura immediata: i trader possono fare arbitraggio il primo giorno.
• Deflazione garantita: l’offerta deve comunque diminuire ogni 30 giorni.
• Acceleratore elastico: quando l’offerta si contrae, la ricarica rallenta e il pool si riduce.
• Oracle-safe – 30 s di ritardo non possono gonfiare; 75 s di ritardo uccidono il modulo.
• Ricarica dell’Oracle-Pool – le commissioni di diffusione del modulo di mercato vengono reindirizzate all’Oracle Pool per ricompense future (50%)
• Bruciature – il 50% della quota di diffusione è bruciato

---

13. Bruciature volontarie

In questo momento, gran parte dell’offerta bruciata proviene da combustioni volontarie (monete inviate al modulo di combustione della catena – terra1…anxu).

Questi fondi dovrebbero essere esclusi dal calcolo dell’epoch burns di 30 giorni per evitare di perdere il supporto di enti come Binance e dei membri della comunità. Questo restringerà i possibili token disponibili. Se necessario, si dovrebbe prendere in considerazione la possibilità di estendere i pool, ma questo dovrà essere discusso con le entità interessate una volta che il concetto generale sarà stato implementato e testato.

---

14. Note importanti

Non è possibile prevedere l’importo delle tasse per i prossimi mesi, quindi l’impatto sul piano MM si basa su ipotesi. I parametri e i meccanismi possono e devono essere modificati durante la fase di testnet pubblica ed è importante testare a fondo l’impatto e i meccanismi sulla testnet prima di considerare un rilascio sulla mainnet.

Si tratta di una proposta che segnala la volontà della governance e della comunità di vedere implementato questo approccio. L’implementazione sarà uno sforzo/contributo volontario di StrathCole, quindi non ci sono scadenze fisse. Un’opzione alternativa è che un team retribuito decida di farsi avanti e di proporre il lavoro, ottenendo l’approvazione della governance. Questo potrebbe accelerare i tempi di implementazione.

---

15. Rischi

Il rischio di iperinflazione è mitigato dall’utilizzo dei soli fondi reindirizzati in un pool distinto dai proventi fiscali del periodo precedente. In questo modo il conio di MM viene disattivato.

I rischi principali di questa implementazione sono:

• bruciature ridotte di LUNC o USTC (non di entrambi) nel caso in cui lo swapping venga utilizzato solo raramente e in modo unilaterale
• delusione della comunità per le aspettative non soddisfatte

---

Appendice 1: Riepilogo non tecnologico

Per riassumere l’idea in termini non tecnici, possiamo descriverla come segue:

Importante: questa NON è una proposta di repeg e NON tratta l’USTC come un’attività stabile.

Implementeremo delle misure di salvaguardia per il modulo di mercato, in modo che non venga modificato per gli swap. Siamo consapevoli che questo si discosta dal concetto originale del MM. Il 60% dei proventi della tassa sulle bruciature (NON le bruciature manuali da parte dei portafogli) viene reindirizzato al pool di swap del MM per il periodo successivo.

Il prezzo di USTC sarà riportato dall’oracolo della catena e non sarà più fissato internamente a 1 dollaro. Questo permette di scambiare al valore reale di mercato, fornendo la quantità corretta o LUNC per USTC e viceversa.

Quando si scambia USTC con LUNC, LUNC viene fornito dal pool MM e l’utente dà USTC al pool a sua volta. Quando si scambia LUNC con USTC, USTC viene fornito dal pool e LUNC viene restituito dall’utente. Questo non è esattamente il modo in cui il modulo di mercato funzionava all’inizio (conio e bruciatura), ma mantiene la logica per i calcoli. Il conio viene sostituito dall’utilizzo di un pool pre-riempito.

La commissione di ogni swap (che non include la tassa, ma lo 0,35% di commissione di spread) sarà distribuita 50%:50% tra Burns e Oracle Pool.

Gli incentivi all’utilizzo del MM per lo swap potrebbero essere le opzioni di arbitraggio tra i prezzi CEX, i prezzi DEX e il Modulo di Mercato. Questo accade perché il prezzo on chain dell’oracolo viene aggiornato solo ogni 30 secondi, il che significa che spesso è in ritardo rispetto ai prezzi CEX. Anche i prezzi dei DEX si discostano spesso tra loro e con i CEX, il che offre un ulteriore potenziale di arbitraggio.

Inoltre, l’utilizzo del MM per lo swap potrebbe essere un incentivo per gli utenti che desiderano provocare la bruciatura di un lato (LUNC o USTC) attraverso i loro swap (vedi i meccanismi di bruciatura del pool mensile).

La maggior parte dei rischi è mitigata dalle misure di salvaguardia. Tuttavia, c’è il rischio che la comunità rimanga delusa se si aspetta un effetto di queste misure superiore a quello ottenuto. Inoltre è possibile che le combustioni siano inferiori a quelle previste, nel caso in cui gli utenti utilizzino esclusivamente il MM per scambiare USTC con LUNC fino all’esaurimento del bacino, ma questo avrebbe a sua volta il vantaggio di aumentare le combustioni di USTC.

---

Appendice 2: Domande e risposte

D: Questo può causare un’ulteriore iperinflazione LUNC?
R: No. Il conio viene evitato negli swap, il LUNC disponibile è limitato all’importo del pool, basato sui proventi fiscali del periodo precedente.

D: Si tratta di un re-pegging USTC?
R: No. L’USTC è un asset speculativo e questa idea lo tratta come tale. Viene valutato al prezzo di mercato per gli swap.

D: E per quanto riguarda le emissioni di Binance? Hanno smesso di bruciare quando abbiamo coniato in precedenza.
R: Con questo approccio evitiamo completamente il conio. Sebbene inizialmente si verifichino bruciature inferiori quando reindirizziamo parte delle tasse al pool di swap, tutti i saldi rimanenti del pool vengono bruciati alla fine del periodo.

D: Cos’è il “pool di swap MM”?
R: È l’importo di LUNC e USTC che può essere utilizzato negli swap durante un periodo. L’importo effettivamente scambiato può essere più alto, perché il saldo aumenta di nuovo con gli swap verso l’altra parte.

Q: ??? Posso avere un esempio?
R: Certo: immagina che 1 USTC valga 200 LUNC. Nel periodo precedente abbiamo avuto un gettito fiscale di 667 milioni di LUNC. Con un tasso del 60%, questo riempirebbe il pool di swap MM con 400 milioni di LUNC per il periodo successivo. Quindi, se ora 2.000.000 di USTC vengono scambiati con LUNC attraverso il MM, l’utente riceverà a sua volta 400 milioni di LUNC dal pool, disabilitando di fatto ulteriori scambi in quella direzione. Ma se ora gli swap avvengono da LUNC a USTC (ad esempio 100M LUNC per 500.000 USTC), questi 100M LUNC saranno nuovamente disponibili per lo swap.

D: Ma questo non ridurrebbe significativamente le ustioni nel complesso, se la quantità viene reindirizzata alla piscina?
R: No. Tutti i saldi rimanenti nel pool verrebbero bruciati all’inizio dell’epoca successiva. Dipende dal comportamento dello swap se vengono bruciati più LUNC e meno USTC o più USTC e meno LUNC.

D: Ma allora non è inutile?
R: No, ogni swap comporta una commissione dello 0,35% che viene distribuita a Burn (50%) e Oracle Pool (50%). Più scambi ci sono e più spesso avvengono, più commissioni vengono generate.

D: Ok, ma che quantità di scambi possiamo aspettarci? Non è possibile che tutti scambino solo le ricompense USTC con LUNC?
R: Potrebbe accadere, ma anche in questo caso l’offerta di USTC diminuirebbe. Tuttavia, se si osserva il rapporto LUNC/USTC negli ultimi mesi, ci si rende conto che il valore è oscillato per lo più tra 190 e 230 LUNC per USTC. Questo suggerisce che le persone utilizzano entrambe le direzioni negli scambi.

D: Bene, che volume possiamo aspettarci allora?
R: È molto difficile da stimare e dipende dal volume della catena e dall’arbitraggio. Le coppie LUNC/USTC sui nostri DEX hanno avuto di recente un volume di circa 120-130k USD al mese. Supponendo che questo volume venga suddiviso in parti uguali tra i DEX e il MM, questo porterebbe a un volume del MM di circa 30-40k USD.

D: Ma hai detto che USTC è valutata al valore di mercato. Come sarebbe possibile un arbitraggio?
R: I prezzi dell’oracolo della catena vengono comunicati ogni 30 secondi. Soprattutto in caso di alta volatilità, i prezzi del CEX possono fluttuare molto rapidamente. Anche i prezzi del DEX hanno mostrato una notevole volatilità negli ultimi mesi, il che potrebbe offrire opzioni di arbitraggio con il MM. Tuttavia non è garantito.

D: Quali sono i rischi principali? E come vengono mitigati?
R: Come detto, il rischio di iperinflazione è mitigato da limiti e confini molto rigidi. Il rischio di errori tecnici nell’implementazione sarà mitigato da una revisione approfondita e, se la comunità è disposta a pagare, da un audit del codice (che sarebbe consigliato). Nell’improbabile caso di un difetto grave, il 33,4% dei validatori potrebbe “bloccare in emergenza” la catena per ottenere un hotfix. Non si prevede che ciò sia necessario.

Il rischio più probabile è quello di avere aspettative troppo alte, che possono poi portare alla delusione.

Un altro rischio è quello di perdere una parte delle combustioni di LUNC nel caso in cui la MM venga utilizzata solo a senso unico (USTC->LUNC). L’equivalente di USTC verrebbe quindi bruciato in eccesso.

D: Chi lo sta sviluppando? È pronto? Quali sono le tempistiche?
R: Io (StrathCole) mi sto offrendo di sviluppare questo progetto volontariamente. Dato che lo faccio nel mio tempo libero, non c’è una tempistica fissa. Mi aspetto che l’implementazione pura e semplice (senza i test) richieda 2-3 settimane. C’è sempre l’opzione che un team possa fare un preventivo per il lavoro e ottenere l’approvazione della comunità per implementarlo.

D: Se lo fai volontariamente, perché hai bisogno di una proposta?
R: Perché non posso dedicare il tempo dello sviluppo senza una proposta di segnalazione che dimostri che questo approccio, così come mostrato, è voluto dalla comunità/governo. Ci sono state molte riserve sull’apertura del modulo di mercato. Quindi l’approvazione di questo modulo è un prerequisito per me per iniziare il lavoro di sviluppo su di esso.

D: Quanto dura il test?
R: Non è prevedibile. Poiché si tratta di una parte critica della blockchain, dobbiamo sottoporre questo approccio a stress-test in tutti i modi possibili. Questo include la simulazione della manipolazione dei prezzi, le interruzioni dell’alimentazione dell’oracolo, la volatilità dei prezzi, il volume degli scambi, ecc. Più persone parteciperanno ai test e alle verifiche, meglio sarà.

D: Dato che si è parlato di revisione/audit, non si tratta di lavoro gratuito?
R: No. Il team che si occupa della revisione, o la società di revisione che offre una revisione, richiederà sicuramente dei fondi per questo.

D: Cosa succede se vogliamo utilizzare il MM nella sua forma originale in un secondo momento?
R: Le modifiche saranno progettate in modo da essere il più possibile ridotte al minimo per quanto riguarda il passaggio dall’approccio “menta/brucia” a quello “piscina”. È possibile ripristinare l’uso del MM in un secondo momento, includendo il meccanismo di estrazione/scambio.