Was ist ERC-8257? Das „ Agent “-Tool-Register erklärt
Was ist ERC-8257? Ein Leitfaden zu „ Ethereum “ (Agent ), dem Tool-Register, der Tool-Suche, Prädikaten, „ agent “-Marktplätzen und der KI-Infrastruktur.

22. Juni 2026 – 8 Minuten Lesezeit

KI- agents en können Code generieren, Workflows ausführen und mit externen Diensten interagieren.
Neue Werkzeuge zu finden, ist nach wie vor viel schwieriger.
Die meisten „ agents “ stützen sich auf zuvor konfigurierte Integrationen, sei es über Eingabeaufforderungen, Frameworks, APIs oder Marktplätze. Da die Zahl der über agent zugänglichen Dienste wächst, lässt sich dieser Ansatz nur noch schwer skalieren.
ERC-8257 verspricht eine genehmigungsfreie Möglichkeit, agentische Tools und Dienste zu finden und zu überprüfen.
In diesem Blogbeitrag wird erläutert, was ERC-8257 ist, wie ein „ agent “-Tool-Register funktioniert, wie es sich in den gesamten Agentic-Infra-Stack einfügt und welche Möglichkeiten dieses Register eröffnet.
ERC-8257 (Agent -Tool-Register) ist ein Entwurf für einen Standard der „ Ethereum “, der ein zugangsfreies On-Chain-Register für KI- agents en und -Tools definiert. Er standardisiert eine minimale, überprüfbare Aufzeichnung darüber, was ein Tool ist, wer es veröffentlicht hat und wer es aufrufen darf.
Im April 2026 schlugen Cody Sears und Ryan Ghods von OpenSea diesen Standard vor, um KI- agents n die Möglichkeit zu geben, Tools selbstständig zu finden, Zugriff darauf zu erwerben und diese aufzurufen.
Jedes registrierte Tool oder jede ERC-8257-kompatible „ agent “ verfügt über einen On-Chain-Eintrag, der aus drei Komponenten besteht:
Angabe zum Urheber: der Herausgeber, bei der Registrierung dauerhaft festgehalten
Metadaten-URI: Ein Verweis auf das Off-Chain-Manifest des Tools
Manifest-Hash: Überprüft, ob sich die Beschreibung nicht geändert hat
Und eine optionale vierte Komponente im Zugriffsprädikat, nämlich eine Vertragsadresse, die festlegt, wer das Tool aufrufen darf.
Zusammen bilden diese Elemente eine gemeinsame, verlässliche Quelle für Tool-Metadaten mit einer Garantie: Das von Ihnen abgerufene Manifest ist genau dasjenige, das der Ersteller von dem von ihm kontrollierten Ursprung aus unter der von ihm signierten Adresse committet hat.
Nachdem wir nun den Zweck und die Komponenten des agent -Tool-Registers verstanden haben, wollen wir uns nun damit befassen, wie diese zusammenwirken und wie die flow aussieht.
Wussten Sie schon? ERC-8257 ist unter Ethereum ,mainnet und Base verfügbar und umfasst Stand Mitte 2026 76 indexierte Tools.
Im Rahmen von ERC-8257 gibt es zwei Arbeitsabläufe, nämlich:
Register- Flow: Interaktion zwischen Herausgeber und Register.
Ermittlung und Verifizierung von Flow: Wechselwirkungen zwischen agents, dem Register und den Tools.
Schauen wir uns das jeweils einzeln an.
Das Register flow regelt, wie ein Tool veröffentlicht und auffindbar gemacht wird. Ein Herausgeber registriert die Adresse des Erstellers des Tools, die Metadaten-URI und den Manifest-Hash (sowie ein optionales Zugriffsprädikat) und erstellt damit den On-Chain-Eintrag, den agents später auflösen und verifizieren kann.
Wenn ein „ agent “ ein Tool oder einen Dienst findet, schafft dieser Erkennungs- und Verifizierungsprozess Vertrauen in die Metadaten, die der „ agent “ ausliest.
Die Rolle der Registrierungsstelle endet, sobald die „ agent “ überprüft hat, dass das Manifest, der Herausgeber und die Zugangsvoraussetzungen mit dem registrierten Datensatz übereinstimmen.
Bislang scheint ERC-8257 ein gewöhnliches Register zu sein, doch durch den optionalen Prädikatabschnitt wird ERC-8257 zu mehr als nur einem Register.
Das Tool-Register „ agent “ dient der Erkennung und Überprüfung. Allerdings sollte nicht jedes Tool von jedem „ agent “ aufrufbar oder vollständig öffentlich sein.
Für einige Dienste ist möglicherweise ein Abonnement erforderlich. Andere Dienste sind möglicherweise auf NFT-Inhaber, Unternehmenskunden oder „ agents “ beschränkt, die bestimmte Reputationsanforderungen erfüllen.
ERC-8257 löst das Zugriffsproblem mithilfe einer optionalen Komponente, die als „Zugriffsprädikat“ bezeichnet wird: ein externer Vertrag, der entscheidet, ob ein Aufrufer ein Tool nutzen darf.
Ein Zugriffsprädikat ist eine Vertragsadresse, die einer Werkzeugregistrierung zugeordnet ist.
Wenn ein „ agent “ versucht, ein Tool zu verwenden, kann es den Prädikat-Vertrag aufrufen und eine einfache Frage stellen: Darf dieser Aufrufer auf dieses Tool zugreifen?
Nun kann der Prädikatvertrag prüfen, ob ein „ agent “ ein NFT besitzt, einen Abonnement-Token hält, für den Zugriff bezahlt hat, auf einer Zulassungsliste steht oder eine Reputationsanforderung erfüllt.
Verschiedene Tools können unterschiedliche Richtlinien umsetzen, ohne dass Änderungen an der Registrierungsdatenbank selbst erforderlich sind. Hier sind einige Beispiele:
Werkzeugtyp | Prädikatenlogik |
|---|---|
Öffentliche API | Gibt immer „true“ zurück |
Hochwertiges Recherchetool | Gültigkeit des Abonnements überprüfen |
Unternehmensdienst | Zugehörigkeit zur Whitelist prüfen |
NFT-basiertes Tool | NFT-Besitz überprüfen |
Agent Marktplatz | Zahlungs- oder Bonitätsanforderungen prüfen |
Vor allem aber sind in ERC-8257 keine dieser Regeln fest codiert; stattdessen wird der Prädikat-Vertrag als optionales Add-on behandelt, wodurch der Standard schlank bleibt und gleichzeitig für eine Vielzahl von Anwendungsfällen erweiterbar ist.
Wir wissen nun, was die „ agent “-Tool-Registrierung ist, wie sie registriert wird, wie „ agents “ sie erkennt und wie der Zugriff gesteuert wird. Als Nächstes: Was lässt sich damit erstellen?
Eine Registrierungsstelle an sich ist nicht besonders interessant.
DNS gewann an Bedeutung, weil Websites über dieses System gefunden werden konnten. Paketregister gewannen an Bedeutung, weil Software darauf angewiesen sein konnte. App-Stores gewannen an Bedeutung, weil sie Nutzer mit Anwendungen verbanden.
ERC-8257 schafft eine Discovery-Ebene für Tools, die über agent zugänglich sind. Sehen wir uns einige Funktionen an, die dadurch ermöglicht werden:
Jedes Tool verfügt über eine nachweisbare Herkunft, programmierbaren Zugriff und Preisangaben in der Blockchain. Das reicht aus, um einen Marktplatz aufzubauen, auf dem Tools entdeckt, genutzt und gehandelt werden können, ohne dass ein Plattformbetreiber dabei als Vermittler auftritt.
Ein Tool-Anbieter kann über den Prädikat-Vertrag Preise, Abonnements, Anforderungen an den Token-Besitz, Reputationsschwellenwerte oder Unternehmensberechtigungen festlegen. Diese Flexibilität ermöglicht den Wettbewerb zwischen verschiedenen Zugriffsmodellen, während die Interoperabilität auf der Discovery-Ebene gewahrt bleibt.
Mit ERC-8257 sind nun mehrstufige „ agent “-Pipelines möglich, bei denen jedes Tool unabhängig überprüft und freigegeben wird.
Beispielsweise kann eine Trading-Web agent mit einem 24/7-News-Scraper-Tool verknüpft werden, oder eine Prognosemarkt-Web agent kann mit einem Twitter-Account (X) agent verknüpft werden.
ERC-8257 bietet eine standardisierte Methode zur Ermittlung und Überprüfung dieser Abhängigkeiten, wodurch sich Multi-agent -Workflows über unabhängige Anbieter hinweg einfacher zusammenstellen lassen.
Jede Plattform steht früher oder später vor derselben Herausforderung: die Pflege eines eigenen Verzeichnisses ihrer Dienste.
ERC-8257 verlagert diese Verantwortung auf eine gemeinsam genutzte Infrastruktur. Tool-Anbieter veröffentlichen die Daten einmal. Agent Frameworks, Wallets, Marktplätze und Anwendungen nutzen dieselben Datensätze.
Die meisten „ agent “-Workflows laufen heute innerhalb einer einzigen Organisation oder Plattform ab.
ERC-8257 ebnet den Weg für organisationsübergreifende Arbeitsabläufe wie beispielsweise zwischen Anbietern und Kunden, zwischen Kunden und Marktplätzen und vieles mehr.
Beispielsweise könnte ein Forschungs agent us den Zugriff auf proprietäre Datenfeeds erwerben, die über registrierte Tools bereitgestellt werden.
Die Funktionsweise und die Möglichkeiten von ERC-8257 sind nun bekannt. Als Nächstes gilt es, den umfassenderen „ agent “-Stack zu verstehen, der erforderlich ist, damit „ agents “ tatsächlich funktioniert.
ERC-8257 löst ein spezifisches Problem innerhalb des umfassenderen „ agent “-Stacks: die Erkennung von Fähigkeiten und die überprüfbare Interaktion.
Allerdings benötigen „ agents “ nach wie vor Identitäten, Ausführungsumgebungen, Zahlungswege und Koordination, um miteinander interagieren zu können.
Lassen Sie uns nun den Stapel zusammenstellen.
Ebene | Frage | Protokoll |
|---|---|---|
Agent Identität | Wer ist der „ agent “? | ERC-8004-Identitäten oder Wallets |
Entdeckung | Welche Funktionen gibt es? | ERC-8257 |
Zugriffskontrolle | Wer kann sie nutzen? | ERC-8257-Prädikate |
Zahlungen | Wie wird der Zugang finanziert? | x402, Stablecoins |
Ausführung | Wie werden Tools aufgerufen? | MCP, APIs, „ agent “-Frameworks |
Koordination | Wie arbeiten „ agents “ zusammen? | Multiagent -Systeme |
Mit diesem lens wirkt ERC-8257 weniger wie ein KI-Standard, sondern eher wie eine Infrastruktur.
Ein registriertes Tool kann einen MCP-Server offenlegen.
Ein Prädikat kann eine Zahlung verlangen, bevor der Zugriff gewährt wird.
Zur Identitätsfeststellung des Antragstellers kann ein Identitätsstandard gemäß „ agent “ herangezogen werden.
Keine dieser Aufgaben obliegt ERC-8257 selbst.
Die Aufgabe des Standards besteht darin, eine einfachere Frage zu beantworten: „Welche Funktionen stehen zur Verfügung und wo sind sie zu finden?“
Nun, die Architektur ist solide, ebenso wie die Designentscheidung. Die offenen Fragen betreffen die Akzeptanz.
Die meisten Softwareprogramme basieren heutzutage auf direkten Integrationen.
Ein Entwickler wählt einen Dienst aus, liest dessen Dokumentation, schreibt Code auf Basis dessen API und pflegt diese Beziehung im Laufe der Zeit.
ERC-8257 trägt nicht dazu bei, sondern lenkt die Entwicklung der agentenbasierten Infrastruktur in eine andere Richtung.
Funktionen werden zur Laufzeit erkennbar.
Zugriffsrichtlinien lassen sich programmieren.
Dienste können ohne menschliche Genehmigung in Anspruch genommen werden.
ERC-8257 ist eine gängige Discovery-Schicht. Das mag wie ein kleiner Teil der Infrastruktur erscheinen.
DNS war ein kleiner Teil der Infrastruktur. Paket-Registerstellen waren ein kleiner Teil der Infrastruktur. App-Stores begannen als Verzeichnisse.
Die größere Herausforderung liegt noch vor uns.
Wie sollten „ agents “ die Reputation bewerten? Wie sollten Marktplätze Tools einstufen? Nach welchen Standards sollten Zahlungen, Abonnements oder die Umsatzbeteiligung zwischen autonomen Systemen geregelt werden? Wie sollten Organisationen interne Fähigkeiten offenlegen, ohne die Sicherheit zu gefährden?
ERC-8257 gibt keine Antworten auf die Fragen. Es leitet den Dialog und den Lösungsweg ein.
Ein Anbieter registriert ein Tool, indem er eine Erstelleradresse, eine Metadaten-URI, einen Manifest-Hash und optional ein Zugriffsprädikat veröffentlicht. Agents ruft das Manifest ab, vergleicht es mit dem Eintrag in der Blockchain, prüft etwaige Zugriffsvoraussetzungen und ruft anschließend das Tool auf.
Ein Manifest ist eine maschinenlesbare Beschreibung eines Tools. Es enthält Metadaten wie Funktionen, Endpunkte, Nutzungsanforderungen und weitere Informationen, die „ agents “ benötigt, um den Dienst zu verstehen und mit ihm zu interagieren.
Nein. Jeder maschinell zugängliche Dienst kann über ERC-8257 registriert werden. Der Standard wurde zwar mit Blick auf KI- agents s entwickelt, doch auch APIs, Software-Dienste, Automatisierungssysteme und andere programmierbare Anwendungen können dasselbe Erkennungsmodell nutzen.
MCP standardisiert die Art und Weise, wie Tools bereitgestellt und aufgerufen werden. ERC-8257 standardisiert die Art und Weise, wie Tools erkannt und verifiziert werden. Beide ergänzen sich und können gemeinsam innerhalb derselben „ agent “-Architektur eingesetzt werden.
Entwickler können auf der Grundlage eines gemeinsamen Registrierungsstandards „ agent “-Marktplätze, programmierbare Zugangssysteme, organisationsübergreifende „ agent “-Workflows, Service-Discovery-Schichten und „multi-agent “-Ökosysteme aufbauen.
Ja. Der ToolRegistry-Vertrag wird unter folgender Adresse bereitgestellt: 0x265BB2DBFC0A8165C9A1941Eb1372F349baD2cf1 unter Ethereum ,mainnet und Base. Stand Mitte 2026 sind 76 Tools indexiert. Der EIP befindet sich weiterhin im Entwurfsstatus, was bedeutet, dass sich die Schnittstelle vor der endgültigen Festlegung noch ändern kann.
Nein. Die Registry speichert Verweise auf Metadaten und nicht die Metadaten selbst. Die Beschreibungen der Tools verbleiben außerhalb der Blockchain, während die in der Blockchain gespeicherten Hashes es agents ermöglichen, deren Integrität zu überprüfen.
Quicknode wurde 2017 gegründet und stellt Entwicklern und Unternehmen eine Blockchain-Infrastruktur auf institutionellem Niveau zur Verfügung. Dank einer Verfügbarkeit von 99,99 % und der Unterstützung von mehr als 77 Blockchains können Teams On-Chain-Anwendungen ohne Kompromisse entwickeln und skalieren.
Die neuesten Erkenntnisse aus der Technik, Produkt-Updates und Neuigkeiten aus der Web3-Welt – direkt in Ihren Posteingang.
📚 NEU: Entwicklung von Finanzsoftware auf SolanaKostenloses Buch mit 10 vollständigen Programmen, von Optionen bis hin zu Perps.
Eine Kopie besorgen