CLARITY Act 讓開發者少背 broker 風險

我把 CLARITY Act 的開發者保護說法拆成一份可直接套用的政策 memo，給 blockchain 團隊拿去改文件。

我看 crypto 監管被講成一攤霧已經很多年了。大家一邊叫你去做創新，一邊又把「寫程式」「跑基礎設施」「當 broker」混在一起，像是只要碰到鏈上東西，你就自動變成金融中介。這種感覺很煩，因為它不是單純的法規問題，是開發者每天都會撞到的風險問題。

我讀到 Coinfunda 這篇 CLARITY Act 開發者保護整理，再加上 Solana Institute 相關說法之後，我就知道重點不是政治口水，而是角色邊界。規則不清楚，團隊就會過度找律師、過度加限制，最後不是慢就是跑。你如果做過 open-source 基礎設施，還要一邊怕 repo 被看成受監管中介，我猜你很懂這種煩躁。

我這篇要做的事很單純：把這個說法拆成開發團隊看得懂、法務也能接的版本。不是在講法案會不會過，而是講一個團隊到底怎麼把「我們不是 broker」這件事寫清楚。

這次我抓的原始來源是 Coinfunda 的文章，裡面沒有提供觀看數、書籤數或星數，所以我不亂編。它的價值在於把一個老問題講得很直白：如果法律能清楚區分開發者和金融中介，團隊就能少掉一大塊莫名其妙的風險。

先把 code、custody、broker 三件事分開

“Many developers argue that writing software should not automatically expose them to the same regulatory obligations imposed on financial institutions, brokers, exchanges, or custodial service providers.”

翻譯一下就是：寫軟體，不等於你在做金融機構該做的事。這句看起來像廢話，但現實裡很多人就是會把它們混成一團。你只要做 wallet SDK、protocol client、smart contract library，旁邊就有人開始問：那你是不是也在處理客戶資產？是不是在操作交易？是不是其實是 broker？

我自己就遇過這種 review。工程團隊明明在做工具，法務卻因為「跟資產有關」就開始往最壞的方向想。問題不是他們愛找麻煩，而是文件寫得太糊，讓人只能用最保守的方式理解。CLARITY Act 這類說法想做的事，就是把角色切清楚。

實操上，我會要求團隊先寫一份「我們是誰、我們不是誰」的短文。不要先講願景，先講責任邊界。因為一旦你把自己寫成「提供金融服務的平台」，後面再想切回 software builder，就很難看。

• 把團隊角色寫成單句：builder、maintainer、operator、custodian、facilitator 擇一。
• README、whitepaper、網站文案裡，避免暗示你有 custody 或 brokerage 能力。
• 架構圖要標出哪裡是程式碼，哪裡是資產控制點，別讓人看完以為你全包。

我一直覺得，監管最怕的不是你很敢，而是你很模糊。模糊會讓別人替你補最壞的想像，最後你連自己做什麼都說不清楚。

真正嚇人的不是罰款，是人跟錢先跑掉

“Regulatory uncertainty has increasingly encouraged startups to relocate abroad, venture capital to seek overseas opportunities, and developers to build outside the United States.”

這段我很有感。很多政策討論都愛講道德、講秩序、講保護消費者，但對創業團隊來說，第一個反應通常很土：這會不會讓我比較難活？如果答案是「有可能」，那人就會開始想別的地方。

白話說，法規不清楚不是只有合規成本變高而已，它會直接變成遷移成本。小團隊最痛，因為他們沒錢養一整隊法務，也沒空陪制度慢慢磨。最後就會變成：能不能在別的司法管轄區先做？能不能把公司放外面？能不能乾脆不碰這塊？

我看過不少 startup 會議最後都變成同一題：不是我們要做什麼，而是在哪裡做比較不會被煩死。這其實很悲哀，因為產品討論被法律不確定性拖成生存討論。

實操上，我會建議團隊每季記一份「監管摩擦清單」：

• 哪些功能因為分類不清楚而延後？
• 哪些決策花最多法務時間？
• 哪些國家/地區成了臨時備案？

這份清單不是拿來抱怨，是拿來跟投資人、顧問、甚至自己對齊：如果規則這麼糊，我們到底是在做產品，還是在做風險管理外包？

CLARITY Act 本質上是在畫線，不是在講口號

“The legislation seeks to provide greater certainty regarding digital asset classification, regulatory jurisdiction, market structure oversight, compliance obligations, and developer liability.”

這一句基本上就是整個政策 stack。它想解的不是單一條文，而是五個一起糊掉的問題：資產怎麼分類、誰有管轄權、誰盯市場結構、誰要負合規責任、開發者到底要背多少 liability。

也就是說，這法案的核心不是「放寬」，而是「定義」。我知道定義聽起來很無聊，但在法規世界，無聊通常比亂槍打鳥好很多。因為只要邊界清楚，團隊就能設計；邊界不清楚，團隊只能猜。

我之前看過一些專案為了看起來安全，硬塞一堆權限層、管理後台、公司包裝。結果不是更安全，而是更像在補洞。這種防禦式工程很多時候不是產品需要，是政策模糊逼出來的。

實操上，我會叫團隊把這五個面向直接做成一張表：

• classification：我們碰不碰資產分類問題？
• jurisdiction：我們在哪裡被認定、由誰管？
• oversight：誰在盯市場行為？
• compliance obligations：我們需要做哪些申報或揭露？
• developer liability：哪一段責任真的落在我們身上？

這張表不要只給法務看，產品、工程、BD 都要看。因為只要其中一個人講錯話，整個團隊的敘事就歪掉。

open-source 開發者需要的是軟體法，不是情緒安慰

“Supporters argue blockchain developers should be treated similarly to creators of internet protocols or open-source software frameworks.”

