The "Invisible Tax" on Solana
TechFlow Selected TechFlow Selected
The "Invisible Tax" on Solana
Who is secretly taking your Sol?
Navigating Web3 tides with focused insightsWritten by: SpecialistXBT
Earlier this year, an article titled "Payment for Order Flow on Solana" exposed a dark corner of Solana's fee market, sparking phenomenal attention on English Twitter.
PFOF (Payment for Order Flow) has long been a mature business model in traditional finance. Robinhood used this very model to play its "zero-commission trading" trump card, rapidly breaking through the ranks of established brokerages. This strategy not only filled Robinhood's coffers but also forced industry giants like Charles Schwab and E-Trade to follow suit, reshaping the landscape of U.S. retail brokerage.
In 2021 alone, 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 remains in the hundreds of millions of dollars. This clearly demonstrates the immense profitability behind this business model.
In traditional markets, market makers have a strong preference for retail orders. The reason is simple: retail orders are typically considered "non-toxic," often based on emotion or immediate needs and lacking precise predictions of future price movements. By taking these orders, market makers can reliably profit from the bid-ask spread without worrying about being counterparties to informed traders (like institutional whales).
Based on this demand, brokerages (like Robinhood) bundle their users' order flow and sell it in bulk to market-making giants like Citadel, thereby receiving hefty rebates.
Regulation in traditional financial markets offers some protection for retail investors. The SEC's Regulation National Market System mandates that even bundled and sold orders must be executed at prices no worse than the National Best Bid and Offer (NBBO).
However, in the unregulated on-chain world, applications are exploiting information asymmetry to induce users to pay priority fees and tips far exceeding the actual on-chain requirements, quietly pocketing these premiums. This practice essentially levies a highly profitable "invisible tax" on unsuspecting users.
Monetizing Traffic
For applications that control major user entry points, the methods for monetizing traffic are far more diverse than one might imagine.
Front-end applications and wallets can determine where users' transactions go, how they are executed, and even how quickly they are confirmed on-chain. Every "checkpoint" in a transaction's lifecycle harbors a business logic aimed at extracting the maximum value from users.
"Selling" Users to Market Makers
Just like Robinhood, applications on Solana can 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 request quotes directly from specific market makers and execute trades. On Solana, aggregators like Jupiter have already integrated this model (JupiterZ). Within this system, the application side can charge these market makers connection fees or, more directly, sell bundled retail order flow in bulk. As on-chain spreads continue to narrow, the author anticipates this "selling heads" business will become increasingly common.
Furthermore, a certain alliance of interests is forming between DEXs and aggregators. Prop AMMs (Proprietary AMMs) and DEXs heavily rely on the traffic brought by aggregators, and aggregators are fully capable of charging these liquidity providers and returning a portion of the profits as "rebates" to the front-end applications.
For example, when the Phantom wallet routes a user's transaction to Jupiter, the underlying liquidity providers (like HumidiFi or Meteora) might pay Jupiter to secure the execution rights for that transaction. After receiving this "channel fee," Jupiter then rebates a portion back to Phantom.
While this speculation hasn't been publicly confirmed, the author believes that, driven by profit, such "hidden rules of profit-sharing" within the industry chain are almost a natural phenomenon.
Exploitative Market Orders
When a user clicks "Confirm" and signs in their wallet, the transaction is essentially a "Market Order" with a slippage parameter.
For the application side, there are two paths for handling this order:
The Benign Path: Sell the "Backrun" (trailing arbitrage) opportunity generated by the transaction to professional trading firms and share the profits. A Backrun refers to when a user's buy order on DEX1 pushes up the token price on DEX1, and an arbitrage bot immediately follows, buying on DEX2 within the same block (without affecting the user's purchase price on DEX1) and then selling on DEX1.
The Malicious Path: Assist sandwich attackers in targeting their own users, pushing up the users' execution price.
Even taking the benign path doesn't mean the application side has a conscience. To maximize the value of "trailing arbitrage," the application side has an incentive to deliberately slow down the transaction confirmation speed. Driven by profit, the application side might also intentionally route users to pools with poorer liquidity, artificially creating larger price fluctuations and arbitrage opportunities.
Reports indicate that some well-known front-end applications on Solana are engaging in the above practices.
Who Takes Your Tip?
If the aforementioned methods involve some technical barriers, then the opaque operations on "transaction fees" can be described as "not even pretending anymore."
On Solana, the fees users pay are actually divided into two parts:
- Priority Fee: This is an in-protocol fee paid directly to validators.
- Transaction Tip: This is a SOL transfer to any address, typically paid to "Landing Services" like Jito. The service then decides how much to give to validators and how much to rebate back to the application side.
Why are Landing Services needed? Because Solana network communication becomes extremely complex during congestion, making regular transaction broadcasts prone to failure. Landing Services act as "VIP channels," promising users successful on-chain confirmation through specialized optimized pathways.
Solana's complex block builder market and fragmented routing system have given rise to this special role, also creating excellent rent-seeking opportunities for the application side. Applications often induce users to pay high tips to "guarantee" success, then split this premium with the Landing Service.
Transaction Traffic and Fee Landscape
Let's look at some data. During the week of December 1-8, 2025, the Solana network generated 450 million transactions.
Among these, Jito's Landing Service processed 80 million transactions, dominating the market (93.5% builder market share). The vast majority of these transactions were Swap-related, oracle updates, and market maker operations.
Within this massive traffic pool, users often pay high fees to "get fast." But is all that money actually used for acceleration?
Not entirely. Data shows that low-activity wallets (typically retail users) pay outrageously high priority fees. Considering the blocks weren't full at the time, these users were clearly overcharged.
Applications exploit users' fear of "transaction failure," inducing them to set extremely high tips, and then, through agreements with Landing Services, pocket this premium.
A Negative Example: Axiom
To more vividly illustrate this "harvesting" model, the author conducted an in-depth case study on Axiom, a leading application on Solana.
Axiom generates the highest transaction fees on the network, not only because it has many users but also because it charges them the most.
Data shows that the median (p50) priority fee paid by Axiom users is as high as 1,005,000 lamports. In contrast, high-frequency trading wallets pay only about 5,000 to 6,000 lamports. That's 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" and, without any negative feedback, completes a double charge on users.
The author bluntly speculates: "The vast majority of transaction fees paid by Axiom users ultimately end up back 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 don't know what constitutes a reasonable fee, and the application side is happy to maintain this confusion.
To break this situation, we need to start with the underlying market structure. The anticipated introduction of Multiple Concurrent Proposers (MCP) and Priority Ordering around 2026, along with the widely proposed Dynamic Base Fee mechanism, might be the ultimate solution.
Multiple Concurrent Proposers (MCP)
Solana's current single-proposer model is prone to temporary monopolies. The application side only needs to secure the current Leader to control transaction bundling rights for a short period. With MCP, multiple proposers work concurrently in each slot, significantly increasing the cost 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
Enforcing "ordering by priority fee" at the protocol layer eliminates sorting randomness (Jitter). This weakens users' forced reliance on private acceleration channels like Jito merely 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 network validators will prioritize processing based on deterministic rules.
Dynamic Base Fee
This is the most crucial step. Solana is attempting to introduce a concept similar to Ethereum's Dynamic Base Fee.
Users no longer blindly give tips but explicitly instruct the protocol: "I am willing to pay a maximum of X Lamports for this transaction to be confirmed on-chain."
The protocol automatically prices based on current congestion levels. If it's not congested, it charges a low price; only if it's congested does it charge a high price. This mechanism reclaims fee pricing power from the application side and intermediaries, returning it to a transparent protocol algorithm.
Memes brought prosperity to Solana but also left a lingering ailment—a restless, profit-chasing 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 recklessly.
As the saying goes, "Clean the house before inviting guests." Only through upgrades to the underlying technical architecture, using technical means to eradicate the soil for rent-seeking, 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.
Join TechFlow official community to stay tuned
Telegram:https://t.me/TechFlowDaily
X (Twitter):https://x.com/TechFlowPost
X (Twitter) EN:https://x.com/BlockFlow_News
BlockBeats
