Comparative Analysis of Transactions: Solana vs. Others

By Michael @ CryptoEQ | CryptoEQ | 14 May 2024

You are reading an excerpt from our free but shortened abridged report! While still packed with incredible research and data, for just $40/month you can upgrade to our FULL library of 60+ reports (including this one) and complete industry-leading analysis on the top crypto assets. 


Becoming a Premium member means enjoying all the perks of a Basic membership PLUS:

  • Full-length CORE Reports: More technical, in-depth research, actionable insights, and potential market alpha for serious crypto users
  • Early access to future CORE ratings: Being early is sometimes just as important as being right!
  • Premium Member CORE+ Reports: Coverage on the top issues pertaining to crypto users like bridge security, layer two solutions, DeFi plays, and more
  • CORE report Audio playback: Don’t want to read? No problem! Listen on the go.




Solana has consistently been at the forefront of discussion within the cryptocurrency community, especially with the advent of Solana MEV and recent challenges concerning network reliability. As market dynamics evolve, it is crucial to reevaluate Solana's current performance and its economic and technical landscape.

Solana Fee Structure and Economic Viability

Solana's approach to handling transactions sets it apart from other blockchain networks like Ethereum in several key ways. Notably, Solana does not rely on a public mempool where pending transactions are aggregated through peer-to-peer gossip. Instead, these transactions are directly forwarded to the current leader and the next few leaders in line for processing.

The key differences in the transaction lifecycle on a non-mempool blockchain like Solana compared to a mempool-based blockchain are:

  1. Absence of a public mempool: Instead of pending transactions being part of a distributed mempool built by peer-to-peer gossip, they are forwarded directly to the current leader and next few leaders.
  2. Continuous block production: Solana's default validator implementation features continuous block production, where transactions continuously stream into the validator for execution, then block production, and finally transaction propagation. This is in contrast to Ethereum's block-based model.

The lifecycle of a transaction on a non-mempool blockchain like Solana is as follows:

  1. The user initiates and signs a transaction for an application they are using.
  2. The application routes the transaction information to a Remote Procedure Call (RPC) server.
  3. The RPC provider sends the transaction to the current designated block producer, as well as the next three producers. This is a precautionary step in case the current leader cannot execute the transaction in time. Solana employs a slot leader schedule to help RPCs route transactions more efficiently.
  4. The block producer then sends the signed transaction to consensus nodes for verification.
  5. Consensus nodes vote to verify the contents of the transaction, and once completed, the transaction status is routed back to the RPC > application > user as either 'success' or 'failed'.
  6. Similar to mempool-based blockchains, the block itself is finalized after a certain time or block-based threshold has passed.

solana tx lifecycle Source

Moreover, Solana's default validator implementation emphasizes continuous block production, in contrast to Ethereum's 12-second block intervals. This means that priority fees on Solana do not guarantee inclusion within a block.

This continuous process allows for faster transaction pre-confirmation, offering a significant advantage in terms of speed. However, this approach does not come without its challenges. The continuous nature of block-building in Solana's system can result in a lack of predictability and certain inefficiencies, particularly regarding the inclusion and prioritization of transactions.

The blockchain operates on a multi-threaded mechanism, allowing for the parallel processing of transactions. This structure aims to enhance the network's throughput and efficiency. Nonetheless, the decision-making behind the allocation of threads and compute units appears to be somewhat arbitrary, raising questions about the system's optimization and scalability.

evm vs svm Source

One of the most notable features of Solana's design is the concept of local fee markets. These markets are intended to operate independently for different types of transactions, such as NFT mints or DeFi operations. Theoretically, this structure should prevent a high-demand transaction type from disproportionately inflating fees across the network. However, in practice, the realization of local fee markets in Solana has been less than ideal.

The current mechanism for processing transactions in Solana is predominantly a first-price, greedy system. This setup does not provide clear guidance to users on the priority fee required for timely inclusion of their transactions, leading to inefficiencies. Particularly during periods of high network demand, users and protocols may increase their transaction fees in an uncoordinated and empirical manner, leading to an overall inefficient system.

This situation contrasts with Ethereum's implementation of EIP 1559, which introduced a more predictable base fee that adjusts with block saturation, offering a clearer and more efficient way for users to gauge the required transaction fees.

Finally, Solana transactions come with a fixed network fee per signature, typically one signature per transaction, amounting to 0.000005 SOL, approximately $0.0001 at the time of writing. Additionally, users have the option to include a priority fee, measured in the fee paid per requested compute unit, to gain higher priority within the Solana scheduler. It's important to note that Solana's block size limit is determined by compute units used, akin to Ethereum's gas target. Interestingly, Solana's fee structure allocates half of the network fees to burning while the remaining half is awarded to the leader.

