Wat zijn onchain AI-agenten? Mogelijkheden, wallets en beperkingen in 2026
Belangrijkste punten
- •Een onchain AI-agent wordt pas autonoom wanneer hij blockchainacties kan ondertekenen en verzenden binnen de grenzen die de gebruiker vooraf heeft geautoriseerd; het enkel voorbereiden van niet-ondertekende transacties geldt als assistentie en niet als uitvoering.
- •Fetch.ai Agentverse, Olas, Coinbase AgentKit, Safe en x402 hebben elk een eigen rol: agent discovery, permanente autonome diensten, wallet-transactietooling, machtigingen voor smart accounts en machinebetalingen; het zijn geen onderling uitwisselbare producten.
- •Een ontwikkelaar die Coinbase AgentKit met x402 koppelde, rapporteerde stille bibliotheekstoringen door een mismatch met smart accounts en een retry die tweemaal betaalde voordat de eerste transactie was bevestigd.
- •Een operator verwijderde x402 na zes weken productiegebruik op een MCP-server, onder meer door payment retries, wallet rate limits, stille webhook-fouten, refunds bij mislukte jobs en klanten die in dollars in plaats van USDC wilden betalen.
- •Het artikel noemt verouderde of gemanipuleerde input, promptinjectie, simulation drift, te ruime sessieautoriteit, dubbele betaalde retries en settlement zonder levering als belangrijkste beveiligingsrisico’s, en adviseert om te starten met read-only machtigingen en negatieve-paadtests voordat begrensde bevoegdheid wordt toegekend.

