This is a good proposal to say the fact but the issue I have here is that of the account creator that is still linked to Steem Blockchain that would be affected at the long run. I thought Hive is hard fork of Steem, why can't we create code to deal with that, although I know this would be tedious. But it's a good idea, because any idea to make Hive Blockchain a better chain is a welcoming idea to me.👍

It's overall a step in the right direction, but when I'd first heard of RC Pools I guess I was envisioning something a bit more automated and elegant. I'd imagine RC Pools tied to certain transaction types as opposed to individual user accounts, if such a thing is even possible.

I know that most (all?) posts contain some form of metadata that defines where the activity originated, as far as application, front end, tool, etc. I don't know if that's also true of voting activities. I feel that RC Pools should be tied to *that* information, instead of linked between each individual user account, which seems to still be a nightmare when scaling to tens and hundreds of thousands of users or more.

As an example, if Bob is posting his daily Actifit update, the system first draws from his own personal RC as is the case in what you describe above, if his balance is insufficient, it then draws from the Actifit RC Pool instead. Then Bob swings over to PeakD and makes a comment on a piece of art he really likes in the OnChain Art community. This RC cost is then auto picked up by either PeakD or OnChain Art. As a new user, Bob's experience is seamless, no requests need to be made for RC delegations, and the RC costs are being levied on the applications he's actually using. Otherwise, Bob may sign up through eSteem, get an RC delegation, discover SplinterLands, and spend his allotment of eSteem's RC on playing SplinterLands.

In the sort of system I describe, the three pools would essentially be relegated to different hierarchies of user, application, and community... quite possibly in that order of fallback. Applications and communities would ideally be able to set their own "rate limiting," blacklist certain users, etc. to control spamming and abuse of their RC. Applications could feasibly set a limit on both individual users and communities. In the example given above, PeakD may allow only 1% of their RC pool to be used toward any one community, ensuring a single popular community can't drain all their resources and harm the user experience. Then it's the responsibility of the community to power up HIVE and backstop with their own RC Pool to keep their members active and happy.

Communities are already tied to a singular account at creation that could serve as the RC Pool, Applications would have to have an account designated as their RC resource. 

Whew. Hope that made some sort of logical sense.

Summation: Users should individually delegate into RC Pools of communities and applications that they want to support, but expenditure of RC Pools should be tied to transactions, not users, thereby removing the need to manage individual delegations across potentially millions of accounts. The minimal RC amount that all accounts are credited with at creation *should* be enough to ensure any new account can still make limited needed wallet transactions and other behaviors, while the heavy lifting of content creation and interactivity is automated on the backend and charged to the services being utilized.

> button to "ask for rc delegation" that would make the user set his personal slot to the game and then the app would delegate to it.

Does this mean that RC pool can not delegate RC to any account they wish to? First the user would have to set the right slot, yes?

What is the benefit to the account delegating the RC's ? Will it be just to support projects out of Goodwill or is there a Return on Investment? I's be happy to delegate either way, I'm just curious what the motivations would be.

Congratulations @howo! You have completed the following achievement on the Hive blockchain and have been rewarded with new badge(s) :

<table><tr><td><img src="https://images.hive.blog/60x70/http://hivebuzz.me/@howo/comments.png?202004301337"></td><td>You made more than 1500 comments. Your next target is to reach 2000 comments.</td></tr>
</table>

