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

מדוע טוקן דפלציוני מאבד ערך לאחר השקתו למחזור

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

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

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

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

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

מה נותנת שריפה מבוקרת: אפקטים מדידים עבור הפרויקט

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

בתוך שלושה שבועות שיעור הכשלים בהעברות דרך כתובות המרה עלה ל-9%, וההחלקה ביציאה מפוזיציה בגודל 2% מהמאגר הגיעה ל-6-8%. זהו סוג כשל המתואר במרשם תקריות חוזים חכמים ציבורי: שריפה בתוך העברה משנה יתרות לפני שהספיק לפעול נתיב ההמרה.

מה הונדס מחדש

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

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

מדדים לפני ואחרי

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

מה לעשות אם מנגנון השריפה לא הוטמע מההתחלה?

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

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

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

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

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

שאלות טכניות: שריפה, אינטגרציות, מגבלות

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

מי וכיצד יכול לשנות את שיעור השריפה?

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

מה בדיוק בודק המבקר?

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

כיצד הטוקן מתנהג בפלטפורמות חיצוניות?

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

היכן המנגנון נשבר לרוב?

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

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

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

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

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