很多钱包在往某些 Stellar 账户转账时，会在最后一步弹出一句“这个收款方需要 memo”，然后把提交按钮按住。这个提示不是钱包猜的，也不是交易所通过接口回给你的，而是钱包在链上读到了账户自己挂的一条声明。承载这条声明的规范是 SEP-29，全名 Account Memo Requirements，状态 Active，版本 0.5.0，起草于 2019 年 12 月 27 日，最后一次更新记在 2020 年 5 月 4 日。
它要治的是什么病
托管钱包经常用同一个 Stellar 账户收所有人的存款和提款，靠交易上的 memo 字段分辨这笔钱归谁。用户偏偏经常忘记填 memo，而处理漏填可能牵扯到资金丢失，还需要托管方的客服做人工操作。SEP-29 的解法很朴素：把“我这个账户需要 memo”这件事写成账户级别的公开声明，让付款方的软件在提交之前自己去查。
声明怎么写、检查怎么做
账户所有者提交一笔交易，用 MANAGE_DATA 操作加一条数据项，名字是 config.memo_required，值为字符串 1（单字符，ASCII 码 49，Unicode 码位 U+0031），名字按 SEP-18 的记法全部小写。发送方这边的义务是：当交易里含有 PAYMENT、PATH_PAYMENT_STRICT_SEND、PATH_PAYMENT_STRICT_RECEIVE 或 MERGE_ACCOUNT 操作，而目标账户又不是多路复用账户时，先加载目标账户的细节，看它是否挂了这条数据项；挂了，就核实交易的 memo 字段是否已填，没填就提示用户并阻止这笔交易提交；如果一笔交易包含多个操作，同样的检查要对每个操作各做一遍。
它是约定，不是共识规则
最需要划清的一条边界：SEP-29 不改变底层协议，链本身不会因为 memo 缺失而拒收这笔付款。检查发生在客户端提交之前，规范在理由部分也写得很直白，把 memo 要求写成挂在账户上的数据项，是在不改动协议的前提下实现这套约束；更完整的方案是 CAP-27 的一等公民多路复用账户，但整个生态和托管交易所全面接受它需要更多时间和开发投入，这也是 SEP-29 存在的现实原因。由此推出的后果很实际：一个不认识这条约定的旧钱包、脚本或交易所系统，仍然可以把不带 memo 的钱打到一个声明了需要 memo 的账户上，钱会落进那个公共账户，之后回到人工核对与认领的老路上。
它管“有没有”，不管“对不对”
规范有意不去校验 memo 的类型和内容，实现细节被留给未来更细的规范条目（原文举例了 config.memo_required_type 这类数据项的可能性）。SEP-29 只回答“这个收款方要求带 memo 吗”，不回答“你填的这串字符是它期望的格式和值吗”。这就是为什么钱包弹了提示、你随手敲了个 1 提交成功，钱照样可能进不了你在交易所的账户：格式与值的正确性来自对方的充值页面，而不是链上声明。核对顺序仍然是链上转账前必查清单：网络选择、最小单位与 Memo 注意事项里那套，memo 与地址两个字段都要逐字符比对。
哪些情况下你查不到、也不该查
多路复用账户是规范明确列出的豁免对象，这类账户的形式由 CAP-27 定义，走的是另一套机制。另外要提醒的是，声明本身只是账户持有者愿意公开的一个标记：任何人都能给自己账户加这条数据项，它既不能证明对方是交易所，也不能证明对方的记账系统真的可靠。反过来说，没挂这条数据项也不代表对方一定不需要 memo，有些服务靠其他约定分辨归属。所以别把钱包没弹提示当成免检章。
出错了怎么处置
如果你是在提交前被拦住，那只是钱包替你避免了后续的麻烦，去对方页面重新复制带 memo 的完整充值要求即可。如果钱已经带着空 memo 落了地，处置顺序和一般的漏填问题一致：先确认链上交易确实成功、拿到交易哈希，再按地址没错，钱却卡在半路：Memo/Deposit ID 机制与充错自查里的思路准备证据，按交易所充值未到账自查：哈希、确认数与 memo 的三步核对那种“哈希、确认、memo”三步结构向对方提交认领申请，别在没留证据的情况下反复重转。各家钱包与 SDK 对这条约定的支持程度以现网版本为准，官方实现清单在原文里列了 Go、JavaScript、Java 与 Python 客户端库的对应发布说明，本文写作时未逐一复测这些库的最新行为。本文只做机制与防御说明，不构成投资建议。
发表评论
还没有评论，来说两句吧。
评论区为展示样式，提交不会被处理。