LOADING...
LOADING...
LOADING...
当前位置: 玩币族首页 > 行情分析 > James说6:我们真的理解去中心化抵押吗?

James说6:我们真的理解去中心化抵押吗?

2021-10-15 NEST爱好者 来源:区块链网络

任何事情,只要沾上去中心化,马上就变得不好说,说不好。司空见惯的抵押借贷、抵押操作也如此。传统的抵押很简单,你把一个有价资产抵给我,我借给你一些现金或者其它资产,到期了你还本付息,我给你抵押品,如果到期不还,我就有权处理或者拍卖掉你的抵押品。如果抵押物的价格是动态波动的,在价格变化的过程中,我有权要求你补充抵押,否则不一定要等到到期,我就可以处置你的抵押品。这个流程很简单,很清晰,大家都能接受。

但如果抵押操作是在链上,是以去中心化的方式进行,上面的过程马上就带来了问题:首先谁来完成抵押和借贷的匹配呢?其次,一旦价格发生变化,谁来完成保证金的追缴或者清算呢?我们最早构建了一个典型的匹配撮合借贷模型:p2p模型,借方和贷方将各自的需求写在合约里,然后发布在一个撮合平台上,一旦达成交易,贷款方就具备对抵押资产的条件清算权。这一模型看起来很合理,而且真的做到了完全去中心化,但是问题也随之而来,借贷存在着周期、利率抵押资产等多种变量,要实现匹配实在是太难了,对贷方而言,机会成本或者说再投资成本太高了,实际收益率就会很小,进而丧失了贷款的意愿,而另一方面,如果借款方长期找不到匹配的资金,也会撤出市场,导致整个规模进一步萎缩。

这是我们实践下来的经验。匹配撮合的难度,借贷双方的时间成本,让p2p匹配变得非常鸡肋,这也是早期大部分defi借贷做不起来的原因。于是大家开始寻找出路,一种方案是做一个高资金利用率的池子,一种是直接让借方抵押成某种稳定币,如大家见到的,前者是compound的模型,后者是makerdao的模型。这两种模型都保证的借贷的某一方先稳定的存在,然后再寻求交易的对手方:compound确保贷款方资金池充足,而makerdao则先制造了一个借款方的资产池,一个是投资导向,一个是借款导向。

在两种资金或资产池模型里,抵押价格波动带来的清算风险永远是第一位的。如果抵押资产的流动性是无穷大,价格永远有效,那无论怎样的抵押率,只要是抵押资产价值高于借款金额,永远不会有清算风险,你抵押率为60%(含息借款规模除以抵押价值)还是90%永远都是一样的。然而,现实世界里,流动性既不会无限大,价格也不一定一直有效,某种极端情况下,价格波动直接导致抵押资产价值低于借款规模,这就是所谓的穿仓:由于一切是去中心化的,你也无法通过锁定借款人要求其进行穿仓赔付,所以这种损失只能由贷方承担,这会增加了贷方挤兑或者踩踏的风险。另外,资金池模型里,清算无法由指定的人完成,因为这会导致某种信任风险:该清算而不清算造成更大的损失。因此,清算操作必须是去中心化的,这意味着谋者激励机制的设计,保证任意第三方都有动力去完成这个操作,在目前defi项目里,清算残值就是为了这个激励而设计。


前面也提到,如果贷方在池子里一直没有人借钱,会导致自己的综合收益率下降,这就是我们说的再投资风险:获得一段时间利息后,需要新的机会支付利息,而不是稳定的长期的收益。结合我们刚才讨论的清算风险和保险基金,在这个模型里,保险基金会因为部分抵押资产被清算而少了持续的稳定费或利息,这蕴含了一个不同清算时间的期限结构:清算越早,再投资风险越大,清算越晚,再投资风险越小。在给定的价格模型下,触碰清算的时间跟抵押率或者清算线有关,考虑到二者经常保持线性关系,我们就以抵押率来衡量触碰清算的时间构成:抵押率越高(注意是借款资产除以抵押资产),触碰清算的时间越短,抵押率越低,触碰清算的时间越久。这样抵押率构成了一个再投资风险的度量,这意味着保险费率的高低,可以基于抵押率进行一个设定,比如一个简单的方案是线性公式,当然,如果严格的讲,我们完全可以给出一个较为精确的公式。清算风险是一个典型的尾部风险,在compound和makerdao的设计里,是通过让所有人一起承担来解决这个问题,这会带来贷方风险的上升以及dai的内在价值不稳定(不再等于1美元)。像这种尾部风险,最好的解决办法是引入一种去中心化保险机制:大部分情况下,收取保险费,在遇到这种极端情况时,进行赔付,整个过程是去中心化的,任何人都可以成为保险基金的参与者,也可以在合适时机退出保险基金。保险基金相当于抵押操作者将尾部风险卖给了第三方,这能够保证贷方的安全或者dai的稳定。这一设计代表着部分的借款利息以及所谓的稳定费,应当支付给保险基金。考虑保险基金的规模是动态的,因此这里能够通过动态的保险规模确定市场的风险对价!提供了一个看待整个池子清算风险的指标。

