Il y a quelques années, l’article « Payment for Order Flow on Solana » révélait un aspect opaque du marché des frais sur Solana, suscitant un débat intense sur le crypto Twitter anglophone.
Le Payment for Order Flow (PFOF) est un modèle bien établi dans la finance traditionnelle. Robinhood a utilisé le PFOF pour lancer le « zero-commission trading », dépassant rapidement les courtiers historiques. Cette approche a généré des bénéfices significatifs pour Robinhood et contraint des acteurs majeurs comme Charles Schwab et E-Trade à adopter des stratégies similaires, transformant durablement le secteur du courtage de détail américain.
En 2021, Robinhood a généré près d’un milliard de dollars de revenus PFOF, soit environ la moitié de son chiffre d’affaires annuel. Même en 2025, ses revenus trimestriels issus du PFOF atteignaient encore plusieurs centaines de millions de dollars, soulignant la rentabilité exceptionnelle de ce modèle.
Les market makers privilégient fortement le flux d’ordres retail, car ils sont considérés comme « non toxiques » : généralement motivés par l’émotion ou un besoin immédiat, ils ne reflètent pas des prévisions précises d’évolution des prix. En absorbant ces ordres, les market makers captent le spread bid-ask sans risquer de s’opposer à des acteurs institutionnels informés.
Pour exploiter ce flux, des courtiers comme Robinhood regroupent les ordres retail et les vendent à des géants du market making tels que Citadel, percevant au passage d’importants rabais.
La régulation financière traditionnelle offre une certaine protection aux investisseurs particuliers. La Regulation NMS de la SEC impose que les ordres groupés soient exécutés à des prix au moins équivalents au meilleur du marché.
À l’inverse, l’écosystème on-chain non régulé permet aux applications d’exploiter l’asymétrie d’information. Elles incitent les utilisateurs à payer des frais prioritaires et des tips bien supérieurs aux besoins réels du réseau, s’appropriant discrètement l’excédent. Ce mécanisme revient à imposer une « taxe invisible » élevée aux utilisateurs non avertis.
Les applications qui contrôlent fortement les points d’accès utilisateurs déploient des stratégies de monétisation bien plus sophistiquées qu’on ne l’imagine.
Les applications front-end et les wallets déterminent la destination, le mode d’exécution et la rapidité d’intégration des transactions sur la blockchain. Chaque étape du cycle de vie d’une transaction constitue une opportunité d’extraction de valeur auprès de l’utilisateur.
Comme Robinhood, les applications Solana peuvent vendre des « droits d’accès » aux market makers.
Le modèle Request for Quote (RFQ) en est une illustration. Contrairement aux AMM classiques, le RFQ permet aux utilisateurs ou aux applications de demander des cotations et d’échanger directement avec des market makers spécifiques. Sur Solana, des agrégateurs comme Jupiter ont déjà adopté ce modèle (JupiterZ). Ainsi, les applications peuvent facturer aux market makers des frais de connexion ou, plus directement, regrouper et vendre le flux d’ordres retail. À mesure que les spreads on-chain se resserrent, ce modèle de « courtage utilisateur » devrait se généraliser.
De plus, des alliances émergent entre DEX et agrégateurs. Les AMM et DEX propriétaires dépendent fortement du trafic généré par les agrégateurs, tandis que ces derniers peuvent facturer les fournisseurs de liquidité et reverser une part des profits aux applications front-end.
Par exemple, lorsque le wallet Phantom oriente une transaction vers Jupiter, des fournisseurs de liquidité comme HumidiFi ou Meteora peuvent verser une commission à Jupiter pour exécuter la transaction. Jupiter, après avoir perçu ce « channel fee », partage une partie avec Phantom.
Bien que cette pratique ne soit pas officiellement confirmée, l’auteur estime qu’au vu des incitations financières, de tels mécanismes de partage de revenus sont quasiment inévitables dans l’industrie.
Lorsqu’un utilisateur clique sur « Confirmer » et signe une transaction dans son wallet, il crée en réalité un ordre de marché avec un paramètre de slippage.
Les applications ont deux principales options pour traiter ces ordres :
Constructive : vendre l’opportunité de « backrun » (arbitrage en suivi) à des sociétés de trading professionnelles et partager les profits. Le backrun désigne une situation où l’ordre d’achat d’un utilisateur sur DEX1 fait monter le prix du token, puis un bot d’arbitrage achète immédiatement sur DEX2 dans le même bloc (sans impacter le prix d’exécution sur DEX1), pour revendre ensuite sur DEX1.
Exploitative : collaborer avec des attaquants sandwich pour cibler leurs propres utilisateurs et gonfler artificiellement le prix d’exécution.
Même en choisissant la voie constructive, les applications ne servent pas toujours au mieux les intérêts des utilisateurs. Pour maximiser la valeur du backrun, elles peuvent volontairement retarder la soumission des transactions. Motivées par le profit, elles peuvent aussi orienter les utilisateurs vers des pools à faible liquidité, générant de plus fortes variations de prix et davantage d’opportunités d’arbitrage.
Des rapports indiquent que certaines applications front-end majeures sur Solana recourent à ces pratiques.
Si les stratégies précédentes impliquent une certaine complexité technique, la manipulation des « frais de transaction » est souvent flagrante.
Sur Solana, les frais utilisateur se répartissent en deux volets :
Pourquoi recourir aux landing service providers ? En période de congestion réseau, les diffusions standard de transactions risquent d’échouer. Les landing service providers jouent le rôle de « canaux VIP », optimisant les routes et garantissant l’inclusion des transactions.
Le marché complexe des builders et le système de routage fragmenté sur Solana ont favorisé cette fonction, offrant aux applications de véritables opportunités de captation de rente. Elles incitent souvent les utilisateurs à verser des tips élevés pour une « inclusion garantie », puis partagent la prime avec les landing service providers.
Quelques chiffres : entre le 1 et le 8 décembre 2025, Solana a traité 450 millions de transactions sur l’ensemble du réseau.
Le service landing de Jito en a géré 80 millions, dominant avec une part de marché builder de 93,5 %. La majorité de ces transactions concernaient des swaps, des mises à jour d’oracle et des opérations de market making.
Dans cet environnement à fort volume, les utilisateurs paient souvent des frais élevés dans l’espoir d’une inclusion plus rapide. Mais ces frais sont-ils vraiment nécessaires ?
Pas toujours. Les données montrent que les wallets à faible activité — principalement des utilisateurs retail — paient des Priority Fees nettement supérieurs à la moyenne. Les blocs n’étant pas pleins à cette période, ces utilisateurs ont clairement été surfacturés.
Les applications exploitent la crainte des utilisateurs de voir leur transaction échouer, les incitant à fixer des tips excessifs. Grâce à des accords avec les landing service providers, elles captent cette prime.
Pour illustrer ce modèle d’extraction, l’auteur a mené une étude de cas sur Axiom, l’une des principales applications de Solana.
Axiom a généré les frais de transaction les plus élevés du réseau, non seulement grâce à sa large base d’utilisateurs, mais aussi en raison de pratiques tarifaires agressives.
Les données montrent que les utilisateurs d’Axiom ont payé un Priority Fee médian (p50) de 1 005 000 lamports. À titre de comparaison, les wallets de trading haute fréquence n’ont payé que 5 000 à 6 000 lamports — soit un écart de 200 fois.

