This is the final instalment of our 4-part series written in tandem with Blockchain Capital. We hope you’ve enjoyed the series. If you want to collaborate with us, reach out!

Solana generates 70% more fees than Ethereum even though both networks have relatively similar pricing mechanisms. In this article we will compare Solana and Ethereum's business models, namely how each charges for their core product: blockspace.

Both networks charge for usage via a base fee, a priority fee, and an out-of-protocol MEV component. Each converts work into abstract units: Gas on Ethereum and Compute Units on Solana. But they diverge in how those units are defined, priced, and optimized, shaping each network's microstructure. These differing fee structures result from design choices in their respective virtual machines. Let's dive in!

If you are new here, feel free to check out our previous articles in this series: Intro, EVM & SVM and MEV.

On Ethereum, the cost of a transaction is calculated as:

gas used × (base fee + priority fee)

The base fee component was introduced in EIP-1559 (August 2021) aiming to smooth user’s fee expectations, prevent intra-block gas spikes and set a floor on the fee the network will accept. The base fee operates like a control system and adjusts by up to 12.5% per block to hold average gas utilization at 50%. As a result, transaction wait time improved across the board as fees became more predictable.

The base fee is burned, removing ETH from circulation and creating deflationary pressure. Since launch, approximately 4.5 million ETH (about $13 billion) has been burned, often offsetting issuance and reinforcing ETH's "ultrasound money" narrative.

Users may add a priority fee to their transaction, paid entirely to the validator to accelerate inclusion. In theory, transactions with the highest priority fees should land in a block, but while the priority fee is a core driver for validators to include transactions, it is not the only factor. As discussed in our MEV article, validators typically outsource block building to block builders who also factor MEV opportunities into block construction. Interestingly, many applications and rollups send non-MEV transactions directly to builders to improve inclusion.

Solana has a slightly different fee model that charges for work in two parts: signatures and CUs. It uses the formula:

(signatures × base fee) + (compute units × priority fee)

The base fee is fixed at 5k lamports (0.000005 SOL, $0.001 at $200/SOL) per signature, of which half is burned and half goes to the validator. Priority fees, set in micro-lamports (0.000001 lamports) per CU, go entirely to the validator as of SIMD-0096 in February 2025. Before that, only 50% of the priority fees went to validators. Because the base fee never changes with congestion, Solana relies solely on priority fees to signal willingness to pay.

As with Ethereum, while priority fees should theoretically guarantee transaction inclusion, MEV also influences inclusion decisions through the Jito auction. Importantly, Solana MEV is collected differently than Ethereum MEV. Ethereum's MEV is collected via lump-sum block-builder auctions in the proposer-builder separation pipeline, obscuring per-transaction MEV contributions (though you can look at the per bundle prices in many cases). By contrast, Solana's Jito-Solana sidecar runs off-chain auctions that attach explicit Jito tips to each bundle about 95% to validators and 5% to operators. We discuss Solana and Ethereum MEV more thoroughly in our previous article.

Just like Ethereum, some non-MEV transactions use Jito bundles purely for inclusion reliability. Since Jito prioritizes bundles, users can bypass standard networking and guarantee inclusion.

In our article about the EVM & SVM, we discussed how Ethereum and Solana's virtual machines differ: while Ethereum processes all transactions sequentially, Solana is built to process transactions in parallel. These architectural differences have downstream effects in terms of how fees in one transaction affect the fees in other transactions within the same block.

On Ethereum, EIP-1559's dynamic base fee adjusts each block, meaning when demand spikes, every transaction incurs higher costs. For example, an NFT drop drives up fees for all network activity, including simple transfers. A recent example on Ethereum was when @worldlibertyfi unlocked their first tranche of tokens, causing everyone to claim around the same time and making all other applications on Ethereum cost prohibitive. See the hotspot in the chart below.

Solana, by contrast, isolates contentious from non-contentious state: each transaction specifies exactly which accounts it will read or write, and its priority fee competes only with other transactions targeting those same accounts rather than with the entire network.