这样,保险基金,抵押率相关的保险费率(在compound里是利率的一部分,在makerdao里是稳定费),构成了对去中心化抵押借贷或抵押稳定币的最基础风险管理方案,这一方案是基础的,原子化的。我们在未来会看到越来越多的抵押类项目要进行此类调整。

说完了一些风险,我们再来谈谈抵押的收益。抵押借出usdt和抵押生成dai,二者的风险虽然类似,但收益时有着天壤之别的。作为一个稳定资产的基础需求,无非是投资和消费(使用),线说说消费,很显然,链上接受度更高的是usdt,无论是融资,还是链上报价,还是dex的交易计价,都是usdt远远占据了上风,而在链外,中心化交易所直接将usdt设置为计价货币,而dai则很难得到同样的待遇,这里面原因是多方面的,包括共识的时间,包括规模扩张的难度等等。另外,如果进入法币世界,usdt有与美元1:1(近似)的货币储备进行兑付,而dai则必须通过交易成usdt或者某些场外的服务商将其兑成美元,这种转化的成本以及流动性规模,也是远远不如usdt的。因此,从纯粹的使用角度,抵押生成dai的需求变寄希望于链上各种项目方的合作,也就是大家所说的defi乐高的接纳程度了。这其实更多是我们要提到的第二个需求:投资需求。

由于dai本身是一种衍生品,没有任何特殊性,也即我们复制一张合约,生成一个dai2dai几乎是一样,而且,从博弈的角度,如果一开始抵押资产价格100,按照最大50%抵押率,抵押出了50个dai,当价格跌到80的时候,第二个人继续在dai的池子里抵押,可以抵押出40个dai,此时,每个抵押资产支撑了45dai,但如果第二个人复制一张dai的合约,按照同样的规则,抵押出dai2,这个时候,每个抵押资产支撑了40dai2,那么试问第三人,同样的资产,你是愿意按照1美元价格接受一个抵押资产支撑了45个的dai,还是接受一个抵押资产支撑了40个的dai2?没有其它额外的变量情况下,这种选择是毋庸置疑的,肯定是dai2了。那如果dai要吸引大家不在乎抵押支撑的规模,需要做什么?

可以想象,第一件事就是增加场外usd兑换,保证dai随时可以变成usd,这一路径其实是把dai当成了一个中间凭证,maker社区真正干的事usd的借贷或者usd的流动性提供。这件事想必所有的抵押稳定币都需要考虑的吧?其次则是想办法增加dai的应用,比如进入到各种挖矿以获得超额收益。很显然,为何别人允许你来获取这部分价值呢?可以用usdt的地方为何要你?这些问题完全取决于maker团队在和其它defi合约的发展中提供的价值,但这种价值肯定也是不稳定的,因为下游合约随时可以替换dai,甚至自己写一个dai2。今天看起来无比和谐的画面,其实是很脆弱的:一个系统总要有人提供价值,你什么都不干,就跑到另外一个系统攫取收益,这是不持久的。

因此,必须有一些基本的硬需求来支撑抵押稳定币的内在价值。单纯从maker社区角度,我们是看不到这种需求的,刚才提到,因为太容易被复制,缺少稀缺性,以及自增强属性,因此不能构成链上独一无二的资产。其次,社区内部并没有这种需求的原点:到底是什么项目需要dai,而且还非dai不可?这种问题在maker里是无法回答的,它不像usdt,规模做大了再复制也没法保证信用等级一致,而去信用的dai则完全一致。一个比较合理的想法是,抵押生成dai的抵押资产本身完成某种逻辑闭环必须需要dai,这样构成了基础性的供给需求关系:抵押资产——dai——抵押资产的产生。在这样的场景化的抵押稳定币逻辑里,我们只看到了parasset有这方面的考量:基于nest抵押的psudpeth本身在报价系统里被有效的使用,用来产生更多的nest或者nest报价,反过来,使用dai的话则没有这种相关性和依赖性,无法系统的降低nest生态矿工的资金压力和资产波动风险。而且,抵押越多nestpusd将被优先使用,这涉及到操纵和影响价格的难度,间接形成了自增强属性,而完全和eth产生隔离的maker则是一个简单的标准合约而已(复制一份也是一样)。

如果需求是一个个的同心圆,则抵押操作需要构建最底层的同心圆,特别是抵押稳定币,一定是来自于抵押资产本身的内在需求才能差异化于各种dai1,dai2并形成自增强属性,而这一稳定的需求提供了保险基金明确的保险费收益,从而形成需求和流动性原点,不需要项目方在场外进行otc服务(这本质是一种中心化的东西)。当这一底层同心圆形成,会逐渐扩散至生态内部一些项目的使用,比如交易、借贷和衍生品等,从而逐渐扩散至合作社区、一般社区以及链外市场。这些基本逻辑的基础决定了一个区块链项目的长期合理性,并在漫长的演化中不断获得有利信息。成功比较的是将来会有多少信息有利于它,而不是当前有多少噪音在追捧它,这一点我们深信不疑。


注:本文系个人观点,不构成任何投资建议,本文所有网图侵删。

—-

编译者/作者:NEST爱好者

玩币族申明:玩币族作为开放的资讯翻译/分享平台,所提供的所有资讯仅代表作者个人观点,与玩币族平台立场无关,且不构成任何投资理财建议。文章版权归原作者所有。

LOADING...
LOADING...