Il en va de même pour les tips.
Les utilisateurs d’Axiom ont versé des tips sur des landing services comme Nozomi et Zero Slot bien supérieurs à la moyenne du marché. L’application a exploité la sensibilité des utilisateurs à la rapidité, les facturant double sans retour négatif.

L’auteur conclut sans détour : « La grande majorité des frais de transaction payés par les utilisateurs d’Axiom finit dans les poches de l’équipe Axiom. »
Un désalignement majeur des incitations entre utilisateurs et applications est à l’origine des difficultés actuelles. Les utilisateurs ignorent ce qu’est un frais équitable, tandis que les applications ont tout intérêt à entretenir cette opacité.
Pour y remédier, il faut réformer la structure du marché sous-jacente. L’introduction attendue des Multiple Concurrent Proposers (MCP), du Priority Ordering et d’un mécanisme de base fee dynamique sur Solana — prévue autour de 2026 — pourrait apporter une solution.
Le modèle actuel à proposeur unique de Solana est vulnérable aux monopoles temporaires, où les applications peuvent influencer le leader du moment. MCP introduit plusieurs proposeurs travaillant en parallèle sur chaque slot, ce qui augmente nettement le coût des attaques et des monopoles, renforce la résistance à la censure et rend la captation des utilisateurs par le contrôle d’un seul nœud bien plus difficile.

En imposant un tri au niveau du protocole selon le Priority Fee, l’aléa (jitter) dans l’ordre des transactions disparaît. Cela réduit la dépendance des utilisateurs aux canaux privés d’accélération comme Jito pour garantir l’inclusion. Pour les transactions standard, il n’est plus nécessaire de deviner le montant des tips : le paiement au protocole suffit pour que les validateurs priorisent les transactions selon des règles déterministes.

Il s’agit de la réforme la plus déterminante. Solana travaille à l’introduction d’un modèle de base fee dynamique, semblable à celui d’Ethereum.
Les utilisateurs ne donneront plus de tips à l’aveugle ; ils indiqueront au protocole : « Je suis prêt à payer jusqu’à X lamports pour que cette transaction soit incluse. »
Le protocole fixera automatiquement les frais selon la congestion du réseau en temps réel. Si le réseau n’est pas saturé, le frais reste faible ; en cas de congestion, il augmente. Ce mécanisme transfère le pouvoir de tarification des applications et intermédiaires vers un algorithme transparent du protocole.

Les memecoins ont dopé la croissance de Solana, mais ont aussi instauré une culture de recherche de profits spéculatifs. Pour que Solana réalise la vision de l’ICM, il faut empêcher la collusion entre applications contrôlant le trafic utilisateur et protocoles gérant l’infrastructure.
Comme le dit le proverbe : « Il faut balayer devant sa porte avant d’inviter des hôtes. » Seule une évolution de l’architecture technique, l’élimination des rentes et la construction d’un marché équitable et transparent, centré sur le bien-être des utilisateurs, permettront à Solana de rivaliser avec la finance traditionnelle et de s’y intégrer.





