Onchain-KI-Agenten sind Softwaresysteme, die eine Anweisung in eine Blockchain-Aktion umsetzen, indem sie offchain-gestütztes Reasoning mit onchain-Konten, Verträgen, Zahlungen und Belegen verbinden. In den meisten Designs läuft das Modell selbst offchain. Was den Agenten „onchain“ macht, ist seine Fähigkeit, verifizierbaren Zustand zu lesen oder über eine Wallet unter definierten Regeln eine Zustandsänderung anzustoßen.

Die nützliche Variante ist kein Chatbot mit einem uneingeschränkten privaten Schlüssel. Daten werden mit Zeitstempel versehen, die vorgeschlagene Transaktion wird simuliert, Richtlinien entscheiden, ob sie fortgesetzt werden darf, und der Beleg wird mit der ursprünglichen Anweisung abgeglichen. Dieser Unterschied ist wichtiger als die Frage, ob irgendwo im Stack ein AI-Agent-Token auftaucht, denn die praktische Frage lautet immer, welche Ebene die Aktion beobachten, autorisieren und verifizieren kann.

Was sind Onchain-KI-Agenten?

Ein mit der Blockchain verbundener KI-Agent kann Blockchain-Zustände lesen, Optionen vergleichen oder eine nicht signierte Transaktion vorbereiten. Autonom wird er erst dann, wenn er eine konkrete Aktion innerhalb der vom Nutzer im Voraus autorisierten Grenzen signieren und einreichen kann.

Beide Designs kombinieren Reasoning, Werkzeuge, ein Konto und Ergebnisüberwachung. Das Vorbereiten von Calldata ist Unterstützung; die Ausübung delegierter Signierbefugnis ist autonome Ausführung.

Ein Onchain-Agent sollte nicht mit jedem Projekt im breiteren Krypto-Sektor der KI-Infrastruktur verwechselt werden. Compute-Netzwerke verkaufen Rechenleistung, Agent-Plattformen koordinieren Software und Smart Accounts setzen Autorität durch. Sie können kombiniert werden, aber keine davon wird allein dadurch autonom, dass ein Token oder ein Vertrag vorhanden ist.

Ein regelbasierter Bot wiederholt vordefinierte Bedingungen und kann Transaktionen senden, interpretiert aber kein übergeordnetes Ziel. Ein autonomer Onchain-KI-Agent wählt Werkzeuge und Aktionen aus dem Kontext und signiert nur innerhalb delegierter Grenzen.

Ein Smart Account trifft keine Entscheidungen. Er setzt Eigentümer, Limits, Module, Genehmigungen und Wiederherstellungsregeln durch.

Ein x402-Zahlungsrail transportiert und begleicht eine signierte Maschinen-Zahlungsautorisierung, ohne zu entscheiden, ob der Kauf sinnvoll ist.

Identität ist getrennt von einem Wallet-Guthaben oder einem Agentennamen. Ein Produktionssystem sollte den Agenten, den Betreiber, die Softwareversion, die Wallet, die Service-Endpunkte und den Widerrufsverantwortlichen miteinander verknüpfen. Der Überblick von Ethereum zu Agentenidentität und -validierung zeigt, wie Register Auffindbarkeit und Reputation unterstützen, aber eine Registrierung beweist nicht, dass ein Ergebnis korrekt ist.

Diese Grenze ist in DeFAI-Systemen wichtig, in denen aus einer Empfehlung ein Swap, eine Einzahlung, eine Bridge-Transaktion oder ein Rebalancing werden kann. Nutzer müssen sehen, welche Ebene die Aktion vorgeschlagen hat und welche Ebene die Mittelbewegung erlaubt hat.

Wie Onchain-KI-Agenten funktionieren

Betrachten Sie die Anweisung, auf Base ETH im Wert von 50 USDC zu kaufen, aber nur dann, wenn der Price Impact unter 0,5% bleibt. Ein WebSocket löst den Workflow aus, wenn sich der Pool ändert, und der Agent liest Guthaben, Quote, Liquidität, Gas und Blockzeit. Veraltete oder unvollständige Eingaben stoppen die Ausführung, bevor eine Transaktion erstellt wird.

