Stellar 的 CAP-23 把一笔付款拆成创建与领取两步，收款方不必提前准备好信任线。本文按官方文档拆 ClaimableBalanceEntry 的两种操作、领取条件谓词、余额 ID 的来源、占用与回收，以及未到期与回收的边界。

Stellar 锚点用 SEP-24 协议让法币出入金在钱包内完成：JWT 认证、交互式网页、状态机与回调各有规矩。本文按官方协议文本梳理流程、状态含义与排错点。

Stellar 生态标准 SEP-7 定义了 web+stellar 链接格式，让不持密钥的网页把签名请求委托给用户信任的钱包。本文按 2.1.0 版拆解 tx 与 pay 两种操作的参数、callback 与 replace 机制，以及钱包必须先验 origin_domain 与 signature 再显示的合规要求——没签名的请求为什么要按红旗处理。

Stellar 的 SEP-10 用一笔序列号为零的“挑战交易”完成签名登录。本文拆解它的返回结构、十五分钟时间窗、服务器核对清单与签名字段各自的职责。

SEP-8 为受监管资产定义了钱包与审批服务之间的对话：先本地签名，把交易交给审批服务，拿回带发行方签名的交易再提交。本文拆解两种检测入口、success 与 revised 与 pending 与 action_required 与 rejected 五种回话，以及 revised 时用户重签前必须看什么。

SEP-29 让账户所有者用一条 MANAGE_DATA 数据项声明“给我付款必须带 memo”，让发送方在提交前检查。本文按原文拆解 config.memo_required 的写法、四类被检查的操作、多路复用账户的豁免，以及为什么它只是客户端约定、漏填时链上仍然会发生什么。

Stellar 的协议版本是账本头里的 ledgerVersion，一次协议变更就加一，不需要约定停机区块高度。变更本身是共识议题：节点在提名阶段把看不懂、与自己预设不一致或时间未到点的升级项从投票里丢掉，法定集合投了无效值就整轮弃权；升级在交易集之后才应用，可改的对象包括基础费、交易集上限、最低保留额、协议版本与一组配置升级集。本文按 stellar-core 版本机制文档拆解投票顺序、失败回退与兼容性层次。

Stellar 生态对 NFT 有两种做法：用经典资产发不可分割资产，或在 Soroban 合约里实现 SEP-0050 定义的 NFT 接口。SEP-0050 目前状态是草稿，授权以账本序号到期。本文解释两条路的差异、各自限制，以及为什么“有接口”不等于“有共识标准”。