header-langage
简体中文
繁體中文
English
Tiếng Việt
한국어
日本語
ภาษาไทย
Türkçe
Scan to Download the APP

Solana's "Phantom Tax"

2026-01-06 07:12
Read this article in 17 Minutes
Who's been stealing your Sol secretly?

Earlier this year, an article titled "Payment for Order Flow on Solana" uncovered a dark corner of the Solana fee market, sparking a viral phenomenon on English Crypto Twitter.


PFOF (Payment for Order Flow) has long been a mature business model in traditional finance. Robinhood, through this model, played the trump card of "commission-free trading," swiftly breaking free from numerous traditional brokers. This strategy not only filled Robinhood's coffers, but also forced industry giants like JPMorgan Wealth Management and E-Trade to follow suit, reshaping the landscape of the U.S. retail brokerage business.


In just 2021, 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 is a clear sign of the windfall behind this business model.


In the traditional market, market makers heavily favor retail orders. The reason is simple: retail orders are often seen as "order flow toxic-free," typically based on emotion or immediate need, without precise predictions of future price movements. Market makers taking these orders can easily earn the bid-ask spread without worrying about trading against informed traders (such as institutional investors).


Based on this demand, brokers (like Robinhood) bundle user order flow and sell it in bulk to market maker giants like Citadel, thus receiving substantial rebates.


In traditional financial markets, regulation to some extent protects retail investors. The SEC's "Regulation NMS (National Market System)" mandates that even orders sold in bulk must receive execution at a price no worse than the market's best available price.


However, in the unregulated world of blockchain, applications are leveraging information asymmetry, enticing users to pay priority fees and tips far above the actual on-chain demand, quietly siphoning off these premiums. This behavior fundamentally imposes an invisible tax of windfall profits on unsuspecting users.


Monetizing Traffic


For applications holding a large number of user entry points, the means of traffic monetization are far richer than you might imagine.


Front-end applications and wallets can determine where a user's transaction goes, how it is executed, and even how quickly it is processed on-chain. Every "checkpoint" in a transaction's lifecycle conceals a business practice aimed at profiting off user value at every turn.


"Selling" Users to Market Makers


Just like Robinhood, applications on Solana can also sell "access rights" to liquidity providers.


RFQ (Request for Quote) embodies this logic directly. Unlike traditional AMMs, RFQ allows users (or applications) to directly request quotes from specific liquidity providers and execute trades. On Solana, aggregators like Jupiter have integrated this model (JupiterZ). In this system, the application side can charge a connection fee to these liquidity providers, or more directly, sell batched retail order flow. As on-chain spreads continue to narrow, the author expects this "selling of access" business to become more common.


Additionally, there is a forming alliance of sorts between DEXes and aggregators. Prop AMMs (proprietary liquidity providers) and DEXes rely heavily on the traffic brought in by aggregators, and aggregators are fully capable of charging these liquidity providers and redistributing some of the profits back to frontend applications in the form of "kickbacks."


For example, when the Phantom wallet routes a user's trade to Jupiter, the underlying liquidity provider (such as HumidiFi or Meteora) may pay Jupiter to compete for the execution of that trade. After receiving this "channel fee," Jupiter may then rebate a portion back to Phantom.


While this speculation has not been publicly confirmed, the author believes that, driven by incentives, this kind of "profit-sharing unwritten rule" within the industry is almost a natural phenomenon.


Dracula Swap


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


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


Benign Route: Sell the trade-induced "Backrun" (front-running arbitrage) opportunity to a professional trading firm, sharing the proceeds. Backrun refers to when a user's buy order on DEX1 drives up the token price on DEX1, arbitrage bots swiftly buy on DEX2 in the same block (without affecting the user's buy price on DEX1) and sell on DEX1.


Malicious Route: Assist sandwichers (sandwich arbitrageurs) in attacking their own users, driving up the user's execution price.


Even taking the benign route does not mean the application side is ethical; to maximize the value of "front-running arbitrage," the application side has an incentive to intentionally slow down the transaction's on-chain speed. Driven by profit, the application side may also intentionally route users to pools with lower liquidity to artificially create greater price fluctuations and arbitrage opportunities.


According to reports, some well-known front-end applications on Solana are engaging in the above-mentioned practices.


Who Took Your Tip?


