عندما ينضم المستخدمون إلى مشروع تعدين العملات الرقمية عبر الهاتف المحمول، فإنهم عادةً ما يبدأون بمهام بسيطة.
يفتحون التطبيق يومياً. يقومون بالتعدين. يدعون أصدقاءهم. يبنون مجتمعات. بعض المستخدمين ينشئون محتوى، أو يديرون عُقدًا، أو يساعدون في التحقق من مستخدمين آخرين.
كل إجراء يستند إلى قواعد منشورة من قبل المشروع.
ومع ذلك، قد تتغير القواعد بعد عدة أشهر أو عدة سنوات.
جديد KYC قد تظهر متطلبات جديدة. قد تتغير معادلات المكافآت. قد تنخفض معدلات التحويل. قد تعتمد مكافآت الإحالة على شروط لم تكن موجودة سابقًا. قد يتم تجميد بعض الأرصدة أو تخفيضها أو إزالتها.
وهذا يثير سؤالاً مهماً:
هل ينبغي للمشروع استخدام قواعد جديدة لتغيير المكافآت التي حصل عليها المستخدمون بموجب القواعد القديمة؟
المشاريع بحاجة إلى الحق في التغيير
لا يمكن لأي نظام أن يبقى دون تغيير إلى الأبد.
قد يحتاج المشروع إلى تغيير قواعده إلى:
- أوقفوا البرامج الآلية والحسابات المزيفة.
- تصحيح أخطاء الحساب.
- حماية مخزون الرموز.
- اتبع القوانين الجديدة.
- حماية البيانات الشخصية.
- منع الاحتيال.
- دعم العمليات طويلة الأجل.
- قم بتعديل المكافآت بناءً على المساهمات المستقبلية.
قد تكون هذه التغييرات ضرورية.
ومع ذلك، يجب على المشروع أن يفصل بوضوح بين قواعد العمل المستقبلي والقواعد الجديدة المطبقة على العمل السابق.
ينبغي تطبيق القواعد الجديدة على العمل الجديد
إذا قام مشروع ما بتغيير صيغة المكافآت الخاصة به، فيجب إخطار المستخدمين قبل بدء التغيير.
ينبغي أن يوضح الإشعار ما يلي:
- متى سيبدأ تطبيق القاعدة الجديدة؟
- ما هي الأنشطة التي ستتأثر؟
- كيفية حساب المكافآت.
- سواء KYC ستتغير الظروف.
- هل ستبقى المكافآت القديمة محمية؟
- ما إذا كان بإمكان المستخدمين التوقف عن المشاركة في حال عدم موافقتهم.
بعد تلقي معلومات واضحة، يمكن للمستخدمين أن يقرروا ما إذا كانوا يرغبون في مواصلة المساهمة.
هذا تغيير شفاف.
ينبغي حماية المساهمات السابقة
لا ينبغي أن تؤدي القاعدة الجديدة إلى إزالة العمل المنجز بموجب قاعدة قديمة بشكل تلقائي.
على سبيل المثال، قد يكون المستخدم قد دعا شخصًا ما عندما KYC لم يكن ذلك مطلوبًا. بعد عدة سنوات، قد يضيف المشروع KYC متطلبات مكافآت الإحالة.
قد يكون الشرط الجديد ضروريًا لوقف الحسابات المزيفة. ومع ذلك، لا يزال يتعين على المشروع توضيح ما يلي:
- إلى متى ستبقى المكافأة القديمة محمية؟
- هل سيخسر الداعي المكافأة بأكملها؟
- ماذا يحدث إذا KYC غير متوفر في بلد المستخدم المدعو؟
- هل ينبغي أن يكون الداعي مسؤولاً عن تصرفات شخص آخر؟
- هل سيتم حرق المكافآت المرفوضة أم إعادتها إلى صندوق آخر؟
لا ينبغي أن يتحمل المستخدمون التكلفة الكاملة للتأخير KYC أو التغييرات التي أجراها المشروع.
قد يُغيّر مشروعٌ ما قواعد الغد، لكن لا ينبغي له أن يمحو العمل المنجز بالأمس.
متى يكون من العدل تصحيح المكافآت القديمة؟
في بعض الحالات، قد يحتاج المشروع إلى تصحيح المكافآت التي تم تسجيلها بالفعل.
قد يكون هذا عادلاً عندما:
- هناك دليل واضح على وجود حساب مزيف.
- استخدم أحد المستخدمين برامج روبوت أو أدوات آلية محظورة.
- قام النظام باحتساب نفس المكافأة أكثر من مرة.
- هناك خطأ تقني يمكن التحقق منه.
- لقد خالف هذا النشاط القواعد التي كانت موجودة بالفعل عند اكتمال العمل.
- ينص القانون على إلزام المشروع بمنع أو رفض الصفقة.
ومع ذلك، لا ينبغي للمشروع أن يخبر المستخدمين فقط بأن الحساب "غير مؤهل".
ينبغي أن يوفر المشروع ما يلي:
- سبب واضح.
- القاعدة التي تم انتهاكها.
- المعلومات المستخدمة لاتخاذ القرار.
- الموعد النهائي لتقديم الاستئناف.
- عملية لمراجعة القضية.
- وقت المراجعة المتوقع.
يُعدّ منع الاحتيال أمراً ضرورياً، لكن لا ينبغي أن يكون منع الاحتيال ذريعةً للامتناع عن تقديم التفسير.
مؤجل KYC لا ينبغي حذف المكافآت
KYC قد يكون ذلك مطلوبًا قبل أن يتم تحويل الرموز إلى المحفظة.
ومع ذلك، KYC وحساب المكافأة مهمتان مختلفتان.
حتى عندما يتعذر نقل الرموز، لا يزال بإمكان المشروع ما يلي:
- سجل مساهمة المستخدم.
- احسب المكافآت شهرياً.
- تأكيد المكافآت المستحقة.
- مكافآت منفصلة في انتظارك KYC.
- حماية التخصيصات المؤكدة.
- قدّم للمستخدمين تقريراً شهرياً.
- يجب توفير آلية للاستئناف عند حدوث الأخطاء.
في انتظار KYCلا ينبغي أن تعني عبارة "لا نعلم ما إذا كانت مكافأتك موجودة أم لا".
If KYC إذا لم يكن متاحًا في بلد ما، فلا ينبغي معاقبة المستخدمين في ذلك البلد لعدم إكمالهم عملية لم يوفرها المشروع.
كل رصيد يحتاج إلى حالة واضحة
ليس لكل رقم على لوحة التحكم نفس المعنى.
ينبغي للمشروع أن يفصل بوضوح بين ما يلي:
- المكافآت المتوقعة.
- مكافآت مؤكدة.
- مكافآت في انتظارك KYC.
- المكافآت قيد المراجعة.
- المكافآت المخصصة.
- تم تحويل المكافآت إلى المحفظة.
- المكافآت المرفوضة وسبب الرفض.
إذا تم عرض كل هذه المبالغ فقط تحت مسمى "الرصيد"، فقد يسيء المستخدمون فهم ما يملكونه فعلياً.
ينبغي أن تُظهر لوحة التحكم الشفافة ما تم تسجيله وما يتحكم فيه المستخدم فعلياً.
يجب وضع قواعد المكافآت قبل أن يبدأ المستخدمون بالعمل
قبل مطالبة المستخدمين بالتعدين أو دعوة الآخرين أو إنشاء محتوى أو تشغيل العُقد، يجب على المشروع نشر ما يلي:
- معادلة المكافأة.
- شروط الأهلية.
- KYC المتطلبات.
- تاريخ الانتهاء من تحديد المكافآت.
- جدول التوزيع.
- فترات قفل الرمز المميز.
- أسباب سحب المكافآت.
- عملية الاستئناف.
- حق المشروع في تغيير سياسته.
- كيف سيتم التعامل مع المكافآت السابقة بعد تغيير السياسة.
لا يستطيع المستخدمون اتخاذ قرار مستنير إذا لم تظهر الشروط المهمة إلا بعد أن يكونوا قد ساهموا بالفعل.
استخدم KYCFIRST Standard
KYCFIRST يقترح مبدأً بسيطاً:
قواعد جديدة لعمل جديد.
احمِ المكافآت التي حصلت عليها بالفعل.
ينبغي للمشروع المسؤول أن:
- أعلن عن التغييرات قبل تطبيقها.
- لا تقم بتغيير الأرصدة دون إشعار.
- تجنب تطبيق شروط جديدة على أعمال قديمة دون سبب وجيه.
- احمِ المكافآت التي تنتظرك KYC.
- امنح المستخدمين الحق في الاستئناف.
- اشرح كل مكافأة تم رفضها.
- أفصح عن وجهة المكافآت المسحوبة.
- احسب وراجع المكافآت شهرياً.
تغيير السياسة ليس خطأً دائماً.
تبدأ المشكلة عندما يقبل مشروع ما المساهمات بموجب مجموعة من القواعد ثم يستخدم لاحقاً مجموعة أخرى من القواعد للتهرب من المسؤولية.
ينبغي على المستخدمين معرفة القواعد قبل المساهمة.
ينبغي على الفرق الأساسية حماية العمل المنجز بالفعل.
لا ينبغي أن تبدأ العدالة بعد الشبكة الرئيسية.
