收款不等于发行 Stablecoin：大多数应用真正缺少什么

最近开始有人问我：GENIUS Act 已经成为美国法律，stablecoin 的规则比过去清楚了，ArcBlock 为什么不发行自己的 stablecoin？如果 ArcBlock 希望帮助应用处理支付，这不是一条很自然的路吗？

我的答案很直接：收款不等于发行 stablecoin，支付也不等于运营一项业务。

Stablecoin 可以是一种很好的 payment 和 settlement asset。支付网关可以接受、传递并结算这种付款，就像它处理信用卡或银行付款一样。但用户完成付款之后，一项数字服务真正复杂的工作才刚刚开始：他买到了什么、可以使用多少、怎样计量、什么时候续费、失败的付款怎样处理、余额怎样展示、退款怎样执行、多方怎样分账、发生争议时怎样对账。

这就是为什么 ArcBlock 关注的不只是 payment rail。借用电信行业 BSS/OSS 的思路，我们希望帮助应用建立一套数字化、可组合、必要时可以验证的 billing and operations support system：连接产品、价格、订单、支付、服务额度、用量、订阅、账单、support 和 reconciliation。Payment 是入口，不是整个运营体系。

这篇文章讨论的是产品与系统设计，不是对 stablecoin 或 Credit Token 的法律定性，也不是法律或投资建议。具体产品在不同地区如何处理，仍然需要根据它提供的真实权利、资金流和运营方式判断。

Stablecoin 的发行、支付的接受与业务运营是三个系统

现实世界里，一个超市、酒店、工厂或软件公司会接受美元，用美元标价、记账和结算。它们不需要为了完成这些工作，各自发行一种“自己的美元”。接受和使用一种货币，与承担发行这种货币的责任，是完全不同的业务。

数字支付也是如此。企业可以通过 Stripe 接受信用卡或银行支付，也可以在合适的网络、法律与集成条件下接受链上资产。ABT、ETH，以及 USDC、USDT 这类 stablecoin，是不同类别的行业例子；它们并不因此具有相同的法律性质、结算保证或风险。选择一种 payment asset，回答的是“用户用什么把价值交给商家”；选择支付处理方式，回答的是“这笔价值怎样被授权、转移、确认和结算”。这两个问题都很重要，但都没有回答“商家怎样持续交付和运营服务”。

以一个 AI 应用为例。用户充值 100 美元，只说明一笔付款已经成功。系统仍然要决定这笔钱对应多少 credit，不同模型、API call、图片生成、GPU 时间和存储空间怎样扣费；一次失败的任务要不要收费；团队中的不同成员怎样共享额度；低余额怎样提醒或自动充值；月底如何让用户看懂账单；客服怎样追溯一笔有争议的扣费。

因此，至少要分清三个层次：

Stablecoin 可能位于第一层，payment gateway 主要连接第二层；应用每天真正运行在第三层。

发行一种 stablecoin，不会自动得到后两层。接入一个 stablecoin，也不会自动得到完整的 billing。反过来，一套好的运营系统也不应该被某一种支付资产锁住。今天用户用信用卡，明天用银行转账，另一位用户用 ABT 或某种合规 stablecoin，应用内部的产品、额度、用量和对账规则仍然应该保持一致。

GENIUS Act 在 2025 年 7 月 18 日成为美国法律。它把 payment stablecoin 定义为用于支付或结算、由发行方承诺按固定金额兑换、赎回或回购，并让持有人合理预期其相对固定货币价值保持稳定的 digital asset。法律写入了 permitted issuer、至少 1 的合格储备、赎回政策与费用披露、月度储备披露与核验，并要求监管机构继续制定资本、流动性、运营、合规和信息技术风险管理等标准。^[1]

“已经成为法律”也不等于全部制度已经生效。法案规定的生效日，是签署后 18 个月，或主要联邦监管机构发布最终实施规则后 120 天，以较早者为准。本文写作时，相关机构仍在推进 proposed rules 和实施细节。^[2] 因此这里讨论的是法律确立的方向与责任边界，不是假设所有执行规则已经落定。

我认为，这项法律带来的一个重要 clarity，是让企业更容易看清自己究竟需不需要成为 issuer。真正希望运营一种公共 payment and settlement asset，并愿意持续承担储备、赎回、流动性、披露和合规责任的机构，可以把 stablecoin issuance 当作自己的核心业务。仅仅希望向客户收款的应用，大多没有这个必要。

“Stablecoin 现在有了法律框架”不能推导出“每家企业都应该发行 stablecoin”。它更像是在告诉市场：发行这类 payment asset 是一项具体、严肃、持续的业务。清晰的规则让真正需要做的人知道怎样做；其他企业仍可以在适用法律、网络和支付集成允许的范围内选择现有支付资产。

ArcBlock 要解决的是付款之后发生的事

