## Summary

Burns fees if they would otherwise be collected into an account that violates
one of the following constraints:

1. Must be a system owned account
2. Must be rent-exempt

This applies 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 collection occurs outside of the transaction runtime because the Solana
   protocol mandates that fees are collected 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.

## Alternatives Considered

### Elide the system-owned constraint

Restricting fee collector accounts to be system-owned is perhaps overly
restrictive and limits the amount of flexibility that validator operators have
when managing sensitive accounts with funds. However, the risk of having more
runtime edge cases is too high to allow any program-owned account to collect
fees. The Solana protocol should aim to limit the types of account modifications
that can occur outside of the transaction processor to avoid introducing
loopholes.

### Introduce an enshrined "validator node" account

Rather than restricting fee collector accounts to be system-owned, a new type of
"validator node" account could be introduced. Currently, in normal validator
operations, the "fee collector" account is also used as the "node id" as well as
the vote fee payer. Introducing a "validator node" account that is owned by a
"validator node" program which allows configuring a "withdraw authority" and
"vote fee payer" could help increase validator operation flexibility and
increase clarity in how validator keys are used in the protocol.

This approach requires a migration of all "fee collector" accounts as well as
the development of a new on-chain program to manage the new "validator node"
accounts. It will be a big effort compared to the proposed constraints in this
SIMD and should be discussed in a new SIMD if this approach is desired.
Furthermore, durable nonce accounts already have a configurable authority field
which can be used to manage fee collector account funds in a more flexible way.

## New Terminology

Fee Collector: The account that receives block and rent fees collected by
validators. Also known as the "node id".

## Detailed Design

At the end of a block, validators MUST ONLY distribute fees to accounts that are
both system owned and rent-exempt. If a fee collector account does not satisfy
these constraints, the fees MUST be burned by not distributing them to anyone.

## 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.

Additional Fee Collector Constraints