Comment on page
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的统一。
- 获得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不具备的生息属性，原生token具备rToken不具备的纯Layer1安全保障；
但是rToken和SC中锁定的Staking Token是1：1等量的，一个rToken对应了一个原生Staking Token的赎回权。倘若这点发生动摇，则会动摇rToken的价值基础。
最可能破坏这种一对一映射关系的，就是发生在原链上的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的实际运营中，这套机制将得到进一步的检验和完善。
Last modified 3yr ago