מכירת טוקנים: הגרלות, מערכות דירוג וחלוקת הקצאות מבוססת ניקוד

טוקנסייל והקצאה: איפה נשברת חלוקת המקומות

הקצאת טוקנסייל היא בראש ובראשונה משימת רישום נכון, ולא חלוקת מקומות. כל עוד הסיבובים והמשתתפים מעטים, חלוקת ההקצאות נשענת על רשימות משתתפים ידניות וטבלה שמנהל אדם אחד.

ברגע שהתנאים הופכים מורכבים — רמות השתתפות, משקל הארנק, היסטוריית פעילות — הסכימה מפסיקה להסתדר: שתי רשימות מתפצלות, חלק מהכתובות נכנסות לסיבוב פעמיים, וחלק כלל לא נכנסות.

רשימות ידניות יוצרות סוג נפרד של תקלות — חריגים שנויים במחלוקת. משתתף שעומד לכאורה בתנאים לא עובר את הסינון בגלל שגיאת הקלדה בכתובת או עיכוב באישור, והטיפול במקרה כזה נעשה ידנית ובפומבי. כל תיקון בדיעבד מבטל את ערכם של הכללים שהוכרזו מראש.

תקלות ברישום לסיבוב מתחילות במקום שבו לרגע אחד מתרכז פרץ בקשות. צומת הרישום עובר לעומס יתר: התור גדל, אישורים מגיעים באיחור, חלק מהעסקאות נשלחות שוב, ובלי מפתח אידמפוטנטי השליחה החוזרת הופכת לזיכוי כפול. השיא נמשך דקות ספורות, אבל ההשלכות נבחנות שבועות.

לאחר מכן נכנס האפקט התדמיתי: הקהילה רואה לא את המכניקה, אלא «מישהו הוחמץ, ומישהו הועבר פעמיים». לשקם אמון קשה יותר מאשר לבנות מחדש את החלוקה מאפס — ובדרך כלל יקר יותר מהפיתוח עצמו. בהמשך נפרט איך זה נסגר: מפורמליזציה של כללי המיון ועד לעמידות צומת הרישום בעומס שיא.

מה נותנת חלוקת מקומות שקופה בהתחלה

חלוקת מקומות בהתחלה היא לא רשימת זוכים, אלא סט בדיקות שמבוצעות לפני פתיחת הסיבוב. מיון מבוקר של משתתפים נדרש כדי שההתחלה לא תהפוך למירוץ בוטים, ושניתן יהיה לבדוק מחדש את התוצאה לפי יומן מפורסם.

• חלק המשתתפים האמיתיים. סינון לפי היסטוריית הכתובת, היקף הפעילות וגיל הארנק חוסם חשבונות מרובים ומעטפות ריקות — להקצאה נכנסות כתובות עם פעילות אמיתית, ולא שכפולים אחידים.
• כללי סיבוב שקופים. משקולות הרמות, סף הכניסה והמגבלה לכתובת קבועים בנוסחה לפני ההתחלה ואינם משתנים במהלכה; מקרים שנויים במחלוקת נבחנים לפי אלגוריתם מפורסם, ולא בהתכתבות.
• הגרלה ניתנת לאימות. הגרלת מאגר הלוטו נשענת על אישור חיצוני של אקראיות דרך Chainlink, ולכן התוצאה אינה תלויה בשרת שלנו ומאומתת על ידי צד שלישי.
• עמידות בביקוש שיא. הבקשות עוברות דרך תור עם רישום באצוות, ושליחה חוזרת מאותה כתובת מעדכנת את אותה רשומה: לא נוצרים כפילויות של מקומות או חיובים כפולים, והמונה לא הופך לצוואר בקבוק.
• צפיות בעומס. מחשבים מראש את זרם הבקשות בשיא ושומרים על רזרבה בתפוקה — הסיבוב לא נופל ברגע הביקוש המקסימלי.

כל סעיף אנחנו מריצים בסיבוב בדיקה לפני ההתחלה: מזינים תרחיש עם עומס, בודקים את היומן, ורק אחר כך פותחים את הסיבוב האמיתי. הכללים נשארים זהים לכל המשתתפים.

פורמטים של הקצאה: לוטו, מערכת Tier, מבוסס Score

