La « taxe invisible » sur Solana

Écrit par : SpecialistXBT

Il y a quelques années, un article intitulé « Payment for Order Flow on Solana » a dévoilé un coin sombre du marché des frais sur Solana, suscitant une attention phénoménale sur Twitter en anglais.

Le PFOF (Payment for Order Flow) est une pratique commerciale bien établie dans la finance traditionnelle. Robinhood a justement utilisé ce modèle pour lancer la stratégie du « trading sans commission », se démarquant rapidement parmi de nombreux courtiers établis. Cette approche a non seulement permis à Robinhood de réaliser des profits colossaux, mais a aussi forcé des géants comme Charles Schwab, E-Trade, etc., à imiter cette méthode, modifiant ainsi la carte du courtage de détail aux États-Unis.

En 2021 seulement, Robinhood a généré près de 1 milliard de dollars de revenus via le PFOF, représentant 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. Cela montre à quel point ce modèle commercial est extrêmement lucratif.

Sur les marchés traditionnels, les teneurs de marché privilégient fortement les ordres des petits investisseurs. La raison est simple : ces ordres sont généralement considérés comme « inoffensifs », souvent basés sur l’émotion ou des besoins immédiats, sans prédiction précise des futurs mouvements de prix. En acceptant ces ordres, les teneurs de marché peuvent réaliser des marges sur le spread, tout en évitant d’être en opposition avec des traders informés (comme des gros investisseurs institutionnels).

Pour répondre à cette demande, les courtiers (comme Robinhood) regroupent le flux d’ordres des utilisateurs et le vendent en gros à des géants comme Citadel, en percevant d’importants rétrocommissions.

La réglementation sur les marchés financiers traditionnels protège en partie les petits investisseurs : la SEC impose que même les ordres regroupés soient exécutés à un prix au moins aussi favorable que le meilleur prix du marché.

Cependant, dans le monde décentralisé sans régulation, les applications exploitent l’asymétrie d’information pour inciter les utilisateurs à payer des frais de priorité et des pourboires bien supérieurs à leurs besoins réels, tout en détournant discrètement ces surcoûts. En substance, cela revient à imposer une « taxe invisible » très lucrative aux utilisateurs sans défense.

Monétisation du trafic

Pour les applications disposant d’un grand nombre d’utilisateurs, la monétisation du trafic est bien plus variée que ce que l’on pourrait imaginer.

Les interfaces utilisateur et portefeuilles peuvent décider où les transactions sont envoyées, comment elles sont exécutées, voire à quelle vitesse elles sont enregistrées sur la blockchain. Chaque « étape » du cycle de vie d’une transaction recèle des opportunités pour maximiser la valeur utilisateur.

Vendre l’accès aux teneurs de marché

Comme Robinhood, les applications sur Solana peuvent vendre « le droit d’accès » aux teneurs de marché.

RFQ (Request For Quote) est une manifestation directe de cette logique. Contrairement aux AMM traditionnels, le RFQ permet à un utilisateur (ou une application) de demander directement un prix à un teneur de marché spécifique et de conclure la transaction. Sur Solana, des agrégateurs comme Jupiter ont déjà intégré ce mode (JupiterZ). Dans ce système, l’application peut percevoir des frais de connexion ou, plus simplement, regrouper et vendre en gros le flux d’ordres des petits investisseurs. Avec la réduction constante des spreads on-chain, l’auteur prévoit que cette « vente de leads » deviendra de plus en plus courante.

De plus, un certain partenariat se forme entre DEX et agrégateurs. Les Prop AMMs (market makers auto-gestionnés) et DEX dépendent fortement du trafic généré par les agrégateurs, qui peuvent leur facturer des frais et redistribuer une partie des profits sous forme de « rétrocommissions » aux applications frontales.

