- n_days: Loockback period. If set to 0, start_date and end_date are used.

- start_date: Data collection start date.

- end_date: Data collection end date.

Every Solana transaction requires a base fee (SOL) to compensate validators for processing the transaction. An optional prioritization fee is also available to increase the probability that the transaction is processed by the current leader (validator).

After [SIMD-0096](https://github.com/solana-foundation/solana-improvement-documents/blob/main/proposals/0096-reward-collected-priority-fee-in-entirety.md) 100% of the priority fee is paid directly to the validator processing the transaction.

Base fee is instead [50% burnt](https://github.com/anza-xyz/agave/blob/67412607f511ded3770031280b6aaf10607713fc/sdk/fee-calculator/src/lib.rs#L70) and [50% distributed to validators](https://github.com/anza-xyz/agave/blob/e621336acad4f5d6e5b860eaa1b074b01c99253c/runtime/src/bank/fee_distribution.rs#L58-L62).

Studying transaction dynamics is crucial to assess the impact of changes in the percentage of fees burned. Analyzing the ratio between vote and non-vote transactions, the TPS distribution, and the priority fees per transaction (PF/tx) provides key insights into network behavior. Shifts in these metrics help evaluate whether fee adjustments influence transaction inclusion, validator incentives, and overall network efficiency. Understanding these trends ensures that changes in Solana’s fee structure optimize resource allocation without negatively impacting transaction throughput or user costs.

Solana transactions are categorized into two types: vote and non-vote. Vote transactions are executed by validators to participate in consensus, while non-vote transactions represent standard user activity, such as transfers, swaps, and program interactions.