脑洞大开：未来的算法保险究竟可以怎么玩？

去中心化保险的构想一直是区块链应用理想用例的经典例子之一。保险企业有动机尽可能长时间地拖延索赔，而由于这个过程几乎完全没有透明度，用户严重缺乏知情权，这导致整体的用户体验不佳。将这些保险流程放在链上的想法很具有吸引力：如果满足某些条件，可以通过编程方式立即支付保险索赔，且整个系统的状态始终对每个人保持完全透明。

例如，可以为自己的航班购买旅行保险，如果 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 应该做的事。