曼昆研究 | 詳解美國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. 本文作者：劉紅林、邵嘉碘