NexusMutual一直是DeFi保险的龙头老大，而Cover则是获得AC加持的后起之秀，发展势头非常迅猛。在未来的发展过程中，谁会成为DeFi保险赛道的王者？本文从用户流程、通证模式、保险定价和资金池、运营数据等各方面对两个项目进行了比较。
用户流程
NXM系统中，“索赔评估者”是决定是否赔付的关键，若发生索赔，资金池下降会降低NXM价值。Cover中则采用社区投票，避免故意拒绝合理索赔的情况。
NexusMutual用户流程
NexusMutual的业务流程里面主要有三种用户角色，分别是风险评估者，保险购买者和索赔评估者。
风险评估者，经过评估以后判断某个合约的安全性比较好，就会把资金以NXM的形式质押。当有其他人购买这个合约保险的时候，就可以获取对应的保费收入；而当有索赔发生的时候，用质押的NXM会被用来支付对应的保险金额。
保险购买者需要选择投保的合约，币种，金额和日期，然后用NXM来支付保费。如果风险事件发生，用户需要提交索赔申请，由索赔评估者来评审，通过以后才能获得赔偿。
索赔评估者通过质押NXM来参与索赔的评估，需要达成>70%比例的“一致性“判断。如果评估者的评估结果和大家的“一致性”判断相同，那么评估者就获取一定激励；相反的话，收到的惩罚是质押的NXM会被锁定更久时间。如果大家的评估结果没有达到70%的一致性要求或者投票数量没有达到最小要求，那么就到升级到全体成员进行投票。
Cover用户流程
Cover业务流程主要有三种用户角色，保险提供人，保险购买者和做市商。
保险提供者如果判断某个合约的安全性比较好，将抵押品DAI存入铸造该合约的NOCLAIM/CLAIM令牌，并在市场上出售其CLAIM令牌。如果没有索赔发生，1个CLAIM最终价值为0，1个NOCLAIM价值为1DAI；如果索赔发生，1个CLAIM最终价值为1DAI，1个NOCLAIM价值为0.
保险购买者直接去Balance交易所购买对应合约的CLAIM令牌，风险事件发生以后，可以在Cover官网发起索赔申请，申请通过以后，就可以获取CLAIM数目相同的DAI。
流动性提供商将抵押品DAI存入铸造合约的NOCLAIM/CLAIM令牌，然后加上额外的DAI将NOCLAIM／DAI和CLAIM／DAI添加到Balance里面的流动性池子。
用户流程对比
相比NexusMutual，Cover没有索赔评估者的角色，因为Cover用了社区投票的方式。社区投票和索赔评估者投票相比，会更倾向于从项目长远利益出发，避免故意拒绝合理索赔的情况，因为Cover的价值和赔付是否发生没有关系；而索赔评估者持有的NXM的价值和资金池有关系，赔付发生以后，资金池下降，NXM的价值会下降，所以有一定动机去拒绝赔付合理索赔。
另外，Cover增加了流动性提供者的角色，这是因为Cover引入了NOCLAIM/CLAIM令牌，需要为他们提供流动性。流动性提供者会分享BAL交易费用，并且能获取Cover挖矿的收益，但是也会有无常损失的风险。根据Cover产品白皮书［2］，流动性提供者的无常损失最坏情况在12.5%左右。
通证模型
NXM代币基本上承接了NexusMutual项目的所有价值实现，其价格由项目资金池决定；而COVER代币的主要用途是项目治理，其价格与市场供需有关。?
NexusMutual通证
从上面的流程可以看到，NexusMutal的用户在风险评估，购买保险，索赔评估的流程都使用到了NXM，包括社区治理，用户也是通过NXM实现。NXM基本上承接了NexusMutual项目的所有价值实现。
NXM使用了连续通证模型ContinuousTokenModel，用户在官网购买和赎回NXM，并且价格是由项目资金情况计算出来的。
上面的图展示了随着项目资本金的增加，NXM的价格也会上升，关于计算的详细公式和解释，大家可以参考项目白皮书［1］。
采用连续通证模型之后，NXM的价格不再由供需情况决定，而是主要由项目的基本面来决定，这个有利于稳定NXM的价格。
Cover通证模型
Cover项目的通证COVER主要用途是项目治理，用户在购买保险和质押铸造的时候用的是DAI。COVER的价格和项目资金状况没有直接关系，主要由市场的供需价格确定。COVER第一年的Token供应是9万枚，第二年1万枚，以后每年减半。
上图展示了COVER在未来三年的释放计划
Cover项目除了COVERtoken以外，还有CLAIM和NONCLAIMtoken，不同的合约有不同的Token，这些Token在Balance里面可以自由交易。CLAIM和NONCLAIM的价格是由市场交易确定，反映的是合约的风险程度，如果市场认为某个合约风险升高，这个合约的CLAIM的价格就上升，NONCLAIM价格就下降；反之，这个合约的CLAIM的价格就下降，NONCLAIM价格就上升。
通证模型比较
NexusMutual用户购买保单以后，无法将保单转给其他人，而Cover通过引入CLAIM和NONCLAIMtoken，让用户购买的保单可以交易，提高了用户的产品体验，更容易让用户接受。另外，由于COVERtoken和项目资金状况没有直接关系，避免了1.3中提到的索赔评估者和保险购买人的潜在利益冲突问题。
保险定价和资金池模式
NexusMutual中资金池本质由所有被保合约共享；Cover系统中不同合约的理赔不会相互影响。
NexusMutual的定价和资金池模式
NexusMutual的合约保险定价由专门的计算公式确定［1］，主要有以下决定因素：合约质押的NXM数量，保险金额，保险时间。如果质押的NXM数目越多，保险金额越少，保险时间越短，那么保费就会越便宜。
保险资金池的资金来源主要是用户质押的NXM。当某个合约发生赔偿的时候，合约里面质押的NXM首先被销毁来支付赔偿。如果质押的NXM不能完全支付赔偿，那么资金池里面的其他资金用来做赔偿。所以，虽然用户针对不同的合约质押NXM，但是保险资金池本质上最终是所有合约共享的。
Cover的定价和资金池模式
Cover的保险定价反映在CLAIMtoken的价格，价格越低，保费就越低，而CLAIM的价格是由市场供需来决定的。
在COVER里面没有资金池的概念，而是用户之间的博弈来确定保费的高低。同时，由于每个合约的CLAIM／NONCLAIMtoken不一样，不同合约的理赔不会相互影响。
定价和资金池模式比较
NexusMutual的资金池里面如果资金不足，可能会出现用户无法购买保险的情况，这就会导致出现业务的可扩展性问题，用户有强烈需要购买保险却无法购买。而Cover的定价模型不会出现这样的情况，当用户购买保险需求增加的时候，会出现保险价格上涨，但是不会出现无法购买的情况。
合规框架
NexusMutual遵循英国金融互助协会相关规定，以合规化形式展开，用户需要做KYC才能使用。Cover不限制国家地区，也不收集用户的身份信息。
NexusMutual合规框架
NexusMutual在英国注册为自由互助社，每个成员按照法律规定有互助社相关比例的所有权和提供保证的义务。自由互助社在英国不是一个保险公司，而是成员相互提供保证的组织，所以不需要遵从英国所有的保险监管政策。目前NexusMutual只遵循英国金融互助协会的相关规定，并考虑成为其正式会员。
根据英国相关法律，NexusMutual可以向世界其他国家用户提供服务，但是其他国家也有当地的一些合规限制。在研究了不同国家和地区的法律之后，NexusMutual目前只对部分国家地区开发，并且需要对会员做KYC。
Cover合规框架
Cover官网信息没有显示Cover注册成为保险互助社或者类似机构，所以没有对成员进行KYC的要求。
合规框架比较
Cover因为不需要对成员进行KYC，同时也没有国家和地区的限制，所以获取客户方面肯定比NexusMutual更有优势。但是从长期发展的角度来说，NexusMutual一开始就以合规的方式开展业务，以后合规风险会比较小。
业务数据
下面的表格总结了NexusMutual和Cover目前的业务数据
NexusMutual目前保险合约数超Cover3倍，锁仓金额是Cover的近2倍，但是赔偿金额远不及Cover。
总结
NexusMutual可以看作是传统保险的区块链化，而Cover则可以认为是在区块链上面重新构造了保险。
Cover相对于NexusMutual的优势主要包括
项目扩展性：Cover没有使用传统保险的保费计算模式和资金池模式，而是让市场供需确定保费，使得项目发展不受资金池大小的限制
保单流动性：Cover保险单子可以自由交易，并且引入了流动性做市商
代币科学性：Cover只是轻量的治理币，它的价格和项目资金状况没有绑定在一起，减少了用户投票故意拒绝索赔的动机
当然，作为创新事物，Cover也会面临一些问题，比如挖矿流程复杂，币价波动比较大,覆盖协议比较少等问题，相信随着项目发展Cover会慢慢解决这些问题。
总的来说，NexusMutual可以看作是传统保险的区块链化，而Cover则可以认为是在区块链上面重新构造了保险。从业务颠覆和创新的角度来说，Cover更胜一筹。
保险是一个万亿美元的巨大市场，从目前的市值来看，Cover和NexusMutual还有几百上千倍的增长空间，我们期待着他们成长为真正的保险行业巨头。
参考文献
1.https://nexusmutual.io/assets/docs/nmx_white_paperv2_3.pdf
2.https://docs.coverprotocol.com/product/paper
微博：分布式金融DeFi
郑重声明： 本文版权归原作者所有， 转载文章仅为传播更多信息之目的， 如作者信息标记有误， 请第一时间联系我们修改或删除， 多谢。