Une « layer 1 HFT » n’est pas une crypto plus rapide. C’est un nouveau règlement de place.

Tous les quelques années, quelqu’un promet de « rendre les marchés plus rapides » en changeant la plomberie. Le discours est toujours technique. Moins de latence. Plus de throughput. Moins d’intermédiaires. Une meilleure UX.

Mais dès que vous supprimez la file d’attente publique, vous ne faites pas qu’accélérer une blockchain. Vous écrivez un nouveau règlement de place.

Concrètement, le mempool public est une transparence imparfaite, parfois chaotique. Tout le monde voit la salle d’attente. Chacun peut déduire ce qui pourrait se passer ensuite. En remplaçant cela par des transactions streamées et de la préconfirmation, vous déplacez le pouvoir d’ordonnancement en amont, entre les mains de celui qui contrôle l’admission et le sequencing. Cette entité devient de facto une couche de matching, qu’elle se qualifie de validator, de sequencer, de builder ou autrement.

J’ai construit et opéré des systèmes où la vitesse était déterminante, y compris sur mes propres systèmes de trading avec indicateurs et automatisation. J’ai aussi dirigé des organisations où la fiabilité comptait davantage que l’élégance, par exemple lorsque je pilotais des opérations couvrant engineering, production et supply chain dans l’électrification et le stockage d’énergie. La leçon ne change pas : la vitesse coûte peu, la confiance coûte cher. Quand vous compressez le temps, vous amplifiez les erreurs. Quand vous privatisez l’ordonnancement, vous créez un nouvel endroit où extraire une rente, sauf si vous concevez l’auditabilité et une allocation équitable dès le premier jour.

Cet essai propose un regard d’opérateur, valable dans la durée, sur les architectures « layer 1 HFT ». Pas comme un spectacle crypto. Comme une question de structure de marché.

Quand un changement technique devient un changement de gouvernance

Un mempool public, c’est une file d’attente publique. C’est bruyant et manipulable, mais lisible. Les participants peuvent l’observer, bâtir des stratégies et, au minimum, débattre de l’équité à partir d’un socle de données partagé.

Supprimez-le, et vous créez par construction une asymétrie d’information. Vous avez désormais une entrée privée. La préconfirmation, c’est une promesse sur l’ordonnancement futur. Le flux streamé, c’est un feed privilégié.

À partir de là, le produit cœur n’est plus le « blockspace ». Le produit devient :

• Politique d’ordonnancement : qui passe en premier, et selon quelles règles.
• Allocation : comment la priorité se vend, se mérite ou se distribue.
• Gestion des litiges : que se passe-t-il quand la préconfirmation contredit l’inclusion finale.
• Responsabilité : qui peut prouver, a posteriori, ce qui s’est passé, preuves à l’appui.

C’est pour cela qu’il faut évaluer ces architectures comme un lancement de place, pas comme un graphique de benchmark.

Quand l’ordonnancement devient privé, le MEV devient « le business model »

Côté opérateurs, on aime faire comme si le MEV était un bug. Dans les systèmes d’ordonnancement privé, c’est souvent le business model — simplement pas toujours nommé.

Si une entité contrôle l’ordonnancement et peut s’engager via la préconfirmation, elle maîtrise l’écart entre « j’ai vu le flux en premier » et « j’ai réagi en premier ». Cet écart, c’est le spread. Il peut apparaître sous forme de frais explicites, de slippage implicite ou d’une tarification de priorité opaque. Dans tous les cas, quelqu’un l’encaisse.

Il n’y a que trois issues soutenables :

1. Vous acceptez la collecte de rente et vous l’assumez comme un coût de qualité d’exécution, comme on paie une place. Très bien, mais alors vous devez l’encadrer en interne : règles, audits, sanctions.
2. Vous commoditisez l’ordonnancement via des enchères transparentes et une équité vérifiable. C’est difficile, mais faisable si le mécanisme d’allocation est lisible et auditable.
3. Vous prétendez décentraliser tout en centralisant le pouvoir. C’est la trajectoire instable. Elle finit en perte de réputation, pression réglementaire et départ des participants les plus sophistiqués.

Pour un board, la question n’est pas : « Est-ce rapide ? ». La question est : « Qui possède l’ordonnancement, et qu’est-ce qui l’empêche de taxer tout le monde ? »

Des marchés plus rapides exigent des contrôles de niveau broker, pas plus de TPS

Une fois la salle d’attente publique supprimée, vous héritez d’une autre famille de problèmes difficiles. Ce sont les mêmes sujets que toute place sérieuse, tout broker, ou tout système au contact du clearing traite au quotidien :

• Limites de risque pré-trade : pas après l’exécution. Avant. Taille max d’ordre, notionnel max, cadence max de messages, exposition max ouverte.
• Plafonds de crédit dynamiques : que se passe-t-il quand un agent agit avec un capital délégué. Il faut des lignes de crédit dynamiques, pas des soldes statiques.
• Kill switches : par compte, par stratégie, par clé API, et au niveau de la place. Pas « mettre la chaîne en pause ». Un bouton d’arrêt précis. J’ai détaillé ce pattern dans AI value and the stop button, et il s’applique ici aussi.
• Surveillance : détection de manipulation, patterns de cotation abusifs, wash behavior, jeux cross-venue. Si vous ne savez pas le détecter, vous le subventionnez.
• Playbooks d’incident : quand les préconfirmations échouent, quand les horloges dérivent, quand un sequencer se comporte mal, quand il y a des partitions réseau. « On corrigera » n’est pas un plan.

