不遵循Bancor 协议最基本条件 BM的新算法只是昙花一现
刚刚,BM发布了他的新稳定币设计:
https://medium.com/@bytemaster/high-liquidity-price-pegged-token-algorithm-d86d71188162 可戳阅读原文看原文。
文中BM首先反思了bitUSD,在他看来,bitUSD主要的问题是流动性不好,所以,他基于EOS设计新的稳定币(姑且叫做EUSD),首要考虑的也是如何解决流动性的问题。
与bitUSD一样,EUSD同样是通过抵押资产产生,只不过bitUSD的产生是抵押BTS,而EUSD的产生是基于抵押EOS,同样,这两种稳定币都是空方向多方提供的服务。
不同点在于:
bitUSD是人人可发行,人人可持有自己债仓,而EUSD的设计中,只有系统维护的一个全局债仓,这个债仓与Bancor 连接器直接关联,并且通过Bancor连接器向市场提供流动性。不仅如此,系统还基于喂价信息,对Bancor连接器中的EOS和EUSD余额进行管理,从而保证Bancor连接器提供的流动性的价格与市场一致,而这也正是保证EUSD锚定的基本逻辑。
BM还为EUSD设计了另外一种资产MMS,简单来说,有点象MKR,是为了给为稳定币做出贡献的人提供收益用的。
先看看EUSD的基本逻辑。
如上图,系统债仓设定的初始抵押率是400%,按此抵押率产生的EUSD和25%的抵押物EOS被放入Bancor连接器,这个连接器按照Bancor协议为市场提供EUSD流动性,价格也根据Bancor协议改变。
下面这段原文中的代码就是EUSD的锚定逻辑,简单地说,就是比较Bancor连接器中的SPOT价格与喂价,同时根据抵押率情况,采取增发或销毁EUSD,在excess collateral与连接器间转移EOS的措施来改变SPOT价格,使之与喂价一致。
但这段代码本身有一处问题。如标红处所示,“发行新EUSD到连接器”和“将excess EOS转移至连接器”这两种操作引起的SPOT价格变化一定是相反的,不可能都引起SPOT价格降低,我的判断是BM把标红处移动EOS的方向搞反了,应该按注释修改。
RR = Reserve Ratio = 4x
TC = Total Collateral and Excess Collateral
TUSD = Total USD in connector and Circulation
SPOT = Spot Price = ratio of Bancor connector balances
FEED = the feed price with allowed tolerance
if( SPOT > FEED )
if( TC > TUSD * RR * SPOT )
then gradually issue new USD to connector (lowering SPOT)
else if ( TC < TUSD * RR * SPOT )
then gradually move excess EOS into connector (lowering SPOT) ## 应改为 then gradually move EOS from connector to excess (lowering SPOT)
else if( SPOT < FEED )
if( excess collateral )
then gradually buy USD using excess collateral
and destroy it (raising SPOT)
else do nothing
这只是个很容易修改的小问题,真正的问题在于:
Bancor协议能被BM这么随心所欲地使用吗?
Bancor协议是一种确定发行资产的价格的协议,当一种新资产是基于抵押另一种旧资产发行的时候,那么根据一个确定的抵押率和新资产供应量,Bancor协议可以确定一个新资产价格,以这种价格向市场出售或回购新资产,Bancor协议可以保证,只要按照协议产生的价格来交易,那么资产发行主体(通常是一个智能合约)就可以使自身资产池中的两种资产一直保持固定的抵押率,而且,由设置的交易价差还可以盈利。
但Bancor协议的一个要点是,主体交易价格只由设定的抵押率和新资产供应量决定,不受其它因素影响。
而在EUSD的逻辑里,不但没有一个固定的EOS和EUSD的抵押率(Bancor意义的固定抵押率是指1EUSD=CW*1EOS,CW固定),而且又引入了新的影响价格的因素,那就是Bancor连接器中的EOS资产还随时可以增减,增减只为影响SPOT价格。
这就破坏了Bancor协议的基本条件,其结果是,资产发行主体根本无法保证通过交易保持收支平衡。由于市场上攻击者常有,亏损是高概率事件。
还有,单独一个全局债仓的设置也缺乏足够缓冲,使得黑天鹅事件发生的概率变高。
总之,这样的一个系统是难以持续运行的。