Bible Network Crypto DeFi Onchain RWA AI Agent Stablecoin CryptoTax DeFAI Chain SAFU AGI Claude Me Claude Skill Claude Design Claude Cowork
獨立知識媒體
與任何項目無關聯
DeFi 協議底層運作全解析:AMM、借貸、收益與風險
defi-bible.com
最新
Uniswap 不再只是交易所:Earn 功能上線,你的閒置資產底層其實是 Morpho 金庫  ·  一筆 6540 萬美元的閃電貸,換來 600 萬美元的利潤:Summer.fi Lazy Summer 金庫被駭事件完整回顧  ·  協議說自己有九成流動性都是自己的,這句話該怎麼查證,不能只聽官方說法  ·  積分歸零那一天,你會後悔嗎?決定要不要衝一個積分計畫前,先問自己這個問題  ·  你手上的 WBTC,背後其實是一把三分之二的鑰匙:拆解包裝比特幣的完整信任結構  ·  跟你完全無關的協議被駭,你的存款為什麼還是縮水了:Kelp 到 Aave 的壞帳連鎖拆解
名詞解析 · amm-liquidity

Impermanent Loss Protection (ILP)

無常損失保護機制
amm-liquidity intermediate

30 秒版 · 給沒耐心的人
協議透過額外的資金來源(例如自己發行的原生代幣、或者協議自身的儲備資產),主動吸收流動性提供者原本該承擔的無常損失,讓提供者在提領資金時,能拿回接近或等同於單純持有這些資產、不放進資金池的價值,把原本前面文章介紹過的無常損失風險,從個別提供者身上轉移到協議整體承擔。
完整解說 +
01 · 這是什麼?

無常損失保護機制是什麼,跟前面介紹過的無常損失本身有什麼不同?

前面文章介紹過,無常損失指的是提供流動性期間,因為資金池裡兩種資產的相對價格出現變化,導致提領時拿回的資產總值,比單純持有這兩種資產不放進資金池,來得更低,這個落差是自動做市商機制本身數學結構下的必然結果,前面文章也明確提到,這個損失無法被完全消除,只能透過選擇波動性較低的資產配對去降低發生機率。無常損失保護機制想解決的正是這個「無法消除」的難題——不是改變 AMM 本身的定價公式,而是額外設計一套補償機制,在提供者實際提領、無常損失真正變成已實現損失的那一刻,由協議另外拿出資金,把這筆落差補回來。

跟無常損失本身最大的不同在於「誰承擔這筆損失」:無常損失是一個數學現象,原本由流動性提供者自己承擔;無常損失保護機制則是協議主動介入,把這筆原本該由個別提供者承擔的損失,轉移到協議整體身上,某種程度上是用「保險」的邏輯,讓提供者不需要再擔心無常損失,協議則需要另外準備資金池以外的資源,去支付這筆保險理賠。

02 · 為什麼存在?

無常損失保護機制為什麼會出現,想解決什麼結構性問題?

前面文章介紹過,無常損失是所有 AMM 流動性提供者都必須面對的固有風險,這個風險本身某種程度上限制了整體流動性挖礦生態系的參與意願——多數潛在的流動性提供者,尤其是不熟悉這套數學機制的一般用戶,面對「即使資產本身沒有下跌,依然可能因為兩種資產相對價格變化而承受實質損失」這個相對違反直覺的風險,可能會選擇完全不參與提供流動性,這對協議想吸引更多流動性深度的目標而言,是一個結構性的參與門檻。

無常損失保護機制想解決的正是這個「參與門檻過高」的問題:透過承諾提供者最終能拿回接近持有價值的保障,協議能有效降低流動性提供者對這個風險的疑慮,吸引原本因為不理解或不願承擔無常損失風險,而觀望不前的資金進場。這某種程度上是協議用自己的資源(通常是原生代幣的供給彈性或協議儲備),去換取更願意長期停留的流動性,是一種主動承擔風險以換取生態系參與度的策略選擇。

03 · 如何影響你的決策?

無常損失保護機制具體怎麼運作,資金來源是什麼,理賠條件通常怎麼設計?

以無常損失保護機制這個概念最具代表性的先驅協議之一的實作演進為例,典型設計包含幾個環節:

  1. 資金來源設計:協議通常不會另外募集一筆獨立的保險基金,而是透過協議自己發行的原生代幣(作為每個資金池裡的配對資產之一),搭配協議從交易手續費裡抽取的分潤,共同組成理賠資金的來源——某種程度上是前面文章介紹過的、協議自有流動性概念的一種延伸應用,協議自己也持續投入資金池,並用賺到的手續費去補貼無常損失
  2. 保護額度隨時間累積:早期版本的設計裡,保護額度不是提供者一存入資金就立即滿額生效,而是隨著資金持續留在池子裡的天數,逐步累積保護比例(例如每天累積 1%,經過 100 天達到 100% 完整保護),提早在保護額度還沒累積滿的階段就提領,只能拿到對應比例的部分理賠
  3. 提領時結算理賠:當提供者實際提領資金,協議會計算這段期間實際發生的無常損失金額,依照當下累積到的保護比例,把落差補回給提供者,確保提供者最終拿回的價值,盡可能接近單純持有這些資產的水準
  4. 機制持續演進:後續版本的設計,進一步把「需要等待天數才能累積滿額保護」這個限制拿掉,改成從存入資金的第一刻起,就立即提供 100% 的保護額度,不需要提供者承擔早期提領只能拿到部分理賠的風險

