在绝大多数链上收发资产，要先有一个”替你放资产的子合约”，而 TON 把这件事反了过来：它的账户本身就是合约，一个还没有部署任何代码的地址也有确定的坐标。TON 改进提案 TEP-89 要解决的正是由此引出的一个小问题——资产主控合约能不能亲口告诉你，某个地址对应的那只资产钱包在哪里。这份 2022 年 9 月提出、当前状态为 Active 的接口规范，篇幅很短，但把 TON 编程模型里”地址可以先于合约存在”这一层讲得很清楚。
先看协议结构。TEP-89 要求符合它的新版 Jetton 主控合约实现一个名为 provide_wallet_address 的链上处理入口。发给它的消息带三段内容：query_id 用来把请求和响配对上；owner_address 是你要查询的持有人地址；include_address 是一个布尔开关，决定回复里要不要把持有人地址也带回来。这条消息的算子标识写作 2c76b973，是协议文本对整个消息签名串做 CRC32 得到的校验值，钱包和合约都靠它辨认消息类型。
主控合约收到请求后，必须以模式 64 回一条 take_wallet_address 消息（算子 d1735400），字段里带上算出来的钱包合约地址；当请求里 include_address 为真时，回复还要在 owner_address 字段回带请求中的持有人地址。这个回带设计是为核对留的：接收方能确认这份答案答的就是自己问过的那个人，而不是被中间消息张冠李戴。如果因为工作链不匹配等原因根本算不出钱包地址，回复里的 wallet_address 字段必须填 addr_none，而不是直接抛异常——这让调用方至少能区分”算不出”和”没回应”。
费用门槛是这份提案里最容易踩的一段。规范写明，请求附带的 TON 必须高于 5000 gas 单位加上转发消息的 lump_price 与 cell_price 之和，按提案文本里当时的基础链参数换算约为 0.0061 TON；带少了，主控合约连发出回复的成本都不够，查询会安静地没有任何回音。这个下限同时带来一个提案自己也承认的缺陷：单看行为，你无法区分一个收费异常高的发现合约和一个压根没实现该接口的合约，排查时要把费率与回复内容一起看。
存量资产怎么办也是规范明确处理过的。已经上线且主控不可升级的 Jetton，可以另外部署一只独立的 Jetton Discovery 合约来补齐这套查询接口，让”主控合约加发现合约”这一对的行为与新版主控一致；对于元数据可以改的旧主控，规范建议在元数据里加一个 wallet-discovery 键，值写成那只发现合约地址的文本形式。也就是说，做索引和市场集成的程序要同时走两条路：先问主控、问不到再找发现合约，否则老资产会被系统性漏掉。
对普通使用者，这套机制改变的是收款体验中最费解的一环。过去从一个新项目收款，钱包往往要先执行一笔”部署资产钱包”的交易并为此付一笔手续费；如果对方平台只是凭推导给你一个地址，你无法确认真伪。有了 TEP-89 之后，任何钱包或浏览器都可以在链上向主控合约发一次 provide_wallet_address 查询，拿回确定性答案，再对照平台显示的地址。核对时至少做三件事：确认查询的主控合约地址就是官方公布的那只合约；确认回复里带回的 owner_address 等于你输入的持有人地址；确认 wallet_address 不是 addr_none。
需要留意的边界还有两处。其一，地址推导的确定性来自具体合约的实现约定，不同资产项目之间不能交叉套用，一条推导规则只对它服务的那只主控合约成立。其二，这份接口本身不携带任何权限语义，它能回答”钱包在哪”，不能回答”钱包是否已准备好接收”或”这笔资产是否合法”，把地址查询当成资产验证来用是概念错位。真正判断资产归属，仍然要看资产钱包合约自己的持有权记录。
对开发者，提案还提醒了一种依赖风险：如果所有新应用都只走新版主控这条路、不再兼容旧的发现合约配对，那么遇到存量资产就会处理不了。集成时把两种形态都写进兼容层，并对查询超时与低回复率设置监控，是这份短规范隐含的工程要求。
本文为机制说明，不构成任何投资建议。
发表评论
还没有评论，来说两句吧。
评论区为展示样式，提交不会被处理。