以太坊:一文梳理无常损失保护的DeFi协议,具体效果如何?

原文作者:alertcat.eth,链捕手

无常损失是DeFi流动性提供者(LiquidityProvider)不可避免的风险之一。据Dune数据显示,去中心化交易所的每个月交易量已超过500亿美元,如何管理无常损失成为AMM协议的重大挑战。

本质上,无常损失是提供流动性时发生的暂时性资金损失。对于身为流动性提供者而言,当价格下跌时,不仅本金在亏损,同时还会被强迫加仓,越亏越多;反之价格上涨时被强迫减仓,少赚一些,这点跟网格交易有些相像。下图中给出了无常损失在ALT对于USD价格变化时的PnL和做空ALT对冲风险使波动率减少的对应数值。

在加密分析师charliemarketplace.eth于2022年12月24日发表的文章中,他分析了Uniswap上的WBTC-USDC和ETH-USDC的在2022年9月20日之前已平仓的交易,并对这些交易进行了发散损失分析。

在分析结果中,55%的ETH-USDC0.05%持仓损益超过了HODL。40%输给了HODL。这代表AMM模型的收益大于无常损失的风险。下图是组ETH-USDCLP相对于HODL的损益分析。

在分析结果中,即使是构建于Uniswap上的项目方的金库的损益的情况略比个人好一些,下图是

机构的持仓和个人的持仓的情况。

结论是Univ3LP对于普通人来说对抗HODL是可行的。从数量上来看,从提供流动性的过程中跑赢大盘的头寸数量比跑输大盘的多,但是有疯狂的巨型欧米茄输家扭曲了一切。单个头寸占所有头寸总损失的15%。

所以,少数的亏损者向我们描述了无常损失在构建投资组合时的尾部影响。

注:BTC市场是一个具有长记忆特征的多分形市场。通过使用一种以上的方法来计算Hurst指数,发现对数收益率系列在0.5302-0.6565之间,代表波动率的平方收益率系列在0.6876-0.9837之间。计算出的Hurst指数在0.5-1的范围内,证明了分形市场假设在BTC市场上是有效的,存在着长期的冲击持续性。分形市场假说假定在金融市场中,由于长期投资者在市场发生极端波动时趋向于转变为短期投机者跟风交易,从而导致波动率不服从正态分布,造成了金融市场的肥尾效应。

市场上存在若干种旨在降低或者减少无常损失的DeFi项目,下面试举例分析项目的可行性和鲁棒性,包括ClipperFinance、TarotFinance、TsunamiFinance、Deltadex、Vaderprotocol、Kryptonexchange、PlatypusFinance、Shieldex等协议。

首先是ClipperFinance,该项目以流动性的数额具有硬顶从而限制了参与人数而广受散户的诟病,下面就从项目白皮书的角度来解析其机制的可行性。

白皮书提出了两项基本假设:定义一是不变量是一个正的同质标量场,意义是:流动性的增加和删除是线性的,举例言之:在正同质性的情况下,两个流动性提供者各自负责池子一半的流动性的人将各自拥有池子的一半收益。定义二是价格排列不变量采用风险中性定价,每项资产的财富相等。就是LP对中两项资产的初始价值相等。

白皮书考虑了一个方程:

当k=0时,就是刚兑,曲率为零的情况,所有币都是恒价的,可以任意以1:x做交换,永远不会滑价。此模型称作恒定总量做市商(ConstantSumMarketMaker)。由于价格不会因供需而改变,因此当外部市场的稳定币间出现价差时,就会有人前来套利,直到其中一边的资金池枯竭为止,会使这些币种在池内失去流动性。

当k=1时就是Uniswap的方案,此模型称作恒定乘积做市商(ConstantProductMarketMaker),遵循xy=k的反比例函数模型,然而交易深度较浅,价格将会明显改变。此模型函数曲率过大,价格变化太快,因此我们需要更平滑的曲线。

Clipper的k取值介于0到1之间,这有点类似于curve,下图是curve的价格变化图。

下表是Clipper的交易大小对于滑点的影响。k取中间值可以减少套利者对于刚兑池的剥削,也可以减少交易者按照AMM的滑点,由于本身Clipper池子较小,按照总流动性的比例就只能承受较小规模的交易,取值为中间值可以较好地集中流动性。图中红线是Clipper,蓝线是刚兑模型,绿线是Uniswapv2模型。

由于Clipper采用了多资产的模型,它实际上是按比例分布的一种指数基金的初始分布。根据数学公式计算得出下图:绿线为HODL的损益结果,红线为Uniswap的损益,黑线为Clipper的损益,蓝线为刚兑模型的损益。

由此可见,Clipper的集中流动性以提高资本利用效率的架构使得小额交易的滑点降低了,但这一点是以增加了LP的无常损失为代价的,从数学上说,任何在0到1之间的k取值都会比Uniswapv2模型有更高的无常损失。