A single busy pool such as a popular AMM thereby creates its own mini–fee market, clearing at elevated priority fees, while unrelated transactions continue to pay the low median rate. In November 2024, average non-vote priority fees reached roughly 35× the median non-vote transaction fee.

Under the hood, Solana’s Agave client employs a central scheduler to sequence transactions by their state dependencies. An earlier TPU design used per-thread FIFO queues, preventing true fee isolation. Now, all incoming transactions enter a global “prio-graph” that considers only those contending for the same account locks, ordering them deterministically by priority fee across every thread. As a result, contested state markets clear at the prices bidders set for those specific accounts, while uncontested transactions remain priced at the low median, preserving predictable costs for most users, even during periods of peak demand.

Despite this parallel design, like Ethereum, Solana can suffer congestion. Even with adequate fees, Solana transactions could still fail due to UDP packet loss, RPC pool desynchronization, or forks that invalidate recent blockhashes. To compensate, many users broadcast large batches of low-priority transactions clogging validator queues, wasting rebroadcast capacity, and degrading UX.

On April 5 2024, this manifested as an alarmingly high revert rate with 75.7% of all non-vote transactions reverting. With the rollout of Agave v1.18’s central scheduler in May 2024, that rate plunged to 26.6% by July 4 2024. By deterministically sequencing only conflicting transactions through its global prio‐graph, the scheduler dramatically reduced queue overloads and reorg-related drops.

Spam, however, persists. To compensate for this, Solana has a DDoS-prevention mechanism called Stake-Weighted Quality of Service, where validators with higher stake are prioritized, meaning their transactions are more likely to be included (we will discuss this more in future articles). As a result, RPC providers compete on inclusion guarantees, often by vertically integrating with well-staked validators. While this improves performance for their clients, it also concentrates network influence among the largest stakers.

On Ethereum, VM operations are priced proportionally to the resources they consume. Any mis-pricing could lead to DDoS attacks, where an attacker can consume a disproportionate amount of resources compared to the fee paid. Every operation in the EVM, therefore, is priced differently: simple arithmetic operations like addition cost 3 gas units, while more complex operations like multiplication cost 5 gas units.

Commonly used operations that would be prohibitively expensive to implement within the VM are implemented as precompiles, which covers common cryptographic operations such as hash functions and elliptic curve operations. These operations cost significantly more gas: hashing operations cost at least 30 gas units, and pairing operations demand at least 79k gas units.

The next Ethereum Hardfork (Glamsterdam) has many gas price focused EIPs, ranging from a complete pricing overhaul, changing memory expansion pricing to increasing the cost of hash functions. For those interested in more in-depth pricing information visit this website.

Given that Ethereum transactions are expensive relative to other blockchains, there is an incentive for developers to hyper-optimize code to make transactions as efficient as possible. As a result, suboptimal programming paradigms are used to shave small costs off code, which can lead to making certain contracts hard to maintain. This is a known issue in the Ethereum development community where more time is spent on gas optimizations than on the core business logic itself.

A fun example of gas hyper-optimization is a zk protocol verifier written in assembly that @Maddiaa0 worked on to reduce gas costs by 60% compared to implementing it in vanilla Solidity. Projects have written their entire protocols in assembly like Opensea’s Seaport. This line in the Seaport contract literally just returns the name of the contract.

Another classic gas-saving tactic is the use of vanity addresses. Contract addresses with leading zeros cost slightly less to call than regular addresses because zeros in call data are cheaper to process.

Solana takes a simplified approach to pricing in comparison to Ethereum where transactions are charge a flat 1 Compute Unit (CU) per eBPF instruction. So both heavy and trivial operations cost the same, simplifying pricing but sacrificing fidelity. For example, a simple addition and multiplication cost the same, unlike Ethereum, even though they consume a very different number of compute cycles.

