tokenizen .nl NL EN GitHub
tokenizen.nl

open source

Open-source tools

Run them yourself, so you do not have to believe us.

The tools

  • capacity-attest

    After an x402 payment for capacity, the paying agent leaves a signed claim of what it says was delivered. A record, not a score and not a verdict.

    On npm

  • agent-receipt-verify

    Checks x402 endpoint conformance before an agent pays, and links the receipt to its settlement.

    On npm

  • x402-lint

    Checks an x402 seller's own payment-required (402) response against the real client-side schema.

    On npm

  • muraqib-agent-watch

    A free, instant capability check for an MCP server: it lists what its tools say they can do (money, files, outbound messages, destructive actions, credentials) and flags tools that do not state their own safeguard.

    On npm

The code on GitHub

What they are not

No score, no verdict and no token of our own.

The problem

Paying already happens by itself. Checking what you got does not.

An agent pays within a second for compute, storage or access to a service. If it got less than promised, that disappears the moment the session ends. Nothing is left for anyone to look at later. No complaint, no proof, no memory.

The buyer knows

They saw the output, or they didn't. But that knowledge is lost the moment the session ends.

The next buyer doesn't

They start blind with the same seller, with no history to check before they pay.

Usually no record of the claim

Without a signed record, there is nothing linking a promise to a claimed delivery, let alone anything the next buyer can verify.

Why now

Three developments converge this year.

In our own nine scans of August 2026 the pattern was the same: the buyer side of the agent economy gets all the attention. The seller side, and the object itself (the evidence), stays underexposed, exactly when regulation and payment rails are starting to call for it.

July 20, 2026

EU Digital Product Passport register live

The European Commission opened the DPP register; mandatory passports follow in phases per product category (batteries from Feb. 2027). This shows that a machine-readable, finance-free asset passport is becoming a real EU standard, not that it is already mandatory everywhere. regulation

EU AI Act, Article 14

High-risk AI systems must be demonstrably overseeable by humans. That calls for a verifiable record of what an autonomous agent did, exactly the kind of auditability Tokenizen addresses, without us making an Article 14 compliance claim ourselves. ongoing

x402 and Google AP2 leave one question open

Coinbase and Google built the payment and authorization rails. "What exactly am I buying, and is the seller allowed to deliver this?" remains unanswered.

Pillar 1: proof of delivery

A receipt of what was delivered. No score, no verdict.

Once an agent has paid, it records whether it got what was promised: yes, no, or partial. That receipt is signed, so a later change to it shows. Anyone who later wants to deal with that same seller can look up the history before paying.

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"
}
}
response 
{
"ok": true,
"claimId": "0x7c2ee1a4…a1f4b9"
}
MCP tool call → get_delivery_history 
{
"tool": "get_delivery_history",
"arguments": {
"sellerAddress": "0x9f1C1a3b…6e7F80"
}
}
response 
{
"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..."
}

This is a fictional example: the addresses, hashes, and signature above are made up to illustrate the schema, not derived from a real claim. For a real, live claim, see the proof block in the Status section below. The full schema is in packages/capacity-attest/src/schema.ts .

record_delivery

The paying agent calls this after an x402 settlement. The server first validates the schema, then whether claimId is really the hash of the content, and then whether signature recovers to buyerAddress . Only then does the claim land on the append-only ledger.

get_delivery_history

Given a sellerAddress : all known, signature-verified claims against that seller, chronologically. Purely factual: no average, no percentage, no trust score.

Pillar 2

Proof of inspection, not proof of safety.

A company letting a stranger's AI agent in has nothing but the vendor's own brochure. Pillar 2 turns that into a receipt anyone can check: the owner first proves the endpoint is theirs, gives permission, and we record what we actually found. Signed, dated, and readable by anyone.

The owner proves it is theirs

They publish a token in their DNS or as a file on their own server. That proves they control the endpoint, the same way a note in your letterbox proves the house is yours.

They give permission

We never touch an endpoint without explicit consent, and we never list one whose owner did not ask for it.

We write down what we saw

No score and no verdict. Whatever we could not establish is called inconclusive, and it says so.

We never stamp something safe. A test can show that something is wrong, but it can never prove that nothing is.

Try it, free Free, no account needed. The paid attestation is deliberately still switched off.

How it works

Four steps, no intermediary.