בחירת הסכימה נקבעת לפי שתי שאלות: מי מקבל זכות להקצאה וכמה בדיוק. סכימת מיון לוטרית, מערכת Tier וחלוקה מבוססת Score — שלוש תשובות בסיסיות, וכל אחת מציבה מגבלות משלה על כלכלת הפרויקט ועל העומס על התמיכה. בצורתן הטהורה בוחרים בהן לעיתים רחוקות, ולכן נוח להחזיק את ההשוואה בטבלה אחת.

בפועל סכימות מרכיבות יחד: Tier קובעת זכות השתתפות, Score מגדיר משקל בתוך הרמה, והלוטו משלים את היתרה ברמה התחתונה. אז החישוב מתבצע לפי תמונת מצב קבועה, והמשקולות והספים מפורסמים לפני פתיחת הסיבוב — המשתתף רואה למה קיבל בדיוק את ההיקף הזה.

הטמעת חלוקה לפי שלבי עבודה

חלוקת הקצאות היא לא הגדרה חד-פעמית, אלא תהליך ניתן לשחזור: כללים, משקולות ותמונות מצב צריכים לתת תוצאה זהה בהרצה חוזרת. טעות במשקולות או בבלוק שנבחר לתמונת המצב עולה ביוקר במיוחד דווקא בשלב הטוקנסייל — אחרי החישוב כבר אי אפשר לבטל אותה בשקט, המשתתפים יראו את הפער. לכן העבודות מתבצעות בסדר קפדני: מאיסוף הדרישות וסכימת המיון ועד להרצת בדיקה ומסירה.

1. איסוף דרישות ומודל מיון. קובעים את מספר הסיבובים, מי מורשה להשתתף בהם, איזו תרומת משתתף נלקחת בחשבון ואילו פעולות פוסלות מהחלוקה — זה הופך לקריטריון קבלה.
2. סכימת משקולות ניקוד. לכל פעולה מקצים משקל וסף לרמה במערכת Tier; את המשקולות מרכזים בטבלה, כך שכל שינוי בכלל נקרא שורה-שורה, ולא טובע בקוד.
3. הכנת תמונות מצב. בוחרים בלוק שבו נלקחים הנתונים, אוספים כתובות, מסירים כפילויות, מוציאים כתובות שירות וכתובות חוזה, ומושכים היסטוריית פעילות לכל ארנק.
4. הגדרת כללי חלוקה. פרמטרים של סיבובים, מגבלות למשתתף, סדר זיכוי הקצאות והתנהגות במקרה של אי-מילוי מוציאים לקונפיגורציה — כך הכלל משתנה בלי לגעת בקוד החישוב.
5. הרצת בדיקה של הסיבוב. מחשבים על עותק של הנתונים, בודקים סכומים לפי רמות ולפי ארנקים בודדים, ובודקים בנפרד מקרי קצה: תרומה אפס, מעבר רמה על גבול הסף, כתובות כפולות.
6. הפעלה ומסירה. מריצים את הסיבוב, מוסרים רשימות הקצאות, דוח על מקרים שנויים במחלוקת ותיעוד כללים עם נוהל חישוב חוזר — התוצאה משוחזרת על ידי הצוות שלכם.

ארטיפקטים שנשארים אצל צוות הלקוח

החבילה נמסרת לא כמצגת על הסכימה, אלא כמערכת מסמכים עבודה: לפיהם מהנדס של הלקוח או קבלן חדש יריץ את הסיבוב הבא בעצמו, בלי לשחזר את לוגיקת המיון מתוך התכתבות ולוגים.

• תיאור סכימת המיון: רמות, משקולות הקריטריונים, סדר חישוב ההקצאה והגבולות שמעבר להם הכלל משתנה.
• כללי חישוב ניקוד: נוסחה, מקורות נתונים, עיגול, ספי חיתוך והתנהגות המערכת לכתובות עם היסטוריה חלקית.
• מטריצת הרשאות: תפקידי מפעיל, אנליסט ומבקר, אילו פעולות דורשות חתימת סף ואיך ההרשאות נשללות.
• הוראות מפעיל הסיבוב: תרחישים שלב-אחר-שלב — הכנת הרשימה, פתיחת החלון, השהיה, חישוב חוזר, סגירה וייצוא תוצאות.
• נוהל למקרים שנויים במחלוקת: זמני תגובה, מי מקבל החלטה, תבניות תשובה למשתתף, פרוטוקול תיעוד כל החלטה.
• מילון מדדים וסכמת נתונים: איך קשורים כתובת, ארנק ורשומת משתתף, היכן נשמרת היסטוריית חישובים חוזרים.
• דוח מסכם לסיבוב: כמה כתובות עברו מיון, התפלגות לפי רמות, היקף פניות לתמיכה ובמה הן נסגרו.

