ERC-8004 grounded feedback: ratings that carry their receipt

The short answer

Zambo's own agent sits in this registry as agentId 107529 in the Identity Registry on Base, and every job it runs leaves a receipt. This page is about the other side of that pairing: what a client does with a receipt after the work, so the feedback they file can be believed by people who were not there.

The hole: 0.14 percent of ratings follow a payment

On October 14, 2026, the Agentic Finance Graph published its measurement of the Base Reputation Registry, taken that morning at 10:50 UTC, with the full dataset released as an open CSV fixture under CC BY 4.0 so anyone can re-run the counts. The method was a join: every feedback entry in the registry, matched against the stablecoin payments the project indexes, asking one question: did the rater pay the rated agent's wallet before rating it?

• Feedback entries on Base: 514,096
• From a rater who had paid the rated agent first: 728, that is 0.14 percent
• Raters behind those 728: 17
• Agents rated: 64
• Payment transactions behind them: 107
• Of those payments, x402 settlements: 3
• Median payment: $0.03

The authors are careful about their own number, and the care matters. Payments to a separate x402 payTo address and payments on other chains sit outside the join, so 728 is a lower bound. Even taken as a floor, the picture does not change: ratings and payments are almost separate worlds, and a reader deciding whether to hire an agent is reading scores that, 99.86 percent of the time, cannot be tied to a transaction at all.

And the grounded sliver has a second weakness, which the same analysis names plainly. Most of the 728 grounding payments are plain USDC transfers. A transfer proves two addresses transacted. It does not prove the rating is about that transaction, and it says nothing about what the job produced. Closing the hole takes more than a payment reference. It takes a reference, carried inside the feedback, to the record of the work itself. That is the receipt's job.

What a feedback entry actually is

Under the ERC-8004 proposal (a Draft EIP, titled Trustless Agents), any client address posts feedback to the Reputation Registry, on Base at 0x8004BAa17C55a88189AE136b182e5fdA19dE9b63, by calling:

giveFeedback(uint256 agentId, int128 value, uint8 valueDecimals,
  string tag1, string tag2, string endpoint,
  string feedbackURI, bytes32 feedbackHash)

The value is a fixed-point number whose meaning the tags define: a starred tag makes it a quality score out of 100, other tags carry uptime, success rate, response time, and similar signals. The value and the tags are stored in the registry. The endpoint, feedbackURI, and feedbackHash are emitted with the NewFeedback event. Only the value and its decimals are required; everything else is optional, which is exactly why so many entries carry nothing.

The feedbackURI points to a feedback file, a JSON document with the details behind the score. The proposal's own file structure includes a proofOfPayment block with the paying address, the receiving address, the chain id, and the payment transaction hash, designed for x402 proof of payment, and it leaves room for further fields the rater chooses to add. Where the URI is not content-addressed, the feedbackHash is the keccak256 hash of the file's content, so the file a reader opens later can be checked against the hash posted with the rating. One rule shapes everything on this page: the feedback submitter must not be the agent owner or an approved operator for that agentId. Feedback comes from clients, or it is not feedback.

How an AER-1 receipt grounds an entry, step by step

1. The client hires and pays. The job starts with a real transaction: an x402 settlement in USDC on Base, a Day Pass purchase, a Pass subscription. The payment transaction hash is the first half of the grounding. It names the payer, the payee, and the amount, in a public transaction record both sides can point to and anyone can re-read.
2. The work runs and leaves a receipt. Work run through Zambo leaves a verifiable AER-1 receipt for the job, saved when the work ran: the canonical bytes of the call, the SHA-256 hash of what it returned, and a public page for the receipt at zambo.dev/run/{receipt id}. The receipt is the second half of the grounding, and the half a bare payment can never supply: what the job actually was and what it produced.
3. Anyone checks the receipt before trusting it. The receipt's public verification endpoint recomputes the checks in the open: the SHA-256 commitment against the canonical bytes, the canonical payload reconstruction, the provenance and metadata bindings, and the checks that were not run, stated as not checked rather than passed over in silence. The same check is free for a person at zambo.dev/verify.
4. The client files the feedback. The client writes a feedback file naming the agent registry and agentId, their score and tags, the proofOfPayment block with the payment transaction hash from step 1, and the receipt URL from step 2. They hash the file with keccak256 and call giveFeedback with the file's URI as feedbackURI and that hash as feedbackHash.
5. A reader re-walks the whole chain. Open the feedback file and confirm its hash matches the one posted with the rating. Open the payment transaction and confirm the rater paid the agent. Open the receipt and confirm its checks pass. At that point the rating is no longer an opinion floating free: it is a score tied to a payment and to a saved, checkable record of the work it judges. That is grounded feedback.

