"Hidden Taxes" on Solana

Author: SpecialistXBT

Years ago, an article titled "Payment for Order Flow on Solana" exposed a dark corner of the Solana fee market, generating phenomenal attention on English Twitter.

PFOF (Payment for Order Flow) is already a mature business model in traditional finance. Robinhood used this model to launch its "zero-commission trading" game, quickly breaking through the competition from many established brokerages. This strategy not only made Robinhood incredibly wealthy but also forced industry giants such as Charles Schwab and E-Trade to follow suit, changing the landscape of the US retail brokerage business.

In 2021 alone, Robinhood raked in nearly $1 billion in revenue through PFOFs, accounting for half of its total revenue that year; even in 2025, its quarterly PFOF revenue still reached hundreds of millions of dollars. This demonstrates the exorbitant profits behind this business model. In traditional markets, market makers have a strong preference for retail orders. The reason is simple: retail orders are generally considered "non-toxic," often based on sentiment or immediate needs, and do not contain accurate predictions of future price movements. Market makers can profit from the bid-ask spread by taking these orders without worrying about becoming the counterparty to informed traders (such as institutional investors). Based on this demand, brokerages (such as Robinhood) package user order flows and sell them in bulk to market-making giants like Citadel, thereby collecting huge rebates. In traditional financial markets, regulation has protected retail investors to some extent. The SEC's National Market System Regulation mandates that even bundled orders must be executed at a price no less than the best market price. However, in the unregulated on-chain world, applications are exploiting information asymmetry to induce users to pay priority fees and tips far exceeding actual on-chain needs, quietly pocketing these premiums. This behavior is essentially levying a hefty "hidden tax" on unsuspecting users. Traffic Monetization For applications with a large user base, the means of monetizing traffic are far more diverse than you might imagine. Front-end applications and wallets can determine where user transactions go, how they are executed, and even how quickly they are recorded on the blockchain. Every "key point" in the lifecycle of a transaction hides a business strategy for fully maximizing user value. "Selling" users to market makers: Just like Robinhood, applications on Solana can also sell "access rights" to market makers. RFQ (Request for Quote) is a direct manifestation of this logic. Unlike traditional AMMs, RFQs allow users (or applications) to directly request prices from specific market makers and execute trades. On Solana, aggregators like Jupiter have already integrated this model (JupiterZ). In this system, applications can charge these market makers connection fees, or more directly, package and sell bulk retail order streams. As on-chain price spreads continue to narrow, the author predicts that this "selling users" business will become increasingly common. Furthermore, a kind of alliance of interests is forming between DEXs and aggregators. Prop AMMs (Proprietary Market Makers) and DEXs are heavily reliant on traffic from aggregators, and aggregators are fully capable of charging these liquidity providers and returning a portion of their profits to front-end applications in the form of "rebates." For example, when the Phantom wallet routes a user's transaction to Jupiter, the underlying liquidity provider (such as HumidiFi or Meteora) may pay Jupiter to secure the execution rights of the transaction. After receiving this "channel fee," Jupiter then returns a portion of it to Phantom. While this hypothesis has not been publicly confirmed, the author believes that, driven by profit, this kind of "profit-sharing unspoken rule" within the industry chain is almost a natural phenomenon.

A Market Order That Suckers

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

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

The benign route: Sell the "backrun" opportunity generated by the transaction to a professional trading company, and share the profits. A backrun refers to when a user's buy order in DEX1 pushes up the token price in DEX1, the arbitrage bot immediately follows up by buying in DEX2 within the same block (without affecting the user's buy price in DEX1), and then selling in DEX1.

The malicious route: Assist the sandwich arbitrageur in attacking its own users, pushing up the user's transaction price.

The malicious route: Assist the sandwich arbitrageur in attacking its own users, pushing up the user's transaction price.

