上一篇我們提到，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的實際運營中，這套機制將得到進一步的檢驗和完善。