Polkadot

Polkadot è un protocollo di rete multi-chain che collega molte blockchain specializzate (“parachain”) a una Relay Chain centrale. La Relay Chain fornisce sicurezza condivisa, consenso e interoperabilità cross-chain, mentre le parachain operano in parallelo e comunicano usando il cross-consensus messaging (XCM) di Polkadot. Il design punta a fornire scalabilità e componibilità tra le chain all’interno di una sola rete.

Nell’architettura di Polkadot, le parachain sono chain applicative specifiche i cui blocchi sono prodotti dai collatori e verificati dai validatori della Relay Chain. Collegandosi alla Relay Chain, le parachain ereditano la sicurezza economica del set dei validatori e possono scambiare messaggi con altre chain tramite XCM. I bridge possono collegare anche Polkadot a reti esterne—ad esempio, Ethereum tramite Snowbridge; la connettività con Bitcoin è garantita da parachain come Interlay piuttosto che da un bridge native light-client. Per dettagli operativi sulla messaggistica cross-chain, vedi la sezione dedicata a XCM.

DOT è il token nativo della rete sulla Relay Chain. Nella specifica di Polkadot svolge tre funzioni principali: governance del protocollo, staking per la sicurezza della rete e bonding (il meccanismo storicamente usato per aggiungere chain).

Il modello di risorse di Polkadot sta evolvendo con “Polkadot 2.0”. Invece di affittare slot a lungo termine, i progetti accedono al calcolo della Relay Chain tramite coretime (tempo sui core virtuali). Il coretime è assegnato alle system chain tramite governance e acquistato dalle altre chain sul mercato aperto.

DOT è il token nativo della Relay Chain di Polkadot. Sostiene le principali funzioni della rete:

Sicurezza della rete tramite staking (NPoS): I possessori di DOT possono nominare validatori o gestire un validatore per contribuire a finalizzare i blocchi e mantenere la rete onesta. I DOT messi in staking supportano il comportamento del validatore e guadagnano ricompense; comportamenti scorretti possono essere penalizzati (slashing). Vedi: Nominated Proof-of-Stake e Slashing per meccanismi e rischi.

Governance on-chain (OpenGov): DOT è usato per proporre e votare referendum su diversi "track", delegare potere di voto e partecipare ad aggiornamenti del protocollo e decisioni sulle system chain. Vedi: OpenGov e Come possono gli utenti partecipare alla governance… per dettagli su track, depositi e deleghe.

Commissioni di rete e depositi richiesti: Le transazioni sulla Relay Chain consumano commissioni pagate in DOT, e i conti devono mantenere un saldo minimo (existential deposit) per restare attivi. Alcune azioni on-chain richiedono anche depositi rimborsabili in DOT (es: identità). Vedi: Quali sono le utilità on-chain di DOT… per tipi di commissioni e depositi.

Acquisizione di coretime della Relay Chain in Polkadot 2.0: I progetti ottengono tempo di esecuzione sui core della Relay Chain acquistando coretime con DOT; questi DOT vengono bruciati. Questo modello sostituisce gli affitti slot a lungo termine/crowdloan. Vedi: Cosa cambia con Polkadot 2.0… e Come può un team lanciare una chain… per economia e percorsi di deploy.

Finanziamento del sistema tramite la Treasury on-chain: Gli afflussi alla Treasury (parte delle ricompense di blocco, commissioni, tip, slashing) sono denominati in DOT e possono essere spesi—tramite governance—su proposte approvate. Vedi: Come funziona la Treasury on-chain… per processi e ambiti.

Movimenti cross-chain e utilizzo nell’ecosistema: DOT può essere teletrasportato tra la Relay Chain e system parachain come Asset Hub tramite XCM; i trasferimenti cross-chain possono comportare commissioni sia sulla chain sorgente che su quella destinazione. Alcune parachain/app accettano DOT nativamente; altre richiedono rappresentazioni bridge/wrapped. Vedi: Asset Hub e Come DOT interagisce con altre reti… per dettagli e avvertenze.

Se cerchi il modello specifico di commissioni, minimi, depositi e i flussi di staking, continua con “Quali sono le utilità on-chain di DOT (staking, commissioni, governance e depositi)?”

