SIMD-0123: Block Revenue Distribution

[jstarry]

Delegated stake directly increases the number of blocks that a validator is allocated in an epoch leader schedule but the core protocol doesn't support diverting any of that extra revenue to stake delegators. This proposal introduces a way to set a commission for validator collected block fees and tips and then have the rest of the fees distributed to delegated stake accounts.

[jstarry]

cc @buffalu @t-nelson, thoughts on this direction?

It's a little difficult to work around the fact that nodes can have multiple vote accounts technically and that vote accounts can change node ids at will.

[diman-io]

Hello, I'm glad to see you looking in this direction.

I wrote my draft on this subject, see SIMD 119, but this one is undoubtedly superior.

I want to highlight that block fees are not the only amounts to be distributed. Validators collaborate with RPC pools, extract MEV from their blocks, and aim to compensate their stakers for the validators' downtime, among other things.
Therefore, it would be beneficial to have the ability to replenish a 'treasury' (for lack of a better term), which will be distributed among stakers.

Again, this would serve as a unified point for monitoring various dashboard sites (and stake pools) for validators' APY. Currently, the focus is solely on the commission percentage. However, as the methods of rewarding stakers evolve, I believe everyone will begin to operate with actual amounts. Thus, a straightforward and comprehensible algorithm for obtaining these data on-chain is essential.

[jstarry]

Thanks for chiming in @diman-io! I'm imagining that most fees including MEV tips will get accumulated into a single fee collection account for now but I'm interested to hear if there are use cases that require more flexibility. Looks like #109 will provide a convenient way to collect different types of fees into that account. Maybe it makes sense to track different types of fees/tips separately so that they can use different distribution methods but I think I would prefer to start with a simple solution that could be made more configurable in the future.

Can you also elaborate more on why using commission might not be flexible enough?

[diman-io]

#109 is limited in this respect: its essence is to obtain the current leader's dependent account, otherwise, the goal cannot be achieved: the leader is not known in advance, the account must be locked for writing, potentially this account is needed by all block transactions (except for vote transactions), which blocks parallelism - in general, all this cannot be solved in any other way.
And the main thing here is that this instruction is tightly linked to this transaction, its success, and the leader.

Why commissions are not enough. Validators can attract borrowed stake, compensating the loan fees from the block fee. Thus, the percentage from the block fee cannot be the same for all stakers (or it will add many restrictions).

About fee types. Yes, I've also thought about this for a long time. That's why in 119, I proposed several treasuries with different percentages. This adds flexibility in general. Is this necessary? I don't have a definitive answer. I don't think this will allow dashboards to track such revenues because if we move away from hardcoded typing and just allow validators to create multiple treasuries for one epoch, then for typed tracking to work, dashboards will have to know which treasury is of what type. Besides a textual description inside, I think nothing else can be invented. This rather gives validators the opportunity to keep their accounting on-chain, nothing more. On the other hand, it does not accuse the validator of anything, and he can still use off-chain calculation and himself fund the treasuries for the total amount to be distributed.

After much contemplation, I've concluded that all this breaks down into two parts:

1. Accumulation of additional amounts
2. Distribution of these amounts among stakers

Part 1) is strongly associated with business processes, financial schemes within the validator's business, so it's hard to program all variants.

But part 2) is clear and, as it seems to me, there are no disagreements among everyone about it.

Moreover, part 2) immediately allows all dashboard sites to see the real profitability of the validator for stakers (i.e., the element that is very important for validators in their competitive fight for stakers)

