標題：《CLARITY 審議突遭押後，業界分歧為何如此嚴重？》
原文作者：Azuma，Odaily 星球日報
現已知，原定於北京時間 1 月 15 日舉行首次參議院審議的加密貨幣市場結構法案（CLARITY）突發變數——長期追蹤加密貨幣立法進程的美國記者 Eleanor Terrett 暴料指稱，鑽石山（Coinbase）突然反對 CLARITY 所引發的市場爭議，美國參議院銀行委員會已取消原定於美國東部時間 1 月 15 日上午 10 點（即北京時間今晚 11 點）舉行的 CLARITY 審議聽證會（markup），新審議時間尚未公佈。
· Odaily 註：關於 CLARITY 的審議，此前參議院農業委員會（CFTC 的主要監督委員會）亦曾計劃於 1 月 15 日與參議院銀行委員會（SEC 的主要監督委員會）同時進行審議，但參議院農業委員會其後已率先將審議時間推遲至 1 月 27 日。參議院銀行委員會方面原本仍按原時間表準備，但今早臨近審議時卻又突然推遲。
CLARITY 簡介（熟悉可跳過）
上週，我們曾在《加密後市最大變數，CLARITY 法案能否通過參議院？》一文詳細梳理了 CLARITY 的內容、意義及進度。
簡而言之，CLARITY 的目標是明確區分數碼資產的分類，並劃分美國證券交易委員會（SEC）和商品期貨交易委員會（CFTC）的監管職責，從而為美國數碼資產市場建立一個清晰、具功能性的聯邦監管框架，解決長期以來監管模糊和執法不一致的問題。
對從業者而言，CLARITY 的落實將意味著監管環境的實質性轉變，即未來將有更可預期的合規路徑，市場參與者將能夠明確知道哪些活動、產品及交易屬於受監管範疇，從而減少長期監管不確定性，降低訴訟風險和監管摩擦，吸引更多創新者和傳統金融機構參與其中。
對加密貨幣本身而言，CLARITY 的落實預計可推動加密貨幣成為「更易被傳統資本配置的資產類別」，透過解決制度上的不確定性，讓那些原本無法入場的長期資本獲得合規的入場路徑，從而提升整個市場的估值下限。
業界分歧嚴重
明顯，加密貨幣行業對 CLARITY 對未來監管環境寄予厚望，但臨近審議之際，業界各大代表公司卻表達了截然不同的態度。
今天早上，加密貨幣立法遊說的重要力量 Coinbase 明確表示，將反對現行版本的 CLARITY 法案。
Coinbase 創辦人 Brian Armstrong 發文表示，在現行文本下，該法案比現狀更差，寧可沒有法案，也不要一部壞法案。——「該法案在 DeFi 和穩定幣收益方面存在重大問題，部分條款或賦予政府無限制取得個人金融紀錄的權力，損害用戶私隱，並可能扼殺穩定幣的獎勵機制。」
同時，a16z、Circle、Kraken、Ripple 等多家業界代表公司卻對現行版本的 CLARITY 表達了關注。支持態度。
a16z 的明星合夥人 Chris Dixon（Web3 故事的主推者）就此解釋表示：「加密貨幣開發者需要明確的規則…… 本質上，這項法案就是為了達成這個目標。」它並非完美，在正式成為法律之前還需要進行一些修改，但若我們希望美國繼續保持在全球建立加密貨幣未來的最佳地位，現在就是推動 CLARITY 的最佳時機。」
Kranken 聯席行政總裁 Arjun Sethi 解釋說，圍繞市場結構進行立法本來就很複雜，摩擦的出現是不可避免的。遺留問題的存在並不表示我們的努力失敗，而是意味著我們正在努力解決最困難的問題……現在放棄只會把不確定性鎖定，令美國公司在模糊的環境中運作，而世界其他地方卻仍在繼續前進。
現行法案的缺陷究竟在哪裡？
從各方的表態中可以看出，無論是堅決反對的 Coinbase，還是暫時選擇支持的 a16z 和 Kraken，雙方在對待現行版本 CLARITY 的態度上都有共通之處。即都認同現版本法案不夠完美，存在一定缺陷——區別只在於，Coinbase 選擇了更強硬的抵制，直接將其定性為「壞法案」，而 a16z、Kraken 則選擇了較為保守的措施，在措辭上使用了「不夠完美」、「遺留問題」等較為緩和的說法。
事實上，圍繞 CLARITY 的爭議早已存在——該法案在去年 7 月 17 日通過眾議院後，原定於去年年中提交參議院審議，但其後被推遲至 10 月，再推遲至去年年底，之後又被推遲至 2026 年，最近看來還得繼續推遲……
我們在上一篇文章中曾經提到過，關於 CLARITY 的爭議主要集中在對 DeFi 監管、穩定幣收益以及特朗普家族的道德規範等問題上。
針對特朗普家族的道德規範問題，業界最活躍的律師之一、Variant 首席法務官 Jake Chervinsky 解釋表示，雖然許多民主黨人已表明若不對此作出限制，將投票反對 CLARITY，然而，由於道德問題並不屬於參議院銀行委員會的監管範圍，審議聆訊無法討論該問題，因此這項分歧並非當前的爭議焦點。
· Odaily 註：在未來參議院的全體審議中，這個問題一定會成為民主黨議員的攻擊重點。
至於其他核心分歧，Jake Chervinsky 將其拆解為五個更細的要點，具體如下。
重點一：穩定幣回報問題
去年通過的 GENIUS 法案曾經禁止了計息穩定幣，這項妥協是為了爭取銀行業的支持，但代價則是扼殺了一整類的創新產品。
但現今，銀行界對這項條款依然不滿，試圖在 CLARITY 中推翻重來。這是因為 GENIUS 雖然規定穩定幣發行方不得向持有人支付「任何形式的利息或收益」，但並未限制第三方提供收益或獎勵，而現行 CLARITY 第 404 條卻連第三方提供收益的行為也一併禁止。倘若現行版本的法案獲得通過，穩定幣持有者將無法獲得任何收益或獎勵，只能透過支付等行為獲得激勵。
Jake Chervinsky 批評表示，限制穩定幣的收益或獎勵缺乏合理的政策依據，這只會損害美國消費者利益、美元國際地位以及美國國家安全。而銀行之所以強烈要求作出此項更改，是因為大型銀行每年可從支付和存款業務中獲利超過 3600 億美元，而產生利息的穩定幣將直接威脅到這些利潤。
重點二：證券代幣化
去年，證券交易委員會（SEC）主席 Paul Atkins 發起了「Project Crypto」計劃，旨在通過將金融系統遷移至區塊鏈上，以實現系統升級。然而，CLARITY 第 505 條似乎可能透過剝奪其公平對待加密資產的權力，阻礙這一目標的實現。
保羅阿金斯曾強調「創新豁免」，而第505條則規定，不能僅因證券是在區塊鏈上發行，就豁免或修改任何證券監管要求，亦不能基於此理由豁免任何人的登記義務。
要點三：代幣發行
這或許是 CLARITY 中最重要的部分，為建設者提供清晰的路徑，使他們可以在不擔心因發行「未登記證券」而遭到 SEC 执行法律行動的情況下發行代幣。
CLARITY 的第一編（Title 1）涵蓋了這條路徑，雖然條文清晰，但並不容易，也不便宜。第一編要求許多項目進行資訊披露，從理論上來說是好事，但問題在於細節——第一編包含了極其繁重、接近股權層級的披露要求，與上市公司的要求幾乎沒有太大分別——包括經審計的財務報表等。這套制度適用於成熟的公司，但並不適合初創企業。
這只是眾多細節之一。第一編還要求建設者必須為每一個代幣獲得美國證券交易委員會（SEC）的批准；發行後須長期履行資訊披露義務；公開募股融資金額上限為2億美元等等。
相形之下，創辦人不如直接到海外發行或干脆發行股票算了。
要點四：開發者保護
非受管軟件的開發者並非資金傳輸機構，根本無需承擔用戶的 KYC 驗證責任——這一點應該毫無爭議。
然而，CLARITY 第三編（Title 3）屢次暗示監管機構或會將監控範圍伸延至 DeFi 領域。這些條文必須刪除或修訂。
要點五：機構通道
受監管的金融機構始終因合規顧慮而不敢涉足 DeFi。
CLARITY 的第 308 條原本希望解決這個問題，卻在關鍵點上犯了錯誤——它對機構施加了額外負擔，反而比現狀更容易令它們卻步於 DeFi 之外。
激進派與保守派
根據 Jake Chervinsky 對現行 CLARITY 法案中幾個核心問題的分析，不難理解為何 Coinbase、a16z、Kraken 等機構都一致認為——這並非一部完美的法案。
面對一項藏有暗雷的法案，作為加密貨幣的行業代表，Coinbase 與 a16z、Kraken 在根本利益上其實是一致的，但在爭取利益的路徑上卻存在著差異。
Coinbase 選擇了更為強硬的對抗姿態。其核心邏輯在於，如果 CLARITY 帶著那些不利於業界的條款獲得通過，即使只是含糊其辭，也可能在執法層面上被無限放大，對創新形成長期抑制。至於日後的修法成本和政治阻力，反而可能遠高於繼續承受現時監管不確定性的代價。
a16z、Kraken、Circle 等機構所採用的則是更為保守、也更偏「現實主義」的策略。在他們看來，美國加密監管長期停滯的最大問題，並非「規則不夠好」，而是根本沒有規則。CLARITY 雖然存在瑕疵，但至少提供了一個可被修訂、可被博弈、可被逐步完善的立法定點。一旦 CLARITY 正式落實，美國加密行業將首次擁有一个聯邦層面的統一框架，後續再圍繞具體條款進行修補，反而更具操作空間。
這裡並沒有簡單的是非對錯，雙方矛盾的核心其實在於是否應該在現行版本下繼續推進法案，以及應該為此付出多大的妥協代價。這裡也不存在什麼「行業內哄」，雙方的統一訴求都是讓 CLARITY 變得更好，只是各自選擇了不同的博弈策略。
正如 Jake Chervinsky 所說：「無論好壞，這份文本在正式成為法律之前還會出現大量變動。希望它能往更好的方向發展吧。」
歡迎加入律動 BlockBeats 官方社群：
Telegram 訂閱群：https://t.me/theblockbeats
Telegram 討論群組：https://t.me/BlockBeats_App