## Overview
(NEEDS REVIEW)
Currently, there is a lack of transparency in resource allocation for transactions, leading to suboptimal cluster performance. To address this issue, we need a solution that enables quick and cost-effective identification of a transaction's impact on cluster performance. We propose a fee structure based on the resources requested by transactions. This approach aligns the interests of both transaction submitters and operators by charging fees according to the resources required.

Solana's current fee mechanisms are insufficient in applying "economic backpressure" with respect to account state access contention (hot region). With a flat base fee, local fee markets and thread localized priority fees the function still results in failed transactions landing on chain which suggests blockspace is not being priced correctly$^1$.

With the mispricing being the current state of blockspace, there is a misalignment of incentives thus creating additional behaviors (latency) in order to facilitate inclusion within a block.

This proposal is designed to highlight the current model and its design mechanics, expand upon it with a shift in one aspect of the `base_fee` calculation. This is accomplished by leveraging a new `lamports/cu` fee structure to assign a cost to resources estimated and consumed. While not a primary goal of this work, there are some notes about future design considerations and changes with respect to the economics of a transaction on Solana.

## Background / Motivation
https://discord.com/channels/428295358100013066/754723351389536348/1174842511873806436
(NEEDS REVIEW)
Solana charges a fixed base fee rate to all transactions submitted to the validator for inclusion of the block. This fee is 0.000005/signature SOL or 5000 Lamports.

There are additionally self imposed restrictions on blockspace such as
- `48M CU/slot`
- `12M CU/account write lock/slot`
These are artificial constraints placed within the codebase to ensure effective topology within the cluster of validators processing the Solana blockchain.

Scheduling within the current design of Solana is a unique and difficult challenge given that Solana blocks are built continuously (execution is bottleneck, and partial blocks are streamed out as they are built so other validators can replay) therefore not ideal for auction market for inclusion with any expected guarantees (see Overview for additional behaviors).

There is currently Compute Unit Price method and Compute Unit Limit to establish "priority fees" for inclusion in the block, however since non-conflicting transactions are executed in parallel (using threads) priority fees are localized to the working thread the transaction is assigned on the machine, not across all threads.

This, combined with natural "jitter" within the network due to a myriad of systems and processing, provides a UX which is challenging to integrate for users (or at least motivate significant user behavior change).

There exists ongoing development to implement a new scheduler design by Solana Labs. There is ongoing discussions with respect to bankless leaders and reducing blocktime. There are existing proposals for engaging dApps to act as gatekeepers to influence user specific behavior. All of these ongoing efforts fail to address the fundamental aspect of Optimizing Resource Allocation. This is essential for achieving high network throughput and low latency.

"there's no economic backpressure. you can still get included in block even if priority fee is low. if the system is running "hot" in certain areas or on a global level, the network should increase those fees at a level agreed upon in consensus" - Buffalu (Jito)

## Implementation
Modification to compute unit calculation such that the network fee is based on `lamports/cu` where the following applies:

- `lamports` is calculated based on `base_lamport_fee * variable_rate`
- `cu` is the compute unit as defined within Solana
- `variable_rate` is established at a fixed rate to begin, but is identified as a variable to be set by a controller mechanism
- the controller mechanism and design is to be naive but robust, minimally manipulable and incentive compatible

The new base fee calculation now includes two primary components the current fee per signature $F_{sig}$ and additionally the fee for resource allocation $F_r$ as allocated through the variable rate.

$B = F_{sig} * S_n + F_{r}$

In aggregate the final fee structure will be $B$ the base fee as calculated above. Combined with the $p$ priority fee. Multiplied by the requested compute units $CU_{req}$.

$F = (B + p) * CU_{req}$

**Regarding the criteria listed above**
- *naive* in the sense that applicable information is lagging, so its understanding of demand is limited
- *robust* that it stands through multiple market conditions and dynamics currently understood and observed with the flexibility to handle unforseen circumstances without issue
- *minimally manipulable* such that stakeholders and market participants are unable to significantly impact the resulting value for political, social or financial gain
- *incentive compatible* based on balances across the intents and outcomes from the various stakeholders, if there is a carrot, there is also a stick to ensure behavior is able to be understood

**Regarding issues of contention**
In the event a `variable_rate` design mechanism cannot be determined acceptable:
- propose setting a fixed value while research is conducted and solutions evaluated. This value can be determined within the following parameters (Stub)

Beyond this a governance council could be appointed to be stewards of this value while designing systems to automate data aggregation to inform said choice.

Extending further this council could be elected from the broader community in some process of governance.

With an ultimate goal of arriving at governance voting of the validator set to assign value of this rate.

## Risks

## Result / Conclusion

## Related Parties
@Tao
@gmgalactus
@eugene
@buffalu
@Crancx
@trent.sol
@Jarry
@maximilian
@mvines
@7Layer
@Proph3t

And MANY MANY MORE.

## References
[1] https://ellipsislabs.notion.site/Draft-Proposal-Per-Account-Write-Fees-c683c370135641b98c0cc2edf6f35fbf

https://discord.gg/vEEfR4z3
https://discord.gg/solana #economics channel
https://eips.ethereum.org/EIPS/eip-1559
https://arxiv.org/abs/2307.01686
https://docs.solana.com/economics_overview
https://github.com/pgarimidi/Solana-Scheduler/blob/main/Solana_TFMs.pdf
https://github.com/solana-labs/solana/issues/28063#issuecomment-1727151064
https://mango-markets.notion.site/Base-fees-in-Solana-83af1d7eafc848fdb726a64748281f87
https://ellipsislabs.notion.site/Draft-Proposal-Per-Account-Write-Fees-c683c370135641b98c0cc2edf6f35fbf?pvs=4

## Additional Considerations / Notes
- Charging for write locks
- Charging for read locks
- Dynamic fees