Returning to 109, honestly, I would go a different way: I would provide for the vote account 4 accounts: an account for paying for voting, an account for collecting base fees, an account for collecting priority fees, and an account for collecting tips (although personally, I don't like this name, I would prefer success fee or something like that).

And then I would leave it up to the validator's discretion to transfer these fees into treasuries for distribution by the program from part 2).

This will give flexibility to the validator in managing these amounts.
And put them on par with other amounts that he wants to distribute among his stakers.

The only issue that exists for me here is that the transfer might not occur in the current epoch, but in the next one. This bothers me from the standpoint of an ideal world scenario. On the other hand, looking at it as a business and in terms of attracting/retaining stake, transferring in the next epoch for the current one (meaning the staker will receive the amounts one epoch later), will retain stakers (because they will not receive additional amounts for the deactivation epoch - these accruals will happen after). So, overall from a business perspective, this is not a problem. And the validator is able to minimize it in the last few blocks of the epoch.

I hope I was able to answer your questions. Structured presentation is not my strongest skill.

[diman-io]

So, speaking about 109, I'm more inclined towards some analogy of the ComputeBudgetProgram, but the fee collection would only occur if the transaction is successful.
If such amounts are to be allocated to a separate account, then it logically makes sense to do this for priority fees as well. That is, to do this uniformly for all types of fees.
The same applies to the distribution among stakers. Here, I lean towards not distributing automatically because it imposes restrictions on the validator's business on one hand, and on the other, it simply moves this to an off-chain level (the emergence of such solutions is just a matter of time).

UPD. I'm not a proponent of 109 at all. In my opinion, validators will eventually concentrate MEV extraction in their own hands.

[t-nelson]

see #109

[jstarry]

see #109

I did, what's your point? Did you even read this SIMD to know how it's different from #109?

[t-nelson]

see #109

I did, what's your point? Did you even read this SIMD to know how it's different from #109?

in the discussion of #109, we come to the conclusion that we can basically have arbitrary, leader-defined distributions by implementing two much simpler things.

1. a syscall/instruction that credits the leader's collector account
2. allow for vote accounts to specify a collector account independent from the current authorized voter or w/e today.

with these two things, a validator operators can set their collector to a program-controlled account and define distribution in any way they please. this creates a new competitive opportunity

[jstarry]

Great, my understanding was that #109 aims to solve the first simple thing (adding the syscall or instruction to credit the leader's collector account) so I think we're on the same page for that part.

This SIMD aims to tackle the distribution part by allowing validators to create an independent collector account. I'm hopeful that we can have a discussion here about how to implement this in a flexible way without adding too much complexity. But as I mentioned above, there's a sticking point on using the vote account as you suggested because there's technically a one-to-many relationship of validator node id accounts to the vote account.

Currently the collector account for a leader's bank comes from the node id, not the authorized voter key. When calculating the leader schedule we accumulate all the delegated stake for vote accounts and then accumulate all the vote stake according to each vote account's node id.

Since we can't map from node id to a unique vote account, we can't lookup a validator defined collector account saved in vote state. That's why I created this proposal to allow validators to collect fees into a custom collector account which is derived from their node id. This proposal defines an opinionated distribution mechanism which piggy backs on stake reward distribution to distribute fees to delegated stakers.

[t-nelson]

my contention is that the distribution mechanism need not be fixed by, nor imposed upon the protocol.

Since we can't map from node id to a unique vote account

what prevents this?

[diman-io]

Currently the collector account for a leader's bank comes from the node id, not the authorized voter key.

Is that so? I mean, I assume that this is exactly how it's implemented in the code of the validator creating the block (because before this, the right to create a block is checked under other conditions).
I always thought it was the validator identity, not the authorized voter. And I always believed that this public key is also used when validating the block (that it's to this key that the fees go in rewards). In other words, there isn't currently an easy way to change the fee collector account.

UPD. I think you meant not the node id as such (which is broadcast in gossip). Regarding validator identity/authorized voter: I can look into this myself, there's no need to spend time on explanations.

[diman-io]

what prevents this?

I assume that there might exist two vote accounts with the same validator identity/authorized voter.

But I really like the idea of a separate instruction/syscall.

[t-nelson]

there was more discussion around simd 109 alternatives on discord. i think there was some discussion on the topic prior to 109 being created as well, but i can't seem to find it at the moment. cc/ @buffalu

[jstarry]

my contention is that the distribution mechanism need not be fixed by, nor imposed upon the protocol.

Ok, understood. Seems like most people are in agreement so I'll revise that part. I think it's still useful to allow fees to be distributed to stakers if desired but that might be better suited for an amendment.

Since we can't map from node id to a unique vote account

what prevents this?

I've said multiple times now...

But as I mentioned above, there's a sticking point on using the vote account as you suggested because there's technically a one-to-many relationship of validator node id accounts to the vote account.

The protocol allows multiple vote accounts to set their node keys to the same validator node id.

[michaelh-laine]

Would it make sense to rethink the linking of leader to node identity and rather make it linked to the vote account? The right to produce a block is conveyed directly by the active stake of the vote account. Block rewards could accrue through the epoch in a "suspense account" and be distributed with staking rewards, with a singular commission applied (let's also support non-integer commission values while we're at it?)? This also accomplishes the distribution of block fees as staked SOL with compounding and possibly helps economic security in that a leader who stuffs their own blocks won't immediately receive back their full priority fee (if SIMD-0096 passed) and half the base fee, but rather has to wait until epoch N+2 (given stake cooldown)

[jstarry]

Would it make sense to rethink the linking of leader to node identity and rather make it linked to the vote account? The right to produce a block is conveyed directly by the active stake of the vote account.

Yeah, definitely worth exploring.

[cyptofan]

Hey guys. What's the current status of this development?

[michaelh-laine]

Just thinking about this and reading through the comments above, I'm thinking about the actual distribution mechanism and the impact this would have on the network.

With the number of stake accounts already in existence, adding another process that distribute rewards to all of these would only exacerbate the current issues.

In this regard would it be sensible to tie the distribution together, i.e. collect fees (as described above, in a collector account) and distribute at the same time (in the same process/block) as the inflation rewards? The share of distribution (i.e. commission) can be different, which only alters the amount debited/credited, but it means no additional debits or credits to any accounts (though it may be desirable to have them split for accounting purposes, but still within the same block).

The only in-protocol revenue, consistent among all validators, are block fees and inflationary rewards, so I think MEV, side-deals etc should be outside of the scope of this proposal, though can be tacitly included if the collector account can receive arbitrary credits that are subject to the same distribution formula:

1. Validators can set two commission values: staking rewards and block rewards (or maybe even just one), this ideally should happen in the vote account, i.e. the newly added commission value lives in the same place and has the same treatment as regular commission, also an opportunity to alter them both to allow decimals.
2. Intra-epoch block rewards are deposited into the collector account (can be a PDA derived from node identity and seed or something)
3. Anyone can make arbitrary additional credits to the collector account (i.e. validator deposits revenue from a side deal)
4. When rewards distribution occurs the commission is applied to the collector account funds (commission paid to vote account) and balance included with rewards paid into stake accounts

This also ensures compounding of rewards as they are distributed as activated stake

The mapping of identity to vote account may still be problematic, especially where a validator changes their authorized voter, but this could be fixed within the same scope, possibly even changing the leader schedule to link to vote accounts (this actually feels like it should require its own SIMD).

This proposal has been stale for some time, I'd like to see how we can revive this and move it forward, what are the blockers right now, is it just uncertainty over best implementation or some sort of hard blocker like inability to reliably link identity to vote account?

[jstarry]

@Benhawkins18 and I just had a discussion about this today FYI and we will be collaborating on determining how to best distribute block fees to stakers. This goal will mostly likely be split into multiple SIMDs to cover things like setting up collector accounts and commission rates, constraining validator ids to have a single vote account, and modifying the inflation stake reward distribution mechanism to support distributing collected fees. @michaelh-laine your latest comment matches our thinking quite closely, thanks for weighing in.

[segfaultdoc]

Wdyt about having a separate SIMD just for this piece? This on its own is a valuable feature

[jstarry]

Yup, was already writing one up, here's a draft that you can check out. Would appreciate feedback from you and @buffalu. This SIMD now just focuses on 1) where to send commission from different revenue sources and 2) how to collect and distribute post-commission revenue to stake delegators

[jstarry]

oops SIMD draft here: #185

[jstarry]

Long awaited update on this SIMD..

This SIMD now focuses on 1) how to set a commission rate for different revenue sources and 2) how to collect and distribute post-commission revenue to stakers via validator specific stake rewards pool accounts.

