Account Abstraction: ERC-4337 e il futuro della UX crypto

Il mondo crypto ha un problema di esperienza utente. Dopo oltre un decennio di sviluppo, interagire con una blockchain richiede ancora la gestione di una seed phrase di 12 parole che non potrà mai essere recuperata se persa, il mantenimento di un saldo in token nativo solo per pagare le commissioni gas su ogni transazione, e la firma di messaggi esadecimali criptici senza un contesto chiaro. Questi non sono casi limite -- sono l'esperienza predefinita per ogni nuovo utente. E rappresentano la singola barriera più grande all'adozione mainstream della blockchain.

L'account abstraction è il miglioramento UX più significativo nella storia di Ethereum. Sostituisce il modello di account rigido e dipendente dalle chiavi con wallet smart contract programmabili che possono implementare qualsiasi logica di autenticazione, sponsorizzare il gas per gli utenti, recuperare l'accesso attraverso contatti fidati ed eseguire batch di operazioni multiple in un singolo click. Questa guida offre un walkthrough tecnico completo di come funziona l'account abstraction, gli standard che la rendono possibile e come i team di sviluppo possono costruire con essa oggi.

Il problema UX degli Externally Owned Account

Ethereum ha due tipi di account: externally owned account (EOA) e contract account. Dal lancio della rete nel 2015, ogni interazione rivolta all'utente è stata iniziata da un EOA -- un account controllato da una singola chiave privata derivata da una seed phrase. Questo design aveva senso come punto di partenza, ma ha creato un insieme di vincoli UX che sono fondamentalmente incompatibili con l'adozione mainstream.

Il primo problema è la gestione delle chiavi. Una seed phrase è un singolo punto di guasto senza meccanismo di recupero. Se la perdi, i tuoi fondi sono persi permanentemente. Se qualcun altro la ottiene, i tuoi fondi sono persi permanentemente. Non esiste un reset della password, nessun supporto clienti e nessun recupero dell'account. L'intero modello di sicurezza si basa sull'assunzione che ogni utente possa conservare in modo sicuro e non perdere mai una sequenza di 12 parole casuali -- un'assunzione che fallisce regolarmente, anche tra gli utenti tecnici.

Il secondo problema è il gas. Ogni transazione su Ethereum richiede che il mittente paghi il gas in ETH. Ciò significa che anche se un utente riceve USDC, un NFT o qualsiasi altro token, non può farci nulla finché non acquisisce anche ETH. Per i nuovi utenti, questo crea un problema dell'uovo e della gallina: hanno bisogno di ETH per usare l'applicazione, ma acquisire ETH è di per sé un processo a più passaggi che coinvolge exchange, KYC e bridging. Le applicazioni perdono utenti a ognuno di questi punti di frizione.

Il terzo problema è la rigidità delle transazioni. Un EOA può eseguire solo un'operazione per transazione, deve firmare ogni operazione individualmente e non può applicare logica di validazione personalizzata. Non è possibile impostare limiti di spesa, richiedere approvazione multi-party, automatizzare pagamenti ricorrenti o delegare permessi temporanei -- tutte funzionalità che il software finanziario tradizionale fornisce di default. Ogni transazione richiede la chiave privata completa per firmare, ogni volta, senza eccezioni.

Cosa significa realmente account abstraction

L'account abstraction è il concetto di rendere ogni account su Ethereum uno smart contract. Invece di account controllati da una singola chiave privata con verifica della firma ECDSA hardcoded, gli account diventano programmabili -- possono definire la propria logica di validazione, eseguire codice arbitrario durante le transazioni e implementare qualsiasi schema di autenticazione scelto dallo sviluppatore.

La parola abstraction qui è usata nel senso informatico: separare l'interfaccia dall'implementazione. Attualmente, il protocollo di Ethereum codifica rigidamente come funzionano gli account -- firme ECDSA, controllo a chiave singola, pagamento del gas da parte del mittente. L'account abstraction rimuove queste assunzioni hardcoded e permette a ogni account di definire le proprie regole. Al protocollo importa solo che l'account dica che la transazione è valida, non come determina la validità.

Questo non è un miglioramento marginale. È uno shift architetturale che trasforma ciò che un account blockchain può essere. Uno smart contract account può verificare firme da qualsiasi schema -- ECDSA, Ed25519, BLS, passkey o multisig. Può implementare il social recovery attraverso indirizzi guardian. Può raggruppare molteplici operazioni in una singola transazione atomica. Può delegare permessi con session key che scadono. E può farsi pagare il gas da una terza parte, così gli utenti non devono mai possedere ETH.

