Custom Commission Collector Account
- Idea
- Draft
- Review
- Accept
- Implement
- Active
Decision brief
Why this proposal matters
Allow validators to specify custom commission collector accounts where block revenue and inflation rewards commissions will be deposited.
Proposal at a glance
What changes
- Block Revenue Commission Collector: The account used to collect commissioned block revenue for validators. Previously collected by default into the validator identity account.
- Inflation Rewards Commission Collector: The account used to collect commissioned inflation rewards for validators. Previously collected by default into the vote account.
- Must be a system program owned account
Stakeholder map
Who is affected
Builders & client teams Medium impact
When collecting block fee revenue after processing all transactions in a block, the runtime must look up the validator's specified block revenue collector address. After adoption of SIMD-0180 and SIMD-0185, a given block's fee commission collector address can be looked up via the designated vote account for the leader schedule slot that the block was…
Action may be requiredValidators & operators Medium impact
This change will require the use of a new feature gate which will enable collecting block fees and inflation rewards into custom commission collector addresses if specified by a validator.
Action requirement unknownUsers & stakers Medium impact
Validator identity and fee collector accounts no longer need to be the same account. This opens up the ability to use PDA accounts for block revenue collection.
Action may be requiredGovernance & ecosystem Impact unknown
No proposal-specific evidence was found for this group.
Action requirement unknownExact source revision
Full proposal document
6cc17538e266Summary
Allow validators to specify custom commission collector accounts where block revenue and inflation rewards commissions will be deposited.
Motivation
Validator commission collector accounts must currently be the same as their identity hot wallet account. This means that program derived addresses are unable to be used for block revenue collection adding friction to validators wishing to distribute their revenue in custom ways. By allowing validators to specify a separate custom commission collector account, they can use onchain programs to customize how their block revenue is distributed.
Dependencies
This proposal depends on the following previously accepted proposals:
SIMD-0180: Use Vote Account Address To Key Leader Schedule
Necessary for designating a specific vote account for a given leader slot
SIMD-0185: Vote Account v4
Adds necessary block revenue and inflation rewards commission collector address fields to the vote account state
Alternatives Considered
NA
New Terminology
Block Revenue Commission Collector: The account used to collect commissioned block revenue for validators. Previously collected by default into the validator identity account.
Inflation Rewards Commission Collector: The account used to collect commissioned inflation rewards for validators. Previously collected by default into the vote account.
Detailed Design
Runtime
Block Revenue Commission Collection
When collecting block fee revenue after processing all transactions in a block, the runtime must look up the validator's specified block revenue collector address. After adoption of SIMD-0180 and SIMD-0185, a given block's fee commission collector address can be looked up via the designated vote account for the leader schedule slot that the block was produced in. Note that by default, the commission rate for block fee revenue is 100% and support for other rates will be added in SIMD-0123.
In order to eliminate the overhead of tracking the latest commission collector address of each vote account, the commission collector address should be fetched from the state of the vote account at the beginning of the previous epoch. This is the same vote account state used to build the leader schedule for the current epoch.
The designated commission collector must either be equal to the vote account's address OR satisfy ALL of the following constraints:
- Must be a system program owned account
- Must be rent-exempt after depositing block revenue commission
- Must not be a reserved account (note that currently the only system program owned reserved accounts are the native loader and the sysvar owner id).
If any of these constraints are violated, the fees collected for that block will be burned.
Note that it's technically allowed to set the collector account to the incinerator address. Incinerator funds are burned after block revenue collection at the end of the block.
Inflation Rewards Commission Collection
For a given epoch E, the earned inflation rewards for each vote account are
calculated at the beginning of the next epoch E + 1. This proposal doesn't
change the commission calculation but it does define new rules for how the
calculated commission rewards are collected into an account. Rather than
collecting the inflation rewards commission into the vote accounts by default,
the protocol must fetch the inflation rewards commission collector address from
the vote account state at the beginning of epoch E + 1. This is the same
vote account state used to get the commission rate and latest vote credits
for inflation rewards calculation.
The designated commission collector must either be equal to the vote account's address OR satisfy ALL of the following constraints:
- Must be a system program owned account
- Must be rent-exempt after depositing inflation rewards commission
- Must not be a reserved account (note that currently the only system program owned reserved accounts are the native loader and the sysvar owner id).
If any of these constraints are violated, the inflation rewards commission collected for that epoch will be burned.
Note that it's technically allowed to set the collector account to the incinerator address. Incinerator funds are burned at the end of the rewards distribution block.
Vote Program
pub enum VoteInstruction {
/// # Account references
/// 0. `[WRITE]` Vote account to be updated with the new collector public key
/// 1. `[WRITE]` New collector account
/// 2. `[SIGNER]` Withdraw authority
UpdateCommissionCollector { // 17u32
kind: CommissionKind,
},
}
#[repr(u8)]
pub enum CommissionKind {
InflationRewards = 0,
BlockRevenue = 1,
}
UpdateCommissionCollector
A new instruction for setting collector accounts will be added to the vote
program with the enum discriminant value of 17u32 little endian encoded in the
first 4 bytes.
Perform the following checks:
- If the number of account inputs is less than 2, return
InstructionError::NotEnoughAccountKeys - If the vote account (index
0) fails to deserialize, returnInstructionError::InvalidAccountData - If the vote account's authorized withdrawer is not an account input for the
instruction or is not a signer, return
InstructionError::MissingRequiredSignature - If the new collector account (index
1) is not the same as the vote account and not system program owned, returnInstructionError::InvalidAccountOwner - If the new collector account is not rent-exempt, return
InstructionError::InsufficientFunds - If the new collector account is not writable, return
InstructionError::InvalidArgument. Note that this check is performed to ensure that the new collector account is not a reserved account.
Update the corresponding field for the specified commission kind:
CommissionKind::InflationRewards: update theinflation_rewards_collectorfieldCommissionKind::BlockRevenue: update theblock_revenue_collectorfield
Impact
Validator identity and fee collector accounts no longer need to be the same account. This opens up the ability to use PDA accounts for block revenue collection.
Inflation reward commissions no longer need to be collected into a validator's vote account. This validators more flexibility over managing inflation reward income.
Security Considerations
NA
Drawbacks (Optional)
NA
Backwards Compatibility (Optional)
This change will require the use of a new feature gate which will enable collecting block fees and inflation rewards into custom commission collector addresses if specified by a validator.
Evidence graph
Related proposals and rollout
One or more sources are unavailable.
Upstream review record
Upstream discussion & review
GitHub review is editorial context, not evidence of on-chain support, voting, or outcome.
PR #232 · merged SIMD-0232: Custom Commission Collector Account 22 comments and reviews · Jan 12, 2026Trying to minimize the surface area of possible account state changes the runtime can do outside of the SVM. By limiting to system program ownership, we implicitly make it impossible to do things like collect your commission into the system program account or some other unexpected place.
GitHub ↗addressed in https://github.com/solana-foundation/solana-improvement-documents/pull/232/commits/6baf29e1326e0b5eb7925e51469f060a2995cafe
GitHub ↗im a little confused here. by allowing system program, won't you give up programmatic control of the fees?
GitHub ↗Onchain programs will be able to create system owned pda's for the collector accounts.
GitHub ↗Ok, this works for me. The only thing that's left off the table is some PDA that must carry data, which would be owned by the user program still. I think that's ok, since programs can work around that limitation programmatically before providing a PDA signature. It's also more performant to ensure the owner is System, rather than go through some handful of constraints like reserved account keys or multiple disallowed owners.
GitHub ↗Sorry to raise this now, but could we avoid having to cache the commission collector account across epochs? Cross-pasting from a discussion in consensus: Data that needs to be persisted for business logic operations such as paying rewards out, should be persisted on-chain and not solely in a cache that each client has to re-create on re-start. If a particular client wants to add a cache then they obviously are able to, but falling back to on-chain data should always be an option. Two questions: - Do we need to use older versions of this field? Can't we just use the current commission collector account in the vote state at the point of the rewards payout slot? Is there a good reason not to do
GitHub ↗Do we need to use older versions of this field? Can't we just use the current commission collector account in the vote state at the point of the rewards payout slot? Is there a good reason not to do this? Part of the design of this SIMD was done with the idea that some validators will implement their own reward distribution mechanisms using these collector accounts. I feel it's best to not allow rugging those custom reward mechanisms by enforcing a few epoch's delay before applying new collector accounts. This is similar to the idea of avoiding commission rugs by delaying commission rate updates. If we do need to use the collector account from previous epochs, could we store this data on-cha
GitHub ↗Agreed in the discord chat, shipping SIMD-0123 is the priority - approved this SIMD. Having a long-term plan to move this data on-chain is awesome though.
GitHub ↗Provenance
Evidence & technical details
Rollout or chain data, source revisions, freshness and integrity. 2
Provenance
Evidence & technical details
Rollout or chain data, source revisions, freshness and integrity.SIMD
Deployment Status
Feature Gate not yet created
Exact source revision
Sources & integrity
- Proposal document pinned_commit_blob
6cc17538e26601e65beca89bbfa761e755720956 - simd-document document · stale · Oct 28, 2026
6cc17538e26601e65beca89bbfa761e755720956
One or more sources are unavailable.
simd.watch community discussion · SIMD-0232
Powered by Giscus · Sign in with GitHub to comment
Community comments load when this section approaches the viewport.