המסמכים מתארים מערכת שכבר עובדת, ולכן אינם סוטים מהמימוש: כל כלל חישוב וכל תרחיש מפעיל נבדקו בסיבוב אמיתי. אנחנו מעבירים את החבילה למאגר התיעוד שלכם ומקיימים סשן מסירה, שבו נבחנים נקודות שנויות במחלוקת וסדר ביצוע שינויים.

מקרה בוחן: מעבר מלוטו למערכת ניקוד

אלינו הגיעה פלטפורמת השקה הליוס עם מיון לוטרי: הקצאה קיבלו בקשות אקראיות מבין כל מי שהספיק להגיש אותן. לכאורה הוגן, בפועל החלוקה הלכה למי שהחזיק עשרות ארנקים, ולא למי שהשתתף בסיבובים קודמים.

בדקות הראשונות של הסיבוב החוזה קיבל מפולת בקשות, והתמיכה — זרם הודעות אחידות «אישרתי השתתפות, אין הקצאה».

העברנו את המיון למערכת ניקוד. הניקוד מחושב לפי היסטוריית ארנק מאומתת: תקופת החזקה, השתתפות בסיבובים קודמים, פעילות ברשת הפרויקט, אימות שהושלם. מסכום הניקוד מורכבות מדרגות עם משקל הקצאה קבוע, והבקשה מתקבלת לאורך כל חלון הסיבוב — אין יותר מרוץ לשניות.

מדדים לפני ואחרי

חלק המשתתפים המאומתים שהגיעו לקבלת הקצאה עלה מ-42% ל-81%: המיון עובד כעת עם ארנקים מאומתים, ולא חוסם אנשים בשלב האחרון. פניות לתמיכה ביממה הראשונה של הסיבוב פחתו בערך פי חמישה — את השאלה «למה לא בחרו בי» מסיר חישוב ניקוד שקוף, שהמשתתף רואה בחשבונו.

עומס השיא על החוזה ירד בסדר גודל: הבקשות מפוזרות על פני החלון, ולא מגיעות בדקה אחת. את עיקר הבקשות שנפסלו הרכיבו ארנקים מרובים, ובמקביל התור החי נשאר מלא — הסיבוב נסגר עם ביקוש עודף. נוסחת הניקוד וספי המדרגות משתנים בהגדרה — הסיבוב הבא מוכן לקהל חדש בתוך שעות.

מה לבחור: מערכת Tier או הקצאה מבוססת Score?

שתי הסכימות מחלקות היקף הקצאה מוגבל, אבל לוגיקת המיון בהן שונה. מערכת Tier קושרת את הזכות לחלק לסף: התנאי מתקיים — נפתחת רמה עם משקל קבוע. מבוסס Score מחשב ניקוד לפי מכלול פעולות ומחלק את ההיקף ביחס לסכום שנצבר.

בתנאים שווים הסכימות נבדלות ביותר. במערכת Tier סף זהה נותן משקל זהה, ולכן כשנרשמים יותר מדי יש להכניס כלל נוסף — מי תפס מקום קודם, או לוטו בתוך הרמה. מבוסס Score פותר את אותו מצב בחשבון: ניקוד שווה נותן חלקים שווים, ולא נוצרים מקומות שנויים במחלוקת.

גם הדרישות לנתוני המשתתף שונות. למערכת Tier מספיק סימן אחד בר-בדיקה שנקרא ממצב הרשת ברגע החיתוך: יתרה, סטייק, קיום תפקיד. לסכימת הניקוד נדרש מעקב פעולות מלא, עמיד בפני ניפוח מלאכותי, — זיכויים עבור היקף ותקופת החזקה, קנסות על משיכה לפני החיתוך.

לכן את הסף המשתתף בודק בעצמו, ואת הנוסחה — רק דרך תצוגה מקדימה של החישוב לפני ההתחלה. הגרסה העובדת היא בדרך כלל היברידית: סף קשיח חותך רעש אקראי, הניקוד מדרג את העוברים, ואת תמונת המצב מפרסמים כדי שניתן יהיה לחשב מחדש את החלק על Ethereum.

