פיתוח חוזה launchpad: מכירות טוקנים, רשימת היתר, שחרור הדרגתי

פיתוח חוזה launchpad: היכן נשברת מכירת הטוקנים

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

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

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

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

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

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

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

לוגיקת המכירה: רשימת היתר, הקצאות ולוח שחרור

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

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

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

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

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

פורמטי השקה: חוזה עצמאי, מפעל, מודול פלטפורמה

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

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

השוואת פורמטי השקה

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

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

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

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

ערכת מסירה: חוזים, תרשימים, מדיניות ונהלים

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

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

מקרה בוחן: מכירה עם רשימת היתר ולוח שחרור

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

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

מה השתנה במדדים

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

מה לעשות אם המכירה כבר מתנהלת ותנאי השחרור משתנים

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

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

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

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

שאלות טכניות בנוגע להשקת מכירה ותפקידי גישה

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

איך החוזה בודק את הזכות של כתובת לרכוש?

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

למי עוברות זכויות הניהול לאחר ההשקה?

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

מה נבדק לפני פרסום החוזה?

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

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

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

מה צריך לשלוח כדי שנחזור עם חישוב:

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

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