ERC-7412 按需取数：合约先报错，链下数据再随交易一起送达

Layer2、Layer3 越拆越多之后，一个合约想读另一条链上的价格或状态，传统做法要等预言机把数据持续推到每条链，成本高且永远有滞后。ERC-7412 提供了另一条路：数据不常驻，用到才取。2026 年 9 月 9 日在 ethereum/ERCs 仓库核对，该提案状态为 Draft。

用报错当请求

机制的起点是一个反直觉的设计：合约在模拟执行阶段直接回退，抛出 OracleDataRequired(oracleContract, oracleQuery, feeRequired) 错误。错误里写清三样东西——哪个预言机合约能核验所需数据（oracleContract 必须实现含 oracleId 与 fulfillOracleQuery 的接口）、要什么数据（oracleQuery 可以包含链号、合约地址、函数签名、载荷或行情代号加时间戳）、以及需要多少手续费（feeRequired 以 wei 计，客户端补足后错误必须消失，多付的部分可以不退）。支持该标准的钱包或客户端在模拟时认出这个错误，去指定的去中心化预言机网络取回签名数据，再把核验交易与目标调用拼成一次 multicall：先把签好的数据写进链上供合约读取，紧跟着执行原操作，整包原子提交。

与 ERC-3668 的分工差异

提案正文把自己与 ERC-3668 做了对照：后者同样用回退触发链下读取，但依赖回调函数路径，在复杂场景里遇到种种限制；ERC-7412 改用 multicall 预置数据的方式绕开这些约束。对账户抽象钱包来说，4337 体系本就支持原子多操作，接入更自然；EOA 场景则可能需要借助 ERC-2771 那类转发方案，而且规范提醒：通用 multicall 合约只能拼装不依赖 msg.sender 与 msg.data 的函数，否则发送者语义会错位。

用户视角的意义与风险

和推送式喂价的成本对比

传统预言机要保证某条链上任何时刻都能读到最新价格，就得持续把数据写进每条链，空闲时段的更新费也照付。按需检索把这笔常驻成本换成两笔偶发成本：向预言机网络支付的一次性数据费，以及把核验交易拼进目标调用产生的增量 Gas。价格波动剧烈、调用频繁的协议未必划算；调用稀疏、分布在小众 Layer2 上的功能则是明显受益者。用户在界面上感知到的差别，通常只是提交交易前多了一次“获取数据”的等待，以及明细里多一行预言机服务费。若模拟阶段直接报 OracleDataRequired 而钱包不支持该标准，操作会原样失败——这不是资产问题，是工具链缺口，换支持该流程的钱包或手动按错误提示补数据即可。

数据格式与预言机标识

oracleQuery 的内部格式完全由 oracleContract 声明的 oracleId 决定，标准刻意不做统一：跨链读会带链号、合约地址、函数选择器与载荷，行情读可能只有代号与时间戳。客户端因此不能自作聪明地“猜格式”，而是按 ERC-165 思路先认 oracleId，再走该预言机注册的 SDK。fulfillOracleQuery 是 payable 的，规范同时要求核验成功、失败都应可观测，避免“收了费不写数据”成为静默黑洞。这些细节决定了一个钱包能否做成通用集成，还是只能逐预言机写适配。

时间戳字段的读法

查询载荷里带时间戳时，数据有效性由预言机签名时刻决定，而非交易入块时刻；两者间隔越久，快照越旧。界面展示时应把两个时间并排放，避免用旧快照成交后误以为是实时价格。

对普通持有人，这套机制最可能出现在“跨链看版价”“按别链状态决定能不能赎回”这类功能背后。值得注意的边界有三条：其一，按需取到的是“取数那一刻”的快照，价格类数据的时效永远取决于查询时点，不能当成连续喂价用；其二，feeRequired 是数据服务费，Gas 之外会叠加在成本里，操作前值得确认金额；其三，整包交易原子执行，数据核验失败则全单回退，这反而比“先取数再执行”的两段式更安全。提案尚未定稿，接入它以仓库正文和具体预言机文档为准。本文为协议机制科普，不构成任何投资建议；标准状态以 ethereum/ERCs 仓库文本为准（核验时间 2026 年 9 月 9 日）。