SIMD-0085

TL;DR

Every validator defines a node id which is also used as the validator's fee-collector account for collecting earned protocol fees. After implementing this proposal, validator implementations will burn fees if they would otherwise be distributed into a fee-collector account that violates one of the following constraints: 1. Must be a system owned account 2. Must be rent-exempt These constraints apply to both transaction fees and rent fees. Note that the rent-exempt constraint was already added for rent fee collection in [Feature 30151](https://github.com/solana-labs/solana/issues/30151).

Summary

Every validator defines a node id which is also used as the validator's fee-collector account for collecting earned protocol fees. After implementing this proposal, validator implementations will burn fees if they would otherwise be distributed into a fee-collector account that violates one of the following constraints: 1. Must be a system owned account 2. Must be rent-exempt These constraints apply to both transaction fees and rent fees. Note that the rent-exempt constraint was already added for rent fee collection in [Feature 30151](https://github.com/solana-labs/solana/issues/30151).

Motivation

1. Fee distribution occurs outside of the transaction runtime because the Solana protocol mandates that fees are distributed to "fee-collector" accounts at the end of each block. By restricting fee-collector accounts to be system owned, the number of account modification edge cases as well as protocol complexity are both reduced. 2. Prevent new rent-paying accounts from being created since rent collection is planned to be disabled in SIMD-0084.

Key Changes

• Must be a system owned account
• Must be rent-exempt

Impact

New and existing validators must ensure that their fee-collector account is rent-exempt and owned by the system program in order to receive fees. Since the Solana Labs validator implementation currently requires the fee-collector account to be same account as the fee payer for vote transactions, this is unlikely to impact any validators unless they run a custom implementation. Validators will still be able to collect fees into durable nonce accounts if they wish. If a validator does not wish to use a hot wallet to have custody over collected fees, they may use durable nonce accounts which have a configurable authority address.

Security Considerations

Note that durable nonce accounts are system owned and rent exempt and can therefore continue to be used for fee collection.