On-Chain Governance: Il Tech Stack Spiegato

La governance viene discussa come un processo politico, ma il meccanismo dietro è pura ingegneria software: smart contract, token accounting e regole di consenso che decidono chi può cambiare un sistema e come. Se stai valutando un DAO o un percorso di upgrade del protocollo, capire il tech stack è più importante che leggere la mission statement.

I componenti core

La maggior parte dei sistemi di governance on-chain sono costruiti da un piccolo set di componenti:

• Voting contract — tracciano proposte, contano i voti e fanno rispettare le soglie di quorum
• Token o reputation weighting — determina quanto il voto di un indirizzo conta (token-weighted, quadratico o delegato)
• Timelock contract — ritardano l'esecuzione delle proposte approvate, solitamente 24-72 ore, così gli utenti possono reagire prima che i cambiamenti arrivino
• Execution module — il percorso di codice che effettivamente chiama i contract interessati dopo che un voto passa

Compound's Governor Bravo e OpenZeppelin's Governor contract sono le implementazioni di riferimento che la maggior parte dei progetti più nuovi forkano o estendono. Se leggi un solo codebase per capire il pattern, leggi Governor.sol da OpenZeppelin — è ben commentato e mostra il ciclo di vita completo della proposta: propose, vote, queue, execute.

Come una proposta si muove attraverso il sistema

Una proposta non è solo un post del forum che viene votato informalmente. On-chain, è calldata: un indirizzo del contract target, un function selector e parametri codificati. Quando qualcuno invia una proposta di governance, sta inviando la transazione esatta che si eseguirà se il voto passa.

Il flusso tipicamente assomiglia a questo:

1. Il proposer invia calldata più una descrizione, spesso richiedendo un saldo minimo di token per prevenire spam
2. Un voting delay (comunemente 1 block fino a pochi giorni) dà ai holder il tempo di rivedere prima che il voto si apra
3. Il voting period si svolge (Compound usa all'incirca 3 giorni di default, anche se molti fork configurano finestre più lunghe)
4. Se le soglie di quorum e approvazione sono raggiunte, la proposta entra in una timelock
5. Dopo che il ritardo della timelock scade, chiunque può chiamare execute per eseguire la transazione

Quello spazio tra la chiusura del voto e l'esecuzione è il backstop di sicurezza. È la finestra dove una comunità può notare una proposta malevola o difettosa e, in casi estremi, coordinare una risposta d'emergenza — assumendo che il protocollo abbia un ruolo di guardian d'emergenza o un override multisig, che molti hanno durante la governance in fase iniziale.

Dove la logica di weighting diventa complicata

Il semplice token-weighted voting ha un problema noto: chi tiene la maggior parte dei token controlla gli outcome e il turnout dei votanti è solitamente basso. Un pugno di governance forum riportano un turnout nella percentuale a cifra singola della circolating supply per proposte di routine.

I progetti hanno provato diversi fix:

• Delegation — i token holder assegnano il loro voting power a un delegato senza trasferire i token, che è come Compound e Uniswap gestiscono il voto rappresentativo
• Quadratic voting — il costo dei voti aggiuntivi aumenta quadraticamente, inteso a ridurre il dominio dei whale, anche se la resistenza Sybil (una persona che crea molti indirizzi) rimane un problema aperto
• Conviction voting — usato da alcuni strumenti adiacenti a Gitcoin, dove il voting power accumula più a lungo i token rimangono committed a una posizione, favorendo la preferenza sostenuta rispetto ai snapshot vote

Nessuno di questi risolve completamente i bassi turnout, dinamiche inclini alla plutocrazia del token voting. Sono mitigazioni, non fix, e qualsiasi voce di glossario che affermi il contrario sta overselling la tecnologia.

Off-chain signaling versus on-chain execution

Molto di quello che viene chiamato