Solana's "Phantom Tax"

A few years ago, an article titled "Payment for Order Flow on Solana" uncovered a dark corner of the Solana fee market, sparking a viral phenomenon on English Twitter.

PFOF (Payment for Order Flow) has long been a mature business model in traditional finance. Robinhood, through this model, played the "zero-commission trading" card, quickly breaking away from numerous old-school brokerages. This strategy not only filled Robinhood's coffers but also compelled industry giants like JPMorgan Wealth Management and E-Trade to follow suit, reshaping the landscape of the U.S. retail brokerage business.

In just 2021, Robinhood raked in nearly $1 billion in revenue through PFOF, accounting for half of its total revenue that year; even by 2025, its quarterly PFOF revenue still reaches hundreds of millions of dollars. This clearly demonstrates the massive profits behind this business model.

In the traditional market, market makers greatly favor retail orders. The reason is simple—retail orders are often viewed as "non-toxic," typically based on emotion or immediate need, without precise predictions of future price movements. Market makers take these orders, ensuring a profit from the bid-ask spread, without the worry of facing informed traders (like institutional investors) on the other side.

To meet this demand, brokerages (like Robinhood) bundle users' order flow and sell it in bulk to market-making giants like Citadel, thereby receiving substantial rebates.

In the traditional financial market, regulation to some extent protects retail investors, with the SEC's "National Market System Regulation NMS" mandating that even orders sold in bulk must receive execution no worse than the market's best price.

However, in the unregulated world of blockchain, applications are leveraging information asymmetry, enticing users to pay priority fees and tips far above the actual on-chain demand, quietly siphoning off these premiums. This behavior fundamentally represents levying an invisible "tax" on unsuspecting users.

Monetizing Traffic

For apps holding a significant user gateway, the means of monetizing traffic are far richer than you might imagine.

Front-end applications and wallets can decide where users' transactions go, how they are executed, and even how quickly they get on-chain. Every "checkpoint" in a transaction's lifecycle conceals the business of "stripping users' value to the bone."

"Selling" Users to Market Makers

Just like Robinhood, applications on Solana can also sell "access rights" to liquidity providers.

RFQ (Request for Quote) is a direct embodiment of this logic. Unlike traditional AMMs, RFQ allows users (or applications) to directly request quotes from specific liquidity providers and execute trades. On Solana, aggregators like Jupiter have already integrated this model (JupiterZ). In this system, the application side can charge a connection fee to these liquidity providers, or even more directly, sell batches of retail orders flow. As the on-chain spread continues to narrow, the author expects this "selling order flow" business to become more common.

Furthermore, there is also a forming alliance of interest between DEXes and aggregators. Prop AMMs (proprietary liquidity providers) and DEXes heavily rely on the traffic brought in by the aggregator, and the aggregator is fully capable of charging these liquidity providers and returning a portion of the profits to the front-end application as a "rebate."

For example, when the Phantom wallet routes a user's trade to Jupiter, the underlying liquidity provider (such as HumidiFi or Meteora) may pay Jupiter in order to compete for the execution of that trade. After receiving this "routing fee," Jupiter then returns a portion of it to Phantom.

While this speculation has not been publicly confirmed, the author believes that, driven by self-interest, this "profit-sharing unwritten rule" within the industry chain is almost a natural phenomenon.

Vampire Market Order

When a user clicks "confirm" and signs in the wallet, this transaction is essentially a "market order" with a slippage parameter.

For applications, there are two ways to handle this order:

Benign Route: Selling the arbitrage opportunity generated by the transaction to professional trading firms, sharing the profits. The so-called Backrun refers to when a user's buy order on DEX1 drives up the token price in DEX1, arbitrage bots then buy in DEX2 in the same block (without affecting the user's buy price on DEX1) and sell on DEX1.

Malicious Route: Assisting sandwichers (sandwich arbitrageurs) to attack their own users, driving up the user's execution price.

Even taking the benign route does not mean the application side is ethical. To maximize the value of "arbitrage tailgating," the application side has an incentive to deliberately slow down transaction on-chain speed. Driven by profit motives, the application side may also intentionally route users to pools with lower liquidity in order to artificially create greater price fluctuations and arbitrage opportunities.

