open source

Open-sourcegereedschap

Draai het zelf, dan hoef je ons niet te geloven.

Het gereedschap

capacity-attest

Na een x402-betaling voor capaciteit laat de betalende agent een ondertekende claim achter van wat volgens hem is geleverd. Een vastlegging, geen score en geen oordeel.

Op npm
agent-receipt-verify

Controleert of een x402-endpoint zich aan de regels houdt voordat een agent betaalt, en koppelt het bonnetje aan zijn afwikkeling.

Op npm
x402-lint

Controleert het eigen payment-required-antwoord (402) van een x402-verkoper tegen het echte schema aan de koperskant.

Op npm
muraqib-agent-watch

Een gratis, directe capaciteitscheck voor een MCP-server: hij laat zien wat de tools zeggen te kunnen (geld, bestanden, uitgaande berichten, destructieve acties, inloggegevens) en markeert tools die hun eigen beveiliging niet noemen.

Op npm

De code op GitHub

Waar het ophoudt

Geen score, geen oordeel en geen eigen token.

Het probleem

Betalen gaat al vanzelf. Nakijken wat je kreeg, niet.

Een agent betaalt in een seconde voor rekenkracht, opslag of toegang tot een dienst. Kreeg hij minder dan beloofd, dan verdwijnt dat zodra de sessie stopt. Er blijft niets over dat iemand later kan bekijken. Geen klacht, geen bewijs, geen geheugen.

De koper weet het

Hij zag de output, of zag hem niet. Maar die kennis gaat verloren zodra de sessie eindigt.

De volgende koper niet

Die begint blind bij dezelfde verkoper, zonder geschiedenis om op te checken vóór hij zelf betaalt.

Meestal geen vastlegging van de claim

Zonder ondertekend spoor is er niets dat een belofte aan een geclaimde levering koppelt, laat staan iets dat een volgende koper kan controleren.

Waarom nu

Drie ontwikkelingen vallen dit jaar samen.

In onze eigen negen scans van augustus 2026 was het patroon hetzelfde: de koperskant van de agent-economie krijgt alle aandacht. De verkoperskant en het object zelf (het bewijs) blijft onderbelicht, precies op het moment dat regelgeving en betaalrails er wél om vragen.

20 juli 2026

EU Digital Product Passport-register live

De Europese Commissie opende het DPP-register; verplichte paspoorten volgen gefaseerd per productcategorie (batterijen vanaf feb. 2027). Dat laat zien dat een machineleesbaar productpaspoort zonder financiële functie een echte EU-norm wordt, niet dat het nu al overal verplicht is. regelgeving

EU AI Act, Artikel 14

Hoog-risico AI-systemen moeten aantoonbaar door mensen te overzien zijn. Dat vraagt om een controleerbaar spoor van wat een autonome agent deed, precies het soort auditeerbaarheid waar Tokenizen op inspeelt, zonder dat wij zelf een Artikel 14-nalevingsclaim doen. doorlopend

x402 en Google AP2 laten één vraag open

Coinbase en Google bouwden de betaal- en autorisatie-rails. “Wat koop ik precies, en mag de verkoper dit leveren?” blijft onbeantwoord.

Pijler 1: bewijs van levering

Een bonnetje van wat er geleverd is. Geen cijfer, geen oordeel.

Zodra een agent betaald heeft, legt hij vast of hij kreeg wat beloofd was: ja, nee, of gedeeltelijk. Dat bonnetje wordt ondertekend, dus een latere wijziging valt op. Wie later met diezelfde verkoper zaken wil doen, kan die geschiedenis opvragen voordat hij betaalt.

MCP tool-call → record_delivery

{
"tool": "record_delivery",
"arguments": {
"sellerAddress": "0x9f1C1a3b…6e7F80",
"buyerAddress": "0x1a2B3c4D…8e9F01",
"assetType": "gpu-hours",
"promisedSpec": {
"gpuModel": "A100",
"hours": 4,
"region": "us-east"
},
"delivered": "yes",
"evidenceHash": "8f3a1c9e4b…b7d9f0",
"settlementRef": "0xaaaaaaaa…aaaaaa",
"timestamp": "2026-08-31T09:14:02.000Z",
"claimId": "0x7c2ee1a4…a1f4b9",
"signature": "0x4b91e2c7…b2e5a8"
}
}

antwoord

{
"ok": true,
"claimId": "0x7c2ee1a4…a1f4b9"
}

MCP tool-call → get_delivery_history

{
"tool": "get_delivery_history",
"arguments": {
"sellerAddress": "0x9f1C1a3b…6e7F80"
}
}

antwoord

