觀點|DeFi 安全性事件保險:是投保還是投資?

隨著 DeFi 的火熱以及投資者、投機者的不斷加入,市場中存在的危機也不斷湧現。多次的 DeFi 攻擊事件讓用戶意識到,保險板塊也急需參與進 DeFi 「樂高」生態的搭建,提供給客戶可自主選擇的保障方式。
(前情提要:DeFi 項目頻遭「閃電貸」狙擊,保險能成為解方?Cover、Nsure、Nexus Mutual (NXM)

 

期海上貨運的高風險催生出了早期的保險協議,風險高收益高,實現風險轉移分散的同時也出現了新的投資機會。

隨著各個領域風險保障需求增加,保險產品不斷豐富。

DeFi 合約的風險性同樣促進了 DeFi 保險的發展。但相比於傳統保險有明確的保單持有人、保險人、保險標的, DeFi 保險更像是參與者對安全性事故是否發生的一次「賭注」,令其投資屬性甚至超過風險轉移屬性。

DeFi 安全事件頻發

隨著 DeFi 的火熱以及投資者、投機者的不斷加入,市場中存在的危機也不斷湧現。

今年以來, DeFi 協議被攻擊並導致財產損失事件頻發,閃電貸攻擊套利、協議漏洞攻擊、預言機操作攻擊等,都在影響著市場的穩定性以及市場參與者資產的安全性。

  • 2⽉,bZx 遭受來⾃利⽤閃電貸獲得資⾦的「攻擊者」通過操縱市場價格獲利達29 萬美⾦。
  • 6月,Balancer 遭遇閃電貸攻擊,被轉移了價值約 50 萬美元的資產。
  • 9月,bZx 內部的協議漏洞被攻擊,損失 800 萬美元。
  • 10月,Harvest 遭遇閃電貸攻擊損失 3,400 萬美元。
  • 11月,Pickle Finance 因漏洞造成損失近 2,000 萬美元。

多次的 DeFi 攻擊事件,程式碼審計已並不能代表項目的安全保證,項目方不斷完善協議以及機制安全性的同時,更高效與實際的保障措施也需要被採納。

作為傳統金融市場不可或缺的一部分,保險板塊也急需參與進 DeFi 「樂高」生態的搭建,提供給客戶可自主選擇的保障方式。

DeFi + 保險:不必持有「財產」也可進行投保

傳統保險產業中:

  • 保單持有人(Policyholder):購買保險以對保險標的進行投保的主體;
  • 保險人(I Nsure r/Underwriter):承擔保險保單的賠付責任的主體;
  • 承保(Underwriting):承擔規定的保險責任的行為,通常由保險公司擔任這個角色。

在 DeFi 保險項目中,項目方僅作為面向雙方的服務平台,保險人和保單持有人都由平台的用戶承擔,雙方根據交易的不同策略作區分。

DeFi 保險項目類似於傳統保險業中的財產保險。以財產作為保險標的,對標的資產可能發生的經濟損失進行保護;不同點在於,財產保險以房屋保險為例,保單持有人一般為房屋所有者或者使用者。

DeFi 保險項目中,大多數情況下參與者無需持有「標的資產」,即可購買相應保險產品並在遭受攻擊時申請賠付。

例如,用戶未參與 Pickle Finance 合約,但在 Cover 購買了 Pickle Finance 保險產品,賠付評估通過後可享有相應賠付。

Nexus Mutual 是目前承保金額最大的 DeFi 保險平台,截至 2020 年 12 月 15 日,總承保金額為 5,509 萬美元,提供 65 個項目的保險產品。

延伸閱讀:駭客幽默?DeFi 保險 Nexus Mutual 創辦人「錢包被駭820萬美元」,可以理賠嗎?

由於實體公司的要求,用戶需要填寫標準的 KYC / AML(Know Your Customer / Anti-Money Laundering)流程。Nexus Mutual 採用共保模式,與傳統共同保險公司類似,收集保單持有者資金,會員形成共同體以分擔風險,並共享保費收益。

用戶購買 Nexus Mutual 代幣 NXM 並成為其會員(Member),擁有治理投票權,通過質押 NXM 參與索賠的評估;購買 NXM 的資金注入資金池用於保險賠付。

因此 Nexus Mutual 並無明確的保險人進行擔保,所有成員(包括保單持有人)共同享有所有決定包括索賠評估的投票權同時承擔賠付責任。

共同體持有的資金量,即資金池(Capital Pool)用於保險賠付,資金池中資金一方面來自於保險人購買 NXM 資金的直接注入,另一方面保單持有人購買保單的資金的 50%將注入資金池。

Nexus Mutual 保單的價格(保費)模型根據風險成本(Risk Cost)、保險金額(Cover Amount,成功索賠時的賠付金額,即實際投保金額)以及保險期間(Cover Period)設計:

(Nexus Mutual 保費計算方法,source:TokenInsight)

保險產品的保費計算一般基於精算模型,綜合風險成本、保險公司經營銷售費用、產品的市場供求等多個因素。DeFi 保險項目如 Nexus Mutual 、 Nsure 採用了相對精簡的模型進行保費計算。

其中風險成本取決於歷史風險發生的概率,比如人壽保險會依據重大疾病經驗發生率進行覈算。由於 DeFi 發展時間較短、經驗案例數量不足,項目的安全事件發生概率較難進行核點計算,部分 DeFi 保險項目根據保險人對於項目安全的信心程度來計算風險成本。

保險人會選擇自己認為安全的項目進行質押,因此單個項目中被質押代幣數量越多,表明保險人對其信任程度更高,項目自身風險成本越低,保費就會更低。

Nexus Mutual 無明確保險人,但是所有成員可對其認為安全的特定項目質押 NXM 代幣。Nexus Mutual 單個項目的保單購買額度取決於該項目 NXM 質押量,隨著質押量增加,可購買額度增加;同時保費降低,購買量增加。

但是,當出現某個項目質押量不足或需求量過大時,用戶將面臨無保單可買的情況。

(項目質押量大於平均值情況下依舊無單可買,source: Nexus Mutual)

在接下來的發展方向規劃中, Nexus Mutual 也提出會在定價模型中加入需求因素。

今年的新項目 Nsure 則致力於打造去中心化勞合社(Lloyd’s of London),採用股份制方式,用戶通過質押 Nsure 代幣 NSURE 成為保險人,類似於傳統股份制保險公司的股東,並享有保險賠付後的利潤分配。

對於平台方來說股份制模式獲取資金方式相比共保模式靈活度更高。

Nsure 暫未上線,測試版中使用動態定價模型,根據需求規模、抵押規模和項目風險水平為不同的 DeFi 協議的保險產品定價。

相比 Nexus Mutual , Nsure 在定價模型中加入了需求因數,需求規模根據 DeFi 市場總鎖倉量(Total Value Locked,TVL)、預估自身市場佔有率以及保險滲透率進行估算,但該估算方法的有效性還有待檢驗。

總保額需求量 = 市場 TVL * Nsure 市場份額 * 保險滲透率

另一方面,目前各個項目均採用相同的市場份額(測試版中為 1%)以及保險滲透率(測試版中為8%),需求量只取決於保險標的項目的 TVL,當質押量較小時,TVL 的變化會導致保費以及保險人收益率的較大波動。

(傳統保險公司、 Nexus Mutual 、 Nsure 、Cover 運營模式對比;source:TokenInsight)

根植於 DeFi 生態的保險項目

相比於 Nexus Mutual 和 Nsure 更像是基於傳統保險公司運營模式、保費計算模型的平移,Cover Protocol 幾乎是從 DeFi 中誕生,通過去中心化的玩法為用戶提供一個分散風險的途徑,沒有保費計算模型,沒有賠付金額約定,完全通過資金池市場調節完成保險過程。

Cover 協議基於一個公式進行運營,每抵押一個 DAI,用戶獲得一個 CLAIM 和一個 NOCLAIM 兩個代幣:

1 CLAIM 代幣 + 1 NOCLAIM 代幣 ≈ 1 抵押品 (目前僅支持 DAI)

Cover協議的市場中有三類參與者,取決於其持幣情況, CLAIM 和 NOCLAIM可通過抵押DAI獲取,也可以直接在市場購買:

  • 做市商(Market Makers):持有 CLAIM 和 NOCLAIM 兩種代幣並在80/20 CLAIM/DAI and 98/2 NOCLAIM/DAI 兩個資金池提供流動性;
  • 保險提供者(Coverage Providers):僅持有 NOCLAIM 代幣並為其提供流動性;
  • 保險需求者(Coverage Seeker):僅持有 CLAIM 代幣並為其提供流動性。

(Cover運營機制,source:TokenInsight)

如果一個保險項目在保險期限內發生賠付,該項目所抵押 DAI 所對應的 NOCLAIM 價值歸零,CLAIM 價值約為 1 個 DAI 可用於贖回抵押品;如果到期未發生索賠或索賠失敗,對應 CLAIM 價值歸零,NOCLAIM 用於贖回抵押品。

(Cover protocol 兩種代幣對應價值,source:TokenInsight)

Cover 也允許部分付款。當協議損失總金額少於 Cover 中總鎖倉值時,將根據損失按比例分配給存款人,支付比率 x 將小於 100%。

CLAIM 代幣可贖回 x 抵押品,而 NOCLAIM 則可贖回(1-x)抵押品。

當然除了專門針對 DeFi protocol 的風險事件提供保險的項目,也出現一些利用 DeFi 提供的傳統保險標的的項目,如 Etherisc 通過開發 DApp 提供航班延誤、颶風保護、農作物保護等保險產品。

賠付難度較大,投資屬性更強

目前來說大多 DeFi 保險項目對於保障範圍做了詳細並較小的範圍劃分,僅支持由於智能合約本身的漏洞問題在遭受駭客攻擊時所帶來損失。

如 Nexus Mutual 明確規定:

① 指定的智能合約地址、或與智能合約系統直接相關的智能合約地址在保險期間內,遭受由於其智能合約代碼被意外使用導致的駭客攻擊;

② 由於駭客入侵,智能合約或智能合約系統遭受重大資金損失,資金被移至原所有者無法控制的其他地址、或使其永久無法恢復(重大:遠超過合約運營中 Gas 費相關成本;損失的金額至少為總承保金額的 20%);

③ 保單持有者在保險期間內或保險期間結束後的 35 天內提出索賠。

(Cover和 Nsure 索賠評估流程,source:Cover、 Nsure)

用戶支付索賠申請費主動發起索賠申請後,在同時滿足上述條件情況下,經過索賠評估,通過多步的評判與投票全部通過才可實現賠付。

項目方通過提高索賠申請費、設計多步索賠評估來防止虛假索賠事件、保障保險人權益,但另一方面也提高了保單持有人尋求賠付的難度與成本。

系統風險、個人操作失誤、預言機餵價錯誤、公鏈安全問題等造成的資金損失均不在這些 DeFi 保險項目的保障範圍內。

截至 2020 年 12 月 16 日, Nexus Mutual 上共發生 69 次索賠提案,只有 3 個關於今年年初 bZx 被攻擊事件中的索賠申請,在兩次評估後成功獲得賠付。

希望通過保險項目降低風險的用戶面臨著保障範圍狹小、損失來源確認困難問題。

另一方面部分保險項目中,由於保單持有人不需要證明對於標的資產的所有權,甚至不需要在購買前即明確自己希望在該保險進程中的扮演角色,可通過對於持有代幣的買賣來改變角色甚至跨多重角色。

因此我們認為,相比於傳統保險業保單持有人出自對可能發生的損失的擔心而進行保險購買,DeFi 保險更像是保險雙方對於保險期限內項目是否會發生安全問題的賭注,更多的是提供給用戶的一個投資途徑。

總結

12 月 14 日, Nexus Mutual 創辦人的個人地址被攻擊,37 萬個 NXM 被盜,保險項目真的保險嗎?

DeFi 保險項目如何真正為用戶提供財產安全保障,讓用戶有保險可買、有賠付可得,甚至如何保證自己的合約安全性,如保險項目間通過互助為彼此提供保險服務,都是需要進一步解決的問題。

同時隨著用戶量不斷增加、 DeFi 合約形式不斷拓展,如何滿足用戶的多維保險需求,針對不同類型的合約提供差異化的保險產品、面對大額賠付訂單時能否在減少保險人損失情況下進行賠付,相信未來會有項目帶來滿意的回答。

📍相關報導📍

DeFi|Origin Dollar「100%補償」閃電貸攻擊損失,保護基金與保險是大勢所趨?

DeFi子彈 2021 繼續飛!摩根史坦利高管:今年食物幣爆炸成長,明年被傳統金融採用


讓動區 Telegram 新聞頻道再次強大!!立即加入獲得第一手區塊鏈、加密貨幣新聞報導。

LINE 與 Messenger 不定期為大家服務

加入好友

加入好友