ספקות טכניים לפני פתיחת סיבוב

כללי המיון נבדקים על נתונים, לא על הבטחות. ארבע שאלות שאנחנו מבררים לפני פתיחת הסיבוב: איך נחסמים חשבונות מרובים, מה קורה כשמשתתף מחליף כתובת, איך מחושב מחדש החשבון בעת תיקון כללים ומה יקרה בתקלה חלקית. את התשובות מתעדים בקונפיגורציה של הסיבוב — כדי שניתן יהיה לשחזר את ההחלטה, ולא להיזכר בה.

המשתתף החליף כתובת — האם הניקוד עובר?

כן, לפי חתימה מהכתובת הישנה. ההעברה מתבצעת לפי רמת המשתתף, ולא לפי הארנק: מגבלת הסיבוב נקשרת אליו, אחרת אדם אחד יאסוף כמה מכסות. העברות סוגרים לפני פתיחת הסיבוב, ואחר כך — רק טיפול ידני.

שינו את הכללים — האם החשבון מחושב מחדש בצורה הוגנת?

כן. החשבון תמיד נבנה מחדש מתוך תמונת מצב של אירועים בלתי משתנה, ולא בצורה מצטברת. חישוב חוזר נותן את אותה תוצאה על אותם נתונים, ולכן אנחנו משווים את שתי הגרסאות ומראים את ההבדל בכל רמה — המשתתף רואה למה הניקוד השתנה.

מה עושים בתקלה חלקית בסיבוב?

תקלה לא צריכה להוביל לזיכוי כפול. פעולות החלוקה מתועדות ביומן וחוזרות על פיו, מגבלות למשתתף ולסיבוב מחושבות מתוך מה שכבר הונפק. עוצרים את הסיבוב, בודקים את המצב, וממשיכים מנקודת העצירה.

איך נבדקים כללי המיון עצמם?

ביקורת כללים מתבצעת לפני ההפעלה: הרצת בדיקה על עותק של נתונים אמיתיים, חישוב חוזר במימוש בלתי תלוי, בדיקת מקרי קצה — מדגם ריק, משתתף אחד ברמה העליונה, חריגה ממכסה. התוצאה — דוח עם פערים ותיקונים בקונפיגורציה.

נדון במשימת החלוקה ובפורמט העבודה

כדי לחזור עם הערכת פרויקט חלוקה, ולא עם דיונים כלליים, אנחנו צריכים סט נתוני קלט. ככל שהתמונה ההתחלתית קונקרטית יותר, כך תוכנית העבודה למיון ולחלוקה מדויקת יותר, ופחות תיקונים ברגע שהסיבוב כבר פתוח.

• היקפים צפויים של הסיבוב: כמה משתתפים אתם מצפים, היקף היעד, מספר הרמות במערכת Tier והחלקים ביניהן.
• הסכימה הנוכחית: איך ההקצאה מחושבת כעת — ידנית בטבלאות, בסקריפט או בחוזה, והיכן מתנהל רישום המשתתפים.
• מגבלות נתונים: מאיפה אתם לוקחים תמונת מצב של יתרות ופעילות, האם יש גישה תוכנית למקור ובאיזו תדירות ניתן לצלם אותו.
• כללי מיון: קריטריוני חישוב, משקולות, ספי מינימום ודרישות להגנה מפני ניפוח מלאכותי בריבוי ארנקים.
• לוחות זמנים של הסיבוב: מתי הפתיחה והסגירה, עד מתי נדרש חישוב הקצאות מוכן, האם יש תלות באירוע חיצוני.
• דרישות שקיפות: האם המשתתף צריך לבדוק בעצמו את ההקצאה שלו, האם נדרש נוהל ערעור ואילו דוחות מצפים לקבל בסיום.

לפי הנתונים האלה נבנה תוכנית עבודה למיון: כללי חישוב, מודל רמות, מכניקת זיכוי, נוהל ערעורים ולוח בדיקות. נחזור עם הערכת מאמץ ולוחות זמנים להטמעה, ואת פורמט שיתוף הפעולה נקבע בשלבים — תחילה מריצים חישוב על נתונים היסטוריים ומראים תוצאה, ורק אחר כך מפעילים בסיבוב חי.