Quicknode

22 juni 2026 — leestijd: 8 min.

AI-agenten kunnen code genereren, workflows uitvoeren en communiceren met externe diensten.

Het vinden van nieuwe hulpmiddelen blijft een stuk moeilijker.

De meeste agents maken gebruik van integraties die vooraf zijn geconfigureerd, hetzij via prompts, frameworks, API’s of marktplaatsen. Naarmate het aantal diensten waartoe agents toegang hebben toeneemt, wordt die aanpak steeds moeilijker op te schalen.

ERC-8257 belooft een toelatingsvrije manier om agentische tools en diensten te ontdekken en te verifiëren.

In deze blog wordt uitgelegd wat ERC-8257 is, hoe een register voor agenttools werkt, hoe dit past in de algehele agentic-infrastructuurstack en welke mogelijkheden dit register biedt.

Wat is ERC-8257?

ERC-8257 (Agent Tool Registry) is een ontwerp voor een Ethereum-standaard die een toestemmingsvrije on-chain-registratie voor AI-agenten en -tools definieert. Deze standaard legt een minimale, verifieerbare registratie vast van wat een tool is, wie deze heeft gepubliceerd en wie deze mag aanroepen.

In april 2026 hebben Cody Sears en Ryan Ghods van OpenSea deze standaard voorgesteld om AI-agenten in staat te stellen zelfstandig tools te ontdekken, toegang daartoe aan te schaffen en deze te activeren.

Hoe ERC-8257 werkt

Elk geregistreerd tool of elke ERC-8257-compatibele agent beschikt over een on-chain-record dat uit drie onderdelen bestaat:

1. Adres van de maker: de uitgever, bij de registratie definitief vastgelegd

2. Metadata-URI: een verwijzing naar het off-chain-manifest van de tool

3. Manifest-hash: controleert of de beschrijving niet is gewijzigd

En een optioneel vierde onderdeel van het toegangsvoorwaarde, namelijk een contractadres dat bepaalt wie de tool kan aanroepen.

Samen vormen deze een gezamenlijke betrouwbare bron voor metadata van tools, met één garantie: het manifest dat je hebt opgehaald, is hetzelfde manifest dat de maker heeft vastgelegd, vanaf de bron die hij beheert, onder het adres waarmee hij het heeft ondertekend.

Nu we het doel en de onderdelen van het agent-toolregister hebben begrepen, gaan we bekijken hoe deze allemaal samenwerken en hoe het proces verloopt.

Er zijn twee workflows binnen ERC-8257, namelijk:

1. Registratieproces: Interactie tussen uitgever en register.

2. Ontdekkings- en verificatieproces: wisselwerking tussen actoren, het register en hulpmiddelen.

Laten we ze één voor één bekijken.

ERC-8257: Hoe de registratiestroom werkt

De registratiestroom bepaalt hoe een tool wordt gepubliceerd en vindbaar wordt gemaakt. Een uitgever registreert het adres van de maker van de tool, de URI van de metagegevens en de hash van het manifest (plus een optioneel toegangsvoorwaarde), waarmee een on-chain-record wordt aangemaakt dat agenten later kunnen opzoeken en verifiëren.

ERC-8257: Hoe de detectie en verificatie werken

Wanneer een agent een tool of een dienst ontdekt, zorgt dit ontdekkings- en verificatieproces ervoor dat er vertrouwen ontstaat in de metagegevens die de agent leest.

De rol van het register eindigt zodra de agent heeft gecontroleerd of het manifest, de uitgever en de toegangsvereisten overeenkomen met het geregistreerde record.

Tot nu toe lijkt ERC-8257 een standaardregister, maar dankzij het optionele predikaatgedeelte is ERC-8257 meer dan alleen een register.

ERC-8257 Toegangscontrole: het predikaatpatroon uitgelegd

Het register van agenttools biedt een oplossing voor het opsporen en verifiëren van tools. Maar niet elke tool hoeft door elke agent te kunnen worden aangeroepen of volledig openbaar te zijn.

Voor sommige diensten is mogelijk een abonnement vereist. Andere diensten zijn mogelijk voorbehouden aan NFT-houders, zakelijke klanten of agenten die aan specifieke reputatie-eisen voldoen.

ERC-8257 lost het toegangsvraagstuk op met een optionele component die een ‘toegangspredikaat’ wordt genoemd: een extern contract dat bepaalt of een aanroeper een tool mag gebruiken.

Wat is predikaatgebaseerde toegangscontrole?

Een toegangsvoorwaarde is een contractadres dat aan een gereedschapsregistratie is gekoppeld.

