Gli agenti AI onchain sono sistemi software che trasformano un’istruzione in un’azione blockchain combinando ragionamento offchain con account onchain, contratti, pagamenti e ricevute. Nella maggior parte dei casi, il modello stesso opera offchain. Ciò che rende l’agente “onchain” è la sua capacità di leggere uno stato verificabile, oppure richiedere una variazione di stato, tramite un wallet che opera secondo regole definite.

La versione realmente utile non è un chatbot con una private key senza restrizioni. I dati sono marcati temporalmente, la transazione proposta viene simulata, la policy decide se può proseguire e la ricevuta viene verificata rispetto all’istruzione originale. Questa distinzione conta più della presenza o meno di una coin per agenti AI nello stack, perché la domanda pratica è sempre quale livello possa osservare, autorizzare e verificare l’azione.

Cosa sono gli agenti AI onchain?

Un agente AI connesso onchain può leggere lo stato della blockchain, confrontare opzioni o preparare una transazione non firmata. Diventa autonomo solo quando può firmare e inviare una specifica azione entro i limiti autorizzati in anticipo dall’utente.

Entrambi i modelli combinano ragionamento, strumenti, un account e il monitoraggio dei risultati. Preparare il calldata è assistenza; esercitare il potere di firma delegato è esecuzione autonoma.

Un agente onchain non va confuso con ogni progetto nel più ampio settore crypto dell’infrastruttura AI . Le reti di calcolo vendono capacità di elaborazione, le piattaforme per agenti coordinano software e gli smart account fanno rispettare l’autorità. Possono essere combinati, ma nessuno diventa autonomo semplicemente perché è presente un token o un contratto.

Un bot basato su regole ripete condizioni preimpostate e può inviare transazioni, ma non interpreta un obiettivo più ampio. Un agente AI onchain autonomo sceglie strumenti e azioni in base al contesto, quindi firma solo entro i limiti delegati.

Uno smart account non prende decisioni. Fa rispettare proprietari, limiti, moduli, approvazioni e regole di recupero.

Un rail di pagamento x402 trasporta e regola un’autorizzazione firmata di pagamento machine-to-machine senza decidere se l’acquisto sia utile.

L’identità è separata dal saldo del wallet o dal nome dell’agente. Un sistema in produzione dovrebbe legare tra loro agente, operatore, versione software, wallet, endpoint di servizio e responsabile della revoca. La panoramica di Ethereum su identità e validazione degli agenti mostra come i registry supportino discovery e reputazione, ma la registrazione non prova che un output sia corretto.

Questo confine è importante nei sistemi DeFAI , dove una raccomandazione può diventare uno swap, un deposito, un bridge o un rebalance. Gli utenti devono vedere quale livello ha proposto l’azione e quale livello ha consentito il movimento dei fondi.

Come funzionano gli agenti AI onchain

Si consideri un’istruzione per acquistare 50 USDC di ETH su Base solo se l’impatto sul prezzo resta sotto lo 0.5%. Un WebSocket attiva il flusso quando il pool cambia e l’agente legge saldo, quotazione, liquidità, gas e block time. Un input obsoleto o incompleto interrompe l’esecuzione prima che venga costruita una transazione.

Il modello confronta i percorsi senza ricevere l’autorità finale. La simulazione stima le variazioni di saldo; la policy verifica chain, token, contratto, spesa, slippage, deadline e metodo. Il wallet riserva il nonce successivo tramite una coda prima della firma.

Dopo il settlement, il monitoraggio conferma la spesa, il minimo output di ETH, il contratto chiamato e le approvazioni residue. Un percorso modificato, una chiamata revertita o un output scadente generano un alert invece di un retry silenzioso.

La sequenza completa è visibile all’utente invece di essere nascosta dietro un unico messaggio di conferma:

Leggi: acquisire il trigger del WebSocket, la quotazione, il saldo, la liquidità e il timestamp del blocco. Un input mancante o obsoleto interrompe la richiesta.

Decidi: selezionare un pool e il minimo output di ETH. Un impatto sul prezzo atteso superiore allo 0.5% rifiuta il percorso.

