Solana users, beware: your SOL is being quietly harvested through these methods

Years ago, an article titled “Payment for Order Flow on Solana” unveiled a dark corner of Solana’s fee market, sparking phenomenon-level attention on English Twitter.

PFOF (Payment for Order Flow) has long been a mature business model in traditional finance. Robinhood played this model perfectly, launching “zero-commission trading” as its trump card and rapidly breaking through the competition from established brokers. 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 American retail brokerage.

In 2021 alone, Robinhood raked in nearly $1 billion in PFOF revenue, accounting for half of its total annual revenue; even by 2025, its quarterly PFOF income remains in the hundreds of millions of dollars. This testament to the enormous profit potential behind this business model.

In traditional markets, market makers extremely favor retail orders. The reason is simple: retail orders are typically considered “harmless.” They’re usually based on emotion or immediate needs, lacking precise predictions about future price movements. Market makers can profit from the bid-ask spread on these orders without worrying about facing sophisticated traders (like institutional investors).

Based on this demand, brokers (like Robinhood) package user order flow and sell it in bulk to market-making giants like Citadel, collecting substantial rebates.

In traditional financial markets, regulatory oversight to some extent protects retail investors. The SEC’s Regulation of the National Market System mandates that even packaged orders must receive execution prices no worse than the best market price available.

However, in the unregulated on-chain world, applications are exploiting information asymmetries, inducing users to pay priority fees and tips far exceeding actual on-chain requirements, while quietly pocketing these premiums. This behavior essentially levies an exorbitant “hidden tax” on unsuspecting users.

Monetizing Traffic

For applications controlling massive user gateways, the methods for monetizing traffic are far richer than you might imagine.

Front-end applications and wallets can decide where user transactions go, how they’re executed, and how quickly they’re settled on-chain. Every “checkpoint” in a transaction’s lifecycle conceals business opportunities to extract maximum user value.

“Selling” Users to Market Makers

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, RFQ allows users (or applications) to directly query 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 connection fees to these market makers, or more directly, package and sell batches of retail order flow. As on-chain spreads continue to narrow, the author predicts this “selling user access” business will become increasingly prevalent.

Additionally, DEXs and aggregators are forming certain interest alliances. Prop AMMs (proprietary market makers) and DEXs are heavily dependent on traffic brought by aggregators, while aggregators have complete ability to charge these liquidity providers fees and return part of the profits to front-end applications as “rebates.”

For example, when Phantom wallet routes a user’s trade to Jupiter, the underlying liquidity providers (such as HumidiFi or Meteora) may pay Jupiter to secure execution rights for that trade. After Jupiter receives this “channel fee,” it returns a portion as a rebate to Phantom.

While this speculation hasn’t been publicly confirmed, the author believes that driven by financial incentives, such “profit-sharing unwritten rules” within the industry chain are virtually inevitable phenomena.

Bloodsucking Market Orders

When users click “confirm” and sign in their wallet, this transaction is essentially a “market order” with slippage parameters.

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

The virtuous path: Sell the “Backrun” (sandwich arbitrage) opportunities created by the transaction to professional trading firms and share profits. Backrun refers to when a user’s buy order on DEX1 pushes up the token price on DEX1, arbitrage robots immediately follow and buy on DEX2 in the same block (not affecting the user’s buy price on DEX1), then sell on DEX1.

The malicious path: Assist sandwich attackers (MEV searchers) in attacking their own users, pushing up users’ execution prices.

Even the virtuous path doesn’t mean the application has good intentions. To maximize the value of “backrun” arbitrage, applications have incentive to deliberately slow down the transaction settlement. Driven by profit, applications may even intentionally route users to pools with poor liquidity to artificially create larger price fluctuations and arbitrage opportunities.

According to reports, some leading front-end applications on Solana are conducting such operations.

Who Took Your Tips?

If the above methods still carry some technical barriers, the under-the-table manipulation of “transaction fees” is nothing short of blatant.

On Solana, fees paid by users actually consist of two parts:

• Priority Fees: These are protocol-level fees paid directly to validators.

• Transaction Tips: This is SOL transferred to any address, typically paid to “Landing Services” like Jito. The service provider then decides how much to give validators and how much to return (rebate) to the application.

Why are landing services needed? Because Solana network communication becomes extremely complex during congestion, regular transaction broadcasts often fail. Landing services play the role of a “VIP channel,” using optimized routing paths to guarantee successful transaction settlement on-chain.

Solana’s complex Builder Market and fragmented routing system have spawned this special role, while creating excellent rent-seeking opportunities for applications. Applications often induce users to pay high tips to “ensure passage,” then split this premium with landing services.

Transaction Traffic and Fee Landscape

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

Among these, Jito’s landing service processed 80 million transactions, commanding a dominant position (93.5% of builder market share). Most of these transactions were swap-related, oracle updates, and market maker operations.

In this massive traffic pool, users often pay high fees to “go fast.” But are all these fees actually spent on acceleration?

Not entirely. Data shows that low-activity wallets (typically retail users) pay exorbitant 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, then pocket this premium through agreements with landing services.

Axiom as a Cautionary Example

To more directly demonstrate this “extraction” model, the author conducted an in-depth case study of Axiom, a top application on Solana.

Axiom generates the highest transaction fees network-wide, not only because it has many users but also because it charges them most aggressively.

Data shows the median (p50) priority fee paid by Axiom users reaches 1,005,000 lamports. By contrast, high-frequency trading wallets pay only about 5,000 to 6,000 lamports. That’s a 200x difference.

The situation with tips is similar.

Axiom users pay tips on landing services like Nozomi and Zero Slot far exceeding market averages. Applications have completed double-charging users by exploiting their extreme sensitivity to “speed,” without any negative feedback.

The author bluntly speculates: “The vast majority of transaction fees paid by Axiom users ultimately end up in Axiom’s pockets.”

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 reasonable fees, and applications are happy to maintain this confusion.

To break this deadlock, we need to start from the underlying market structure. The introduction of Solana’s Multiple Concurrent Proposers (MCP) and Priority Ordering mechanisms, as well as widely proposed dynamic base fee mechanisms around 2026, may be the solution.

Multiple Concurrent Proposers (MCP)

The current Solana single-proposer model is prone to temporary monopolies. Applications only need to secure the current Leader to control transaction packing rights for a short time. With MCP, each slot has multiple proposers working concurrently, significantly increasing attack and monopoly costs, enhancing censorship resistance, and making it difficult for applications to blockade users through controlling a single node.

Priority Ordering

By enforcing “ordering by priority fee” at the protocol level, the randomness (jitter) in sequencing is eliminated. This reduces users’ forced reliance on private acceleration channels like Jito merely to “ensure passage.” For normal 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 critical step. Solana is attempting to introduce a concept similar to Ethereum’s dynamic base fee.

Instead of blindly giving tips, users explicitly issue an instruction to the protocol: “I’m willing to pay a maximum of X lamports for this transaction to settle on-chain.”

The protocol auto-prices based on current congestion. If uncongested, it charges a low rate; if congested, it charges a high rate. This mechanism reclaims fee pricing power from applications and middlemen, returning it to the transparent protocol algorithm.

Memes brought prosperity to Solana, but also left behind problems and a restless profit-seeking culture. For Solana to truly realize ICM’s vision, it cannot allow applications controlling front-end traffic and protocols controlling infrastructure to collude and act arbitrarily.

As the saying goes, “clean house before inviting guests.” Only through underlying technical architecture upgrades, eliminating the soil for rent-seeking with technological means, and developing a fair, transparent market structure that prioritizes user welfare, can Solana truly possess the confidence to integrate with and compete against traditional finance.