إذا كنت مؤسس Kaito، كيف ستنجو InfoFi 2.0؟

العنوان الأصلي: What If: I Were the Founder of Kaito?
المؤلف الأصلي: RYAN YOON, TIGER RESEARCH
ترجمة: Peggy, BlockBeats

ملاحظة المحرر: تسبب تعديل لمرة واحدة في سياسة API في "تجميد جماعي" لـ InfoFi في غضون ثلاثة أيام. لم يكشف هذا الانهيار عن اعتماد Web3 العميق على المنصات المركزية فحسب، بل كشف أيضًا عن جانب آخر من آليات التحفيز: كلما زادت المكافآت، زادت سرعة التلاعب، مما جعل مراقبة الجودة أكثر صعوبة.

تتخذ هذه المقالة من Kaito نقطة انطلاق، وتحدد خمس طرق خروج ممكنة لمشروع InfoFi، وتشير إلى أن InfoFi 2.0 من المرجح أن يتجه نحو نطاق أصغر، وفحص أقوى، ونمط أكثر مراقبة للجودة. بالإضافة إلى ذلك، هناك سؤال أكثر أهمية وهو: بعد تلاشي الإيردروب وهوس السرديات، ما الذي سيدعم قيمة توكن InfoFi؟

فيما يلي النص الأصلي:

النقاط الرئيسية

تسبب تغيير سياسة X في انهيار نظام InfoFi البيئي في غضون ثلاثة أيام، مما كشف عن الحدود الهيكلية للاعتماد المفرط على المنصات المركزية.

يواجه مشروع InfoFi حاليًا خمسة خيارات: الإغلاق؛ الانتقال إلى منصة مهام قائمة على آلية المكافآت؛ اعتماد نموذج كتابة المحتوى المدعوم من العلامات التجارية على الطراز الكوري؛ التوسع في عمليات متعددة المنصات؛ أو التحول إلى نموذج إدارة KOL على طراز MCN.

من المرجح أن يتطور InfoFi 2.0 إلى نموذج أصغر وأكثر قابلية للتحكم، حيث ينتقل من "التوسع واسع النطاق بدون إذن" إلى "التعاون بين KOLs المختارين وفرق المشروع".

لا تزال هناك تحديتان أساسيتان دون حل: كيفية إنشاء نظام مكافآت عادل وكيفية توفير دعم معقول لقيمة التوكن.

انهيار InfoFi في غضون ثلاثة أيام

المصدر: X (@nikitabier)

في 15 يناير، نشر نيكيتا بير، رئيس المنتجات في X، تحديثًا قصيرًا، يوضح بوضوح أن المنصة لن تسمح بعد الآن للتطبيقات التي "تستبدل المكافآت بالمنشورات" بالاستمرار في العمل. بالنسبة لمشروع InfoFi، كان هذا يعادل تقريبًا حكمًا بيوم القيامة.

وفقًا لمراجعة مؤسس Kaito، يو هو، كان تقدم الحدث تقريبًا كما يلي:

13 يناير: تلقت Kaito بريدًا إلكترونيًا من X يفيد بأنهم قد يدخلون في عملية التدقيق. أرسل الفريق على الفور ردًا يطلب مزيدًا من التوضيح.

14 يناير: أصدرت X إشعارًا قانونيًا رسميًا وقدمت Kaito ردًا قانونيًا في نفس اليوم.

15 يناير: تم نشر منشور نيكيتا بير العام. عرفت Kaito، مثل أي شخص آخر، بالقرار النهائي في نفس الوقت تقريبًا.

كان رد فعل السوق لا يرحم.

انخفض $KAITO بسرعة، وبدأ المجتمع أيضًا في انتقاد الفريق لـ "ادعائهم بوجود خطة طوارئ ولكنهم فشلوا في التحذير من المخاطر مسبقًا". في ذلك المساء، أصدرت Kaito بيانًا طارئًا يوضح أنهم تلقوا إشعارات قانونية من X في الماضي، وكلها تم حلها في النهاية عن طريق توقيع اتفاقيات جديدة. لذلك، اختار الفريق هذه المرة انتظار مزيد من التواصل والتفاوض أولاً.

ومع ذلك، بغض النظر عن التفسير، أصبح الواقع واضحًا بما فيه الكفاية: قرار واحد من X أنهى مباشرة نظام InfoFi البيئي بأكمله. في غضون ثلاثة أيام فقط، انهار مسار كامل تمامًا لأن المنصة اعتبرته ضارًا بتجربة المستخدم وجودة المحتوى.

