腦洞大開：未來的算法保險究竟可以怎麼玩？

算法保險不依賴於人工決策來進行賠付，爲鏈上金融產品開闢了設計空間。

撰文：@tuba，作者授權鏈聞發表該文章的中文版本
編譯：Perry Wang

去中心化保險的構想一直是區塊鏈應用理想用例的經典例子之一。保險企業有動機儘可能長時間地拖延索賠，而由於這個過程幾乎完全沒有透明度，用戶嚴重缺乏知情權，這導致整體的用戶體驗不佳。將這些保險流程放在鏈上的想法很具有吸引力：如果滿足某些條件，可以通過編程方式立即支付保險索賠，且整個系統的狀態始終對每個人保持完全透明。

例如，可以爲自己的航班購買旅行保險，如果 Google Flights 報告航班延誤，智能合約可以自動賠付。

多年來，人們嘗試了很多去中心化保險的項目，但沒有任何觸及現實世界的項目得到太多發展。

首先，對於在鏈上獲取可​​信賴數據存在很多擔憂，比如，智能合約可能被惡意輸入數據，告知發生了颶風，而實際上並沒有發生，那樣鏈上天氣保險市場就不怎麼好用了。其次，當前的以太坊 /DeFi 用戶通常不會在鏈上尋找車輛 / 家庭 / 旅行保險——他們正在尋找更加加密原生的項目。

智能合約保險

過去兩年 DeFi 取得爆炸式增長，單槍匹馬地恢復了市場對去中心化保險產品的需求。很多個人或基金在這些 DeFi 協議中投入大量資金，同時切實需要防範因智能合約遭攻擊而損失資金。因此，去年湧現了新一波去中心化保險協議，主要集中在智能合約保險。

多數這些項目傾向於沿着兩個主軸進行創新——支付機制和定價：

• 像 Nexus Mutual 這樣的項目依賴於一組人來確定智能合約是否真的被黑，由此決定是否應該予以賠付。
• Cozy Finance、Ante Finance 和 Risk Harbor 等其他項目則純粹依靠滿足特定的鏈上條件來確定是否應該進行賠付。

在定價軸一側，部分項目使用基於利用率的聯合曲線來爲保險定價。例如，根據這一保險市場的供求關係爲保險定價的一些公式。其他項目則依賴於人類專家團隊，根據協議未遭黑客攻擊的跟蹤記錄、審計等信息來確定協議保費的「公允」價值。

本文將重點介紹去中心化保險協議的賠付機制。

算法賠付

在傳統金融中，保險公司在支付索賠之前，需要有各種可信賴的中介來驗證是否發生了某些事件。而由於智能合約被黑純粹是鏈上事件，我們應該能夠在鏈上編寫程序，來確定其他鏈上事件是否真實發生——需要零信任假設。

作爲這一領域的建設者和投資者，我們應該始終關注區塊鏈所賦能的、傳統金融無法做到的新生事物。算法保險可能就是其中之一。

算法保險如何運轉？

考慮這些系統如何運轉的最簡單方法是，將它們視爲一個關於是否滿足智能合約中特定條件的預測市場。

例如，如果您在 Compound 合約上借出 USDC，您的 USDC 餘額應該隨着利息的累積而隨時間單向增加——如果突然您能提取的 USDC 少於您最初存入的金額，則可以推斷出智能合約遭遇了攻擊。由於可以可靠地在鏈上檢查這一情況，我們可以創建一個關於 getPricePerFullShare() > 1  的預測市場，看返回值是對（true）還是錯（false）。

因爲 Compound 從未被黑過，我們可以想象大多數人更願意選擇「true」一端，導致預測市場兩端的賠率相差懸殊。這種相差懸殊的賠率爲市場的「false」一端創造了有吸引力的機會—— Compound 一旦被黑，他們將獲得鉅額回報，就算沒發生被黑事件，他們損失的也只是少量資本。 您可以看到這開始看起來像一個保險市場，「false」一端的投注者向「true」一端投注者支付溢價，以獲得一旦預測市場出現有利自己的結果自己有機會獲得大筆收益的機會。

對於更復雜的 DeFi 協議，我們可能想要定義更復雜的支付條件，而不是簡單地檢查代幣存款是否與底層資產相匹配。例如，我們可以將多個條件組合在一起，例如 totalAssets() > x && getPricePerFullShare() > 1，甚至定義一個條件來檢查一段時間內的合約狀態，例如 totalAssets 在一個 10 分鐘的窗口內不得減少超過 50%，否則該條件將返回 true。

