Avant le Nouvel An, un article intitulé « Payment for Order Flow sur Solana » a révélé un aspect sombre du marché des frais de Solana, suscitant une attention phénoménale sur Twitter en anglais.

Le PFOF (Payment for Order Flow, paiement pour flux d'ordres) est depuis longtemps un modèle commercial mature dans le secteur financier traditionnel. Robinhood a justement utilisé ce modèle pour lancer son atout maître, les « transactions sans commission », et s'est ainsi rapidement frayé un chemin parmi de nombreux courtiers établis. Cette stratégie a non seulement permis à Robinhood de réaliser d'importants bénéfices, mais a également contraint des géants du secteur tels que Charles Schwab et E-Trade à l'imiter, changeant ainsi le paysage de la branche des courtages de détail aux États-Unis.

En 2021, Robinhood a généré près de 1 milliard de dollars de revenus grâce au PFOF (Payment for Order Flow), représentant ainsi la moitié de ses revenus totaux de l'année. Même en 2025, les revenus générés par le PFOF sur un seul trimestre atteignent toujours plusieurs centaines de millions de dollars. Cela démontre clairement le caractère lucratif de ce modèle économique.

Dans les marchés traditionnels, les market-makers (faiseurs de marché) préfèrent extrêmement les ordres des investisseurs individuels. La raison est simple : les ordres des investisseurs individuels sont généralement considérés comme « inoffensifs », car ils sont souvent motivés par l'émotion ou des besoins immédiats, sans contenir de prédictions précises sur les variations futures des prix. En absorbant ces ordres, les market-makers peuvent non seulement gagner la marge entre l'achat et la vente, mais aussi éviter de se retrouver en face des investisseurs informés (comme les institutions financières).

Afin de répondre à cette demande, les courtiers (comme Robinhood) regroupent les ordres de leurs utilisateurs et les vendent en vrac à des géants des market makers tels que Citadel, percevant ainsi des commissions très importantes.

La réglementation des marchés financiers traditionnels protège, dans une certaine mesure, les investisseurs individuels. Le règlement sur le système national de marchés de la SEC exige que même les ordres regroupés soient exécutés à un prix au moins équivalent au meilleur prix disponible sur le marché.

Cependant, dans un monde décentralisé non réglementé, les applications profitent de l'asymétrie d'information pour inciter les utilisateurs à payer des frais de priorité et des pourboires largement supérieurs aux besoins réels d'inclusion dans la blockchain, et détournent discrètement ces primes. En réalité, ce comportement équivaut à prélever une « taxe cachée » lucratrice sur des utilisateurs non avertis.

Pour les applications qui disposent d'une grande quantité d'entrées utilisateurs, les moyens de monétiser le trafic sont bien plus variés que vous ne l'imaginez.

Les applications frontales et les portefeuilles peuvent décider où envoyer les transactions des utilisateurs, comment elles seront exécutées, voire même à quelle vitesse elles seront ajoutées à la chaîne. Chaque « étape » du cycle de vie d'une transaction recèle potentiellement des opportunités commerciales visant à « sucer » la valeur des utilisateurs.

« Vendre » les utilisateurs aux market makers

Comme Robinhood, les applications sur Solana peuvent également vendre un « accès » aux courtiers.

La RFQ (Request for Quote, ou demande de cotation) est une application directe de cette logique. Contrairement aux AMM (Automated Market Makers) traditionnels, la RFQ permet aux utilisateurs (ou aux applications) de demander directement un prix à des courtiers spécifiques et d'effectuer des transactions. Sur Solana, des agrégateurs tels que Jupiter ont déjà intégré ce modèle (JupiterZ). Dans ce système, le côté application peut percevoir des frais de connexion auprès de ces courtiers, ou, de manière plus directe, vendre des flux d'ordres agrégés de petits investisseurs. Alors que les écarts de prix sur la chaîne s'amenuisent de plus en plus, les auteurs prévoient que ce type d'activité, consistant à « vendre les clients », deviendra de plus en plus courant.

En outre, des alliances d'intérêts émergent également entre les DEX et les agrégateurs. Les AMM propriétaires (Prop AMMs) et les DEX dépendent fortement du trafic apporté par les agrégateurs, tandis que ces derniers ont pleinement la capacité de facturer ces fournisseurs de liquidité et de reverser une partie des bénéfices sous forme de « remises » aux applications frontales.

Par exemple, lorsque le portefeuille Phantom route les transactions de l'utilisateur vers Jupiter, les fournisseurs de liquidité sous-jacents (comme HumidiFi ou Meteora) peuvent payer une commission à Jupiter pour obtenir le droit d'exécuter cette transaction. Après avoir reçu cette « redevance de passage », Jupiter en reverse une partie à Phantom.

Bien que cette hypothèse n'ait pas encore été publiquement confirmée, l'auteur pense que, sous l'effet du profit, cette « règle implicite de partage des bénéfices » au sein de la chaîne industrielle est presque un phénomène naturel.

Ordre de marché vampire

Lorsque l'utilisateur clique sur « Confirmer » dans son portefeuille et signe la transaction, celle-ci est en réalité une « commande au marché » (Market Order) comportant un paramètre de glissement (slippage).

Pour le côté de l'application, il existe deux méthodes possibles pour traiter cette commande :

Stratégie bénéfique : vendre les opportunités de "Backrun" (arbitrage de suivi) générées par les transactions à des entreprises de trading professionnel, et partager les bénéfices. Le "Backrun" désigne la situation où, après que l'utilisateur ait acheté un jeton sur DEX1, ce qui fait monter son prix sur DEX1, les robots d'arbitrage achètent immédiatement ce jeton sur DEX2 au sein du même bloc (sans affecter le prix d'achat de l'utilisateur sur DEX1), puis le revendent sur DEX1.

Stratégie malveillante : Aider le "clou" (spéculateur en sandwich) à attaquer les utilisateurs, ce qui entraîne une augmentation du prix de transaction des utilisateurs.

Même en suivant une voie apparemment honnête, cela ne signifie pas que l'application elle-même agit avec honnêteté. Afin de maximiser la valeur de l'arbitrage de suivi, l'application a tout intérêt à ralentir délibérément la vitesse à laquelle les transactions sont ajoutées à la chaîne. Sous l'effet du profit, l'application pourrait même délibérément router les utilisateurs vers des pools de liquidité plus faibles, créant ainsi artificiellement davantage de volatilité des prix et d'opportunités d'arbitrage.

Des applications frontales connues sur Solana sont rapportées en train d'effectuer lesdites opérations.

Qui a pris ton pourboire ?

Si les moyens mentionnés ci-dessus comportent encore un certain niveau de complexité technique, les manipulations opaques concernant les « frais de transaction » constituent véritablement une « mascarade inutile ».

Sur Solana, les frais payés par les utilisateurs se divisent en réalité en deux parties :

- Frais de priorité : il s'agit de frais intégrés au protocole, payés directement aux validateurs.

- Commission de transaction : Il s'agit d'une quantité de SOL envoyée à une adresse quelconque, généralement vers un « prestataire de service de validation » (landing service) tel que Jito. Le prestataire décide ensuite de la répartition entre la part destinée aux validateurs et la part à rembourser (rebate) aux applications.

Pourquoi a-t-on besoin d'un prestataire local ? Lorsque le réseau Solana est surchargé, la communication devient extrêmement complexe, et l'envoi ordinaire de transactions échoue facilement. Le prestataire local joue le rôle d'un « passage VIP » : grâce à des liens optimisés spécifiquement, il s'engage à garantir la réussite de l'inscription de la transaction sur la chaîne.

Le marché complexe des constructeurs de blocs (Builder Market) de Solana, ainsi que son système fragmenté de routage, ont donné naissance à ce rôle particulier, créant ainsi un espace idéal pour l'exploitation rentable du côté des applications. Les applications incitent souvent les utilisateurs à payer des pourboires élevés afin d'obtenir un traitement prioritaire, puis partagent cette prime avec les fournisseurs de services en aval.

Examinons un ensemble de données. La semaine du 1er au 8 décembre 2025, le réseau Solana a enregistré 450 millions de transactions.

Parmi ceux-ci, le service de mise en œuvre de Jito a traité 80 millions de transactions, détenant une position dominante (93,5 % de part de marché des constructeurs). La plupart de ces transactions concernaient des échanges liés aux transactions, des mises à jour d'oracles et des opérations de market-making.

Dans ce vaste bassin de trafic, les utilisateurs, souhaitant « gagner du temps », paient souvent des frais élevés. Mais cet argent est-il vraiment utilisé pour accélérer ?

Pas nécessairement. Les données montrent que les portefeuilles à faible activité (généralement des particuliers) paient des frais de priorité démesurément élevés. Étant donné que les blocs à l'époque n'étaient pas pleins, il est évident que ces utilisateurs ont été surfacturés.

L'application profite de la peur des utilisateurs face à un "échec de la transaction" pour les inciter à fixer des pourboires très élevés. Ensuite, via des accords avec les fournisseurs de services locaux, elle s'approprie cette plus-value.

Contre-exemple Axiome

Afin de présenter de manière plus intuitive ce mode de « récolte », l'auteur a mené une étude de cas approfondie sur Axiom, l'une des applications phares de Solana.

Les frais de transaction générés par Axiom sont les plus élevés du réseau, non seulement à cause de son grand nombre d'utilisateurs, mais aussi à cause de ses tarifs exagérément élevés.

Selon les données, la médiane (p50) des frais de priorité payés par les utilisateurs d'Axiom atteint 1 005 000 lamports. À titre de comparaison, les portefeuilles utilisés pour le trading à haute fréquence ne paient que 5 000 à 6 000 lamports environ. Cela représente un écart de 200 fois.

C'est la même chose concernant les pourboires.

Les utilisateurs d'Axiom paient des pourboires bien supérieurs à la moyenne du marché lorsqu'ils utilisent des services tels que Nozomi, Zero Slot, etc. L'application profite précisément de la très grande sensibilité des utilisateurs à la « vitesse » et a réussi à facturer les utilisateurs à double titre sans aucune réaction négative de leur part.

L'auteur affirme clairement : « La majeure partie des frais de transaction payés par les utilisateurs d'Axiom revient finalement dans les poches de l'équipe Axiom. »

Un déséquilibre majeur entre les incitations des utilisateurs et celles des applications est à l'origine des troubles actuels. Les utilisateurs ignorent ce qui constitue des frais raisonnables, tandis que les applications préfèrent maintenir cet état de confusion.

Pour briser cette situation, nous devons intervenir sur la structure fondamentale du marché. L'introduction, prévue vers 2026, de la proposition de plusieurs producteurs de blocs (MCP) et du mécanisme d'ordonnancement prioritaire (Priority Ordering) de Solana, ainsi que du mécanisme de frais de base dynamique largement proposé, pourrait être la solution idéale pour résoudre ce problème.

Proposeurs multiples et concurrents (Multiple Concurrent Proposers)

Le modèle actuel de producteur unique de Solana est sujet à une domination temporaire. Du côté des applications, il suffit de s'entendre avec le leader actuel pour contrôler temporairement le regroupement des transactions. L'introduction du MCP (Multiple Consensus Proposers) permet à chaque intervalle (Slot) d'avoir plusieurs producteurs travaillant en parallèle, ce qui augmente considérablement le coût des attaques et de la monopolisation, améliore la résistance à la censure, et rend difficile pour les applications de bloquer les utilisateurs en contrôlant un seul nœud.

Mécanisme de classement par priorité (Priority Ordering)

En imposant au niveau protocole de classer les transactions par ordre de frais prioritaires, on élimine l'aléa (Jitter) dans l'ordre de traitement. Cela réduit la dépendance des utilisateurs envers des canaux d'accélération privés tels que Jito, qu'ils utilisent uniquement pour "garantir le passage". Pour les transactions normales, les utilisateurs n'ont plus besoin d'essayer de deviner la quantité de pourboire à donner : il leur suffit de payer dans le protocole, et tous les validateurs du réseau traiteront leurs transactions selon des règles déterministes.

Frais de base dynamiques (Dynamic Base Fee)

Il s'agit de l'étape la plus critique. Solana tente d'introduire un concept similaire à la taxe de base dynamique (Dynamic Base Fee) d'Ethereum.

L'utilisateur n'accorde plus aveuglément des pourboires, mais donne explicitement des instructions au protocole : « Je suis prêt à payer un maximum de X Lamports de frais pour faire inscrire cette transaction dans la chaîne. »

Le protocole fixe automatiquement les prix en fonction du niveau actuel de congestion. Lorsque la circulation est fluide, seuls des tarifs bas sont appliqués ; en cas de congestion, des tarifs élevés sont alors facturés. Ce mécanisme transfère le pouvoir de fixation des frais des applications et des intermédiaires vers un algorithme transparent du protocole.

Les memes ont apporté à Solana une certaine prospérité, mais ont également laissé des séquelles, en imprimant un gène de spéculation et d'agitation. Si Solana souhaite véritablement concrétiser la vision de l'ICM (Infrastructure Capital Market), il ne doit pas laisser les applications maîtrisant le trafic frontal et les protocoles contrôlant l'infrastructure s'entendre malhonnêtement et agir à leur guise.

Comme on dit souvent : « Nettoyez d'abord la maison avant d'inviter les invités. » Seule une mise à niveau fondamentale de l'architecture technique, permettant d'éliminer par des moyens technologiques les conditions favorisant les abus, et permettant de créer une structure de marché équitable, transparente et mettant la satisfaction de l'utilisateur en premier, permettra à Solana de véritablement rivaliser et s'intégrer au système financier traditionnel.