If the above methods still involve some technical barriers, then the manipulation of "transaction fees" is a full-blown performance.


On Solana, the fee users pay is actually divided into two parts:

- Priority Fee: This is the protocol fee paid directly to validators.

- Transaction Tip: This is a sum of SOL sent to any address, usually paid to a "Landing Service" like Jito. The service provider then decides how much to give to validators and how much to return (rebate) to the application side.


Why the need for a Landing Service? Due to the highly complex nature of communication on the Solana network during congestion, regular transaction broadcasts often fail. Landing services act as a "VIP channel," pledging to users that their transactions will successfully go on-chain through a specially optimized link.


Solana's complex Builder Market and fragmented routing system have spawned this unique role, creating excellent rent-seeking opportunities for the application side. Applications often induce users to pay high tips for a "guaranteed" transaction and then share this premium with the Landing Service provider.


Transaction Volume and Fee Landscape


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


Among them, Jito's Landing Service processed 80 million transactions, dominating the market (93.5% of the builder market share). In these transactions, the vast majority were related to swaps, oracle updates, and liquidity provider operations.


In this massive pool of traffic, users often pay high fees in pursuit of speed. But was all this money really used to speed things up?


Not quite. Data indicates that wallets with low activity levels (usually retail investors) paid exorbitant priority fees. Considering that the blocks were not full at the time, these users were clearly overcharged.


Applications capitalize on users' fear of "transaction failure," inducing them to set very high tips. Then, through an agreement with the Landing Service provider, they pocket this surplus income.


Anti-Pattern Axiom


To illustrate this "harvesting" pattern more intuitively, the author conducted an in-depth case study of the Axiom flagship application on Solana.


The transaction fees generated by Axiom lead the entire network, not only because of its large user base, but also because it is the most ruthless in skimming its users.


Data shows that the median (p50) priority fee paid by Axiom users is as high as 1,005,000 lamports. In comparison, high-frequency trading wallets pay only about 5,000 to 6,000 lamports. There is a 200x difference in between.



The same is true for tips.


Axiom users pay significantly higher tips on on-chain services like Nozomi, Zero Slot, etc., compared to the market average. The application side precisely exploits users' extreme sensitivity to "speed" and, without any negative feedback, completes a double charge to users.



The author bluntly speculates, "Most of the transaction fees paid by Axiom users ultimately flow back into the pockets of the Axiom team."


Reclaiming Fee Setting Authority


The severe misalignment between user incentives and application incentives is the root cause of the current chaos. Users do not know what a reasonable fee is, and the application side is happy to maintain this chaos.


To break this situation, we need to start from the fundamental market structure. The introduction of Solana's Multiple Concurrent Proposers (MCP) and Priority Ordering around 2026, as well as the widely proposed dynamic base fee mechanism, may be the key to solving the problem.


Multiple Concurrent Proposers


The current Solana single proposer model is prone to temporary monopolies, as the application side only needs to handle the current Leader to quickly control the transaction packaging rights. With the introduction of 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 Mechanism


By protocol-layer mandate, the "priority fee ordering" eliminates the randomness of ordering (Jitter). This reduces the need for users to rely on private acceleration channels like Jito just to "ensure inclusion." For regular transactions, users no longer need to guess how much fee to pay; they just send money within the protocol, and 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.


Users no longer blindly tip but instead explicitly instruct the protocol: "I am willing to pay a maximum fee of X Lamports for this on-chain transaction."


The protocol automatically prices transactions based on the current congestion level. When uncongested, it charges a low fee; when congested, it charges a high fee. This mechanism wrests the pricing power of fees from the application side and intermediaries, returning it to a transparent protocol algorithm.



Memes brought prosperity to Solana but also left a root of the disease, creating a restless profit-seeking gene. To truly realize the ICM vision, Solana 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 underlying technological architecture upgrades, using technical means to eradicate rent-seeking soil, and developing a fair, transparent market structure that prioritizes user welfare can Solana truly have the confidence to integrate and compete with the traditional financial system.


Welcome to join the official BlockBeats community:

Telegram Subscription Group: https://t.me/theblockbeats

Telegram Discussion Group: https://t.me/BlockBeats_App

Official Twitter Account: https://twitter.com/BlockBeatsAsia

Choose Library
Add Library
Cancel
Finish
Add Library
Visible to myself only
Public
Save
Correction/Report
Submit