Il percorso verso ERC-4337: una breve storia

L'account abstraction non è un'idea nuova. La comunità Ethereum ci lavora fin dai primi giorni della rete, ma il percorso è stato lungo e complesso perché le implementazioni più ovvie richiedevano modifiche al protocollo di base di Ethereum -- modifiche difficili da coordinare e rischiose da deployare.

EIP-86, proposto da Vitalik Buterin nel 2017, è stata una delle prime proposte formali. Suggeriva di permettere alle transazioni di originare da qualsiasi indirizzo (non solo dagli EOA) e di consentire ai contratti di pagare il proprio gas. Tuttavia, richiedeva modifiche profonde al formato delle transazioni e alla pipeline di validazione, rendendolo troppo rischioso per un hard fork. EIP-2938, proposto nel 2020, ha raffinato l'approccio introducendo un nuovo tipo di transazione specificamente per l'account abstraction, ma richiedeva comunque modifiche al livello di consenso e affrontava le stesse sfide di deployment.

ERC-4337, scritto da Vitalik Buterin, Yoav Weiss, Kristof Gazso, Namra Patel, Dror Tirosh e Shahaf Nacson, ha adottato un approccio fondamentalmente diverso. Pubblicato nel 2021 e deployato sulla mainnet di Ethereum a marzo 2023, raggiunge l'account abstraction interamente a livello applicativo -- senza alcuna modifica al protocollo. Lo fa introducendo un sistema di transazioni di livello superiore che funziona sopra l'infrastruttura esistente di Ethereum, utilizzando un mempool separato, attori specializzati chiamati bundler e uno smart contract singleton chiamato EntryPoint.

Approfondimento dell'architettura ERC-4337

Comprendere ERC-4337 richiede di comprendere le sue cinque componenti principali: UserOperation, il mempool alternativo, i Bundler, il contratto EntryPoint e i Paymaster. Ciascuno svolge un ruolo distinto nel sistema, e insieme replicano la funzionalità della pipeline di transazioni nativa di Ethereum -- ma con account programmabili al posto degli EOA.

UserOperation

Una UserOperation (o UserOp) è l'equivalente ERC-4337 di una transazione. È una struttura dati che descrive ciò che uno smart contract account vuole fare. A differenza di una transazione tradizionale, firmata con una chiave privata e inviata direttamente al mempool di Ethereum, una UserOp viene inviata a un mempool alternativo dove i bundler la raccolgono per l'elaborazione.

