预言机该回价格还是回数量：ERC-7726 通用报价接口的取舍

合约想问“我的 X 值多少 Y”，最流行的答案是查一个价格乘回去。ERC-7726 偏不：它要求合规合约用“明确的代币数量”代替“价格系数”，宣称这样安全与落地效果更好。这份标准把自己定义为提供资产相对价值数据源的标准 API，文件头记录创建于 2024 年 6 月 20 日，仓库记录状态为 Draft，声明依赖 ERC-7528。

单函数接口与三条硬规则

接口只有一个视图函数 getQuote(uint256 baseAmount, address base, address quote)，返回一个 uint256 的 quoteAmount。语义是：这么多数量的基础资产，值多少个报价资产。规范写了两条行为约束，都用 MUST：计算必须向零向下取整；若结果会超出 uint256 表示范围，必须 revert。注意标准没规定错误码、精度、时效或任何数据质量参数——它只规定“怎么问”，把“答得好不好”整个留给各数据源自己发布说明。

术语部分把三个词钉死：base 是你要估值的那笔资产，quote 是用来计价的资产，value 是一段资产数量而非小数系数。比如“1000 元面额的某美元币值多少 ETH”，答案必须是一串 wei 量级的 ETH 数量，不是一位小数价格。

为什么故意不做 getPrice

取舍部分回答得坦率：链上很少真的需要价格本身——价格是个小数，在 EVM 里难表示；想要“一个整单位值多少”的调用方，可以对ERC-20 资产自己算 getQuote(10**base.decimals(), base, quote)，自然得到整单位报价。把除法挪到调用方手里，标准里就不必养一个固定小数位的假约定。这个设计也把小数处理的责任交还给消费方：getQuote 不要求消费方知道 base 或 quote 内部定义过什么小数分区，直接进直接出。

没有地址的资产怎么办

接口参数是地址，但 ETH、BTC、法币都没有合约地址。规范的特别地址一节给了约定：ETH 用 ERC-7528 定义的 0xEeee…EeEe 那串；BTC 用 0xbBbB…BbBb；没有地址但有 ISO 4217 代码的法币，直接把代码写进地址里，比如美元是 address(840)。这三条约定值得单独记：跨数据源比较时，同一份标准对 ETH 的地址写法可能不同，接口兼容不代表语义一致，读别人的调用前先确认对方用的是哪种“特别地址”版本。

三条容易被误读的规则

第一条是取整方向：规范用 MUST 写明计算必须向零向下取整。这条对小数量兑换很要命——用 getQuote 换回的数量总是小于或等于理论值，永远不会因为四舍五入多给你零头，集成方按“精确值”写等式断言就会偶发失败。第二条是溢出即失败：规范要求结果超出 uint256 表示范围时必须 revert，而不是回绕或截断，所以一个把大额基础资产直接丢进去的调用路径，可能只是因为溢出而整笔回滚，看错误时先排查数量级而不是价格源。第三条是接口不管小数：标准明确说使用 getQuote 不要求消费方了解 base 或 quote 定义过的小数分区，进出都是最小单位量级的整数——把小数换算责任留在调用方，同时也就把“算错小数点”的风险留在了调用方。

使用层面的现实提醒

数据源标准最怕被误读成“数据可信”。安全考量部分写得非常直白：本标准有意不提供任何让消费方评估数据有效性的方法，各实现必须自己公布数据质量承诺与停止供数的条件，消费方应审阅这些承诺再决定是否接入。翻译成尽调动作：接入一个自称 ERC-7726 的预言机前，先回答三件事——它的 getQuote 背后喂的是什么价源、极端行情下它是否承认可能回退或拒绝服务、它的特别地址写法是否与本集成一致。

对 NFT 场景，这类报价接口常被用来把地板价、抵押率、清算阈值折算成 ETH 或稳定币展示。同一份 getQuote 数字，在不同的实现里可能来自单一交易所现货、多源加权、或者带延迟的聚合；接口层面看全都是一行函数，差别全在标准管不到的那一半。仓库状态 Draft 也提醒你，它当前更像一份正在讨论的接口图纸，看到生产协议引用时，先查它绑定的具体数据源合约，而不是编号本身。本文为机制说明，不构成任何投资建议。