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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

סדר העבודה: מפירוק המשימה ועד מסירת החוזה

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

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

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

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

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

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

מקרה בוחן: חוסר סנכרון בשחרור ודילול חלק המייסד

מה היה לפני

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

מה שינו

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

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

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

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

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

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

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

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

ספקות טכניים: ביקורת, עדכונים, הרשאות גישה

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

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

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

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

נדון במשימה: היקף העבודה ומה נדרש מצדכם

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

מה נדרש מצדכם:

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

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