إذا كنت مؤسس مشروع InfoFi اليوم

هل يعني هذا أن InfoFi قد انتهى؟ في الواقع، كانت مشاريع مثل Kaito تستعد للخطوات التالية. لكن ما نحتاجه حقًا الآن ليس الاستمرار في النموذج القديم بل العثور على شكل مختلف من InfoFi 2.0.

إذا كنت مؤسس مشروع InfoFi مثل Kaito، فما هي الخيارات القابلة للتطبيق المتبقية في الواقع اليوم؟ من خلال فحص هذه المسارات "القابلة للتطبيق"، قد نتمكن من تحديد كيف ستبدو المرحلة التالية من InfoFi.

الإغلاق

هذا هو الخيار الأكثر مباشرة وبساطة: التقليص ووقف العمليات بمجرد نفاد الأموال. في الواقع، من المرجح أن تدخل العديد من المشاريع الصغيرة والمتوسطة في "حالة الزومبي"، حيث لا يتم تحديث المنتج بنشاط، ويتم النشر من حين لآخر على وسائل التواصل الاجتماعي، ثم تتلاشى ببطء.

نظرًا لأن PMF (توافق المنتج مع السوق) للمنتج تم بناؤه فوق X، والآن تمت إزالة هذا الأساس، فإن تقليل الخسائر في الوقت المناسب والخروج بشكل استباقي يتوافق مع العقلانية التجارية أكثر من الاستمرار في حرق الأموال للبحث عن اتجاه جديد.

إذا كان المشروع لا يزال يحتفظ بأصول بيانات قابلة لإعادة الاستخدام، فقد يفكر أيضًا في بيعها لشركات أخرى لاسترداد بعض القيمة. ولهذا السبب من المرجح أن تختار معظم مشاريع InfoFi الصغيرة والمتوسطة هذا المسار.

منصة مهام قائمة على المكافآت

عندما لا يمكن الاستمرار في استخدام API الخاص بـ X، فإن البديل القابل للتطبيق هو العودة إلى نموذج تحفيزي "أكثر تقليدية": جعل KOLs يسجلون مباشرة للمشاركة في الأنشطة، وإرسال محتواهم للمراجعة اليدوية، والموافقة عليه، ثم مكافأتهم.

هذه الآلية تشبه في الأساس "منصات المهام" أو "برامج المكافآت" المبكرة: يتقدم KOLs بشكل استباقي؛ يقوم فريق المشروع بالفحص اليدوي وتعيين المهام؛ يقدم المبدعون المحتوى؛ تقوم المنصة بتسوية المكافآت بعد الموافقة.

إنها تضحي بالأتمتة والقابلية للتوسع الأصلية، ولكنها تكتسب عملية تنفيذ أكثر قابلية للتحكم. في الحالات التي تزداد فيها قواعد المنصة صرامة، يكون هذا النهج "غير الفعال ولكن المتوافق" أسهل في البقاء.

المصدر: Scribble

Scribble هي حالة نموذجية. يصدر فريق المشروع منحة في شكل "مهمة مكافأة"، ويقوم KOLs بإنشاء محتوى وتقديمه للمراجعة. لا يمكنهم الحصول على المكافأة إلا بعد الموافقة. هذه الآلية لا تتعلق بالتتبع في الوقت الفعلي والتسوية الفورية، بل تميل أكثر إلى نموذج عملية "تقديم-مراجعة".

هذا الهيكل لديه القدرة على أن يصبح منصة مفتوحة: توفر المنصة دعم المطابقة والبنية التحتية، بينما تكون المشاريع الفردية مسؤولة عن عمليات الأحداث المحددة وإدارة المحتوى. مع انضمام المزيد من المشاريع، يتوسع مجمع KOLs؛ ومع نمو قاعدة المبدعين، يكون لدى فرق المشروع أيضًا المزيد من المتعاونين المحتملين للاختيار من بينهم.

ومع ذلك، فإن عيوبها واضحة أيضًا: عدم اليقين العالي بالنسبة لـ KOLs. إذا تم رفض محتواهم، تضيع تكلفة الوقت المستثمرة تمامًا. بعد تجربة إخفاقات متعددة، من المرجح أن يغادر KOLs المنصة.

نموذج "مدونة العلامة التجارية" على الطراز الكوري

المصدر: Revu

