פיתוח מערכת קליים אוטומטית ל-airdrop

קליימם ידני של טוקנים: צווארי בקבוק ופיתוח airdrop

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

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

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

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

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

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

מה משתנה לאחר הטמעת קליימם אוטומטי

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

שיעור הקלייממים המוצלחים נקבע לא רק על ידי לוגיקת החוזה, אלא גם על ידי טיפול בכשלים. המהנדסים מנתחים את סיבות ה-revert — חוסר בגז אצל המשתמש, מגבלות, קריאה חוזרת — ומגדירים ניסיונות חוזרים עם פרמטרים נכונים בתוספת ניטור לכל כתובת. הצלחת הקליימם עולה ל-95–98%, והמקרים הנותרים נראים בלוג, ולא מתבררים מתוך הודעות המשתתפים.

העומס על התמיכה יורד יחד עם זה: סטטוס הקליימם זמין למשתמש לפי כתובת הארנק, תקלות נכנסות לתור לבדיקה, ושאלות טיפוסיות כמו «איפה הטוקנים שלי» נסגרות ללא מפעיל. היקף הפניות יורד ב-60–70% כבר בשבוע הראשון של החלוקה.

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

פיתוח airdrop: פורמטים של קליימם אוטומטי

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

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

שלבי הטמעת מערכת הקליימם: מביקורת ועד מסירה

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

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

מה נשאר אצלכם: קונפיגורציות, סכמות, נהלים

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

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

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

מקרה בוחן: חלוקה ל-40 אלף כתובות ללא הנפקה ידנית

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

לפני: צוואר בקבוק בצד המפעילים

באופן ידני עברו כ-1,200 קלייממים ביממה — עם 40 אלף כתובות מדובר בשבועות של עבודה רצופה. כל מפעיל החזיק טבלה פתוחה והשווה את הכתובת בעיניים; טעות בספרה אחת שלחה את הטוקנים לנמען הלא נכון, והנפקה חוזרת חייבה טיפול נפרד. התמיכה קיבלה 700–800 פניות בשבוע, וכמעט כולן הצטמצמו לדבר אחד: «שלחתי בקשה, הטוקנים לא הגיעו».

אחרי: קליימם אוטומטי לפי חתימה

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

ללא התערבות ידנית עברו 97% מהקלייממים המוצלחים, העומס בשיא הגיע ל-9,000 ביממה, והזמן מהחתימה ועד הזיכוי — שניות.

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

במה שונה קליימם לפי רשימה מחלוקה בזרימה

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

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

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

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

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

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

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

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

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

כיצד המערכת מסננת חשבונות מרובים?

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

מה לעשות אם תנאי החלוקה משתנים לאחר ההשקה?

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

כיצד בודקים את נכונות הזיכויים?

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

נדון במשימה ונחזור עם הערכה ותוכנית עבודה

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

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

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