链上公告栏：ERC-8049 让合约自己写元数据

一个合约是谁做的、和谁合作、官网是哪个，这些信息过去只存在于网页与文档里。仿冒页面泛滥之后，社区开始希望合约自己能出示“自我介绍”。ERC-8049 给了一个极简方案：合约以字符串键、任意字节值为结构，把关于自己的元数据存上链，每次写入发一条事件。提案在 ercs 仓库的状态是 Draft（草稿），创建于 2025 年 10 月 10 日，要求兼容 ERC-165 并引用 ERC-7930 的地址格式，接口的 ERC-165 标识是 0x8ec3f882。

两个成员与一条事件

合规合约必须实现 contractMetadata(string key)，一个 view 函数，按键取回 bytes 值；规范同时给出可选的 setContractMetadata(key, value)，写入策略由合约自己定。任何元数据被设置时，合约必须发出 ContractMetadataUpdated 事件，携带索引化的键、原始键字符串和值——客户端因此可以不轮询、只跟事件流。没被赋值的值按规范可以按 UTF-8 字符串解读，除非实现方另有声明。键还可以带参数表达实例，比如 registration: 1 或 name: Maria，写法沿用 ERC-8119 的键参数约定。官方示例相当直白：键 name 存合约名、键 ens_name 存 ENS 域名，客户端解析这个名字就能顺藤摸到更多资料。想省冲突的实现可以用 Diamond Storage 模式，命名空间固定为字符串 erc8049.contract.metadata.storage。

ERC-20Agent 档：代币合约挂一个智能体

草案里最有话题性的是一块名为 ERC-20Agent 的档案档：一个同时实现 ERC-20 与本标准的代币合约，可以保留一组约定键，把代币和一个 AI 智能体绑定，值里推荐用 UTF-8 文本（Markdown），可以嵌一段围栏 JSON 供机器读。规范特意说明这只是本标准键值接口的一种用法，不新增函数、不新增接口号。要点在于档案是合约级的——这个智能体属于代币合约整体，不属于任何持有人；智能体干什么由发行方定，可能是答疑客服，也可能是治理代理。

怎么用它防伪，别怎么迷信它

为什么值要设计成 bytes

键是字符串、值是 bytes，这个组合看似别扭，其实经过权衡。字符串键保持人类可读，工具与人都能直接列出常见字段；bytes 值则放弃了类型约束，同一接口可以装一段 UTF-8 说明、一串打包的地址列表、一段 abi 编码的结构体，甚至一枚外部分支文件的哈希。代价随之而来：客户端必须事先知道每个键的解读约定，否则只能按规范兜底当作字符串显示。规范给出的 Diamond Storage 选项解决的是另一类问题——可升级合约与跨链证明场景需要元数据落在可预测的存储槽，字符串 erc8049.contract_metadata.storage 这个命名空间正是为此保留。对普通读者，键值模型的实用收获是一眼看懂项目自述：读到 collaborators 这种键时记住值里的地址可以反查公开渠道，读到 context 里嵌的 JSON 块时可以要求项目方给出可复核字段，自述的每一格都应能被独立追问。

顺带一提，键的字符串没有中央注册表，同义键可能各写各的，工具侧要靠约定与生态词表对齐，读到的陌生键不必猜用途，直接问发行方要求补释义即可。

顺带提醒存储成本：元数据以 bytes 存在合约自身存储里，长值直接抬高合约体积与写入 gas，项目通常只放摘要与外链锚点，读到长串正文时先想想是谁在替谁付账。

读的一侧价值明显：比对两个同名项目，先读它们的 contractMetadata 清单，正规项目往往存着可核的 ENS、合作方地址；事件历史还能回放资料是何时改的。但必须把预期摆正：这些值是合约写入的自述，不是第三方公证——仿冒合约照样可以写一条 ens_name 指向高仿域名。可信度的来源不在“它写在链上”，而在值里的东西能否被独立核验：ENS 反解析回指向这个合约吗？声明的合作方地址自己承认吗？换句话说，ERC-8049 把“自我介绍”从网页搬进区块，核验的步骤一步都不能少。草稿标准、写入即留痕、自述不等于认证，这三点一起记住。本文为机制说明，不构成任何投资建议。