Simula: decodificare la chiamata e proiettare le variazioni di saldo. Un revert, un’approvazione nascosta o un percorso modificato bloccano la firma.

Applica la policy: verificare Base, il contratto approvato, il limite di 50 USDC e la deadline rispetto al mandato originale.

Firma e regola: riservare il nonce e usare una firma limitata. Un conflitto, una sessione scaduta o il rifiuto del firmatario bloccano l’invio.

Verifica: confrontare la ricevuta con la richiesta. Asset, contratto, importo o output errati generano un alert.

Cosa possono fare oggi gli agenti AI onchain

Nella DeFi, un agente può monitorare una posizione di lending, confrontare i rendimenti netti dopo i costi e ribilanciare tra i mercati approvati. Gli utenti dovrebbero vedere il blocco sorgente, i contratti, la variazione attesa del saldo, la decisione di policy e la ricevuta.

Per i pagamenti machine-to-machine, un agente può richiedere una API o un job di calcolo, ricevere i termini x402, autorizzare un USDC limitato e riprovare con prova di pagamento. Un’unica autorizzazione deve produrre un unico risultato consegnato o un rimborso tracciabile, mai un addebito duplicato. Gli agenti possono anche individuare un provider, verificarne l’identità, acquistare un’attività e registrare il risultato restituito. Identità e pagamento rendono tracciabile lo scambio, ma restano necessari anche la prova di completamento e un responsabile del recovery.

Cinque sistemi che danno agli agenti onchain capacità reali

I cinque esempi seguenti non sono cinque agenti intercambiabili. Coprono discovery, servizi autonomi, tooling per transazioni, controllo dell’account e pagamenti machine-to-machine. Letti insieme, mostrano perché le piattaforme per agenti vadano valutate come stack e non da una singola schermata demo.

Fetch.ai Agentverse: discovery degli agenti

La Agentverse di Fetch.ai aiuta utenti e agenti a scoprire servizi, inviare richieste strutturate e ricevere risposte. La registrazione o il pagamento possono toccare una chain mentre la logica del servizio e i dati restano offchain. Una revisione dovrebbe registrare quale agente ha risposto, la sua origine, il tempo di risposta e la prova di completamento.

Un beta tester di DeltaV del luglio 2024 ha trascorso da una a due ore su cinque prompt e non ha ricevuto risultati per colonnine EV nelle vicinanze, pur segnalando circa 15 colonnine. Quel test specifico di DeltaV è datato e aneddotico, non una misura di affidabilità del 2026. Resta comunque utile per individuare verifiche: tempo di risposta, completamento dell’attività, dipendenza dalla fonte e capacità del servizio di risolvere la richiesta.

Olas: coordinamento di servizi autonomi

Olas coordina servizi autonomi persistenti tramite componenti registrati, operatori e account Safe. I revisori dovrebbero collegare ogni service ID e operatore al relativo Agent Safe e al proprietario, o Master Safe, in grado di recuperare il controllo.

Un revisore che ha usato un wallet Pearl ha seguito le interazioni dei contratti su GnosisScan invece di affidarsi solo alla dashboard dell’app. Quel walkthrough del wallet Pearl, consultato il 19 agosto 2026, è un test di pubblicazione limitato, non un benchmark di uptime o supporto.

Resta però una verifica di proprietà riproducibile per l’operatore: copiare l’indirizzo Agent Safe da Pearl, confrontare ogni transazione di registry e servizio nell’explorer e identificare il Master Safe che può recuperare il controllo prima di depositare altri fondi. Questo conta perché la remediation del registry di Olas del giugno 2026 ha rafforzato in modo specifico il legame tra un servizio e il suo multisig.

Coinbase AgentKit: azioni del wallet

Coinbase AgentKit fornisce query di saldo, trasferimenti e chiamate di contratto per software connesso a wallet. Collega le chiamate degli strumenti alle transazioni, ma non decide se un percorso sia sensato. Le applicazioni devono limitare strumenti, ambito dell’account, chain, asset, importo, metodo e durata della sessione.