DOT usa un’emissione annuale fissa che è iniziata all’~8% dell’offerta all’attuazione e ora è costante a ~120 milioni DOT all’anno, causando la diminuzione della percentuale di inflazione col crescere dell’offerta totale. Di ogni emissione annuale, il 15% è coniato direttamente nella Treasury e l’85% finanzia le ricompense staking (pagate per era). Questi parametri sono stati introdotti da OpenGov (Referendum #1139) e implementati nel runtime code.

Cadenza di emissione e distribuzione: Nuovi DOT sono creati continuamente e contabilizzati alla fine di ogni era (~24 ore su Polkadot), poi distribuiti a validatori e nominatori in base al meccanismo di ricompensa staking; la quota del 15% della Treasury viene coniata direttamente sull’account di sistema della Treasury stessa. Con il modello a emissione fissa, questa suddivisione non è più regolata dalla partecipazione allo staking della rete, semplificando le ricompense rispetto al design precedente.

Burn che compensano l’emissione lorda: Due fonti riducono la crescita netta dell’offerta: gli acquisti di coretime (in Polkadot 2.0) sono bruciati, e la Treasury può anche bruciare fondi tramite governance. Di conseguenza, l’inflazione annuale effettiva è pari all’emissione fissa (~120M DOT) meno gli importi bruciati nell’anno.

Cosa cambia rispetto al modello precedente: Prima del cambiamento 2024, Polkadot puntava a circa il 10% di inflazione annua, con le ricompense adattate su un tasso di staking “ideale” e ogni differenza destinata alla Treasury (“staking inefficiency”). Il nuovo modello rimuove quell’aggiustamento e lo sostituisce con la quota Treasury fissa sopra citata.

Nessun hard cap (soggetto a governance): DOT non ha un’offerta massima integrata nel protocollo. I parametri di emissione possono essere modificati tramite governance on-chain; gli aggiornamenti 2024–2025 sono stati implementati tramite questo processo. Per impostazioni e proposte di modifica attive consulta i referendum OpenGov rilevanti.

Redenominazione 2020 (solo cambio unità): Il 21 agosto 2020 (“Denomination Day,” blocco #1.248.328), DOT è stato redenominato con rapporto 1 vecchio DOT = 100 nuovi DOT. Si è trattato di un cambio di unità, non di valore o possesso: i saldi e i prezzi sono stati scalati per 100×, e l’unità base (Planck) per DOT è passata da 10¹² a 10¹⁰ Planck. Le dinamiche economiche della rete sono rimaste invariate.

Staking (sicurezza della rete): DOT può essere vincolato (bonded) per proteggere la rete sotto Nominated Proof-of-Stake (NPoS). I possessori possono nominare validatori o farne funzionare uno; le ricompense sono pagate per era e comportamenti scorretti possono essere penalizzati (slashing). Il set dei validatori è eletto con algoritmi basati su Phragmén e gli utenti possono anche partecipare tramite nomination pool, un’opzione più semplice con importi inferiori. Meccaniche specifiche come tempi di unbonding, condizioni di slashing e dettagli dell’elezione sono trattati nelle sezioni NPoS e Slashing.

Commissioni (pagare le transazioni): Sulla Relay Chain, le transazioni pagano commissioni in DOT prelevate dal saldo trasferibile (non dai fondi bonded). Le commissioni comprendono una fee base, una fee per lunghezza e una fee sulla “weight” (peso dell’operazione), più un tip opzionale che può aumentare la priorità di inclusione; un moltiplicatore di congestione può aggiustare le commissioni in base al riempimento dei blocchi recenti. I wallet mostrano la stima della fee prima della firma.

Le azioni cross-chain possono comportare commissioni sia sulla chain sorgente sia sulla destinazione. Ad esempio, teletrasportare DOT tra la Relay Chain e Asset Hub comporta una commissione di destinazione e non applica la protezione "keep-alive", quindi il saldo deve rimanere sopra il minimo della chain di destinazione per evitare il "reaping".

Governance (OpenGov): DOT è usato per proporre e votare referendum tramite OpenGov. Le proposte richiedono un decision deposit; il voto usa bilanci ponderati per conviction (i token vengono bloccati per aumentare il peso del voto). Gli utenti possono anche delegare potere di voto, anche per singolo track. Le istruzioni operative (voto, delega, gestione dei lock) sono trattate nelle sezioni OpenGov.

Depositi e saldi minimi: Polkadot applica un existential deposit (ED)—un saldo libero minimo necessario per tenere un account attivo. Se il saldo libero scende sotto l’ED, l’account può essere cancellato (“reaped”) e l’eventuale “dust” viene bruciato. L’indicazione attuale è 1 DOT ED sulla Relay Chain e 0,01 DOT su Polkadot Asset Hub (valori specifici per ciascuna chain e soggetti a variazione). I controlli “keep-alive” aiutano a prevenire cancellation accidentali durante i trasferimenti; i teleports non applicano questa protezione.

Alcune funzioni richiedono depositi riservati (bond) tenuti mentre la funzione è attiva e solitamente restituiti al termine. Esempio: l’identità on-chain, ora gestita sulla parachain People, richiede un deposito rimborsabile e una commissione per il registrar; cancellando l’identità il deposito viene sbloccato (i fondi si trovano su People finché non vengono teletrasportati indietro). I depositi legati alla governance (es: decision deposit) sono trattati sotto Governance.

La Relay Chain è la chain centrale di Polkadot. Fornisce sicurezza condivisa e consenso globale della rete ed è intenzionalmente minimale nella logica applicativa: esiste per ospitare e coordinare molte chain parallele piuttosto che offrire funzionalità dirette all’utente finale. Nel design di Polkadot, la Relay Chain assicura una visione singola e consistente dello stato tra tutti gli shard collegati (“parachain”).

Le parachain sono chain applicative specializzate che operano in parallelo e si collegano alla Relay Chain. Mantengono un proprio stato e una propria logica, ma ereditano la sicurezza dal set dei validatori della Relay Chain. I nodi parachain chiamati collator raccolgono transazioni e producono blocchi candidati con prove; i validatori della Relay Chain controllano disponibilità e validità prima di accettare le transizioni di stato delle parachain nello stato condiviso. Questa separazione consente alle parachain di specializzarsi, mentre la Relay Chain gestisce consenso, finalità e coordinamento.

Le parachain comunicano usando il cross-consensus messaging (XCM) di Polkadot, con la Relay Chain che coordina il livello di instradamento/verifica così che le chain possano scambiare dati e asset in modo sicuro. Le meccaniche approfondite di XCM sono trattate nella sezione XCM.

Polkadot include anche system parachain (system chain) per funzioni core del protocollo—es: Asset Hub per asset fungibili e non-fungibili—spostando funzionalità fuori dalla Relay Chain ma beneficiando comunque della sicurezza condivisa. Queste system chain sono assegnate tramite governance on-chain.

Con Polkadot 2.0, i progetti accedono alle risorse di calcolo della Relay Chain tramite i core (“coretime”). Le system chain ricevono i core tramite governance, altre chain ottengono coretime sul mercato; la relazione fondamentale resta la stessa: le parachain eseguono la propria logica e la Relay Chain valida e finalizza le loro transizioni di stato.

XCM (Cross-Consensus Messaging) è il linguaggio di Polkadot per l’invio di messaggi basati su intenti tra sistemi di consenso (Relay Chain, parachain e—tramite bridge—altre reti). Definisce cosa dovrebbe succedere, indipendentemente dai pallet utilizzati a runtime. XCMP (Cross-Chain Message Passing) è il protocollo di trasporto per messaggi parachain↔parachain; il traffico relay↔parachain usa UMP (upward) e DMP (downward). I messaggi sono asincroni.

Trasferimenti: i due schemi nativi XCM

• Teleport: il valore si muove direttamente tra location fidate senza riserva. Uso tipico: DOT tra Relay Chain e Polkadot Asset Hub. I teleport richiedono configurazione di trust reciproco su entrambe le chain.
• Trasferimento basato su riserva: la chain di riserva dell’asset tiene traccia della supply totale; l’origine blocca/brucia una rappresentazione, la riserva regola i saldi e la destinazione accredita una rappresentazione. È lo schema abituale per muovere asset su parachain che non sono la riserva.

Nella pratica, molti team preferiscono i trasferimenti basati su riserva per sicurezza e chiarezza contabile; i teleport sono abilitati solo su rotte altamente fidate (per DOT: Relay Chain ↔ Asset Hub).

Canali e routing: I messaggi parachain↔parachain viaggiano su canali. Oggi, la maggior parte delle reti usa HRMP (Horizontal Relay-routed Message Passing), che fornisce la stessa interfaccia di XCMP ma memorizza i messaggi sulla Relay Chain; XCMP è lo stato finale più efficiente. I canali HRMP sono unidirezionali; la connettività bidirezionale richiede un canale per ogni direzione e deve essere aperto/accettato da entrambe le chain.

Commissioni, weight ed esecuzione: Un XCM deve "comprare esecuzione" sulla chain di destinazione (pagare per weight, cioè calcolo). Quali asset sono accettati come fee e quanta weight è richiesta dipende dalle policy della chain di destinazione. Le extrinsic standard includono teleport_assets e reserve_transfer_assets, che specificano destinazione, beneficiario, asset e fee.

Comportamento a livello utente e salvaguardie:

• Existential deposit & keep-alive: i teleport non applicano il controllo “keep-alive”. Assicurati che il saldo post-fee sulla destinazione resti sopra il suo existential deposit per evitare il reaping. I teleport includono anche una fee sulla chain di destinazione.
• Asincronia & ordinamento: la consegna non è istantanea; l’ordine è garantito solo all’interno di un canale.

Per bridge verso reti esterne e DOT wrapped, vedi la sezione interoperabilità più avanti.

Asset Hub è la system parachain di Polkadot (precedentemente “Statemint”) per l’emissione, la detenzione e il trasferimento di asset, incluse monete fungibili e NFT. È progettata come chain “common good” con commissioni più basse e existential deposit inferiore rispetto alla Relay Chain, e usa DOT come token nativo per commissioni e depositi. Su Polkadot Asset Hub, l’existential deposit è 0,01 DOT (dieci volte inferiore a quello della Relay Chain), e gli asset possono essere flaggati come sufficient (nessun saldo DOT obbligatorio per detenerli) o non sufficient (l’account deve rispettare l’ED di DOT).

Operativamente, Asset Hub è il luogo in cui utenti e team possono creare asset, gestire metadata ed effettuare trasferimenti; la documentazione ufficiale la evidenzia anche come sede per la gestione di token non-nativi e NFT. (Su Kusama, Asset Hub ha abilitato l’esecuzione di smart contract; su Polkadot, gli smart contract native EVM/PVM sono previsti sulla system chain Polkadot Hub, non su Asset Hub.)

Quando ha senso teletrasportare DOT?

Il teleport è la rotta XCM di fiducia configurata tra Relay Chain ↔ Asset Hub per DOT. È utile quando serve DOT su Asset Hub, ad esempio per:

• Pagare commissioni più basse o rispettare l’existential deposit di 0,01 DOT per detenere asset non-sufficienti su Asset Hub, oppure
• Usare funzionalità e applicazioni che girano direttamente su Asset Hub.

Aspetti chiave da sapere prima di teletrasportare:

• Una commissione sulla chain di destinazione viene detratta dall’importo teletrasportato; il saldo rimanente deve essere ≥dell’existential deposit sulla destinazione altrimenti i fondi andranno persi.
• I teleport non applicano la protezione “keep-alive”, quindi assicurati che i saldi post-fee restino sopra l’existential deposit su entrambi i lati se vuoi mantenere attivi gli account.
• Non teletrasportare direttamente verso un indirizzo di deposito di un exchange (la maggior parte degli exchange non rileva i teleport).

Per le meccaniche di teleport vs trasferimenti basati su riserva e il routing cross-chain, vedi la sezione XCM/XCMP. In caso di migrazioni di Asset Hub o manutenzioni pianificate, teleport e trasferimenti XCM potrebbero essere temporaneamente non disponibili; controlla gli avvisi di Support per lo stato attuale.

Scopo e ruolo: Polkadot e Kusama sono reti indipendenti con token separati (DOT, KSM) e stesso codice di base. Kusama è la “canary network”: un ambiente reale e vivo dove le novità arrivano prima e cambiano più rapidamente; Polkadot dà priorità a stabilità e affidabilità per i deploy di produzione.

Cadenza di governance: Entrambe utilizzano OpenGov, ma Kusama generalmente ha timeline più brevi (track-dependenti) da decisione a esecuzione, consentendo upgrade più rapidi; Polkadot usa tempistiche più conservative. I parametri sono per track e modificabili tramite governance.

Tempi staking: Il periodo di unbonding è ~28 giorni su Polkadot e ~7 su Kusama. Le ere (per i pagamenti ai validatori) sono ~24 ore su Polkadot e ~6 su Kusama. Queste differenze influenzano la frequenza delle ricompense e per quanto tempo i fondi restano bloccati dopo unbonding.

Saldo minimo account (existential deposit): Per tenere attivo un account, Polkadot richiede 1 DOT e Kusama 0,000333333 KSM (valori soggetti a cambio via governance). Le Asset Hub parachain usano ED ancora più bassi.

Percorso di aggiornamento: Le grandi novità e cambiamenti di protocollo sono provate prima su Kusama in condizioni reali; una volta validate, sono dispiegate su Polkadot. Questo mantiene Kusama agile e Polkadot conservativo per la gestione a lungo termine.

Le due reti condividono lo stesso modello architetturale (Relay Chain + parachain) e strumenti OpenGov; le differenze sopra riflettono obiettivi (velocità vs stabilità) e parametri operativi (timer, minimi) più che il design centrale.

L’NPoS è il modello di staking di Polkadot con due ruoli centrali: i validatori gestiscono nodi che producono/validano blocchi; i nominatori supportano i validatori scelti coi propri DOT. Entrambi condividono ricompense e rischio di penalità se il validatore sostenuto si comporta male. Le elezioni scelgono il set attivo dei validatori e assegnano il capitale dei nominatori ogni era.

Ciclo e tempistiche elettorali: Su Polkadot un’era dura ~24 ore. Il set dei validatori attivi per la prossima era è calcolato alla fine di quella corrente e attivato all’avvio della prossima; le ricompense sono calcolate per era.

Come partecipano i nominatori: Un nominator può sostenere fino a 16 validatori. L’algoritmo di elezione può assegnare lo stake del nominator solo a una parte delle scelte fatte, mirando a un set bilanciato e ben supportato; non tutti i validatori nominati riceveranno capitale nel risultato finale.

Come vengono eletti i validatori (obiettivo e algoritmo): Le elezioni dei validatori ottimizzano tre obiettivi: (1) massimizzare il capitale totale a supporto, (2) massimizzare il capitale minimo alle spalle di ogni validatore eletto e (3) ridurre la varianza degli stake tra i validatori. Polkadot calcola le soluzioni off-chain e le invia on-chain tramite l’Election Provider (multi-phase), con fasi firmate e non firmate e un fallback on-chain se serve. La rete adotta regole proporzionali di elezione da ricerche su Phragmén, risolte off-chain tramite il multi-phase Election Provider (sostituisce la vecchia sequenza Phragmén).

Assegnazione capitale e ricompense (overview): Una volta scelti i vincitori, la soluzione specifica come lo stake dei nominatori è distribuito tra i validatori eletti. I validatori sono premiati per era in base all’attività, i nominatori tramite i propri validatori supportati. I dettagli operativi delle ricompense sono trattati sotto staking.

Accountability: Dal momento che i nominatori sostengono attivamente dei validatori, questi ultimi possono essere slashed se il validatore nel set attivo commette certi errori. Per condizioni e percentuali, vedi la sezione dedicata allo Slashing.

Per tempi di unbonding, pool e meccaniche dei premi, continua nelle sezioni staking; questa voce tratta solo il modello elettorale e la selezione validator.

Lo slashing è una penalità on-chain applicata quando un validatore viola le regole di consenso. Penalizza con il burn di una percentuale dello stake collegato a quel validator slot (self-bond del validator più lo stake dei nominatori assegnati). La percentuale dipende dalla gravità; i fondi penalizzati vanno alla Polkadot Treasury. I nominatori sono penalizzati solo se avevano stake esposto su quel validator al momento dell’infrazione.

Infrazioni che possono causare slashing (esempi): Polkadot elenca le infrazioni dei validator e associa le risposte tipiche. Articoli rappresentativi includono:

• Equivocazione (BABE/GRANDPA/BEEFY): doppia firma di blocchi o voti. Slashing 0,01%–100% a seconda della gravità e di quanti validator coinvolti; il validator viene disabilitato.
• Supporto a blocco parachain invalido: para-validator ha approvato un blocco invalido. Slashing 100%; disabilitazione on-chain.
• ForInvalid vote: secondary checker ha votato per un blocco invalido. Slashing 2%; disabilitazione.
• AgainstValid vote: ha votato contro un blocco valido. Slashing 0% (nessuna perdita), ma disabilitazione applicata.

Indisponibilità vs slashing: Interruzioni di servizio di routine di solito portano a “forced chilling” (validator fermato) invece che slashing. Su Polkadot, uno slashing per “offline” è considerato solo se l’evento riguarda ≥10% del set validator attivo. La documentazione Support segnala anche che “prolungato” offline (circa 4 ore) tipicamente porta a chilling, non a slashing.

Chi paga e quanto: Slashing è una percentuale sullo stake esposto sul validator slot (self-bond+quota nominatori). Le perdite dei nominatori sono pro-rata rispetto all’esposizione verso il validator sanzionato; lo stake verso altri validator non è toccato. Questo sistema di percentuali incentiva la diversificazione della delega.

Applicazione, delay e reversal: Polkadot posticipa molti slashing di circa un periodo di unbonding (~28 giorni). In tale finestra la governance può annullare lo slash se dovuto a bug o problemi non attribuibili a colpe; altrimenti è applicato prima dell’incasso dei fondi dopo unbonding.

Destinazione fondi slashed: Tutti i DOT penalizzati sono accreditati alla Treasury on-chain, che finanzia iniziative di rete tramite OpenGov.

Letture correlate: per selezione validator e assegnazione stake vedi la sezione NPoS; per unbonding e pool vedi le sezioni staking.

Quando fermi lo staking, i DOT bonded diventano “unlocking” e sono prelevabili solo dopo 28 giorni di unbonding. Occorre poi eseguire Withdraw Unbonded per renderli trasferibili. (Su Kusama 7 giorni.)

Eccezione: Fast Unstake. Se il tuo account non era esposto a validatori attivi nelle ultime 28 era, puoi usare Fast Unstake e saltare l’attesa di 28 giorni. Se eri esposto, vige il periodo normale.

Staking pools vs nomination diretta

Requisiti d’entrata & eleggibilità alle ricompense:

• Nomina diretta (solo): per guadagnare premi il bonded deve superare la soglia minima attiva di nomination, dinamica e variabile.
• Nomination pools: pensati per permettere anche a piccoli holder di partecipare; la documentazione ufficiale segnala che basta 1 DOT (soggetto a pool e attività).

Controllo & custodia:

• Diretta: scegli tu i validator.
• Pool: i DOT restano nel tuo account (bonded), ma il nominator della pool sceglie i validator; una selezione sbagliata impatta le ricompense e condividi il rischio slashing.

Operatività (entrare, cambiare, uscire):

• Tempo unbonding: entrambi seguono i 28 giorni su Polkadot. L’uscita da una pool attende 28 giorni prima del prelievo.
• Cambio pool: serve unbonding prima (28 giorni; niente premi in questo lasso).
• Rebond durante unbonding: i nominatori diretti possono rebondare in qualsiasi momento prima dei 28 giorni; i membri pool NO durante il periodo di unbonding.
• Gestione premi: uscendo dalla pool, i reward pendenti sono già accreditati al balance trasferibile al momento del prelievo. Alcune pool offrono auto-compound opzionale.

La guida attuale conferma che puoi votare in OpenGov anche se staked in una pool, e puoi entrare in una pool con token già bloccati per la governance. (Cambiato rispetto a limitazioni precedenti.)

Per penalità dei validator, vedi Slashing.

Existential deposit (ED) e minimi account:

• Relay Chain ED: Servono 1 DOT per mantenere attivo un account Polkadot. Se il saldo libero scende sotto 1 DOT, l’account può essere cancellato (“reaped”) e l’eventuale “polvere” persa.
• Asset Hub ED: 0,01 DOT su Polkadot Asset Hub (specifica per chain e decisa via governance). Gli asset qui possono essere sufficient (nessun DOT richiesto per detenerli) o non-sufficient (segue l’ED DOT).

Protezione keep-alive: I wallet come Polkadot-JS abilitano "keep alive" di default: un trasferimento che portasse il saldo sotto l’ED è bloccato. Puoi disabilitare questa protezione per inviare l’intero saldo e cancellare l’account mittente.

Modello di commissioni sulla Relay Chain:

Polkadot usa un modello fee basato sul peso. La commissione di una transazione è la somma di:

• Componente base (overhead fisso)
• Fee per lunghezza (in base ai byte)
• Fee per weight (in base al peso di esecuzione della chiamata)
• Tip opzionale (per aumentare priorità d’inclusione)
• Un moltiplicatore dinamico regola leggermente le commissioni su/sotto in base al riempimento blocchi (congestione).

Come vedi/stimi le fee: Wallet e SDK mostrano la stima prima della firma (es: paymentInfo in polkadot.js). Le fee sono prelevate dal saldo trasferibile (non bonded).

Note pratiche:

• Riattivare un account reaped: basta trasferire in almeno l’ED della chain (es: 1 DOT su Relay Chain).
• ED specifici per chain: L’ED varia; Asset Hub ha ED minore rispetto a Relay. Verifica valori aggiornati nelle guide ufficiali.
• Cross-chain: Le operazioni XCM (es teleport) fanno pagare una commissione anche sulla destinazione e non applicano keep-alive; assicurati che il saldo post-fee rispetti l’ED sulla destinazione. Vedi la sezione XCM per le meccaniche.

Per minimi e tempi di unbonding su staking, vedi le sezioni staking; qui focus su fee e minimi account.

OpenGov è il sistema di governance on-chain di Polkadot. Le proposte (“referendum”) sono vincolanti: una volta approvate vengono automaticamente attuate dopo il periodo di enactment. Possono essere attivi più referendum in parallelo.

Track e origini: Ogni referendum è presentato su un track che corrisponde a un’origine (livello di privilegio dell’azione). Ogni track definisce: il decision deposit, finestre temporali (prepare/decision/confirmation/enactment), curve di approvazione/supporto (soglie da rispettare) e spesso quante proposte possono essere simultaneamente “in deciding”. I track ad alto privilegio (es Root) hanno soglie più alte e tempi più lunghi rispetto ai track di basso impatto (es. Small Tipper).

Alcune chiamate possono essere “whitelistate” dalla Polkadot Fellowship e poi eseguite tramite il track Whitelisted Caller, che usa parametri più rapidi dopo l’approvazione del referendum. Comportamenti e casi esempio dei track sono documentati nella guida “origins” di OpenGov.

Voto e conviction: Chi possiede DOT vota Aye/Nay/Abstain. Puoi abilitare conviction (un moltiplicatore temporale) per aumentare il peso del voto bloccando DOT più a lungo; i lock partono a fine referendum e scadono dopo il periodo di conviction scelto. OpenGov consente diverse conviction su referendum simultanei.

Delega e multi-delega: Oltre a votare direttamente, puoi delegare potere di voto. OpenGov supporta la multi-delega per track: puoi delegare importi e conviction diversi a delegate diversi su diversi track. Non puoi delegare un track dove hai già voti non scaduti (o una delega attiva) finché non li azzeri. Le interfacce ufficiali ti guidano nella selezione dei track e delle conviction durante la configurazione delega.

Ciclo di vita del referendum (overview):

• Submission & prepare period – il referendum viene inserito su un track; il voto può iniziare ma i voti contano solo dopo il periodo prepare. Serve un decision deposit per passare allo stadio deciding.
• Decision period – il punto è attivamente deciso. Per passare servono le soglie di approvazione e supporto del track.
• Confirmation period – le soglie vanno soddisfatte per una finestra minima di conferma.
• Enactment period – una volta confermato, l’item è in coda e viene eseguito automaticamente dopo il delay di enactment del track.

Qualsiasi detentore di DOT può partecipare a OpenGov: puoi proporre referendum, votare direttamente o delegare il voto. Le attività avvengono su “track” che definiscono l’origine (privilegio), decision deposit, soglie e periodi. Ogni track ha i suoi parametri, stabiliti dalla governance.

Proporre (creare un referendum):

1. Scegli il track giusto per l’azione che vuoi svolgere (es: Root per chiamate ad alto impatto, Tippers/Spenders per Treasury).
2. Sottoponi il referendum e assicurati che sia piazzato un decision deposit; è tracciato on-chain ed è necessario affinché la proposta passi allo stato deciding dopo il periodo di attesa. I deposit sono visibili nelle UI e rimborsabili secondo le regole del track.

Requisiti: account Polkadot con abbastanza DOT per fee e deposit richiesta dal track. L’identità on-chain è opzionale ma spesso usata dai proponenti per credibilità; richiede un deposito rimborsabile e una fee per il registrar su People parachain.

Votare (partecipazione diretta):

• Scelte: Aye, Nay, Abstain, Split (ripartizione tra Aye/Nay), o SplitAbstain (ripartizione tra tutte le opzioni).
• Conviction voting: puoi bloccare i DOT per più tempo per aumentare la potenza di voto; i lock partono a referendum chiuso e scadono secondo la conviction scelta. I lock si sommano, quindi lo stesso saldo può coprire più voti o essere staked. Puoi anche rimuovere il voto mentre il referendum è aperto per sbloccare subito; altrimenti, libera i lock scaduti dopo il periodo.

Anche DOT staked o in pool possono votare: OpenGov supporta il voto con DOT in pool o staking diretto, dopo gli aggiornamenti che hanno sbloccato questa possibilità.

Delegare (per-track, multi-delega): Se preferisci non votare su ogni item, puoi delegare. OpenGov consente multi-delega per track: scegli delegate diversi su track diversi, con importi e conviction a tua scelta. Non puoi delegare dove hai già votato (lock non scaduti) o una delega attiva senza prima liberare. Puoi gestire le deleghe nelle UI ufficiali (Polkadot-JS, Polkassembly, Nova, PolkaGate).

Tool pratici:

• Polkadot-JS UI: proporre, votare, delegare, liberare i lock scaduti.
• Polkassembly/Subsquare/Nova/PolkaGate: scoprire referendum, votare (anche Split/Abstain), configurare multi-delega per track.

Per soglie, tempistiche e taglie dei deposit consulta il track specifico quando proponi o deleghi; sono parametri dinamici e modificabili via governance.

La Treasury è una pool di fondi on-chain controllata da OpenGov. Riceve afflussi automaticamente e può spendere solo tramite azioni approvate dalla governance. I fondi vivono su un account di sistema; nessun account può muoverli direttamente.

Come si finanzia la Treasury (inflow):

• Commissioni transazioni: l’80% di ogni fee va alla Treasury; il restante 20% ai produttori di blocchi.
• Emissione DOT: il 15% dell’inflazione va alla Treasury.
• Slashing: una quota delle penalità validator è versata alla Treasury.
• Trasferimenti diretti: gli utenti possono mandare asset alla Treasury (poco comune, es: rimborsi).

Come avvengono le spese (outflow):

• Proposte Treasury (spend): la governance approva referendum che spostano fondi a un beneficiario. I pagamenti avvengono secondo lo “spend period”; a ogni fine periodo, una frazione dei fondi non spesi viene bruciata.
• Tip: piccoli pagamenti rapidi tramite track Small/Big Tipper.
• Bounty & child bounty: bounty "parent" riservano fondi che i curator poi distribuiscono tramite child bounty a attività/eventi; utile quando servono pagamenti multipli nel tempo. I curator postano un deposito, possono ricevere una fee e gestiscono pagamenti per la durata del bounty.

Track di governance usati per spesa Treasury: OpenGov gestisce outflow Treasury tramite sei track, ognuno con origine e parametri propri: Treasurer, Big/Medium/Small Spender, Big/Small Tipper. Le spese più grandi usano track con soglie più alte; i tip per premi più piccoli.

Treasury multi-asset: La Treasury può detenere e spendere asset oltre DOT (es: USDT/USDC) una volta attivati su Asset Hub e con conversione impostata dalla governance (track Treasurer). Le spese multi-asset specificano bene asset, chain e importo; supporto per milestone e claim a finestre manuali.

Sub-treasury (budget delegato): La governance può assegnare parte della Treasury primaria a sub-treasury legate a collettivi o system chain. Ognuna segue regole proprie per pagare fondi, riducendo il bisogno di molte proposte sulla Treasury principale.

Per come creare, votare, o delegare proposte Treasury, vedi le sezioni OpenGov.

La Polkadot Fellowship è un collettivo on-chain di contributor tecnici che guida il runtime e gli standard tecnici del protocollo. Opera sulla chain Collectives di Polkadot e coordina lavoro sia on-chain che tramite repository pubblici (es: RFC per proposte di cambiamento). Pur mantenendo i runtime di Polkadot e Kusama, la Fellowship non blocca modifiche di protocollo—qualsiasi detentore DOT può proporre upgrade runtime sulla Root track di OpenGov.

Membri e rank: I membri Fellowship hanno un rank e la governance interna lo usa per pesare il voto e segnalare revisione tecnica. Dashboard pubblici sulla Collectives chain mostrano rank membri e attività Fellowship.

Whitelisting & Whitelisted Caller track: Per azioni urgenti o low-risk, ben auditati (solitamente release runtime), la Fellowship può whitelisteare un hash di chiamata. Questo consente al track Whitelisted Caller in OpenGov di eseguire la call con autorità Root dopo un referendum. Questo track usa parametri e soglie più veloci e diversi dal Root, fornendo un percorso rapido e controllato per item valutati.

Come avvengono gli upgrade: Su Polkadot, gli upgrade runtime avvengono solo tramite referendum Root o Whitelisted Caller. Il ruolo della Fellowship è revisionare e, se appropriato, whitelistare le release per permettere la via rapida; il resto passa dal processo Root standard.

Processo open development: Le proposte tecniche e i lavori sono tracciati con repo RFC pubblici; i segnali della Fellowship (ok/ko) e le decisioni on-chain sono visibili a token holder e votanti.

Agile Coretime (blockspace come mercato)

Polkadot 2.0 sostituisce gli affitti slot a lungo termine e crowdloan con un mercato del coretime. I progetti acquisiscono tempo d’esecuzione sui “core” della Relay Chain in due modi:

• Bulk Coretime: una “region” da circa un mese (~28 giorni, 5.040 timeslice) venduta su una chain Coretime specializzata. La proprietà è registrata come asset non-fungibile e può essere ceduta o rivenduta.
• Coretime istantaneo: raffiche brevi acquistate da un pool quando necessario (pay-as-you-go).

Le vendite usano una “lead-in” a prezzo decrescente (tipo Dutch) per periodo; un prezzo regolare è adattato nel tempo da regole di governance così il prezzo converge sulla domanda. È previsto un mercato secondario per le region. I proventi dalla vendita coretime sono bruciati secondo uno RFC Fellowship. L’emissione netta quindi è emissione lorda meno burn.

Impatto sui costi: i team pianificano spendendo solo per la capacità effettiva necessaria, con prezzi più chiari e senza vincoli pluriennali. Auction/crowdloan sono deprecate da quando Agile Coretime è attivo.

Async Backing (throughput e latenza migliorata)

Async Backing decoupla produzione blocchi parachain dal blocco Relay più recente, permettendo ai collator di pipeline più candidati e overlapping tra backing e inclusione. In pratica:

• le parachain scrivono blocchi ogni ~6s (prima erano 12s)
• la finestra di esecuzione cresce (da ~0,5s a ~2s), permettendo blocchi ~4× più grandi
• l’upshot è fino a ~8× throughput solo con questo e ~10× col PoV-reclaim (che include la reale prova dei size)

Questi cambiamenti sono live dal 2024 (prima su Kusama, poi Polkadot).

Impatto performance: TPS sostenuto più alto e inclusion più rapida per chain che l’attivano; le chain che non hanno bisogno della capacità extra possono abilitare dopo.

Elastic Scaling (multi-core per chain)

Elastic Scaling consente a una sola chain di usare più core in parallelo (scaling verticale) invece che solo uno. Funziona con async backing, parametri nuovi per collator/validator, spingendo throughput/latenza ancora oltre. Da agosto 2025 Elastic Scaling è in ultimazione per l’abilitazione mainnet via OpenGov (prima Kusama, poi Polkadot).

Impatto performance: rollup/parachain con alti carichi possono spalmarsi su più core, aumentando headroom senza frammentarsi su più chain.

Riepilogo effetti:

• Costi & planning: coretime prevedibile e di mercato sostituisce gli affitti; i team comprano region mensili o slice on demand; il burn dei ricavi coretime riduce in parte l’emissione.
• Throughput & latenza: async backing aumenta frequenza/capacità blocchi; elastic scaling aggiunge esecuzione multi-core. Insieme alzano il throughput sostenuto senza cambiare il modello di sicurezza condivisa di Polkadot.

1. Costruisci la tua chain:

   • Usa Polkadot SDK (Substrate + Cumulus) e parti dal template parachain. Riceverai un runtime FRAME-based, un nodo collator e hook XCM pronti.
   • Collega localmente a una Relay Chain per validare produzione blocchi e XCM base; il tutorial ufficiale mostra come collegare una parachain locale.

2. Testnet proving & ottieni una ParaID:

   • Prova gli upgrade e XCM su Paseo (testnet community con coretime).
   • Prenota una ParaID sulla relay di destinazione tramite il registrar: prima reserve (paghi il deposito definito dalla chain), poi register col tuo validation code (WASM) e head di genesis. I depositi sono specifici della chain (registrar pallet/doc mainnet/governance).

3. Acquista Coretime (Polkadot 2.0):

   • Bulk Coretime (“Region”): acquista una region ~28 giorni (5.040 timeslice su core specifico), venduta sulla Chain Coretime. La proprietà è tracciata on-chain e cedibile; le vendite usano un lead-in a prezzo discendente verso il “prezzo regolare”.
   • Coretime istantanea: capacità on-demand dal pool per burst, non una intera region.
   • Contabilità: i proventi coretime sono bruciati secondo Fellowship RFC-0010, quindi budgetizza DOT per l’acquisto; niente lockup/crowdloan.

4. Registra & attiva sulla Relay Chain:

   • Con ParaID, runtime WASM e genesis head preparati, inoltra la richiesta di registrazione e attivazione. Su Polkadot, il normale onboarding va tramite registrar; le system chain (es: Coretime, Asset Hub) via OpenGov (spesso Whitelisted Caller track) come da esempio di referendum su Coretime chain.

5. Gestisci la rete:

   • Collator: gestisci almeno due collator affidabili; scala e geo-distribuisci all’aumentare del carico. (Validator sulla Relay Chain; collator sulle parachain.)
   • XCM & HRMP: apri canali HRMP verso peer (es: Asset Hub) e configura XCM (asset accettati come fee, reserve location). Per DOT routing, nota la guidance su Asset Hub come DOT reserve durante la migration.
   • Upgrade: pubblica runtime upgrade tramite la governance della chain; la Relay Chain li valida inclusione. (Parametri relay e meccaniche OpenGov nelle sezioni governance.)

6. Rollup vs parachain (cosa significa “rollup” qui):

   • Spesso i team implementano “rollup” come parachain via SDK (verifica e settle sulla Relay Chain, usufruendo di availability/validity e XCM). Se punti a un rollup da hostare su una parachain esistente, coordini con l’host piuttosto che comprare coretime; la rotta relay resta come sopra. (La scelta architetturale è propria di ogni progetto.)

Requisiti minimi (checklist)

Tecnici:

• Runtime Polkadot SDK (WASM) + chain spec, genesis head, ParaID.
• Collator node, endpoint RPC, telemetry/monitoraggio.
• Configurazione XCM e almeno un canale HRMP per integrazioni.

Economici:

• DOT per coretime (Bulk o Instantaneous) e fee transazioni; ricorda che il coretime comprato viene bruciato.
• Deposito registrar per riserva/registrazione ParaID (specifico per chain).

To do governance:

• Nessuno per l’onboarding ordinario tramite registrar oltre la governance interna della chain; le system chain sono onbordate da OpenGov (esempio: Coretime chain registration).

Native DOT vs wrapped/derivative DOT:

• Native DOT esiste su Polkadot (Relay e system chain come Asset Hub). All’interno di Polkadot, i DOT si muovono con XCM: teleport (Relay ↔ Asset Hub per DOT) o reserve transfer su altre parachain. La governance sta migrando la reserve location di DOT in XCM da Relay Chain verso Asset Hub; le parachain devono considerare Asset Hub nuova riserva.
• Wrapped/derivative DOT esistono fuori da Polkadot (es: su Ethereum) o come ERC-20 dentro parachain EVM. Su Moonbeam, DOT è xcDOT, uno XC-20: una rappresentazione ERC-20 compatibile il cui DOT resta bloccato su un account “sovereign” sulla chain di riserva, mentre l’interfaccia ERC-20 si usa localmente.

XCM in Polkadot vs bridge verso esterno:

• XCM (ecosistema): pattern e messaggi per spostare asset fra Relay e parachain. Per DOT, teleport abilitato sulla rotta fidata Relay ↔ Asset Hub; per altre parachain si usa il reserve transfer, con la chain di riserva che mantiene il saldo totale.
• Bridge (fuori ecosistema): per reti come Ethereum, Polkadot usa bridge ospitati su Bridge Hub. Snowbridge è il bridge ufficiale Polkadot↔Ethereum basato su light-client. Attualmente conia ERC-20 bridged sulla ForeignAssets di Asset Hub, poi XCM reserve transfer per portare token a destinazione, combinando bridge e XCM.

EVM via Moonbeam (XC-20):

• Standard XC-20: su Moonbeam gli asset cross-chain si vedono come XC-20, compatibili ERC-20 (e Permit). Per DOT si chiama xcDOT. I dev interagiscono con XC-20 con tool Ethereum, Polkadot gestisce accounting tramite account sovereign.
• Local vs external XC-20: i token che hanno la "home" su Moonbeam sono XC-20 locali; asset come DOT sono external XC-20, il cui saldo resta canonico sulla riserva (Relay/Asset Hub), con rappresentazione ERC-20 su Moonbeam.

Note pratiche:

• Quando usare cosa: usa XCM per movimenti dentro Polkadot (es: DOT tra Asset Hub e parachain). Usa bridge (es: Snowbridge) per spostare asset su/da reti esterne; i token bridge hanno rappresentazioni distinte e diversi modelli di trust rispetto ai DOT nativi.
• Aggiornamenti in corso: la migration della reserve-location di DOT (Asset Hub) è in atto; parachain e app devono aggiornare la config di XCM per mantenere accounting canonico nei trasferimenti. Le guide per utenti arrivano tramite Support/Forum di Polkadot.

Polkadot è stata avviata dalla Web3 Foundation (W3F), un’organizzazione no-profit svizzera il cui progetto di punta è Polkadot. Il fondatore di W3F è Dr Gavin Wood, autore del whitepaper Polkadot nel 2016 che introduceva il design multi-chain eterogeneo.

Lo sviluppo del protocollo e del runtime è stato guidato da Parity Technologies, il team di ingegneri che ha lavorato con W3F fino al debutto mainnet nel 2020.

Il team fondativo di Polkadot è comunemente indicato come Gavin Wood, Robert Habermeier e Peter Czaban. L’annuncio ufficiale di W3F indica Robert Habermeier come co-founder/core developer, Peter Czaban co-founder di Polkadot e W3F.

W3F ha avviato il rollout live della rete il 26 maggio 2020, dopo anni di sviluppo; le fasi successive hanno dato controllo agli holder e abilitato l’emissione DOT on-chain. Modalità d’offerta e redenominazione sono trattate nelle sezioni sopra.