Solana uses syscalls that function similarly to Ethereum's precompiles. In fact, Solana implements many of the same operations as Ethereum, such as hash functions and elliptic curve calculations. Syscalls are priced differently than opcodes and have higher CUs. For example, Solana's hashv syscall charges 85 CU as a base fee, plus 1 CU per byte hashed. All global state accessing functions (similar to Ethereum's balance caller) are grouped under the sysvar syscall, which has a base cost of 100 CU.

Transactions are capped at 200k CUs by default and will revert if they exceed this limit. However, developers can set custom CU limits (up to 1.4M CUs) by including a call to the Compute Budget Program’s SetComputeUnitLimit instruction before their other instructions. This gives developers precise control over how much compute their transaction can use, directly affecting the transaction's overall cost.

With per-tx fees typically a couple of cents, the incentive to hyper-optimize is minimal; saving CUs reduces costs by fractions of a cent, so developers focus on staying under the CU cap rather than micro-optimizing. Though, highly optimized libraries like Pinocchio are becoming more widely adopted for high volume Solana programs as lower CU usage improves TX inclusion.

Unlike Ethereum, which bills each storage write via SSTORE gas, Solana separates storage cost into a “rent” model. While it is called “rent”, it is more appropriate to think of Solana’s current storage costs as collateral. When storing data, accounts require an amount of lamports proportional to the amount of bytes being stored. The cost for storage is temporary as the lamports transferred to an account are reclaimable when closing the account or reducing the number of bytes allocated to the account.

In early versions of Solana, the rent model actually had rent-like behavior. Accounts would accrue rent at a rate of about 2,440 lamports per byte per epoch. This rent would be deducted from the account’s balance until it reached 0 when it was then garbage collected. To avoid rent being collected and ensure an account persists indefinitely, clients deposit 2 years’ worth of rent, which meets the minimum balance required for rent exemption. Now, allocating storage to an account with less lamports than the minimum balance will result in the transaction being reverted with an error.

Solana's rent model for storage can still be cost prohibitive for applications that require large amounts of storage. To overcome such costs, dApps will use state compression, storing only a Merkle root on-chain and keeping the full data off-chain.

Ethereum storage operations are priced heavily because database interactions are time-consuming and contribute significantly to state growth. Writing to storage costs 20k gas units, covering the permanent cost of state. Reading from storage costs 2.1k gas units, while subsequent reads from the same slot within the transaction cost only 100 gas units, reflecting that the value will be available in cache.

Ethereum also has a mechanism for refunding gas when clearing storage, though it has changed dramatically throughout the years. The refund for clearing a storage slot used to be 15k gas. This encouraged the creation of "Gas Tokens" where users could write to storage when gas was cheap, then delete storage when gas became expensive to reduce transaction costs. Some applications integrated this feature into their products. The Chi Gas Token from @1inch remains as a relic of this era.

Searchers used this strategy extensively, giving them a significant advantage during high congestion periods. Since then, the refund has been reduced to 4.8k gas, and the maximum refund capped at 20% of the transaction's total gas spend to discourage this practice.

Real Economic Value (REV) measures the total economic activity on a blockchain, calculated as the sum of transaction fees and MEV tips paid by users. This top-line financial metric helps compare demand for blockspace across different blockchains. Note: REV includes the fees L2s pay to L1s.

In August 2025, Solana captured 23.76% ($77.8 million) of monthly REV across all chains, compared to Ethereum at 14.21% ($46.6 million). That means Solana generated nearly 70% more demand for blockspace than Ethereum despite its lower per transaction fees. In the overall rankings, Solana is in second place, Ethereum is in fourth, and Hyperliquid leads with 32.55% ($106.6 million), just below the combined share of Solana and Ethereum.

Note that the Hyperliquid REV metric includes HyperCore fees (the trading platform) which represented 99.18% of the total August REV. Arguably the Solana-Ethereum to Hyperliquid comparison is apples to oranges.

We extend our sincere gratitude to Blockchain Capital for their invaluable support and collaboration throughout the research and writing of this series. We thoroughly enjoyed delving into the intricacies of Solana and Ethereum, and we are incredibly proud of the insights shared. We look forward to future collaborations and continuing to contribute to the blockchain ecosystem. If you are interested in writing with us or have ideas for future research, please do not hesitate to reach out!

Thanks to @zile_cao for the valuable feedback on the article.

Check out our previous articles in the series as well: