Perché gli EOA sono obsoleti: cosa fa davvero uno smart account

Ad aprile 2026, BundleBear registra oltre 1.07 miliardi di UserOperation ERC-4337 e 56.7 milioni di smart account che hanno effettuato almeno una transazione su Ethereum e sulle principali L2. Non si tratta più di una nicchia. L’account a chiave singola, basato esclusivamente su secp256k1, con cui Ethereum è stato lanciato nel 2015 viene aggirato su larga scala, e i numeri on-chain stanno raggiungendo una realtà più silenziosa, già presente a livello di protocollo: l’account stesso è ormai programmabile.

Questa è la prima parte di una serie in cinque puntate sugli smart account. L’obiettivo è circoscritto, ma fondamentale: spiegare che cos’è davvero un EOA, che cos’è davvero uno smart account e perché «smart account o EOA» non è più una preferenza di UX, ma una scelta strutturale su come viene applicata la tua autocustodia.

Che cos’è davvero un EOA a livello di protocollo

Il Yellow Paper di Ethereum definisce due tipi di account: gli Externally Owned Account e i Contract Account. L’unica differenza a livello di stato tra i due è il campo codeHash. Per un EOA, codeHash è l’hash della stringa vuota. Per un contract account, punta al bytecode EVM eseguibile. A livello di protocollo, la distinzione si esaurisce qui.

Un EOA, quindi, non è un «wallet» in senso proprio. È un indirizzo ricavato dagli ultimi 20 byte di keccak256(public key), con la coppia di chiavi vincolata alla curva secp256k1. MetaMask, Ledger e Zelcore sono interfacce utente che custodiscono la chiave. Non sono l’account. Se non conosci ancora il meccanismo alla base, la nostra guida introduttiva a chiavi pubbliche e private e a come si ricava un indirizzo lo spiega nel dettaglio.

Fino all’introduzione di ERC-4337 nel 2023, tutte le transazioni su Ethereum dovevano provenire da un EOA e il protocollo applicava una sola regola di convalida: una firma secp256k1 valida sull’hash della transazione. Mantenere un saldo, firmare una transazione alla volta con ECDSA e pagare il gas in ETH dallo stesso account: questo è tutto ciò che un EOA può fare. Non può fare altro.

I limiti strutturali che contano per chi usa Ethereum

Non sono semplici inconvenienti dell’esperienza utente. Sono il motivo strutturale alla base della maggior parte delle perdite legate all’autocustodia che continuiamo a vedere nel 2026.

• Un solo punto di vulnerabilità. Una sola chiave privata controlla tutto. Se la perdi, perdi l’account. Se viene esposta, perdi i fondi in modo irreversibile. Il protocollo non prevede alcun meccanismo di recupero: è proprio per questo che una singola frase seed è il principale punto di vulnerabilità nell’autocustodia.
• Una sola curva. secp256k1 è definita nel codice. Non puoi usare una passkey (P-256), una chiave Ed25519, BLS o uno schema post-quantistico.
• Nessuna multisig nativa. Ogni «multisig» su Ethereum, dall’originale Gnosis Multisig a Safe, è un contratto chiamato da un EOA. L’EOA stesso non può mai richiedere due firme.
• Nessuna operazione in batch. Un EOA esegue una sola operazione per transazione. Approvare un token e poi scambiarlo richiede due transazioni firmate, due conferme e due pagamenti del gas.
• Nessuna regola di spesa. Il protocollo non prevede condizioni come «questa chiave può spendere fino a $500 al giorno» o «questa chiave può chiamare solo Uniswap».
• Il gas deve essere pagato in ETH dallo stesso account che esegue l’operazione. Non sono previsti nativamente né la sponsorizzazione del gas né i pagamenti in USDC.

È il contenitore in cui ogni utente di Ethereum è stato costretto per un decennio.

Che cos’è davvero uno smart account

In senso letterale, a livello di protocollo, uno smart account è un contract account: un indirizzo il cui campo codeHash punta al bytecode. Il bytecode stabilisce le regole in base alle quali l’account accetta un’operazione.

La regola di convalida di un EOA è un unico controllo secp256k1 predefinito; quella di uno smart account è invece ciò che stabilisce il contratto. Può prevedere una multisig 2 su 3, una firma con passkey verificata sulla curva secp256r1, una chiave attestata da hardware, un blocco temporale, un limite giornaliero, un destinatario di chiamata autorizzato o una combinazione di queste condizioni. Gli account smart contract convalidano le firme secondo lo standard EIP-1271, anziché applicare il controllo secp256k1 fisso a livello di protocollo: è proprio questo che rende possibili schemi di firma alternativi.

Essendo definite nel codice, le regole possono essere aggiornate, combinate e revocate. Gli smart account esistono su Ethereum dal 2018 (Safe ne è l’esempio di riferimento). Mancava un modo per renderli l’opzione predefinita e inviare transazioni senza che un EOA pagasse prima il gas. ERC-4337 ed EIP-7702 hanno colmato questa lacuna.

Come ci siamo arrivati: breve storia dell’astrazione degli account

L’idea di unificare EOA e contratti è antica quanto Ethereum. L’EIP-86 di Vitalik, redatto nel 2016, è stata la prima proposta dettagliata. Da lì agli standard implementati oggi ci sono voluti cinque tentativi.

