
📚 A Mechanism to Certify Agent Identity and Reputation with NFTs ✅ Overview ERC8004 v1.0 is a common set of rules that enables autonomous software agents to safely collaborate across organizations. It uses Ethereum as a "trust foundation" to record agent identities, reputations, and work verification results in an immutable manner. The design has significantly changed from v0.4 and has evolved into a more practical system based on real-world usage. ✅ Agent Identity Management (Identity Registry) The mechanism for proving an agent's "who they are" has transitioned from a custom format to ERC721 (a standard NFT specification). Each agent is registered as a single NFT, and its tokenURI contains registration information in JSON format. This includes communication methods (such as connection endpoints for protocols like A2A or MCP), public keys, and corresponding trust models. As a result, agent identities can be managed through wallets, and in a way compatible with NFT infrastructure, anyone can verify "who is the agent at this address." ✅ Reputation Mechanism (Reputation Registry) Evaluations of an agent's work are directly stored on-chain as scores. Before sending an evaluation, the client receives signed permission data from the agent. This is verified using EIP191 (standard wallet signing method) or ERC1271 (smart contract wallet signing method), preventing impersonation and replay attacks (attacks that reuse past signatures). Since scores and tags (classification labels) can be directly referenced from the smart contract, other dApps can use them as materials to automatically determine "whether this agent is trustworthy." ✅ Work Verification (Validation Registry) This is a mechanism for third parties to verify whether the results produced by an agent are correct. In v1.0, instead of a single hash, evidence is presented via a URI (a reference to external data), allowing multiple stages of verification results to be registered for the same request. For example, a structure can be built where trust levels are incrementally increased through stages such as a quick check, detailed verification, and external audit. Currently, the specification is being finalized in collaboration with the TEE (Trusted Execution Environment, secure execution environment) community. ✅ Security and Gas Costs To address attack methods discovered during testnet operations, signature verification and storage design have been strengthened. As a result, writing evaluations and verifications will cost more in gas fees, but the benefit is that trust data can be directly used on-chain. The cost is significantly reduced on L2 networks. ✅ Migration from v0.4 v1.0 is not backward compatible and has completely changed the storage structure. Therefore, all previous registration information and reputations are reset, and agents must re-register as NFTs, and the evaluation system must adapt to the new signing method. Going forward, the design will use a "namespaced upgrade method," allowing specification updates without deleting data, and this large-scale reset is expected to be a one-time event.