{
"sellerAddress": "0x9f1C1a3b…6e7F80",
"count": 1,
"claims": [
{
"sellerAddress": "0x9f1C1a3b…6e7F80",
"buyerAddress": "0x1a2B3c4D…8e9F01",
"assetType": "gpu-hours",
"delivered": "yes",
"settlementRef": "0xaaaaaaaa…aaaaaa",
"timestamp": "2026-08-31T09:14:02.000Z",
"claimId": "0x7c2ee1a4…a1f4b9"
}
],
"scope": "local-ledger",
"note": "This reflects only claims recorded on this installation's local ledger..."
}

Dit is een fictief voorbeeld: de adressen, hashes en handtekening hierboven zijn verzonnen om het schema te tonen, niet afgeleid van een echte claim. Voor een echte, live claim zie het bewijs-blok in de Status-sectie hieronder. Het volledige schema staat in packages/capacity-attest/src/schema.ts .

record_delivery

De betalende agent roept dit aan ná een x402-afwikkeling. De server valideert eerst het schema, dan of claimId echt de hash van de inhoud is, en dan of signature terugrekent naar buyerAddress . Pas dan komt de claim op de append-only ledger.

get_delivery_history

Bij een sellerAddress : alle bekende, handtekening-geverifieerde claims tegen die verkoper, chronologisch. Puur feitelijk: geen gemiddelde, geen percentage, geen vertrouwensscore.

Pijler 2

Bewijs van controle, niet van veiligheid.

Een bedrijf dat een vreemde AI-agent binnenlaat heeft alleen de folder van de maker. Pijler 2 maakt daar een bonnetje van dat iedereen kan nakijken: de eigenaar bewijst eerst dat de endpoint van hem is, geeft toestemming, en wij leggen vast wat wij werkelijk aantroffen. Ondertekend, met een datum, en door iedereen na te lezen.

De eigenaar bewijst dat het van hem is

Hij zet een code in zijn DNS of als bestand op zijn eigen server. Daarmee toont hij aan dat hij de endpoint beheert, zoals een briefje in je brievenbus aantoont dat het jouw huis is.

Hij geeft toestemming

Zonder uitdrukkelijke toestemming raken wij een endpoint niet aan, en wij zetten nooit iemand op een lijst die er niet om gevraagd heeft.

Wij schrijven op wat we zagen

Geen cijfer en geen oordeel. Wat wij niet konden vaststellen heet onvaststelbaar, en dat staat er dan ook gewoon.

Wij zetten nooit het stempel veilig. Een test kan laten zien dat er iets mis is, maar nooit bewijzen dat er niets mis is.

Probeer het gratis Gratis en zonder account. De betaalde stempel staat bewust nog uit.

Hoe het werkt

Vier stappen, geen tussenpersoon.

Tokenizen verifieert zelf geen betalingen en wikkelt ze ook niet af, dat gebeurt al bij x402. Het grootboek registreert alleen de bon van een afwikkeling die al heeft plaatsgevonden.

01
Agent betaalt via x402

Een AI-agent koopt capaciteit (GPU-uren, opslag, API-credits, bandbreedte) bij een andere agent of dienst.
02
Koper tekent een claim

Na afwikkeling legt de betalende agent vast of het beloofde is aangekomen: ja / nee / gedeeltelijk, plus een hash van het bewijs.
03
Claim naar de ledger

record_delivery valideert schema, claimId en handtekening, en schrijft de claim append-only weg. Niet te wijzigen achteraf.
04
Volgende koper checkt eerst

Vóór hij zelf betaalt roept een agent get_delivery_history aan en ziet de ruwe leveringsgeschiedenis van die verkoper.

Ontwerpgrenzen

Bewust géén token, géén rente, géén lening.

Het is een bewuste, harde ontwerpgrens, en een strategische: het houdt Tokenizen buiten de zwaarst gereguleerde en meest gehypte hoek van crypto. De grens is expliciet ingebakken in het schema en de documentatie, niet weggemoffeld.

Wel: bouwen we

Verificatie van levering (delivered: yes/no/partial + evidence hash)
Append-only audit-trail, content-addressed, dus een latere wijziging valt op
MCP-tools om vóór betaling de geschiedenis van een verkoper te checken
Echte capaciteitshandel: GPU-uren, opslag, API-credits, bandbreedte

Met vangrail

Settlement is spot-only (direct afgewikkeld, nooit op krediet of termijn)
Credits zijn inwisselbare vouchers voor capaciteit, geen verhandelbaar instrument
Bewijsmateriaal wordt als hash opgeslagen, niet als data zelf

Nooit: vast uitgesloten

Geen eigen token of munt
Geen leningen
Geen rente op betalingen
Geen factoring / invoice-financing
Geen yield-producten

Open source & voor developers

De code is er. En nu ook op npm.

