CLARITY Act or Not，我们先把 ABT 讲清楚

前几天，我们发布了新的 ABT 页面。我在社交媒体上写了一句话：CLARITY Act or Not，我们决定先把 ABT clarify 清楚。

这句话获得的反响比我预想的更大。我想，它说中了一个很简单的问题。我们当然希望法律能够给 blockchain 行业清晰、持久的边界，但 builder 不能把自己的责任全部交给法律。一个 token 代表什么，谁能控制它，在什么条件下使用，违约会发生什么，账怎样核对，这些本来就应该由产品先讲清楚。

我在前两篇关于 CLARITY Act 的文章里，分别讨论过为什么 token 的法律判断必须看真实权利与行为，以及为什么 builder 需要一套能跨越政府更替的规则。^[1] 这篇不再分析法案。我想把镜头转回我们自己，具体讲清楚 ArcBlock 为什么需要 ABT，以及我们所说的 token utility 到底是什么。

这也不是对 ABT 法律性质的判断，更不是投资建议。我要讨论的是产品设计：怎样把一项承诺、一份服务额度、一种有限资源、一项数字权利或一笔多方分配，变成参与者看得懂、系统能够执行、事后可以核对的规则。

这也解释了为什么一篇讲 ABT 的文章，会谈到 Credit Token、Curve Token 和 Digital Asset。ABT 是 ArcBlock 公共网络的 native token，直接承担网络支付、staking 以及跨参与者协作中的用途；应用自己的服务额度、资源规则和数字权利，则应该由含义更准确的对象表达。把所有东西都叫 ABT，不会增加 ABT 的 utility，只会把不同的权利和责任重新混在一起。要把 ABT 讲清楚，也必须讲清楚它不需要假装成什么。

Stake 不是 yield，而是把承诺放到台面上

Crypto 行业谈 staking，常常直接联想到 yield。ArcBlock 的 Stake for X 采用了不同的定义。这里的 stake 更接近 bond、deposit 或 collateral：你为了一个具体目的，把一笔 token 锁定在一组事先声明的规则下，以此支持一项别人可以依赖的承诺。

这个 X 可以是一项网络资格、一段服务连续性，也可以是双方约定的其他事情。一笔 stake 会声明用途、期限、谁有权在什么条件下 slash、被扣罚的 token 去哪里，以及退出要等待多久。锁定期间，它不是一笔可以随时花掉的余额。

最直接的例子是 Stake for Gas。对正常用户来说，每发一笔 transaction 都要计算并支付 gas，是很大的体验摩擦；但如果网络彻底没有成本，dust、Sybil 和 spam 又会变得便宜。ArcBlock 的做法，是让用户在公共网络 stake 一笔 ABT，在正常额度内获得交易手续费豁免。token 没有被每笔消费掉，而是作为遵守网络规则的保证。

如果有人高频滥发交易、攻击网络，规则可以 slash 这笔 stake，并把它送往事先声明的 community pool。于是正常使用接近 gas-free，批量制造垃圾交易却会迅速变得不经济。这里的关键不是“免费”，而是把成本从每一次正常行为，移到真正违反约定的行为上。

SubGuard 是另一个已经进入产品的例子。用户可以给支持它的订阅设置 ABT stake。当信用卡过期、支付通道临时失败或账单短暂逾期时，服务不必立刻中断。原账单仍然存在。用户在保护期内正常结清，stake 不会被用于结算这张账单，订阅保护可以继续；结清账单并停用 SubGuard 后，剩余 stake 可以按规则退回。如果长期不处理，服务方才可以按约定从 stake 中结算欠款和服务费。

Stake for X 把正常使用的低摩擦，与滥用行为的实际代价分开。

我们故意不把 stake 设计成一个更麻烦的 prepaid balance。正常付款永远应该更经济。SubGuard 的价值，是让一次支付故障不至于立刻变成业务故障，同时也不把风险单方面留给商家。

再往前一步，可以设想 Stake for Message。一个陌生人希望给你发消息，他先 stake 一小笔 token。正常沟通后，stake 退回；如果是 spam，接收者可以按规则 slash。为了不让接收者靠惩罚别人赚钱，被扣罚的 token 可以进入 community pool，而不是进入执行 slash 的人的账户。

这不会创造百分之百正确的判断。诚实的请求仍可能被误判。但信任在现实世界里本来就意味着承担一点风险。stake 做的事情，是让发出请求的人认真一点，也让接收请求的人知道，对方为自己的行为放上了一份有代价的承诺。同样的机制可以用于论坛发帖、活动报名、no-show、投票或其他需要抑制滥用的场景。它们是可以继续设计的方向，不是我们今天已经上线的一串产品清单。

应用需要的，往往不是另一种 stablecoin

很多数字服务真正缺少的，并不是自己再发行一种 stablecoin，而是一套由业务规则定义、可以精确计量和核对的 credit ledger。