Par exemple, lorsque le portefeuille Phantom route une transaction via Jupiter, le fournisseur de liquidité sous-jacent (comme HumidiFi ou Meteora) pourrait payer pour obtenir le droit d’exécuter cette transaction. Jupiter, en percevant ces « frais de canal », pourrait en reverser une partie à Phantom.

Bien que cette hypothèse ne soit pas encore officiellement confirmée, l’auteur pense qu’en raison des motivations économiques, cette pratique de partage de profits au sein de la chaîne de valeur est presque inévitable.

Vampiriser les ordres au marché

Lorsque l’utilisateur clique sur « Confirmer » et signe dans le portefeuille, cette transaction est en réalité un « ordre au marché » avec un paramètre de slippage.

Pour l’application, il y a deux approches pour traiter cette transaction :

Approche saine : vendre l’opportunité de « backrun » (arbitrage en tail) à des sociétés de trading professionnelles, en partageant les profits. Le backrun consiste à profiter du fait qu’un ordre d’achat sur DEX1 fait monter le prix du token, puis un robot d’arbitrage achète dans un autre DEX (sans impacter le prix d’achat sur DEX1) et revend dans DEX1.

Approche malveillante : aider des attaquants (type sandwich) à manipuler le prix pour piéger leurs propres utilisateurs.

Même dans une optique saine, cela ne signifie pas que l’application a une conscience éthique : pour maximiser la valeur du « tail », elle pourrait volontairement ralentir la confirmation des transactions. Motivé par le profit, l’application pourrait aussi orienter délibérément les utilisateurs vers des pools à faible liquidité pour créer artificiellement plus de volatilité et d’opportunités d’arbitrage.

Selon des rapports, certains grands applications frontales sur Solana pratiquent déjà ces stratégies.

Qui a pris votre pourboire ?

Si ces méthodes demandent encore un certain savoir-faire technique, la manipulation opaque des « frais de transaction » est une véritable mascarade.

Sur Solana, les frais payés par l’utilisateur se divisent en deux parties :

• Frais de priorité : frais internes au protocole, versés directement aux validateurs.

• Pourboires de transaction : SOL transféré à une adresse arbitraire, souvent versé à des « landing services » comme Jito. Ces services décident de combien reverser aux validateurs et combien de « rebates » (remises) redistribuer à l’application.

Pourquoi faire appel à ces landing services ? Parce qu’en période de congestion, la communication sur le réseau Solana devient très complexe, et une simple diffusion d’ordre peut échouer. Ces services jouent le rôle de « voies VIP », utilisant des chemins d’optimisation pour garantir la réussite de la transaction.

Le marché complexe des constructeurs de blocs (Builder Market) et la fragmentation des routes ont créé ce rôle spécifique, offrant aux applications une opportunité de « rent-seeking » exceptionnelle. Elles incitent souvent les utilisateurs à payer des pourboires élevés pour « garantir » la transaction, puis partagent cette prime avec les landing services.

Trafic et frais : la carte du marché

Voici quelques chiffres : entre le 1er et le 8 décembre 2025, le réseau Solana a enregistré 450 millions de transactions.

Parmi elles, les landing services de Jito ont traité 80 millions de transactions, dominant le marché (93,5 % de part de marché des constructeurs). La majorité de ces transactions concernent des swaps, des mises à jour d’oracles ou des opérations de market making.

Dans ce flux massif, pour aller plus vite, les utilisateurs paient souvent des frais élevés. Mais ces fonds sont-ils réellement utilisés pour accélérer ?

Pas forcément. Les données montrent que les portefeuilles peu actifs (souvent des petits investisseurs) paient des frais de priorité exorbitants. Étant donné que les blocs ne sont pas pleins, ces utilisateurs ont été surfacturés.

Les applications exploitent la peur de l’échec des transactions pour inciter à payer des pourboires très élevés, puis partagent ces surcoûts avec les landing services.

Cas extrême : Axiom

Pour illustrer cette pratique de « récolte », l’auteur a mené une étude approfondie de l’application Axiom, l’un des principaux acteurs sur Solana.

