StaFi rToken contracts are fully non-custodial and open-source to guarantee the security of assets. The private keys of Staking Contracts are managed through the MPC (Multi-party Computing) Scheme operated by the special validators (SSV) on the StaFi chain. At present, StaFi's rToken has passed a lot of security audits conducted by third-party security audit institutions, security experts and Community Bug Bounty campaigns. So we believe that the contacts are perfectly reliable.
Still, it is irresponsible to say the users of StaFi rTokens face no risks when using the Derivatives. The risks may come from often-overlooked security vulnerabilities or business risks in the circulation process. StaFi is driven to mitigate the above risks and eliminate them entirely to the extent possible. Despite this, they may still exist.
rToken contracts are open source, so there may be undetected security vulnerabilities or bugs though StaFi has mitigated such risks in the following ways:
1.Third-party security audits, such as PeckShiled and CertiK, etc.
2.Assistant audit and advice from security experts of renowned DeFi protocols.
3.Multi-round Bug Bounty programs.
4.nternal safety testing before rollout.
5.Millions of dollars insurance purchased on insurance platforms such as Tidal.
rTokens can be traded on DEXes as a way for improving liquidity, but the AMM mechanism represented by Unsiwap may impair the prices of rTokens compared with the real exchange rate on-chain especially when the liquidity pool is not big enough.
At present, rETH Token has a liquidity pool of about USD 50 million on Curve, which can meet the liquidity needs of rETH Holders, and the oracle price of rETH/ETH on Curve is also very close to the on-chain exchange rate.
However, the liquidity of other rTokens, such as rDOT and rATOM, on Uniswap is still relatively weak. So there is a price gap between the DEX price and the real on-chain exchange rate. So StaFi will cooperate with DEXes such as Pancake and launch a liquidity incentive program to solve the liquidity problem of rDOT/rATOM on DEXes.
When rTokens like rETH/rDOT/rATOM are integrated into lending platforms, they may have the risks to be liquidated if the price of rToken fluctuates dramatically to meet the liquidation rules.
Since ETH2.0 does not support functions such as transfer and withdrawal at Phase 1, rETH holders can't redeem ETH tokens until ETH2.0 Phase 1.5 is launched. And the StaFi team is still not clear when Phase 1.5 will be launched, or how the Transfer/Withdraw module will be enabled.
All PoS tokens staked by users through rToken App are staked on respective PoS chains, and then delegated to the on-chain validators according to Staking Rewards Maximization Strategy(SRMS). Although StaFi's SRMS algorithm will consider the Original Validator's on-chain identity, self-staking rate, slash record, on-line rate, there is still no guarantee that the delegated validators will not be slashed, even if the probability is relatively low.
At present, StaFi can use the following methods to maximize the risk of being slashed:
The original validators of rETH need to stake 4ETH for each Node as a security deposit. If Slash occurs, the user's loss will be borne by the Validator. As for rDOT and rATOM, StaFi will select the one with a higher self-bond rate.
rToken contract will automatically nominate a group of best validators to diversify the risks. So even if a rare event causes a validator to be slashed, it will have limited impact on the user's funds.
StaFi will build a validator monitoring tool for each rToken to watch delegated validators’ performance. Once a slash event occurs, it automatically triggers the redelegation mechanism if the PoS chain supports redelegation like rATOM to minimize the loss. The slashed node will be blacklisted forever.
As rToken has been integrated by many DeFi protocols, including Curve, Yearn, Convex and so on, the rToken holders could also face the security risks when using rToken on these platforms.