8004 Jan update - 6 changes based on testnet learnings from
@marco_derossi @DavideCrapis :
1. Dropped feedbackAuth signatures
The v0.4 design required agents to sign authorization structs before clients could submit feedback. In practice this created too much friction - every feedback submission needed a round-trip to get a signature first.
New approach: feedback is permissionless. Anyone can give feedback to any agent. Spam mitigation moves to the aggregation layer - filter by trusted reviewers, weight by payment proofs, etc. The on-chain registry just stores signals.
2. agentWallet verification
Previously agentWallet was just another metadata field. Now it's a first-class verified attribute with its own setter:
setAgentWallet(agentId, newWallet, deadline, signature)
The agent must prove ownership of the wallet address via EIP-712 (EOA) or ERC-1271 (smart contract). This matters because agentWallet answers "where should payments go" - x402 integrations, escrow contracts, and payment rails need cryptographic assurance they're sending funds to the right place.
When an agent NFT transfers, agentWallet resets to zero. New owner must re-verify.
3. On-chain registration file
The spec now supports storing the entire registration JSON on-chain via base64 data URI:
data:application/json;base64,eyJ0eXBlIjoi...
For agents that want full censorship resistance without IPFS dependencies. Gas-intensive but available when you need it.
4. Endpoint field in feedback
Feedback now includes an optional endpoint parameter:
giveFeedback(agentId, score, tag1, tag2, endpoint, feedbackURI, feedbackHash)
This lets clients specify which endpoint they interacted with. An agent might expose MCP, A2A, and REST APIs - now reputation can be tracked per-endpoint. Aggregators can answer "how reliable is this agent's MCP server specifically?"
5. Optional endpoint domain verification
Agents can prove they control an endpoint domain by publishing:
https://{domain}/.well-known/agent-registration.json
The file must contain a registrations array matching the on-chain agentId. Verifiers check: (1) file is reachable over HTTPS, (2) registration matches chain data.
Optional but useful for establishing that the agent actually controls the domains it advertises.
6. Human endpoints: web and email
The endpoint list now explicitly supports human-facing channels:
json
"endpoints": [
{"name": "web", "endpoint": "https://agent.example/"},
{"name": "email", "endpoint": "support@agent.example"},
{"name": "A2A", "endpoint": "https://..."},
{"name": "MCP", "endpoint": "https://..."}
]
Agents aren't just for agent-to-agent communication. Many will have human customers who want a website or support email. The registration file now captures the full surface area.