Wanneer een agent een tool probeert te gebruiken, kan hij het predicaatcontract aanroepen en een eenvoudige vraag stellen: Mag deze aanroeper toegang krijgen tot deze tool?

Het predicaatcontract kan nu controleren of een agent eigenaar is van een NFT, een abonnementstoken bezit, voor toegang heeft betaald, op een allowlist staat of aan een reputatie-eis voldoet.

Verschillende tools kunnen verschillende beleidsregels toepassen zonder dat er wijzigingen in het register zelf nodig zijn. Hier volgen enkele voorbeelden:

Het belangrijkste is dat ERC-8257 geen van deze regels vastlegt; het laat het predicaatcontract als een optionele uitbreiding fungeren, waardoor de standaard lichtgewicht blijft en tegelijkertijd uitbreidbaar is voor een groot aantal gebruiksscenario’s.

We weten nu wat het agent-toolregister is, hoe het wordt geregistreerd, hoe agents het vinden en hoe de toegang wordt beheerd. Wat kun je hier vervolgens mee bouwen?

Wat ERC-8257 mogelijk maakt

Een register op zich is niet bijzonder interessant.

DNS werd belangrijk omdat websites ermee konden worden gevonden. Pakketregisters werden belangrijk omdat software ervan afhankelijk kon zijn. App-winkels werden belangrijk omdat ze gebruikers in contact brachten met applicaties.

ERC-8257 creëert een discovery-laag voor tools die toegankelijk zijn voor agents. Laten we eens kijken naar een aantal mogelijkheden die hierdoor worden ontgrendeld:

1. Marktplaatsen met actoren

Elke tool heeft een verifieerbare herkomst, programmeerbare toegang en prijsindicaties op de blockchain. Dat is voldoende om een marktplaats op te zetten waar tools kunnen worden ontdekt, geraadpleegd en verhandeld zonder dat een platformbeheerder daarbij als tussenpersoon optreedt.

2. Markten voor programmeerbare toegang

Een tool-aanbieder kan via het predicaatcontract prijzen, abonnementen, vereisten inzake tokenbezit, reputatiedrempels of bedrijfsmachtigingen vastleggen. Dankzij deze flexibiliteit kunnen verschillende toegangsmodellen met elkaar concurreren, terwijl ze op het ontdekkingsniveau onderling uitwisselbaar blijven.

3. Samenstelbare agent-workflows

Met ERC-8257 zijn nu meerstaps-agentpijplijnen mogelijk waarbij elke tool afzonderlijk wordt geverifieerd en gecontroleerd.

Zo kan een handelsagent bijvoorbeeld worden gekoppeld aan een tool die 24 uur per dag, 7 dagen per week nieuws verzamelt, of kan een voorspellingsmarktagent worden gekoppeld aan een Twitter (X)-agent.

ERC-8257 biedt een gestandaardiseerde manier om die afhankelijkheden te identificeren en te verifiëren, waardoor het eenvoudiger wordt om multi-agent-workflows samen te stellen waarbij gebruik wordt gemaakt van onafhankelijke aanbieders.

4. Open agent-ecosystemen

Elk platform krijgt uiteindelijk te maken met dezelfde uitdaging: het bijhouden van een eigen overzicht van diensten.

ERC-8257 verlegt die verantwoordelijkheid naar een gedeelde infrastructuur. Aanbieders van tools publiceren de gegevens één keer. Agent-frameworks, wallets, marktplaatsen en applicaties maken gebruik van dezelfde gegevens.

5. Organisatieoverschrijdende workflows voor agenten

De meeste workflows van makelaars spelen zich tegenwoordig af binnen één organisatie of op één platform.

ERC-8257 maakt de weg vrij voor organisatieoverschrijdende workflows, zoals leverancier-klant, klant-marktplaats en nog veel meer.

Een onderzoeksmedewerker zou bijvoorbeeld toegang kunnen kopen tot eigen gegevensbronnen die via geregistreerde tools beschikbaar worden gesteld.

De werking en mogelijkheden van ERC-8257 zijn nu duidelijk. De volgende stap is inzicht krijgen in de bredere agentstack die nodig is om agenten daadwerkelijk te laten functioneren.

De plaats van ERC-8257 in de infrastructuurstack van Agentic

ERC-8257 biedt een oplossing voor één specifiek probleem binnen de bredere agentstack: het in kaart brengen van mogelijkheden en verifieerbare interactie.

Maar agenten hebben nog steeds identiteit, uitvoeringsomgevingen, betalingskanalen en coördinatie nodig om met elkaar te kunnen communiceren.

Laten we de stapel nu eens in elkaar zetten.

