Fin octobre 2025, Firedancer est passé en production sur le mainnet de Solana après trois ans de développement par Jump Crypto. En mars 2026, 207 validateurs l'utilisent, ce qui représente environ 20,9 % de tout le SOL staké sur le réseau. Figment, un des plus gros opérateurs de staking, a migré son validateur principal vers Firedancer à l'epoch 871 et a observé une amélioration de 18 à 28 points de base sur ses rendements de staking. Ce ne sont pas des promesses marketing, ce sont des résultats mesurés en production.
Pourquoi un deuxième client validateur
Jusqu'à Firedancer, Solana ne fonctionnait qu'avec un seul client validateur : Agave (anciennement Labs validator). Un seul client, ça veut dire un seul point de défaillance. Si un bug critique touche ce client, tout le réseau tombe. Et Solana a connu plusieurs pannes dans son histoire, parfois pendant des heures.
Firedancer est une réécriture complète en C/C++, indépendante du code original. Si un bug touche Agave, Firedancer continue de fonctionner, et inversement. C'est le même principe que les multiples clients d'Ethereum (Geth, Nethermind, Besu) qui rendent le réseau plus résilient. Polkadot a aussi adopté cette approche avec 43 équipes sur JAM.
1 million de TPS en laboratoire : que valent ces chiffres
Les tests en laboratoire ont montré Firedancer traitant plus de 1 million de transactions par seconde. La couche réseau seule a atteint 1,4 million de TPS sur un seul core lors des benchmarks de Jump. Ces chiffres font rêver, mais il faut les contextualiser.
En production, le débit réel de Solana tourne autour de 3 000 à 5 000 TPS. L'écart entre les benchmarks labo et la réalité est énorme, et c'est normal. En labo, vous contrôlez le réseau, les transactions sont simples, il n'y a pas de congestion. En production, les transactions sont complexes (swaps DeFi, NFT mints, programs calls imbriqués), le réseau est global, et des milliers de validateurs doivent se synchroniser.
Cela dit, même une amélioration de 2x ou 3x du débit réel serait significative. Et les gains observés par Figment sur les rendements de staking suggèrent que Firedancer permet aux validateurs de capturer plus de transactions par bloc, y compris les transactions prioritaires et le MEV.
L'architecture technique qui fait la différence
Firedancer utilise un stack réseau custom avec du kernel-bypass. En simplifiant : au lieu de passer par le système d'exploitation pour traiter les paquets réseau (ce qui ajoute de la latence), Firedancer accède directement au matériel réseau. C'est une technique utilisée dans le trading haute fréquence en finance traditionnelle, et c'est logique que Jump Crypto (une boîte de trading quantitatif) l'ait implémentée.
Le protocole de transport utilise QUIC et UDP, et la couche d'ingestion peut absorber des données aussi vite que le hardware physique le permet. Concrètement, les validateurs Firedancer peuvent recevoir et redistribuer les transactions sans les goulots d'étranglement que le système d'exploitation impose normalement.
Impact sur le staking Solana
Si vous stakez du SOL, le client de votre validateur commence à compter. Un validateur Firedancer peut inclure plus de transactions par bloc, capturer plus de frais prioritaires, et donc distribuer des rendements légèrement supérieurs. L'avantage de 18-28 bps observé par Figment semble modeste, mais sur un an et avec un gros montant staké, ça s'accumule.
Je m'attends à ce que de plus en plus de validateurs migrent vers Firedancer en 2026. Le passage de 8 % à 20,9 % du stake en quelques mois montre que la confiance augmente. À terme, le réseau sera plus rapide, plus stable, et les rendements de staking pourraient s'améliorer pour ceux qui choisissent les bons validateurs.
Les risques à garder en tête
Un nouveau client validateur, c'est aussi du nouveau code. Et du nouveau code, c'est de nouveaux bugs potentiels. Firedancer a été audité et testé extensivement, mais rien ne garantit l'absence totale de problèmes en production. Les premiers mois de déploiement sont les plus critiques.
L'autre risque est la centralisation technique. Si Firedancer devient tellement supérieur que tous les validateurs l'adoptent et qu'Agave disparaît, on retombe dans le problème du client unique. L'idéal, c'est un équilibre où les deux clients coexistent, chacun avec une part significative du réseau.