Tokenizen does not verify or settle payments itself, that already happens at x402. The ledger only records the receipt of a settlement that has already taken place.

  1. 01

    Agent pays via x402

    An AI agent buys capacity (GPU-hours, storage, API credits, bandwidth) from another agent or service.

  2. 02

    Buyer signs a claim

    After settlement, the paying agent records whether what was promised arrived: yes / no / partial, plus a hash of the evidence.

  3. 03

    Claim to the ledger

    record_delivery validates schema, claimId and signature, and writes the claim append-only. Not editable afterward.

  4. 04

    Next buyer checks first

    Before paying, an agent calls get_delivery_history and sees that seller's raw delivery history.

Design limits

Deliberately no token, no interest, no loans.

It is a deliberate, hard design boundary, and a strategic one: it keeps Tokenizen out of the most heavily regulated and most hyped corner of crypto. The boundary is explicitly built into the schema and the documentation, not glossed over.

Yes: we build
  • Verification of delivery (delivered: yes/no/partial + evidence hash)
  • Append-only audit trail, content-addressed, so a later change shows
  • MCP tools to check a seller's history before payment
  • Real capacity trading: GPU-hours, storage, API credits, bandwidth
With guardrail
  • Settlement is spot-only (settled immediately, never on credit or term)
  • Credits are redeemable vouchers for capacity, not a tradable instrument
  • Evidence is stored as a hash, not as the data itself
Never: hardcoded excluded
  • No native token or coin
  • No loans
  • No interest on payments
  • No factoring / invoice financing
  • No yield products

Open source & for developers

The code is there. And now on npm too.

capacity-attest is an MCP server, written in TypeScript, with a test suite. The package is live on npm and is registered in the official MCP registry as io.github.holistis/capacity-attest . An agent can call the server directly without first cloning the repository.

MIT license TypeScript Model Context Protocol live on npm install 
npm install capacity-attest

npmjs.com/package/capacity-attest

For local development: clone the repository, install, build, and run the included end-to-end demo, which uses a disposable test wallet and does not touch any live infrastructure.

Repository on GitHub

local development

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 local demo, TEST keys, no live infra

Status

No paying customers. Three outside parties building on the format, and work others checked themselves.

Tokenizen is open source and in active development. There are no paying customers and no partnerships. What does exist: three parties outside this project now build on the claim format. One of them rebuilt our verifier from scratch in another language and ships it inside their own package. Another cites the measured block as the source of truth for metered delivery in their own draft specification, pinned to a commit of this repo. The next thing that counts is getting the signed test vectors into an official conformance set, so that anyone joining later has to pass them.

Independently verified

Independent checks by other people rather than by us: a real payment claim verified by an external project on September 1, 2026, with the same claimId and the same signature recovered to the buyer; a verifier rebuilt from scratch in another language; live delivery claims readable by anyone on three separate chains; and a real giveFeedback call against the ERC-8004 Reputation Registry on Base mainnet. Each one is linked from the repository so it can be checked again.

View the transaction View the verification

npm publication

capacity-attest is live on npm and in the MCP registry.

First external use

Someone outside this project depending on capacity-attest without us demonstrating it first. Three parties now do: a draft ERC-8004 convention that pins this repo by commit hash, an independently rebuilt verifier shipped inside someone else's published package, and a BSV rail adapter built on the same claim format by a separate author.

Independent verification by someone else's code

An outside party rebuilt the verifier from scratch, standard library only, with its own secp256k1, EIP-191 and canonical JSON implementation. Seven of seven vectors match, including both negative controls, and it now runs as a permanent regression test inside their own published package.

An external agent calling record_delivery itself

Others verify our claims and depend on the format, but we have no evidence yet of an agent from another party writing a delivery claim through the MCP tool in production. Until we see it, this stays open.

The format in an official conformance set

The measured block already sits inside one party's own conformance set, which has five signed vectors and two verifiers built around it. On 14 October the author writing the ERC-8004 grounded-feedback vocabulary said those five vectors can go into the shared conformance set as-is, alongside fixtures from two other parties. That is a commitment from the person drafting it, not a published decision, so this stays open until the vectors are actually in the set. Known limit: the ledger is still local

npm install capacity-attest starts a local, per-installation ledger by default (configurable via CAPACITY_ATTEST_DATA_DIR ). Two independent installations don't automatically see each other's claims through that default; that's still the next build step. What already exists in the meantime, live-verified on Base mainnet: publishing and finding claims via the Ethereum Attestation Service, and a real giveFeedback() connection to the ERC-8004 Reputation Registry, so the delivery fact also becomes visible in the ERC-8004 Reputation Registry. Both are tested, opt-in building blocks: ready to use, not yet automatically active across installations.