אינטגרציה של EtherFi: היכן נשבר רישום החלק והתגמולים
ברסטייקינג נזיל היתרה מפסיקה להיות 1:1 עם ETH: EtherFi מנפיק חלק שערכו משתנה יחד עם שער ההמרה. אם אינטגרציה של EtherFi מנהלת רישום ב-ETH נומינלי ואינה מחשבת מחדש את החלק לנכס הבסיס, היתרה באזור האישי אינה תואמת את היתרה בפועל בחוזה. בסכומים קטנים השגיאה אינה מורגשת, אך היא צצה במשיכה גדולה ראשונה, כאשר את הפער יש לכסות על חשבונך.
תגמולי סטייקינג — נקודת כשל שנייה. מקורם באירועי החוזה ובחישוב מחודש תקופתי של השער, ולא בייצוא מדוח בורסאי. התאמות ידניות נשברות בגלל אירוע שהוחמץ, מסירה כפולה או ארגון מחדש של השרשרת: התגמולים או מוכפלים בטעות, או הולכים לאיבוד, ולא ניתן לשחזר את התמונה בדיעבד.
נקודת כשל שלישית — משיכת כספים. הבקשה נכנסת לתור ונשארת משויכת לכתובת ולקבלה, ולא לרשומה במערכת הרישום.
טעויות נפוצות במשיכת כספים מתחילות בכך שהאינטגרציה מתייחסת למשיכה כפעולה מיידית: סטטוס הבקשה אינו מנוטר, בעל הקבלה אינו נבדק — הכספים נתקעים בתור, והזכות עליהם אובדת עם החלפת ארנק.
השורש המשותף לכל שלושת הכשלים אחד: רישום החלק, התגמולים מסטייקינג והזכויות למשיכה חייבים להיבנות מנתוני החוזה, ולא מטבלאות ביניים. נסביר כיצד זה נסגר.
מה משתנה לאחר חיבור רסטייקינג נזיל
הפוזיציה בסטייקינג מפסיקה להיות "קפואה": במקום ETH ביתרה מופיע אסימון-קבלה, שמייצג את אותו חלק, אך נסחר כמו נכס רגיל. הוולידטורים ממשיכים לעבוד ולהניב תשואת רסטייקינג, ובזמן הזה הקבלה משתתפת בחישובים, משמשת כבטוחה או עוברת לאסטרטגיה אחרת. מודל כזה מספק EtherFi, והוא משנה לא את גובה התגמול, אלא את הנזילות של ה-ETH שכבר הופקד.
משיכה מפסיקה לדרוש עצירת ולידטורים. בעבר יציאה משמעה המתנה בתור ואובדן תגמולים לכל אותו זמן; כעת הפוזיציה נסגרת באמצעות החלפת הקבלה, והוולידטור ממשיך להניב תשואה עד ליציאה בפועל.
זמן המשיכה נמדד בעסקה אחת במקום שעות ויממה של המתנה, והתוצאה ההנדסית כאן היא צפיות: היקף הנזילות הזמינה ידוע מראש, ולא תלוי בעומס הרשת.
רישום התגמולים עובר למרשם. אירועי החוזה נקראים ישירות, תגמולים ושערי חישוב מחדש נכנסים למסד הנתונים אוטומטית, ושיעור הפעולות הידניות יורד לבדיקת חריגים בלבד. נעלם סוג שלם של כשלים — פער בין היתרה הפנימית למצב הפוזיציה בפועל: בעבר תפסו אותו למחרת, כעת הפער נראה ברגע הפעולה.
עבור הלקוח המשמעות היא שתשואת הרסטייקינג הופכת לגודל ניתן לניהול, ולא לדוח בדיעבד. אנחנו סוגרים אינטגרציות כאלה מקצה לקצה: החלק החוזי, קריאת אירועים, חישוב מחדש של שער הקבלה במסד הנתונים, טיפול במצבי קצה וייצוא לראיית חשבון.
פורמטי חיבור: חוזה הפרוטוקול, שער, מתווך
פורמטי החיבור נבדלים לא בממשק, אלא במי שומר על המפתחות והיכן מנוהל רישום הפוזיציות. חוזה פרוטוקול ישיר נותן שליטה מרבית: התפקידים שלכם, האישורים שלכם, ובין הקוד ל-EtherFi אין לוגיקה זרה.
שער-עטיפה מוסיף בצד שלכם שכבה דקה של בדיקות — מגבלות לפעולה אחת, תקרה יומית, הפרדה בין תפקיד המפעיל לתפקיד המושך. תוכנית עם מתווך מעבירה את החזקת הפוזיציות לצד חיצוני, ומשאירה לכם רק את הרישום.
| פורמט | מתי מתאים | מגבלות |
|---|---|---|
| חוזה פרוטוקול ישיר | המפתחות ומדיניות המשיכות נשארים בפנים; נדרשת שליטה מלאה בתפקידים ובהשהיית פעולות | אתם מטפלים בעצמכם בהשהיות משיכה, בשינוי שער ההמרה ובעדכונים בצד הפרוטוקול; חלוקת ההרשאות מתוכננת מאפס |
| שער-עטיפה | ברישום הפנימי כבר יש תפקידים ומגבלות — נדרשת נקודת בדיקה אחודה לפני קריאה לפרוטוקול | מוסיף שלב ביצוע ועלות גז; הקוד שלכם דורש ביקורת ומתעדכן בעקבות ממשק הפרוטוקול |
| תוכנית עם מתווך | התחלה מהירה, אין צוות שמחזיק מפתחות באופן קבוע, הרישום חשוב יותר מהחזקה ישירה של הפוזיציה | סיכון צד נגדי, השהיות במשיכה, הרשאות מוגבלות, תלות בדיווח של צד זר |
באופן מעשי הבחירה מצטמצמת לשלוש שאלות: מי מחזיק במפתחות, באיזו מערכת הרישום מתכנס, וכמה תפקידים צריך להפריד. אם התפקידים אינם מופרדים, אף פורמט לא מציל: מפתח אחד להפקדה ולמשיכה מאפס כל מגבלה. תארו את מודל ההרשאות והרישום שלכם — נחזור עם הערכה ותוכנית מעבר.
סדר האינטגרציה של EtherFi: מביקורת ועד מסירה
אינטגרציה עם EtherFi אינה עסקה חד-פעמית, אלא שינויים בשמירת מפתחות, במודל התפקידים ובמגבלות המשיכה. תחילה אנו מרכיבים את תרשים הזרימות: מהיכן ETH יוצא לסטייקינג, לאן מגיעים אסימוני האישור ובאיזה נתיב הם חוזרים. לאחר מכן העבודה מתבצעת בשלבים — מביקורת התצורה הנוכחית ועד מסירת נהלים לצוות.
- ביקורת ארנקים. מלאי כתובות, מפתחות והרשאות, תוכניות חתימה ואישורים שניתנו לחוזים — כולל אלה שנותרו ממשימות קודמות.
- תרשים זרימות. מתעדים את תנועת ה-ETH ואסימוני האישור בין ארנקים, סטייקינג וקופת האוצר, ומסמנים היכן נדרשת חתימה ידנית.
- הגדרת תפקידים ומגבלות. ייזום, אישור ומשיכה מופרדים לתפקידים שונים; מגבלות חד-פעמיות ויומיות בתוספת סף אישורים אינן מאפשרות למשוך את כל הסכום בחתימה אחת.
- בדיקת משיכה. מריצים את מסלול היציאה המלא תוך התחשבות בהמתנה ליציאה מרסטייקינג ובתרחישי חירום: השהיה, סירוב חתימה, החזרת כספים לאחסון קר.
- תצורת בדיקה. חוזרים על התרשים עם מודל תפקידים אמיתי וסכומים מוגבלים — בודקים שהמגבלות פועלות ושכל פעולה נרשמת ביומן.
- ניטור. מגדירים התראות על תנועות כספים גדולות, שינוי הרשאות וחריגות במשיכות.
- מסירת נהלים. מוסרים מפת תפקידים, מדיניות מגבלות, הוראות משיכה ונוהל פעולה באירועים חריגים.
מה מוסרים לידיים: מדיניות גישה ונהלים
מסירה היא לא ארכיון עם מפתחות, אלא סט ארטיפקטים שלפיו הצוות שלכם מבצע פעולות ומטפל באירועים ללא מעורבותנו. כל מסמך משויך לפעולה קונקרטית, ולא נכתב "לשם שלמות".
- מדיניות גישה. תפקידים והרשאות לחוזים, ספי אישור לארנקים מרובי חתימות, מטריצת "מי חותם על מה", נוהל החלפת מפתחות והוצאת משתתף מהתוכנית.
- תרשים אינטגרציה. כתובות חוזים, מסלולי תנועת אסימונים בין ארנקים לאסטרטגיה, תלויות חיצוניות — עם ציון נקודת הכשל והפעולה בה.
- נוהל משיכה. סדר שלב-אחר-שלב, מגבלות לפעולה וליום, מי מאשר, מה מתעד את העובדה ואת סיבת דחיית הבקשה.
- תיעוד רישום. אילו אירועים נקראים מהרשת, כיצד הם הופכים לרישומים לתגמולים, ספרי התאמה וכללי עיגול.
- ניטור תגמולים. התראות על פער בין התגמול הצפוי לזה שבפועל, גידול בתור המשיכה, תקלה — עם ספים, ערוץ ואחראי.
- בדיקה ושחזור. רשימת תיוג לקבלה, היכן נשמרים גיבויים של תצורות, נוהל חזרה לגרסה תפעולית קודמת.
הרשימה סוגרת שאלות של הצוות ושל ביקורת חיצונית: מדוע נצבר סכום כזה, מי רשאי למשוך כספים, מה לעשות בעת פער. האינטגרציה עם EtherFi מפסיקה להיות תלויה באדם אחד — הידע חי במסמכים, ולא בהתכתבות.
מקרה בוחן: כיצד משיכה מרסטייקינג הפסיקה לדרוש עבודה ידנית
לפני: תור משיכה והתאמות ידניות
הלקוח החזיק נתח גדול של פוזיציות ברסטייקינג נזיל — על בסיס EtherFi עם תור המשיכה שלו. כל בקשה המפעיל הרכיב ביד: ייצא רשימה, התאים לרישום הפנימי, בדק את היתרה הזמינה ורק אז שלח את העסקה. עשרות בקשות בשבוע, ושתיים-שלוש התאמות לכל אחת.
מחיר הטעות התברר כגבוה מעלות העבודה. מגבלות המשיכה נבדקו רק לאחר השליחה: אם הבקשה חרגה מההיקף הזמין, היא נדחתה, והמפעיל הרכיב אותה מחדש מאפס. כשליש מהבקשות נשלחו לחזרה, זמן המשיכה הממוצע הגיע עד יומיים, ואת הפער בין האזור האישי לרישום חיפשו בעיניים.
אחרי: אורקסטרטור עם בדיקה מוקדמת
הוצאנו את התהליך לשירות-אורקסטרטור: הוא עצמו מתשאל את התור, משווה את הבקשה לרשומת הרישום ובודק מגבלות לפני השליחה. המשימות אידמפוטנטיות ושומרות מצב, ולכן ניסיון חוזר לאחר תקלה אינו יוצר כפילות.
בקשות שנדחו נשלחות מחדש אוטומטית, עם השהיה הולכת וגדלה, וההתאמה מחושבת לפי האשים של פעולות במקום טבלה ידנית.
מדדים לפני ואחרי: שיעור הבקשות שעוברות דרך המפעיל — מ-100% לאפס; זמן המשיכה — מיומיים לשעתיים-שלוש; מעבר בניסיון ראשון — מ-65% ל-99%; התאמות ידניות — אפס במקום עשרות בשבוע. סוג נפרד של כשלים נעלם: בקשות מעל המגבלה כבר אינן מגיעות לרשת.
במה רסטייקינג נזיל שונה מסטייקינג רגיל?
בסטייקינג רגיל החלק נשאר חסום: הנכס מניב תגמול, אך עד היציאה מהתור הוא אינו משתתף בפעולות אחרות ואינו ניתן להעברה. רסטייקינג נזיל מנפיק על החלק המופקד אסימון-קבלה — הנזילות של החלק נשארת בידי הבעלים, והחלק עצמו פועל לא רק באבטחת הרשת, אלא גם בשירותים נוספים.
ההבדל בין הגישות מתבטא במצבי המשיכה: במקום תור אחד מופיעים שני מסלולים — החלפת אסימון-הקבלה בשוק (מיד, אך לפי שער שעשוי לסטות משווי החלק הבסיסי) ומשיכה דרך הרשת (לפי שווי מחושב, אך עם השהיה). אלה פרופילי סיכון שונים, והבחירה תלויה בתרחיש, לא במהירות.
| אפשרות | מתי מתאים | מגבלות |
|---|---|---|
| סטייקינג רגיל | החזקה ארוכה, אין צורך בנזילות | החלק חסום עד היציאה, היציאה לפי תור משותף |
| סטייקינג נזיל | נדרש חלק ניתן להעברה ויציאה מהירה | תגמול רק מסטייקינג בסיסי, מתווספת שכבת חוזים |
| רסטייקינג נזיל | החלק צריך לפעול בשירותים נוספים | סיכון חוזים וסטייה בשער אסימון-הקבלה |
לסיכון סלאשינג ולהשהיית היציאה מתווספים סיכון חוזים ופער שערים: אסימון-הקבלה נסחר בנפרד מהנכס הבסיסי, והדיסקאונט מתרחב בדיוק כאשר הנזילות נחוצה ביותר. סטייקינג רגיל אינו יוצר שכבות אלה, אך גם אינו מעניק גמישות.
ברישום ההבדל מורגש לא פחות. חלק רגיל — פוזיציה אחת עם תגמול באותו נכס; באינטגרציה עם EtherFi מופיעים שני אובייקטים: החלק הבסיסי ואסימון-הקבלה, שיש להעריך מחדש, להתאים לשער הנכס הבסיסי ולנהל בנפרד מהתגמול.
ספקות טכניים נפוצים לפני חיבור
לפני ההתחלה הלקוח והמחלקה הפיננסית שלו מעלים את אותו מעגל נושאים: באיזו מהירות הנכסים חוזרים, מי נושא בסיכון קנסות הוולידטורים, היכן נמצאים המפתחות והאם הרישום לא יסתור את נתוני הפרוטוקול. להלן מה בדיוק אנחנו מגדירים בכל סעיף.
כמה ממתינה משיכה מהתור?
תור המשיכה הוא תכונה של הפרוטוקול עצמו, ולא השהיה של האינטגרציה: הנכסים משתחררים לאחר שחרור הוולידטור, ובתקופות שיא התור מתארך. בממשק אנו מציגים את סטטוס הבקשה בפועל ואת מקומה, ולא תאריך משוער. אם נדרשת נזילות מוקדם יותר, אנו מספקים החלפת אסימון הרסטייקינג תוך התחשבות בסליפג'.
מי אחראי על חיובי קנס?
קנס נוצר כאשר ולידטור מפר את הכללים, ולא בעת משיכת כספים. כדי שהסיכון לא ייפול על יתרת הלקוח, אנו מפזרים נכסים בין כמה מפעילים ומגבילים את חלקו של אחד — תקלה אצל אחד אינה מורידה את התשואה הכוללת.
היכן נשמרים המפתחות ומי מנהל אותם?
מפתחות פרטיים נשארים בידי הבעלים: האינטגרציה פועלת באמצעות פעולות חתומות ותפקידים בחוזים. אנו מגדירים הפרדת הרשאות — מי מפקיד, מי מושך, מי משנה פרמטרים — ומתארים נוהל להחלפת בעלים, כך שעזיבת עובד לא תחסום גישה.
כיצד זה יתכנס עם הרישום הקיים ומה יקרה בעת עדכון חוזים?
אסימון הרסטייקינג אינו ETH: יש לו קוטיציה משלו, וברישום הוא נכנס כפוזיציה נפרדת. אנו מוסרים אירועים לכל פעולה ומתאימים תגמולים לנתוני הפרוטוקול, כך שהפער יצוף מיד, ולא בסוף התקופה. כתובות ופרמטרים של חוזים חיצוניים נשמרים בתצורה: בעת עדכון הפרוטוקול משתנה ההגדרה, ולא הקוד.
נדון במשימה: נחזור עם הערכה ותוכנית עבודה
כדי לחזור עם הערכה ותוכנית, אנחנו צריכים לא רעיון כללי, אלא את התצורה שלכם: רשתות, תפקידים, מפתחות, היקפים ומגבלות. אינטגרציה עם EtherFi כמעט תמיד נוגעת בחוזים חכמים של צד שלישי ובזרימות ETH, ולכן פער בנתון אחד משנה גם את הארכיטקטורה וגם את לוחות הזמנים.
- תחילת העבודה. מקבעים מטרה: מה בדיוק עושים עם ETH — מפקידים, מושכים, מציגים יתרה ותגמול שנצבר בממשק — ובאיזה תרחיש משתמש האדם.
- נתוני תצורה. נדרשים רשתות, כתובות חוזים, תפקידים ומדיניות חתימת עסקאות, זרימות נוכחיות, מגבלות ודרישות גישה.
- הערכה ותוכנית. נחזור עם פירוק עבודות, שלבים, תלויות בשירותים חיצוניים וקריטריוני מוכנות שלפיהם תקבלו את התוצאה.
- תצורת פיילוט. מרכיבים היקף מינימלי ברשת בדיקה: הפקדה, משיכה, צבירת תגמול והתנהגות המערכת בעת כשל של שירות חיצוני.
- העברת ידע. מוסרים תרשימי אינטראקציה, תצורות, הוראות תפעול וניתוח אירועים — הצוות מלווה את הפתרון בלעדינו.
תארו את המשימה בצורה חופשית — עם תרשים זרימות או בלעדיו. נחזור עם הערכה, תוכנית עבודה ורשימת שאלות שכדאי לסגור לפני ההתחלה.