למה מוצר SocialFi נשבר כשהקהל גדל
טוקנים חברתיים לגישה נבנים על עקומת מחיר: ככל שיש יותר מחזיקים בחשבון, כך המפתח הבא יקר יותר, ומכירה מזיזה את הערך בחזרה. כל עוד פעילים מאות אנשים, המכניקה נחשבת לצפויה — החוזה מחשב מחדש את מחיר המפתח באופן עקבי, מעדכן יתרות ומזכה את המחזיקים בתשלומים.
גידול הקהל הופך את הסדר הזה לתור של פעולות נדחות. משתמשים לוחצים לקנות באותה שנייה, פעולות מתחרות על אותו מצב ומגיעות לבלוק בסדר אקראי, ולכן המחיר שהאדם ראה בממשק כבר שונה עד למועד הביצוע.
חלק מהעסקאות מתבטלות, חלק עוברות לניסיונות חוזרים, והעומס גדל לא באופן ליניארי: כל דחייה יוצרת גל חדש של בקשות.
צוואר הבקבוק השני של החוזה — אי-התאמה בין יתרות. חלון הראווה, המטמון ושירות ההתראות מקבלים מצב באיחור, ולכן הממשק מציג מחיר כניסה אחד, והחישוב נשען על אחר. מחזיק רואה סכום שכבר אינו נמצא במרשם, וטיפול בפניות הופך להשוואה ידנית של יומנים.
זו אינה פגם במכניקה, אלא תוצאה מכך שהיא לא הוכנה לזרימה המונית. סדרי עדיפויות של פעולות, הגבלת ניסיונות חוזרים וסנכרון מצבים נקבעים בפיתוח SocialFi לפני אלפי המשתתפים הראשונים, ולא אחריהם. נפרט איך סוגרים את זה — מתרשים החישובים ועד ערבויות להחזר במקרה של פעולות שנדחו.
אפקט מדיד ממכניקת הגישה של SocialFi
מכניקת גישה בתשלום ב-friend.tech בנויה כמו מכשיר בורסאי: מפתח לערוץ של יוצר נקנה לפי עקומה, המחיר מחושב מחדש בכל עסקה, והעמלה מתחלקת בין הפרוטוקול ליוצר.
לכן שיעור הפעולות המוצלחות הופך למדד המרכזי: ברגע שחישוב המחיר בצד הממשק אינו תואם את מצב החוזה, העסקה נופלת בבדיקת הסטייה המותרת — והקונה נשאר בלי גישה.
אנחנו מוציאים את החישוב לסימולציה מקדימה: הסטייה נבדקת לפני החתימה, ושיעור הדחיות מסוג זה יורד מאחוזים בודדים לעשיריות האחוז, וההחזרים מפסיקים להיות סעיף קבוע.
מה רואים במדדים
חלוקת העמלות מפסיקה להיות מקור למחלוקות כשהפיצול וסדר התשלומים קבועים בחוזה, ולא מחושבים בשרת. היוצר רואה את חלקו מכל רכישה חוזרת של גישה, החלק השיווקי נחתך לפי אירוע העסקה ולא לפי לוח זמנים — המשיכה זמינה מיד, בלי צבירת תקופת המתנה.
זה משנה את שימור היוצרים: ההגעה לאיזון עצמי מתקצרת, כי הזרימה המשמעותית הראשונה מגיעה בימים הראשונים של הפרסומים, ולא אחרי חישוב מחדש ידני.
רכישות חוזרות של גישה נתקלות בדבר אחר: מחיר המפתח בביקוש פעיל עולה מהר יותר מעליית הערך של הערוץ. אנחנו מוסיפים לכלכלת הטוקן פרמטר מרסן — צעד העלייה ותקרה למספר המפתחות בכל רמה — ושיעור הקהל שחוזר לגישה שנייה ושלישית גדל, כי הכניסה נשארת הגיונית.
סוג הדחיות שנעלמו נראה ביומן: במקום לנתח "למה לא נקנה", התמיכה מקבלת רק מקרים נדירים של חוסר אמצעים.
אפשרויות מימוש של מכניקת SocialFi
מכניקת גישה בתשלום ליוצר, כפי שהוגדרה ב-friend.tech, נשענת על שלושה צמתים: עקומת מחיר המפתח, חלוקת התשלומים בין היוצר למחזיקים, וכללי היציאה. לכן בחירת הגישה היא תשובה לשאלה של מי העקומה וממי יכול לשנות אותה אחרי ההשקה.
| גישה | מתי מתאימה | מגבלות |
|---|---|---|
| פלטפורמה מוכנה | נדרשת השקה בלוח זמנים צמוד, והמכניקה סטנדרטית | עמלת פלטפורמה מכל עסקה; את העקומה ועדכון הקוד קובע בעל הפלטפורמה; במעבר החוצה רשימת המחזיקים והקשרים ביניהם אינם מועברים |
| העתקה של מכניקה פתוחה | הלוגיקה קרובה למודל הייחוס, אך הממשק נדרש משלכם | עוברות בירושה שגיאות ופגיעויות זרות; כלכלת המפתחות נשארת לפי מודל הייחוס, ושינוי שלה מחייב לכתוב מחדש את חישובי התשלומים |
| חוזים חכמים משלכם | נדרשים כללים משלכם לתשלומים, עמלות ויציאה | זמן ארוך יותר: ביקורת, סביבת בדיקות, הגירת מצב; לעומת זאת העקומה, החלקים והמגבלות קבועים בחוזה ואינם תלויים בפלטפורמה זרה |
בהמשך — על המגבלות של הגישה הנבחרת. לפני ההתחלה אנחנו מקבעים שלושה דברים: מי מחזיק בהרשאות המנהל ויכול להעלות עמלה או להשהות את החוזה; האם אפשר לייצא מחזיקים עם יתרות במעבר לפתרון אחר; איך מתבצע החזר כספים אם המכניקה נעצרת. התשובות לסעיפים האלה קובעות אם נדרשת פיתוח משלכם או שפלטפורמה מוכנה מספיקה.
שלבי פיתוח והטמעה של המוצר
מכניקת SocialFi נשברת לא ברעיון, אלא בסדר העבודה. עקומת מחיר מפתח הגישה וזרימת העסקאות הנכנסות קשורות באופן הדוק: טעות בנוסחת ההנפקה או בהרשאות להנפקה הופכת לארביטראז' נגד המשתמשים תוך דקות, לא שבועות. לכן אנחנו מובילים את הפרויקט בשלבים קבועים — מביקורת הרעיון ועד תורנות בשעות הראשונות אחרי ההשקה.
- ביקורת הרעיון. מפרידים בין מה שחייב לחיות בבלוקצ'יין (הנפקת מפתחות, עסקאות משניות, רישום חלקי יוצרים) לבין מה שעובר לחלק השירותי: פיד פעילות, המלצות, בדיקות אנטי-הונאה. מקבעים גבולות עוד לפני שורת קוד.
- תרשים הכלכלה. מחשבים את עקומת המחיר, ההנפקה, עמלות הפלטפורמה והיוצר, וההתנהגות במכירות המוניות. מריצים סימולציות כדי לראות איך פועלת הנזילות בעת יציאה בו-זמנית.
- תכנון חוזים ותרשים גישה. תפקידי הבעלים, המפעיל והאוצר מפוצלים לכתובות נפרדות, ופעולות קריטיות נסגרות בחתימה מרובה. מתארים מראש אילו פונקציות מאפשרות השהיה ואילו לא.
- ביקורת חוזים. ניתוח סטטי, פאזינג של נוסחאות, בחינה ידנית של וקטורים: מניפולציה על מחיר המפתח, כניסה חוזרת בעת משיכה, עקיפת מגבלות הנפקה. דוח עם רמות סיכון ותיקונים — לפני פריסה.
- בדיקה ברשת בדיקות. הרצה מלאה של תרחישי משתמש: קנייה ומכירה של מפתח, משיכות המוניות, הפקדה לאוצר, הגירת מצב. בודקים צריכת משאבים בפעולות שיא והתנהגות החוזה כששירות חיצוני נכשל.
- העברת הרשאות. מעבירים בעלות לכתובות הלקוח, מבטלים מפתחות טכניים של המפתח, מוסרים תרשים גישה, תיאור פרמטרים ונוהל פעולה באירוע חריג.
- ליווי ההשקה. תורנים בשעות הראשונות, עוקבים אחר אנומליות בזרימת העסקאות, ומחזיקים מוכנים תוכנית הקפאה וחזרה לאחור.
מה מוסרים יחד עם החוזים והממשק
אנחנו מוסרים לא ארכיון עם קוד, אלא ערכה שבאמצעותה הצוות שלכם יוכל להוציא עדכוני חוזים, להגיב לאירועים חריגים ולעבור בדיקות בלי ההשתתפות שלנו. כל ארטיפקט סוגר סוג משלו של שאלות: מה קבוע במכניקת ה-SocialFi, מי ואיך יכול לשנות זאת, מה לעשות בעת תקלה.
- קוד המקור של החוזים והממשק עם היסטוריית שינויים קריאה — מאגר, ולא תצלום בודד של "גרסה סופית".
- תיעוד החוזים: ייעוד כל פונקציה, אינווריאנטים, אירועים ותנאים שבהם פעולה נדחית.
- תרשימי גישה — מפת תפקידים: מי מנפיק, מי משהה, מי מוציא כספים ואיך ההרשאות מחולקות בין כתובות.
- מדיניות גישה — כללים להענקה ולשלילה של הרשאות, עבודה עם חתימה מרובה, סדר החלפת מפתחות ופעולות בעת פגיעה באבטחה.
- נהלי תפעול: עדכון חוזים, הגירת מצב, עצירת חירום וחזרה לגרסה קודמת.
- מערך בדיקות למעגל ההפצה — בדיקות וסקריפטים לפריסה שמורצים לפני פרסום.
- דוחות בדיקות עומס ובדיקות יריביות עם רשימת התרחישים שנסגרו.
ההעברה מתבצעת בשלבים: פירוק תרשימים יחד עם המהנדסים שלכם, הרצת עדכון במעגל בדיקות וקבלה לפי רשימת בדיקות מוסכמת. התוצאה — הצוות משחזר הפצה וחזרה לאחור במו ידיו עוד לפני שאנחנו מנותקים מהליווי.
מקרה בוחן: הפעלה מחדש של מכניקת גישה עם גידול בשימור
מה היה לפני ההפעלה מחדש
המוצר נבנה לפי המודל של friend.tech: גישה ליוצר נמכרה כמפתח, מחיר המפתח הבא חושב לפי עקומה ועלה עם כל קונה. הגל הראשון נתן זינוק ברישומים, אבל השימור לא החזיק — חזרה יומית עמדה על כ-34%, ושבועית ירדה ל-9%. קנו בעיקר לשם מכירה חוזרת, ולא לשם תוכן סגור: ברגע שמחזיקים גדולים יצאו, הפעילות בקהילה התאפסה.
מה שינו בחוזים החכמים
המכניקה פוצלה לשני זרמים בלתי תלויים: מנוי לחומרים של היוצר וחלק בקרן תגמולים משותפת. המנוי מתחדש, והחלק מוגבל — אי אפשר למכור אותו מחדש בשעות הראשונות אחרי הקנייה, ולכן תרחיש הספקולציה המיידית נעלם.
העקומה נכתבה מחדש: צעד עליית המחיר נעשה חלק יותר, ורוב העמלה לא הלכה ברגע העסקה אלא לקרן שחולקה לפי פעילות בפועל של המחזיק — צפיות, תגובות, מוזמנים. העדכון עבר עם הגירה: מפתחות ישנים הועברו אחד לאחד, היתרות והיסטוריית המוניטין של הארנקים נשמרו.
המדדים הושוו בתקופות ברות-השוואה. שימור יומי עלה מ-34% ל-58%, ושבועי — מ-9% ל-27%. שיעור הארנקים עם רכישה חוזרת גדל פי 2.3, ומספר המחזיקים הלא-פעילים הצטמצם בערך בחצי.
מכירות בשעה הראשונה אחרי הקנייה ירדו מ-41% ל-7% מכלל העסקאות — השימור הפסיק להיות תלוי במחיר המפתח והפך לפונקציה של התוכן של היוצר.
במה טוקן חברתי של יוצר שונה ממנוי
מנוי הוא רשומה במסד הנתונים של הפלטפורמה: זכות גישה עם תאריך סיום. טוקן חברתי של יוצר הוא יתרה בחוזה חכם: הוא אינו פג, אפשר להעביר אותו, למכור אותו או להשאיר בארנק. מכאן מתפצל כל השאר — הכלכלה, הסיכונים והעומס על החוזים.
מפתחות גישה שקונים מנויים הם מושא בעלות, לא שכירות של גישה. שוק משני מעצב מחיר: קנייה מושכת אותו במעלה עקומת המחיר, מכירה מורידה אותו, והיוצר מקבל חלק מכל מכירה חוזרת ולכן מעוניין לשמור על תשומת לב. מודל כזה הוצג בהיקף רחב ב-friend.tech, ומאז חוזרים עליו בצורות שונות.
ההבדל נראה בחוזים. מנוי בודק סשן חתום ותוקף שלו — המצב משתנה לעיתים רחוקות, והחישובים מתבצעים מחוץ לרשת. טוקן דורש בדיקת יתרה בכל פנייה לתוכן סגור, רישום העברות ותמלוגים: כל עסקה בשוק המשני היא אירוע נפרד ורשומה נפרדת.
גם הסיכונים שונים. מנוי מפסיד בגלל נטישה והחזרי תשלומים: אדם עזב — הגישה עזבה, השאלה סגורה. טוקן גולש לספקולציה: מחזיק אחד רוכש חלק גדול מהמפתחות, המחיר מתנתק מהעניין האמיתי ביוצר, ומימוש מוזיל אותו בתוך שעה — ואי אפשר לסובב את זה אחורה, הרשומה ברשת נשארת לנצח.
הבחירה אינה עניין של טעם. צריך גישה צפויה ודיווח פשוט — מנוי זול יותר בתמיכה. צריך שוק משני ויוצרים שמעוניינים בעליית המחיר של עצמם — לוקחים טוקן ומקבעים מיד הגנה מפני ריכוז מפתחות.
ספקות טכניים לפני תחילת הפיתוח
לפני ההתחלה הלקוח שואל את אותה קבוצת שאלות: למי שייכים המפתחות, מה עם שחזור גישה, אפשר לעדכן חוזה ואיך להתנהג עם תקלים אחרי ההשקה. להלן — איך זה נפתר ברמת הארכיטקטורה.
למי שייכים המפתחות הפרטיים?
החוזים נפרסים מכתובת הלקוח — צירוף השחזור והמפתחות הפרטיים אינם נמסרים לנו. לצורך אוטומציה אנחנו מכניסים תפקיד שירותי עם הרשאות מצומצמות ומגבלה על היקף הפעולות.
מה אם מפתח המנהל אבד?
תפקיד הבעלים מתואר מראש: חתימה מרובה עם סף וכתובת שחזור נפרדת. החלפת בעלים מתבצעת בהשהיה — תפיסת מפתח אינה מעניקה גישה מיידית לאוצר.
האם אפשר לעדכן חוזה אחרי ההשקה?
הקוד בלתי ניתן לשינוי, ולכן את הלוגיקה מוציאים אל מאחורי פרוקסי, ואת האוצר וההנפקה משאירים בלתי ניתנים לשינוי: עדכון לא יכול לשכתב יתרות משתמשים. שינוי כללים — דרך הגירה עם העברת מצב.
מה לעשות עם תקלים אחרי ההשקה?
ביקורת ובדיקות ברשת בדיקות סוגרות מחלקות שגיאה ידועות, אבל תקלים שיוריים נתפסים בתוכנית תגובה: השהיה בפונקציות קריטיות, מגבלות משיכה, ניטור אירועים. החלון בין גילוי לעצירת דליפה — דקות.
מי משנה את פרמטרי הכלכלה?
עמלות, תגמולים וספים מוציאים לערכים ניתנים להגדרה עם יומן שינויים: כל פעולה נרשמת כאירוע, וההרשאות מוגבלות לתפקיד נפרד.
נדון במשימה ונחזור עם אומדן ותוכנית
כדי לחזור עם אומדן לפרויקט, ולא עם מילים כלליות, די לנו בכמה נתוני פתיחה: מכניקת חלקי גישה, כלכלה ומצב הקוד הנוכחי. ככל שתיאור תרחיש הקנייה והמכירה מדויק יותר, כך נניח פחות הנחות בתוכנית הפיתוח. שלחו את מה שכבר יש — הערות, קבצים, קישור לבניית בדיקה.
- מכניקה: איך משתמש קונה ומוכר חלק גישה ומה בדיוק הוא נותן — צ'אט סגור, תוכן, זכות לתשלום.
- כלכלה: איך נוצר המחיר, איזו עמלה עוברת לפרוטוקול וליוצר, באילו דרכים מוציאים כספים.
- תרחישים שלמים: הרשמה, רכישה ראשונה, מכירה חוזרת והחזר כספים בעת כשל בעסקה.
- מצב נוכחי: אב טיפוס, חוזים פרוסים, דוחות בדיקות, מה כבר עובד ברשת הראשית.
- אינטגרציות: ארנקים, ערוצי תשלום, אנליטיקה, שירותים חיצוניים לאימות זהות.
- מגבלות: דרישות רגולטוריות מהפלטפורמה, כללי זיהוי, רשתות יעד ועלות הפעולות בהן.
- סדרי עדיפויות: מה נדרש עד ההשקה, ומה אפשר להוציא לשלב שני בלי לאבד את משמעות המכניקה.
בדיון על המשימה ננתח את מודל הנפקת החלקים ואת המקומות שבהם אפשרי מניפולציה על המחיר, נציע גבולות לחוזים החכמים ואת סדר השלבים, ונפרט בנפרד עמידות בכשלים, מגבלות והוצאת כספים. אחרי זה נחזור עם אומדן ותוכנית פיתוח حسب שלבים עם נקודות ביקורת.