Das Modell vergleicht Routen, ohne die finale Autorität zu erhalten. Die Simulation schätzt Guthabenänderungen; die Policy prüft Chain, Token, Vertrag, Ausgabe, Slippage, Frist und Methode. Die Wallet reserviert vor dem Signieren die nächste Nonce über eine Warteschlange.

Nach dem Settlement bestätigt das Monitoring die Ausgabe, die minimale ETH-Menge, den aufgerufenen Vertrag und die verbleibenden Genehmigungen. Eine geänderte Route, ein revertierter Aufruf oder ein schlechtes Ergebnis löst einen Alarm aus, statt stillschweigend erneut zu versuchen.

Die vollständige Abfolge ist für den Nutzer sichtbar und nicht hinter einer einzigen Bestätigung verborgen:

• Lesen: WebSocket-Trigger, Quote, Guthaben, Liquidität und Blockzeitstempel erfassen. Fehlende oder veraltete Eingaben stoppen die Anfrage.
• Entscheiden: Einen Pool und die minimale ETH-Ausgabe auswählen. Erwarteter Price Impact über 0,5% lehnt die Route ab.
• Simulieren: Den Aufruf dekodieren und Guthabenänderungen projizieren. Ein Revert, eine versteckte Genehmigung oder eine geänderte Route blockiert das Signieren.
• Policy durchsetzen: Base, den freigegebenen Vertrag, das 50-USDC-Limit und die Frist mit dem ursprünglichen Mandat abgleichen.
• Signieren und beglichen: Die Nonce reservieren und eine begrenzte Signatur verwenden. Ein Konflikt, eine abgelaufene Sitzung oder die Ablehnung durch den Signer stoppt die Übermittlung.
• Verifizieren: Den Beleg mit der Anfrage vergleichen. Das falsche Asset, der falsche Vertrag, Betrag oder Output löst einen Alarm aus.

Was Onchain-KI-Agenten heute können

In DeFi kann ein Agent eine Lending-Position überwachen, die Nettorendite nach Kosten vergleichen und über freigegebene Märkte hinweg rebalancieren. Nutzer sollten den Quellblock, die Verträge, die erwartete Guthabenänderung, die Policy-Entscheidung und den Beleg sehen.

Für Maschinenzahlungen kann ein Agent eine API- oder Rechenaufgabe anfordern, x402-Bedingungen erhalten, begrenzte USDC autorisieren und mit Zahlungsnachweis erneut versuchen. Eine Autorisierung muss genau ein geliefertes Ergebnis oder eine nachvollziehbare Rückerstattung erzeugen – niemals eine doppelte Abbuchung. Agenten können außerdem einen Anbieter entdecken, dessen Identität verifizieren, eine Aufgabe kaufen und das zurückgelieferte Ergebnis protokollieren. Identität und Zahlung machen den Austausch nachvollziehbar, aber Nachweise über die Erfüllung und ein Wiederherstellungs-Verantwortlicher bleiben erforderlich.

Fünf Systeme, die Onchain-Agenten echte Fähigkeiten geben

Diese fünf Beispiele sind nicht fünf austauschbare Agenten. Sie decken Entdeckung, autonome Dienste, Transaktionswerkzeuge, Kontokontrolle und Maschinenzahlungen ab. Zusammen gelesen zeigen sie, warum Agenten-Plattformen als Stacks und nicht anhand eines einzelnen Demo-Bildschirms bewertet werden müssen.

Fetch.ai Agentverse: Agenten-Entdeckung

Fetch.ais Agentverse hilft Nutzern und Agenten, Dienste zu entdecken, strukturierte Anfragen zu senden und Antworten zu erhalten. Registrierung oder Zahlung können eine Chain berühren, während die Service-Logik und Daten offchain bleiben. Eine Prüfung sollte festhalten, welcher Agent geantwortet hat, welche Quelle er genutzt hat, wie lange die Antwort dauerte und welche Nachweise für die Erfüllung vorliegen.

