"Hidden Tax" on Solana

Author: SpecialistXBT

A year ago, an article titled "Payment for Order Flow on Solana" revealed a dark corner of the Solana fee market, sparking phenomenal attention on English Twitter.

PFOF (Payment for Order Flow) is already a mature business model in traditional finance. Robinhood leveraged this model to launch "zero-commission trading," quickly breaking away from many established brokerages. This strategy not only made Robinhood immensely profitable but also forced industry giants like Charles Schwab and E-Trade to follow suit, changing the landscape of retail brokerage in the U.S.

In 2021 alone, Robinhood garnered nearly $1 billion in revenue through PFOF, accounting for half of its total revenue that year; even by 2025, its quarterly PFOF revenue was still in the hundreds of millions. This illustrates the enormous profits behind this business model.

In traditional markets, market makers have a strong preference for retail orders. The reason is simple: retail orders are often considered "non-toxic," typically based on emotions or immediate needs, lacking precise predictions of future price movements. Market makers take these orders, ensuring they profit from the bid-ask spread without worrying about becoming counterparty to informed traders (like institutional investors).

Based on this demand, brokerages (like Robinhood) bundle user order flows and sell them in bulk to market-making giants like Citadel, thus collecting hefty rebates.

While regulation in traditional financial markets somewhat protects retail investors, the SEC's National Market System Regulation mandates that even packaged orders must be executed at no less than the market's best price.

However, in the unregulated on-chain world, applications exploit information asymmetry, enticing users to pay priority fees and tips that far exceed actual on-chain demand, quietly pocketing these premiums. This behavior essentially imposes a lucrative "invisible tax" on unsuspecting users.

Monetizing Traffic

For applications that control significant user entry points, monetizing traffic is far more diverse than you might think.

Front-end applications and wallets can determine where users' trades go, how they are executed, and even how quickly they are processed on-chain. Every "checkpoint" in a transaction's lifecycle hides business opportunities to extract maximum value from users.

"Selling" Users to Market Makers

Like Robinhood, applications on Solana can also "sell access" to market makers.

RFQ (Request for Quote) is a direct manifestation of this logic. Unlike traditional AMMs, RFQ allows users (or applications) to directly request quotes from specific market makers and execute trades. On Solana, aggregators like Jupiter have already integrated this model (JupiterZ). In this system, the application can charge connection fees to these market makers or more directly, bundle and sell retail order flows in bulk. As on-chain price spreads continue to narrow, the author anticipates that this "selling heads" business will become increasingly common.

Moreover, a certain alliance of interests is forming between DEXs and aggregators. Prop AMMs (proprietary market makers) and DEXs heavily rely on the traffic brought by aggregators, and aggregators have the capability to charge these liquidity providers while returning part of the profits as "rebates" to front-end applications.

For instance, when the Phantom wallet routes a user's trade to Jupiter, the underlying liquidity providers (like HumidiFi or Meteora) might pay Jupiter to secure the execution rights for that trade. After receiving this "toll fee," Jupiter then returns a portion of it to Phantom.

Although this speculation has yet to be publicly confirmed, the author believes that under profit-driven motives, such "profit-sharing rules" within the industry chain are almost a natural phenomenon.

Bloodsucking Market Orders

When users click "confirm" and sign in their wallets, this transaction essentially becomes a "market order" with slippage parameters.

For the application side, there are two ways to handle this order:

• Positive Route: Sell the "backrun" (arbitrage opportunity) created by the transaction to professional trading firms, sharing the profits. Backrun refers to when a user's buy order on DEX1 drives up the token price on DEX1, and arbitrage bots subsequently buy on DEX2 within the same block (without affecting the user's buy price on DEX1) and sell on DEX1.

• Negative Route: Assist sandwich attackers in targeting their own users, driving up the users' execution prices.

Even taking the positive route does not guarantee that the application side is acting ethically; to maximize the value of "backrunning," the application may have the incentive to deliberately slow down the transaction's on-chain speed. Driven by profit, the application might also route users to liquidity pools with lower liquidity, artificially creating larger price fluctuations and arbitrage opportunities.

Reports indicate that some well-known front-end applications on Solana are engaging in the aforementioned practices.

Who Takes Your Tips?

If the above methods still involve some technical barriers, then the opaque operations regarding "transaction fees" can be described as "not even pretending."

On Solana, the fees paid by users are actually divided into two parts:

