AI agents are starting to hold wallets, take jobs and rate each other. ERC-8004 gives them an onchain identity and a public place to collect feedback. But when I looked at the real data on Monad testnet, I found a problem: the registry can tell you what people said about an agent, but not whether you should trust it.
So I built AgentCredit: a Qwen 3.8 Max agent that investigates an ERC-8004 agent, works out a trust score from the raw feedback, and can write its verdict onchain with a hash of its evidence. It was built for the Monad hackathon (Trust, Identity & AI Infrastructure track) and the Alibaba Cloud Best Builds with Qwen 3.8 Max bounty. Live demo: https://agentcredit-six.vercel.app Code: https://github.com/Abbagigo13/agentcredit Contract on Monad testnet: 0x0b0792a328c2253e4F23f98875ebb7DEEa859971
: the Trust Checker result for agent 10, with the reasoning steps and the score breakdown]
ERC-8004's Reputation Registry lets anyone leave feedback for an agent: a number, plus tags saying what it is. There's no standard for what the number means. I scanned the first 100 registered agents on Monad testnet and looked at what the feedback really contains: Agent #9 (ScavBot) has a registry summary of 1439. Its feedback is Elo ratings, which aren't a 0-100 score at all. Agents #10 and #20 both show a summary of 0. But #10's feedback is 33 wins and 9 losses, and #20's is 2 wins and 21 losses. One is a decent performer and the other is a disaster, and the summary number hides it. The registry appears to average values that are +1 for a win and -1 for a loss, then round, so both land on 0. Agent #1 had a summary of 52. In reality it had passed only 2 of 8 validation checks, and one friendly quality rating of 90 had pulled the blended average up.
If you build a trust layer on top of that summary, you approve the wrong agents. So the job isn't "ask an AI for a number". The job is to read the individual entries, work out what each one means, and refuse to score what can't be interpreted.
Here is the flow for a question like "Can I let agent 10 do a task that needs a trust score of at least 70?": Qwen 3.8 Max plans and calls tools. It confirms the agent exists, reads and classifies all of its feedback, computes the score, checks it against your threshold, and optionally records the verdict onchain. A contract on Monad stores the verdict together with a coverage figure and an evidence hash. Anyone can verify the record, and any app or contract can gate an action on it with one call.
The analyst is a function-calling loop on qwen3.8-max, using Alibaba Cloud's OpenAI-compatible endpoint. Qwen has five tools:
| Tool | What it does | | --- | --- | | getagentidentity | Reads the agent's ERC-8004 identity from the Identity Registry | | getfeedbackbreakdown | Reads every feedback entry and sorts it into win/loss outcomes, pass/fail checks, percentage ratings and off-scale values | | computetrustscore | Scores the agent, applying minimum-evidence rules | | checkthreshold | Compares the score with your requirement | | recordonchain | Writes the verdict to the AgentCredit contract |
The loop itself is short. The model asks for tools, my code runs them and returns the results, and the model decides what to do next, until it answers without asking for another tool:
A real run takes four or five model rounds and 25 to 45 seconds. The website streams every tool call to the page as it happens, so you can watch the agent work instead of staring at a spinner.
[Screenshot: the verdict card with the "Recorded onchain" box and the transaction link]
This was the most important design decision. computetrustscore takes only an agent ID. It derives every input from the verified feedback breakdown on its own, and recordonchain recomputes the score again before writing. Qwen never types a score. A model that hallucinated a number would have no way to put it onchain.
So what does Qwen actually do? It decides which tool to call and in what order, reads the results, stops when a tool says the evidence is too thin, and writes the verdict and the explanation. For agent #1, for example, it noticed on its own that the score came from "real failure data, not an absence of data", and that a single 90% rating "carries no weight because it does not clear the minimum-evidence bar". That kind of explanation is what makes the verdict usable by a person.
In my first version, the score was built from the registry's summary number. When I asked about agent #16, which has exactly one rating of 85 from a single client, Qwen answered APPROVE (with caution). It hedged well in its wording, but it still approved an agent on the strength of one review, and a single wallet could create that.
Telling the model to be careful isn't a safeguard. So I moved the rules into the tools, where the model can't argue with them: A signal needs at least 3 feedback entries, and the agent needs feedback from at least 2 different clients. Feedback on a non-percentage scale, like Elo, is ignored. If nothing usable is left, the tool returns no score and the analyst must answer INSUFFICIENTDATA.
After that, agent #16 ends as INSUFFICIENT_DATA, and ScavBot's Elo history is ignored with an explanation instead of being scored as a perfect 100. The model's judgment still matters for how it explains and what it recommends, but the line between "enough evidence" and "not enough" is code.
| Agent | Evidence | Score | Coverage | Verdict | | --- | --- | ---: | ---: | --- | | #1 Monad Demo Agent | 2 of 8 validation checks passed | 25 | 25% | Reject | | #10 | 33 wins, 9 losses from 5 clients | 79 | 40% | Approve, low confidence | | #20 Veridex Oracle Agent | 2 wins, 21 losses from 4 clients | 9 | 40% | Reject | | #9 ScavBot | Elo ratings only | none | 0% | Insufficient data | | #16 | one rating from one client | none | n/a | Insufficient data |
The score is a weighted average of five signals (task success 40%, validation 25%, reputation 20%, reliability 10%, recency 5%). Only the signals that have enough evidence are used, with the weights rescaled, and a coverage figure tells you how much of the model the evidence supports. Agent #10's 79 rests on one signal, so the analyst correctly calls its confidence low and recommends a supervised trial for anything high-stakes.