给一个刚创建、还没开过任何资产的 Stellar 地址转币，直接支付多半会失败：收款方得先激活账户、为该资产建立信任线，才接得住。CAP-23 提出的两段式支付就是为这类场景准备的：付款先变成一个挂在账本上的”可领取余额”，等对方准备好再来认领。这类功能在 Solana 上有近亲（见 收款前先有一个”关联代币账户”：Solana ATA 为什么先建、租金谁出），机制却完全不同，别互相套经验。
提案与两种操作
CAP-23 的全称是 Two-Part Payments with ClaimableBalanceEntry，提案 2019 年 6 月创建、同年进入协议 14 的落地轨道，状态 Final。落地形态是一拆为二：源账户用 Create Claimable Balance 操作创建一个 ClaimableBalanceEntry 账本条目，里面写金额、一个或多个收款人（claimant）及各自的领取条件；被指定的账户之后用 Claim Claimable Balance 操作把资产认领到自己名下。创建成功返回一个余额 ID，领取时必须带上它——官方文档说明这个 ID 内含该创建操作的 OperationID 的 SHA-256 哈希。
领取条件（ClaimPredicate）是一棵可嵌套的条件树：UNCONDITIONAL 任何时间可领；BEFORE_RELATIVE_TIME(X) 和 BEFORE_ABSOLUTE_TIME(X) 分别限定在相对或绝对时间窗之前，后者的时间戳按 Unix 秒计；用 NOT、AND、OR 组合，就能表达”X 之后才能领""仅在 X 与 Y 之间可领”这类窗口。SDK 对时间参数一律按秒处理，写成毫秒是常见翻车点。
占用与回收
可领取余额是一条真实的账本条目，不是免费午餐：每个条目里的每个收款人都会给创建者的最低余额加一份基础储备（Stellar 的储备机制在 账户为什么要冻结 XLM：Stellar 的 base reserve 与拥堵费拍卖 拆过）。更关键的是，官方文档直言没人领的余额会永远躺在账本上占空间，因此建议创建者把自家账户也写成一个 claimant 作兜底——领取条件全部落空时，可以自己再把它领回来。文档同时点明：可领取余额总体上没有通用找回机制，谓词写死又不含兜底收款人的余额可能永远动弹不得。
发行方手里还有另一把钥匙：Clawback Claimable Balance 操作可以把尚未领取的可领取余额整体回收、退还发行方并销毁，注意只能整笔回收不能部分回收；已经被领走的资产，回到普通的 clawback 路径处理。
领取动作本身也有门槛：认领非原生资产前，claimant 必须已经为该资产建好信任线，否则领取操作直接报 op_no_trust。这解释了新手最迷惑的一幕——明明被指定了可领取余额，点领取却失败，差的往往是信任线而不是签名。这与 钱包突然要你填 Memo：Stellar SEP-29 是怎么在提交前查到的 里 memo 要求的前置检查类似：Stellar 把很多”收得下吗”的检查放在提交与领取的瞬间，而不是事后补偿。
与”未激活地址”相关的另一处细节
这套两段式支付常和 Stellar 的账户激活规矩一起出现：目标地址激活与最低余额（也就是 base reserve 相关规则，账户为什么要冻结 XLM：Stellar 的 base reserve 与拥堵费拍卖 拆过）没准备好时，普通支付直接失败；而可领取余额把”准备手续”推迟到了领取那一刻——收款人建信任线、激活、再认领，每一步的失败回话都不同，教程里混叫”到账失败”会误导排查方向。还有两点实操提醒：余额 ID 从创建操作派生，两笔”同金额、同对象”的交易 ID 也不会相同，对账问对方要创建交易的哈希，别只报”我转过一笔”；若谓词窗口全部耗尽又没留兜底收款人，官方文档的答复很干脆——没有通用找回机制，条目永远留在账本上，发行方一侧的 clawback 是例外通道而不是保证，主动权也不在收款人手里。
用户侧核对清单
付款方：确认对方是否已激活，未激活就选两段式并给自己留兜底收款人，别把领取窗口写成永远。收款方：钱包里出现待领取项时，核对余额 ID、金额、谓词时间窗是否与你拿到的承诺一致，再去建信任线、发起领取。对账时把链上条目存在、可领取、已被领取、钱包已展示当四种状态分开记录，任何”转了但对方没拿到”的问题，按这四层排查一遍再下结论。机制以官方文档与 CAP-23 原文 2026 年 10 月抓取版为准，本文不构成投资建议。
发表评论
还没有评论，来说两句吧。
评论区为展示样式，提交不会被处理。