ERC-900：把“谁在这家协议锁了多少”写成九个函数

质押这件事，产品页面各有各的说法，但落到合约层面，一个地址在某份质押合约里锁了多少、总量多少、用的是哪枚代币，本来就是可查询的数据。ERC-900 在 2018 年 2 月 22 日就想把这些查询统一成一份接口。按 ercs 仓库记录，这份名为 Simple Staking Interface 的提案状态为 Stagnant，是这份清单里资历最老的之一，当年被 Aragon 应用、Polygon 早期质押合约等实现引用过。

两个事件加七个必选函数

接口以一个 Staking 合约展开。动作侧三个函数：stake 从调用者账户划转指定数量的代币进合约，stakeFor 允许调用者替别人质押、代币仍从调用者处划走，unstake 取回代币、当前不可取时必须让交易失败。三个函数都带一个自由的 data 字节参数，原文解释是在复杂质押系统里携带信令信息；三者都必须触发对应事件，事件里同时记录用户、本次金额、该用户累计总额和 data。查询侧四个函数：totalStakedFor 查某个地址的质押量，totalStaked 查全场合计，token 回答这份质押合约用的是哪枚代币合约，supportsHistory 告诉外界历史查询功能开没开。

可选的历史三件套

标准留了三个可选函数：lastStakedFor 返回某地址最近一次质押所在区块，totalStakedForAt 和 totalStakedAt 按区块号回看任意时点的质押量。因为不是所有质押系统需要完整历史，标准把决定权交给实现方，但要求 supportsHistory 必须诚实——这三个函数实现了才许返回 true。这个“能力自报”的小机关和 ERC-165 的接口探测精神一致：与其让工具猜，不如让合约自己说。

它为什么停摆，又为什么眼熟

这份接口没有任何关于收益、罚没、解锁期的规定——它刻意只覆盖“锁仓账本”这一层，原文的动机段提到，统一接口能让代币策展注册表这类应用直接复用质押数据。它最终没有成为主流，原因也大体清楚：后来的质押形态越来越复杂，委托、流动性凭证、再质押都超出了“把币锁进合约”的简单图景，一份不含收益与惩罚语义的接口显得太薄。但把今天的质押面板逐项对上你会发现，锁仓、赎回、总量、按地址查询、所用代币这几个原语，仍和九个函数一一对应。读停摆提案的正确姿势就在这里：不是可惜它没赢，而是借它看清任何质押产品都必须回答的最小问题集。普通用户拿到一份陌生质押合约，用这份老接口当提问单——谁在为谁锁了多少、现在能不能取、历史可不可查——比看宣传页上的年化数字踏实得多。

拿九个函数核对一家质押产品

把这份 2018 年的接口当成体检单用，能立刻落地成一串操作。在区块浏览器里找到质押合约，先看 token() 返回的地址是不是官方代币合约，谨防同名仿冒币；再查 totalStaked() 与页面宣传的锁仓规模是否同一口径，注意事件法累计与状态读取的差异；用 totalStakedFor 抽几个大户地址，看看集中度是否高到少数地址即可左右规则；确认 supportsHistory 返回什么，再决定历史数据的可信度；最后用 unstake 的权限与解锁条款补上接口不问的部分——这份接口完全不涉及能否即时取出、有无罚没、谁有权暂停，那些写在条款页面而不是这份标准里。九函数是骨架，条款是血肉，两家产品可以共享同一副骨架却给出完全不同的风险画像，这正是标准与产品之间的距离。

再补一条接口之外的常识：质押合约的授权要求通常比转账复杂——多数实现要求你先对代币合约发起 approve，质押合约才能划走币，这份 2018 年的接口对 approve 保持沉默，因为它默认 ERC-20 的既有流程。清理授权时对质押合约留的额度常被遗忘，成为长期的攻击面；每次赎回离场后顺手复核并撤销授权，与查询质押总量同样属于九函数之外必修的动作。

本文为机制说明，不构成任何投资建议。