考虑这些系统如何运转的最简单方法是，将它们视为一个关于是否满足智能合约中特定条件的预测市场。

　　例如，如果您在 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 底层资产时予以赔付。 (责任编辑：admin)