ملفات FIP، الفصل 10: الاقتراح الذي جعل "القيام بأدنى حد ممكن" على @FlareNetworks يكلف شيئًا. قبل هذا، كان يمكن لمزود البيانات أن يظهر بانتظام لـ FTSO لكنه يتجاهل بهدوء بروتوكولًا أقل ربحية، دون مواجهة أي عواقب تقريبًا. أصلح FIP.10 ذلك بآلية بسيطة: التذاكر. يبدأ كل مزود من الصفر. إذا استوفيت الحد الأدنى من المتطلبات عبر كل بروتوكول نشط في فترة زمنية، فتكتسب تذكرة، حتى الحد الأقصى البالغ 3. وإذا فشلت في أي بروتوكول واحد، تخسر تذكرة واحدة. وإذا نفذت جميع التذاكر وما زلت غير مستوفٍ للمتطلبات، فتخسر جميع المكافآت لتلك الفترة، تمامًا. كما تم تصميم عتبة التخصيص بشكل متدرج عمداً. فـ 80% من وقت التشغيل مع 1M FLR مُخصصة ذاتيًا يكفي فقط لتأهيلك للمكافآت. أما كسب أو خسارة التذاكر فيتطلب 3M مُخصصة ذاتيًا و15M مُستثمرة بنشاط، مما يجعل من الصعب على الترتيبات الصغيرة التي تختار فقط الأرباح تلاعب النظام بنفس السهولة التي يمكن بها للجهات الملتزمة تمامًا فعل ذلك. اقتراح مزدوج، SIP.04، طبق نفس المنطق أولاً على Songbird، شبكة الاختبار الخاصة بـ Flare، قبل إطلاقه على الشبكة الرئيسية في فبراير 2025. لا يرى أحد هذا في أي مخطط. لكنه السبب في أن بيانات FTSO لا تتدهور بهدوء مع إضافة بروتوكولات جديدة، ولا يمكن للمزودين ببساطة اختيار البروتوكول الربحي فقط والاعتماد على الباقي.