Quand j’ai construit IBHQ, une plateforme SaaS pour des activités d’Introducing Broker, le sujet récurrent était celui des control planes. Les brokers vivent et meurent par leurs risk gates, pas par des interfaces séduisantes. La place peut être rapide, mais si vous ne savez pas faire respecter des limites au moment de l’admission, vous finissez par donner les clés au flux le plus agressif. Ensuite, tout le monde paie : accidents, clawbacks, ou coûts cachés.

La vitesse sans garde-fous n’est pas une innovation. C’est du levier.

Un prisme simple de décision : qui est l’arbitre, et peut-on auditer le match ?

Si vous êtes membre de board, actionnaire ou opérateur et que vous évaluez un design de L1 à ordonnancement privé, j’orienterais la discussion vers cinq questions concrètes. Vous pouvez les utiliser dès ce trimestre, que vous construisiez la place, que vous vous y connectiez, ou que vous y allouiez du capital.

1) Quelle est la politique d’ordonnancement, en langage clair ?

Si la réponse nécessite un whitepaper pour être déchiffrée, vous avez un problème de gouvernance. Les règles d’ordonnancement doivent être explicables à un comité des risques en cinq minutes.

2) Comment la priorité est-elle allouée, et est-ce vérifiable ?

Est-ce du premier arrivé, premier servi, basé sur l’heure de réception ? Est-ce aux enchères ? Est-ce relationnel via un flux privé ? Quoi qu’il en soit, vous cherchez deux propriétés : la prévisibilité et l’auditabilité.

3) Quel est le modèle de résolution entre préconfirmation et finalité ?

La préconfirmation est une promesse. Une promesse suppose des recours. Que se passe-t-il si la promesse n’est pas tenue ? Qui paie ? Comment produit-on la preuve ? Si le seul recours est le « consensus social », vous gérez un club, pas un marché.

4) Où vivent les risk gates, et qui les contrôle ?

Les garde-fous au niveau de la place doivent être intégrés et appliqués en périphérie. Ceux au niveau des participants doivent être configurables et démontrables. Si tous les garde-fous sont externes, vous aurez des événements systémiques. S’ils sont tous internes et opaques, vous éroderez la confiance.

5) Comment mesurez-vous la qualité d’exécution sans auto-déclaration ?

Il faut des métriques indépendantes. Pas seulement les TPS. Raisonnez en distributions de slippage, prévisibilité d’inclusion, efficacité des annulations, et comportements de queue en situation de stress.

C’est exactement l’état d’esprit que j’ai appliqué en milieu industriel. En électronique de puissance, vous pouvez respecter une spec en labo et échouer sur le terrain si vous ne maîtrisez pas la variance, les cas de stress et les budgets d’erreur. La fiabilité est un contrat que vous faites respecter, pas une fonctionnalité que vous affirmez. Je l’ai défendu directement dans Ruggedization is a reliability contract. Les marchés ne font pas exception.

La vérité qui dérange : les participants acceptent la centralisation si les règles sont propres

Beaucoup d’équipes partent du principe que les utilisateurs ne jurent que par la décentralisation, par principe. En pratique, les acteurs sérieux regardent d’abord :

• La qualité de fill.
• Des règles stables et prévisibles.
• Un faible risque de litige.
• Des recours clairs quand ça casse.

Ils accepteront une couche d’ordonnancement plus centralisée si cela leur apporte ces résultats, surtout si l’alternative est une file d’attente publique bruyante où ils se font systématiquement « picked off ».

Mais cela ne marche que si la place traite l’ordonnancement et la préconfirmation comme des surfaces à encadrer, même si aucun régulateur ne l’impose. Autrement dit, vous devez vous gouverner comme une place boursière, parce que c’est ce que vous devenez, fonctionnellement.

Cela implique des politiques transparentes, des logs d’audit, de la surveillance et de vraies conséquences en cas d’abus. Et cela suppose d’assumer une réalité que beaucoup évitent : si vous voulez un flux « institutional », vous livrerez des contrôles de niveau broker et vous direz non à certains participants.

Mon point de vue : écrivez d’abord le règlement, puis livrez la vitesse

Une « layer 1 HFT » n’est pas une optimisation de performance. C’est une refonte de marché. Les gagnants ne seront pas les équipes avec le meilleur récit de latence. Ce seront celles capables d’expliquer, en termes opérationnels, qui contrôle l’ordonnancement, comment les rentes sont contenues et comment les incidents sont gérés.

Si vous en construisez une, ne commencez pas par le throughput. Commencez par la gouvernance : politique d’ordonnancement, allocation auditable, mécanismes de litige et risk gates qui tiennent sous stress.

Si vous vous y intégrez, ne commencez pas par la connectivité. Commencez par la mesure de la qualité d’exécution, des frameworks de limites, et un kill switch que vous pouvez déclencher en une action.

La vitesse s’achète facilement. La confiance se gagne chèrement. Les systèmes d’ordonnancement privé peuvent valoir le coup, mais uniquement si le règlement est explicite, applicable et auditable.