ERC-7893 偿付能力证明接口：DeFi 协议的资产负债表怎么变成可查询合约

储备证明年年被提起，但各家格式互不相通：有的发博客，有的发链上快照，字段口径全凭自述。ERC-7893（DeFi Protocol Solvency Proof Mechanism）试图把这件事变成一份合约接口——资产、负债、偿付率、历史曲线全部标准化为链上可查询数据。按以太坊 ercs 仓库的记录，这份提案状态为 Final，创建于 2025 年 1 月 30 日。

四组函数构成一条流水线

标准的 ISolvencyProof 接口可以按职责分四组。录入组是 updateAssets 与 updateLiabilities：由授权预言机调用，把协议持有的每项资产与负债（代币地址、数量、以 18 位小数 ETH 计价的值）写进合约状态，并强制两组数组长度一致、记录更新时间戳——所有数值统一用 ETH 计价，是刻意消除各币各报口径的混乱。计算组是 calculateRatio 与 verifySolvency：偿付率的公式在标准里写死为总资产除以总负债再乘以一万，也就是 100% 对应数值一万；标准同时给了最低偿付率 105% 的风险阈值配置。查询组最丰富，getSolvencyRatio、getProtocolAssets、getProtocolLiabilities、getSolvencyHistory、getHistoricalDataInfo 让仪表盘免 Gas 拉取当前值和时间区间内的历史序列；标准允许实现在合理保留期（例如一年）后清理旧数据，但必须在文档里写明保留策略。风控组是应急机制：emergencyPause 与 emergencyUnpause 配合 getEmergencyStatus 控制熔断状态，_checkCircuitBreaker 在关键写入前检查熔断，safeLiquidation 给出安全清算入口，setOracle 换预言机时发 OracleUpdated 事件。

三类事件各有读者

每次指标更新发 SolvencyMetricsUpdated，这是仪表盘和索引器的主数据流；跌破配置的风险阈值时发 RiskAlert，这是给监控机器人和告警系统的信号；预言机变更发 OracleUpdated。标准还专门提醒事件发射要做防刷设计，防止有人高频触发更新用事件淹没日志——换句话说，读这个合约时，事件流的节奏本身就是信息。

证明的支点从合约转移到了预言机

仪表盘之外：普通用户的一次自查

把标准接口落到一次真实自查上。第一步读 getSolvencyRatio，注意返回值是万分比：一万零五百对应的就是标准建议的 105% 最低线，界面若把它显示成”10500%“属于换算事故。第二步读 getProtocolAssets，逐条核对数组里的代币地址：真正代表用户储备的，应当是你可以在对应链上独立验证的 ERC-20 或原生资产，出现来历不明的包装代币地址时，资产质量的判断就要打折扣——储备依赖某个第三方封装币，等于偿付证明的可信度外包给了封装方。第三步调 getSolvencyHistory 拉一段区间，健康的曲线应当随市场起伏而连续，长期纹丝不动的数值往往意味着预言机没有真实更新，可以再用 getHistoricalDataInfo 对照时间戳密度。第四步查 OracleUpdated 事件历史，看数据源最近一次更换是何时、被谁批准。整套动作不需要任何许可，这正是把偿付能力做成合约接口相对做成月度 PDF 的实质差别：数据从”发布物”变成了”可查询状态”，质疑的成本从写信催更降到了两次调用。

这里必须讲清这套机制的边界：合约忠实执行公式，但公式的输入来自 updateAssets 与 updateLiabilities 的调用方。标准用权限控制要求只有授权预言机可以写入，于是全部信任都压到了预言机的身份与能力上。两个现实问题无法靠接口解决：一是资产盘点——协议在多个链、多个合约里的头寸要靠预言机自己扫得全、报得实，链上可验证的是”谁在什么时间报了这些数”，不是”世界上确实只有这些钱”；二是负债界定——用户未提取份额算不算负债、未到期义务怎么折算，属于协议自己的会计政策，接口只要求它写进结构体。判断一个 7893 实现的质量，看三样东西：setOracle 历史里预言机换过谁、RiskAlert 是否真接了自动化处置、以及资产数组里每项能否映射回可独立核实的链上合约。本文为机制说明，不构成任何投资建议。