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

撰文:卡咩;Middle

本篇我们谈谈 Staking Token 的风险管理。

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

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

系列回顾

Staking Contracts(1/3)|SC 合约的基本功能 >>

Staking Contracts(2/3)| 如何选择支持的项目 >>


往期文章

Token 估值模型 | 注意 ! 金融攻击|Staking 衍生品 | Staking 附加操作 | PoS 简史 | Staking 资产流动性 | 双倍 Staking 收益 |


关注 Stafi_Protocol,关注 Sta king Fi nance

Stafi.io

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

来源链接:mp.weixin.qq.com