DeFi 崩盤時的清算怎麼少一點

這篇拆一個用 options 改寫抵押品行為的 DeFi 提案，目標是把崩盤時的連鎖清算壓下來。

我盯 DeFi 夠久了，最煩的就是那個熟悉節奏：平常一切都很像樣，文件寫得很滿，介面也很會講，然後市場一個急跌，整個系統開始瘋狂喊抵押率不足。清算機器人衝進來，倉位被掃掉，價格再被往下砸，大家又裝得很驚訝，好像這不是從設計第一天就埋好的。

我對這件事一直有怨氣。DeFi 很愛賣「資本效率」，但實際上很多系統只是把風險包成漂亮名詞，等著一次波動把它撕開。我做過借貸市場周邊，也看過 vault 在壓力測試裡瞬間失真，所謂健康倉位在流動性變薄時，會很快變成被迫出場的素材。

所以我看到 Vitalik Buterin 那類 synthetic asset / options 的設計討論又被拿出來講時，我是會停下來看的。不是因為它聽起來很潮，而是它碰到 DeFi 最討厭、也最常被假裝不存在的地方：崩盤時到底誰在替系統承擔壓力。這篇的觸發來源我主要是從 CryptoSlate 的 DeFi 頁面看到的；來源沒有給我什麼觀看數或書籤數，我就不亂編。

DeFi 真正會死，不是在順風局

“The Ethereum co-founder’s options-based synthetic asset proposal attacks a core DeFi failure mode: forced liquidation during crashes.”

這句話翻成白話，就是：這個提案不是在幫 DeFi 多賺一點，而是在讓它在壓力下不要那麼蠢。這個差別很重要，因為很多 DeFi 行銷都反過來，先講收益，再把風險塞到註腳裡。

強制清算會把一次價格下跌變成系統事件。抵押品一被重估，倉位就被砍；倉位一被砍，市場賣壓就上來；賣壓一上來，價格再掉，迴圈就自己轉起來。我看過這種事在借貸協議、合成資產、以及任何假設使用者永遠有足夠緩衝的系統裡發生。

這類 options-based synthetic 的有趣點在於，它不是只想讓風險消失，而是把風險形狀改掉。也就是說，系統不必每次都靠「快點補倉，不然就砍」來維持表面整齊，而是可以更明確地定義曝險。風險還在，但至少變得可讀。

我之前在測一個借貸原型的清算邏輯時就遇過這種差異。平常回測都很漂亮，一旦我把價格急跌跟淺流動性一起丟進去，系統不是優雅降級，而是直接抽搐。門檻一到，沒有中間檔，只有「好」跟「死」。

實操上我會這樣看：你在設計 DeFi 產品時，先別問「我們能開多大槓桿」，先問「如果市場一晚跌 20%，系統會怎樣」。如果答案只有「立刻清算」，那你做的是脆弱系統，不是金融基礎設施。

抵押品要會呼吸，不要像 Excel 格子一樣裝死

很多 DeFi 系統把抵押品當成靜態物件：存進去、鑄出來、然後祈禱。問題是市場不是靜態的，使用者也不是。波動一上來，這套模型就開始露餡，因為協議還在假裝抵押品會乖乖照表走。

我會在意這個 options-based 的原因，是它比較像把風險寫進機制裡，而不是假裝所有倉位都能撐過所有情況。這不叫魔法，這叫誠實。協議如果是要在壓力下繼續運作，而不是只在平盤時漂亮，那你就得承認市場會亂，不然就是自欺欺人。

我之前在做一個清算模擬時，最刺眼的不是數學錯，而是設計太單薄。只要價格滑動稍微快一點，清算線就像懸崖，沒有緩衝、沒有過渡、沒有第二次機會。那種設計看起來很乾淨，實際上很暴力。

所以我現在看 DeFi 設計，會先找中間狀態。不是健康就是清算，這種結構太粗了。真正能撐住壓力的系統，應該先降風險、再降曝險，最後才是清算，而不是一腳把使用者踹下去。

• 先做風險下降，不要一開始就清算。
• 把抵押品在壓力下的行為寫清楚。
• 要測急跌，不要只測平均波動。

實操上，我會在每個協議設計審查裡加一條：崩盤路徑 review。不要只看正常存取、oracle 更新、或平常的利率曲線。你要測的是流動性變薄、價格跳空、套利變慢時，系統還能不能活。如果不能，那就別急著上主網。

合成資產不是漂亮包裝，重點是能不能扛爛市況

大家喜歡 synthetic asset，因為它聽起來很優雅：不用直接持有底層，也能拿到曝險。聽起來很順，但優雅很便宜，真正值錢的是它在市場開始亂的時候，還能不能撐住。合成資產不是拿來做圖表好看的，它是拿來讓使用者拿到想要的曝險，同時不要把協議炸掉。

這也是這個提案值得看的地方。它不是把 synthetic 當成一個 token wrapper 而已，而是把它當成風險塑形工具。如果系統是 options-based，那協議就能更精準地定義義務與 payoff。對工程師來說，這比「我們有個很酷的包裝層」實際多了。

我看過太多 synthetic 系統只在牛市回測裡長得像樣。熊市一來，所有巧思都蒸發，合約照樣執行，但使用者體驗變成慢動作事故。沒爆不代表沒壞，只是壞得比較慢。

實操上，我會要求團隊先寫出「哪些壓力條件下，不該直接觸發強制清算」。先把這些條件列出來，再倒推設計。多數團隊剛好相反，先把 happy path 做漂亮，再補一個清算引擎。那樣做出來的產品，通常只在沒事時看起來有效率。

