rToken
reward-Token
rToken is a alternative token obtained by Staker through Staking contract, If you Staking XTZ, you can get rXTZ, Staking Atom, users can get rAtom. rToken and Staking Token are in a ratio 1:1. Holding rToken can get incentives from token staked. At the same time, rToken can be traded in the market instead of rToken. After the transaction, Staking contract will modify the reward and redemption rights.
There is no limit on the number of rTokens. Theoretically, it is equal to the total number of tokens that are integrated in PoS projects. When rTokens are redeemed, there is a burning mechanism, which basically maintains the unity with Staking Token.
In Stafi protocol, the specific roles of rToken are
1. Obtaining Staking Rewards
rToken is the mapping of Staking Token, and the Staking rewards obtained by Staking Token will be sent to the holders of rToken. During the redemption period, rToken will be locked and its rights obtain reward will be lost temporarily.
2. Trade
rToken can be traded. After the transaction, the corresponding motivation and redemption rights will be transferred accordingly. The Stafi Protocol will promote the listing of rToken and corresponding Staking Token trading pairs on centralized and decentralized exchanges to provide rToken with higher trading liquidity.
3. Redemption
rToken is the only redemption medium for Staking Token. rToken holders can initiate a redemption to the Staking contract. During the redemption process, the holder no longer has the motivation rights, and rToken will be locked. After the Staking token is unlocked on the original chain, it will be sent back to the user’s Account.
In the field transaction, there may be a price gap between rTokens and native tokens. Though rTokens and native tokens are pegged, they don’t share the same asset attributes. rTokens has interest-earning attributes that native tokens doesn’t have, while native tokens enjoy pure Layer1 safety control which rTokens lack.
However, the number of rTokens and Staking Tokens locked in SCs are of a fixed ratio of 1:1. 1 rToken represents the redemption right of 1 native Staking Token. This must be unshakable. If not, the value base of rToken will collapse.
Slash on the original chain is most likely to destroy the 1:1 mapping relationship between rTokens and native tokens. If that happens, we must resume their ratio through some mechanism or the redemption entitled by rToken will be shaky.
Stafi has come up with 3 proposals:
First, the Slash lost is buried by Stakers.
In the first article of this series I mentioned that, when the interests are distributed, SC will communicate with the original chain to inquire income and update the balance of rToken for each account. Slash will also be updated at that time. That is to say, rToken holders will find their balance of rToken added or cut when the interests distribution is over.
If rTokens become less, that means in the previous cycle, the amount that got Slashed is bigger than the earnings.
It should be noted that the distribution of SC is in a uniform manner. So, if the Slash is greater than the income, each and every Staker will find their rTokens decresed.
This is the simplest way. If we just consider Stafi Protocol, there’s no problem. However, it will cause trouble for developers who are making derivative applications based on rTokens, for they must take into consideration the chain effect caused by the decrease of rTokens. The biggest value of rTokens is that it is the fundamental asset of Staking Finance. When rToken is simple and stable enough, there will be a more flourishing derivatives finance.
Second, Slash is buired by validators on the original chain
In most cases, it is a careless validator who causes Slash, so it is reasonable for validators to bury the loss of Slash. In SaaS market, there’s even some validators who provide insurance for Slash.
But it is rather difficult to let validators bury the loss. Not all validators have Slash insurance, and even for those who do, the claim settlement is very difficult to be executed on the chain. If is is off-chain, there must be a centralized intervention, with many uncertainties lurk. If there is a Contract on the chain for Slash insurance, validators must stake their assets into the pool. That will intimidate most validators.
Third, Slash is offset by insurance mechanism
The drawbacks of first two methods are distinct. Stafi is also considering a more appropriate method, that is, to introduce an insurer role to solve the rToken unpegging caused by Slash. An insurance mutual aid pool will be established. When dividends are paid to Stakers, a portion of them will go into the insurance mutual aid pool. When Slash occurs, the punishment is buried from that pool, then the anchor relationship between rToken and the native token is restored. Another option is that someone in the system, such as SSVs, can undertake insurance tasks. When dividends are distributed to Stakers, a portion will be detained and given to SSVs. When Slash occurs, SSV takes a portion of its Stakng FIS to purchase native tokens to make up for the deficit caused by Slash. The benefit of SSVs as insurers is that SSV’s Stakes will act as both the margin of multi-sign account assets and an insurance compensation pool. In this way, the asset value of the SSV mortgage will be maximized.
If there are mature third-party blockchain insurance providers, Stafi will also consider direct access.
In terms of structural design, Stafi tends to use insurance as an insurance module as an integral part of Stafi’s liquidity services. When Staker mint rTokens through Stafi, insurance will not be optional but mandatory. The biggest advantage of this is to ensure the homogeneity of rToken (that is, each rToken represents the exact same rights and interests), which facilitates circulation.
A properly designed insurance mechanism can deal with the vast majority of Slash risks, but we must make clear that there’s no insurance with infinite compensations. We cannot rule out the occurrence of rare, abnormal or gigantic Slash on the original chain. When the Slash is beyond insurance’s compensation, the rest will have to be borne by users according to the first method above. Of course, this is a very rare case.
After all, compensation is still a follow-up mechanism. We should also introduce a set of methods to reduce the risk of Slash. Since the risk of Slash is mainly due to the irregular operations of a validator, it is important to have quota management in place for the validators. That is to say, to determine how many tokens should we delegate to each validator?
First, instead of putting all eggs in the same basket, SC will select as many validators as possible in a decentralized manner so that the quota will be held in hands of a single or a few validators. This reduces the impact of Slash.
Second, when Slash occurs to a validator, SC will first urgently cancel the delegation under the validator's name to avoid the expansion of losses. At the same time, the validator's quota will be adjusted to 0 immediately. Only after the validator runs stably for more than a certain period, SC will gradually restore the validator's quota.
We should also consider that it is not only Slash that may lead to a reduction in Staking Token in multi-sign accounts.
The original chain may generate erroneous transaction data due to attacks or its own bugs, which may lead to accidental reduction of the assets in the multi-sign account. In addition, in order to deal with the erroneous data, the original chain project may take measures to roll back, and rollback behavior may also lead to unexpected reduction of Staking assets in multi-signature accounts.
Faced with this risk, the insurance mechanism described in the Slash Risk section is also applicable. Within a certain range, the insurer bears the loss, and the exceeded will be born by Stakers.
As for the original chain security risks, Stafi already has a good preventive mechanism. That is a full screening investigation of projects. It is elaborated in the second article of this series.
Of course, for projects already supported by SC, the Stafi Foundation will also update the safety rating of each project regularly. When the safety rating of a supported project decreases and does not meet the support conditions, the Foundation will initiate a motion to liquidate. The final decision is made through governance voting.
If unfortunately, there is still a security incident in a project that SC has supported, SC will start an emergency loss reduction mechanism, forcibly redeeming all rTokens of the project, and temporarily suspending Staking support for the project. When the accident is over, Stafi will decide whether to resume Staking support to allow Staker to re-mint rToken by governance vote.
The above is set of measures including prevention, loss reduction, and remediation. It is a rather all-round risk control system. Under the escort of such a risk control system, it is extremely unlikely for rTokens to experience irreparable losses which needs to be born by Stakers. Moreover, the price-pegging between rTokens and native tokens is very tough. With this system in place, users will be more willing to hold rTokens, and developers will feel relieved to develop derivatives based on rToken. This system will be tested and optmized during Stafi’s daily operation in the future.
Last modified 2yr ago