Una UserOp contiene campi analoghi a una transazione regolare -- sender, nonce, calldata, limiti di gas -- più campi aggiuntivi specifici dell'account abstraction: initCode (per il deploy dell'account al primo utilizzo), paymasterAndData (per la sponsorizzazione del gas) e signature (che può essere in qualsiasi formato atteso dal contratto dell'account, non necessariamente ECDSA). Il campo sender è l'indirizzo dello smart contract account, non di un detentore di chiave privata.

Bundler

I Bundler sono attori off-chain che monitorano il mempool delle UserOperation, raccolgono le UserOp valide e le raggruppano in una singola transazione Ethereum regolare. Il bundler chiama la funzione handleOps del contratto EntryPoint, passando un array di UserOp. Dal punto di vista del protocollo Ethereum, si tratta di una transazione standard inviata dall'EOA del bundler -- il protocollo non ha alcuna conoscenza dell'account abstraction.

I Bundler svolgono un ruolo analogo ai block builder nella pipeline di transazioni esistente di Ethereum. Validano le UserOp, simulano l'esecuzione, ordinano le operazioni e inviano il bundle on-chain. Sono compensati attraverso rimborsi gas e mance opzionali. Chiunque può eseguire un bundler, e esistono molteplici servizi di bundler -- da Rundler di Alchemy a Stackup, Pimlico e Biconomy.

Il contratto EntryPoint

L'EntryPoint è uno smart contract singleton deployato a un indirizzo canonico su ogni catena EVM. È il coordinatore centrale dell'intero sistema ERC-4337. Quando un bundler invia un batch di UserOp, l'EntryPoint elabora ciascuna attraverso un modello di esecuzione a due fasi.

Nella fase di verifica, l'EntryPoint chiama la funzione validateUserOp sullo smart contract account del mittente. L'account può implementare qualsiasi logica di validazione -- verificare una firma ECDSA, validare una soglia multi-sig, verificare un'asserzione passkey o qualsiasi schema personalizzato. Se la validazione ha successo, l'EntryPoint procede alla fase di esecuzione, dove chiama il contratto dell'account per eseguire l'operazione effettiva descritta nel calldata della UserOp. Questo modello a due fasi assicura che la validazione sia separata dall'esecuzione, impedendo ad account malevoli di manipolare il bundler.

Paymaster

I Paymaster sono il componente che abilita le transazioni gasless -- il singolo miglioramento UX più impattante nell'account abstraction. Un Paymaster è uno smart contract che accetta di pagare i costi del gas per una UserOperation per conto dell'utente. Quando una UserOp include un campo paymasterAndData, l'EntryPoint chiama la funzione validatePaymasterUserOp del Paymaster per confermare che sponsorizzerà il gas.

I modelli di business per i Paymaster sono diversificati. Un'applicazione può sponsorizzare il gas per tutti gli utenti per rimuovere l'attrito (come le web app non addebitano agli utenti le richieste HTTP). Un Paymaster può accettare token ERC-20 come pagamento, così gli utenti pagano il gas in USDC o DAI invece che in ETH. Un Paymaster può implementare modelli di abbonamento, tier gratuiti o sponsorizzazione condizionale basata sul comportamento dell'utente. L'intuizione chiave è che il pagamento del gas è completamente disaccoppiato dall'utente -- qualcun altro può pagare, e l'esperienza utente diventa indistinguibile da un'applicazione web tradizionale.

Aggregator

Gli Aggregator sono un componente opzionale ma potente per la scalabilità. Permettono a molteplici UserOperation che utilizzano lo stesso schema di firma di avere le loro firme aggregate in un'unica prova compatta. Per le firme BLS, ad esempio, centinaia di firme individuali possono essere combinate in una sola, riducendo drasticamente i dati on-chain e il costo del gas per UserOp. Sebbene non ancora ampiamente adottati, gli aggregator diventano sempre più importanti man mano che l'account abstraction scala a milioni di utenti.

Capacità chiave abilitate dall'account abstraction

L'architettura descritta sopra non è solo un refactoring tecnico -- abilita esperienze utente completamente nuove che erano precedentemente impossibili con gli EOA.

• Transazioni gasless: i Paymaster permettono alle applicazioni di sponsorizzare il gas, consentendo agli utenti di interagire con le dApp senza mai acquisire ETH. Questo singolo cambiamento rimuove la barriera di onboarding più comune nel mondo crypto.
• Social recovery: invece di affidarsi a una seed phrase, gli utenti possono designare indirizzi guardian -- amici, familiari o custodi istituzionali -- che possono collettivamente autorizzare una rotazione delle chiavi se l'utente perde l'accesso. Nessun singolo guardian può agire da solo, e l'utente mantiene il pieno controllo durante il funzionamento normale.
• Session key: gli smart account possono emettere chiavi temporanee con permessi limitati che consentono a un'applicazione di inviare transazioni per conto dell'utente senza richiedere una firma per ciascuna. Un'applicazione di gaming può richiedere una session key valida per 30 minuti con un limite di spesa, abilitando un gameplay fluido senza popup del wallet costanti.
• Transazioni batch: molteplici operazioni possono essere raggruppate in una singola transazione atomica. Un utente DeFi può approvare un token, scambiarlo e mettere in staking il risultato in un solo click invece di tre transazioni separate, ciascuna con conferma e pagamento del gas.
• Multi-signature con UX migliore: gli smart account possono richiedere l'approvazione di più parti per una transazione presentando un'interfaccia semplice. Le tesorerie aziendali possono imporre policy di approvazione two-of-three, limiti di spesa e indirizzi in whitelist -- il tutto applicato dal contratto dell'account stesso.
• Logica di validazione personalizzata: gli account possono utilizzare qualsiasi metodo di autenticazione -- passkey WebAuthn (autenticazione biometrica tramite impronta digitale o Face ID), moduli di sicurezza hardware, approvazioni time-locked, restrizioni geografiche o qualsiasi combinazione. L'account definisce la propria policy di sicurezza.

Implementazioni nel mondo reale

L'account abstraction non è teorica -- è deployata sulla mainnet e utilizzata da milioni di account in tutto l'ecosistema EVM. Sono emerse diverse implementazioni principali, ciascuna con un focus e un pubblico target diverso.

Safe (precedentemente Gnosis Safe) è il wallet smart contract più collaudato, che protegge oltre 100 miliardi di dollari in asset. Originariamente progettato per wallet multi-signature, Safe ha adottato la compatibilità ERC-4337, consentendo alla sua architettura modulare di integrarsi con bundler e paymaster. Il sistema di moduli di Safe permette agli sviluppatori di estendere le funzionalità del wallet aggiungendo moduli per social recovery, policy di spesa, strategie DeFi automatizzate e altro -- il tutto senza modificare il contratto del wallet principale.

ZeroDev fornisce un SDK orientato agli sviluppatori costruito sullo smart account Kernel, un account ERC-4337 leggero e modulare. L'architettura kernel di ZeroDev utilizza validator (per la verifica personalizzata delle firme), executor (per la logica di transazione estesa) e hook (per i controlli pre/post esecuzione). Il suo SDK astrae la complessità di UserOp, bundler e paymaster in semplici chiamate API, rendendo semplice per gli sviluppatori integrare l'account abstraction nelle applicazioni esistenti.

Biconomy offre una piattaforma di account abstraction full-stack con il suo smart account Nexus, l'infrastruttura bundler e il servizio Paymaster. Il loro SDK supporta session key, transazioni batch e operazioni cross-chain immediatamente. Biconomy si è concentrata fortemente sull'esperienza sviluppatore, fornendo React hook drop-in e una dashboard per la gestione delle policy di sponsorizzazione del gas.

L'Account Kit di Alchemy fornisce un livello di infrastruttura end-to-end che combina un'implementazione di smart account (Modular Account), un bundler ad alte prestazioni (Rundler, scritto in Rust) e API per la gestione del gas. La loro soluzione di embedded wallet integra login tramite email e social con smart account, creando un'esperienza di onboarding in cui gli utenti creano un account blockchain usando le credenziali Google senza mai vedere una seed phrase o una commissione gas.

ERC-7702 e l'aggiornamento Pectra: account abstraction nativa

Mentre ERC-4337 raggiunge l'account abstraction a livello applicativo, ERC-7702 -- incluso nell'aggiornamento Pectra di Ethereum -- porta l'account abstraction nativa a livello di protocollo. Proposto da Vitalik Buterin e Sam Wilson, ERC-7702 introduce un nuovo tipo di transazione che permette a un EOA di delegare temporaneamente la propria logica di esecuzione a uno smart contract per la durata di una transazione.

Il meccanismo è elegantemente semplice. Un nuovo tipo di transazione include una lista di autorizzazione -- un insieme di coppie (indirizzo del contratto, firma). Quando la transazione viene elaborata, il campo code dell'EOA viene temporaneamente impostato su un designatore di delega che punta al contratto specificato. Per quella transazione, l'EOA si comporta come se fosse uno smart contract, ottenendo accesso all'esecuzione batch, al gas sponsorizzato e alla logica di validazione personalizzata. Dopo il completamento della transazione, la delega persiste fino a revoca esplicita.

Questo è significativo perché risolve il problema della migrazione. Con ERC-4337, gli utenti devono deployare un nuovo smart contract account e migrare i loro asset dal loro EOA esistente -- un punto di attrito che ha rallentato l'adozione. ERC-7702 permette agli EOA esistenti di ottenere le capacità degli smart account in loco, senza spostare fondi o cambiare indirizzi. I miliardi di dollari detenuti negli EOA su Ethereum possono essere aggiornati senza un singolo trasferimento.

ERC-7702 ed ERC-4337 sono complementari, non in competizione. ERC-7702 gestisce l'aggiornamento degli account a livello di protocollo, mentre l'infrastruttura di ERC-4337 -- bundler, paymaster e il mempool delle UserOperation -- continua a fornire il livello di coordinamento off-chain. Insieme, creano uno stack di account abstraction completo che funziona sia per i nuovi smart account che per gli EOA aggiornati.

Impatto nei diversi settori

L'impatto dell'account abstraction si estende ben oltre una UX del wallet migliorata. Cambia fondamentalmente ciò che è possibile in ogni settore che tocca la blockchain.

DeFi: composabilità in un click

Nella DeFi, l'account abstraction abilita swap in un click che combinano l'approvazione del token e l'esecuzione in una singola transazione. Le strategie di yield farming che richiedono molteplici operazioni sequenziali -- deposito, staking, riscossione dei premi, reinvestimento -- possono essere raggruppate in un solo click. Il ribilanciamento automatico del portafoglio può essere delegato a una session key con limiti di spesa rigidi, eliminando la necessità per l'utente di approvare manualmente ogni ribilanciamento. E i Paymaster possono accettare il token scambiato come pagamento del gas, così un utente che scambia USDC per WBTC paga la commissione gas in USDC invece di aver bisogno di ETH.

Gaming: blockchain invisibile

Per il gaming su blockchain, l'account abstraction rende la blockchain invisibile al giocatore. Le session key permettono a un gioco di inviare transazioni -- muovere personaggi, creare oggetti, completare missioni -- senza un popup del wallet a ogni azione. Il gioco richiede una session key al login con un limite di tempo e un tetto di spesa, e il giocatore interagisce come farebbe con qualsiasi gioco tradizionale. Il gas è sponsorizzato dallo sviluppatore del gioco attraverso un Paymaster, così il giocatore non pensa mai all'ETH. La blockchain diventa infrastruttura, non interfaccia.

Enterprise: wallet con policy integrate

L'adozione enterprise della blockchain è stata ostacolata dalla mancanza di controlli di accesso e funzionalità di conformità negli EOA. L'account abstraction risolve questo direttamente. Una tesoreria aziendale può implementare uno smart account con controllo degli accessi basato sui ruoli -- il personale junior può iniziare trasferimenti fino a un certo limite, il personale senior può approvare importi maggiori e il CFO può autorizzare qualsiasi operazione. Gli indirizzi di destinazione in whitelist impediscono trasferimenti non autorizzati. Le operazioni time-locked aggiungono un periodo di revisione prima che le transazioni di importo elevato vengano eseguite. Questi non sono controlli a livello applicativo che possono essere aggirati -- sono applicati dal contratto dell'account stesso, on-chain e immutabili.

Considerazioni sulla sicurezza

I wallet smart contract introducono un modello di sicurezza diverso rispetto agli EOA, e i team che costruiscono con l'account abstraction devono comprendere i compromessi.

Il rischio dello smart contract è la preoccupazione più fondamentale. La sicurezza di un EOA dipende solo dalla chiave privata -- l'algoritmo ECDSA è ben compreso e non presenta vulnerabilità note. La sicurezza di uno smart contract account dipende dalla correttezza del suo codice. Un bug nel contratto del wallet, nei suoi moduli o nel meccanismo di aggiornamento potrebbe compromettere ogni account che utilizza quell'implementazione. Ecco perché le implementazioni collaudate come Safe, che ha protetto oltre 100 miliardi di dollari senza un exploit a livello di contratto, sono fortemente preferite rispetto alle implementazioni personalizzate.

I meccanismi di aggiornamento richiedono una progettazione attenta. La maggior parte delle implementazioni di smart account supporta gli aggiornamenti in modo che nuove funzionalità possano essere aggiunte e bug corretti. Tuttavia, un percorso di aggiornamento senza restrizioni significa che chiunque controlli l'autorità di aggiornamento può sostituire completamente la logica del wallet. Le best practice includono aggiornamenti time-locked (che danno agli utenti il tempo di uscire prima che le modifiche abbiano effetto), aggiornamenti controllati dalla governance e l'opzione per gli utenti di rinunciare agli aggiornamenti congelando l'implementazione del proprio account.

La gestione dei guardian per il social recovery deve essere attentamente ponderata. I guardian dovrebbero essere diversificati -- non tutti dalla stessa piattaforma o regione geografica. La soglia per il recupero dovrebbe essere abbastanza alta da prevenire la collusione ma abbastanza bassa da rimanere pratica. La rotazione dei guardian dovrebbe essere semplice, e dovrebbe esserci un ritardo temporale sulle azioni di recupero per dare al proprietario legittimo il tempo di intervenire se un attaccante compromette un sottoinsieme di guardian.

• Utilizza implementazioni di smart account consolidate e sottoposte ad audit piuttosto che costruire contratti wallet personalizzati
• Implementa aggiornamenti time-locked con un periodo di ritardo minimo che dia agli utenti la possibilità di revisionare e uscire
• Progetta i set di guardian pensando alla diversità -- dispositivi, piattaforme, posizioni geografiche e relazioni di fiducia diverse
• Imposta i permessi delle session key all'ambito minimo richiesto e alla durata pratica più breve
• Monitora pattern insoliti nel comportamento dei bundler e nel consumo di gas dei paymaster
• Conduci audit di sicurezza regolari su qualsiasi modulo personalizzato o logica di validazione aggiunta all'account di base

Costruire con l'account abstraction oggi

Per i team di sviluppo pronti a integrare l'account abstraction, l'ecosistema offre strumenti e infrastruttura maturi. La scelta dell'SDK e del fornitore di infrastruttura dipende dalle esigenze specifiche della tua applicazione -- se dai priorità alla modularità, all'esperienza sviluppatore o al controllo dell'infrastruttura.

Inizia scegliendo un'implementazione di smart account. L'architettura modulare di Safe è ideale per applicazioni che necessitano di multi-sig, permessi complessi o moduli componibili. L'account Kernel di ZeroDev è leggero e altamente personalizzabile, rendendolo una scelta forte per applicazioni con requisiti specifici di logica di validazione. Nexus di Biconomy e Modular Account di Alchemy forniscono soluzioni full-stack opinionated che minimizzano la complessità di integrazione.

Successivamente, seleziona la tua infrastruttura di bundler. Puoi eseguire il tuo bundler per il massimo controllo, o utilizzare servizi hosted da Alchemy, Pimlico, Stackup o Biconomy. Per sviluppo e testing, i bundler locali come quelli forniti dall'implementazione di riferimento Infinitism ti permettono di sviluppare e testare i flussi UserOp senza dipendere da servizi esterni.

Configura la tua strategia Paymaster in base al tuo modello di business. Sponsorizzare tutto il gas durante la beta o per i nuovi utenti riduce drasticamente l'attrito di onboarding. Accettare token ERC-20 per il pagamento del gas permette ai power user di pagare nel loro token preferito. La sponsorizzazione condizionale -- sponsorizzare il gas per azioni specifiche ma non per altre -- ti dà un controllo granulare sul tuo budget di sussidi.

• Usa permissionless.js o i moduli di account abstraction di viem per lo sviluppo TypeScript-first con controllo granulare sulla costruzione delle UserOp
• Sfrutta l'aa-sdk di Alchemy o l'SDK di Biconomy per astrazioni di livello superiore che gestiscono automaticamente la comunicazione con il bundler e l'integrazione con il paymaster
• Testa su Sepolia o altri testnet dove l'EntryPoint è deployato e i servizi di bundler sono disponibili
• Implementa ERC-4337 in modo incrementale -- inizia con transazioni gasless tramite Paymaster, poi aggiungi session key e batching man mano che le esigenze dei tuoi utenti evolvono
• Monitora il rollout di ERC-7702 e pianifica la tua strategia di migrazione in modo che gli utenti EOA esistenti possano aggiornarsi in loco una volta che Pectra si attiva
• Usa strumenti come userop.js, la suite di test del Bundler e i metodi di simulazione dell'EntryPoint per validare le UserOp localmente prima di inviarle a un bundler live

Il percorso futuro

L'account abstraction rappresenta uno shift fondamentale nel modo in cui gli utenti interagiscono con la blockchain. La combinazione dell'infrastruttura a livello applicativo di ERC-4337 e degli aggiornamenti a livello di protocollo degli EOA di ERC-7702 crea un percorso chiaro verso un futuro in cui gli account blockchain sono flessibili e user-friendly come gli account in qualsiasi sistema software tradizionale -- ma con la self-custody e la resistenza alla censura che rendono la blockchain preziosa.

La tecnologia è pronta per la produzione oggi. I principali wallet, fornitori di infrastruttura e applicazioni hanno adottato ERC-4337. Le reti L2 come Base, Arbitrum e Optimism vedono milioni di transazioni di smart account ogni mese. Gli strumenti sono maturi, gli standard sono stabili e il track record di sicurezza sta crescendo. Per i team di sviluppo che costruiscono applicazioni blockchain, non c'è più motivo di costringere gli utenti all'esperienza EOA. L'account abstraction è il modo in cui il mondo crypto diventa utilizzabile da tutti.

In Xcapit, il nostro team di sviluppo blockchain ha una profonda esperienza nella costruzione di wallet smart contract, protocolli DeFi e infrastruttura Web3. Che tu stia integrando ERC-4337 in un'applicazione esistente, progettando un nuovo prodotto con account abstraction fin dal primo giorno, o pianificando la tua strategia di migrazione ERC-7702, possiamo aiutarti a navigare le decisioni architetturali e consegnare un'implementazione pronta per la produzione. Scopri di più sui nostri servizi di sviluppo blockchain.