Staking Contracts(3/3) | SC的资产风控框架

扫码链接5000+新基建产业链上下游从业者,入群请备注“机智地+姓名+公司+岗位

上一篇我们提到,Stafi在选择项目上,会对安全性有着重的考虑。然而依旧有一些因素会影响到SC所管理的Staking Token的安全,例如Slash机制和原链可能发生的安全事故。

尽管实际交易中,rToken和原生token有可能不等价。rToken和原生token虽然有锚定关系,但资产属性不同,rToken具有原生token不具备的生息属性,原生token具备rToken不具备的纯Layer1安全保障。



Staking Contracts(3/3) | SC的资产风控框架
但是rToken和SC中锁定的Staking Token是1:1等量的,一个rToken对应了一个原生Staking Token的赎回权。倘若这点发生动摇,则会动摇rToken的价值基础。

Slash风险

最可能破坏这种一对一映射关系的,就是发生在原链上的Slash.我们必然要通过某种机制,去恢复这种一对一映射关系。否则rToken对应的赎回权益将发生变化。

Stafi考虑过三种处理方案:

▶ 第一种,Staker承担Slash损失

本系列第一篇中提到,在派息时点,SC会和原链通讯,获取收益状况,并更新各账户rToken的数字。对于Slash的情况,也如实同步。这意味着持有rToken的用户,在每个派息时点之后,rToken数量会发生两种可能的变化,大多数时候发现自己的rToken变多,也偶尔会发现自己的rToken变少。

如果rToken变少,意味着上一个派系周期内,被Slash掉的金额大于收益。

需要注意的是,SC的派息是均一化处理的,如果Slash掉的金额大于收益,导致rToken减少,当前项目的每个Staker都会发现自己的rToken变少了。

这是最简单的处理方式,单纯考虑Stafi协议本身问题不大,但是对于基于rToken来研发衍生应用的开发者,会造成一定困扰,开发者不得不考虑rToken可能的减少,带来的连锁反应。


rToken最大的价值在于,可以作为Staking Finance中的基础资产,当rToken具备更加简单且相对稳定的金融属性时,会更利于衍生金融生态的繁荣。

▶ 第二种,由原链验证人来承担Slash损失

Slash的发生,往往是由于验证人的失误引起的,由验证人承担Slash损失更加符合情理,在SaaS市场中,甚至有一部分验证者提供Slash保赔服务,不让委托人承担Slash风险。

但让验证人承担损失,面临很大困难,且不说不一定所有验证人都提供保赔服务,就算对于提供保赔服务的验证者,赔付过程很难在链上执行,如果在链下执行,需要以中心化的方式介入,有很多不确定性,如果编写链上合约,则需要验证者抵押资产,作为赔付资金池。这会让大多数验证者望而却步。

▶ 第三种,通过保险机制来消化Slash损失

前两种方式都有各自的弊端,Stafi也在考虑一个更妥善的方式,那就是引入一个“保险者”的角色来解决Slash导致的rToken脱锚。可以建立一个保险互助池,在给Staker派息的时候,扣留一部分进入保险互助池,当Slash发生时,从互助池中转移支付,补足被Slash掉的金额,恢复rToken与原生token的锚定关系。或者由系统内角色,比如SSV承担保险任务,在给Staker派息的时候,扣留一部分保费,给到SSV。当发生Slash时,由SSV从自己的抵押的FIS中拿出一部分来购入原生token,补足因Slash而产生的亏空,SSV承担保险的好处是,SSV的抵押金起到了双重作用,既充当了处理多签账户资产的保证金,也充当了保险赔付池的功能,最大化了SSV抵押金的资产价值。

如果有成熟的第三方区块链保险提供方,Stafi也会考虑直接接入。

在结构设计上,Stafi倾向于将保险作为保险模块作为一个Stafi的流动性服务中不可分割的一部分。Staker在通过Stafi铸造rToken的时候,保险将不是一个可选项,而是必选项。这样做的最大好处是,保证rToken的同质性(即每个rToken都代表了完全相同的权益),便于流通。

一个设计合理的保险机制,能够应对绝大多数的Slash风险,但不得不说,任何保险机制都不可能是无限补偿的。我们不能排除,在原链上发生罕见的,反常的,超大额度的Slash。当发生这种情况时,在保险赔付的极限范围外,其余的将不得不按照上述第一种方式,由用户承担。当然,这种概率是极低的。 

验证者配额管理

补偿终究还是亡羊补牢的机制,我们也应该考虑到,用一套方法去降低Slash的风险,由于Slash风险主要出自验证者的不规范操作,所以最核心的是要做验证者配额管理,也就是说我们要给各个验证者分别委托多少个token。

第一,不把鸡蛋放在同一个篮子里,SC会尽可能分散的选择多个验证者,而不会把配额集中在单个或少数验证者手里,这样做降低了Slash发生时,所能带来的影响。

第二,当某验证人发生Slash时,SC会先紧急取消在该验证人名下的委托,以避免损失的扩大。与此同时,该验证人的配额将立马被调整为0,只有在该验证人平稳运行超过一定周期后,SC会逐步恢复该验证人的配额。

原链安全风险

我们还应该考虑到,可能导致多签账户里的Staking Token减少的,不止是Slash。

原链有可能因遭受攻击或者自身bug产生错误的交易数据,错误的交易数据本身可能导致多签账户里的Saking资产意外减少,另外,为了处理错误数据,原链项目方可能采取回滚的措施,回滚行为也有可能导致多签账户中的Staking资产意外减少。

面对这种风险,Slash风险小节中阐述过的保险机制是同样适用的。在一定范围内,由保险人承担损失,超出保险范围,Staker承担损失。

原链安全风险管理

对于原链安全风险,Stafi已经有一套很好的预防机制,就是在选择项目时,进行充分的考察,在本系列第二篇中有详细阐述。

当然,SC已经支持的项目,Stafi基金会也会不断更新每个项目的安全评级,当某个已支持的项目安全评级降低,不符合支持条件时,基金会将发起清退项目的动议,并通过治理投票来最终决定。

如果很不幸,SC已经支持的某个项目还是发生了安全事故,SC会启动应急降损机制,紧急强制赎回该项目的所有rToken,并临时封停对该项目的Staking支持,在风波平息后,通过治理投票决定,是否恢复Staking支持,以让Staker重新铸造rToken.

小结

以上这些措施,有预防,有降损,有补救,是一个相对周全的风控体系,在这样一个风控体系的保驾护航之下,rToken出现无法完全补救的,需要Staker来承担损失的情况的风险是极低的,rToken对原生token的锚定是极其牢固的。这将使得人们持有rToken的意愿度增加,也使得开发者基于rToken开发衍生品积极性增加。在Stafi的实际运营中,这套机制将得到进一步的检验和完善。 


声明: 本文由入驻基智地平台的作者撰写,观点仅代表作者本人,不代表基智地立场;基智地发布此信息的目的在于传播更多信息,与本站立场无关。

发表评论

邮箱地址不会被公开。 必填项已用*标注