Solana has demonstrated remarkable economic growth, with its total network fees recently reaching half the volume of Ethereum's, a stark increase from the previous year. This surge in fees is attributable to the near parity achieved with Ethereum's MEV, signaling a shift in the economic stability of blockchain networks. The introduction of Jupiter’s auto slippage feature has notably enhanced transaction success rates, a development highlighted by Phantom as a significant improvement. Despite a downturn in transaction volumes, the Total Value Locked (TVL) on the network remains surprisingly resilient.


Only Ethereum (gray) generates more fees than Solana (green). Source

Comparing Solana vs. Other Chains

Blockchain technology offers diverse methods for transaction composition, significantly impacting how developers build and interact with decentralized applications (dApps). This analysis explores distinct approaches across multiple blockchains, focusing on their usability, development flexibility, and potential barriers for developers and end-users.

Sui: Programmable Transaction Blocks (PTBs)

Sui utilizes Programmable Transaction Blocks (PTBs), which can include up to 1024 commands executed atomically. These commands vary from MoveCalls to transfers and coin operations, accommodating various development languages through SDKs like TypeScript, Rust, Python, and Go. PTBs shift a considerable portion of the development workload from smart contract developers to front-end/back-end developers, necessitating integration of their packages into the dApp by Move developers on Sui. This approach democratizes the development of complex, efficient dApps but increases the burden on front-end developers.

Aptos: Scripts in Move

Aptos employs scripts—non-persistent pieces of Move code—to execute complex operations atomically. The transaction is constructed using the script's bytecode, with the provision for argument inputs. This method benefits smart contract developers by allowing easy extension of functionalities through scripts. However, it presents a challenge for non-Move developers who may find script writing inaccessible. The popularity and effectiveness of this feature in Aptos remain unclear due to its non-implementation in Sui.

Radix: Transaction Manifests

Radix introduces Transaction Manifests, which are assembled off-chain and designed to be human-readable, distinguishing them from PTBs. This design aims to empower non-developers to compose their transactions, enhancing the user-friendliness of front-end displays such as wallets. Although less intuitive for developers accustomed to traditional programming languages like Move, Rust, and TypeScript, this approach could potentially lower the entry barrier for non-dev users, provided they engage with the manifests.

Solana: Transaction Composition

Solana's transaction model aligns closely with Sui's PTBs, incorporating multiple instructions within a single transaction. However, it differs in its transaction size limitations, which may affect the scope of operations that can be executed in a single transaction compared to Sui. This aspect warrants further exploration to understand how it influences both developer and user experiences relative to other platforms like Sui.

Solana has introduced several technical solutions aimed at alleviating congestion issues, notably the Stake Weighted Quality of Service (SWQoS) and Bandwidth Markets. SWQoS prioritizes transactions from nodes based on the amount of SOL they stake, facilitating efficient traffic management across Solana’s validator network during peak periods. This method ensures that transactions are routed through validators based on their geographical and network proximity, reducing transaction drop rates.

Adoption Hurdles

Despite these advancements, the adoption of new network improvements presents significant challenges. A limited number of high-stake validators have adopted the latest updates, which include optimizations for QUIC and enhanced congestion management. This slow adoption rate, particularly among non-Solana native teams, highlights a misalignment of incentives, where entities like Coinbase benefit from large staking positions without directly contributing to the network’s health.


The varied approaches to transaction composition across blockchain platforms illustrate a spectrum of developer and user experiences. Sui and Solana offer robust, developer-focused models that may necessitate higher technical involvement, while Radix seeks to simplify user interaction, potentially at the cost of developer familiarity. Aptos's reliance on Move scripts may limit accessibility for those not versed in Move programming. An ongoing assessment of these models will help clarify their efficacy, user adoption, and potential for mainstream acceptance in the blockchain ecosystem. 

With the market stabilization, Solana’s network and economic indicators suggest a robust health status. Continuous innovations in transaction processing and valuation keep the network competitive. With contributions from teams such as Jito, Helius, and Jupiter, and the anticipation of new solutions like Firedancer, Solana is well-positioned to enhance its resilience and performance further.

In summary, Solana’s trajectory in the cryptocurrency landscape is marked by significant economic growth and technical innovations aimed at improving network efficiency and stakeholder returns. The platform’s ability to adapt to emerging challenges and opportunities will be crucial in maintaining its competitive edge in the evolving blockchain ecosystem.

How do you rate this article?


Michael @ CryptoEQ
Michael @ CryptoEQ

I am a Co-Founder and Lead Analyst at CryptoEQ. Gain the market insights you need to grow your cryptocurrency portfolio. Our team's supportive and interactive approach helps you refine your crypto investing and trading strategies.


Gain the market insights you need to grow your cryptocurrency portfolio. Our team's supportive and interactive approach helps you refine your crypto investing and trading strategies.

Send a $0.01 microtip in crypto to the author, and earn yourself as you read!

20% to author / 80% to me.
We pay the tips from our rewards pool.