Archivos FIP, capítulo 10: la propuesta que hizo que "hacer lo mínimo indispensable" en @FlareNetworks tuviera un costo. Antes de esto, un proveedor de datos podía presentarse de forma confiable para FTSO pero omitir silenciosamente un protocolo menos rentable, sin enfrentar consecuencias prácticamente ninguna. FIP.10 solucionó esto con un mecanismo sencillo: pases. Cada proveedor comienza en cero. Cumple los requisitos mínimos en cada protocolo activo durante un epoch y ganas un pase, hasta un máximo de 3. Si fallas en cualquier protocolo, pierdes uno. Si te quedas sin pases y aún así no cumples, pierdes todas las recompensas de ese epoch, punto final. El umbral de staking también está deliberadamente escalonado. Un 80% de uptime con 1M FLR auto-enlazados solo te hace elegible para recompensas. Para ganar o perder pases realmente, se requieren 3M auto-enlazados y 15M en staking activo, por lo que los esquemas más pequeños y selectivos no pueden manipular el sistema tan fácilmente como los participantes plenamente comprometidos. Una propuesta gemela, SIP.04, aplicó la misma lógica primero a Songbird, la red canaria de Flare, antes de su lanzamiento en mainnet en febrero de 2025. Nadie ve esto en un gráfico. Pero es la razón por la que los datos de FTSO no se degradan silenciosamente a medida que se añaden nuevos protocolos, y los proveedores no pueden simplemente elegir el más rentable y descansar en los demás.