פיתוח פלטפורמת ICO: חוזים חכמים, KYC, ריבוי רשתות, הבשלה

פלטפורמת ICO קורסת תחת עומס: היכן נשבר גיוס הכספים

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

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

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

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

מה נותנת פלטפורמת ICO מנוהלת למשקיע ולמנפיק

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

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

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

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

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

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

דרכים לקיים סבבים: השוואה בין גישות

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

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

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

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

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

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

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

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

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

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

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

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

לפני: בדיקה ידנית ובירור פערים

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

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

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

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

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

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

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

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

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

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

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

תשובות לספקות טכניות בנוגע לחוזים ולהרשאות

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

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

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

איך בנויים vesting ושחרור?

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

נדבר על המשימה: מעגלים, תפקידים וסדר עבודה

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

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

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

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