Rischio del proprietario e del recupero di uno smart account

Verifica chi può controllare uno smart account, come il recupero cambia il proprietario, quali ritardi e diritti di annullamento si applicano e se moduli o upgrade creano percorsi nascosti di acquisizione.

Solo a scopo educativo; non è consulenza finanziaria, legale o di sicurezza. Un errore di recupero o configurazione può trasferire il controllo di uno smart account o bloccarlo permanentemente.

Risposta diretta

Uno smart account è controllato dalla logica di autorizzazione distribuita per quell’account, non necessariamente da una sola chiave privata. Un proprietario o validatore può approvare le operazioni ordinarie, mentre un guardiano, modulo di recupero, esecutore o amministratore degli upgrade può avere un percorso separato per sostituire il proprietario o eseguire transazioni.

Il recupero riduce la probabilità che la perdita di una chiave renda inutilizzabile l’account, ma aggiunge una superficie di acquisizione. Verifica ogni percorso che può autorizzare esecuzioni, cambiare validatori o proprietari, installare moduli, aggiornare codice oppure annullare e finalizzare il recupero. Le etichette dell’interfaccia come «proprietario» e «guardiano» non provano i poteri reali del contratto.

Registra il risultato in una tabella dei permessi: indirizzo on-chain esatto, ruolo, azione richiamabile, soglia, ritardo, autorità di annullamento, scadenza, ambito di spesa, autorità di upgrade e dominio di controllo indipendente. Ricontrollala dopo ogni modifica e su ogni chain dove esiste l’account.

Come funziona

Identifica account e codice. Verifica chain ID e indirizzo, poi implementazione, proxy o beacon, factory e versione. Per un proxy ERC-1967 leggi gli slot di implementazione, beacon e amministratore invece di fidarti di un badge.
Elenca i percorsi di autorizzazione. Leggi proprietari e soglie, validatori ERC-4337, validatori, esecutori, hook e fallback handler ERC-7579, moduli e guardie tipo Safe, chiavi di sessione, contratti di recupero e amministratori di emergenza o upgrade. Un esecutore o modulo Safe può agire senza la soglia normale.
Decodifica la macchina a stati del recupero. Stabilisci chi propone il sostituto, come si contano e scadono le approvazioni, quando parte il ritardo, chi annulla, chi finalizza e cosa avviene se il recupero viene sostituito o ripetuto. Non tutti i contratti di «recupero sociale» seguono la stessa sequenza.
Prova indipendenza e disponibilità. Indirizzi diversi non sono indipendenti se li controlla lo stesso dispositivo, persona, account cloud, password vault, custode o amministratore. Conferma che la soglia resti raggiungibile dopo un guasto previsto senza dare a un dominio potere sufficiente per acquisire l’account.
Esamina l’autorità di configurazione. Determina chi aggiunge o rimuove guardiani, validatori, esecutori, hook, moduli o fallback handler; cambia soglia o ritardo; sospende l’annullamento; o aggiorna account e recupero. Un timelock serve solo se nessun altro ruolo può aggirarne ritardo e annullamento.
Monitora e verifica. Sottoscrivi o interroga indipendentemente modifiche a recupero, proprietari, moduli, soglia, implementazione e amministratore. Dopo ogni operazione decodifica la transazione e verifica ricevute, eventi, storage e proprietari finali sulla chain corretta; il messaggio di successo non basta.

Esempio pratico

Supponi che un account abbia proprietario O e tre guardiani G1, G2 e G3. Qualsiasi 2-of-3 guardiani può proporre il nuovo proprietario N; parte un ritardo di 24-hour; O può annullare durante il ritardo; poi chiunque può finalizzare. Il modulo può chiamare il cambio di proprietario senza l’approvazione di O sulla transazione finale.

Le etichette suggeriscono recupero distribuito, ma G1 e G2 sono app salvate nello stesso account cloud. Compromettere quella credenziale dà a un aggressore la soglia effettiva 2-of-3. Propone N; se monitoraggio o annullamento falliscono per 24 hours, la finalizzazione trasferisce il controllo anche se la chiave privata di O non è stata rubata.

L’audit quindi segna G1 e G2 come un dominio, verifica indirizzo e codice del modulo, prova l’annullamento da un dispositivo sicuro, conferma l’evento che avvia il ritardo e controlla se un amministratore può sostituire subito il modulo. Non esegue un recupero reale sull’account con asset senza un processo di test documentato e reversibile in sicurezza.

Rischi e controlli

Guardiani correlati: usa dispositivi, credenziali, persone o custodi davvero indipendenti; prova le procedure senza riunire le seed phrase.
Modulo o esecutore troppo potente: ispeziona codice installato e ambito esatto. Rimuovi moduli inutili con il percorso documentato e verifica on-chain.
Soglia debole: valuta resistenza all’acquisizione e disponibilità. Una soglia nominale alta non aiuta se i firmatari condividono un dominio; una soglia irraggiungibile blocca l’account.
Ritardo assente o aggirabile: verifica on-chain ritardo, evento iniziale, chi può ridurlo e ogni percorso di cambio immediato.
Annullamento inefficace: prova rilevamento e annullamento, conserva gas nativo e una via di invio indipendente se necessaria e verifica se servono vecchio proprietario, quorum o altro ruolo.
Acquisizione tramite upgrade: monitora implementazione, beacon e amministratore. Chi può aggiornare senza ritardo può cambiare tutte le regole documentate.
Interfaccia malevola o obsoleta: verifica chain, account, modulo, proprietario proposto, soglia, ritardo e calldata. Non rivelare mai seed phrase o chiave privata a un servizio di «recupero».
Falsa finalizzazione: dopo annullamento o finalizzazione conferma ricevuta e storage finale. Verifica che proprietario e moduli voluti siano attivi e la proposta indesiderata non sia eseguibile.

Se appare un recupero non autorizzato, smetti di firmare richieste non correlate e conserva ID della proposta, hash, calldata, blocco, indirizzo del modulo e stato. Da un dispositivo sicuro verifica l’allarme con un RPC indipendente, usa l’annullamento documentato se disponibile e monitora finalizzazione, upgrade, moduli e trasferimenti. Se il controllo può essere perso, segui un piano d’incidente già scritto e contatti autenticati; un trasferimento improvvisato può subire front-running o rivelare la destinazione.

Idee sbagliate comuni

«Solo il proprietario può spostare gli asset.» Validatori, esecutori, moduli, contratti di recupero o codice aggiornato possono offrire altri percorsi.
«Tre guardiani sono tre parti indipendenti.» Il contratto conta approvazioni di indirizzi; non rileva dispositivi, backup o amministratori condivisi.
«Un ritardo di 24-hour garantisce tempo per reagire.» Servono monitoraggio, annullamento utilizzabile, gas e inclusione; un’altra via privilegiata può aggirarlo.
«Rimuovere un guardiano termina il suo accesso.» Conferma la configurazione finale e controlla altri ruoli, moduli, chiavi di sessione e recuperi pendenti collegati.
«Il supporto può ripristinare qualsiasi smart account.» Solo i poteri codificati o preconfigurati on-chain possono modificare un account in autocustodia. Senza proprietario o recupero validi, l’accesso può perdersi per sempre.