Met deze lens lijkt de ERC-8257 minder op een AI-standaard en meer op infrastructuur.

• Een geregistreerd hulpprogramma kan een MCP-server blootstellen.

• Een predikaat kan betaling vereisen voordat toegang wordt verleend.

• Er kan gebruik worden gemaakt van een standaard voor de identificatie van een agent om aan te tonen wie het verzoek indient.

Geen van deze verantwoordelijkheden valt onder ERC-8257 zelf.

De rol van de norm is om een eenvoudigere vraag te beantwoorden: „Welke mogelijkheden zijn er en waar zijn ze te vinden?”

De architectuur is in orde, net als de ontwerpkeuze. De openstaande vragen hebben betrekking op de acceptatie.

Wat staat er op het programma voor ERC-8257?

De meeste software is tegenwoordig gebaseerd op directe integraties.

Een ontwikkelaar kiest een dienst, bestudeert de documentatie ervan, schrijft code op basis van de API ervan en onderhoudt die relatie in de loop van de tijd.

ERC-8257 draagt hier niet aan bij, maar stuurt de agentische infrastructuur juist een andere richting op.

• Functies worden tijdens de uitvoering zichtbaar.

• Toegangsbeleidsregels worden programmeerbaar.

• Diensten kunnen worden afgenomen zonder menselijke goedkeuring.

ERC-8257 is een veelgebruikte discovery-laag. Dat lijkt misschien maar een klein onderdeel van de infrastructuur.

DNS was een klein onderdeel van de infrastructuur. Pakketregisters waren een klein onderdeel van de infrastructuur. App-winkels begonnen als overzichten.

De grootste uitdaging ligt nog in het verschiet.

Hoe moeten agenten de reputatie beoordelen? Hoe moeten marktplaatsen tools rangschikken? Welke normen moeten gelden voor betalingen, abonnementen of het delen van inkomsten tussen autonome systemen? Hoe moeten organisaties hun interne mogelijkheden toegankelijk maken zonder de veiligheid in gevaar te brengen?

ERC-8257 geeft geen antwoord op de vragen. Het zet de dialoog en het pad naar een oplossing in gang.

Veelgestelde vragen (FAQ)

1. Hoe werkt ERC-8257?

Een aanbieder registreert een tool door een makeradres, een metadata-URI, een manifest-hash en een optioneel toegangsvoorwaarde te publiceren. Agenten halen het manifest op, verifiëren dit aan de hand van het on-chain-record, beoordelen eventuele toegangsvereisten en roepen vervolgens de tool aan.

2. Wat is een ERC-8257-manifest?

Een manifest is een machinaal leesbare beschrijving van een tool. Het bevat metagegevens zoals mogelijkheden, eindpunten, gebruiksvereisten en andere informatie die agents nodig hebben om de dienst te begrijpen en ermee te communiceren.

3. Is ERC-8257 alleen bedoeld voor AI-agenten?

Nee. Elke machine-toegankelijke dienst kan via ERC-8257 worden geregistreerd. Hoewel de standaard is ontworpen met het oog op AI-agenten, kunnen API’s, softwarediensten, automatiseringssystemen en andere programmeerbare toepassingen hetzelfde detectiemodel gebruiken.

4. Waarin verschilt ERC-8257 van MCP?

MCP zorgt voor standaardisatie van de manier waarop tools worden aangeboden en aangeroepen. ERC-8257 zorgt voor standaardisatie van de manier waarop tools worden gevonden en geverifieerd. Beide zijn complementair en kunnen samen worden gebruikt binnen dezelfde agentarchitectuur.

5. Wat kunnen ontwikkelaars bouwen met ERC-8257?

Ontwikkelaars kunnen op basis van een gedeelde registratiestandaard agentenmarktplaatsen, programmeerbare toegangssystemen, organisatieoverschrijdende agentenworkflows, service-discovery-lagen en multi-agent-ecosystemen bouwen.

6. Is ERC-8257 live op het mainnet?

Ja. Het ToolRegistry-contract is geïmplementeerd op 0x265BB2DBFC0A8165C9A1941Eb1372F349baD2cf1 op het Ethereum-mainnet en Base. Medio 2026 zijn er 76 tools geïndexeerd. De EIP heeft nog steeds de status ‘Draft’, wat betekent dat de interface nog kan veranderen voordat deze definitief wordt vastgesteld.

7. Slaat ERC-8257 metadata over tools op in de blockchain?

Nee. Het register slaat verwijzingen naar metadata op, en niet de metadata zelf. Beschrijvingen van tools blijven buiten de blockchain, terwijl agents aan de hand van de op de blockchain opgeslagen hashes de integriteit ervan kunnen controleren.