Les frais générés par Axiom sont les plus élevés du réseau, non seulement parce qu’elle a beaucoup d’utilisateurs, mais aussi parce qu’elle pratique une politique de tarification très agressive.

Les données montrent que la médiane des frais prioritaires payés par les utilisateurs d’Axiom (p50) atteint 1 005 000 lamports. En comparaison, les portefeuilles de trading haute fréquence ne paient qu’environ 5 000 à 6 000 lamports. L’écart est de 200 fois.

Concernant les pourboires, la situation est similaire.

Les utilisateurs d’Axiom versent des pourboires bien supérieurs à la moyenne sur des services comme Nozomi ou Zero Slot. L’application exploite la forte sensibilité des utilisateurs à la « vitesse » pour leur faire payer deux fois, sans qu’ils s’en rendent compte.

L’auteur n’hésite pas à supposer : « La majorité des frais de transaction payés par les utilisateurs d’Axiom finissent dans la poche de l’équipe d’Axiom. »

Reprendre le contrôle du prix des frais

Le décalage grave entre l’incitation des utilisateurs et celle des applications est à l’origine de la situation actuelle. Les utilisateurs ignorent ce qui constitue un coût raisonnable, et les applications ont intérêt à maintenir ce chaos.

Pour changer la donne, il faut repenser la structure même du marché. L’introduction, d’ici 2026, de propositions multiples (MCP) et d’un mécanisme de priorité (Priority Ordering), ainsi que la mise en place d’un mécanisme de frais de base dynamiques, pourraient être la clé pour résoudre ces problèmes.

Proposeurs multiples (Multiple Concurrent Proposers)

Le modèle actuel à un seul proposeur sur Solana favorise la monopolisation temporaire : l’application n’a qu’à contrôler le leader pour maîtriser la mise en bloc des transactions. Avec l’introduction du MCP, plusieurs proposeurs peuvent travailler simultanément à chaque slot, ce qui augmente considérablement le coût d’attaque ou de monopole, renforçant la résistance à la censure et empêchant une seule entité de contrôler totalement le réseau.

Mécanisme de priorité (Priority Ordering)

En imposant une règle dans le protocole pour classer les transactions selon leur frais de priorité (high priority fee), on élimine la variabilité aléatoire (Jitter). Cela réduit la dépendance à des canaux privés comme Jito pour accélérer les transactions. Pour les transactions classiques, l’utilisateur n’a plus besoin de deviner combien de pourboires donner : en payant dans le protocole, tous les validateurs du réseau traiteront en priorité selon une règle déterministe.

Frais de base dynamiques (Dynamic Base Fee)

C’est la étape la plus cruciale. Solana cherche à introduire un mécanisme de frais de base dynamique, similaire à celui d’Ethereum.

Les utilisateurs n’annoncent plus aveuglément leur pourboire, mais indiquent explicitement : « Je suis prêt à payer jusqu’à X lamports pour cette transaction. »

Le protocole ajuste automatiquement le prix en fonction de la congestion du réseau. Si le réseau est peu chargé, il applique un tarif faible ; en cas de congestion, il augmente le prix. Ce mécanisme redonne le contrôle du prix des frais au protocole, en toute transparence.

Meme a apporté la prospérité à Solana, mais aussi ses racines de superficialité et de recherche de profit à tout prix. Pour que Solana réalise pleinement la vision de l’ICM, il ne faut pas laisser les applications frontales et les protocoles qui contrôlent l’infrastructure agir en toute impunité.

Comme on dit, « nettoyer la maison avant d’inviter », seul un changement profond de l’architecture technique, en éradiquant la recherche de rente, peut permettre de construire un marché équitable, transparent, et orienté vers le bien-être des utilisateurs. C’est ainsi que Solana pourra véritablement rivaliser et s’intégrer dans le système financier traditionnel.