网络已经能用，开发仍需继续
一个区块链创始人对 SEC 加密资产 FAQ 的个人解读
作者说明：本文仅为我个人从技术与产品建设者角度作出的解读，不构成法律意见或合规判断。刊登于 ArcBlock 官网，不代表公司的法律或合规立场，也不代表 SEC 或其他机构的认定。具体法律问题应咨询专业法律顾问。
软件什么时候算做完了？
对一个真正有人使用的系统，这个问题通常没有一个简单的日期。上线以后，安全问题还要修，性能还要改，用户遇到的新问题还要解决。软件已经能用，与开发仍在继续，本来就是可以同时成立的两件事。
但在讨论监管时，这两件事很容易被混在一起。一支团队是在维护已经交付的系统，还是仍在完成当初承诺要建出来的东西？看到他们都在写代码，并不足以回答。
我觉得 SEC 这次 FAQ 最值得讨论的，就是对这两种工作的区分。持续改进一个已经能用的网络，与承诺把网络做出来，不应仅仅因为都需要开发者，就被当成同一回事。
SEC 公司融资部（Division of Corporation Finance，简称 CorpFin）在 9 月 25 日发布的 FAQ，把这个区别讲得更具体了。作为一个准备长期把产品做下去的人，我关心的是：规则能不能看见交付前后的变化，也给持续维护和改进留下清楚的空间。
此前几篇 CLARITY 文章，我一直在谈实际行为与标签的区别，以及建设者能不能依照清楚、持久的边界做事。这次我想把问题再往日常工作里放一点：什么已经交付，什么仍待兑现，今天的用户究竟在使用什么。
先看清楚，这是什么层级的文件
这份 FAQ 是 CorpFin 工作人员的指导意见，不是 SEC 委员会的规则、法规或声明。委员会既未批准，也未表示不认可其内容。它没有法律约束力，不改变现行法律，也不为任何人增加新的义务。这些限定应当放在讨论的开头，不能缩成文章最后一行小字。[1]
它的基础，是 SEC 委员会 3 月 17 日发布、3 月 23 日生效的加密资产解释文件。这份解释文件区分了资产本身，以及围绕资产形成的投资契约：某项资产本身不属于证券，不代表涉及它的发行或销售安排就不会构成投资契约。这里的“投资契约”指的是整个投资安排，不一定是一份标题叫“投资合同”的纸面文件。解释文件也讨论了，这种关系在什么情况下可能结束。它是在解释如何适用既有的 Howey 框架，没有取代这个框架。[2]
如果不熟悉证券法，可以先抓住与本文有关的一点：人们是不是把钱投入共同事业，并合理期待依靠他人的关键经营或管理工作取得收益？重点是购买者究竟依赖别人完成什么关键工作，例如把一个尚不能运行的系统开发出来。只看“开发者还在干活”，回答不了这个问题。
这里还涉及一份 8 月的文件。Q2.3 明确引用了委员会在 8 月 18 日《Regulation Crypto Assets》规则提案第 56 页表达的解释性立场。9 月的 FAQ 说明的是这一立场，并没有把提案中的发行豁免或投资契约安全港变成已经通过的规则。[3]
委员会的解释文件、规则提案中表达的解释性立场、工作人员进一步给出的回答，是不同层级的东西。它们能让监管机构的立场更清楚，但不等于已经实现了我此前期待的、通过立法建立的长期稳定性。下面是一个建设者对这个方向的理解，不是法律意见，也不是对 ABT 或任何资产作法律定性。
软件能用了，不等于软件做完了
Q2.3 是我觉得最有用的一条。它讨论的是系统已经具备功能之后，继续保障安全、维护、改进功能，以及促进网络效应的工作，包括资助开发项目。按照工作人员所引用的委员会立场，这些服务不属于这里所说的关键管理努力；承诺在系统已经具备功能之后继续提供这些服务，也就不能满足 Howey 中对应的这一要素。[1]
这其实承认了一个普通的软件事实。一个已经能用的操作系统，仍然需要安全更新。开发者可能花很多年改进性能、适配新硬件。有下一版，不代表这一版还不能用。当然，这只是帮助理解软件工作的类比，不是把操作系统和加密资产作法律上的等同。判断一个系统的状态，数提交记录显然不够。
但“能用”也不能随便解释。Q2.3 的脚注明确采用 3 月解释文件第三部分的定义：系统的原生代币，是否已经可以按照系统设定的程序用途，在其中使用。仅仅有一个能打开的网站，并不能证明这一点。[1][2]
系统是否具备功能，与发行方是否兑现了自己的具体承诺，是两个问题。Q1.1 说得很清楚：判断承诺有没有完成，要看发行方当时究竟向购买者表示会做到什么。符合一个通用的功能定义，并不自动说明那些具体承诺也已经兑现。[1]
这就挡住了一种很容易出现的过度解读：交付了一部分软件，不等于所有重要的开发承诺都完成了。还得把实际交付的东西，和它本来要兑现的承诺放在一起看。
Q2.1 把同样的区分带到了对外沟通中。介绍一个系统现有的用途和能力，在没有其他因素的情况下，通常不构成从事关键管理努力的承诺。对于未来能力的一般性愿景，这一条也给出了类似说明，但限定是没有宣传潜在获利。判断仍然取决于具体事实与情境。[1]
我不会把它读成“路线图越模糊越安全”。产品有责任向用户讲清楚，什么已经能用，什么还在开发。这里有用的区别，是解释产品，与围绕某个人未来的关键经营工作出售获利预期之间的区别。删掉网站上的几个词，不能代替对实际安排的判断。
换个名字，不会让旧承诺自动消失
想想两种开发历史。一种是团队把网络做到了可用，随后几年持续维护、修复问题，扩展用户可以做的事情。另一种是每个新阶段都重新开始：新项目、新融资，再次承诺关键系统将在未来出现，有时还伴随着新代币和新的代币上架宣传。
在这套框架下，这两种历史提供的事实基础确实不同。区别不在创始人进入加密行业已经八年，还是只有八个月，而在某个具体安排对应哪些工作、哪些承诺。新项目当然可以正当，也可以有用，“新”本身不是问题。同样，“一直在做”也不能单独决定老项目的法律待遇。
Q2.2 回答了其中一种具体情形：如果另一方接手了原发行方从事关键管理努力的承诺，不能仅仅因为原发行方不再履行，就认为资产已经与相关投资契约分离。无论是主动承接，还是依法承接，都一样。[1]
这不是一条对所有连续创业者作判断的规则。成立一家新公司，不一定意味着接手上一家公司的承诺。但新项目也不会因此继承某种豁免身份。它自己的发行、行为和承诺，仍然需要按自身事实分析。换一个公司名字，不能替你把承诺做完。
这里还有一个不能回避的反例。如果把故事讲成“只有成功运行的网络才能与投资契约分离”，同样不准确。3 月的解释文件也讨论了失败或放弃：当购买者已经不能合理期待那些承诺的工作会继续发生时，相关关系也可能结束。但文件明确保留了此前未履约、虚假陈述或违法发行可能产生的责任。Q2.2 又限定了这条思路：有人接手承诺，不能简单套用原团队不再履行的逻辑。[1][2]
所以，我并不是说持续建设就获得法律奖励，停止开发就受到法律惩罚。具备功能和放弃开发，是不同的事实，也有不同的后果。对建设者真正有意义的是：围绕一个已经能用的系统继续工作，不必被一概视为最初开发承诺的无限延长。
最后两条回答，也说明这些边界有多具体。Q2.5 说，对本身不属于证券的加密资产，如果相关系统已经具备功能，宣布回购不构成从事关键管理努力的承诺；如果系统还不具备功能，而发行方把回购宣传为给持有人创造收益或回报，分析就可能不同。这回答的是特定的 Howey 要素，不是对一切回购安排及执行方式的普遍认可。[1]
Q2.6 更窄。交易平台提供二级市场，并不会因此自动成为这里的发起人（promoter）；还要符合《证券法》Rule 405 中 promoter 的定义。这一答案没有解决平台的其他全部义务，代币获交易平台上架也不能证明底层网络已经具备功能。[1]
这些回答帮助我们看清，某种行为究竟与哪个问题有关。它们都不能代替交付。
交付之后，我们一直在继续建设
对 ArcBlock 来说，这个区别很具体。我们早已交付了可以使用的产品，也一直有客户在使用。过去八年，我们的工作一直在继续：把已有的产品做得更好，解决实际使用中的问题，再在同一个基础上扩展新的能力。
从 Blocklets、去中心化身份，到 ArcChain、ArcSphere、ArcSpace，产品形态和实现方式在演进，但这些工作有一条连续的线。已经交付的能力成为后续建设的基础，客户的使用又带来新的需求。今天仍有大量开发工作，并不意味着过去的交付一直没有发生。
做过长期产品的人，大概都熟悉这种状态。客户不会因为你曾经宣布上线，就不再需要维护；一套系统开始有人使用以后，接下来的工作往往才变得具体。哪些地方需要改进，哪些能力值得扩展，哪些设计需要重新考虑，都要在持续使用中逐步解决。
所以，Q2.3 对我有共鸣的地方，就是它认识到了交付之后的工作。一个网络已经具备功能，团队仍然可以认真维护它、改进它，让它更好用。持续开发是一个产品正常的生命过程，不应仅仅因为开发没有停止，就把它理解为系统始终没有完成最初的建设。
这也是我读这份 FAQ 最关心的一点：规则能不能分清，哪些工作是在把承诺变成现实，哪些工作是在让已经成为现实的产品继续变好。对我们来说，交付早已发生，客户一直在使用，而建设仍会继续。
参考资料