Nei whitepaper di ogni progetto DeFi, c'è una sezione dedicata alla "Governanza DAO." Dipinge un'immagine di un'utopia decentralizzata dove i possessori di token si tengono per mano e prendono decisioni insieme. In realtà, i protocolli in fase iniziale come Lorenzo sono spesso dittature travestite da democrazie. Questo non è necessariamente negativo: le startup hanno bisogno di agilità - ma come investitore nel token BANK, devi sapere esattamente dove si traccia la linea tra "governanza della comunità" e "chiavi di amministrazione."
Ho investigato i parametri di governanza attuali del Protocollo Lorenzo. Sebbene il token BANK sia commercializzato come lo strumento per prendere decisioni, il controllo effettivo on-chain del "Financial Abstraction Layer" probabilmente risiede in un wallet multi-firma controllato dal team principale e forse da alcuni investitori iniziali. Questo multi-sig ha poteri da dio. Può mettere in pausa il ponte, può cambiare la whitelist dei validatori, può alterare la struttura delle commissioni e, teoricamente, in uno scenario peggiore che coinvolge contratti aggiornabili, potrebbe manipolare i saldi degli utenti o reindirizzare i rendimenti.
Questa centralizzazione è l'elefante nella stanza. Quando parliamo di "Bitcoin Layer 2s," stiamo spesso parlando di "multisigs con team di marketing." Per Lorenzo, il rischio è aggravato dal contesto normativo. Se il team mantiene il controllo sul ponte e sul set di validatori, sembrano sospettosamente un fornitore di servizi di attività virtuali (VASP). Questo li rende un obiettivo primario per i regolatori. Se un ente governativo ordina al team di Lorenzo di congelare gli stBTC di un utente specifico, e hanno le chiavi di amministrazione per farlo, dovranno conformarsi. Questo distrugge la tesi della resistenza alla censura di costruire su Bitcoin. La promessa di Bitcoin è che nessuno può sequestrare i tuoi fondi; se Lorenzo introduce uno strato che può sequestrare i tuoi fondi, hanno degradato l'asset.
La transizione al vero controllo DAO è la fase più pericolosa per un progetto. Se consegnano le chiavi troppo presto ai detentori di BANK, il protocollo potrebbe essere dirottato da un attacco di governance malevolo (ad es., una balena che acquista abbastanza BANK per votare per un aggiornamento malevolo). Se le consegnano troppo tardi, la comunità perde fiducia e il premio di "decentralizzazione" sul token evapora.
Sto cercando specificamente un "Timelock" sulle azioni di governance. Un timelock garantisce che se le chiavi di amministrazione (o il DAO) votano per cambiare un parametro critico, ci sia un periodo di attesa obbligatorio (ad es., 48 ore) prima che il codice venga eseguito. Questo dà agli utenti il tempo di ritirare i loro asset se non sono d'accordo con il cambiamento. Attualmente, la visibilità su questi timelock per i contratti core di Lorenzo è limitata. Come ricercatore, tratto qualsiasi protocollo senza un timelock visibile e significativo come custodiale.
Perché il token BANK abbia un valore a lungo termine, deve evolversi da un "token di coordinazione" a un "token sovrano." Il valore di BANK è attualmente limitato dalla fiducia nel team. Se il team scompare, il protocollo muore? Al momento, la risposta è probabilmente sì. Il sovraccarico operativo di gestione dei punteggi di credito dei validatori e dei relatori del ponte è troppo alto per un DAO disorganizzato. Ciò significa che $BANK i detentori stanno scommettendo sulla capacità del team di automatizzarsi per liberarsi dal lavoro. Stiamo investendo nella loro obsolescenza. Fino a quando il "Financial Abstraction Layer" non diventa una base di codice auto-perpetuante e immutabile, $$BANK è solo un proxy per l'equità in una startup tecnologica centralizzata, comportando tutti i rischi di controparte che ciò implica.
