EU DeFi 審查把模糊變政策

我把 EU 的 DeFi 諮詢拆成可執行的合規檢查表，直接對照控制點、前端與治理集中度。

我盯 EU 這波 DeFi 諮詢一陣子了，越看越不對勁。不是因為它在問問題，問問題很正常；是它老想把一個本來就很髒、很散、很難一刀切的系統，硬塞進現成框架裡，還假裝答案很明白。

我看過太多團隊一開口就說自己「去中心化」，但一追下去，誰能改費率、誰能暫停、誰握著升級權、誰管前端、誰在導流，全部都冒出來。這些東西平常大家不愛講，因為講了就沒那麼像神話了。可偏偏監管最愛的就是這些細節。

這次我拆的是 The Rage 的 Pedro Solimano 報導，它把歐盟正在問的那套模糊標準講得很直白；再對照 MiCA 原文，你會發現 EU 其實是在找一個能把 DeFi 重新分類的抓手。

EU 不是在理解 DeFi，是在找可管的入口

歐盟執委會已經開了公眾諮詢，想看看要不要把原本沒碰到的 DeFi 也納進 MiCA 的範圍。

翻譯一下就是：EU 不想讓 DeFi 繼續躲在監管盲區。它不是先問「這東西本質是什麼」，而是先問「我能不能把它接進既有規則」。這是典型官僚打法，省事，但很容易把不該一起算的東西全算進去。

我之前跟產品團隊講這件事，大家最常回我一句就是「我們沒有中介啊」。聽起來很乾淨，實際上常常只是把中介藏到別的地方：前端、API、錢包、路由器、治理委託、升級多簽。你只要把流程畫出來，神話就會自己掉下來。

這篇報導真正重要的地方，不是它講了什麼新制度，而是它把 EU 的操作邏輯露出來了：只要服務沒有明確排除，就有機會被拉進來。這對那些以為「我不是交易所、我不是託管方、我就安全」的團隊來說，真的不是好消息。

實操上，我會先做一張「人類介入點地圖」：誰能部署、誰能升級、誰能暫停、誰能改參數、誰能控前端、誰能動 DNS、誰能看交易資料。這張圖如果畫不出來，後面所有合規討論都只是嘴砲。

「完全去中心化」這四個字太好用，所以監管一定會拆它

在現行 MiCA 架構下，只要是「以完全去中心化方式運作、且沒有任何中介」的服務，就被排除在 MiCA 之外。

這句話看起來像護身符，實際上問題超多。因為「完全去中心化」不是二元開關，而是一串控制面：技術控制、治理控制、營運控制、法律控制。你只要有一個面還握在人手上，整個敘事就會變得很脆。

我很常看到團隊把 DAO 投票當成去中心化證明。說真的，這種說法我聽到都會皺眉。投票上鏈，不代表權力就平均；代幣分散，不代表影響力就分散；社群很熱，不代表沒有少數人能拍板。監管不需要你完美，他只需要找到一個可以抓的控制點。

這也是為什麼我不愛聽「我們是 protocol，不是 company」這種話。你是不是公司，跟你是不是可被監管的服務，是兩件事。只要你有升級權、有暫停權、有門戶控制權，或者有一群人實際上能左右結果，EU 就會開始把你看成可管對象。

實操寫法很簡單：不要再用一個字講完你的系統。把它拆成四欄：誰部署、誰升級、誰暫停、誰改參數。再加一欄寫「最小可行控制群組」。這欄最重要，因為監管關心的不是理想狀態，是誰在現實裡能動手。

• 技術控制：升級、暫停、參數、預言機
• 治理控制：代幣集中度、委託權、投票門檻
• 營運控制：前端、API、DNS、Relayer
• 法律控制：基金會、公司、服務條款、合約關係

EU 的六個標準，其實是在問三件事

執委會正在向產業代表和公部門徵詢意見，想用六個標準判斷某個 DeFi 軟體是不是「不完全去中心化」，如果不是，就可能要被納管。

六個標準聽起來很多，拆開其實就三個問題：有沒有可識別的中介？有沒有技術控制？治理是不是集中？其他幾項多半是在補這三件事的空缺。EU 想知道的是：到底誰該負責。