يتبع نموذج "مدونة العلامة التجارية" الكوري مسار "الفحص أولاً، ثم الإدارة"، بدلاً من نهج "إنشاء المحتوى أولاً، ثم المراجعة" الذي يظهر في منصات المكافآت. تعمل مؤسسات مثل Revu تحت هذا النموذج منذ أكثر من عقد.

العملية واضحة جدًا أيضًا: يحدد فريق المشروع أولاً العدد المستهدف للمشاركين ويطلق نشاطًا. بعد أن يقدم المبدعون طلباتهم، يختار فريق المشروع KOLs المتعاونين بناءً على مقاييس مثل حجم قاعدة المعجبين والأداء السابق. يتلقى KOLs المختارون إرشادات محتوى واضحة ومتطلبات كتابة. بعد نشر المحتوى، يتم فحصه من قبل موظفي العمليات؛ إذا لم يستوف المعايير، يتم طلب تعديلات. قد يؤدي عدم التقديم في الوقت المحدد إلى عقوبات أو خصومات.

أكبر ميزة لهذا النموذج هي أن المبدعين لا يخرجون خاليي الوفاض تقريبًا. طالما تم اتباع عملية الاختيار واستيفاء المعايير، يمكن اعتبار المكافأة مقفلة بشكل أساسي، مما يتجنب خطر "رفض الإكمال الذي يؤدي إلى تكلفة عمالة صفرية" الموجود في آليات المكافآت. بالنسبة لفريق المشروع، نظرًا لأنه يتم فحص المتعاونين مسبقًا، فإن إدارة الجودة أسهل، مما يجعل التنفيذ العام أكثر قابلية للتحكم.

التوسع متعدد المنصات

إذا لم يعد X متاحًا، فإن الخيار التالي القابل للتطبيق هو التحول إلى منصات مثل YouTube وTikTok وInstagram وغيرها. في الواقع، داخل مجتمع Web3، كان "التحرك إلى ما بعد X" إجماعًا منذ فترة طويلة: لتحقيق نمو هادف، من الضروري الانتقال من مجتمع يتكون أساسًا من مستخدمي التشفير الأصليين إلى قنوات حيث توجد قاعدة مستخدمين أوسع.

الميزة الرئيسية لهذا النهج هي قاعدة المستخدمين المحتملة الأكبر بكثير مقارنة بـ X. خاصة في الأسواق الناشئة مثل جنوب شرق آسيا وأمريكا اللاتينية، قد يكون تأثير TikTok وInstagram أقوى. بالإضافة إلى ذلك، لكل منصة منطق توزيع المحتوى الخاص بها، لذلك حتى لو تم تقييد منصة واحدة، يمكن الحفاظ على الظهور والعمليات في قنوات أخرى.

ومع ذلك، فإن المقايضة هي زيادة حادة في التعقيد التشغيلي. على X، تحتاج فقط إلى مراجعة النصوص والتفاعلات؛ على YouTube، يؤثر وقت المشاهدة وجودة الإنتاج بشكل مباشر على الأداء؛ على TikTok، تحدد الثواني الثلاث الأولى النجاح أو الفشل؛ على Instagram، من الضروري تقييم القصص والتخطيط والاكتمال البصري. يتطلب هذا من الفريق امتلاك قدرات تشغيل المنصة أو إنشاء أدوات وعمليات جديدة. علاوة على ذلك، تختلف سياسات API للمنصة وطرق استرجاع البيانات، وهو ما يشبه "إعادة بناء النظام".

لا تزال مخاطر السياسة موجودة، حيث يمكن لأي منصة تغيير قواعدها فجأة كما فعلت X. ومع ذلك، يمكن للوجود متعدد المنصات على الأقل تخفيف مخاطر النقطة الواحدة. بالنسبة للمشاريع الأكبر، هذا هو الاتجاه الوحيد الذي لا يزال يوفر "مساحة قابلة للتوسع".

نموذج إدارة KOL على طراز MCN

في نموذج MCN للويب 2، تحدد قيمة العلامة التجارية لـ KOLs قيمتها التجارية بطبيعتها؛ في Web3، هذا التأثير أكثر وضوحًا. تقود السرديات تدفقات الأموال، ويتم تضخيم تأثير قادة الرأي لدرجة أنهم يمكنهم التأثير بشكل مباشر على أسعار التوكن، مع تعليق واحد يسبب تقلبات.

