EIP-7702 permette a un account Ethereum controllato da una chiave privata di delegare l’esecuzione a un contratto. Il risultato può essere un wallet con operazioni raggruppate, gas pagato da un altro soggetto e permessi applicativi più flessibili. Il punto di sicurezza è altrettanto importante: non stai semplicemente autorizzando un token, ma scegliendo codice che opererà nel contesto del tuo account.
La delegazione non scade automaticamente alla fine di una singola transazione. Può restare attiva finché non viene sostituita o rimossa correttamente. Per questo una richiesta di firma non va accettata soltanto perché promette gas gratuito, un airdrop o una comoda attivazione. Questa guida spiega cosa cambia, come distinguere le autorizzazioni e quali controlli fare senza improvvisare procedure di recupero.
EIP-7702: account, chiave privata e codice delegato
Un account esterno, o EOA, è tradizionalmente controllato attraverso una chiave privata. EIP-7702 introduce la possibilità di indicare un contratto il cui codice viene eseguito nel contesto di quell’account. L’indirizzo resta lo stesso e la chiave originale continua ad avere un ruolo fondamentale. Non nasce automaticamente un nuovo portafoglio con una sicurezza superiore.
La novità riguarda il comportamento dell’account. Un’implementazione ben progettata può aggiungere funzioni utili, ma la qualità di queste funzioni dipende dal codice scelto e dai suoi controlli. La delegazione è il meccanismo di base; limiti di spesa, chiavi di sessione e recovery sono caratteristiche dell’implementazione, non garanzie offerte indistintamente dal protocollo.
Se vuoi chiarire prima la differenza tra controllo delle chiavi e servizio di custodia, parti dalla guida ai wallet crypto. Il fatto che un’interfaccia sia semplice non elimina il bisogno di capire chi può firmare e quali operazioni vengono autorizzate.
Cosa può migliorare nell’uso quotidiano
Il batching può riunire più operazioni in una singola esecuzione. Un’applicazione potrebbe, per esempio, organizzare un’approvazione e un successivo scambio in un flusso meno frammentato. Bisogna però verificare che il codice garantisca davvero il comportamento atteso: raggruppare azioni non significa che ciascuna sia sicura o economicamente conveniente.
La sponsorizzazione permette a un altro soggetto di sostenere il costo della transazione. Questo può evitare di comprare ETH prima di un’operazione, ma non rende il gas inesistente. Qualcuno paga; il servizio può recuperare il costo attraverso commissioni, condizioni commerciali o un altro asset. Leggi il prezzo complessivo, non soltanto l’etichetta “gasless”.
Un wallet può inoltre costruire permessi più limitati sopra il codice delegato. Una chiave di sessione potrebbe essere vincolata a un’applicazione o a una soglia di spesa. Quei limiti devono essere realmente implementati e verificabili. Non basta che il sito li descriva: la domanda è quale codice li fa rispettare e con quali possibilità di aggiornamento.
Perché non è una normale approvazione token
Un’approvazione ERC-20 consente a uno spender di utilizzare una certa quantità di un determinato token. Una firma Permit o Permit2 segue un altro percorso autorizzativo, ma resta legata a specifiche capacità definite dai relativi contratti. La delegazione modifica invece il codice eseguito nel contesto dell’account.
| Operazione | Oggetto del controllo | Domanda da fare |
|---|---|---|
| Approvazione token | Spender e importo autorizzato | Chi può spendere questo token? |
| Permit o Permit2 | Firma e autorizzazioni del relativo sistema | Quali asset e limiti sono coinvolti? |
| Delegazione | Codice associato all’account | Quale implementazione governerà le operazioni? |
La guida a Permit2 e revoca delle firme serve proprio a non confondere questi livelli. Revocare un’approvazione token non rimuove automaticamente una delegazione. Rimuovere la delegazione, a sua volta, non cancella tutte le approvazioni esistenti.
La persistenza è il dettaglio da ricordare
Nel modello definitivo la delegazione è persistente. Pensarla come un permesso valido soltanto durante il click corrente porta a sottovalutare le conseguenze. Una firma può preparare un’autorizzazione che viene presentata in una transazione, e il codice delegato può continuare a essere associato all’account dopo quell’esecuzione.
Esiste inoltre una distinzione fra elaborazione dell’autorizzazione e successo dell’operazione successiva. Una transazione che termina con un errore non implica necessariamente che la delegazione elaborata sia stata annullata. Dopo un tentativo fallito non dedurre lo stato dalla sola scritta “failed”: controlla ciò che il wallet e la catena riportano sull’account.
Un esempio pratico: un sito promette uno scambio sponsorizzato, lo scambio fallisce e l’utente chiude la pagina. Non è prudente assumere che tutto sia tornato alla condizione precedente. Il controllo corretto riguarda anche l’eventuale delegazione installata, non soltanto il saldo o la ricevuta dello scambio.
Indirizzo del contratto, rete e nonce
L’autorizzazione contiene informazioni che identificano il codice indicato, la rete o il suo ambito e il nonce dell’account. Non sono dettagli decorativi. Il contratto può essere sicuro su una rete e diverso, assente o non verificato su un’altra. Un indirizzo simile a quello ufficiale non è sufficiente.
Il protocollo contempla anche un valore di chain ID pari a zero con un ambito non limitato a una sola catena. Ciò non significa che ogni firma funzioni ovunque: restano condizioni come nonce e supporto della rete. Significa però che il wallet deve rendere comprensibile l’ambito autorizzato, anziché nasconderlo dietro un messaggio generico.
Per l’utente, il controllo sensato non è ricostruire a mano la codifica della firma. È utilizzare implementazioni supportate e documentate dal wallet, verificare la rete e rifiutare delegazioni verso indirizzi arbitrari suggeriti da un’applicazione. La documentazione ufficiale del wallet vale più di una schermata promozionale del sito collegato.
Il rischio maggiore: delegare codice non affidabile
Codice eseguito nel contesto dell’account può avere conseguenze molto più estese di una semplice lettura del saldo. Un’implementazione malevola o difettosa può compromettere gli asset o le autorizzazioni. La verifica del contratto su un esploratore aiuta a identificare ciò che è stato distribuito, ma non costituisce un audit di sicurezza.
Chiedi quali revisioni indipendenti esistono, quali parti sono aggiornabili e chi controlla gli aggiornamenti. Un audit riguarda una versione e un perimetro precisi, non garantisce ogni futura configurazione. Anche un wallet conosciuto dovrebbe spiegare chiaramente quale implementazione propone e come gestire un problema.
Non firmare una delegazione arbitraria per “verificare il wallet”, ricevere un premio o correggere un presunto errore. I truffatori possono presentare una modifica profonda come un passaggio di routine. Se l’interfaccia non distingue tra accesso a un sito e controllo dell’account, fermarsi è più sicuro che approvare per tentativi.
Come ragionare sulla rimozione
Il meccanismo prevede che una nuova autorizzazione verso l’indirizzo zero possa rimuovere il codice di delegazione. Va eseguita attraverso strumenti affidabili e compatibili, verificando successivamente lo stato sulla rete corretta. Non utilizzare istruzioni ricevute da sconosciuti e non importare la seed phrase in un presunto servizio di pulizia.
La rimozione non è un reset universale: non cancella automaticamente lo storage dell’account, le approvazioni dei token o ogni permesso creato da applicazioni diverse. Può quindi essere necessario controllare separatamente quei livelli. In presenza di una chiave privata compromessa, rimuovere la delegazione non rende di nuovo segreta la chiave.
Anche le autorizzazioni firmate ma non ancora utilizzate meritano attenzione. Non assumere che scollegare un sito cancelli firme già consegnate. La gestione concreta richiede strumenti del wallet e conoscenza dello stato dell’account. Per importi importanti o un incidente attivo, cerca assistenza tecnica qualificata invece di concatenare operazioni non comprese.
Hardware wallet: aiuta, ma serve supporto reale
Un dispositivo hardware protegge la custodia della chiave, ma non rende automaticamente innocua una firma autorizzata dall’utente. Se lo schermo non spiega il tipo di autorizzazione o mostra dati incomprensibili, la sicurezza pratica può ridursi. Verifica il supporto del produttore e del software che comunica con il dispositivo.
La guida agli hardware wallet chiarisce il limite: separare la chiave dal computer è utile, ma resta necessario leggere ciò che si approva. Non aggirare una mancata compatibilità disattivando avvisi o seguendo configurazioni suggerite da un sito sconosciuto.
Una prova riuscita non dimostra tutto
Un test conferma soltanto che una particolare operazione ha funzionato in quelle condizioni. Non dimostra che tutti i permessi siano limitati o che ogni aggiornamento futuro sia sicuro. Annota rete e implementazione, controlla lo stato descritto dal wallet e verifica se le operazioni successive usano un diverso percorso di firma.
Distingui inoltre ciò che l’interfaccia mostra da ciò che il codice impone. Un campo con un limite giornaliero è una protezione soltanto se viene applicato correttamente. Chiudere la pagina non elimina diritti già concessi. Se il tipo di autorizzazione non corrisponde alla documentazione ufficiale, interrompi il test: una somma piccola non rende innocua una modifica ampia del controllo dell’account.
Conserva soltanto le informazioni pubbliche necessarie a ricostruire il test; chiavi private e parole di recupero non devono comparire nei ticket di assistenza.
Checklist prima di attivare un account delegato
- Il wallet documenta il supporto e la rete interessata?
- L’implementazione è quella verificata dal wallet, non un indirizzo arbitrario?
- È chiaro chi paga il gas e quali costi restano?
- I limiti dichiarati sono implementati, e chi può cambiarli?
- Conosci la procedura supportata per verificare e rimuovere la delegazione?
- Hai distinto delegazione, approvazioni token e firme già consegnate?
Il vantaggio di EIP-7702 è rendere più flessibile l’uso di un account esistente. La scelta corretta, però, non è attivare qualsiasi funzione nuova: è capire quale codice stai autorizzando e quali controlli lo limitano. Una migliore esperienza utente è utile soltanto se non nasconde una decisione di sicurezza più ampia di quella che pensavi di prendere.
Fonti primarie, verificate il 30 settembre 2026: specifica EIP-7702; Ethereum: EIP-7702 e Pectra; documentazione Ethereum. Questa è una guida di comprensione dei rischi, non una procedura universale di recupero né una raccomandazione finanziaria.