可編程金融的美妙之處在於，我們可以創建任意複雜的支付條件，因爲我們確信鏈上檢查會予以確定性地執行。此外，由於所有這些支付條件都是在鏈上定義的，我們總是可以知道市場何時支付，無論條件多麼複雜，而不可能通過法律「條款和條件」來混淆視聽和定義。

引導這些市場發展的一種方法，是讓核心團隊自己創建這些保險市場並做空——既作爲一種引導保險購買者流動性的方式，也表明對自己的代碼充滿信心。Ante 是一個專注於這一點的項目案例，試圖通過開發者對其項目編寫保險市場來獲得採用和普及。我們可以想象一個這樣的世界：不爲自己的協議進行投保的項目與未經審計的智能合約的項目一樣充斥着風險。

潛在的陷阱

當用戶購買智能合約保險時，他們只想在協議被黑時獲得資金保障。但是，可能很難通過代碼定義具體怎樣算是被黑。例如，流動性資金池的創建者移除所有流動性的經典「捲款跑路」，可能導致 LP 所持有的代幣價值歸零。這是一種被黑，還是用戶在 AMM 中提供流動性的意料之中結果？

這個問題的一個「解決方案」是簡單地讓自由市場決定哪些市場是各種協議的規範保險市場。例如，我們可以爲 Compound 創建兩個不同的保險市場：第一個在 cTokens 的提取價值無法達到 >1 底層資產時予以賠付；第二個在 cTokens 的提取價值無法達到 >0.5 底層資產時予以賠付。

我個人認爲，作爲 Compound 的「規範」保險市場，市場很可能會自然地圍繞兩者當中的一個逐漸聚斂，也許通過像 Compound 團隊爲其中之一倡導「謝林點」(Schelling point) 的方式實現——讓大部分流動性保持在一個市場中。

如果協議的複雜性很高，則其中哪個市場成爲協議的規範市場可能就不那麼「搶眼」了，但這種自由市場方法的假設前提是：市場會自行解決。

在這一模式中，您是具體哪個特定保險市場的買家或賣傢俱有很大的很大的影響。協議可能明顯（肉眼可見地）被黑，但您所下注的市場的支付條件可能並沒有被觸發。相反，如果協議中的邊緣情況導致賠付條件觸發，即使在協議沒有被黑的情況下，保險賣方也可能「不公平地」被迫賠付索賠。

因此，對具體賠付條件的準確溝通非常重要，這樣保險買家和賣家才能確切地知道他們簽署的是什麼。這主要是一個用戶體驗（UX ）挑戰，將賠付條件從代碼翻譯成文字，是一項不平凡的任務。 而團隊可能會試圖將保險兜售的風險混淆爲「無風險收益」以吸引總鎖倉價值（TVL），或者向買家吹噓其產品是包羅萬象的智能合約保險，以提高銷量。

不僅僅是保險

智能合約保險市場潛力巨大，但這一類協議也可用於創建服務投機者的奇異掉期衍生品市場。將支付條件從「決不應該發生」的事情更改爲「應該很少發生」的事情，讓尋找不對稱機會的投機者對其更感興趣。

可組合性還使得開發者可以以任意方式組合這些市場，例如，將用於在一個市場上出售保險的抵押品再抵押爲另一個市場的抵押品，讓一個資金池同時出售承保多個（理想情況是不存在相關性的）事物的保險。

來自保險市場兩端的這些代幣也應該可以與其他 DeFi 協議實現組合。一些可行的構思包括：

• Protected-cToken，將保險代幣 + cToken 打包成一個代幣
• 永續保險購買，合約可以不斷地從產生收益的資產中提取收益來支付保險費用
• 槓桿式保險銷售，用戶可以從其保險銷售頭寸中借款，以銷售更多保險併產生更多收益

算法保險爲引人矚目的鏈上金融產品開闢了設計空間，因爲它完全獨立，不依賴於人工決策來進行賠付。這種客觀性有助於開發者準確推斷保險市場提供的風險敞口，並可以在這些金融原語之上構建其他應用，而無需擔心人爲決策或信任——這正是 DeFi 應該做的事。

感謝 Miyuki 和 Emily 閱讀本文並予以反饋。