Un builder che ha collegato AgentKit a x402 ha scoperto che librerie che presumevano un account esterno di proprietà (EOA) potevano fallire in modo silenzioso perché AgentKit usava uno smart account. Anche un retry ha effettuato un doppio pagamento prima della conferma della prima transazione. Questo report di integrazione di due settimane non è un benchmark dell’intera piattaforma, ma produce due verifiche di release: rilevare il tipo di account e rendere idempotenti i retry a pagamento.

Safe: permessi degli smart account

Safe separa le proposte del modello dall’autorità sugli asset attraverso owner, soglie, moduli e guard. Ogni owner, modulo, regola di spesa, percorso di upgrade e meccanismo di recovery va revisionato, perché un modulo troppo potente o un’interfaccia illeggibile possono indebolire una soglia forte.

Un partecipante della community Safe che testava la verifica cross-device ha osservato che hash e dettagli decodificati dovevano essere confrontati su superfici separate. Test successivi hanno mostrato che un’interfaccia di timeout che scompare può creare una falsa urgenza. Questi esperimenti di approvazione Safe sono osservazioni individuali, ma supportano la decodifica e la conferma di azioni di alto valore su un dispositivo che non ha creato la proposta.

x402: pagamenti machine-to-machine

x402 consente al software di richiedere una risorsa, ricevere i termini di pagamento, firmare un’autorizzazione, riprovare e ottenere la risorsa dopo il settlement. Copre solo il livello di pagamento del più ampio panorama dei protocolli di pagamento per agenti AI.

Dopo sei settimane di utilizzo di x402 per monetizzare un server MCP, un operatore lo ha rimosso nonostante ritenesse elegante il meccanismo di handshake del pagamento. Il resoconto operativo di prima mano descrive retry dei pagamenti, pricing per strumento, limiti di velocità del wallet, rimborsi dopo job falliti, errori silenziosi dei webhook e un requisito separato per i clienti che pagano in dollari invece che in USDC.

Una singola implementazione non può stabilire l’affidabilità a livello di protocollo, ma mostra cosa deve coprire un test di release: ripetere una richiesta dopo il settlement, far fallire deliberatamente il job a pagamento e verificare che un’unica autorizzazione produca o una singola risposta consegnata o un rimborso tracciabile, mai un secondo addebito.

Livelli di autorizzazione per gli agenti AI onchain

La capacità di ricerca e l’autorità finanziaria devono essere valutate separatamente. Passare dall’accesso in sola lettura alla firma aperta crea nuove vie di perdita e richiede un owner del controllo più robusto.

Una review del 2026 su 317 studi rilevanti ha separato in modo analogo analytics in sola lettura, generazione di intenti, esecuzione delegata, firma autonoma e workflow multi-agente, confrontando custody, policy, osservabilità e recovery.

L’obiettivo di produzione più sicuro è di solito l’esecuzione limitata. Mantiene applicabili fuori dal modello asset, destinazione, importo, metodo e scadenza. Un prompt può essere interpretato male; la policy dell’account può impedire la firma di una chiamata invalida.

Rischi di sicurezza degli agenti AI onchain

I guasti avvengono spesso nei passaggi di consegna: i dati diventano obsoleti prima della firma, il calldata cambia dopo la simulazione oppure il pagamento viene regolato mentre la risposta API si perde. Un wallet può anche imporre un tetto ma chiamare un metodo in allowlist con parametri non intenzionali.

I rischi principali includono:

• Input obsoleto o manipolato può produrre una raccomandazione sicura basata su una vecchia quotazione. Timestamp, fonti approvate e limiti di freschezza dovrebbero rifiutarla.
• Prompt injection o tool injection può introdurre una nuova destinazione o un’istruzione nascosta. L’isolamento degli strumenti e gli allowlist dei contratti mantengono tale modifica fuori dal percorso di firma.
• Simulation drift si verifica quando il calldata non corrisponde più all’anteprima. La firma deve restare vincolata al calldata simulato e alla deadline.
• Autorità di sessione eccessiva consente a un’azione valida di ripetersi oltre l’intento dell’utente. Limiti su importo, frequenza, asset, metodo e scadenza contengono il danno.
• Retry a pagamento duplicati possono addebitare di nuovo dopo un timeout API. Una chiave di idempotenza deve collegare il retry alla sua autorizzazione originale.
• Settlement senza consegna lascia un pagamento confermato ma nessun output utile del servizio. La ricevuta richiede un controllo di consegna e un percorso nominato di rimborso o escalation.