ArcBlock 没有必要为了证明自己支持 payment，去发行一种 ArcBlock stablecoin。过去，独立的 Payment Kit 已经把支付方式与支付货币作为可配置对象：应用可以连接 Stripe，也可以配置 Ethereum、Base 等 EVM 网络；在支持的网络上配置兼容标准 token 的合约后，可以用它完成支付，并把付款转换成应用自己的 credit。^[3] Payment Kit 的独立 Blocklet 已被后续架构吸收，不再作为独立产品维护；这些能力正沿着 ARC 的统一应用架构继续演进。

这是一种有意为之的分层。传统银行卡、银行账户、ABT、ETH，以及 USDC、USDT 这类 stablecoin，都可以在各自适合并已完成相应合规与技术集成的场景承担支付或结算角色。应用不应该因为要接受它们，就被迫成为它们的发行方；ArcBlock 也不需要再制造一种 stablecoin，才能帮助应用完成收款。

我们更关心付款之后的连续记录。

一笔 payment 可能只发生一次，服务消费却可能发生一万次。用户可以买一个月订阅，也可能预付一笔余额；企业可以按月 postpaid，也可能先送试用额度；一次服务可能同时调用模型、存储、网络和第三方 API；一个产品的收入可能还需要在开发者、运营者和合作伙伴之间分配。

在这些过程中，系统需要回答：

支付方式可以变化，应用对产品、服务和用量的记录必须连续。

这才是一套运营支撑系统，而不只是一只 wallet 或一个 checkout button。历史 Payment Kit 已经验证了 payment 与 credit top-up 的一部分；ArcBlock Chain 和 Verifiable Ledger 则提供 token、记录与协议基础。我们希望让这些能力在 ARC 中逐步组成付款之后的运营层：payment 负责价值进入，应用账本负责把价值与服务联系起来；当多方需要共同核对时，可验证记录与明确协议让彼此少依赖一方私有数据库里的最终解释。这仍是一条持续建设的产品路径，不是一套今天已经覆盖所有 billing、support 和 reconciliation 场景的成品。

这里也要保持务实。一个只有单一运营者、业务很简单的产品，用普通数据库完成 billing 往往已经足够。Blockchain 不是每张账单的必需品。可验证账本真正增加价值的地方，是跨系统、跨组织或跨参与者的记录、授权、审计和 reconciliation。

Credit Token 表达的是服务，而不是另一种美元

Credit Token 的价值，正来自它不必假装成一种公共货币。

一个 application credit 可以代表一千次 API call、一张图片生成、一小时 GPU、一 GB-month 存储、一段订阅期、一次活动名额，或者合作伙伴之间约定的分配单位。Credit Token 协议负责 token 的产生、余额与消费权限；应用负责它的名称、用途、有效期、退款、界面展示和实际服务交付。

同一个商家可以让用户支付 10 美元，得到 1,000 credits；也可以让 1 credit 在界面上显示为 1 美元的服务余额。两种界面看起来不同，底层问题相同：它们记录的是商家承诺提供的服务，以及用户怎样消耗这项承诺。是否构成 payment stablecoin 或其他受监管对象，仍然要看真实权利与运作方式，不能只由界面单位或“credit”这个名称决定。

航空里程、酒店积分、信用卡 rewards、游戏点数和餐馆的 stamp card 都说明了这一点。它们之所以有用，不是因为每个品牌都发行了一种新的美元，而是因为这些 credit 把一组业务关系表达得很清楚：谁可以获得、在哪里可以使用、能换什么、什么时候失效、多个合作伙伴怎样共同承认。

数字服务让 credit 的作用更强。可以设想，一个 AI 平台把模型调用、图片生成和存储统一放进一份用户可读的 service ledger；一个 creator network 让读者购买共同订阅，再按阅读或用户选择分配给作者；一组独立门店共同接受 loyalty credit，同时保留每次产生和消费的出处。这些是 Credit Token 与可验证账本可以支持的设计方向，不是本文宣称已经交付的完整方案。

Credit 的边界越明确，它对用户越有意义，也越不需要借用“货币”的想象。

Credit Token 也不意味着所有 credit 都必须公开、自由转让或永久有效。恰恰相反，很多服务额度应该由发行应用控制消费权限，限制用途或转让，并清楚展示其规则。如果一项 credit 只能由指定服务扣减，这可能正是正确的产品设计。把它强行设计成可在市场流通的 token，反而会增加用户误解和不必要的风险。

事实上，不可由用户之间自由转让、不能在二级市场任意出售、通常也不能随意赎回，往往正是 Credit Token、会员资格和 loyalty credit 最重要的设计属性。航空里程代表航空公司在特定规则下提供的权益，会员等级代表用户与服务之间的关系，API credit 代表发行应用将要交付的用量。它们的 utility 来自这段明确关系；如果脱离发行方、用户和服务仍能无限制流通，原本清楚的含义反而会被稀释。