<sub>_You can view [your badges on your board](https://hivebuzz.me/@howo) and compare to others on the [Ranking](https://hivebuzz.me/ranking)_</sub>
<sub>_If you no longer want to receive notifications, reply to this comment with the word_ `STOP`</sub>



**Do not miss the last post from @hivebuzz:**
<table><tr><td><a href="https://peakd.com/hivebuzz/@hivebuzz/hivebuzz-hive-gamification-experience"><img src="https://images.hive.blog/64x128/https://i.imgur.com/3borgex.png"></a></td><td><a href="https://peakd.com/hivebuzz/@hivebuzz/hivebuzz-hive-gamification-experience">HiveBuzz - Hive Gamification Experience</a></td></tr></table>

###### [Vote for us as a witness](https://hivesigner.com/sign/account-witness-vote?witness=steemitboard&approve=1) to get one more badge and upvotes from us with more power!

I know I'm a little late to the party, but I'm wondering why this very complex system is necessary. I think a much simpler system would suffice for the majority of use-cases.

I can see why the current system doesn't suffice. If you delegate HP, you delegate RC _and_ voting power. This is a way of saying that you approve the actions of the user you delegated to. A large account creator can't check all actions of all their created accounts, so they can't trust them with their voting power. They do want to give the users enough ability to interact with the blockchain so they can start earning their power. That's where RC delegation comes in.

A probably much simpler way of implementing RC delegation would be to make it similar to HP delegations. You delegate a portion of your max RC to a single user. That user can use that RC to interact with the blockchain. Most required code can probably be reused from the HP delegation codebase. <sup>1</sup>

This simplistic version indeed doesn't cover all use-cases that RC pools cover. As a dapp who provides accounts, you can't use community delegations to proxy to your new users. There's also no 'oversubscription', so the max RC delegated to the dapp users will be a lot lower, possibly low enough to run out. <sup>2</sup>

On the other hand, this simpler system would allow every user to support any other user they want to support, without them spending an 'RC slot'. I have a mere 78 HP at the time of writing. That's not much voting power, but I never get below 80% RC. If I encounter a new user who brings great value to the blockchain, I am not in the position to delegate HP, but I would be willing to delegate some RC to them.

I believe that if we make it easy enough to delegate RC to others, there will be much less pressure on the account creator to provide the required kickstart RC. Instead, the community will be able to take care of most of it. The only problem that remains is blockchain games. Those systems usually don't promote new players to write posts and earn rewards before playing. That would require too much effort, so a dapp delegation is required. But I highly doubt that this single use-case justifies the complexity of this system.

<strong>Conclusion:</strong> I think this system is implemented to ease the life of large, singular entities, onboarding massive amounts of users while being irrelevant for small-medium accounts with sufficient RC. I believe that if we build a system that empowers everyone, small to large, to help out brand new users who make quality content, we can solve most problems those singular entities have while increasing decentralization, and decreasing complexity.

<em><sup>1</sup> I can't say with certainty that this is a simpler system to implement. I only assume it is because of its similarities to HP delegation. Please tell me if I'm wrong here.
<sup>2</sup> It is likely that I miss some use-cases. Some of them are not covered by the simpler system.</em>

This is litterally the first time Delegation Pools have been attemtped to be explained to most of us so bear with us/me as we ask some questions.

-------

It appears one account can contribute to 40 pools.
But one application can make as many accounts as they want so the number of pools to manage can be pretty infinite and hopefully automated. 

So how many users can share from a pool?

Also it appears from the 120RC delegated example with 4 users sharing from the pool that it seems like the limit is proportional? Because you said 30rc per user.

Does the pool limit per user have to be proportional? That sounds like RC was being set up to directly benefit the steemit system of allocating 15sp to each new user.

A non-proportional may lend to the apps (RC delegators) to be more attentive to RC abuse. Just not entirely sure of the reason for proportionality because so many users won't use their proportion allowing for lots more users to have RC but with proportional you kind of have to plan for the worst case user.

I think that one slot is enough anyway, why would you need delegations on two different slots? If you're a business that needs a lot of RC, then yeah, you might use the three slots but in this case, a business can easily deal with the complexity of that system. There is no need, to change the code too much if it is sound.

I just give an opinion because it was asked but I really think that you would have a better idea regarding what to do (along with other devs). 

Is there a particular reason for the quantity parameter to be 40? What not 50, what not 25? (Kinda seems like an odd number to me)