曼昆研究 | 详解美国SEC《加密资产的证券发行和注册》

2025年4月10日，美国证券交易委员会（SEC）公司融资部（Division of Corporation Finance）发布了一份重量级政策文件：《Offerings and Registrations of Securities in the Crypto Asset Markets》。标题虽然温和，但对Web3行业来说，它本质上是一份标准化的发币“披露文件指引”。 这不是新的执法公告，也不是某个项目的处罚通知，而是一份极具实操意义的披露指引。SEC非常罕见地用近四千字逐条告诉你：如果你想在美国合规发行Token、融资募资，那你必须把这些事写清楚、说明白。 你可以把它当成Web3项目通向美国资本市场的说明书，也是SEC给行业画出的一张清晰的边界地图。 背景：为什么SEC要发这份文件？ 这几年，越来越多Web3项目走合规路径，试图以证券形式公开募资，不少项目采用了如下方式： • 通过Form S-1在SEC注册公开募股（类IPO）； • 利用Reg A+进行小额募资，绕过完整IPO流程； • 由海外团队提交Form 20-F进入美国市场； • 甚至用信托结构发行与Token挂钩的ETF产品。 SEC注意到，不同项目提交的注册文件五花八门，有的完全照搬白皮书，有的技术术语堆砌却毫无实质内容，更有甚者连基本风险因素都遮遮掩掩。为了规范行业操作，SEC公司融资部发布这份政策，列出发币募资时必须披露的核心内容。它不具有法律效力，但实质上成为行业默认的注册参考标准。 正文开头特别点名：“to provide greater clarity on the application of the federal securities laws to crypto assets…”——为加密资产如何适用证券法提供更清晰的指引。 业务披露：不是讲梦想，而是讲你到底在干什么 SEC强调，项目方必须提交一份关于自身业务的完整描述。这段话在传统IPO中是标配，现在也被明确引入Token注册流程中。 “Issuers are required to disclose information material to an understanding of the general development of their business.” 说白了，不许再用“区块链+未来愿景”的叙述糊弄投资人，而是要实打实写清楚： • 你做的是什么项目？是L2？DEX？GameFi？DePIN？ • 现在项目发展到哪一步？有主网吗？用户量？链上活跃数据？ • 上线之后你还运营吗？项目方解散？还是交给DAO？DAO是否有清晰治理结构？ • 你怎么盈利？是否有清晰的变现路径？靠手续费、Token溢价、生态反哺？ • Token到底是干嘛的？是治理、Gas、服务凭证，还是一种投资凭证？ SEC特别指出，不能用“讲技术讲生态”代替真实业务情况，也不能照搬白皮书。材料中必须体现出你具体、清晰、可量化的商业模型。 技术结构披露：你说有链，就得把链的构造说清楚 这次SEC文件最大的亮点，是技术披露部分写得前所未有地细。 “The objectives of the network and how the technology… functions and accomplishes its objectives, including architecture, software, key management…” 具体包括以下内容： 网络和应用的目标、用途和运行机制；共识机制、交易确认方式、区块大小、Gas机制、交易吞吐量；钱包系统和密钥管理方式（是否自托管、是否支持多签）；网络是否开源？IP归属谁？有无专利争议？是否设置网络升级机制？升级提案流程是怎样的？谁有执行权限？如果通过智能合约进行治理，这些合约是否已审计？谁来维护？是否可升级？ SEC还要求项目说明网络中各种角色——包括用户、开发者、验证者、治理参与人、链下服务提供方等——的职责与交互方式。你不能再只说“我们有链、链上运行”，而是要像描述一家公司治理结构一样，把链的技术细节、治理机制、升级逻辑都解释清楚。 上述项目未必全部适用于每一个项目，SEC并未强制所有项目都披露这些内容，而是说“如果这些内容是你项目的组成部分且对投资人重大，那你就必须披露”。 Token披露：你发的是证券，就按证券的标准披露 这部分SEC写得非常直白：你发的Token如果属于证券范畴（大概率是），那你就得像披露股票那样，讲清楚它的属性和权利结构。 “Rights, obligations, and preferences… including voting rights, liquidation rights, redemption terms, etc.” 你需要回答以下问题： Token是否代表资产收益权？清算权？投票权？Token是否可转让？是否有锁仓、禁售、流通限制？是否具备拆分、质押、回购、销毁等功能？规则如何设定？Token的生成机制是什么？是一次性mint？定期释放？有无上限？是否为DAO设立特别Token结构（如治理Token vs. 经济Token）？合约是否支持升级？如果是，谁有权限修改逻辑？是否做过第三方审计？审计报告是否公开？ 你可以用很强的技术逻辑设计你的Token模型，但最终你还是得按SEC习惯的语言，把这个模型翻译出来供审阅。这时候不是拼创新，而是拼“能不能讲明白”。 风险揭示：不只是价格波动，而是每一个你担心出问题的点都要说清楚 SEC对风险披露向来最为敏感。它强调风险不是走流程的装饰，而是项目的义务。 “Material factors that make an investment speculative or risky… including technological, regulatory, and operational risks.” 你必须披露的风险不止是“Token价格波动”： 与发行人计划的业务运营相关的风险，例如与技术和网络安全相关的风险，以及发行人业务的实施，以及对其他网络或应用程序的依赖。与证券有关的风险，例如与证券的任何独特特征有关的风险，包括其形式、价格波动、持有人的权利或其缺乏权利、估值和流动性、供应和保管。与其他适用法律法规相关的风险，例如发行人的活动是否需要根据汇款法向金融犯罪执法网络或某些州金融服务机构注册，或向其他监管机构注册，例如联邦或州银行监管机构或商品期货交易委员会。 这些都必须如实披露，哪怕它们听起来会“影响融资”。SEC的底线是“不要藏”，否则你就等着SEC来发函。 发行人管理层信息披露：谁是操盘手，谁拿了钱，都必须写上来 你可以说自己是DAO项目，或者基金会控制，但SEC不会听你自我介绍，它看的是“谁在做决策、谁能发token、谁拿到了实质利益”。 “Disclosure is required for persons who do not hold formal titles… but who perform policy-making functions.” 发行人的管理层是谁？其身份和经验相关的信息哪些人参与了项目治理、资金决策、路线图制定？哪些服务方在运营项目？是否支付了顾问费、技术费？是否有员工或团队持有大量代币？是否将智能合约或网络代码托管给特定团队/组织？ 哪怕你用了最复杂的结构包装，也必须披露实质控制方。SEC对结构设计并不敌意，它只要你别“挂羊头卖狗肉”。 财务与审计：你不是只发了个token，而是把自己带进了SEC的视野 很多项目方会说：“我没有营业收入啊，需要财务报表干嘛？”SEC不是要你美化财务报表，而是要你说明白这些事： Token是否计入资产？预售是否作为负债处理？是否使用Token对价支付服务？如何计量？Token激励、代币释放、质押利息等是否构成费用？是否存在链上收入流？如何确认和审计？Token是否产生与传统证券相似的分红、返利或复利？ 原文写道：“Issuers are required to provide financial statements that comply with applicable requirements…” 你需要提交标准格式的财务报表（尤其是S-1、Reg A+、20-F路径），并对Token相关的资产、负债、收入、费用做出清晰会计处理。 SEC特别指出，如果你的Token规则写在合约里、链上治理规则由代码决定，那么这段代码本身就要作为Exhibit（正式附录）提交，而且更新必须同步。 “We have observed filings include as an exhibit the code of the smart contract(s)…” 也就是说： 智能合约地址、版本、审计情况都要同步披露；升级逻辑是否存在、是否被少数人控制，也要说明；如果合约控制Token释放规则，那这就是你项目的“证券协议”。 曼昆律师总结：合规，是一次行业集体成年礼 很多创业者看到SEC这份文件的第一反应是：“太复杂了，我们换个国家搞吧。”但这份文件并不是拒绝Web3，而是邀请Web3走向公开市场、走向制度化的一次尝试。 它不是一张红灯，而是一张路线图。 你想要真正拿到传统机构的钱？你想让项目在主流市场交易？你想长期活下去，不怕任何司法函？那你就必须适应这种披露要求，以证券的逻辑来管理你的token，以公众公司意识来运营你的项目。 SEC并没有告诉你怎么设计token，但它告诉你哪些信息不能藏、哪些结构不能玩。这份清单就是你向美国市场合规融资的指南针。 如果你是Web3项目方、交易平台、基金、律师、审计机构——现在就是时候，拿起这份文件，重新审视你准备提交给SEC的一切。

/ END. 本文作者：刘红林、邵嘉碘