Quicknode

22 juni 2026 — leestijd: 8 min.

agents code genereren, workflows uitvoeren en communiceren met externe diensten.

Het vinden van nieuwe hulpmiddelen blijft een stuk moeilijker.

De meeste agents van integraties die vooraf zijn geconfigureerd, hetzij via prompts, frameworks, API’s of marktplaatsen. Naarmate het aantal diensten waartoe agent 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 agent werkt, hoe dit past in de algehele agentic-infrastructuurstack en welke mogelijkheden dit register biedt.

Wat is ERC-8257?

ERC-8257 (Agent Registry) is een ontwerp voor Ethereum die een toestemmingsvrije on-chain-registratie voor agents -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 agents in staat agents stellen zelfstandig tools agents ontdekken, toegang daartoe aan te schaffen en deze te activeren.

Hoe ERC-8257 werkt

Elk geregistreerd hulpmiddel of elke ERC-8257-compatibele agent 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 in 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 hebben begrepen, gaan we bekijken hoe deze allemaal samenwerken en hoe het flow .

Er zijn twee workflows binnen ERC-8257, namelijk:

1. Flow: Interactie tussen uitgever en register.

2. Ontdekkings- en Flow: wisselwerking tussen agents, het register en hulpmiddelen.

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

ERC-8257: Hoe de Flow

De flow 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 agents later agents opzoeken en verifiëren.

ERC-8257: Hoe de detectie en verificatie werken

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

De rol van het register eindigt zodra de agent 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 agent biedt een oplossing voor het opsporen en verifiëren agent . Maar niet elke tool hoeft door elke agent te kunnen worden aangeroepen agent volledig openbaar te zijn.

Voor sommige diensten is mogelijk een abonnement vereist. Andere diensten zijn mogelijk voorbehouden aan NFT-houders, zakelijke klanten of agents 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 agent 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 een NFT, een abonnementstoken bezit, voor toegang heeft betaald, op een allowlist staat of aan een reputatie-eis voldoet.

Verschillende hulpprogramma’s 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 agent is, hoe het wordt geregistreerd, hoe agents het agents 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 agent. 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 voor het bezit van tokens, reputatiedrempels of bedrijfsmachtigingen vastleggen. Dankzij deze flexibiliteit kunnen verschillende toegangsmodellen met elkaar concurreren, terwijl ze op het ontdekkingsniveau onderling uitwisselbaar blijven.

3. Samenstelbare Agent

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

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

ERC-8257 biedt een gestandaardiseerde manier om die afhankelijkheden in kaart te brengen en te verifiëren, waardoor het eenvoudiger wordt omagent samen te stellen waarbij gebruik wordt gemaakt van onafhankelijke aanbieders.

4. Open Agent

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 , wallets, marktplaatsen en applicaties maken gebruik van dezelfde gegevens.

5. Organisatieoverschrijdende Agent

De meeste agent vinden tegenwoordig plaats 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 agent bijvoorbeeld toegang agent 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 te krijgen in de bredere agent die nodig is om agents 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 agent : het in kaart brengen van mogelijkheden en verifieerbare interactie.

Maar agents hebben agents 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 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 moeilijkste uitdaging ligt nog in het verschiet.

Hoe moeten agents de reputatie agents ? 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 capaciteiten toegankelijk maken zonder de veiligheid in gevaar te brengen?

ERC-8257 geeft geen antwoord op de vragen. Het zet de dialoog en het oplossingstraject 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. Agents het manifest Agents , 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 agents om de dienst te begrijpen en ermee te communiceren.

3. Is ERC-8257 alleen bedoeld voor agents?

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

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 gedetecteerd en geverifieerd. Beide zijn complementair en kunnen samen worden gebruikt binnen dezelfde agent .

5. Wat kunnen ontwikkelaars bouwen met ERC-8257?

Ontwikkelaars kunnen op basis van een standaard voor gedeelde registers agent , programmeerbare toegangssystemen, organisatieoverschrijdende agent , service-discovery-lagen enagent bouwen.

6. Is ERC-8257 live op mainnet?

Ja. Het ToolRegistry-contract is geïmplementeerd op 0x265BB2DBFC0A8165C9A1941Eb1372F349baD2cf1 opmainnet 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 de op de blockchain opgeslagen hashes de integriteit ervan kunnen controleren.