מדוע טוקנים חברתיים אינם מצליחים להחזיק משתתפים
טוקנים חברתיים מושקים על גל של עניין: החלוקה הראשונה אוספת אנשים, הצ'אט מתעורר לחיים, המונים עולים. לאחר כמה שבועות הירידה בפעילות נעשית מורגשת — המשתתפים לקחו את התגמולים ועזבו, מכיוון שבתוך כלכלת הקהילה לא נותרה סיבה לחזור.
בדרך כלל נשברים שלושה צמתים. תגמולים פנימיים מונפקים בלי ערוצי הוצאה: נקודות נזקפות לכולם וכמעט על הכול, אבל אין היכן להמיר אותן — היתרה גדלה, הערך יורד, והמשתתף קורא זאת לפני הצוות.
כללי הזיכוי חיים במצב ידני: עבור תרחיש חדש מוסיפים תנאי לטבלה, שוכחים מהרשומה ההפוכה, ובשלב מסוים אף אחד לא יכול להסביר מאין סכום כזה אצל המשתתף. אין שקיפות: האדם רואה את התוצאה, אבל לא רואה את הנוסחה — על מה בדיוק זוכה ומתי זה יפוג.
החזקת משתתפים במערכת כזו נשענת על הבטחה לתועלת עתידית, ולא על מכניקה. לכן הניתוח מתחיל לא מהנפקת הטוקן, אלא ממטרות הקהילה: היכן המשתתף מקבל ערך, היכן הוא מוציא את התגמול, מי ולפי איזה כלל מזכה אותו.
אנו מחשבים את שיעור הפעילים עד לגל השני, את שיעור התגמולים שהוצאו בכלל, ואת מספר העריכות הידניות של הכללים בתקופה — לפי המספרים האלה רואים היכן המבנה דולף. בהמשך נפרק כיצד זה נסגר.
מה נותנת מערכת טוקנים חברתיים מהונדסת היטב
מערכת של טוקנים חברתיים היא כלכלה של תרומה, ולא «טוקן לשם טוקן». הנפקת התגמולים קשורה לפעולות ניתנות לאימות: תשובה מועילה, ניתוח מקרה של אחר, משתתף שהוזמן ונשאר פעיל. חוזה על ERC-20 מספק תאימות לארנקים מוכרים — המשתתף רואה את היתרה במקום שנוח לו, ולא בפאנל סגור נפרד.
מדדי פעילות מחושבים מאירועים, ולא מסקרים: שיעור המשתתפים הפעילים בתקופה, שיעור הפעולות החוזרות, הזמן עד לתרומה הראשונה. כאשר משקולות התגמול נראים בנתונים, ההנפקה מופנית מחדש למקום שבו היא מייצרת פעולות חוזרות, ולא התפרצויות חד-פעמיות.
ניהול היתרה מפריד בין מערכת עובדת לבין אינפלציה: מגבלות הנפקה יומיות, vesting עבור הפקדות גדולות, מנגנוני חיוב — גישה לחומרים סגורים, סלוטים לאירועים, הצבעה. שיעור התגמולים שלא נפדו נשמר בטווח מוגדר, אחרת הטוקן מפסיק להיות כלי והופך לנקודה בלי שימוש.
מודרציה של זיכויים עוברת לתוך הכללים: סף מוניטין לפעולות מזכות, חלון צינון, אישור ידני רק למקרים שנויים במחלוקת. שיעור ההחלטות הדורשות אדם יורד מכל זיכוי לכמה אחוזים בודדים — המנהל עוסק בקונפליקטים, ולא בחשבון.
על מעורבות הקהילה זה משפיע באופן מדיד: שיעור המשתתפים הפעילים עולה, הפעולות החוזרות מתגברות, הנשירה יורדת. בהמשך פרמטרי ההנפקה מתוקנים לפי נתונים, בלי לכתוב מחדש את לוגיקת החוזים.
אפשרויות מבנה: מעגל סגור, רשת פתוחה, היברידי
את סכימת ההנפקה בוחרים לא לפי טכנולוגיה, אלא לפי שתי דרישות: עד כמה הפעולות צריכות להיות גלויות החוצה ומי מוסמך לשנות את כללי הזיכוי. מכך תלויים גם אמון המשתתפים וגם מחיר השינויים לאחר ההשקה.
מעגל סגור מנהל את החשבונאות בתוך תשתית הקהילה: את היתרות ואת היסטוריית הזיכויים רואים המפעיל ובעל החשבון עצמו, ואת הכללים משנה מנהל המערכת. רשת פתוחה מפרסמת כל פעולה, והכללים קבועים בחוזה ומשתנים לפי נוהל שתואר מראש.
סכימה היברידית משאירה את החשבונאות סגורה, אך מפרסמת ברשת הפתוחה הוכחות להנפקות: המשתתף מאמת שההנפקה לא חרגה מהמגבלה, בלי לחשוף את גודל היתרה שלו.
| אפשרות | נראות הפעולות | מי מנהל את הכללים | מתי מתאים | מגבלות |
|---|---|---|---|---|
| מעגל סגור | מפעיל ובעל חשבון | מנהל הפלטפורמה | נקודות פנימיות ורמות נאמנות | אין אימות חיצוני, האמון נשען על המוניטין של המפעיל |
| רשת פתוחה | כל הפעולות פומביות | חוזה והצבעת בעלי החשבון | תגמולים פומביים, מאגרים משותפים | אי-הפיכות של פעולות ושקיפות מלאה של היתרות |
| סכימה היברידית | החשבונאות סגורה, ההוכחות פומביות | הכללים — המפעיל, הנוהל — בחוזה | קהילות עם קהל ופרטנרים כשנתוני המשתתפים סגורים | שתי סביבות והסנכרון ביניהן |
את הסכימה קובעים בשלב התכנון: להעביר מעגל מסגור לפתוח לאחר ההשקה יקר יותר מאשר להטמיע אותה מלכתחילה.
שלבי הפיתוח: מביקורת הקהילה ועד להשקה
המכניקה של טוקן חברתי נשמעת פשוטה: המשתתף מקבל תגמול על פעילות. העבודה ההנדסית מתחילה במקום שבו כל זיכוי צריך להיות מתואר כפונקציה חד-משמעית של אירוע — אחרת הכללים מתפרשים באופן שונה, ומקרים שנויים במחלוקת נפתרים ידנית. לכן שלבי הפיתוח הולכים מביקורת תפקידים למפרט פורמלי, והשקת המערכת היא הצעד האחרון, לא הראשון.
-
ביקורת הקהילה והתפקידים. אוספים מפת משתתפים והרשאות: מי יוזם זיכוי, מי מאשר, מי יכול לשנות פרמטרים או לעצור את ההנפקה. כל תפקיד הופך למערכת הרשאות בחוזה, ולא להסכמה בצ'אט — זה מסיר סוג שלם של קונפליקטים מסוג «חשבנו שהוא לא יכול לעשות כך».
-
מפרט כללי הזיכוי. קובעים את נוסחת ההנפקה, משקולות הפעולות, תקופות, מגבלות לארנק ולחלון זמן. בנפרד מתארים מניעת הונאה: מה נחשב לפעולה כפולה וכיצד מטופלות התפרצויות פעילות.
-
מנגנוני בטיחות. השהיית הנפקה, מגבלה לפעולה אחת, השהיית משיכה, אישור שינוי פרמטרים בכמה חתימות. הם מוטמעים לפני המימוש: להטמיע אותם במערכת מוכנה יקר ומסוכן יותר מאשר להביא אותם בחשבון מראש.
-
מימוש וביקורת פנימית. החוזים של הטוקן, ההפצה וההצבעות נכתבים בקפדנות לפי המפרט ומכוסים בבדיקות למקרי קצה: זיכוי אפס, חריגה מהמגבלה, בקשה חוזרת למשיכה.
-
בדיקת תרחישים ברשת בדיקה. מריצים מחזור מלא — זיכוי, הצבעה, המרה, משיכה. בנפרד מדמים אנומליות: רישום המוני, גידול לא אופייני בהנפקה, כשל של שירות חיצוני — ובודקים לאיזה מצב המערכת נכנסת.
-
סקירת קוד חיצונית והכנה להשקה. מומחים בלתי תלויים בודקים את החוזים ואת לוגיקת ההרשאות, וההערות נסגרות לפני ההפעלה. הרשאות המנהל מועברות לחתימה מרובה או לקהילה, ונקבע נוהל עדכון.
-
השקה ומעקב. המערכת מופעלת עם מגבלות מוגבלות, שאותן מעלים בהדרגה, כל עוד ההנפקה וההפצה נשארות בטווח המצופה. בהמשך — ניטור, התראות על אנומליות ונוהל ברור לחזרת פרמטרים.
שלב נחשב לסגור לא כאשר הקוד נכתב, אלא כאשר התנהגות המערכת ברשת הבדיקה תואמת את המפרט, ומנגנוני הבטיחות נבדקו תחת עומס.
מארז האספקה: קונפיגורציות, תרשימים, מדיניות, נהלים
איננו מוסרים אוסף קבצים, אלא מערכת עובדת שלפיה צוות הלקוח ממשיך לנהל את הקהילה באופן עצמאי. המארז כולל את כל מה שנדרש כדי לשנות פרמטרים של תגמולים, לטפל במקרים שנויים במחלוקת ולחבר מנהלים חדשים בלי לפנות אלינו.
- קונפיגורציות של הנפקה ומשקולות תגמולים: היכן משתנים המגבלות למשתתף, קצב הזיכוי וספי הרמות — עם הסבר לכל פרמטר.
- תרשימי זרימת התגמולים: המסלול של הטוקן מפעולת המשתתף ועד לזיכוי, נקודות הבדיקה והתנהגות המערכת בעת תקלה.
- מדיניות גישה: מטריצת תפקידים — מי מזכה, מי רק קורא, מי יכול להשהות תשלומים וכיצד מוענק כל תפקיד.
- נהלי מודרציה: קריטריונים לניפוח מלאכותי, סדר החסימה והשחזור, זמני תגובה לתלונות משתתפים.
- הוראות למצבים שנויים במחלוקת: זיכוי כפול, העברה שגויה, פריצה לחשבון — עם סדר פעולות מוכן.
- תיעוד לגבי גיבויים וחזרה לאחור: אילו מצבים נשמרים, לאיזו תקופה, וכיצד להחזיר את המערכת לנקודה שלפני התקלה.
- צ'ק-ליסט קבלה: תרחישים שאנו מריצים יחד עם הצוות שלכם לפני המסירה, עם תוצאה מצופה לכל אחד.
הארטיפקטים נשארים אצלכם יחד עם הקוד ומתעדכנים בכל שינוי, ולכן אינם סוטים מההתנהגות בפועל של המערכת. אנו משלימים את המארז בניתוח ובהדרכת הצוות, כדי שאנשים חדשים לא ישחזרו את הלוגיקה מתוך תכתובות.
מקרה בוחן: קהילה עם פעילות יורדת של בעלי הטוקן
הקהילה הגיעה עם סכימה קלאסית: טוקנים זוכו עבור הודעות ותגובות בצ'אט, לא היה סף למשיכה, והתגמול נכנס לארנק מיד לאחר הפעילות. כעבור חודשיים בעלי הטוקן החלו לעזוב — את התגמולים משכו אותן כתובות עם פעילות בוטים, ואלה שהביאו תרומה אמיתית לא ראו הבדל בין העבודה שלהם לבין ניפוח מלאכותי.
מה שינינו בכללים
פירקנו את הכלכלה לשכבות וכתבנו מחדש את לוגיקת הזיכויים בחוזה. התגמול החל להגיע עבור פעולות מדידות — משימות סגורות, סקירות, חומרים למתחילים — ולא עבור נפח התכתובת.
את ההצבעות העברנו לשכבה נפרדת דרך Snapshot, כדי שהחלטות יתקבלו על ידי בעלי טוקן עם היסטוריית השתתפות, ולא על ידי כתובות שקנו טוקן אתמול.
את שחרור התגמולים קשרנו לזמן: הזיכוי נחשף באופן ליניארי במשך כמה שבועות, וביציאה מוקדמת חלק ממנו מחויב למאגר המשותף. איפוס מיידי של טוקנים לאחר כל חלוקה נעלם, והשתתפות ארוכת טווח הפכה שוב למשתלמת יותר מחד-פעמית.
מדדים לפני ואחרי
| מדד | לפני | אחרי |
|---|---|---|
| בעלי טוקן עם פעילות בחודש | 11% | 34% |
| זמן חציון של החזקת הטוקן | 6 ימים | 71 יום |
| שיעור התגמולים עבור פעילות מנופחת | כ-40% | מתחת ל-5% |
| חזרת משתתפים לאחר החודש הראשון | ירידה | גידול פי 3 |
המדדים נשמרו ברמה החדשה עוד שתי תקופות לאחר העיבוד מחדש — הכללים לא דרשו עריכה ידנית של ההנפקה.
מה לעשות אם ההנפקה כבר בוצעה, ובעלי הטוקן אינם פעילים?
אם ההנפקה כבר בוצעה והיתרות שוכבות בלי תנועה, יש בדרך כלל שלוש סיבות: הטוקן אינו פותר אף משימה של בעליו, התגמול אינו פרופורציונלי למאמץ, או שהדרך עד להוצאה ארוכה מדי. הניתוח מתחיל ביומן הפעולות: שיעור הכתובות הפעילות, התפלגות היתרות, המרה מקבלה לשימוש. המספרים האלה מראים איזה מסלול יציאה יניב אפקט, ואיזה רק ישרוף זמן.
המסלולים אינם סותרים זה את זה, אך הסדר חשוב: תחילה כוונון כללי הזיכוי, אחר כך הרחבת התרחישים, ורק לבסוף צמצום היתרה שלא נוצלה.
כוונון הוא עריכה של ספים, משקולות ותקופות זיכוי: אם התגמול ניתן עבור פעולה שרק בודדים מגיעים אליה, משנים את התנאי, ולא את הקהל. יש תנאי טכני אחד — בחוזה שהונפק חייבת להיות חלק ניהולי עם רזרבת הרשאות; בחוזה שאינו ניתן לשינוי המסלול הזה סגור, ואין דרך לעקוף זאת.
תרחישי שימוש חדשים עובדים גם בחוזה שאינו ניתן לשינוי: הטוקן מחובר לגישה, להצבעות, לחישובים פנימיים. התרחיש חייב להיות קבוע, אחרת חוזרת אותה דממה.
צמצום התגמולים הוא הצעד האחרון: תקופה מוצהרת, החלפה מקבילה של היתרה שלא נוצלה ושמירת היסטוריית הפעולות, כדי שבעלי הטוקן לא יאבדו את מה שנצבר.
הסדר שלנו: אבחון לפי היומן, כוונון הכללים, תרחישים חדשים, ורק אחר כך צמצום הדרגתי. תארו היכן עצרתם — נחזור עם הערכה ותוכנית.
ספקות טכניים: תגמולים, מגבלות, אינטגרציות
תגמולים הם הדבר הראשון שנשבר עם גידול הקהילה: חוות סקריפטים, חשבונות מרובים ופעילויות מתואמות מפחיתים את ערך הטוקן מהר יותר מקצב גידול הקהל. לכן כללי הזיכוי, המגבלות וההגנה מפני ניפוח מלאכותי מתוכננים לפני ההנפקה הראשונה, ולא נכתבים בדיעבד לאחר תקלה.
כיצד אנו מסננים ניפוח מלאכותי וחשבונות מרובים?
ניקוד התנהגות: גיל הפרופיל, היסטוריית פעילות, קישוריות בין פעולות של משתתפים שונים. בנוסף השהיה לפני הזיכוי, מגבלות יומיות וחודשיות למשתתף והקפאה אוטומטית של התפרצויות אנומליות עם בדיקה ידנית. את הספים מוציאים לפרמטרים ניהוליים — ניתן לשנות אותם רק באישור בעל הקהילה.
מה יראו משתתפים אחרים על התגמולים?
בפיד הציבורי — עובדת הפעילות או נתון מצרפי, אבל לא סכומים של אדם מסוים. נתונים אישיים איננו כותבים לשרשרת: שם נמצא מזהה, והפרופיל נשאר במסד הנתונים שלכם. הצגת היתרה האישית היא הגדרה נפרדת של המשתתף, ובברירת מחדל היא סגורה.
כיצד זה משתלב עם השירותים שלנו ועם פלטפורמות חיצוניות?
בוט ב-Discord או בצ'אט הקהילה, אירועים מהפורום, כניסה דרך ההזדהות הקיימת שלכם, ייצוא מרשם הזיכויים למערכת הנהלת חשבונות או לטבלה, משיכת הטוקן לפלטפורמה חיצונית. במקום שלשירות אין ממשק ציבורי, החלפה מתבצעת דרך תור אירועים עם ניסיונות חוזרים, כדי שקריאה שהוחמצה לא תאבד את התגמול.
מגבלות הזיכוי אינן קבוע בקוד, אלא מדיניות ניתנת להגדרה: הן משתנות לפי החלטת הקהילה, והיסטוריית השינויים נשמרת. להלן השאלות הנשאלות לרוב לפני ההתחלה.נדון במשימה ונחזור עם הערכה ותוכנית
כדי לחזור עם הערכה ותוכנית, ולא עם מילים כלליות, אנחנו צריכים לאסוף נתוני פתיחה על תוכנית הנאמנות שלכם. כל סעיף להלן הוא מה שקובע את הארכיטקטורה: ממודל הזיכוי ועד להיכן נשמרת היסטוריית העסקאות וכיצד נכנסים אירועים חיצוניים למערכת.
- תיאור הקהילה: היכן חיים המשתתפים (מסנג'רים, פורום, פלטפורמה), כמה פעילים, כיצד הם מתקבצים לקבוצות, האם יש כבר חשבונות משתמש ובמה הם מאומתים.
- הרכב התפקידים: מי מזכה תגמולים, מי מאשר פעולות, מי מכריע במקרים שנויים במחלוקת ולמי יש זכות להקפיא את ההנפקה.
- כללי הזיכוי הנוכחיים: עבור אילו פעולות נזקפות נקודות, כיצד הן מחויבות, האם לתגמול יש תוקף וכיצד נפתרים זיכויים כפולים.
- תרחישי שימוש בתגמולים: מה המשתתף מקבל בסוף — גישה בתשלום, סטטוס, זכות הצבעה, המרה בין משתתפים או משיכה לשירותים חיצוניים.
- מגבלות: דרישות לזיהוי, קטגוריות משתתפים שאסור להם לקבל טוקנים, ומה שכבר אמרו הרגולציה או עורכי הדין בעניין.
- נתונים וקשרים: ייצוא של פעילות, הממשקים הזמינים של הפלטפורמות, היכן נשמרת כעת היסטוריית הפעולות ובאיזה פורמט אפשר להעביר אותה.
- מי מקבל החלטות בצד שלכם ובאיזה קצב אפשר לאשר גרסאות ביניים.
לאחר הניתוח אנחנו מרכיבים סכימת תפקידים והרשאות, מודל זיכוי עם כללי הגנה מפני ניפוח מלאכותי ותוכנית שלבית: עם שלבים, לוחות זמנים, נקודות קבלה והרכב הצוות. תארו את המשימה — נחזור עם הערכה ותוכנית.