• Priority Fee: This is the fee within the protocol, directly paid to validators.

• Transaction Tip: This is a SOL amount transferred to any address, usually paid to "landing service providers" like Jito. The service provider then decides how much to distribute to validators and how much to rebate back to the application side.

Why are landing service providers necessary? Due to the complexity of communication during congestion on the Solana network, ordinary transaction broadcasts can easily fail. Landing service providers act as "VIP channels," promising users successful on-chain transactions through specialized optimized links.

The complex block builder market and fragmented routing system on Solana have given rise to this special role, creating excellent rent-seeking opportunities for the application side. The application often entices users to pay high tips to "guarantee success," then splits this premium with the landing service provider.

Transaction Flow and Fee Landscape

Let's look at some data. During the week of December 1 to 8, 2025, the entire Solana network generated 450 million transactions.

Among these, Jito's landing service processed 80 million transactions, dominating the market (93.5% of the builder market share). Most of these transactions were related to swaps, oracle updates, and market maker operations.

In this vast pool of traffic, users often pay high fees to "seek speed." But is all this money really used to accelerate transactions?

Not necessarily. Data indicates that low-activity wallets (usually retail investors) pay exorbitant priority fees. Considering that the blocks at that time were not filled, these users were clearly overcharged.

The application exploits users' fear of "transaction failure," enticing them to set extremely high tips, and then pockets this premium through agreements with landing service providers.

Negative Example: Axiom

To illustrate this "harvesting" model more intuitively, the author conducted an in-depth case study on Axiom, a leading application on Solana.

Axiom generates the highest transaction fees in the entire network, not only because it has many users but also because it charges the most.

Data shows that the median priority fee (p50) paid by Axiom users is as high as 1,005,000 lamports. In comparison, high-frequency trading wallets only pay about 5,000 to 6,000 lamports. This represents a 200-fold difference.

The situation is similar regarding tips.

Axiom users pay tips on landing services like Nozomi and Zero Slot that far exceed the market average. The application side exploits users' extreme sensitivity to "speed," completing double charging without any negative feedback.

The author bluntly speculates: "The vast majority of transaction fees paid by Axiom users ultimately end up in the pockets of the Axiom team."

Reclaiming Fee Pricing Power

The severe misalignment between user incentives and application incentives is the root cause of the current chaos. Users do not know what constitutes reasonable fees, while the application side is happy to maintain this confusion.

To break this situation, we need to start from the underlying market structure. Introducing Solana's Multiple Concurrent Proposers (MCP) and Priority Ordering mechanisms around 2026, along with the widely proposed dynamic base fee mechanism, may be the key to solving the problem.

Multiple Concurrent Proposers (MCP)

The current single proposer model on Solana easily leads to temporary monopolies; the application side only needs to deal with the current leader to control transaction packaging rights in a short time. After introducing MCP, multiple proposers will work concurrently in each slot, significantly increasing the costs of attacks and monopolies, enhancing censorship resistance, and making it difficult for the application side to block users by controlling a single node.

Priority Ordering

By mandating "ordering by priority fee" at the protocol level, the randomness of ordering (jitter) is eliminated. This weakens the need for users to rely on private acceleration channels like Jito just to "guarantee success." For ordinary transactions, users no longer need to guess how much tip to give; as long as they pay within the protocol, all validators across the network will prioritize processing based on deterministic rules.

Dynamic Base Fee

This is the most critical step. Solana is attempting to introduce a concept similar to Ethereum's dynamic base fee.

Users will no longer blindly give tips but will explicitly instruct the protocol: "I am willing to pay a maximum fee of X lamports for this transaction to be processed on-chain."

The protocol will automatically price based on the current level of congestion. If there is no congestion, it will charge a low price; if congested, it will charge a high price. This mechanism reclaims the pricing power of fees from the application side and intermediaries, returning it to a transparent protocol algorithm.

Meme culture has brought prosperity to Solana, but it has also sown the seeds of problems, leaving behind a restless profit-seeking gene. For Solana to truly realize the vision of ICM, it cannot allow applications controlling front-end traffic and protocols controlling infrastructure to collude and act at will.

As the saying goes, "Clean the house before inviting guests." Only through upgrades to the underlying technical architecture, using technical means to eliminate rent-seeking soil, and developing a fair, transparent market structure that prioritizes user welfare can Solana truly possess the confidence to integrate and compete with the traditional financial system.