Ein DeltaV-Beta-Tester aus Juli 2024 verbrachte ein bis zwei Stunden mit fünf Prompts und erhielt trotz der Angabe von ungefähr 15 Ladepunkten keine Ergebnisse zu nahe gelegenen EV-Ladestationen. Dieser konkrete DeltaV-Test ist alt und anekdotisch, kein Maßstab für Zuverlässigkeit im Jahr 2026. Er benennt dennoch nützliche Prüfungen: Reaktionszeit, Aufgabenerfüllung, Abhängigkeit von der Quelle und ob der Dienst die Anfrage gelöst hat.

Olas: Koordination autonomer Dienste

Olas koordiniert persistente autonome Dienste über registrierte Komponenten, Betreiber und Safe-Konten. Prüfer sollten jede Service-ID und jeden Betreiber mit dem zugehörigen Agent Safe und mit dem Eigentümer oder Master Safe verknüpfen, der die Kontrolle wiederherstellen kann.

Ein Prüfer, der eine Pearl-Wallet verwendete, verfolgte deren Vertragsinteraktionen auf GnosisScan, statt sich nur auf das App-Dashboard zu verlassen. Dieser Pearl-Wallet-Durchgang, abgerufen am 19. August 2026, ist ein begrenzter Publikationstest, kein Uptime- oder Support-Benchmark.

Er liefert dennoch einen reproduzierbaren Eigentumsnachweis: die Agent-Safe-Adresse aus Pearl kopieren, jede Registry- und Service-Transaktion im Explorer abgleichen und den Master Safe identifizieren, der die Kontrolle wiederherstellen kann, bevor weitere Mittel eingezahlt werden. Das ist wichtig, weil die Registry-Bereinigung von Olas im Juni 2026 die Bindung zwischen einem Service und seiner Multisig ausdrücklich verschärft hat.

Coinbase AgentKit: Wallet-Aktionen

Coinbase AgentKit bietet Guthabenabfragen, Transfers und Vertragsaufrufe für Wallet-verbundene Software. Es verbindet Tool-Aufrufe mit Transaktionen, entscheidet aber nicht, ob eine Route sinnvoll ist. Anwendungen müssen Tools, Kontoumfang, Chain, Asset, Betrag, Methode und Sitzungsdauer begrenzen.

Ein Entwickler, der AgentKit mit x402 verband, stellte fest, dass Bibliotheken, die von einem extern kontrollierten Konto ausgehen, stillschweigend ausfallen konnten, weil AgentKit ein Smart Account verwendete. Außerdem wurde bei einem Retry zweimal bezahlt, bevor die erste Transaktion bestätigt war. Dieser zweiwöchige Integrationsbericht ist kein plattformweiter Benchmark, liefert aber zwei Release-Prüfungen: Kontotyp erkennen und bezahlte Retries idempotent machen.

Safe: Berechtigungen für Smart Accounts

Safe trennt Modellvorschläge von der Vermögensautorität durch Eigentümer, Schwellenwerte, Module und Guards. Jeder Eigentümer, jedes Modul, jede Ausgabenregel, jeder Upgrade-Pfad und jeder Wiederherstellungsmechanismus sollte geprüft werden, denn ein übermächtiges Modul oder eine unlesbare Oberfläche kann einen starken Schwellenwert schwächen.

Ein Mitglied der Safe-Community, das die geräteübergreifende Verifikation testete, stellte fest, dass Hashes und dekodierte Details auf getrennten Oberflächen verglichen werden mussten. Spätere Tests zeigten, dass eine verschwindende Timeout-Oberfläche falsche Dringlichkeit erzeugen kann. Diese Safe-Genehmigungsexperimente sind Einzelbeobachtungen, stützen aber das Dekodieren und Bestätigen von Vorgängen mit hohem Wert auf einem Gerät, das den Vorschlag nicht erstellt hat.

x402: Maschinenzahlungen

x402 ermöglicht es Software, eine Ressource anzufordern, Zahlungsbedingungen zu erhalten, eine Autorisierung zu signieren, erneut zu versuchen und die Ressource nach dem Settlement zu erhalten. Es deckt nur die Zahlungsebene der breiteren Landschaft von Zahlungsprotokollen für KI-Agenten ab.