這裡很像以前金融監管碰到新產品時的老套路。你不用證明自己多像傳統金融，你只要讓監管找得到一個「責任主體」，它就能往下推。DeFi 最麻煩的地方，就是它常常刻意把責任弄散，然後再說自己沒有中心。

報導裡提到 ECB 的研究也很刺眼。像 Aave、MakerDAO、Uniswap、Ampleforth 這些案例，前 100 大持幣者掌握超過 80% 投票權；Ampleforth 前 5 大持有人甚至快到 60%。這種數字一出來，很多「社群治理」的包裝就會瞬間變薄。

我自己看過不少治理設計，表面上是 token voting，實際上是少數 delegate 在輪流代理。這不是說它一定有問題，而是說你不能再用「上鏈」兩個字當遮羞布。上鏈不等於分散，DAO 不等於沒人管。

實操上，我會把這三件事做成一頁 memo：可識別中介、技術控制、治理集中。每一欄都填真名、真地址、真合約、真門檻。不要寫形容詞，寫事實。因為合規審查最討厭的就是形容詞。

• 可識別中介：公司、基金會、前端營運方、協議服務商
• 技術控制：admin key、多簽、pause 權、upgrade 權
• 治理集中：大戶、delegate、quorum、veto、緊急權限

前端不是皮，前端常常就是入口管制

諮詢也問：要不要要求 DeFi 協議認證、要求把連接用戶與 DeFi 的中介做盡職調查，甚至強制用區塊鏈分析去標記可疑資金流。

這段我最在意。因為如果我是做錢包、聚合器、DEX 前端，這就是最容易被從側門打進來的地方。EU 不一定要直接管合約，它只要先管「連接用戶的人」就夠了。

翻譯一下就是：你不用是協議本體，只要你在導流、篩選、排序、推薦、屏蔽、分析，你就可能被當成中介。很多團隊會說「我們只是顯示資料，不碰資金」。問題是，監管不一定在乎你有沒有碰資金，它在乎你有沒有影響用戶怎麼走進去。

我以前看過一個前端團隊很自豪地說，他們只是把合約渲染出來，沒有任何控制。結果一問，原來他們會預設路由、會封某些池、會做風險標籤、會把用戶推去特定資產。那就不是純展示了，那是在做導流決策。

區塊鏈分析也一樣。只要監管開始想把 analytics 變成義務，他其實就在假設有一層監控可以套上去。這對隱私友善設計很不友善，對基礎設施供應商也很麻煩，因為你會被要求證明「我有在看」。

實操寫法：把你的產品角色寫清楚，至少分成 publisher、router、broker、operator 四類。然後老實回答：你能不能封、能不能排、能不能推薦、能不能隱藏、能不能改預設路由。只要有其中一項，你就不是純靜態頁面。

控制權不是技術詞，是法律會拿來下刀的詞

美國有法官認定 Uniswap 確實是去中心化的，沒有對協議本身施加控制；但同一套法律脈絡下，Tornado Cash 的前端介面又被拿來討論是否存在控制力。

這件事很煩，但也很現實。法律裡的「控制」從來不是工程師以為的那種精確定義。你覺得自己是 immutable，不代表法官會照單全收；你覺得自己是 DAO，不代表別人會把你當成沒有操作者。

我一直覺得很多團隊太愛用 immutable 當盾牌。程式碼不容易改，不代表接入方式不會改；合約不容易改，不代表升級權不存在；前端不容易改，不代表營運方不存在。監管抓的往往不是你最喜歡講的那一層，而是它最容易證明控制的那一層。

報導裡提到的 ECB 數字，剛好把這個問題戳破。前 100 大持有人掌握超過 80% 投票權，這種結構要說完全分散，真的很難讓人信。很多時候，所謂的「社群治理」只是把權力包裝得比較不難看。

實操上，我會要求團隊自己先定義三句話：我們能改什麼、我們不能改什麼、少數人能在不經廣泛同意下改什麼。第三句最重要，也最常被跳過。因為真正有風險的，通常不是大家都知道的權力，而是那種平常沒人提、但一出事就能動的權力。

如果你要做 EU 風險判讀，先別問「我們算不算去中心化」。先問「誰能改變使用者結果」。這句話比任何白皮書標語都更接近監管語言。

先把風險地圖畫出來，別等法務來幫你補課

