Earlier this year, an article titled "Payment for Order Flow on Solana" exposed a dark corner of Solana's fee market, sparking a phenomenon-level discussion on English Twitter.
PFOF (Payment for Order Flow) is already a mature business model in traditional finance. Robinhood used this model to play the "zero-commission trading" trump card, quickly breaking through from many established brokers. This strategy not only made Robinhood immensely profitable but also forced industry giants like 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 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 shows 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"—they are often based on emotion or immediate needs and do not contain precise predictions of future price movements. Market makers can take these orders, steadily profit from the bid-ask spread, and not worry about being the counterparty to informed traders (like large institutions).
Based on this demand, brokers (like Robinhood) package their users' order flow and sell it in bulk to market maker giants like Citadel, receiving huge kickbacks in return.
Regulations in traditional financial markets offer some protection for retail investors. The SEC's Regulation National Market System (Reg NMS) mandates that even orders sold in packages must be executed at a price no worse than the best available 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 the actual on-chain requirements, and quietly pocket these premiums. This behavior essentially levies a lucrative "stealth tax" on unsuspecting users.
Monetizing Traffic
For applications that control major user entry points, the methods for monetizing traffic are far more numerous than you might imagine.
Front-end applications and wallets can decide where a transaction goes, how it gets executed, and even how quickly it lands on-chain. Every "checkpoint" in a transaction's lifecycle hides business opportunities to extract every last bit of value from the user.
"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 integrated this model (JupiterZ). In this system, the application side can charge these market makers a connection fee, or more directly, sell packaged retail order flow in bulk. As on-chain spreads continue to narrow, the author expects this "selling users" business to become increasingly common.
Furthermore, a certain alliance of interests is forming between DEXs and aggregators. Prop AMMs (Proprietary AMMs) and DEXs are highly dependent on the traffic brought by aggregators, and aggregators are fully capable of charging these liquidity providers and returning part 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 right to execute this trade. After receiving this "conduit fee," Jupiter then rebates a portion of it back to Phantom.
Although this speculation has not been publicly confirmed, the author believes that, driven by profit, this kind of "profit-sharing under-the-table rule" within the industry chain is an almost natural phenomenon.
Bloodsucking 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:
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 after, within the same block) buys on DEX2 (without affecting the user's purchase price on DEX1) and sells on DEX1.
Malicious Path: Assist sandwich attackers (sandwich arbitrageurs) in attacking their own users, pushing up the user's 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 landing speed on-chain. Driven by profit, the application side might also intentionally route users to pools with poorer liquidity, artificially creating larger price fluctuations and arbitrage space.
Reports indicate that some well-known front-end applications on Solana are engaged in the aforementioned operations.
Who Took Your Tip?
If the above methods involve some technical threshold, then the black-box operations on "transaction fees" can be called "not even pretending."
On Solana, the fees paid by users actually consist of two parts:
- Priority Fee: This is a protocol-level fee, paid directly to validators.
- Transaction Tip: This is a transfer of SOL to any address, typically paid to "Landing Services" like Jito. The service provider then decides how much to give to the validator and how much to rebate back to the application side.
Why are Landing Services needed? Because communication on the Solana network is extremely complex during congestion, and ordinary transaction broadcasting can easily fail. Landing Services act as a "VIP channel," promising users successful on-chain landing through specialized optimized pathways.
Solana's complex builder market and fragmented routing system have given rise to this special role, also creating perfect rent-seeking opportunities for the application side. Applications often induce users to pay high tips to "guarantee" transaction success, and 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 to 8, 2025, the Solana network generated 450 million transactions.
Among them, Jito's landing service processed 80 million transactions, dominating the market (93.5% builder market share). The vast majority of these transactions were Swaps, oracle updates, and market maker operations related to trading.
In this huge pool of traffic, users often pay high fees to "go fast." But is all this money really used for acceleration?
Not entirely. Data shows that low-activity wallets (typically retail users) pay ridiculously high priority fees. Considering that blocks were not full at the time, these users were clearly overcharged.
The application side exploits users' fear of "transaction failure" to induce them to set extremely high tips, and then, through agreements with landing services, pockets this premium.
Negative Example: Axiom
To more直观地 (intuitively) demonstrate this "harvesting" model, the author conducted an in-depth case study on the leading Solana application, Axiom.
Axiom generates the highest transaction fees on the entire network, not only because it has many users but also because it charges the most exorbitantly.
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. This is a 200-fold 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 takes advantage of users' extreme sensitivity to "speed" and, without any negative feedback, completes this double charging of users.
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."
Recapturing 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 chaos.
To break this situation, we need to start with the underlying market structure. The anticipated introduction of Multiple Concurrent Proposers (MCP) and Priority Ordering mechanism 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 forming temporary monopolies. The application side only needs to deal with the current Leader to control transaction packaging rights for a short time. Introducing MCP means multiple proposers work concurrently per slot, significantly increasing the cost of attacks and monopolization, enhancing anti-censorship, and making it harder for the application side to corner users by controlling a single node.
Priority Ordering Mechanism
Mandating "sorting by priority fee height" at the protocol layer eliminates sorting randomness (Jitter). This weakens the user's need to rely solely on private acceleration channels like Jito just to "guarantee" transaction 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 critical step. Solana is trying 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 land 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 takes the pricing power of fees away from the application side and middlemen and returns it to the transparent protocol algorithm.
Memes brought prosperity to Solana but also left behind a浮躁的逐利基因 (floating, profit-chasing gene). For Solana to truly realize the vision of ICM (Internet Commodity Market), it cannot let applications controlling front-end traffic and protocols controlling infrastructure act in collusion and do whatever they want.
As the saying goes, "clean the house before inviting guests." Only through underlying technological architecture upgrades, 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.