Nach sechs Wochen Einsatz von x402 zur Monetarisierung eines MCP-Servers entfernte ein Betreiber es, obwohl er den Zahlungs-Handshake elegant fand. Der Praxisbericht aus erster Hand beschreibt Zahlungs-Retries, Preisgestaltung pro Tool, Wallet-Rate-Limits, Rückerstattungen nach fehlgeschlagenen Jobs, stille Webhook-Fehler und eine separate Anforderung für Kunden, die in Dollar statt in USDC zahlen. Eine einzelne Implementierung kann keine protokollweite Zuverlässigkeit belegen, aber sie zeigt, was ein Release-Test abdecken muss: eine Anfrage nach dem Settlement wiederholen, den bezahlten Job absichtlich fehlschlagen lassen und prüfen, dass eine Autorisierung entweder genau eine gelieferte Antwort oder eine nachvollziehbare Rückerstattung erzeugt, niemals eine zweite Abbuchung.

Berechtigungsstufen von Onchain-KI-Agenten

Fähigkeit zur Recherche und finanzielle Autorität müssen getrennt bewertet werden. Der Übergang von schreibgeschütztem Zugriff zu offenem Signieren schafft neue Verlustpfade und erfordert einen stärkeren Kontrollverantwortlichen. Eine Review aus dem Jahr 2026 zu 317 relevanten Studien trennte ebenfalls schreibgeschützte Analysen, Intent-Generierung, delegierte Ausführung, autonomes Signieren und Multi-Agent-Workflows und verglich dabei Verwahrung, Policy, Beobachtbarkeit und Wiederherstellung.

Das sicherste Produktionsziel ist meist begrenzte Ausführung. Es hält Asset, Ziel, Betrag, Methode und Ablauf außerhalb des Modells durchsetzbar. Ein Prompt kann missverstanden werden; die Kontopolicy kann verhindern, dass der ungültige Aufruf signiert wird.

Sicherheitsrisiken von Onchain-KI-Agenten

Fehler treten häufig an Schnittstellen auf: Daten werden vor dem Signieren alt, Calldata ändert sich nach der Simulation oder eine Zahlung wird beglichen, während die API-Antwort verloren geht. Eine Wallet kann auch ein Limit durchsetzen und dennoch eine allowlist-gestützte Methode mit unbeabsichtigten Parametern aufrufen.

• Veraltete oder manipulierte Eingaben können aus einem alten Quote eine selbstbewusste Empfehlung erzeugen. Zeitstempel, freigegebene Quellen und Frische-Limits sollten dies ablehnen.
• Prompt- oder Tool-Injection kann ein neues Ziel oder eine versteckte Anweisung einführen. Tool-Isolation und Contract-Allowlists halten diese Änderung außerhalb des Signierpfads.
• Simulation Drift tritt auf, wenn Calldata nicht mehr zur Vorschau passt. Das Signieren sollte an die simulierte Calldata und die Frist gebunden bleiben.
• Zu weitreichende Sitzungsautorität lässt eine gültige Aktion über die Absicht des Nutzers hinaus wiederholt werden. Limits für Betrag, Häufigkeit, Asset, Methode und Ablauf begrenzen den Schaden.
• Doppelte bezahlte Retries können nach einem API-Timeout erneut belasten. Ein Idempotency-Key muss den Retry mit der ursprünglichen Autorisierung verbinden.
• Abrechnung ohne Lieferung hinterlässt eine bestätigte Zahlung, aber kein nützliches Service-Ergebnis. Der Beleg braucht eine Lieferprüfung und einen benannten Rückerstattungs- oder Eskalationspfad.

Ein stärkeres Modell kann die Routenwahl verbessern, ersetzt aber keine deterministischen Limits, Wiederherstellung, Idempotenz oder einen Beleg, der das Geschehen nachweist.

Transaktionsbelege und Audit-Trails

Die 50-USDC-Anweisung sollte mit einem Datensatz enden, der die Anfrage mit dem Settlement verbindet. Weder ein Chat-Protokoll noch ein Transaktionshash allein zeigen, welche Quote, welches Limit und welche Policy das Ergebnis erzeugt haben.

