Skip to main content
Technical proposal SIMD-0232 Review

Custom Commission Collector Account

  1. Idea
  2. Draft
  3. Review
  4. Accept
  5. Implement
  6. 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.

Source-backed reading aid · source language: EN

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 required
Validators & 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 unknown
Users & 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 required
Governance & ecosystem Impact unknown

No proposal-specific evidence was found for this group.

Action requirement unknown

Exact source revision

Full proposal document

Source-language document. Technical identifiers and evidence remain unchanged. 0616093b2952

Summary

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:

  1. Must be a system program owned account
  2. Must be rent-exempt after depositing block revenue commission
  3. 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:

  1. Must be a system program owned account
  2. Must be rent-exempt after depositing inflation rewards commission
  3. 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, return InstructionError::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, return InstructionError::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 the inflation_rewards_collector field
  • CommissionKind::BlockRevenue: update the block_revenue_collector field

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

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.

Provenance

Evidence & technical details

Rollout or chain data, source revisions, freshness and integrity.
3

SIMD

Deployment Status

Document lifecycleReview
CategoryCore protocol

Feature Gate not yet created

Exact source revision

Sources & integrity

  • Proposal document pinned_commit_blob
    0616093b2952ed6de52c4a27d66aadd11d48d4f9
  • simd-document document · stale · Sep 10, 2026
    0616093b2952ed6de52c4a27d66aadd11d48d4f9

One or more sources are unavailable.

One or more sources are unavailable.