> ## Documentation Index
> Fetch the complete documentation index at: https://docs.intention.xyz/llms.txt
> Use this file to discover all available pages before exploring further.
# Modifiche alle regole
> Come cambiano le regole di trading, i parametri di rischio e il comportamento del protocollo: preavvisi, altezze di blocco di efficacia e perché le regole di un blocco passato non si possono riscrivere.
A una rete attiva arrivano tre tipi di modifica: le **modifiche di parametro** (un limite di rischio, una tabella commissionale, un tetto di funding), le **modifiche di comportamento** (come funziona l'esecuzione stessa) e le **modifiche di mercato** ([quotazioni e revoche](/it/programs/listings)).
Si annunciano in modi diversi. Condividono una proprietà, ed è quella che conta: una modifica prende effetto in un **punto preciso della storia della catena**, e la storia precedente a quel punto non viene toccata.
Modifiche di parametro
I parametri di rischio, i livelli di leva, i tetti di funding, i limiti di posizione e le tabelle commissionali sono configurazione on-chain. Cambiarne uno è una transazione di protocollo che si esegue in un blocco, in cima alla [priorità di blocco](/it/trading/tx-sequencing).
Poiché il valore è stato della catena, la modifica si osserva direttamente, non viene comunicata. Non c'è bisogno che qualcuno ti dica che il margine di mantenimento su un mercato si è spostato: puoi leggere quanto vale, e puoi leggere quanto valeva a qualsiasi blocco passato.
Le chiavi di configurazione sono inoltre **versionate**. Quando cambia la forma di un valore e non il suo numero, la nuova forma viene scritta sotto una nuova chiave e la vecchia resta leggibile. Un client che risolve la configurazione dal vivo continua a funzionare anche dopo la modifica; un client che ha scritto nel codice un percorso di chiave se ne accorge subito, invece di leggere in silenzio qualcosa di stantio. Vedi [Modello dello stato](/it/protocol/architecture/state/model).
Modifiche di comportamento
Cambiare *come si comporta* l'esecuzione è un problema più difficile che cambiare un numero, perché ogni validatore deve fare il cambio esattamente nello stesso istante. Una modifica che arriva a nodi diversi in momenti diversi non è un rilascio graduale: è un fork.
Intention lo gestisce con i **gate on-chain** (gli interruttori on-chain che abilitano una funzionalità). Ogni gate è una singola chiave di stato che contiene un'altezza di blocco: l'altezza a cui inizia il nuovo comportamento.
Nuovo comportamento inattivonel binario, non attivo
Si scrive un gateuna chiave di stato con un'altezza futura
Ogni validatore legge la stessa altezza
Cambia esattamente a quel blocco
L'altezza deve essere nel futuroUn gate non può essere impostato a un'altezza già passata. È questa singola regola a rendere la modifica simultanea.
Gate assente significa inattivoUn nodo che riesegue la storia non trova chiavi a quelle altezze e prende il vecchio percorso, quindi resta corretto senza matrice di compatibilità.
Letto alla versione in esecuzioneMai da una cache. Leggere un valore corrente mentre si riesegue un vecchio blocco applicherebbe le regole di oggi alla storia di ieri.
Ne discendono tre proprietà, e ciascuna è portante:
**L'altezza deve essere nel futuro quando viene scritta.** Un gate non può essere impostato a un'altezza già passata. È questa singola regola a rendere la modifica simultanea: ogni validatore arriva a quel blocco con la stessa chiave già visibile.
**Un gate assente significa inattivo.** Un nodo che riesegue la storia non legge alcuna chiave a quelle altezze e prende esattamente il vecchio percorso di codice. Il replay storico resta corretto gratis, senza che nessuno debba mantenere una matrice di compatibilità.
**Il gate viene letto alla versione che si sta eseguendo, mai da una cache.** Leggere un valore corrente mentre si riesegue un vecchio blocco applicherebbe le regole di oggi alla storia di ieri e produrrebbe una radice dello stato diversa. Quindi il valore viene letto sempre dalla vista di esecuzione del blocco in corso.
Lo stesso meccanismo consente un'abilitazione graduale: un flag può essere introdotto inattivo, verificato sul traffico reale e acceso a un'altezza programmata, anziché rilasciato come un aggiornamento binario tutto in una volta.
Periodi di preavviso
Il preavviso è proporzionale a ciò che una modifica può fare a una posizione che hai già.
| Modifica | Preavviso |
| -------------------------------------------------------------------------------------------------------------- | ---------------------------------------------------------------- |
| **Tocca le posizioni aperte** — requisiti di margine, livelli di leva, tetti di funding, revoche di quotazione | Annunciata prima della data di efficacia, con la data dichiarata |
| **Tocca le integrazioni** — interfaccia API, forma dei messaggi, disposizione delle chiavi | Annunciata in anticipo, con un percorso di migrazione |
| **Tocca solo il costo** — tabelle commissionali, livelli di rebate | Annunciata prima della data di efficacia |
| **Corregge un rischio in corso** — un parametro reso più stringente in risposta a una condizione di mercato | Può prendere effetto immediatamente |
L'ultima riga è un'eccezione vera, non una scappatoia. Un limite di posizione che deve aspettare una settimana per stringersi è un limite di posizione che non fa nulla proprio nella settimana in cui serviva. Quando viene usata, la modifica e il motivo vengono pubblicati insieme.
Una modifica ai requisiti di margine o ai livelli di leva cambia il prezzo di liquidazione sulle posizioni che hai già. Non chiude nulla e non ti avvisa individualmente. Se tieni posizioni aperte durante una modifica annunciata dei parametri di rischio, ricalcola la distanza dalla liquidazione sui nuovi valori, non su quelli in vigore quando hai aperto. Vedi [Leva](/it/trading/leverage).
Che cosa non può cambiare
Le regole che si applicavano a un blocco già committato.
Ogni modifica di regola prende effetto a un'altezza che era nel futuro quando è stata registrata, quindi rieseguire un vecchio blocco applica sempre le regole attive allora. Sapere se una data regola fosse in vigore a una certa versione passata è una domanda che ha una sola risposta, la stessa oggi e fra un anno.
È una garanzia più forte di una policy pubblicata. Non è che il protocollo *non voglia* riscrivere la storia: è che il meccanismo non ha alcuna rappresentazione per una regola iniziata nel passato. Vedi [Modello dello stato](/it/protocol/architecture/state/model).
Annunci
Gli impegni di preavviso di questa pagina iniziano con la **testnet pubblica il 20 settembre 2026**. La [testnet privata](/it/protocol/architecture/network-status) cambia parametri e comportamento senza preavviso: esiste proprio per tararli.
Una volta iniziati i periodi di preavviso, ogni modifica viene registrata nel [changelog del protocollo](/it/protocol/roadmap/changelog) con la data in cui ha preso effetto, e annunciata prima di quella data quando la tabella qui sopra lo richiede.
Le voci sono datate in base a **quando la modifica ha preso effetto sulla rete**, non a quando è stata annunciata.
Dove proseguire
Il registro datato di ciò che è stato rilasciato.
Le modifiche di mercato e i loro periodi di preavviso.
Perché le chiavi di configurazione sono versionate e risolte dal vivo.
Che cosa fa una modifica dei parametri di rischio a una posizione aperta.