觀點｜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 代幣並為其提供流動性。