8th Nov 2020, 12:59 pm
8th Nov 2020, 12:59 pm
After getting more familiar with Stake-o-Matic and numerous research, we highly appreciate it and try to optimize it. The points below will reveal the new version we developed and explain our point of view.
The URL of our fork of stake-o-matic:
In the original version, Stake-o-Matic creates two stake accounts for every single validator in the list in the beginning. Because the delegation process only executes for non-delinquent ( baseline stake ) or qualified ( bonus stake ) validators, there will be many undelegated accounts caused, occupying resource inefficiently.
Therefore, we decided to create the stake accounts only for non-delinquent validators, instead of everyone.
In the original version, validators in the list will be assessed through reviewing their status such as skip rate to justify their qualities. If the validators became delinquent or did not match the criteria set in the script, their baseline / bonus accounts would be deactivated until their performances got improved.
Same as the issue mentioned above, the deactivated stake accounts occupy the resource but makes no profit. Hence, in our new design, the baseline / bonus accounts held by delinquent / unqualified validators will be withdrawn after the deactivation process is done if they are still delinquent / unqualified.
Besides, the delinquent validators will be removed from the list as well. Surely, these validators have the chance to regain the stake accounts, I’ll state it clearly in the next point.
“When someone leaves, it’s because someone else is about to arrive.”
To select new qualified validators which fill the absence caused by the removed validators, we created a filter to find the qualified validators by reviewing their commission rates, activated stake percentage, and skip rate.
Originally, cluster is used as an argument to run the script, which does not have the mechanism to exclude the delinquent validators, leading to the fact that a bunch of variable-quality validators exist (some of them are even delinquent). Due to the situation, there are many undelegated accounts, raising the difficulty of managing the stakes undoubtedly.
To solve the problem, we tried to select the qualified validators manually and add them into the list at the initiation. It worked successfully. However, it is not a decentralized method obviously.
So, the filter mentioned in paragraph 3 was born, which helps to select the initial validators with good quality. Meanwhile, management of the stakes becomes easier.
Clone from github and build it with cargo.
git clone https://github.com/forbole/solana
git checkout stake-o-matic/forbole
Then run it with command.
../target/debug/stake-o-matic <ADDRESS> <KEYPAIR> \
— quality-block-producer-percentage 75 \
— baseline-stake-amount 0.01 \
— bonus-stake-amount 0.05 \
— validator-list validator.yaml \
— validator-min-length 20 \
— stake-percentage-cap 5 \
— commission-cap 100 --confirm
The argument stake-percentage-cap and commission-cap are used in validator filter, and the validator-min-length is the minimum validator amount expected.
Almost all validators are setting their commission rate to 100% in the testnet, so please set commission-cap to 100.
Please ensure the keypair specified in the command is the withdraw authority.
The original design of Stake-o-Matic is for validators to redistribute their stake accounts. But we think this idea can be extended to all token holders. Imagine if there is a GUI tool running locally and shortlist validators by the filter function. Then it will help you reorganize the stake automatically and run periodically.
According to the current structure, every validator is delegated with two accounts, one for baseline and the other for bonus. However, it utilizes the filter to shortlist qualified validators in our design. Thus, these two accounts could be merged into one account, then managing the stakes would be much more efficiently.
The ideas are still in discussion. We look forward to implementing them in the next version.