这种约束也有助于让产品把注意力放回使用。一个 utility token 的首要目标，应该是让用户获得、使用或证明某项真实权益，而不是先制造一个可以自由交易的 marketplace。不可转让并不代表它没有价值；它意味着价值存在于服务和关系之中，而不主要由陌生买卖双方的出价来定义。

它与 prepaid balance 也不能只靠名字区分。用户交付了什么，发行方承诺了什么，是否可退款或赎回，资金怎样保管，credit 能否转让，以及具体地区的法律怎样适用，都要看真实设计。技术对象提供表达和执行规则的能力，不能替产品逃避这些问题。

ArcBlock 的目标，是让应用把这些规则做成可编程、可组合、可追踪的对象。历史 Payment Kit 的 credit top-up 流程允许应用定义充值产品、价格、支付货币和获得的 credit 数量；支付可以使用配置好的传统或链上方式，credit 则继续承担服务计量。^[4] 这已经验证了“用一种资产付款”和“用另一种对象运营服务”的分工。完整的 billing、support、跨组织对账与多方分配仍需要应用逻辑，以及 ARC 后续能力的持续完善。

好的支付基础设施，应当让应用少发行一种币

过去，很多 blockchain 项目从“我们能发行 token”出发，再寻找 token 可以解决的问题。我更愿意从业务事实反过来设计：用户要购买什么？商家承诺交付什么？哪些记录只属于单一运营者，哪些需要多方核对？哪里需要公共结算资产，哪里只需要应用内部的 credit？

早期 blockchain 应用最常见的误区之一，是把“一项新业务”直接等同于“一种新币”。一个团队做社交应用、内容平台、游戏或数字服务，很容易先假定：既然要使用 blockchain，又希望建立 utility，就必须发行自己的 fungible token。于是本来应该用来表达产品规则的 token，先被设计成了一种面向市场的货币；应用还没有证明需求，发行、流动性和市场价格已经变成了产品的负担。

更麻烦的是，很多这样的 token 实际 utility 不够强，对转让和使用范围的约束又不够准确。用户很快发现，最容易做的事情不是用 token 获得服务，而是在市场上买卖它。有人赚钱，也有人亏损；价格波动这个副作用因为最显眼，逐渐被误认为 token 的主要作用。项目接着需要维护流动性、解释价格和迎合交易预期，真正应该建设的产品 utility 反而退到后面。

这不是市场本身的错误，而是对象设计错了。如果一种权益本来只适用于特定用户、服务或期限，就应该让协议和应用表达这些边界；如果它不应该赎回或进入二级市场，就不应仅仅因为 blockchain 可以转账，就默认赋予它无限制流通能力。技术上的可转让性不是产品必须开启的功能。

现实商业世界给出了更简单的答案。Starbucks 有数字支付、余额、会员和 rewards；航空公司、酒店集团、信用卡公司和商场有各自的里程、积分、等级、优惠、凭证与会员资格。它们可以建立非常复杂的 loyalty system，却不需要发行“Starbucks Dollar”或“Delta Coin”。一家企业需要自己的客户关系与服务规则，并不意味着它需要自己的公共货币。

Blockchain 应用也是如此。一个应用完全可以使用已有的货币或链上资产收款，再用 Credit Token 表达服务额度，用 Verifiable Credential 表达会员等级、资格、优惠或完成记录，用 Digital Asset 表达独特的权利和可转移资产。不同对象各自承担准确的工作，比让一个可以交易的 fungible token 同时假装是支付、会员、积分、凭证和治理工具更清楚。

这并不是说应用永远不应该发行 fungible token，也不是说限制转让或赎回就自动决定了某种法律性质。少数网络确实需要一个跨参与者的 native asset，用于公共费用、协议安全或无法由单一运营者承担的协调。判断标准应该是这种资产是否承担不可替代的协议职责，而不是“我们做了一个 blockchain 应用，所以应该有一种 coin”。

如果答案真的要求一种广泛流通、维持固定价值、可按约定赎回的 payment asset，那么 stablecoin 是一项合理而重要的基础设施。GENIUS Act 为这项业务建立清晰边界，是行业进步。

但如果目标是让用户用信用卡或 stablecoin 付款，让应用按次、按量或按订阅提供服务，那么重新发行一种货币通常绕远了。应用需要连接合适的 payment rail，然后把精力放在产品、计量、billing、support 和 reconciliation 上。

这也是 ArcBlock 的选择。我们已经积累了多种支付方式、标准 token 与 credit top-up 的实现经验；接下来会让 Credit Token、ArcBlock Chain、Verifiable Ledger 与 ARC 的应用能力逐步组成付款之后的运营层。支付资产可以演进，业务规则可以由应用定义，账目在需要时可以被参与者核对。

真正的问题不应该是：“我们还可以发行什么 coin？”

它应该是：用户付款以后，我们能不能让每一单位价值怎样变成服务，都清楚、连续、可以核对？

这比再发行一种 stablecoin 难得多，也更接近绝大部分应用每天真正要解决的问题。

延伸阅读