Stellar 上的 NFT 有两条路：经典资产与 SEP-0050 草稿

一条路不写合约，一条路必须写合约

Stellar 的原生资产系统（SAC）是为同质化资产设计的。SEP-0050 的提案文本很坦白：技术上可以通过发行不可分割、带唯一元数据的资产（文中指向 SEP-39 描述的资产元数据规范）来做 NFT，但这条路对开发者不直观，而且有两个结构性缺陷——一枚 NFT 就要发一种资产，会很啰嗦；如果改成“一个资产代表一个合集”，那合集内部的成员就变回可互换的了， fungibility 直接不成立。

于是就有了第二条路：在 Soroban 智能合约里实现一套名为 SEP-0050 的非同质化代币接口，接口形状接近 ERC-721，但按 Stellar 的机制做了调整，例如授权不是无限期挂着的 allowance，而是带 live_until_ledger——授权在指定账本序号后自动失效。提案文本里还专门讨论了 safeTransfer 与 onReceive：因为 NFT 不可分割，没法像代币那样“先转一小笔试试水”，所以给合约转账前要有一个接收能力检查环节。

草稿就是草稿

SEP-0050 文档头部写得很清楚：Status 是 Draft，创建于 2025 年 3 月 10 日，版本 0.1.0。这和“某个链上已经有权威标准”的距离必须说清楚：草稿意味着接口可能改动、实现之间可能不一致、工具生态未必统一适配。看到“Stellar NFT 标准”这种说法时，先看状态字段，再看有多少项目实际按同一版本实现。

反过来，走经典资产路线的“NFT”具备资产系统的原生性质（余额、信任线、冻结这些操作都在协议层），但不一定具备 SEP-0050 描述的合约接口，两套东西不能互相假设。

授权到期与账本序号：一个具体的差异

在 ERC 语境里，一笔授权要么撤销要么一直有效。Stellar 的合约设计里，approve 要传一个账本序号，超过这个序号授权自动失效；approve_for_all 同理，传 live_until_ledger 为 0 表示撤销。账本序号是 Stellar 的区块计数，会比你预估的“几天”走得更快或更慢，取决于网络出块情况——设定过期时，宁可保守一些。

提案文本另外指出，Stellar 的内置签名机制在协议层就能提供类似 permit 的效果，这一点被拿来解释为什么某些以太坊侧为省 gas 而加的设计在这里没有必要照搬。

三条常见误区

第一，把“我发行了一种不可分割资产”当成 NFT 的全部要件——同一个资产标识下的多个单位仍是可互换的，唯一性要靠资产种类本身的数量来保证。第二，把 SEP-0050 当已定稿标准接入，草稿阶段应锁定具体版本并做兼容性测试，工具方也不应假设所有合约都实现全部方法。第三，忽略 Stellar 侧的收款前提：在经典资产场景里，接收方需要先有信任线，否则转账与认领流程都会失败；这也是官方文档里反复提醒 claimable balance（可认领余额）存在价值的原因之一。

一句话总结

Stellar 上的 NFT 现状是“两套模型并存、合约接口仍在草稿阶段”。判断一枚具体藏品的性质，要依次问：它走的是资产系统还是合约？合约声明按哪个版本的 SEP 实现？授权到期怎么设？这三个问题都答得上来，才谈得上后续的价格、流动性与版权讨论。

换到读者视角

对普通收藏者，Stellar 上的 NFT 更像一份“半成品标准”下的商品：资产层的规则（信任线、冻结、回收）足够硬，合约层的规则还在草稿里流动。这未必是坏事——结构清晰的两条路，总比一条含糊的路好判断。你真正要养成的习惯是：拿到一枚藏品，先问它是“资产”还是“合约”，再看它声明的标准版本，最后才轮到价格与热度话题。顺序对了，绝大多数“标准之争”的问题在起点就不存在。

风险提示：本文只解释技术机制与操作边界，不构成投资建议，也不推荐任何项目或平台。链上规则可能随版本升级变化，判断以官方规范文本与链上实际代码为准。