Arquivos FIP, capítulo 10: a proposta que fez "fazer o mínimo necessário" no @FlareNetworks realmente ter um custo. Antes disso, um provedor de dados podia comparecer regularmente ao FTSO, mas ignorar silenciosamente um protocolo menos lucrativo, sem enfrentar quase nenhuma consequência. O FIP.10 corrigiu isso com um mecanismo simples: passes. Cada provedor começa com zero. Cumpra os requisitos mínimos em todos os protocolos ativos em um epoch e ganhe um pass, até um máximo de 3. Falhe em qualquer único protocolo e perca um pass. Esgote todos os passes e ainda assim não atinja o mínimo, e perderá todas as recompensas daquele epoch, ponto final. O requisito de staking também foi intencionalmente escalonado. 80% de uptime com 1M FLR auto-empenhados apenas o torna elegível para recompensas. Na verdade, ganhar ou perder passes exige 3M auto-empenhados e 15M ativamente stakeados, de modo que configurações menores e seletivas não consigam manipular o sistema tão facilmente quanto as totalmente comprometidas. Uma proposta gêmea, SIP.04, aplicou a mesma lógica primeiro ao Songbird, a rede canária da Flare, antes de ser implementada no mainnet em fevereiro de 2025. Ninguém vê isso em um gráfico. Mas é a razão pela qual os dados do FTSO não degradam silenciosamente à medida que novos protocolos são adicionados, e os provedores não podem simplesmente escolher o mais lucrativo e descansar nos demais.