GENIUS Act 已经在 2025 年成为美国法律。它第一次为 payment stablecoin 建立了联邦监管框架，也因此把“发行一个 stablecoin”究竟意味着什么写得更具体：发行方必须属于获准的 issuer，维持至少 1 的合格储备，公开赎回政策和费用，按月披露储备构成并接受相应核验，还要承担资本、流动性、运营、合规和风险管理要求。^[2]

我认为，这项法律给企业的一个重要启示不是“stablecoin 合法了，所以每家公司都应该发行一个”，而恰恰是相反。法律把 payment stablecoin 从一个模糊的技术概念，变成了一项有明确赎回义务、储备责任和持续监管成本的金融业务。对真正需要提供公共支付与结算资产的机构，这是值得建立的基础设施；对只是希望向用户收款、记录服务消耗的普通企业，这往往是完全不同的问题。

一个商家需要接受美元、信用卡付款或合规的数字支付，不等于它需要发行一个与美元保持固定价值、承诺按固定金额赎回的 digital asset。收款可以由现有的银行、card network 或 stablecoin payment rail 完成。收款之后，企业真正面对的是自己的业务账本：用户买到了什么服务额度，额度怎样消费，能不能转让或退款，什么时候过期，多个产品或合作伙伴怎样分账。

这和现实世界并没有那么不同。超市、工厂、酒店和软件公司都用美元或欧元收款、记账和结算，没有哪一家因此需要发行自己的美元或欧元。对绝大部分企业和 network operator 来说，能够使用一种支付资产，与自己成为这种资产的发行方，是两件完全不同的事。

这也是我们没有因为 stablecoin 获得清晰框架，就决定做一个 ArcBlock stablecoin 的原因。我们没有看到这样做对 ArcBlock 应用产生了必要价值。相反，发行 stablecoin 会把储备、赎回、流动性、披露和合规变成产品的中心责任，而绝大部分应用要解决的其实是服务计量与对账。对这些应用，我们选择提供 Credit Token，让它们用明确的业务规则表达自己的服务额度。

这个区别值得用一篇独立文章展开。GENIUS Act 之后，为什么大部分企业不需要发行 stablecoin，为什么 Credit Token、loyalty points 和可验证的服务账本反而更接近日常业务，我会在后面专门讨论。这里先留下最重要的判断：支付使用什么资产，与应用内部用什么对象表达服务，不应该被混成同一个问题。

Payment rail 负责收款和结算，Credit Ledger 负责持续的服务计量。

航空里程、酒店积分、信用卡积分和餐馆盖章卡早就在做类似的事。今天的 AI 与 API 产品则把这个问题变得更明显。用户可以预先充值，随后每次 API call、图片生成或计算任务从余额里扣除；也可以先累积逐项用量，到结算日再支付账单。无论 prepaid 还是 postpaid，一次信用卡或 stablecoin 支付只解决了资金进入或结算的瞬间。应用仍然需要记录每项服务用了多少、由谁使用、按什么规则计价，以及发生争议时如何对账。

单一商家的数据库经常就是合适的答案。Blockchain 并不是数据库的自动升级版。但当多个门店、合作伙伴、作者、服务提供者或用户需要共享记录和分配结果时，一个可验证的 ledger 开始有实际价值。

比如十位作者共同提供一项订阅。读者只付一次费用，却可以阅读所有人的内容；收入可以按阅读量分配，也可以让读者把一部分额度直接分给自己认可的作者。这个系统需要非常细的 credit 与 transaction 记录，却没有理由让十位作者为了这件事共同发行一种 stablecoin。

Credit Token 为这类应用提供可编程的服务额度。它的一单位可以代表一次 API call、一张图片生成、一定量的存储、一个订阅权益，或者应用自己定义的分配权重。发行方决定怎样产生、消费和显示这些 credit，ArcBlock Chain 提供 token 与可验证账本机制。界面也应该把发行方、用途、消费权限、有效期和退款规则说清楚；相关法律处理仍取决于具体事实和权利安排，不能由产品名称代替。

有限资源还有另一类问题。GPU、AI inference、计算实例和临时容量会经历明显的波峰与波谷。空闲时，资源希望被利用；高峰时，供给有限，需要用公开的规则调节分配。ArcBlock Chain 的 Curve Token 让应用可以把 token 的发行与销毁，同一个指定的 reserve token 以及声明的曲线规则联系起来。固定规则可以接近普通的 service credit；应用也可以把自己测得的资源状态映射为规则参数，再按曲线完成换算。

Bonding curve 过去常被 memecoin 和自动化交易采用，但曲线本身并不只属于投机。它也可以是资源定价和配额分配的工具。这里必须把边界说清楚：曲线执行的是应用声明的换算规则，它不会自己测量 GPU 是否真的空闲，也不会自动完成调度和交付。这些仍然是应用的责任。