capacity-attest is een MCP-server, geschreven in TypeScript, met een testsuite. Het pakket staat live op npm en is geregistreerd in het officiële MCP-register als io.github.holistis/capacity-attest . Een agent kan de server direct aanroepen zonder eerst de repository te klonen.

MIT-licentie TypeScript Model Context Protocol live op npm installeren

npm install capacity-attest

npmjs.com/package/capacity-attest

Voor lokale ontwikkeling: kloon de repository, installeer, bouw, en draai de meegeleverde end-to-end demo, die een wegwerp-testwallet gebruikt en raakt geen live infrastructuur aan.

Repository op GitHub

lokale ontwikkeling

terminal

git clone https://github.com/holistis/tokenizen.git
cd tokenizen/packages/capacity-attest
npm install
npm run build # tsc -> dist/
npm test # vitest run
npm run demo # end-to-end lokale demo, TEST-sleutels, geen live infra

Status

Geen betalende klanten. Wel drie externe partijen die op het formaat bouwen, en werk dat anderen zelf hebben nagerekend.

Tokenizen is open source en in actieve ontwikkeling. Er zijn geen betalende klanten en geen samenwerkingen. Wat er wel is: drie partijen buiten dit project bouwen inmiddels op het claimformaat. Een van hen heeft onze verifier van de grond af opnieuw gebouwd in een andere taal en levert hem mee in zijn eigen pakket. Een ander noemt het measured-blok de bron van waarheid voor gemeten levering in zijn eigen conceptspecificatie, vastgepind op een commit van deze repo. Het volgende dat telt is de ondertekende testvectoren in een officiële conformance-set krijgen, zodat iedereen die later meedoet er langs moet.

Onafhankelijk geverifieerd

Onafhankelijke controles door andere mensen in plaats van door ons: een echte betaalclaim die een extern project op 1 september 2026 verifieerde, met hetzelfde claimId en dezelfde handtekening terugberekend naar de koper; een verifier die van de grond af in een andere taal is herbouwd; live leveringsclaims die iedereen kan uitlezen op drie losse chains; en een echte giveFeedback-aanroep op het ERC-8004 Reputation Registry op Base mainnet. Elke controle staat gelinkt vanuit de repository, zodat hij opnieuw na te rekenen is.

Bekijk de transactie Bekijk de verificatie

npm-publicatie

capacity-attest staat live op npm en in het MCP-register.

Eerste extern gebruik

Iemand buiten dit project die van capacity-attest afhangt zonder dat wij het voordoen. Drie partijen doen dat nu: een concept-ERC-8004-conventie die deze repo op commit-niveau vastpint, een onafhankelijk herbouwde verifier die meegeleverd wordt in andermans gepubliceerde pakket, en een BSV-rail-adapter op hetzelfde claimformaat van een losse auteur.

Onafhankelijke verificatie door andermans code

Een externe partij heeft de verifier van de grond af opnieuw gebouwd, alleen met de standaardbibliotheek, met een eigen implementatie van secp256k1, EIP-191 en canonieke JSON. Zeven van zeven vectoren komen overeen, inclusief beide negatieve controles, en het draait nu als permanente regressietest binnen zijn eigen gepubliceerde pakket.

Een externe agent die zelf record_delivery aanroept

Anderen verifiëren onze claims en hangen van het formaat af, maar we hebben nog geen bewijs van een agent van een andere partij die in productie een leveringsclaim via de MCP-tool wegschrijft. Tot we dat zien, blijft dit open.

Het formaat in een officiële conformance-set

Het measured-blok zit al in de eigen conformance-set van één partij, met vijf ondertekende vectoren en twee verifiers eromheen gebouwd. Op 14 oktober zei de auteur die de ERC-8004-vocabulaire voor grounded feedback schrijft dat die vijf vectoren ongewijzigd in de gedeelde conformance-set kunnen, naast fixtures van twee andere partijen. Dat is een toezegging van degene die het opschrijft, geen gepubliceerd besluit, dus dit blijft open tot de vectoren er echt in staan. Bekende grens: het grootboek is nog lokaal

npm install capacity-attest start standaard een lokaal grootboek per installatie (in te stellen via CAPACITY_ATTEST_DATA_DIR ). Twee onafhankelijke installaties zien elkaars claims nog niet automatisch via die standaardinstelling; dat blijft de volgende bouwstap. Wat er intussen wél is, en live geverifieerd op Base mainnet: claims publiceren en terugvinden via de Ethereum Attestation Service, én een echte giveFeedback() -koppeling met de ERC-8004 Reputation Registry, zodat het leveringsfeit ook zichtbaar wordt in het ERC-8004 Reputation Registry. Beide zijn geteste, opt-in bouwstenen: klaar om te gebruiken, nog niet automatisch actief tussen installaties.