Onchain AI-agenten zijn softwaresystemen die een instructie omzetten in een blockchainactie door offchain redenering te combineren met onchain accounts, contracten, betalingen en ontvangstbewijzen. In de meeste ontwerpen draait het model zelf offchain. Wat de agent onchain maakt, is het vermogen om verifieerbare state te lezen of via een wallet een statewijziging aan te vragen onder gedefinieerde regels.
De bruikbare versie is geen chatbot met een onbeperkte privésleutel. Gegevens worden getimestamped, de voorgestelde transactie wordt gesimuleerd, beleid bepaalt of het proces door mag gaan en het ontvangstbewijs wordt gecontroleerd tegen de oorspronkelijke instructie. Dat onderscheid is belangrijker dan of er ergens in de stack een AI-agent-coin verschijnt, omdat de praktische vraag altijd is welke laag de actie kan waarnemen, autoriseren en verifiëren.
Wat zijn onchain AI-agenten?
Een op onchain aangesloten AI-agent kan blockchainstate lezen, opties vergelijken of een niet-ondertekende transactie voorbereiden. Hij wordt pas autonoom wanneer hij een specifieke actie kan ondertekenen en verzenden binnen de grenzen die de gebruiker vooraf heeft geautoriseerd.
Beide ontwerpen combineren redenering, tools, een account en resultaatbewaking — maar calldata voorbereiden is assistentie, terwijl gedelegeerde ondertekeningsmacht autonome uitvoering is.
Een onchain-agent moet niet worden verward met elk project in de bredere crypto-sector voor AI-infrastructuur. Compute-netwerken verkopen verwerkingscapaciteit, agentplatformen coördineren software en smart accounts handhaven autoriteit. Deze lagen kunnen worden gecombineerd, maar geen ervan wordt autonoom enkel omdat er een token of contract aanwezig is.
Een rule-based bot herhaalt vooraf ingestelde voorwaarden en kan transacties indienen, maar interpreteert geen breder doel. Een autonome onchain AI-agent kiest tools en acties op basis van context en ondertekent alleen binnen gedelegeerde grenzen.
Een smart account neemt zelf geen beslissingen. Het handhaaft eigenaren, limieten, modules, goedkeuringen en herstelregels.
Een x402-betalingsrail draagt en verrekent een ondertekende machinebetalingsautorisatie zonder te beslissen of de aankoop nuttig is.
Identiteit staat los van een walletsaldо of een agentnaam. Een productie-systeem moet de agent, operator, softwareversie, wallet, service-endpoints en de revocation owner aan elkaar koppelen. Het overzicht van agentidentiteit en validatie van Ethereum laat zien hoe registries discovery en reputatie ondersteunen, maar registratie bewijst niet dat een output correct is.
Die grens is belangrijk in DeFAI-systemen, waar een aanbeveling kan uitmonden in een swap, deposit, bridge of rebalance. Gebruikers moeten zien welke laag de actie voorstelde en welke laag geldbeweging toestond.
Hoe onchain AI-agenten werken
Neem een instructie om 50 USDC aan ETH te kopen op Base, alleen wanneer de price impact onder 0,5% blijft. Een WebSocket triggert de workflow wanneer de pool verandert en de agent leest saldo, quote, liquiditeit, gas en blocktijd. Verouderde of onvolledige input stopt de uitvoering voordat een transactie wordt opgebouwd.
Het model vergelijkt routes zonder eindautoriteit te krijgen. Simulatie schat saldoveranderingen; beleid controleert chain, tokens, contract, besteding, slippage, deadline en methode. De wallet reserveert de volgende nonce via één queue voordat er wordt ondertekend.
Na settlement bevestigt monitoring de besteding, de minimale ETH-output, het aangeroepen contract en de resterende goedkeuringen. Een gewijzigde route, reverted call of slechte output leidt tot een alert in plaats van een stille retry. De volledige reeks is zichtbaar voor de gebruiker in plaats van verborgen achter één bevestigingsbericht:
Lees: Leg de WebSocket-trigger, quote, saldo, liquiditeit en blocktimestamp vast. Ontbrekende of verouderde input stopt het verzoek.
Beslis: Selecteer een pool en minimale ETH-output. Verwachte price impact boven 0,5% wijst de route af.
Simuleer: Decodeer de call en projecteer saldoveranderingen. Een revert, verborgen goedkeuring of gewijzigde route blokkeert ondertekening.
Handhaaf beleid: Controleer Base, het goedgekeurde contract, het plafond van 50 USDC en de deadline tegen het oorspronkelijke mandaat.
Onderteken en verwerk: Reserveer de nonce en gebruik een begrensde handtekening. Een conflict, verlopen sessie of weigering van de ondertekenaar stopt indiening.
Verifieer: Vergelijk het ontvangstbewijs met het verzoek. Het verkeerde asset, contract, bedrag of output genereert een alert.
Wat onchain AI-agenten vandaag kunnen doen
In DeFi kan een agent een leenpositie volgen, netto-opbrengsten na kosten vergelijken en herverdelen over goedgekeurde markten. Gebruikers moeten de bronblock, contracten, verwachte saldoverandering, beleidsbeslissing en ontvangstbewijs kunnen zien.
Voor machinebetalingen kan een agent een API- of compute-taak aanvragen, x402-voorwaarden ontvangen, begrensde USDC autoriseren en opnieuw proberen met betalingsbewijs. Eén autorisatie moet één geleverd resultaat of een traceerbare terugbetaling opleveren — nooit een dubbele afschrijving. Agents kunnen ook een provider vinden, de identiteit verifiëren, een taak inkopen en het teruggegeven resultaat vastleggen. Identiteit en betaling maken de uitwisseling traceerbaar, maar bewijs van voltooiing en een herstelowner zijn nog steeds vereist.
Vijf systemen die onchain agents echte mogelijkheden geven
Deze vijf voorbeelden zijn geen vijf onderling uitwisselbare agents. Ze bestrijken discovery, autonome diensten, transactietooling, accountcontrole en machinebetalingen. Samen laten ze zien waarom agentplatformen als stacks moeten worden beoordeeld in plaats van op basis van één demo-scherm.
Fetch.ai Agentverse: agent discovery
Fetch.ai's Agentverse helpt gebruikers en agents om diensten te ontdekken, gestructureerde verzoeken te sturen en reacties te ontvangen. Registratie of betaling kan een chain raken terwijl service logica en data offchain blijven. Een review moet vastleggen welke agent antwoordde, wat de bron was, de responstijd en bewijs van voltooiing.
Een DeltaV-bèta-tester uit juli 2024 besteedde één tot twee uur aan vijf prompts en kreeg geen resultaten voor EV-laders in de buurt, ondanks melding van ongeveer 15 laders. Die specifieke DeltaV-test is oud en anekdotisch, niet representatief voor betrouwbaarheid in 2026. Ze wijst nog steeds op nuttige controles: responstijd, taakvoltooiing, bronafhankelijkheid en of de service het verzoek daadwerkelijk oploste.
Olas: coördinatie van autonome diensten
Olas coördineert permanente autonome diensten via geregistreerde componenten, operators en Safe-accounts. Reviewers moeten elke service-ID en operator koppelen aan de Agent Safe en aan de owner of Master Safe die controle kan herstellen.
Een reviewer die een Pearl-wallet gebruikte, volgde de contractinteracties op GnosisScan in plaats van alleen te vertrouwen op het app-dashboard. Die Pearl-wallet walkthrough, geraadpleegd op 19 augustus 2026, is een beperkte publicatietest en geen benchmark voor uptime of support. Toch biedt het een reproduceerbare eigendomscontrole voor een operator: kopieer het Agent Safe-adres uit Pearl, match elke registry- en servicetransactie in de explorer en identificeer de Master Safe die controle kan herstellen voordat er meer geld wordt gestort. Dat is belangrijk omdat de registry-remediatie van Olas in juni 2026 de koppeling tussen een service en zijn multisig specifiek heeft aangescherpt.
Coinbase AgentKit: wallet-acties
Coinbase AgentKit biedt balansopvragen, transfers en contractcalls voor software die aan een wallet is gekoppeld. Het koppelt toolcalls aan transacties maar beslist niet of een route verstandig is. Applicaties moeten tools, accountscope, chain, asset, bedrag, methode en sessieduur beperken.
Eén ontwikkelaar die AgentKit met x402 koppelde ontdekte dat bibliotheken die uitgaan van een externally owned account stil konden falen omdat AgentKit een smart account gebruikte. Een retry betaalde bovendien twee keer voordat de eerste transactie was bevestigd. Dit integratierapport over twee weken is geen platformbrede benchmark, maar levert wel twee releasecontroles op: accounttype detecteren en betaalde retries idempotent maken.
Safe: machtigingen voor smart accounts
Safe scheidt modelvoorstellen van assetautoriteit via owners, thresholds, modules en guards. Controleer elke owner, module, spending rule, upgradepad en herstelmechanisme, omdat een te krachtige module of onleesbare interface een sterke threshold kan verzwakken.
Een lid van de Safe-community dat cross-device verificatie testte merkte dat hashes en gedecodeerde details op afzonderlijke schermen moesten worden vergeleken. Latere tests lieten zien dat een verdwijnende timeout-interface valse urgentie kon creëren. Deze Safe-goedkeuringsproeven zijn individuele observaties, maar ondersteunen het decoderen en bevestigen van waardevolle acties op een apparaat dat het voorstel niet heeft aangemaakt.
x402: machinebetalingen
x402 laat software een resource aanvragen, betalingsvoorwaarden ontvangen, een autorisatie ondertekenen, opnieuw proberen en de resource na settlement verkrijgen. Het dekt alleen de betalingslaag binnen het bredere landschap van AI-agent-betalingsprotocollen.
Na zes weken x402 te hebben gebruikt om een MCP-server te monetiseren, verwijderde één operator het ondanks de elegante betalingshandshake. Het first-hand productieverslag beschrijft payment retries, prijsstelling per tool, wallet rate limits, refunds na mislukte jobs, stille webhook-fouten en een aparte vereiste voor klanten die in dollars betalen in plaats van USDC. Eén implementatie kan geen protocolbrede betrouwbaarheid aantonen, maar laat wel zien wat een releasetest moet afdekken: herhaal een verzoek na settlement, laat de betaalde job bewust mislukken en verifieer dat één autorisatie één geleverde response of een traceerbare terugbetaling oplevert, nooit een tweede afschrijving.
Machtigingsniveaus van onchain AI-agenten
Onderzoekscapaciteit en financiële bevoegdheid moeten apart worden beoordeeld. Overgang van read-only toegang naar onbeperkte signing creëert nieuwe verliespaden en vereist een sterkere control owner. Een review uit 2026 van 317 relevante studies scheidde eveneens read-only analytics, intentgeneratie, gedelegeerde uitvoering, autonome signing en multi-agent workflows, terwijl custody, beleid, observability en herstel werden vergeleken.
Het veiligste productiedoel is meestal begrensde uitvoering. Daarmee blijven asset, bestemming, bedrag, methode en vervaldatum buiten het model afdwingbaar. Een prompt kan verkeerd worden begrepen; accountbeleid kan voorkomen dat de ongeldige call wordt ondertekend.
Beveiligingsrisico's van onchain AI-agenten
Storingen treden vaak op bij overdrachtsmomenten: data wordt verouderd vóór ondertekening, calldata verandert na simulatie of betaling wordt verrekend terwijl de API-respons verloren gaat. Een wallet kan ook een limiet afdwingen en toch een allowlisted methode aanroepen met onbedoelde parameters.
Verouderde of gemanipuleerde input kan een zelfverzekerde aanbeveling opleveren op basis van een oude quote. Timestamps, goedgekeurde bronnen en freshness limits moeten dat afwijzen.
Prompt- of tool-injectie kan een nieuwe bestemming of verborgen instructie introduceren. Tool-isolatie en contract allowlists houden die wijziging buiten het ondertekeningspad.
Simulation drift ontstaat wanneer calldata niet langer overeenkomt met de preview. Ondertekening moet gebonden blijven aan de gesimuleerde calldata en deadline.
Te veel sessieautoriteit laat een geldige actie herhalen buiten de bedoeling van de gebruiker. Limieten op bedrag, frequentie, asset, methode en vervaldatum beperken de schade.
Dubbele betaalde retries kunnen opnieuw kosten na een API-timeout. Een idempotency key moet de retry koppelen aan de oorspronkelijke autorisatie.
Settlement zonder levering laat een bevestigde betaling achter zonder bruikbare service-output. Het ontvangstbewijs heeft een leveringscontrole en een benoemd refund- of escalatiepad nodig.
Een sterker model kan routing verbeteren, maar het kan deterministische limieten, herstel, idempotency of een ontvangstbewijs dat aantoont wat er gebeurde, niet vervangen.
Transactieontvangsten en audit trails
De instructie voor 50 USDC moet eindigen met één record dat het verzoek aan de settlement koppelt. Noch een chattranscript, noch alleen een transaction hash laat zien welke quote, limiet en welk beleid het resultaat opleverde.
Mandaat en inputs: koop ETH op Base, geef niet meer uit dan 50 USDC, houd de price impact onder 0,5% en registreer de quoteprovider, liquiditeit, blocknummer en timestamp.
Voorgestelde actie en simulatie: behoud de router, pool, tokenadressen, bedrag, minimale output, deadline, calldata-hash, geprojecteerde saldi, gasinschatting en wijziging in goedkeuringen.
Beleid en autorisatie: leg de regelversie, reden voor goedkeuring of afwijzing, smart account, ondertekenaar of sessie, gereserveerde nonce en vervaldatum van de machtiging vast.
Settlement en opvolging: voeg de transaction hash, block, daadwerkelijke bedragen, verschil tussen gevraagd en werkelijk, resterende goedkeuringen, alert en herstelowner toe.
Test vóór het verhogen van de walletlimiet een verouderde quote, geblokkeerd contract, buitensporig bedrag, verlopen sessie, gewijzigde calldata, conflicterende nonce en post-payment timeout. Elk geval moet stoppen op de toegewezen laag en zichtbaar blijven in het record.
Conclusie
Onchain AI-agenten verbinden offchain beslissingen met blockchainaccounts en statewijzigingen. Fetch.ai, Olas, AgentKit, Safe en x402 vertegenwoordigen discovery, permanente diensten, actietooling, accountbeleid en betaling, en niet één onderling uitwisselbare productcategorie. De sterkste implementatie laat zien waarom een actie werd voorgesteld, waarom beleid het toestond, wat de wallet ondertekende en of de settlement overeenkwam met het mandaat. Begin met observeerbaar werk, voeg begrensde bevoegdheid alleen toe aan herhaalbare workflows en houd herstel buiten het model.
Veelgestelde vragen
Hebben onchain AI-agenten een token nodig?
Nee. Een applicatie kan een model, data-API's, transactietools en een smart account combineren zonder een dedicated token uit te geven of te vereisen. Een token is alleen relevant wanneer het een noodzakelijke functie vervult, zoals betaling, staking, toegang, governance of coördinatie.
Wat draait offchain in een onchain AI-agent?
Het model, geheugen, private context, dataverwerking en het grootste deel van de inferentie draaien doorgaans offchain omdat berekening kostbaar is en input gevoelig kan zijn. De blockchain registreert vaker identiteit, machtigingen, betalingen, contractcalls en de eindstatus.
Zijn smart accounts voldoende voor onchain AI-agenten?
Nee. Een smart account kan thresholds, modules en limieten afdwingen, maar de configuratie moet nog steeds worden beoordeeld. Onveilige modules, brede allowlists, lange sessies, zwak herstel of onleesbare signing interfaces kunnen de accountgrens ondermijnen.
Met welke walletmachtigingen moet een onchain AI-agent beginnen?
Read-only monitoring en het voorbereiden van niet-ondertekende transacties bieden de minste financiële bevoegdheid. Uitvoering op basis van goedkeuring is de volgende stap. Begrensde automatisering mag pas komen nadat negatieve-paadtests aantonen dat ongeldige, verouderde of gewijzigde acties betrouwbaar worden geweigerd.
Disclaimer: De informatie op AiCryptoCore.com is uitsluitend bedoeld voor educatieve en informatieve doeleinden en vormt geen financieel, investerings- of handelsadvies. Beleggen in cryptocurrency brengt risico’s met zich mee en kan leiden tot financieel verlies. Doe altijd uw eigen onderzoek en raadpleeg een gekwalificeerde financieel adviseur voordat u beleggingsbeslissingen neemt.