Clipper在减少流动性提供者的损失中也做出了一些努力,比如:通过限制池子规模造成大额交易较高的滑点减少有订单流和通过使用链下预言机以及其池中资产的比率来考虑外部市场价格来实现这一目标。这意味着,当市场变动时,Clipper会更新其价格,而无需套利流量来平衡池大小。套利者的低回报意味着LP的损失减少!它的机制有些类似于GLP,将一篮子代币打包组LP,然后通过集中流动性的数学曲线实现在较小的池子规模之下完成较少滑点的交易。然而这确实在数学上有更高的无常损失。而减少的套利者和有订单流能否弥补其损失应该具体问题具体分析了。

其次是TarotFinance,本质上是借方承担了杠杆的风险,然后贷方获得了一定的收益,减少了自己的无常损失,这个就是通用的杠杆挖矿模型,是一种形式上的风险转移.

TsunamiFinance,一个仍然在Aptos测试网上面的项目,这个项目的机制非常类似于Clipper,一篮子代币,然后从链下预言机获取价格,盈利来源是LP和交易者对.Tsunami提供汇集LP代币(TLP),通过蓝筹加密货币和稳定币的多样化将无常损失的风险降至最低(本质上只是和Clipper一样的机制),同时通过在swap费用之上产生杠杆交易费用来最大化回报.

Deltadex,一个期权平台,提出了对冲无常损失的方法是在自己的平台上买看跌期权.这不失为一种方法.但是不是从AMM本身的方向去解决无常损失,而是类似于一种保险.

NILprotocol暂时没有推出实质性的原型产品,可以期待下一步的产品。

Vaderprotocol本质上构造了一个准备金池,流动性提供者在遭受无常损失时能够从池子中获得补偿。它从运营中产生的部分费用为储备金提供资金,以提供永久损失保护,并允许铸造合成资产。发出的补偿在100天内从0线性增加到100%。代币经历了极为惨烈的死亡螺旋过程,证明了运营产生的费用无法补贴流动性提供者,机制虽然说得通,但是资不抵债。

Kryptonexchange是一个去中心化交易所,旨在通过自己打包一段时间的交易并执行的方法来尽可能地减少有订单流。因为这些有活动阻碍了有效的动态交易策略的实施,导致对系统性风险因素的次优暴露以及对特异性风险的不必要暴露。同样的,这种方法从某种程度上说减少了交易者的损失,但是仍然需要推出产品来经受时间的检验。

Shieldex是一个提供链上永续期权的平台,Shield使用oracle提供价格信息,最大限度地减少价格差异并减少套利交易者的机会,从而降低无常损失。机制和Clipper相似。

PlatypusFinance是一个允许用户提供单边流动性的平台。Platypus采用了债务模型而不是AMM,这是一种根据池子中剩余资产的数额来决定挤兑风险来决定流动性提供者能够赎回代币的数量。覆盖率所代表的,是某一种稳定币在Platypusfinance流动池中的资产负债率。Platypusfinance采用了单变量滑点函数代替不变曲线。当某一种稳定币的覆盖率高时,换出的交易滑点就会相当低;而当某一种稳定币的覆盖率低时,换出的交易滑点就会提高。

这种设计无疑是新颖的,它把无常损失巧妙地转移风险给了池子中的每一个存入者,当恐慌出逃时,先出逃的用户获得的资金较后出逃的用户获得的资金多。

因此,这种机制消除了无常损失,将原有的风险改变为退出流动性的风险。

该项目由三箭资本领投,公募轮价格0.1,目前已经破发。

因此,从无常损失保护的项目的分析中,我们可以看出无常损失的风险并不能通过链上机制的设计而良好的对冲。这些项目的宣传中都有减少或者没有无常损失风险,然而,这一赛道的鼻祖Bancor都因为自身代币的价值不足以补贴无常损失而宣布停止补贴,所以这些项目往往通过消除有订单流、使用链下预言机、使用打包交易等等方式来间接地减小交易者的损失。或者采用转移风险的方式使用自身代币补贴,使用新的机制构建单边池或者借贷池,将自己的风险转移给了交易对手方。

天行有常,不为尧存,不为桀亡。无常损失是一个难题,不可解,但存在优化的方法。无常损失是使用了AMM模型的数学规律,是一种特性,不应该以缺陷来定义,因为LP本质上在传统金融领域类比来看是一种"卖出永续跨期"的头寸。如图是其损益情况。

结论

这一类旨在无常损失保护项目的可行性和鲁棒性是相当有限的,他们在Web3领域使用了金融风险的转移策略,根据采用的金融工具不同,金融风险转移策略可以分为:

套期保值策略:套期保值策略主要是利用远期类合约来消除风险。

风险转嫁策略:主要利用保险和期权类合约将风险转嫁给其他人。

分散化策略:通过构造投资组合来减少总体风险。

这就是无常损失保护协议的本质,以风险的转移为基石构造的DeFi协议。

郑重声明: 本文版权归原作者所有, 转载文章仅为传播更多信息之目的, 如作者信息标记有误, 请第一时间联系我们修改或删除, 多谢。

链链资讯

[0:0ms0-3:914ms