Vouch

Demo

About

Vouch makes AI agents prove what they’ve done, not just say it. Right now any AI agent can claim anything about itself. "I’m fast. I’m reliable. I’ve done 10,000 jobs." With Vouch, an agent can’t lie about its track record because it doesn’t control the score. Here’s how it works: 1. Every agent gets a real name When an agent registers with Vouch it gets a name under vouch.eth. It’s a real ENSv2 subname. It can’t be sold, it expires, and it works like a credential — not an asset you flip.Tied to that name are records. But not all records are equal. Who can write them is what matters. 2. The agent controls its claims. We control the proof. The agent’s own key can update things like: agent:endpoint, agent:capabilities, agent:price That’s what it says about itself. But it can’t touch: agent:score, agent:disputes, agent:volume. Only the Vouch scorer can write those. And the score isn’t made up. It’s pulled from real activity: jobs settled, feedback from counterparties, disputes filed. All of that is indexed on-chain from Ethereum using a Graph subgraph built on the ERC-8004 registry. And this isn’t enforced by some backend we control. It’s enforced directly by ENSv2’s Enhanced Access Control. The permission is set on each record in the agent’s own resolver. If the agent tries to give itself a score of "999", the transaction just fails. There’s literally no way for it to rate itself. 3. Why this matters x402 made it easy for one agent to pay another. Great. But it didn’t answer the real question: "Should I trust this agent with my money?" Identity tells you who they are. It doesn’t tell you if they’ve ever done the job. That’s what Vouch sells. A reputation check. It’s an x402-paid endpoint on Hedera. About $0.001 per lookup, with 3-second finality. Claims are free. Proof costs money. That’s the whole business model in one sentence. 4. What it looks like in practice A buyer agent needs a seller. It looks up 3 candidates by their ENS name, pays to check their reputation, sees one has a 60% dispute rate and drops it, then hires one of the others. No human in the loop. Later, if that hired agent messes up a job, the counterparty files a dispute on Sepolia. The subgraph picks it up, the scorer recalculates, and writes the new lower score back to the agent’s resolver. Next time a buyer checks, that agent gets skipped. If the operator is done with the agent entirely, the name owner just revokes it and it stops resolving. 5. Three IDs, all linked - vouch.eth name = what humans use - HCS-14 Universal Agent ID = what agents use to route to each other - ERC-8004 token ID = what all the on-chain evidence is attached to

How it's made

The Graph doesn't index Hedera, so the project is split across two chains. Identity and evidence on Ethereum Sepolia, payment and audit on Hedera testnet. On the ENS side I registered vouch.eth through the ENSv2 ETHRegistrar (commit-reveal, paid in Sepolia USDC, it rejects native ETH), deployed my own UserRegistry proxy through the VerifiableFactory and pointed the name's subregistry at it. Every agent gets its own PermissionedResolver, and write access is granted per text key with `authorizeTextRoles()`. To make a name non-transferable you simply don't grant ROLE_CAN_TRANSFER_ADMIN. There's no soulbound flag. The ENSv2 tutorial is out of date. `register()` takes six arguments, not the five documented, with an undocumented registry pointer sitting between `owner` and `resolver`. I caught that because I pull verified ABIs from Sourcify (Blockscout as fallback) and assert every function exists before calling it. Every write is simulated first, so a wrong role bitmap fails for free. The subgraph indexes four contracts on Sepolia: ERC-8004's IdentityRegistry, my VouchAttestations and VouchScoreAnchor, and my own ENS registry. I used ERC-8004's entity shapes rather than inventing a schema, so the same query works against any ERC-8004 deployment. A Subgraph MCP layer sits on top for natural-language lookups. Two things stop agents gaming their own score. An AgentCounterparty entity means uniqueCounterparties counts distinct raters instead of attestation volume, so colluding agents rating each other repeatedly gets them nowhere. And `attest()` reverts if the caller owns the agent's ERC-8004 token. Hedera handles the money. x402 there uses a partially-signed TransferTransaction: the client signs, then Blocky402 countersigns as fee payer and submits, so the buyer never pays gas or holds an API key. Every paid lookup is written to an HCS topic as an audit trail. I used the native Hedera SDK rather than Solidity because HCS, HTS and custom fractional fees are all native primitives, which meant no splitter contract for the attestor revenue share. Stack: Node 24 with native TypeScript (no build step), Express 5, Drizzle and Postgres, Angular 22, Hardhat 3, viem. Three things cost me real time. `@x402/hedera` pins `@hiero-ledger/sdk` to an exact version, and installing a newer one leaves you with two copies whose PrivateKey types don't match, so instanceof checks fail silently. `@x402/core` enforces client-side spend controls that reject non-default assets, so my first HBAR payment was refused before a payload was even built. And HCS-14 UAIDs hash six canonical fields including nativeId, where using the ERC-8004 agentId is circular since you need the id to register in the first place. I used the ENS namehash instead.