I feel that it is going to be difficult to delegate RCs to accounts that will need them as I don't think anyone will want to do that manually. Hope there will be something to address this
You are viewing a single comment's thread from:
I feel that it is going to be difficult to delegate RCs to accounts that will need them as I don't think anyone will want to do that manually. Hope there will be something to address this
It's not hard for any large stakeholder or app operator to do those delegations with a script/bot. I'm pretty sure some already do that with HP delegations.
what would be obviously useful would be if one could delegate RCs to e.g., (not) random accounts that are active and have less than 10 HP or so. Hope somebody will write a script like that.
There are already a number using things for HP delegations for the same purpose, they will just have to be re-jigged for RCs. I think where there is a lot of potential is through the curation accounts, where for example, @ocdb could delegate RCs to new onboards and use the HP to vote for value as they ramp up.
great, hope we get a manual/app for when its here
I am not sure if this is the way it will be or not, but is it possible for an account to give authority to delegate RCs?
For example, I delegate HP to a curation account like @ocdb and grant them the possibility to delegate that portion of my RCs to new onboards.
It might be too complex with undelegations etc...
As far as I remember posting key is required to set (or clear) RC delegation, so yes, it is possible. There were talks about introducing custom authorities that could be tied to specific operations or even types of custom_jsons, so when that is implemented you could allow some service to manage RC delegations for you while not giving it the authority to vote or post in your name.
That would be nice. I have always seen the possibility for there to be liquidity pools of RCs available for apps that could draw upon it. Similarly, there could be LPs for accounts also, where those in need can buy from the pool, distributing the HIVE to providers. These could be paired together also, where buying an account from the pool will also give it adequate RCs - and of course, three could be "hot seat" accounts that apps use where a user can function, but not own the account directly and when they log out and back in, they occupy another seat.
Again, perhaps too much complexity at this point, but thinking ahead for scalability, if there does happen to be millions of new users coming in.