Why AI Agent Reputation Data Belongs on IPFS, Not a Database

AI agent reputation data has a specific structural problem ERC-8004 was designed around: the score itself is cheap to store on-chain, but the evidence behind that score, work samples, detailed feedback, validator reports, isn't. That evidence has to live somewhere off-chain, referenced by a hash. Where it actually lives changes what that hash-reference is worth. This covers why IPFS is the right answer for that specific job, and why a private database quietly breaks the one property the hash reference exists to provide.

TL;DR:

• ERC-8004's Reputation Registry stores a 0-100 score on-chain, with richer evidence referenced off-chain via feedbackURI and an optional feedbackHash
• A hash reference only means something if the referenced content can't silently change, that's a content-addressing property, not something a private database provides
• If evidence sits behind a database, the operator can edit or delete it without the on-chain hash ever reflecting the change
• Pinning that evidence to IPFS gives the hash reference something it can actually verify against

The Piece ERC-8004 Doesn't Store On-Chain

The Reputation Registry keeps its on-chain footprint small on purpose: a numeric score, up to two tags, and revocation status. That's cheap to write and cheap to query. What it doesn't store on-chain is the substance behind a rating, the actual work product, a detailed review, evidence a validator checked. That gets referenced through an optional feedbackURI field, with a feedbackHash alongside it for integrity checking. The design assumes something is holding real content at that URI, durably enough and verifiably enough that the hash reference still means something a year later.

What a Hash Reference Actually Promises

A feedbackHash is only useful if you can fetch the content at feedbackURI and confirm the hash still matches. That's the entire value of including it. If the content behind that URI can change without the hash changing along with it, in other words if the URI points at something mutable, the hash stops proving anything. This is exactly the property content addressing provides and a conventional database doesn't: an IPFS CID is derived from the content itself, so the address and the fingerprint are inseparable. A database row has a stable ID and mutable content behind it, the opposite arrangement.

Where a Private Database Quietly Breaks This

Point feedbackURI at a company's own API endpoint instead of a CID, and the hash-verification property depends entirely on that company's continued honesty and continued existence. They could edit the record. They could take the API down. They could get acquired and lose the data in a migration. None of that would be visible on-chain, the hash field would sit there unchanged while what it's supposed to verify quietly stops being verifiable. This isn't a hypothetical failure mode specific to bad actors, it's just what "mutable storage behind a stable reference" means by default, regardless of anyone's intentions.

The Honest Version of This Argument

This isn't a claim that IPFS is inherently more reliable than a well-run database, a company with good backups can keep data available just as long as anyone pinning to IPFS can. The actual difference is what each one lets you verify independently. A database can tell you "this is still the same record" only if you trust the operator to say so honestly. A CID lets you check that yourself, recompute the hash locally and compare, no trust required. For reputation data specifically, where the entire point is letting a stranger evaluate an agent without pre-existing trust, that's not a minor technical preference, it's the actual mechanism the whole system depends on.

What a Mismatch Actually Looks Like in Practice

Concretely, checking a feedbackHash looks like this: fetch whatever is currently sitting at feedbackURI, hash it locally, and compare the result to the feedbackHash value stored on-chain. If they match, the evidence you're looking at is provably the same evidence the score was originally attached to. If they don't match, one of two things happened, either the content changed since the feedback was recorded, or the URI never pointed at genuinely fixed content in the first place, and either way, that's a real, actionable signal that the evidence behind this particular score shouldn't be trusted at face value. This is the same recompute-and-compare workflow already covered for NFT metadata, just applied to reputation evidence instead of artwork, and it's only possible at all because the reference is a CID rather than a URL a server could quietly repoint.

Where AIOZ Pin Fits

Pinning reputation evidence is the same operation already covered for NFT metadata and ERC-8004 registration files: pin the evidence file with pinFilesToIPFS() or pinByHash() if you already have a CID, reference the result as feedbackURI, and if a validator or another agent needs to check that evidence frequently, AIOZ Pin's Premium Gateways serve it without the rate limits a public gateway would eventually impose.

This Is the Same Pattern as NFT Metadata, One Level Up

Readers of this blog's NFT coverage will recognize the shape of this argument, because it's structurally identical to why NFT metadata belongs on IPFS rather than a centralized server: a permanent on-chain reference is only as trustworthy as the thing it points at, and a mutable server breaks that trust silently while a content-addressed one makes it verifiable. What changes for agent reputation specifically isn't the mechanism, it's the stakes. An NFT's metadata being altered is primarily a concern for the token's current or future owner. An AI agent's reputation evidence being alterable undermines the entire premise ERC-8004 exists to solve, letting a stranger evaluate an agent's trustworthiness without pre-existing trust in either the agent or whoever's hosting its record.

Frequently Asked Questions

What does ERC-8004's Reputation Registry actually store on-chain? A numeric score (0-100), up to two tags, and revocation status. Detailed evidence is referenced off-chain through an optional feedbackURI field.

Why does the location of reputation evidence matter if there's already a hash? The hash only proves something if the referenced content can't change without the hash changing too. A database record can be edited silently; a CID can't be, since the address is derived from the content itself.

Is a database actually less reliable than IPFS for storing this data? Not necessarily, a well-run database can be just as durable. The real difference is verifiability: a CID lets anyone independently confirm content hasn't changed, a database requires trusting the operator's word.

How do I pin reputation evidence for an ERC-8004 agent? The same way as any other file with AIOZ Pin, pinFilesToIPFS() for a new file or pinByHash() if you already have a CID, then reference the result in the feedbackURI field.

Does this same reasoning apply to the Validation Registry too? Yes. responseURI and responseHash follow the identical pattern, on-chain score plus a hash-verifiable off-chain reference, for the same reason.

Related Reading

• What Is ERC-8004? The AI Agent Trust Standard, Explained - the full Reputation and Validation Registry specification this argument is built on
• Content Addressing for NFTs: How to Verify a CID Yourself - the exact verification mechanism that makes a hash reference meaningful
• How to Pin an ERC-8004 Registration File on AIOZ Pin - the same pinning workflow applied to reputation evidence

References

• ERC-8004: Trustless Agents (official EIP)
• Content Identifiers (CIDs), IPFS Docs