لقد قامت بعض مشاريع InfoFi الناجحة بالفعل ببناء مجموعة نشطة ومتماسكة للغاية من KOLs. لم يتم جلب هؤلاء KOLs مؤقتًا من الخارج ولكنهم نموا تدريجيًا على المنصة على مدى أشهر. على عكس MCNs للويب 2 التي تعتمد على "اكتشاف المواهب" المستمر، من المرجح أن يحتفظ InfoFi بـ KOLs الحاليين هؤلاء ويحول ميزة المنصة نحو الإدارة والتوزيع القائم على البيانات.

ما يسمى بـ MCN-ization يعني أن الشراكة ستنتقل من "المشاركة الطوعية" الفضفاضة إلى عقد والتزام أكثر رسمية. من خلال الاستفادة من البيانات وشبكات العلاقات المتراكمة لفترة طويلة، ستكون القوة التفاوضية للمنصة في نظام Web3 البيئي أقوى أيضًا، مما يسهل الحصول على شروط شراكة وتخصيص موارد أفضل.

ومع ذلك، يفرض هذا المسار متطلبات أعلى على مشروع InfoFi: يجب أن يكون هناك نظام إدارة قوي بما فيه الكفاية، وستصبح "البيانات" أصلًا أساسيًا. إذا تمكنت المنصة من استخدام البيانات لتوجيه سرعة مخرجات KOLs واتجاه المحتوى وفعالية التحويل، وتزويد المشروع باستراتيجية Go-To-Market (GTM) أكثر احترافية وقائمة على البيانات، فقد يؤسس هذا النموذج حاجزًا تنافسيًا طويل الأمد.

InfoFi 2.0

ترك انهيار InfoFi درسين مهمين لنظام Web3 البيئي بأكمله.

الأول هو سخرية اللامركزية: تعتمد العديد من مشاريع Web3 في الواقع بشكل كبير على المنصة المركزية X، وقرار واحد من X يكفي للتسبب في انهيار النظام بأكمله.

الثاني هو حدود تصميم الحوافز: نجحت آلية المكافآت بالفعل في جذب عدد كبير من المشاركين، لكن المنصة افتقرت إلى تدابير فعالة لمراقبة الجودة، مما أدى إلى انتشار سريع للمحتوى غير المرغوب فيه وسلوك الألعاب، مما أعطى X أكثر من أسباب كافية للتدخل والإغلاق.

المصدر: X (@nikitabier)

هل يعني هذا أن InfoFi قد انتهى؟

ليس تمامًا. قد تظل بعض المشاريع التي حققت بالفعل PMF (توافق المنتج مع السوق) على قيد الحياة من خلال إعادة تشكيل نفسها، مثل الانتقال إلى التوسع متعدد المنصات، أو إجراء مواضع إعلانية أكثر اختيارًا، أو الترقية إلى نموذج إدارة KOL على طراز MCN.

ومع ذلك، من المرجح أن يصبح InfoFi 2.0 أصغر وأكثر قابلية للتحكم، ويضع تركيزًا أكبر على جودة المحتوى. سينتقل من "شكل المنصة" المفتوح وغير المصرح به والساعي للحجم في الماضي إلى شبكة شراكة مختارة، تشبه إلى حد كبير منصة تسويق متكاملة تدفع GTM محليًا وتجمع بين مكونات مثل الإعلانات غير المتصلة بالإنترنت لتشكيل حلقة تنفيذ أكثر اكتمالًا.

ومع ذلك، لا تزال القضايا الأساسية قائمة.

يشير جويل مون من Tiger Research House إلى أنه بمجرد إدخال آلية المكافآت، سيبحث المشاركون حتماً عن طرق "للتلاعب" بالنظام، مما يجعل من المستحيل تقريبًا تصميم هيكل حوافز عادل. سيستمر هذا السلوك في خفض جودة المحتوى وخلق حلقة ردود فعل سلبية، مما يضر في النهاية بالمنصة نفسها—وهو التحدي الرئيسي الذي يجب أن يواجهه مشروع InfoFi بشكل مباشر.

طرح ديفيد سؤالًا أكثر جوهرية. كان يعتقد أن اقتراح قيمة توكن InfoFi، بدلاً من نابعه من الأداء الفعلي للمنصة، كان يعتمد أكثر على "staking إيردروب" و"إيمان السردية". ومع ذلك، فقد كلاهما أهميتهما العملية، لذلك تم طرح السؤال مباشرة: لماذا يشتري المستثمرون توكن InfoFi؟

إذا أراد InfoFi 2.0 البقاء، فيجب عليه تقديم إجابات واضحة على هذه الأسئلة. المشروع المنفصل عن حاملي التوكن يكافح في النهاية لتحقيق استدامة حقيقية.

[رابط المقالة الأصلية]