Un modello più potente può migliorare il routing, ma non può sostituire limiti deterministici, recovery, idempotenza o una ricevuta che provi cosa sia accaduto.

Ricevute delle transazioni e audit trail

L’istruzione da 50 USDC dovrebbe terminare con un singolo record che colleghi la richiesta al settlement. Né una trascrizione della chat né un hash della transazione, presi singolarmente, mostrano quale quotazione, limite e policy abbiano prodotto il risultato.

Mandato e input: acquistare ETH su Base, spendere non più di 50 USDC, mantenere l’impatto sul prezzo sotto lo 0.5% e registrare provider della quotazione, liquidità, numero del blocco e timestamp.

Azione proposta e simulazione: preservare router, pool, indirizzi dei token, importo, output minimo, deadline, hash del calldata, saldi proiettati, stima del gas e modifiche alle approvazioni.

Policy e autorizzazione: registrare la versione della regola, il motivo dell’approvazione o del rifiuto, lo smart account, il firmatario o la sessione, il nonce riservato e la scadenza dei permessi.

Settlement e follow-up: allegare hash della transazione, blocco, importi effettivi, differenza tra richiesto ed effettivo, approvazioni residue, alert e owner del recovery.

Prima di aumentare il limite del wallet, testare una quotazione obsoleta, un contratto bloccato, un importo eccessivo, una sessione scaduta, un calldata modificato, un nonce in conflitto e un timeout post-pagamento. Ogni caso deve fermarsi al livello assegnato e restare visibile nel record.

Conclusione

Gli agenti AI onchain collegano decisioni offchain a account blockchain e cambiamenti di stato. Fetch.ai, Olas, AgentKit, Safe e x402 rappresentano discovery, servizi persistenti, tooling di azione, policy dell’account e pagamenti, non una singola categoria di prodotto intercambiabile.

L’implementazione più solida mostra perché un’azione è stata proposta, perché la policy l’ha consentita, cosa ha firmato il wallet e se il settlement ha rispettato il mandato. Iniziare con lavoro osservabile, aggiungere autorità limitata solo a workflow ripetibili e mantenere il recovery fuori dal modello.

Domande frequenti

Gli agenti AI onchain hanno bisogno di un token?

No. Un’applicazione può combinare un modello, API dati, strumenti di transazione e uno smart account senza emettere o richiedere un token dedicato. Un token è rilevante solo quando svolge una funzione necessaria come pagamento, staking, accesso, governance o coordinamento.

Cosa gira offchain in un agente AI onchain?

Il modello, la memoria, il contesto privato, l’elaborazione dei dati e la maggior parte dell’inferenza in genere girano offchain perché il calcolo è costoso e gli input possono essere sensibili. La blockchain registra più spesso identità, permessi, pagamenti, chiamate di contratto e stato finale.

Gli smart account sono sufficienti per gli agenti AI onchain?

No. Uno smart account può imporre soglie, moduli e limiti, ma la configurazione deve comunque essere revisionata. Moduli non sicuri, allowlist troppo ampie, sessioni lunghe, recovery debole o interfacce di firma illeggibili possono compromettere il confine dell’account.

Da quali permessi wallet dovrebbe partire un agente AI onchain?

Il monitoraggio in sola lettura e la preparazione di transazioni non firmate espongono la minore autorità finanziaria. L’esecuzione basata su approvazioni è il passo successivo. L’automazione limitata dovrebbe arrivare solo dopo che test negativi hanno mostrato che azioni invalide, obsolete o modificate vengono rifiutate in modo affidabile.

Disclaimer: Le informazioni fornite su AiCryptoCore.com hanno solo scopo educativo e informativo e non costituiscono consulenza finanziaria, di investimento o di trading. Gli investimenti in criptovalute comportano rischi e possono comportare perdite finanziarie. Effettuare sempre ricerche autonome e consultare un consulente finanziario qualificato prima di prendere qualsiasi decisione di investimento.