Worked example: a real receipt, mapped into a feedback file

Take a real delivery record. Cairnworks, an independent verification service, wired AER-1 receipts into its standing-check deliveries in October 2026, and one of those deliveries is public: receipt 28c79cde-20a0-48a3-b4ec-e5d0e3ac104d. Its verification endpoint reports verified: the receipt's canonical bytes are 2,078 bytes, and recomputing their SHA-256 gives 5f06acfbe2ff6254f7bd3a494ef9848551a0946a305d82c4ac9da410a07dd2a5, exactly the output hash the receipt commits to. That recompute was run independently for this page, from the live record, and it matched. The same record states its limits in plain language: issuer authentication is listed as not checked, and the delivery's own claims audit is preserved in the record with its gaps flagged.

Now map that receipt into the feedback file a client would post after a job like it. The structure below follows the proposal's feedback file format; the receipt fields are the real values from the live record above, and the payment and score fields are shown as the slots the paying client fills from their own transaction:

{
  "agentRegistry": "eip155:8453:0x8004A169FB4a3325136EB29fA0ceB6D2e539a432",
  "agentId": 107529,
  "clientAddress": "eip155:8453:{client wallet that paid}",
  "createdAt": "{rating time, ISO 8601}",
  "value": 100,
  "valueDecimals": 0,
  "tag1": "starred",
  "endpoint": "https://zambo.dev/mcp",
  "proofOfPayment": {
    "fromAddress": "{client wallet}",
    "toAddress": "{agent wallet}",
    "chainId": "8453",
    "txHash": "{payment transaction hash}"
  },
  "aer1Receipt": {
    "receiptId": "28c79cde-20a0-48a3-b4ec-e5d0e3ac104d",
    "receiptURI": "https://zambo.dev/run/28c79cde-20a0-48a3-b4ec-e5d0e3ac104d",
    "verifyURI": "https://zambo.dev/verify",
    "outputHash": "sha256:5f06acfbe2ff6254f7bd3a494ef9848551a0946a305d82c4ac9da410a07dd2a5",
    "verificationStatus": "verified"
  }
}

Posted with the keccak256 hash of this file as the feedbackHash, an entry like this gives a reader three independent things to open: the registry record itself, the payment transaction, and a receipt whose own checks they can re-run. Compare that with the typical entry in the 514,096: a number, stored next to an agentId, standing on nothing. The registry did not change between the two. The rater did the grounding work, and the agent made it possible by leaving a receipt for the job in the first place.

Note whose hand is on the pen in this example. The client files it, from the wallet that paid, because the specification bars the agent's owner and operators from rating their own agent. Zambo's part in grounded feedback is the part it can honestly play: do work that leaves a checkable receipt every time, so that any client who wants to ground a rating has something real to point at. The Validation Registry page covers the companion pattern, where a named checker examines a job and posts the score.

Putting it to work

1. If you run an agent: register its identity first (the live walkthrough), then make its work leave receipts. Work run through Zambo's 153 tools leaves a verifiable AER-1 receipt per job automatically. A client cannot ground a rating in a job that left no record.
2. If you hire agents: keep the payment transaction hash and the receipt URL from every job. When you rate the agent, file the feedback file with both inside it and post its hash. Your rating becomes one of the few a future reader can actually audit.
3. If you read reputation: filter for entries whose feedback file carries a payment reference and a receipt, and re-check both before the score moves you. The registry's read functions let you pull feedback by client address, which is the filter the proposal itself recommends against noise.

None of this costs the reader anything: registry reads and receipt checks are free. On the work side, the free tier covers a normal day of receipted work, a $0.99 Day Pass covers a heavy day, and the $29 per month Pass ($19 per month for $ZAMBO holders, $290 for the year) is there for agents that work daily. Reputation told the world what people say about your agent. Grounded feedback shows them the payment and the work: run a job and check its receipt.