FIP Files, chapitre 10 : la proposition qui a fait en sorte que « faire le minimum » sur @FlareNetworks coûte désormais quelque chose. Avant cela, un fournisseur de données pouvait se présenter régulièrement pour FTSO tout en ignorant discrètement un protocole moins rentable, sans subir presque aucune conséquence. FIP.10 a corrigé cela grâce à un mécanisme simple : les passes. Chaque fournisseur commence à zéro. Réussissez les exigences minimales pour chaque protocole actif lors d’un époque, et vous gagnez une passe, jusqu’à un maximum de 3. Échouez sur un seul protocole, et vous perdez une passe. Si vous épuisez vos passes et que vous ne répondez toujours pas aux exigences, vous perdez tous vos récompenses pour cet époque, point final. Le seuil de staking est également délibérément échelonné. Un uptime de 80 % avec 1 M FLR auto-staké vous rend simplement éligible aux récompenses. Pour gagner ou perdre des passes, il faut 3 M FLR auto-stakés et 15 M FLR activement stakés, ce qui rend plus difficile pour les configurations partielles de manipuler le système comparé aux fournisseurs pleinement engagés. Une proposition jumelle, SIP.04, a appliqué la même logique en premier sur Songbird, le réseau canari de Flare, avant son déploiement sur le mainnet en février 2025. Personne ne voit cela sur un graphique. Mais c’est la raison pour laquelle les données FTSO ne se dégradent pas silencieusement lorsque de nouveaux protocoles sont ajoutés, et pourquoi les fournisseurs ne peuvent pas simplement choisir le protocole rentable et se reposer sur les autres.