According to reports, some well-known front-end applications on Solana are engaging in the above practices.

Who Took Your Tip?

If the above methods still have some technical barriers, then the clandestine operation in "transaction fees" can be considered a full-blown performance.

On Solana, the fee users pay is actually divided into two parts:

- Priority Fee: This is the protocol fee paid directly to validators.

- Transaction Tip: This is an amount of SOL sent to any address, usually paid to a "Landing Service" like Jito. The service provider then decides how much to give to the validator and how much to rebate back to the application end.

Why the need for a Landing Service? Because communication on the Solana network is highly complex during congestion, ordinary transaction broadcasts easily fail. Landing services play the role of a "VIP channel," promising users on-chain transaction success through a specially optimized pathway.

Solana's complex Builder Market and fragmented routing system have given rise to this unique role, creating excellent rent-seeking opportunities for the application end. Applications often entice users to pay high tips for a "guaranteed" transaction and then share this premium with the Landing Service provider.

Transaction Traffic and Fee Landscape

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

Among them, Jito's Landing Service processed 80 million transactions, dominating the market (93.5% Builder Market share). And within these transactions, the vast majority were related to swaps, oracle updates, and liquidity provider operations.

In this massive pool of traffic, users often pay high fees in pursuit of speed. But was all this money truly spent to expedite transactions?

Not necessarily. Data indicates that low-activity wallets (usually retail investors) paid exorbitantly high Priority Fees. Considering the blocks were not full at the time, these users were evidently overcharged.

Applications leverage users' fear of "transaction failure," enticing them to set extremely high tips, and then, through an agreement with the Landing Service provider, pocket this surplus income.

Anti-Pattern Axiom

To illustrate this "harvesting" pattern more intuitively, the author conducted an in-depth case study of the Axiom top app on Solana.

The transaction fees generated by Axiom lead the entire network, not only because of its large user base but also because it is the most ruthless in milking its users.

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

The same is true for tips.

Axiom users pay significantly higher tips on landing services such as Nozomi and Zero Slot compared to the market average. The app side cleverly exploits users' extreme sensitivity to "speed" and, without any negative feedback, achieves double charging of users.

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

Reclaiming Fee Setting Power

The severe misalignment between user incentives and app incentives is the root cause of the current chaos. Users do not know what a reasonable fee is, and the app side is happy to maintain this chaos.

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

Multiple Concurrent Proposers

The current Solana single proposer model is prone to temporary monopolies, where the app side only needs to handle the current Leader to quickly control transaction packaging. With the introduction of MCP, multiple proposers work concurrently in each slot, significantly increasing the cost of attacks and monopolies, enhancing censorship resistance, making it difficult for the app side to block users by controlling a single node.

Priority Ordering Mechanism

By protocol-level enforcement of "ordering by fee priority," the randomness of ordering (Jitter) is eliminated. This reduces the need for users to rely on private acceleration channels like Jito just to ensure transaction inclusion. For regular transactions, users no longer need to guess how much fee to provide. They simply send the payment within the protocol, and all network validators will prioritize transactions 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 no longer blindly tip but instead explicitly instruct the protocol: "I am willing to pay up to X Lamports as the fee for this on-chain transaction."

The protocol automatically prices transactions based on the current level of congestion. If uncongested, only a low fee is charged; if congested, a higher fee is collected. This mechanism takes the pricing power away from the application side and intermediaries, returning it to a transparent protocol algorithm.

Memes have brought prosperity to Solana but have also left behind a deep-rooted problem, fostering a restless profit-seeking gene. For Solana to truly realize the vision of an ICM, it cannot allow applications controlling frontend traffic and protocols controlling infrastructure to act recklessly and selfishly.

As the saying goes, "Clean the house before inviting guests." Only by upgrading the underlying technical architecture, using technological means to eradicate rent-seeking behavior, and developing a market structure that is fair, transparent, and prioritizes user welfare, can Solana truly have the confidence to integrate and compete with the traditional financial system.