• 先用白話定義使用者到底拿到什麼曝險。
• 把每個壓力情境對應的協議反應寫下來。
• 把清算放在最後手段，不要當第一反應。

清算連鎖不是天災，是設計味道不對

我最想吐槽的一點是，很多人把 liquidation cascade 講得像自然法則，好像市場就是會這樣。但更常見的情況其實是：協議設計把市場波動放大了。對，市場會動；對，波動存在；但你怎麼把這個波動放大成一整串賣壓，這是你自己的選擇。

當系統太愛清算，它其實是在壓力下變成賣方。這不是中立，這是在火上加油。尤其當很多參與者都用類似抵押品時，清算會高度相關，然後整個下跌就開始自我餵食。

所以我覺得這類提案比一般「新收益產品」更值得看。它逼大家回到機制設計：系統在壓力下到底做什麼？是分段降風險，還是直接倒貨？是保住使用者一段時間，還是第一秒就把倉位砍爛？

實操上，我會把清算邏輯當成要被攻擊的地方來審。問自己：這個協議會不會自己創造賣壓？如果會，就想辦法讓它慢一點、分段一點、或直接換成沒那麼暴力的 unwind 方式。

還有，別把清算機器人預設成 feature。它只是工具。如果你的核心設計必須靠最快的 bot 才能活，那不是韌性，那是把弱點外包給誰跑得最快。

真正有價值的是使用者行為變乾淨，不只是數學變漂亮

這種設計最容易被忽略的地方，是它會改變使用者怎麼做決策。當協議能更清楚地表達風險、又不會在一個小波動就瞬間清算，使用者就有空間去再平衡、對沖、或退出，而不是被迫在最差時點做最差交易。

這很重要，因為大多數使用者不會用協議內部機制思考。他們只看結果：風險能不能控、曝險能不能懂、會不會突然被陰。你如果要他每小時盯一次抵押率，那你不是做了更好的金融產品，你是做了一個很會消耗人的流程。

我看過很多協議不是因為收益差而掉用戶，而是因為操作負擔太煩。人可以接受複雜，但前提是那個複雜看起來有意義；如果複雜只是陷阱，大家會直接走人。

實操上，我會要求產品的預設路徑不要是「使用者一直管風險」。如果市場一有風草動，使用者就得一直補救，那表示系統把太多工作丟回人身上，而且還丟得很粗暴。好產品應該吸收波動，不是把焦慮外包。

我會從這個提案偷走什麼

如果我把這個提案縮成一句我真的會拿去用的話，就是：別再做那種只會在市場已經壞掉之後，才開始懲罰使用者的 DeFi 系統。你要做的是更早表達風險、更清楚描述曝險、而且不要把系統設計成懸崖。

這不代表每個協議都要立刻變成 options-native。意思是，你的架構要承認崩盤不是例外，而是營運環境的一部分。你如果不能處理它，那就別說自己是可上線的金融系統。

我會給 builder 的實際建議很簡單：先設計爛情境，再回頭補正常情境。很多 DeFi 就是反過來，先把順風局做得很漂亮，等市場一兇，整個系統就露餡。這也是為什麼那麼多協議在平常看起來很專業，一出事就像紙糊的。

實操上，我會這樣排優先順序：

• 先模擬崩盤，再優化收益。
• 用分段風險下降，別只靠全有全無的清算。
• 把 synthetic exposure 寫成白話，不要只留給工程師看。
• 測整個系統的相關性壓力，不要只看單一倉位。

可抄的模板

# DeFi 崩盤韌性設計備忘錄

## 問題
我們目前的 DeFi 倉位模型，太依賴抵押品跌破門檻後的強制清算。當市場快速下跌時，這會製造額外賣壓、放大滑價，並可能引發連鎖清算。

## 目標
透過更早的風險塑形與更溫和的曝險調整，降低崩盤時的強制清算比例。

## 設計原則
- 把崩盤情境當成正常營運條件，不要當邊角案例。
- 優先使用分段降風險，而不是瞬間清算。
- 讓使用者曝險定義清楚、可以用白話解釋。
- 測試薄流動性、oracle 延遲、相關資產同跌時的行為。

## 上線前必答問題
- 如果資產在 1 小時內跌 20%，系統會怎樣？
- 如果同時流動性消失，會發生什麼事？
- 清算前的第一個反應是什麼？
- 系統能不能在不賣出的前提下降低曝險？
- 使用者會在哪裡收到清楚警告與控制權？

## 建置清單
- [ ] 列出所有清算觸發條件
- [ ] 模擬崩盤路徑
- [ ] 找出協議自己製造賣壓的地方
- [ ] 加入中間風險狀態
- [ ] 用白話文寫清楚使用者端行為

## 給產品/文件看的白話描述
這個協議的設計目標，是在市場快速下跌時，透過更早的曝險調整，降低崩盤期間的強制清算與被動賣出。

這段就是我會直接丟給團隊的版本。它不花俏，但會逼大家討論對的問題。

這篇拆解的原始觸發點來自 CryptoSlate 的 DeFi 內容，裡面帶到 Vitalik Buterin 對 options-based synthetic asset 的想法。上面這篇的判讀、整理方式和產品化改寫，都是我自己的拆法，不是原文逐字翻譯。

如果你想補背景，我也會順手看 Ethereum、Aave，還有 MakerDAO 這幾個地方的設計脈絡。它們不是同一套答案，但很適合拿來對照誰在真的處理風險，誰只是把風險包得比較好看。