There are a few prerequisite SIMDs...

1. SIMD-0180 which migrates the leader schedule from using validator identity keys to using validator vote account pubkeys. This allows blocks to be directly tied to a vote account which will store commission rates and collector accounts.
2. SIMD-0185 which describes a new update to the vote program to set commission rates and collector accounts for 3 different revenue sources: inflation rewards, block fees (both base and priority), and block tips

I will also be drafting up a SIMD to design the syscall and/or system instruction for tipping the current leader

[jstarry]

@michaelh-laine you previously wrote

When rewards distribution occurs the commission is applied to the collector account funds (commission paid to vote account) and balance included with rewards paid into stake accounts

But I think it would be better for validators if they could receive block fee revenue immediately after each block in order to have a stream of income to pay for voting costs rather than needing to wait for epoch boundaries. With this approach, an important thing to consider is how to design commission rate updates because it would be a little strange to allow commission to change multiple times throughout the epoch. Maybe the vote program should only support setting the commission for the upcoming epoch so that the current epoch commission rates are always fixed from the beginning of an epoch.

[michaelh-laine]

At most a validator would need to frontload 2 SOL to pay an epoch's voting fees, but I don't feel strongly about that component. Commission change should not be permitted after 50% of the epoch has elapsed the same as it is for staking and should apply for an entire epoch, agreed there.

Your proposal states commission should be paid to a system program-owned account, but I think a major use case here would be for larger and institutional validators to automatically divert those funds into a multisig for security and opsec purposes - this then naturally isn't a system-program owned account.

[jstarry]

Commission change should not be permitted after 50% of the epoch has elapsed the same as it is for staking and should apply for an entire epoch, agreed there.

Hoping to make commission related updates only apply for the following epoch FYI. Will be updating #185 to reflect that design.

Your proposal states commission should be paid to a system program-owned account, but I think a major use case here would be for larger and institutional validators to automatically divert those funds into a multisig for security and opsec purposes - this then naturally isn't a system-program owned account.

Note that since you can define a system-program owned account that isn't your node validator id, it doesn't need to have a private key anymore and so you could use a PDA which is controlled by a multisig or other onchain program.

[jstarry]

Just updated this SIMD with the following changes:

• Assume there will only be a single block revenue source to be distributed to stakers for now (removed mention of block tips)
• Explained how stake rewards pool accounts will have rewards distributed to stakers when the amount of pending stake activations exceeds 9% of effective stake
• Detailed calculations for commission and stake weighted rewards

[Benhawkins18]

Great work on this! The proposal looks really solid. One thought I keep coming back to is the terminology around 'Stake Rewards Pool Account.' The term ‘Stake Rewards Pool Account’ might cause some ambiguity, as it could be interpreted in multiple ways. For instance, it doesn’t immediately convey that this account specifically benefits delegators rather than the validator itself or general stake rewards.

Using something like ‘Delegator Rewards Pool Account’ could make it clearer that this account is intended to distribute block revenue directly to delegators, which might help readers understand its purpose more quickly. It’s a small adjustment, but I think it could go a long way in preventing misinterpretation.