Even if they take a benign approach, it doesn't mean the application is ethical. To maximize the value of "tail arbitrage," applications are incentivized to deliberately slow down the on-chain transaction speed. Driven by profit, applications may also intentionally route users to pools with lower liquidity, artificially creating greater price volatility and arbitrage opportunities. According to reports, some well-known front-end applications on Solana are engaging in this practice. Who took your tip? While the above methods still have some technical barriers, the opaque manipulation of "transaction fees" is blatant. On Solana, the fees paid by users are actually divided into two parts: - Priority Fee: This is a protocol-defined fee, paid directly to the validator. - Transaction Tip: This is a SOL payment transferred to any address, typically to a "Landing Service" like Jito. The service provider then decides how much to give to validators and how much to rebate to the application. Why are Landing Services Needed? Because communication on the Solana network is extremely complex during congestion, ordinary transaction broadcasts are prone to failure. Landing Services act as "VIP channels," promising users successful on-chain transactions through specially optimized links. Solana's complex Builder Market and fragmented routing system have created this special role and an excellent opportunity for rent-seeking by applications. Applications often induce users to pay large tips to "guarantee" success, then share this premium with the Landing Service.

Transaction Traffic and Fee Landscape

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

Of these, Jito's landing services processed 80 million transactions, holding a dominant position (93.5% of the builder market share). The vast majority of these transactions were transaction-related swaps, oracle updates, and market maker operations.

In this huge traffic pool, users often pay high fees in pursuit of speed. But is all this money actually used for acceleration?

Not entirely. Data shows that low-activity wallets (usually retail users) pay ridiculously high priority fees.

Given that the block size wasn't full at the time, these users were clearly overcharged. Applications exploit users' fear of "transaction failure" to induce them to set extremely high tips, then pocket this premium through agreements with landing service providers. A prime example is Axiom. To more clearly illustrate this "harvesting" model, the author conducted an in-depth case study of Axiom, a leading application on Solana. Axiom generates the highest transaction fees across the entire network, not only because of its large user base but also because it's the most exploitative. Data shows that the median priority fee (p50) paid by Axiom users is a staggering 1,005,000 lamports. In contrast, high-frequency trading wallets only pay out around 5,000 to 6,000 lamports. That's a 200-fold difference. The same applies to tips. Axiom users tip far more than the market average on landing services like Nozomi and Zero Slot. The application platform exploited users' extreme sensitivity to "speed," charging them twice 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." The root cause of this chaos lies in the severe misalignment between user incentives and application incentives. Users are unaware of what constitutes a reasonable fee, and applications are happy to maintain this chaos. To break this situation, we need to start with the underlying market structure. The introduction of Solana's Multiple Concurrent Proposers (MCP) and Priority Ordering mechanism, along with the widely proposed dynamic base fee mechanism, expected around 2026, may be the only solution to the problem. The current Solana single-proposer model is prone to creating temporary monopolies; applications can control transaction packaging rights for a short period simply by controlling the current leader. With the introduction of MCP, multiple proposers work concurrently in each slot, significantly increasing the cost of attacks and monopolies, improving censorship resistance, and making it difficult for applications to control a single node to block users.

Priority Ordering

This mechanism enforces a "priority fee-based" ordering at the protocol layer, eliminating the randomness (jitter) of the ordering process. This reduces the need for users to rely on private acceleration channels like Jito simply to "guarantee a pass." For ordinary transactions, users no longer need to guess how much to tip; as long as they pay within the protocol's limits, validators across the network will prioritize their transactions 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 are no longer blindly tipping, but explicitly instructing the protocol: "I am willing to pay up to X Lamports for this transaction to be recorded on-chain."

The protocol automatically prices based on the current congestion level. If there is no congestion, a low price is charged; if there is congestion, a high price is charged. This mechanism wrests the pricing power of fees back from applications and intermediaries, returning it to the transparent protocol algorithm.

Memes brought prosperity to Solana, but they also sowed the seeds of problems, leaving behind a profit-driven and superficial gene. If Solana wants to truly realize its ICM vision, it cannot allow applications that control front-end traffic and protocols that control infrastructure to collude and act arbitrarily. As the saying goes, "Clean the house before you invite guests," only by upgrading its underlying technical architecture, using technological means to eradicate the breeding ground for rent-seeking, and developing a fair, transparent market structure that prioritizes user welfare, can Solana truly possess the confidence to integrate with and compete with the traditional financial system.