You are viewing a single comment's thread from:
RE: Steem Basic Income, rShares, and Automation
Is there a limit on the backlog of upvote-amount on inactive users?
It probably would not be that good if suddenly a few 2-year inactive stat posting again and they are due the voting of a whole week of all accounts ;)
I have the same question. I've sent you (lennstar) an SBI share for raising the issue. I'd like to know if there's a cap on how much can be accumulated.
This is a good question. Originally we were dropping members that were inactive past 180 days. I do have the data in place in our back-end system to monitor for accounts that have been inactive for extended periods. Most likely we will 'tax' inactive users balances each month, so they would reach some equilibrium of their own where the new value received is just enough to cover the tax and their balances don't really grow past that point.
Was going to ask, if there is an maximum for the internal rshares balance.
But that sounds quite fair.
So it will be a "tax" (fee, whatever) above a specific threshold of rshares as a saturation function against 100%. It will function basically as a limit.
Will be interesting to hear at which amount the tax will start, how fast the tax will rise to 100% and what the limit ist. 👍
Once I define this we will make an announcement. It's not a critical function, so it will be in future development, not part of core automation. Most likely it would be 'when months inactive = n, where n is any whole number, then rshares_taxed = rshares * (n / 100)'
So basically at one month inactive, 1% of rshares are lost. At two months, 2% are lost, etc. until 100 months when rshares after the tax would be 0 and the member would be deleted. Eight years seems really like though. I will have to think about this more.
Here's a question that might be relevant someday. Will SBI be inheritable?
Posted using Partiko Android