Hello,

First of all if you haven't already, please check out my proposal for blockchain development on hivedao: https://hivedao.com/proposals/97

This the kind of posts that I want to do now and then on chain to gather some feedback and ideas about features and ongoing hive core work.

So here's some history on RC delegations, it's a feature that was worked on over a few years by the steemit team, and was supposed to ship with the smt hard fork, I figured this was a very important feature to have asap and we shouldn't wait on smts to have it. The problem is that the code is quite different between the SMT branch (where smts are done) and the main branch (the one that powers the chain right now).

When the steemit team said "SMT development change almost every element of the chain" they weren't kidding. So the challenge was to extract the code and then adapt it to work without the rest of the SMT code. Which can be quite tricky as I had to dig up some changes that were made back in 2018.

Then I realized that there was some bugs, so I set out to fix them and finally I got a working proof of concept.

FYI: it won't go live for hf24 because we don't want such a big change in hf24 and also there's some discussions to be had and potentially modifications to be done depending on your feedback.

Here's currently how RC delegations work:

Pools

Each account got an RC pool in his account, anyone can delegate to any account pool, that RC won't be usable by the account, it's just a pool he can delegate RC from. (he can delegate to himself if he wishes).

RC slots

There is a notion of delegation slots, each account got 3 slots from which they can receive delegations. meaning they can receive rc from at most from 3 pools, also, each slot can only receive from a specific pool. If you are not "whitelisted" you can't delegate to an user.

By default:
Slot 1 is set to the account creator of the account, and only the account creator can change that slot
Slot 2 is set to the recovery account, and only the recovery account or a top witness can change that slot
Slot 3 is set to null, and the account can change that slot.

it may seem a bit odd how the user don't "own" 2/3 of his slots, but it's designed in order to offload the complexity (setting up slots etc) to power users (witnesses/account creators/recovery partners) instead of putting that burden on the user.

Most of the use cases for rc delegations are linked to account creation anyways, and that use case is handled by default, then there's games or other operation intensive applications and those could have a 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.

It's worth noting that if you change your slot, you lose your previous delegation on that slot.

Oversubscription

Pool work on an oversubscription model: (thanks @vandeberg for the explainer)

Let's say Alice delegates 100 RC to an RC Pool.
That pool can then delegates 30 RC to Bob, Carol, Dave, and Eugene.
There is a total of 120 RC delegated, but only 100 RC in the pool.

Is that a problem? No.The implementation allows each of the out delegations to use up to the delegation's worth of RC, but that is charged to the pool.

If Bob uses all 30 RC and no one else does, Bob will no longer have access to RC from the pool until his regenerates, even though to pool still has 70 RC available. However, if Bob, Carol, and Dave all use 30 RC, then Eugene will only be able to use 10 RC before he cannot access any more.

Although he has RC still available from the delegation, because the pool ran out of RC, Eugene does not have any to use.

This is useful for this use case: Large stake holder making many small delegations, such as Steemit delegating to new users via the faucet (back when that was a thing). Users will consume their RC, but because not all users are retained, this can be significantly over subscribed.

Another real life example:

• Alice delegates 50 rc to her pool
• Bob changes it slot 3 to Alice
• Alice delegates 30 RC from it's pool to Bob (Bob can now use the RC)
• Alice tries to delegate to Eve, but since she didn't set a slot to Alice, Alice cannot delegate RC to it

FAQ:

Will this affect the current hive power delegations ?

No it will stay the same

If I delegate hive power to someone then RC, which one is used ?

The RC used is in priority the account's own rc (hive power + delegated hive power), then if that's not enough, delegated RC is used.

It it possible to have to have multiple users contribute to the same pool ?

Yes.

How many pools can one account contribute to ?

40

To be clear an account can contribute to 40 pools, which will then be used to delegate RC to as many accounts as they want (way more than 40).

Let's say the same thing but with a soup analogy:
A user can contribute to 40 different pots, but each one of those pots can be used to feed as many people as he wants.

Does delegated RC regenerate like normal RC ?

Yes

Is it possible to Delegate from one pool to another ?

No

Feedback wanted

Now, question is, what do you think of that implementation ? Are there things you would change ? I am open to coding any changes. But keep in mind there are performance and complexity considerations to take into account (for instance that's why we don't have like 50 slots per account).

Some early feedback include allowing users to change all their slots if they want to, because a lot of slot 1 (account creator slot) would be blocked and never used since they are linked to the @steem account (including mine).

Questions ? Ask them below !

And again, please consider voting on my core development proposal here https://hivedao.com/proposals/97