我會看這份諮詢，不是因為它已經把答案寫死，而是因為它逼大家先把控制面攤開。這很煩，但很有用。你不把系統畫清楚，最後一定是別人幫你解釋，而那個解釋通常不會對你比較友善。

報導提到回覆截止到 8 月 31 日，而且任何人都能交意見。這代表這不是只有布魯塞爾內圈才需要關心的事。做錢包、做協議、做治理工具、做基礎設施的人，都應該回去看：我們到底是怎麼被接入、怎麼被控制、怎麼被使用的。

實操上，我會先準備兩份東西：一份是架構圖，一份是政策立場。架構圖講事實，政策立場講你為什麼認為某些東西不該被算成中介、為什麼某些權限是有限的、為什麼治理集中不等於營運控制。不要混在一起寫，混在一起只會讓你自己也看不懂。

我也建議團隊老實面對弱點。你有升級 key，就寫。你前端能 censor，就寫。你 DAO 其實是 delegate 主導，就寫。監管通常不怕你誠實，怕的是你裝沒事。

實操寫法：指派三個人，各管一件事。第一個人盤點控制點，第二個人盤點用戶入口，第三個人把它翻成白話。然後拿 EU 的六個問題逐項對。只要有一題答不出來，那就是你真正該補的洞。

可抄的模板

# DeFi EU Control Memo / 合規控制備忘錄

## 1. 協議概覽
- 協議名稱：
- 主要合約：
- 主要前端：
- 支援鏈：
- 核心功能：交換 / 借貸 / 支付 / 託管 / 其他

## 2. 可識別中介
回答：
- 是否存在公司、基金會、DAO 實體、或任何提供 crypto-asset service 的人/組織？
- 若有，名稱是：
- 它提供什麼服務？
- 使用者哪個動作依賴它？

## 3. 技術控制
回答：
- 誰持有 admin keys？
- 誰能 pause 協議？
- 誰能 upgrade 合約？
- 誰能改 fee / parameter？
- 這些權限是單人、multisig、還是治理決議？
- 最小可行控制群組是誰？

## 4. 治理集中度
回答：
- 前幾大 token holder：
- 前幾大 delegate / voter：
- 投票權集中度：
- quorum 條件：
- veto 權：
- emergency 權限：
- 已知 delegate capture 風險：

## 5. 使用者入口層
回答：
- 誰 hosting frontend？
- 誰控制 DNS / deployment / API？
- 前端能不能 filter、block、route 使用者？
- 介面有沒有做 screening、analytics、transaction monitoring？
- wallet、aggregator、exchange 是否扮演 access intermediary？

## 6. 監管風險
回答：
- 若服務不屬於 fully decentralized，MiCA 是否可能適用？
- 是否可能需要 transaction monitoring？
- 是否可能需要 sanctions screening？
- 是否可能需要 reporting obligations？
- 是否可能需要 certification / licensing？
- 是否可能被要求使用 blockchain analytics？

## 7. 白話結論
用一段話回答：
- 誰控制什麼？
- 控制集中在哪裡？
- 哪些部分真的去中心化？
- 哪些部分不是？
- 若 EU 將其視為 regulated DeFi，會改變什麼？

## 8. 證據附件
附上：
- 合約地址
- Multisig signer
- Governance 文件
- Frontend ownership 記錄
- Treasury ownership 記錄
- Delegate 分布資料
- 任何公開宣稱去中心化的聲明

## 9. 內部行動項目
- 盤點所有控制點
- 檢查 frontend / operator 身分
- 檢查治理集中度
- 檢查 upgrade / pause 權限
- 準備 consultation response
- 更新風險揭露
- 決定 EU access 是否要調整

如果是我在帶團隊，我會把這份表控制在一頁半內，因為太長大家就不填了。重點不是寫一篇法律論文，重點是讓控制結構先浮出來，別等別人來幫你解讀。

這份模板可以當活文件用。只要 key 換了、delegate 變了、前端改了、治理規則變了，就更新一次。這種東西最怕放著不動，因為六個月前你寫的故事，常常已經跟現在的系統不是同一台了。

來源致謝：我主要拆的是 The Rage 的 Pedro Solimano 報導，並對照 MiCA 原文 和報導中提到的 European Central Bank working paper。上面的控制備忘錄與檢查表是我自己的整理，不是直接複製來源內容。