当一项软件服务由模块作者、应用开发者、独立运营者、基础设施提供者和推广者共同完成时，我们希望可验证账本和协议最终能够执行参与者事先同意的分配规则。过去往往是离付款最近的一方最容易拿到收入，其他人的贡献只能依靠后台报表和周期性结算。这个方向可以让贡献记录更容易核对，并让更多分配步骤自动完成，但它还不是 ArcBlock Chain 里已经交付的一套完整收入归因与结算产品。它也不会凭空创造公平，规则是否合理，仍然要由参与者决定。

Digital Asset 可以把权利、合同与执行联系起来

在 ArcBlock Chain 里，我们更愿意把 NFT 称为 Digital Asset。它不应该只让人想到头像、收藏品或一张可以炒作的图片。

ArcBlock 设计里一个很特别的基础，是账户、FT、Digital Asset、agent identity、stake 等对象都使用 DID 作为统一的标识方式。它们当然仍有不同的数据结构、权限和规则，但不需要被隔离在互不相干的地址世界里。这种共同的标识方式，让协议可以明确引用不同对象及其关系，也为后续的授权和价值分配留下统一的表达基础。

这为一种很有意思的递归结构提供了方向。一个 Digital Asset 可以表达某项数字版权或使用许可的记录；它本身又可能引用其他人的素材、模块或权利，以及已经约定的分配关系。未来，人类可读的合作合同可以被签名并以 Verifiable Credential 表达，再由相关资产引用；协议则处理其中适合自动化的明确规则。ArcBlock 目前还没有把这整套合同表达、VC 关联和收入结算作为一个完整产品交付出来。

共同的 DID 标识模型让不同对象可以互相引用；每条关系仍然有自己的规则和证据边界。

我希望，人读得懂的 contract 和机器可以执行的 agreement 最终不必成为两个完全分离的世界。一个作品产生收入时，系统可以依据已经声明并由参与者接受的关系，执行可自动化的分配步骤；当链上资产发生转移，或某项授权被更新时，各自的记录也可以按对应协议保留和核验。现实权利是否随之转让、某份 credential 能否撤销，仍然取决于具体协议、实现和法律安排。

这里同样需要克制。DID 只负责标识对象，不会自动证明某个人真的拥有现实世界的版权。VC 可以证明某个 issuer 作出过某项声明，不会保证声明天然为真。Digital Asset 可以表达权利、合同和授权记录，不会替代司法系统，也不会自动赋予一项法律权利。技术的价值，是把谁声明了什么、依据是什么、规则怎样执行，变得更明确、更容易核验。

Public Chain 和自己的账本，解决的是不同范围的 clarity

并不是每一条记录都应该放到 public chain。

ArcBlock Chain 的公共网络适合需要 public record、共同状态和多方协作的场景。任何人也可以运行自己的 Verifiable Ledger，用于组织内部、个人应用，或一组明确合作伙伴之间的记录。自己的 ledger 不会自动继承公共网络的共识，也不会因为写入了数据就让外部事实变成真实；它提供的是可归属、可追踪、可以复核的记录基础。

今天使用云计算或 AI 服务时，我们往往收到一张总账单，却很难从自己的角度回答：究竟哪个应用、哪个 agent、哪次错误重试、哪段开发实验消耗了这些 token 或计算资源？如果内部有一份自己的 verifiable usage ledger，就可以先完成团队内部的 reconciliation；如果供应商或合作伙伴也签署对应记录，还可以进一步核对双方账目和处理争议。

这不需要把商业数据全部公开。它也不要求每笔 API call 都变成一笔公开链上的 payment。Public Chain 提供跨组织协作需要的公共记录，private 或 self-run ledger 提供自己和特定伙伴需要的 operational clarity。两者可以使用相同的 DID、credential 和 protocol 思路，却服务于不同的信任范围。

所以，对我来说，把 ABT 的 utility 讲清楚，不能只在页面上列几个 use case。它属于一套更大的设计：Stake for X 让承诺带上可执行的代价；Credit Token 表达应用自己的服务额度；Curve Token 把有限资源的换算规则写清楚；Digital Asset 为权利、凭证和多方协作建立连接；public chain 与 Verifiable Ledger 则让这些记录在合适的参与范围里可以核对。

我仍然期待 CLARITY Act 给整个行业一套长期可依靠的法律边界。但 CLARITY Act 能不能通过，不影响我们今天应该做的事。我们不应该等一部法律替我们解释 ABT。我们应该先把用途、控制、责任和限制写进产品，再用最清楚的语言把它们说出来。

我希望法律告诉 builder 边界在哪里，也要求我们自己把产品里的边界讲明白。只有两边都做到，创新者才敢往前走，用户也才知道自己把什么交给了系统。

延伸阅读