Solana Users Beware: Your SOL Is Being Quietly Harvested in These Ways

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. It was precisely this model that allowed Robinhood to play its "zero-commission trading" trump card, enabling it to break 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 US retail brokerage.

In 2021 alone, Robinhood raked in nearly $1 billion from PFOF, accounting for half of its total revenue for the year. Even by 2025, its quarterly PFOF revenue remained in the hundreds of millions of dollars, highlighting 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 generally considered "non-toxic," often driven by sentiment or immediate needs, lacking precise predictions of future price movements. By taking these orders, market makers can profit from the bid-ask spread without worrying about being on the opposite side of 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, collecting substantial kickbacks in return.

Regulation in traditional financial markets offers some protection for retail investors. The SEC's Regulation NMS mandates that even bundled orders must be executed at a price no worse than the National Best Bid and Offer (NBBO).

However, in the unregulated on-chain world, applications exploit 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 "gateway" in a transaction's lifecycle harbors a business logic aimed at extracting maximum value from users.

"Selling" Users to Market Makers

Just like Robinhood, applications on Solana can sell "access rights" 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). In this system, the application side can charge connection fees to these market makers or, more directly, bundle and sell retail order flow in bulk. As on-chain spreads continue to narrow, the author predicts this "selling of user access" 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 provider (like HumidiFi or Meteora) might pay Jupiter to secure the execution rights for that trade. After receiving this "channel fee," Jupiter would then rebate 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.

Extractive 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 to handle 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 buys on DEX2 within the same block (without affecting the user's purchase price on DEX1) and then sells on DEX1.

The Malignant Path: Assist "sandwich" attackers (front-running bots) in attacking 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's confirmation speed. Driven by profit, the application might also intentionally route users to pools with poorer liquidity, artificially creating larger price fluctuations and arbitrage opportunities.

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

Who Takes Your Tip?

If the aforementioned methods require some technical expertise, then the opaque operations around "transaction fees" can be described as "not even trying to hide it."

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

- Priority Fee: This is a protocol-level 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? Due to the extreme complexity of communication during Solana network congestion, regular transaction broadcasting is prone to failure. Landing Services act as "VIP channels," promising users successful on-chain confirmation through optimized, dedicated pathways.

Solana's complex builder market and fragmented routing system have given rise to this special role, creating an excellent opportunity for rent-seeking by the application side. Applications often induce users to pay high tips to "guarantee" confirmation, then split this premium with the landing service.

Transaction Traffic & Fee Landscape

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

Among these, Jito's landing service handled 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 exorbitantly high priority fees. Considering 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.

Axiom: A Negative Case Study

To more clearly 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 of its large user base but also because it charges users the most aggressively.

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 200x difference.

The situation is similar with Tips.

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

The author speculates bluntly: "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 a reasonable fee is, 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 mechanisms around 2026, along with the widely proposed Dynamic Base Fee mechanism, may be the ultimate solution.

Multiple Concurrent Proposers (MCP)

Solana's current single-proposer model is prone to forming temporary monopolies. The application side only needs to influence 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 monopolization, enhancing censorship resistance, and making it difficult for applications to corner users by controlling a single node.

Priority Ordering Mechanism

By mandating "ordering by priority fee" at the protocol layer, the randomness (Jitter) in ordering is eliminated. This reduces users' need to rely solely on private acceleration channels like Jito just to "guarantee" confirmation. 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. Instead, they 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; if it is congested, it charges a higher price. This mechanism reclaims fee pricing power from applications and intermediaries, handing it back to a transparent protocol algorithm.

Memes brought prosperity to Solana but also left behind a problematic legacy—a浮躁的逐利基因 (flawed, profit-chasing DNA). 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 technological 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.