rToken

reward-Token

rToken是Staker通过Staking合约Staking token后获得的有效凭证,比如Staking XTZ,用户可以获得rXTZ,Staking Atom,用户可以获得rAtom。rToken和Staking Token是1:1的数量关系,持有rToken可以获得Staking Token的激励,同时,rToken可以被当成Staking Token在市场上交易,交易后,奖励权和赎回权都会变更,由Staking 合约修改。

rToken没有数量限制,理论上等于接入PoS项目的Token总量,rToken被赎回时有销毁机制,总体上维持和Staking Token的统一。

rToken的作用

  • 获得Staking奖励

rToken是Staking Token的映射,Staking Token获得的Staking奖励将会发到rToken的持有人身上。赎回期间rToken会被锁定,也不再拥有奖励的权益。

  • 可交易

rToken可以被交易,交易后,其对应的激励权和赎回权都将变更。Stafi协议会推进在中心化交易所去中心化交易所上线rToken和对应Staking Token的交易对,为rToken提供交易流动性。

  • 可赎回

rToken是Staking Token唯一的赎回凭证,持有rToken的人可以向Staking合约发起赎回,赎回过程不再拥有激励的权益,同时rToken会被锁定,待Staking token在原链解锁后,发送回用户账户。

rToken和原token的映射保持

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

但是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的实际运营中,这套机制将得到进一步的检验和完善。