值得誠實補充的是,這套機制並非萬無一失——2022 年 6 月,市場經歷一波劇烈的整體性壓力,這套保護機制的先驅協議,曾經因為理賠壓力對協議自身財務穩定性造成威脅,暫時性地全面暫停了這項保護服務,這起事件具體示範了,無常損失保護機制本質上依然是協議承擔的一種或有負債,在極端市況下,協議自身的償付能力,依然可能成為這套保護機制能不能持續運作下去的關鍵瓶頸。

04 · 你該怎麼辦?

無常損失保護機制對一般用戶有什麼實際影響,該怎麼評估一個提供這類保護的協議是否真的可靠?

對想提供流動性、但特別擔憂無常損失風險的用戶而言,無常損失保護機制提供了一個具體的解決方案——理論上讓你能專注賺取交易手續費,不需要再擔心資產相對價格波動,對降低前面文章介紹過的、無常損失這個進入障礙,確實有實質幫助。但評估這類保護是否真的可靠時,幾個具體值得查證的面向:查證這套保護機制的資金來源具體是什麼,如果理賠資金完全依賴協議自己發行的代幣,這代表協議需要持續有足夠的代幣供給彈性或手續費收入去支撐理賠,一旦協議整體財務體質出問題,這套保護機制的可持續性,可能連帶受到影響;查證是否存在理賠額度隨時間累積的限制,如果你打算短期進出,提早提領可能只能拿到部分理賠,不是想像中的完整保護。

更重要的是,值得誠實理解一個核心事實:無常損失保護機制,本質上是協議承擔了一筆或有負債,不是真正把無常損失這個數學現象「消除」,而是把承擔損失的主體,從流動性提供者轉移到協議身上。前面文章介紹過的真實案例證明,在極端市況下,協議可能因為理賠壓力過大,選擇暫停這項保護服務,這代表這套機制提供的保障,某種程度上依然是協議在正常市況下才能兌現的承諾,不是絕對、任何情境下都能兌現的保證,評估時值得把這層有限性,一併納入考量,而不是單純假設「有保護機制,就等於完全沒有無常損失風險」。

實際例子 +

Bancor 是無常損失保護機制最具代表性的先驅協議,2020 年推出的 v2.1 版本首次引入這套機制,早期設計要求提供者連續存入資金滿 100 天,才能取得完整的保護額度,30 天內提領完全沒有理賠、31 到 99 天之間依比例部分理賠;後續 Bancor 3 版本則進一步改進,提供者從存入資金的第一刻起,就能立即取得 100% 的保護額度,不需要等待天數累積。但這套機制並非沒有極限——2022 年 6 月,加密貨幣市場經歷一波劇烈的整體性壓力,Bancor 官方表示這項保護機制已經對協議自身的財務穩定性構成威脅,因此暫時性地全面暫停了無常損失保護服務,這起事件成為這套機制設計時,值得參考的具體案例,示範了協議承擔的保護承諾,在極端市況下依然可能面臨無法兌現的現實限制。

常見誤解 +
✕ 誤解1
× 誤解:有無常損失保護機制的資金池,就等於完全消除了無常損失這個風險,實際是:這套機制本質上是協議承擔了一筆或有負債,把損失從提供者身上轉移到協議身上,不是真正從數學上消除無常損失,2022 年 6 月 Bancor 因極端市況暫停保護服務的案例,證明這個保障在特定情境下依然可能無法兌現
✕ 誤解2
× 誤解:所有無常損失保護機制的理賠額度,從存入資金那一刻起就立即滿額生效,實際是:部分早期設計要求提供者持續留在池子裡累積一段時間,才能取得完整保護額度,提早提領只能拿到部分理賠,具體條件因協議設計版本不同而有明顯差異,需要個別查證
這件事跟你有什麼關係 +
直接影響

優點是有效降低流動性提供者對無常損失風險的疑慮,理論上能吸引更多原本因為擔憂這個風險而觀望的資金參與,提升整體資金池深度;缺點是協議需要另外承擔理賠成本,這筆成本通常依賴協議代幣的供給彈性或手續費分潤,在極端市況下,理賠壓力可能反過來威脅協議自身的財務穩定性,2022 年 Bancor 暫停保護服務的案例證明,這套機制的可靠度,終究還是受限於協議自身的償付能力,不是絕對、任何情境下都能兌現的保證。

提問
請至少輸入 10 個字
更多相關主題