這句我覺得最有用，因為它把戰場從「crypto 特例」拉回到「軟體作者到底該負什麼責任」。這才是比較正常的討論方式。你寫的是 protocol、framework、library，還是你真的在操作服務，這些事本來就不一樣。

翻譯一下就是：不要因為你寫的是 blockchain code，就把你當成永遠要對所有下游行為負責的人。這種邏輯如果成立，那寫 TCP/IP、瀏覽器、甚至壓縮工具的人都能被拖下水，因為總有人拿工具做壞事。

我很在意這點，因為 open-source 社群最怕的不是沒人用，而是沒人敢碰。當貢獻者覺得每一次 commit 都可能變成個人風險，大家就會退。最後剩下的不是最好的技術，而是最敢扛風險的人。

實操上，我會這樣寫文件：

• 用「protocol author / framework maintainer / library contributor」這種軟體語言，不要亂扯成金融中介。
• 把治理、 custody、 software authorship 分開寫，別混在同一段。
• 如果有社群接管或去中心化移交，明確寫出時間點和控制權變化。

這樣做的目的不是裝清高，是讓外部的人一眼看懂：我們是寫程式的人，不是替每個使用者的行為背書的人。

市場結構清楚，投資人才會少一點神經質

“The legislation seeks to provide greater certainty regarding digital asset classification, regulatory jurisdiction, market structure oversight, compliance obligations, and developer liability.”

同一句話，換個角度看就是市場結構。這不是只有律師在意，投資人、交易所、基礎設施團隊都在意。因為規則一清楚，錢才知道要往哪裡走。

白話說，如果 VC 覺得一個專案的開發者不會突然被拉去背不該背的鍋，他們比較敢投；如果交易所知道自己面對的是什麼類型的資產和責任，他們比較敢接；如果工程團隊知道自己不是在做中介，他們比較敢 ship。

我看過太多 roadmap 被「先等等，法務還沒看完」卡死。這種卡法很貴，因為你不是少做一個功能而已，是整條產品線一起慢下來。最糟的是，等你終於搞懂規則時，市場早就跑掉了。

實操上，我會建議加一欄叫「regulatory dependency」：

• 每個功能旁邊標註它依賴哪個未決定的法律問題。
• 投資人簡報裡，直接講你的架構怎麼降低 custody 和 intermediary risk。
• 如果某功能要先等法律定義，明講，不要假裝只是排程問題。

這樣你才不會在內部會議一直鬼打牆，大家都以為自己在談產品，其實是在談風險。

責任要跟控制權綁，不要跟作者身分綁死

“Developers should not automatically inherit responsibility for how users interact with decentralized networks after software has been released.”

這句就是整場爭論最實際的地方。軟體一旦發出去，使用者會拿去做各種你沒預料的事，這很正常。問題是，法律到底要不要把這些後果全部算到作者頭上？如果答案是要，那沒人會想碰高風險基礎設施。

翻譯一下就是：作者身分，不該自動等於永久責任。你寫完、釋出、交出去，如果後面控制權已經不在你手上，責任就不該還黏著你不放。否則你做的不是開源，是替所有下游行為買無限保險。

我自己跟工程師聊這題時，最常看到的反應不是憤怒，是沉默。因為大家都知道這很不合理，但也知道現實裡不合理的東西常常真的會發生。於是團隊開始加一堆防火牆、權限、聲明，最後產品變得又重又醜。

實操上，團隊至少要記三件事：

• 哪一天開始，控制權從團隊移交給社群或協議？
• 誰還保有 admin key 或升級權？
• 哪些使用者行為不在你可控範圍內？

這些不是學術問題，是責任切割的證據。沒有這些，別人很容易把你寫成「其實還在控制一切」；有了這些，至少你有材料可以說明邊界。

可抄的模板

# Blockchain Team Policy Memo: Developer Protection Position for CLARITY-Style Rules

## Our role
We build and maintain [protocol / wallet / SDK / smart-contract tooling / infrastructure].
We do not operate as a broker, exchange, custodian, or discretionary intermediary.

## What we do not control
- user custody of assets after release
- market prices or trade execution
- discretionary approval of user transactions
- downstream user behavior on decentralized networks
- third-party deployments outside our direct control

## Risk boundaries to document
- digital asset classification
- regulatory jurisdiction
- market structure oversight
- compliance obligations
- developer liability
- admin and upgrade privileges

## Internal review checklist
1. Does any team member hold custody or discretionary control over user assets?
2. Does any feature require us to act like a regulated intermediary?
3. Could our README, website, or whitepaper be read as implying brokerage or custody?
4. When does operational control leave the team?
5. What governance process replaces that control?

## Documentation rules
- Use precise role language: builder, maintainer, operator, custodian, facilitator.
- Separate software authorship from financial service provision.
- Keep governance, custody, and code authorship in different sections.
- Record handoff points for decentralized deployments.

## Policy stance
We support clear legal distinctions between open-source software development and regulated financial intermediation.
Developers should not automatically inherit liability for downstream user behavior after software release.

## Copyable paragraph
We support legal clarity that distinguishes blockchain software development from brokerage, exchange, and custodial activity. Developers who publish software without taking custody of customer assets or exercising discretionary control over transactions should not automatically inherit liability for every downstream use of their code.

如果是我在公司裡推這件事，我會先拿上面這段當內部 memo，先讓工程、產品、法務三方對齊。不要一開始就想寫得很漂亮，先把邊界寫對比較重要。

原始來源是 Coinfunda 的 CLARITY Act 開發者保護整理，以及 Solana Institute 相關論述；我這篇是把它重組成台灣開發者比較好用的版本。法規脈絡如果要再往下追，我會連著看 House Financial Services Committee、SEC、還有 CFTC。