• EIP-2938 (settembre 2020) proponeva l’astrazione degli account a livello di protocollo. Fu abbandonata perché troppo invasiva, mentre Ethereum era nel pieno della transizione al proof of stake.
• EIP-3074 (ottobre 2020) introduceva gli opcode AUTH e AUTHCALL, che consentivano a un EOA di delegare a un contratto invoker. Fu ritirata per problemi di sicurezza e sostituita.
• ERC-4337 è stata attivata sulla mainnet di Ethereum il 1 marzo 2023. Agisce solo a livello applicativo, senza hard fork, e instrada pseudo-transazioni chiamate UserOperation attraverso un mempool separato, un Bundler e un contratto EntryPoint singleton.
• EIP-7702 è stata introdotta con l’aggiornamento Pectra il 7 maggio 2025. Introduce il tipo di transazione 0x04, con cui un EOA firma una tupla di autorizzazione (chain_id, address, nonce, y_parity, r, s) che indirizza l’account al codice di un contratto delegato tramite l’indicatore 0xef0100 || address. L’EOA si comporta temporaneamente come uno smart account, senza trasferire i fondi.
• ERC-6900 standardizza l’architettura modulare a plug-in che consente agli smart account di combinare moduli di convalida, esecuzione e hook.

In sintesi, l’astrazione degli account non è più un esperimento. È uno standard implementato e articolato su più livelli: ERC-4337 offre un percorso lineare per creare smart account da zero, mentre EIP-7702 permette a ogni EOA esistente di aderirvi.

Le cinque funzionalità che uno smart account aggiunge

Se un EOA significa «una chiave, una firma, una transazione», uno smart account offre un insieme di funzionalità che lo comprende e lo supera.

• Convalida programmabile. Qualsiasi schema di firma (passkey, P-256, HSM hardware), qualsiasi quorum (2 su 3, 3 su 5), qualsiasi condizione (altezza del blocco, prezzo indicato da un oracolo). È l’account a decidere che cosa significa «autorizzato».
• Operazioni atomiche in batch. Approva, scambia e deposita con un’unica operazione firmata. O viene eseguito tutto, oppure non viene eseguito nulla. Questo elimina direttamente il debito da approvazioni e il modello multisig in Zelcore, soluzioni alternative che gli utenti hanno dovuto gestire manualmente.
• Astrazione del gas tramite paymaster. Un contratto di terze parti paga il gas per conto dell’utente, oppure l’utente paga in USDC, USDT o qualsiasi ERC-20 accettato dal paymaster. Per approfondire come si collegano gas, approvazioni e meccanismi DeFi, leggi prima l’articolo sui fondamenti della DeFi.
• Chiavi di sessione. Chiavi di firma limitate per ambito, durata e app. «Questa chiave può spendere fino a 100 USDC su Uniswap nelle prossime 24 ore». Se una chiave di sessione viene compromessa, i danni sono limitati dalle regole, non dal saldo dell’account.
• Recupero. Recupero sociale, tramite hardware o con blocco temporale. L’account può essere recuperato senza la chiave di firma originale: così la frase seed smette finalmente di essere un elemento che costituisce un singolo punto di vulnerabilità.

Perché oggi è un elemento fondamentale per l’autocustodia

La crescita dell’adozione non è più oggetto di dibattito. EIP-7702 ha superato le 11.000 autorizzazioni nella prima settimana dopo Pectra e poco dopo ha oltrepassato quota 25.000 wallet, con OKX e MetaMask in testa. I totali cumulativi di BundleBear (1.07B UserOps, 56.7M smart account) completano il quadro.

Ciò che cambia davvero è il modello delle minacce. Con un EOA, il compito dell’utente è «proteggere per sempre la frase seed, non firmare mai una transazione malevola, non cadere mai vittima di phishing, non riutilizzare mai il dispositivo sbagliato». È un compito che gli esseri umani, come dimostrato, non riescono a svolgere. Con uno smart account, invece, il compito dell’utente è «configurare una volta una soglia di approvazione per il recupero e una policy di spesa». È un compito che il codice può far rispettare.

Uno smart account non sostituisce un hardware wallet. Permette di fare di più con un hardware wallet e, di fatto, circoscrive il ruolo che un hardware wallet continua a svolgere per uno smart account alle operazioni principali per cui è più utile: firmare le operazioni master di alto valore e poco frequenti, lasciando le attività quotidiane alle chiavi di sessione.

Cosa ci aspetta nei prossimi articoli

Abbiamo definito il contesto. Il resto della serie entra nel merito operativo.

• Parte 2 analizza lo stack ERC-4337: UserOperations, Bundler, EntryPoint, Paymaster e i possibili punti di errore per ciascuno.
• Parte 3 approfondisce la delega EIP-7702: la tupla di autorizzazione, l’indicatore 0xef0100 e le considerazioni di sicurezza legate a indirizzare il proprio EOA verso il codice di qualcun altro.
• Parte 4 confronta le principali implementazioni di smart account (Coinbase Smart Wallet, Safe, Argent, Ambire) e le impostazioni predefinite di ciascuna.
• Parte 5 conclude con gli aspetti operativi: configurare il recupero, le chiavi di sessione e la policy di spesa su un account reale senza rinunciare all’autocustodia.

La frase da ricordare per la Parte 2 è: un EOA è una chiave con un indirizzo; uno smart account è un contratto che decide cosa la sua chiave può fare.