מדוע האינטגרציה של Kelp DAO נשברת בעת משיכת כספים
פוזיציה ב-liquid restaking פתוחה, הנכסים פעילים ומניבים תשואה, אך המשיכה לא עוברת: הבקשה נכנסת לתור היציאה ותלויה ללא תנועה. בממשק היתרה מוצגת, אך לא ניתן למשוך אותה — תעודת ה-restaking נשארת כתביעה על הנכס הבסיסי, עד שהוא יתפנה מה-staking.
הסיבה היא שהאינטגרציה של Kelp DAO נשענת בבת אחת על שני תורים שאינם מסונכרנים: יציאה מפרוטוקול ה-liquid restaking ויציאת הוולידטורים מהרשת שבה מונח הנכס הבסיסי. הראשון נסגר לפי בקשות, השני — לפי מחזורים פנימיים ומגבלות על מספר היציאות ביממה, ובמצב של עומס יתר שניהם נמתחים לימים.
אם התעודה הספיקה לעבור לשוק המשני או התקבלה כבטוחה, עד לרגע היציאה מחזיק התביעה והכתובת שהגישה את הבקשה כבר אינם זהים.
המחיר התפעולי של פוזיציה תקועה גבוה מכפי שנדמה: מערכות הנה"ח מחזיקות אותה כיתרה נזילה, אף שלא ניתן לסגור אותה עד לתאריך הנדרש. יציאה דחופה דרך השוק המשני משמעה ניכיון ביחס לערך הנקוב, והתשואה שנצברה בזמן ההמתנה אינה מכסה את הניכיון. עבור מחלקת הכספים נוצר פער בין המספר בדוח לבין הכספים שזמינים בפועל.
אנו מפרקים כיצד סוגרים זאת: אילו בדיקות להציב לפני פתיחת הפוזיציה, כיצד לנהל את תור היציאה ומה לנטר, כך שפוזיציה תקועה תתגלה בשעות הראשונות ולא ברגע שבו הכספים נחוצים.
מה מספק ה-liquid restaking מלבד תשואה
ה-liquid restaking בעל ערך לא בפני עצמו: הוא מאפשר להחזיק פוזיציה בהגנה של רשת EigenLayer ובו-זמנית להשאיר את אותם נכסים במחזור. בחיבור דרך Kelp DAO הנכס המופקד הופך לטוקן-קבלה, שניתן להשתמש בו בהמשך — כבטוחה, בבריכות נזילות או כערובה. להלן — האפקטים שנראים בדיווח, ולא במצגת.
- מחזור הנכסים אינו נפסק. התשואה על הנכסים המופקדים נצברת, וההון אינו מושבת לכל תקופת החסימה — הוא ממשיך לפעול באסטרטגיות אחרות.
- נזילות הפוזיציה נשמרת. הזכות לחלק ב-staking נסחרת כטוקן רגיל: ניתן למשוך חלק מהפוזיציה בלי לצאת מה-restaking כולו.
- הנה"ח פוזיציות ה-restaking מתאמת אוטומטית. התשואות, ה-re-delegation והעמלות נאספים ממקור אחד, ולכן התאמות מול ייצוא ידני יוצאות מהמשימות השוטפות.
- צמצום הפעולות הידניות. בקשות משיכה וחלוקת תגמולים פועלות לפי נוהל ולוח זמנים, ולא לפי מייל מהמפעיל.
- משטר משיכות צפוי. התורים והמגבלות ידועים מראש — תקלות לא מתוכננות הופכות לזמן המתנה מוגדר.
אנו בודקים זאת בשלב החיבור: תחילה פוזיציה ניסיונית בהיקף מינימלי, אחר כך התאמת נתונים מול המרשם, ורק לאחר מכן משיכת שאר הנכסים. כך האפקט נראה עוד לפני שכל התיק עובר ל-restaking.
תרשימי חיבור: מסלול ישיר, עטיפה, היברידי
האינטגרציה של Kelp DAO נתקלת לא בפרוטוקול עצמו, אלא בבחירת תרשים החיבור: הוא קובע היכן עובר גבול האמון ומי מחזיק במפתחות לפוזיציה ב-restaking.
מסלול ישיר, חוזה-עטיפה והיברידי מכסים פרופילי תשתית שונים — מ"כבר יש אחסון באחריות וניהול חלקים" ועד "דרוש ליישם שכבת ניהול משלנו מעל חיצוני".
| אפשרות | מתי מתאים | מגבלות |
|---|---|---|
| מסלול ישיר | ניהול החלקים והמפתחות כבר בשליטה, יש ניסיון בעבודה ישירה עם פרוטוקולים חיצוניים | תלות בשינויים בצד הפרוטוקול, דפי חשבון ודיווח נאספים ידנית |
| חוזה-עטיפה | דרושים מגבלות משלנו על משיכה, תפקידי מפעילים וניהול חלקים אחיד בתוך המערכת | שכבת חוזים נוספת: יש לבדוק אותה, לעדכן אותה ולהחזיק אותה בהתאמה לבסיסית |
| תרשים היברידי | חלק מהנכסים עובר ישירות, חלק — תחת עטיפה, החלוקה נקבעת לפי מדיניות סיכון | שתי ספרי חשבונות: ההתאמה מסובכת יותר, דרושים מרשם פעולות משותף וכללים חד-משמעיים לאיחוד יתרות |
בהמשך מכריע חלוקת התפקידים: מי שמנהל את המפתחות ומי שמנהל את החלקים — אלה מסלולים שונים עם הרשאות שונות, ואין לערבב ביניהם. בנפרד אנו בודקים תאימות עם הסטאק הנוכחי: פורמטים של דפי חשבון, סדר הצגת התשואות, ממשקי החלפה עם מה שכבר פועל. פערים בנקודות אלה זולים יותר לגלות בשלב התכנון — כשהתרשים עוד לא מעוגן בחוזים.
סדר האינטגרציה: מביקורת פוזיציות ועד למסירה
השלבים הולכים ברצף קפדני: כל אחד נשען על תוצאת קודמו, ולא ניתן לדלג על ביקורת הפוזיציות — פערים בהנה"ח צפים כבר בהיקפים מבצעיים, כשהטיפול בהם הוא היקר ביותר.
- ביקורת פוזיציות. אנו מרכזים מה והיכן מושקע: נכסים מופקדים, קבלות שהתקבלו, תגמולים שנצברו, בקשות משיכה שלא נסגרו. אנו מתאימים את הארנקים למצב של Kelp DAO — פער בשבריר אחוז הופך לאחר החלוקה מחדש הראשונה ליתרה שאינה מונהלת בחשבונאות.
- תרשים זרימות הנכסים. אנו מתארים את המסלול של כל נכס: מהיכן הוא מגיע, היכן הוא נכלל בחשבונאות, ובאיזו צורה הוא חוזר בעת המשיכה. התרשים מראה מיד את הנקודות שבהן דרושה חתימה ידנית, ואיפה די באוטומציה.
- הגדרת תפקידי גישה. אנו מפרידים בין הרשאות קריאת פוזיציות, ניהול ומשיכה; פעולות גדולות מוציאים למסלול עם ריבוי חתימות. את ההרשאה למשיכה אין אנו מעניקים לאותם מפתחות שמבצעים את הפעולות השוטפות.
- בדיקה בהיקפים קטנים. אנו מריצים מחזור מלא — הפקדה, קבלה, צבירה, משיכה חלקית. כאן נראים עיגולים ועלויות רשת, וחוסר סנכרון בין הנה"ח שלנו לנתוני הפרוטוקול נתפס עוד לפני שפוזיציות מבצעיות נכנסות למסלול.
- קבלת המסלול. אנו מתאימים מדדי בקרה: סכומי הפוזיציות, התגמולים שנצברו, זמן התגובה לשינוי מצב. אנו מקבלים לא "זה עובד", אלא עם מספרים — שיעור המסלולים תחת בדיקות והיעדר צעדים ידניים במחזור השוטף.
- מסירה. אנו מוסרים קונפיגורציות, תרשים, נהלי משיכה ושחזור גישה, הוראות למשמרת התורנות. בנפרד אנו מתעדים תרחיש נסיגה: כיצד להחזיר את הנכסים למצבם המקורי.
מה נשאר לצוות לאחר ההטמעה
ההטמעה מסתיימת לא בהרצה, אלא במסירת מסלול הליווי: המהנדסים של הלקוח חייבים להיות מסוגלים לבצע בעצמם את הפעולה, להחזיר את הפוזיציה ולשחזר אותה לאחר תקלה. לכן בפלט — ערכת הגדרות ומסמכים שלפיהם העבודה מתנהלת בלעדינו: מקונפיגורציות צמתים ועד סדר הפעולות בעת עצירת משיכה.
- תרשימי אינטגרציה — כיצד נעים הכספים בין ארנק הקסטודיה, חוזי ה-restaking ושכבת הנה"ח: היכן מונפק הטוקן הנגזר, היכן נרשם החלק ובאיזו נקודה אפשרי קרע.
- קונפיגורציות המסלול — כתובות חוזים לפי רשתות, פרמטרי צמתים, מגבלות לפעולה אחת ולהיקף יומי, ערכות נפרדות למסלול הניסוי ולמסלול המבצעי.
- מדיניות גישה — מטריצת תפקידים: מי מכין את הפעולה, מי מאשר, מי משנה מגבלות; ארנק עם ריבוי חתימות ומפתח מפעיל עם הרשאות מצומצמות.
- נוהל משיכה — סדר היציאה מהפוזיציה בהתחשב בתור ובתקופת השחרור, עם נקודות בקרה שבהן ניתן לעצור את הפעולה בלי לאבד את החלק.
- סדר שחזור הפוזיציה — פעולות במקרה של עסקה תקועה, פער ביתרה או עצירת וולידטור: נקודות כניסה, סדרי עדיפויות של צעדים, למי להסלים.
- הוראות לצוות — פירוק פעולות טיפוסיות עם התוצאה הצפויה בכל צעד, רשימת תיוג לקבלה לאחר שינויים וטבלת שגיאות נפוצות.
הערכה נשארת אצל הלקוח ומתעדכנת בהתאם לצמיחת הפוזיציה.
מקרה בוחן: מסלול restaking עבור מפעיל צמתים
מפעיל צמתים החזיק פוזיציית restake ב-Kelp DAO: rsETH מופץ בין מפעילי EigenLayer, התגמולים נצברים, אך היציאה והחלוקה מחדש של החלק בוצעו ידנית בידי המהנדסים. בקשת היציאה נאספה בסקריפט, התור הותאם בעין, החתימות — בריבוי חתימות, ועסקה שלא אושרה נשלחה שוב עם אותו גוף.
לפני: משיכה ידנית ומצבים מהפכפים
משיכה ממוצעת ארכה עד שלושה ימים — לא בגלל רוחב הפס של הרשת, אלא בגלל צעדים ידניים והמתנה לקוורום של חותמים. מסוכן יותר מהעיכוב היה דבר אחר: הגשה חוזרת של בקשה יצרה רשומה שנייה בתור, וחלק מהפוזיציה נתקע בין מצבים. המרשם היה מנותק מהפוזיציה בפועל ברשת, וטיפול בכל מקרה כזה ארך עוד כמה ימים.
אחרי: מסלול אידמפוטנטי ומדדים
מקרה האינטגרציה נבנה סביב המשיכה: צופה תור, הגשה אידמפוטנטית של בקשות עם מפתח-מזהה, חלוקת תפקידים בין היוזם למאשר, מרשם בקשות עם מצבים ויומן פעולות. הצעדים הידניים הוסרו, החזרה אינה יוצרת עוד בקשה חדשה, אלא רק מאשרת את הקיימת.
- זמן משיכת הכספים: משלושה ימים לעשרות דקות.
- סוג התקלות שהוסר — "בקשת יציאה כפולה": נעלם לחלוטין.
- פער בין המרשם לפוזיציה ברשת: ממקרים בודדים בחודש לאפס.
- טיפול בתקלה: לפי היומן תוך דקות במקום התכתבות והתאמה ידנית.
במה שונה ה-liquid restaking מ-staking רגיל
staking רגיל חוסם נכסים: כל עוד החלק פועל על וולידטור, אי אפשר למשוך אותו — רק לצאת מהתור ולהמתין לחישוב. הנכס מניב תשואה, אך יוצא מהמחזור: אי אפשר למכור אותו, למשכן אותו או להעביר אותו לאסטרטגיה אחרת. חסימת נכסים זו אינה הגדרה, אלא תנאי של עבודת הרשת, ועל הגמישות האבודה בדיוק משלמים לכם בתגמול.
liquid restaking מנתק את הקשר בין ההשתתפות ברשת לבין החסימה. הנכסים המופקדים עוברים ל-staking, ובתמורה מקבלים טוקן-קבלה — טוקן חשבונאי לפוזיציה מסוימת, המאשר את הזכות לנכסים שהופקדו ולתגמול שנצבר. הקבלה נסחרת בחופשיות: מחזיקים בה, מוכרים אותה, ממשכנים אותה, נותנים אותה כערובה.
מכאן השכבה השנייה — restaking, כאשר אותה פוזיציה ממושכנת שוב בשירותי צד שלישי. Kelp DAO פועל כעטיפה מעל תרשים כזה: מפזר את הפוזיציה בין מפעילים ומוציא למשתתף קבלה שהופכת לכלי הנזיל שלו.
ניהול הנזילות משתנה מהיסוד. בעבר אי אפשר היה להעריך מחדש פוזיציה חסומה או לסגור אותה חלקית — רק להמתין ליציאה. כעת ההחלטה מתקבלת בשוק המשני, אך יחד עם הגמישות מגיעים סיכונים חדשים: פער בין מחיר הקבלה לנכס הבסיסי, חיסול בעת משכון, שגיאה בקוד החוזה.
לכן באינטגרציה בודקים קודם כל באיזה מחיר הקבלה נכללת בחישובים, כיצד מתבצעת היציאה מהפוזיציה ומה קורה לה בעת נפילה חדה בשוק. שלוש נקודות אלה קובעות אם התרשים יישאר ניתן לניהול.
שאלות טכניות נפוצות לפני תחילת העבודה
לפני תחילת העבודה, הספקות ההנדסיים חוזרים על עצמם: כמה זמן להמתין ליציאה מהתור, מה קורה בעת slashing של מפעיל, כיצד משחזרים את הפוזיציה לאחר תקלה, האם המסלול החדש ישתלב עם השירותים שכבר פרוסים ואילו הרשאות נדרשות לגישה למפתחות. אנו עונים לגופן של הדברים — בלי ניסוחים שיווקיים.
כמה זמן באמת אורכת משיכת הכספים?
המשיכה מ-Kelp DAO עוברת דרך תור היציאה של ה-restaking: כל עוד המפעיל לא סיים את ההליך, הטוקנים לא משוחררים. אנו מחשבים את הזמן לפי העומק הנוכחי של התור ומכניסים אותו לתוכנית, ואיננו מבטיחים החזר מיידי.
מה קורה בעת slashing?
slashing הוא חיוב של חלק מהחלק בגין הפרת כללי הוולידציה, והוא פוגע בכל מי שהאציל. לכן אנו מפזרים את הפוזיציה בין כמה מפעילים עם פרופילי סיכון שונים ומגדירים התראה על ירידת החלק.
כיצד משחזרים את הפוזיציה לאחר תקלה?
אנו שומרים תמונת מצב וכתובות מפתח באחסון מאובטח: בעת כשל של צומת הפוזיציה נבנית מחדש לפי יומן האירועים, ולא מאפס. את תרחיש הנסיגה אנו מריצים במסלול הניסוי לפני ההרצה במסלול הראשי.
האם זה תואם למסלול שכבר פרוס?
כן. האינטגרציה אינה מחייבת לכתוב מחדש את השירותים הקיימים או להחליף את אחסון המפתחות — היא מתחברת כשכבה נפרדת ופועלת דרך הממשקים שכבר אומצו. בדיקת החוזים והפרדת הרשאות הגישה נעשות לפני ההעברה הראשונה של כספים.
נדון במשימה ונחזור עם תוכנית עבודה
כדי שאומדן היקף העבודה יהיה מדויק, ולא "פחות-או-יותר", תארו את המשימה בחתך של נכסים, תפקידים ותרחישים. להלן — מערך הנתונים המינימלי שמספיק לנו כדי לחזור עם תוכנית אינטגרציה והרכב העבודה לפי שלבים.
- נכסים ורשתות. אילו נכסים מוכנים לקבל ל-restaking, באיזו רשת פועל המוצר, האם נדרשת משיכת הפוזיציה בחזרה לצורה נזילה ובאיזו צורה.
- תרחישי שימוש. הפקדה, משיכה, צבירה ותביעה מחדש של תגמולים, הצגת החלק בבריכה — מה מזה נדרש בממשק, מה בדיווח ומה נסגר ידנית.
- תפקידים והרשאות. מי חותם על הפעולות, האם קיים תרחיש קסטודיאלי או לא-קסטודיאלי, האם דרושים מגבלות, ריבוי חתימות והפרדת הרשאות בין העובדים.
- הנה"ח ודיווח. כיצד הפוזיציה צריכה להיות מוצגת במאזן הפנימי, האם נדרשת הערכה מחדש של החלק וייצוא נתונים לראיית חשבון או לקומפליינס.
- מגבלות ודרישות. תחומי שיפוט של המשתמשים, דרישות קומפליינס, סוג התקלות שחייבים לטפל בו בהכרח, ומה שאסור לעשות.
- מצב נוכחי. אילו פיתוחים קיימים כבר, מה עם ההרשאות והקוד, מי בצד שלכם מקבל את התוצאה וחותם על הקבלה.
- לוחות זמנים ועדיפויות. מה נדרש לקראת ההרצה, ומה ניתן להוציא לשלב שני בלי לאבד ערך.
שלחו זאת בצורה חופשית — אין צורך להכין מסמך. נחזור עם אומדן היקף העבודה ותוכנית האינטגרציה: הרכב העבודה לפי שלבים, אזורי האחריות של הצוות שלכם ושל הצוות שלנו, נקודות הקבלה וסדר הפנייה לשינויים. נדון במשימה בקצרה כדי לחדד פרטים, ונקבע את הסיכומים בכתב — כך הציפיות לא יתפצלו כבר בהתחלה.