• Mandat und Eingaben: ETH auf Base kaufen, nicht mehr als 50 USDC ausgeben, Price Impact unter 0,5% halten und Quellanbieter, Liquidität, Blocknummer und Zeitstempel erfassen.
• Vorgeschlagene Aktion und Simulation: Router, Pool, Token-Adressen, Betrag, Mindest-Output, Frist, Calldata-Hash, projizierte Guthaben, Gas-Schätzung und Änderungen an Genehmigungen beibehalten.
• Policy und Autorisierung: Version der Regel, Freigabe- oder Ablehnungsgrund, Smart Account, Signer oder Sitzung, reservierte Nonce und Ablauf der Berechtigung protokollieren.
• Settlement und Nachbereitung: Transaktionshash, Block, tatsächliche Beträge, Differenz zwischen angefordert und tatsächlich, verbleibende Genehmigungen, Alarm und Wiederherstellungs-Verantwortlichen anhängen.

Bevor das Wallet-Limit erhöht wird, sollten ein veraltetes Quote, ein blockierter Vertrag, ein zu hoher Betrag, eine abgelaufene Sitzung, geänderte Calldata, eine kollidierende Nonce und ein Timeout nach der Zahlung getestet werden. Jeder Fall muss auf seiner zugewiesenen Ebene stoppen und im Protokoll sichtbar bleiben.

Fazit

Onchain-KI-Agenten verbinden offchain-Entscheidungen mit Blockchain-Konten und Zustandsänderungen. Fetch.ai, Olas, AgentKit, Safe und x402 stehen für Entdeckung, persistente Dienste, Aktionstools, Kontopolitik und Zahlungen, nicht für eine austauschbare Produktkategorie. Die stärkste Implementierung zeigt, warum eine Aktion vorgeschlagen wurde, warum die Policy sie erlaubt hat, was die Wallet signiert hat und ob das Settlement dem Mandat entsprach. Beginnen Sie mit beobachtbarer Arbeit, fügen Sie begrenzte Autorität nur für wiederholbare Workflows hinzu und halten Sie die Wiederherstellung außerhalb des Modells.

Häufig gestellte Fragen

Brauchen Onchain-KI-Agenten einen Token?

Nein. Eine Anwendung kann ein Modell, Daten-APIs, Transaktionswerkzeuge und ein Smart Account kombinieren, ohne einen eigenen Token auszugeben oder zu benötigen. Ein Token ist nur dann relevant, wenn er eine notwendige Funktion wie Zahlung, Staking, Zugriff, Governance oder Koordination erfüllt.

Was läuft bei einem Onchain-KI-Agenten offchain?

Das Modell, der Speicher, privater Kontext, Datenverarbeitung und die meiste Inferenz laufen häufig offchain, weil Rechenleistung teuer ist und Eingaben sensibel sein können. Die Blockchain speichert häufiger Identität, Berechtigungen, Zahlungen, Vertragsaufrufe und den Endzustand.

Reichen Smart Accounts für Onchain-KI-Agenten aus?

Nein. Ein Smart Account kann Schwellenwerte, Module und Limits durchsetzen, aber die Konfiguration muss dennoch geprüft werden. Unsichere Module, zu breite Allowlists, lange Sitzungen, schwache Wiederherstellung oder unlesbare Signieroberflächen können die Kontogrenze untergraben.

Mit welchen Wallet-Berechtigungen sollte ein Onchain-KI-Agent beginnen?

Schreibgeschütztes Monitoring und die Vorbereitung nicht signierter Transaktionen geben die geringste finanzielle Autorität. Ausführung auf Genehmigungsbasis ist der nächste Schritt. Begrenzte Automatisierung sollte erst kommen, nachdem Negative-Path-Tests gezeigt haben, dass ungültige, veraltete oder geänderte Aktionen zuverlässig abgelehnt werden.

Haftungsausschluss: Die auf AiCryptoCore.com bereitgestellten Informationen dienen nur zu Bildungs- und Informationszwecken und stellen keine Finanz-, Anlage- oder Handelsberatung dar. Investitionen in Kryptowährungen sind mit Risiken verbunden und können zu finanziellen Verlusten führen. Führen Sie stets Ihre eigene Recherche durch und konsultieren Sie vor Anlageentscheidungen einen qualifizierten Finanzberater.