כשלים בהנפקה: היכן נשבר טוקן Jetton
הנפקת טוקן Jetton נראית כמו עסקה אחת: החוזה נפרס, התגובה הצליחה, הנכס קיים. הבעיות מתחילות מאוחר יותר — היתרה לא מופיעה בארנק, העברות מחויבות אצל השולח ולא מגיעות למקבל, והצוות לא יכול להנפיק נפחים נוספים. אנו מנתחים את הסיבות ההנדסיות לכך ומהיכן הן נקבעות כבר בשלב התכנון.
המקום השכיח ביותר לכשל הוא מטא-נתוני החוזה. שם, סימול ומספר הספרות אחרי הנקודה העשרונית חייבים להיות מוצהרים לפי הסכמה המקובלת, וקובץ התיאור החיצוני חייב לשבת בכתובת יציבה ולהימסר עם סוג תוכן תקין.
אם לפחות תנאי אחד מופר, אינדקסרים ואפליקציות לקוח מדלגים על הנכס בשקט: יש עסקאות ברשת, אין טוקן בממשק, והמשתמש חושב שההנפקה נכשלה.
סוג שני של כשלים — שגיאות בחוזה החכם בלוגיקת ההעברות ורישום היתרות. טיפול שגוי בהודעות נכנסות, היעדר החזר בעת ביצוע כושל, קוד פעולה שגוי או חוסר גז להודעת שירות מובילים לכך שהחיוב מתבצע אבל הזיכוי לא. כשל כזה לא משוחזר בארנק בדיקה אחד — הוא מתגלה בזרם פעולות, כשחלק מנתיבי הביצוע אינם מכוסים בבדיקות.
השלישי — ניהול הנפקה. אם זכות ההנפקה מוצמדת למפתח יחיד בלי תוכנית העברה, והזכויות להנפקה, הקפאה ושינוי מטא-נתונים אינן מופרדות, הנכס מאבד מהר את השליטה: אי אפשר לשנות פרמטרים או להנפיק נפח נוסף, ובמקביל ההתחייבויות כלפי המחזיקים נשארות. סכמה אמינה היא חוזה ניהול עם אישור בריבוי חתימות ותפקידים נפרדים.
כל ארבע הנקודות נבדקות לפני פרסום החוזה ברשת הראשית — בתרחישי בדיקה עם כמה ארנקים והרצת נתיבי כשל. אנו מנתחים איך זה בנוי בעבודה.
מה נותנת הנפקה מנוהלת של נכס: אפקט במדדים
הנפקה מנוהלת מתחילה בהפרדת זכויות: החוזה הראשי מקבל תפקיד מנהל, שמנפיק ושורף את הנכס, והמחזיקים פועלים רק דרך הארנקים שלהם. תפקיד נפרד — לעצירת פעולות, ועוד אחד — לשינוי מטא-נתונים: אם המפעיל טועה, לא יהיה צורך לשלול סמכויות מיותרות מכל ההרכב. ב-TON זה נשען על תקן Jetton הסטנדרטי, ולכן ארנקים ופלטפורמות רואים את הנכס בלי התאמות מצדם.
מטא-נתוני הנכס מרוכזים למקור יחיד: שם, סימול, מספר הספרות אחרי הנקודה העשרונית ותיאור נמצאים בחוזה, ולא בהתכתבות עם קבלן. ארנקים וסורקים מושכים אותם אוטומטית — תיקון במקום אחד מסיר סוג שלם של אי-התאמות בין ממשקים.
מה משתנה במדדים לאחר עיבוד החוזה מחדש. הנפקת מנה מפסיקה להיות הרכבה ידנית: המנהל קורא לפעולה אחת, ושאר הדברים נעשים על ידי תפקידים ובדיקות. שיעור כשלי ההעברות יורד מדו-ספרתי לשברי אחוז — החוזה עצמו דוחה שליחה לכתובת לא פעילה ומשווה את הספרות אחרי הנקודה העשרונית.
היקף הפעולות הידניות מצטמצם פי כמה: התאמת יתרות, העברת טוקנים בין ארנקים ותיקוני מטא-נתונים עוברים לחוזה. נעלם גם סוג של כשלים בגלל חוסר יתרה לעמלה וכתובת מקבל שגויה — העברות כאלה נחסמות לפני שליחה, לא אחריה.
אפשרויות הנפקה: מתי צריך טוקן Jetton משל עצמך
Jetton — זה לא חוזה אחד, אלא צירוף: מאסטר עם מטא-נתונים והנפקה ועוד ארנקים שנוצרים עבור כל מחזיק. הבחירה מצטמצמת לשאלה אחת: כמה לוגיקה אנחנו שמים מעל ממשק הטוקן הסטנדרטי, וכמה משאירים ללא שינוי. ארנקים, בורסות ושירותי המרה קוראים בדיוק את הממשק הסטנדרטי — סטיות ממנו שוברות זיהוי ורישום יתרה.
אפשרויות החוזה מצטמצמות לשלוש: תבנית סטנדרטית ללא שינויים, תבנית עם הרחבות או ארכיטקטורה ייעודית. ההבדל מתגלה לא בהפעלה, אלא כשצריך הקפאה, עמלה מהעברה או מגבלות על ארנק — שם ההתנהגות הסטנדרטית כבר לא מספיקה.
| אפשרות | מתי מתאימה | מגבלות |
|---|---|---|
| תבנית סטנדרטית | טוקן פשוט עם הנפקה קבועה, הטבעה ושריפה לפי התקן | הלוגיקה מוטבעת: אין עמלות, הקפאות והפצה, כל שיפור — חוזה חדש |
| תבנית עם הרחבות | הנפקה ושריפה בשליטת מנהל, הקפאה, גביית עמלה מהעברות | ביקורת וחישוב גז מסובכים יותר, ובמימוש לא זהיר נפגעת התאימות עם ארנקים |
| ארכיטקטורה ייעודית | כלכלה בתוך הטוקן: הפצה, הבשלה, מגבלות, תרחיש העברה משלך | פיתוח ובדיקות ארוכים יותר, נדרשת עבודה נפרדת על הגירת מצב |
יכולת ההרחבה של החוזה נקבעת לפני הפריסה: קוד המאסטר ב-TON אינו ניתן לשינוי לאחר הפרסום, ולכן שדרוג הוא פרסום מאסטר חדש והעברת מצב. כתובות הארנקים של המחזיקים משתנות, ולוקחים זאת בחשבון באינטגרציות מראש — אחרת לאחר העדכון רישום היתרות בשירות או בבורסה יתפצל.
שלבי העבודה: מסכמת הנפקה עד העברת המערכת
שלבי הפיתוח בנויים כך שלפני ההפעלה החוזה יתאים לסכמת ההנפקה, ולא יורכב מחלקים. כל שלב נסגר בארטיפקט ניתן לבדיקה: סכמת תפקידים, דוח בדיקות, כתובת החוזה שפורסם.
- ניתוח דרישות. קובעים את נפח ההנפקה, מי ולפי איזה כלל מקבל טוקנים, האם נדרשים הנפקה משלימה ושריפה, והאם נדרשת הקפאת העברות.
- תכנון סכמת הנפקה ותפקידים. מגדירים אילו ארנקים מנהלים הנפקה ועדכון מטא-נתונים, ותפקידים קריטיים סוגרים בריבוי חתימות.
- פיתוח חוזה לפי תקן Jetton. מיישמים העברות, הנפקה ושריפה, מטא-נתונים, הגבלות גישה וטיפול תקין בשגיאות.
- בדיקות ברשת מבודדת. מריצים תרחישי הנפקה, העברה, שריפה וסירוב גישה, כולל סכומי קצה וקריאות חוזרות.
- פרסום החוזה. פורסים ברשת הראשית, מקבעים מטא-נתונים, בודקים כתובות ומאמתים את ההנפקה הראשונה.
- העברת זכויות. מעבירים בעלות לארנקים של הלקוח, מתארים נוהל החלפת מנהל ופעולות במקרה של אובדן גישה.
- העברת המערכת וליווי. מוסרים תיעוד וסכמות, עוקבים אחר הפעולות הראשונות ועונים על שאלות הצוות שלכם.
מה מוסרים לידיים: קונפיגורציות, סכמות, נהלים
אנו מוסרים לא רק טוקן עובד, אלא גם כל מה שמאפשר לתמוך בו בלעדינו. הערכה נאספת כך שהמהנדס שלכם יוכל לבנות את החוזים מהקוד המקור, להשוות התנהגות עם סורק הבלוקצ'יין ולבצע כל פעולה בנכס בלי לחפש אותנו.
- קוד המקור של החוזים וקובץ בנייה עם תלויות מקובעות — הפריסה משוחזרת אצלכם שלב אחר שלב, בלי שינויים נסתרים.
- סכמת תפקידים עם עץ בעלות: מי מנפיק, מי מנהל, מי יכול לעצור פעולות ואילו פעולות דורשות כמה חתימות.
- מדיניות גישה — מגבלות הנפקה, סדר העברת ניהול, כללים להוספה ולשלילה של מנהלים.
- תיעוד הנכס: מטא-נתונים, דיוק עשרוני, אופן בדיקת כתובת החוזה והשוואת קוד המקור מצד הסורק.
- תרחישי בדיקה — בדיקות נתיבים ראשיים ונתיבי קצה: הנפקה חוזרת, ניסיון פעולה בלי הרשאות, העברת ניהול, התנהגות בשגיאה.
- נוהל ליווי — מה הבעלים עושה בעצמו, באיזה סדר פועל בתקרית ובאיזה ערוץ יוצר קשר איתנו.
הקבלה נעשית לפי העובדות: פורסים ברשת בדיקה, מריצים תרחישים, משווים התנהגות לתיאור ורק לאחר מכן מקבעים את הערכה עבורכם. בהמשך אתם מנהלים את הנכס בעצמכם — התמיכה מתחברת לפי נוהל, לא כברירת מחדל.
מקרה בוחן: איך הסרנו עומס מחוזה המאסטר
הפרויקט הגיע אלינו עם Jetton שכבר הונפק: הטוקן חי ונסחר, אבל כל הניהול עבר דרך חוזה מאסטר אחד וארנק בעלים אחד. הנפקת מנה, הפצה, הקפאת כתובות — כל פעולה בוצעה ידנית מהארנק הזה, והעסקה הבאה המתינה לאישור הקודמת.
מה היה צוואר הבקבוק
כתובת אחת — מונה סידורי אחד: שתי עסקאות שנשלחו ברצף התחרו זו בזו, והשנייה נכשלה. הפצה לכמה מאות כתובות נמשכה 40–60 דקות של עבודה ידנית, וכ-7% מהפעולות היה צריך להפעיל מחדש. המפתח לחוזה המאסטר היה במקום אחד: פריצתו משמעותה אובדן שליטה על ההנפקה.
מה עיבדנו מחדש ומה נהיה
את חוזה המאסטר השאירו רק להנפקה ולפרמטרים של הטוקן, ואת לוגיקת ההפצה הוציאו לחוזי ארנק נפרדים עם מגבלות מוגדרות. את הגישה פיצלו לתפקידים ב-TON: הנפקה — תחת ריבוי חתימות, העברות שגרתיות — תחת מפתח מפעיל עם תקרה יומית. רשימות הכתובות מוכנות כחבילה, ולכן הפעולות כבר לא עומדות בתור זו אחר זו.
- הנפקת מנה לכמה מאות כתובות: 40–60 דקות ידנית → 2–3 דקות בפעולה אחת.
- פעולות שנכשלו והופעלו מחדש: כ-7% → אף אחת במשך חודש מעקב.
- מפתחות עם זכות הנפקה: אחד → שלוש חתימות, נדרשות שתיים מתוך שלוש.
סוג הכשלים שנעלם — התנגשות על כתובת אחת ושגיאה בשליחה חוזרת. החזרה לאחור הפכה לעסקה אחת, ויומן הפעולות נשאר בחוזה — כעת אפשר לנתח תקלות לפי היסטוריה, לא לפי התכתבות בצ'אט.
מה לעשות אם הנכס כבר הונפק בתקן אחר?
אם הנכס כבר סחר בתקן אחר, אי אפשר לשכתב את החוזה שלו: הקוד ברשת אינו ניתן לשינוי. נשארים שלושה מסלולים — עטיפת הנכס, העברה לפי תמונת מצב של המרשם והחלפה דרך חוזה נפרד. הבחירה נתקעת בשאלה אחת: האם למנפיק יש מפתחות מנהל שנותנים זכות הנפקה ועצירה.
העטיפה בנויה כך: הנכס המקורי ננעל בחוזה מחסן, וב-TON מונפק העתק שלו אחד לאחד. המחזיקים מקבלים כלי תואם בלי פעולות מצדם, והנכס המקורי נשאר בתוקף — חזרה לאחור אפשרית. המחיר — אמון במחסן: בלי אישור ציבורי של הרזרבה, העטיפה נסחרת בזול יותר מהמקור.
העברה לפי תמונת מצב מיושמת כשהחוזה מוסר זכות הנפקה ועצירה. על מצב רשת קבוע נאסף מרשם מחזיקים, החוזה הישן מוקפא, ובחדש מונפקים אותם נפחים — שימור המחזיקים מלא, ואין להם צורך לעשות דבר.
הקושי הוא בדיוק המרשם: אם התקן לא מוסר רשימת כתובות, אוספים אותה לפי אירועי העברות, וכל רשומה שהוחמצה הופכת למחלוקת עם הבעלים.
התאמה בין תקנים כמעט לעולם אינה מלאה: שונים הספרות העשרוניות, מודל המטא-נתונים, שיטת הרישום — יתרה בתוך החוזה מול מרשם נפרד. זול יותר לסגור פערים בשלב התכנון של חוזה חדש מאשר אחרי ההנפקה.
בלי מפתחות מנהל נשאר חוזה הגירה: המחזיק עצמו מכניס את הנכס הישן ומקבל חדש. אין כפייה, אבל המעבר מתארך, חלק מהמחזיקים נשארים בנכס הקודם, ובנכס אחד מופיעים שני מחירים. מבחינת זכויות הבעלים זו האפשרות החלשה ביותר: ניהול ההנפקה עובר לחוזה החדש, וההתחייבויות כלפי מחזיקי הישן נשארות.
שאלות טכניות נפוצות לפני תחילת העבודה
לפני פריסת טוקן Jetton כמעט תמיד עולות אותן שאלות הנדסיות: אפשר לשנות לוגיקה אחר כך, היכן נמצאים מפתחות המנהל, האם נדרשת ביקורת ומה נשאר לבעלים לאחר ההעברה. התשובות להן קובעות את הארכיטקטורה לא פחות מהטוקנומיקה עצמה.
להלן ניתוחים קצרים. דווקא ההחלטות האלה קובעות אם חוזה המאסטר יהיה ניתן לשדרוג או בלתי ניתן לשינוי, מי מחזיק בזכות ההנפקה ואילו מגבלות מוטבעות בקוד.
אפשר לעדכן את לוגיקת החוזה לאחר ההפעלה?
כן, אבל רק אם יכולת השדרוג נקבעת מראש. לשם כך שמים חוזה מאסטר מנוהל עם כתובת קוד נפרדת או סכמת פרוקסי: ההתנהגות משתנה, כתובת הטוקן והארנקים של המחזיקים נשארים כשהיו.
בחוזה בלתי ניתן לשינוי אין עדכון — הלוגיקה החדשה נפרסת כמאסטר נפרד, והיתרות מועברות בתמונת מצב, מה שדורש הגירת מחזיקים.
היכן נשמרים מפתחות המנהל?
לא במאגר, לא בהתכתבות ולא במכונת עבודה. מפתח הבעלים נמצא בארנק חומרה, ולהנפקה ושינוי פרמטרים משתמשים בריבוי חתימות עם הפרדת תפקידים: חתימה אחת לא נותנת שליטה מלאה. מתארים מראש רוטציה של מפתחות ונוהל שחזור גישה, כדי שהחלפת אחראי לא תחסום את ניהול הטוקן.
האם ביקורת חוזה היא חובה?
להשקה ציבורית — כן. בודקים הנפקה ושריפה, מגבלות, מתמטיקת עמלות, זכויות בעלים ותרחישי כניסה חוזרת. בנפרד בודקים שאין אפשרות לקרוא לפונקציות הניהול תוך עקיפת הכללים המוצהרים. בסיום — דוח עם רשימת הערות ותיקונים לפני הפריסה.
אילו זכויות נשארות לבעלים ומה קורה אם המפתח נפרץ?
לאחר ההעברה לא נשאר אצלנו דבר: זכויות הנפקה, השהיה ושינוי פרמטרים מועברות לכתובת של הלקוח. בהמשך אנו מגבילים את היקף הזכויות בכוונה — מגבלות על הנפקה, מנעול זמן לשינוי פרמטרים קריטיים, חוזה מנהל נפרד. זה מפחית נזק אם מפתח הבעלים נפרץ: תוקף לא יוכל בקריאה אחת להנפיק נפח שרירותי או לקחת נזילות.
נדון במשימה ונחזור עם הערכה ותוכנית
דרישות טכניות לטוקן Jetton לעיתים רחוקות נכנסות לשורה אחת: נדרשים תפקידים להנפקה ולהקפאה, כללי העברות, מטא-נתונים, חיבור לארנקים ולפלטפורמות.
כדי שהערכת העבודה תתבסס על היקף העבודה ולא על אינטואיציה, אנחנו צריכים הקשר ראשוני — אז בתוכנית היישום נשארות פחות הנחות, ונקודות מחלוקת נדונות לפני שורת הקוד הראשונה.
מה לשלוח לניתוח:
- כלכלת הטוקן: הנפקה כוללת, חלוקת חלקים, מכניקת הנפקה משלימה ושריפה;
- תפקידים וזכויות: מי מנפיק, מקפיא, משנה פרמטרים של החוזה ואיך הזכויות האלה מועברות;
- תרחישי העברות: עמלות, מגבלות על סכום ותדירות, מס על עסקה, רשימות לבנות ושחורות;
- דרישות למטא-נתונים: שם, סימול, מספר הספרות אחרי הנקודה העשרונית, אייקון ותיאור לארנקים;
- פלטפורמות יעד: בורסות, שירותי משמורת, בורסות מבוזרות — התנאים שלהן לחוזה;
- מגבלות הפרויקט: לוחות זמנים, צורך בביקורת חיצונית, חיבור לשירותים שכבר פועלים.
בתשובה נחזיר סכמת חוזים עם אזורי אחריות, רצף שלבים, הרכב העבודה והערכה עם רשימת הנחות שמהן היא תלויה. אם בניתוח יצוצו הסתעפויות — למשל הנפקה קבועה מול מנוהלת — נראה את שתי האפשרויות וההשלכות שלהן להמשך הפיתוח. תארו את המשימה בצורה חופשית וצרפו את מה שכבר קיים: נחזור עם הערכה ותוכנית.