כאשר משתמשים מצטרפים לפרויקט כרייה נייד, הם בדרך כלל מתחילים במשימות פשוטות.
הם פותחים את האפליקציה כל יום. הם כורים. הם מזמינים חברים. הם בונים קהילות. חלק מהמשתמשים יוצרים תוכן, מפעילים נוד או עוזרים לאמת משתמשים אחרים.
כל פעולה מבוססת על כללים שפורסמו על ידי הפרויקט.
עם זאת, הכללים עשויים להשתנות לאחר מספר חודשים או מספר שנים.
חדש KYC ייתכן שיופיעו דרישות. נוסחאות תגמול עשויות להשתנות. שיעורי המרה עשויים להיות מופחתים. תגמולי הפניה עשויים להיות תלויים בתנאים שלא היו קיימים קודם לכן. יתרות מסוימות עשויות להיות נעולות, מופחתות או מוסרות.
זה יוצר שאלה חשובה:
האם פרויקט צריך להשתמש בכללים חדשים כדי לשנות תגמולים שמשתמשים הרוויחו תחת הכללים הישנים?
פרויקטים זקוקים לזכות להשתנות
אף מערכת לא יכולה להישאר ללא שינוי לנצח.
ייתכן שפרויקט יצטרך לשנות את הכללים שלו ל:
- תפסיקו עם בוטים וחשבונות מזויפים.
- תקן שגיאות חישוב.
- הגן על אספקת האסימונים.
- לפעול לפי חוקים חדשים.
- הגן על נתונים אישיים.
- למנוע הונאה.
- תמיכה בפעילות ארוכת טווח.
- התאמת תגמולים עבור תרומות עתידיות.
ייתכן ששינויים אלה יהיו נחוצים.
עם זאת, על הפרויקט להפריד בבירור בין כללים לעבודה עתידית לבין כללים חדשים שיושמו על עבודה קודמת.
כללים חדשים צריכים לחול על עבודה חדשה
אם פרויקט משנה את נוסחת התגמול שלו, על המשתמשים לקבל הודעה לפני תחילת השינוי.
ההודעה צריכה להסביר:
- מתי ייכנס לתוקף הכלל החדש.
- אילו פעילויות יושפעו.
- כיצד יחושבו התגמולים.
- אם KYC התנאים ישתנו.
- האם תגמולים ישנים יישארו מוגנים.
- האם משתמשים יכולים להפסיק להשתתף אם אינם מסכימים.
לאחר קבלת מידע ברור, המשתמשים יכולים להחליט אם ברצונם להמשיך לתרום.
זהו שינוי שקוף.
יש להגן על תרומות קודמות
כלל חדש לא אמור להסיר באופן אוטומטי עבודה שהושלמה תחת כלל ישן.
לדוגמה, ייתכן שמשתמש הזמין מישהו כאשר KYC לא נדרש. מספר שנים לאחר מכן, הפרויקט עשוי להוסיף KYC דרישה לתגמולי הפניות.
ייתכן שהתנאי החדש נחוץ כדי לעצור חשבונות מזויפים. עם זאת, הפרויקט עדיין צריך להסביר:
- כמה זמן יישאר התגמול הישן מוגן?
- האם המזמין יאבד את כל הפרס?
- מה יקרה אם KYC אינו זמין במדינת המשתמש המוזמן?
- האם מזמין צריך להיות אחראי למעשיו של אדם אחר?
- האם תגמולים שנדחו יישרפו או יוחזרו למאגר אחר?
המשתמשים לא צריכים לשאת במלוא העלות של עיכובים KYC או שינויים שבוצעו על ידי הפרויקט.
פרויקט עשוי לשנות את הכללים למחר. אסור שהוא ימחק את העבודה שהושלמה אתמול.
מתי זה הוגן לתקן תגמולים ישנים?
במקרים מסוימים, ייתכן שיהיה צורך בתיקון תגמולים שכבר נרשמו בפרויקט.
זה עשוי להיות הוגן כאשר:
- ישנן ראיות ברורות לחשבון מזויף.
- משתמש השתמש בבוטים אסורים או בכלים אוטומטיים.
- המערכת ספרה את אותו גמול יותר מפעם אחת.
- ישנה תקלה טכנית שניתן לאמת.
- הפעילות הפרה כללים שכבר היו קיימים כשהעבודה הושלמה.
- החוק מחייב את הפרויקט לחסום או לדחות עסקה.
עם זאת, הפרויקט לא צריך רק להודיע למשתמשים שחשבון "אינו זכאי".
הפרויקט צריך לספק:
- סיבה ברורה.
- הכלל שהופר.
- המידע ששימש לקבלת ההחלטה.
- מועד אחרון להגשת ערעור.
- תהליך לבחינת התיק.
- זמן סקירה צפוי.
מניעת הונאה היא הכרחית. אך מניעת הונאה לא צריכה להפוך לסיבה להימנעות ממתן הסבר.
נדחה KYC אסור למחוק פרסים
KYC ייתכן שיידרש לפני שניתן יהיה להעביר אסימונים לארנק.
עם זאת, KYC וחישוב תגמול הן שתי משימות שונות.
אפילו כאשר לא ניתן להעביר טוקנים, פרויקט עדיין יכול:
- תיעוד תרומת המשתמש.
- חשבו את התגמולים בכל חודש.
- אשר תגמולים זכאים.
- פרסים נפרדים שמחכים להם KYC.
- הגן על הקצאות שאושרו.
- תנו למשתמשים דוח חודשי.
- לספק הליך ערעור כאשר מתרחשות שגיאות.
"מחכה ל KYC"לא אמור להיות "איננו יודעים אם הגמול שלך קיים".
If KYC אינו זמין במדינה מסוימת, אין להעניש משתמשים באותה מדינה על אי השלמת תהליך שהפרויקט לא סיפק.
כל איזון זקוק למצב ברור
לא לכל מספר בלוח המחוונים יש את אותה משמעות.
פרויקט צריך להפריד באופן ברור בין:
- תגמולים משוערים.
- תגמולים מאושרים.
- פרסים מחכים KYC.
- תגמולים בבדיקה.
- פרסים שהוקצו.
- תגמולים הועברו לארנק.
- תגמולים שנדחו והסיבה לדחייה.
אם כל הסכומים הללו מוצגים רק כ"יתרה", המשתמשים עלולים להבין לא נכון מה באמת הבעלים שלהם.
לוח מחוונים שקוף צריך להראות מה נרשם ומה המשתמש באמת שולט בו.
כללי תגמול חייבים להתקיים לפני שהמשתמשים יעבדו
לפני שמבקשים ממשתמשים לכרות, להזמין אחרים, ליצור תוכן או להפעיל את Node, פרויקט צריך לפרסם:
- נוסחת התגמול.
- תנאי זכאות.
- KYC דרישות.
- התאריך בו התגמולים מתקבלים באופן סופי.
- לוח הזמנים של החלוקה.
- תקופות נעילת אסימונים.
- סיבות מדוע ניתן להסיר תגמולים.
- הליך הערעור.
- זכותו של הפרויקט לשנות את מדיניותו.
- כיצד יטופלו תגמולים מוקדמים יותר לאחר שינוי מדיניות.
משתמשים אינם יכולים לקבל החלטה מושכלת אם תנאים חשובים מופיעים רק לאחר שכבר תרמו.
השמיים KYCFIRST תֶקֶן
KYCFIRST מציע עיקרון פשוט:
כללים חדשים לעבודה חדשה.
הגן על תגמולים שכבר צברת.
פרויקט אחראי צריך:
- יש להכריז על שינויים לפני יישומם.
- לעולם אל תשנו יתרות ללא הודעה מוקדמת.
- הימנעו מהחלת תנאים חדשים על עבודה ישנה ללא סיבה מוצדקת.
- הגן על תגמולים שמחכים להם KYC.
- תנו למשתמשים את הזכות לערער.
- הסבר כל פרס שנדחה.
- גלו לאן יועברו הפרסים שהוסרו.
- חשב ובחן את התגמולים בכל חודש.
שינוי מדיניות לא תמיד פסול.
הבעיה מתחילה כאשר פרויקט מקבל תרומות תחת סט כללים אחד ובהמשך משתמש בסט כללים אחר כדי להתחמק מאחריות.
על המשתמשים להכיר את הכללים לפני שהם תורמים.
על צוותי הליבה להגן על עבודה שכבר הושלמה.
הגינות לא צריכה להתחיל אחרי Mainnet.
