אינטגרציה של Mantle Staked ETH (mETH) לסטייקינג נזיל ב-Mantle L2

Mantle Staked ETH: היכן נשבר הסטייקינג הנזיל במוצר

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

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

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

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

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

מה משתנה בכלכלת המוצר לאחר חיבור mETH

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

הכלכלה משתנה прежде всего ברמת הרישום. הצבירה אינה מפוזרת כרשומות נפרדות ביומן: התשואה מוטמעת ב-mETH עצמו ומתבטאת בשער שלו מול ETH. גודל אחד מתאר גם את הפוזיציה וגם את הצבירה — ההתאמה מצטמצמת לשער בתאריך, ולא למרשם צבירות ידני לכל תקופה.

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

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

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

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

הנפקת Mantle Staked ETH (mETH) דרך חוזה סטייקינג מסירה את שאלת המפתחות: ההפקדה מוחלפת לפי שער, והטוקן נרשם מיד ביתרה.

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

שלבי הטמעה: ביקורת סכימה, הגדרה, בדיקה, מסירה

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

סדר העבודה

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

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

ארטיפקטים של הטמעה: תצורות, סכמות רישום, נהלים

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

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

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

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

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

מה שינינו

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

מה התקבל

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

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

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

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

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

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

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

ספקות טכניים: סיכוני חוזה, משיכה, דיווח

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

מה מציגה הביקורת וכיצד החוזה מתנהג בעת כשל?

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

כיצד מושכים כספים ומה עם הנזילות?

החלפת Mantle Staked ETH בשוק המשני מהירה יותר, אך תלויה בעומק המאגר; פדיון דרך החוזה מתבצע בתור, עד שהמאמת יוצא מהרשת. עומק השוק והיקף המשיכות הצפוי נבדקים מראש, ואנחנו מחזיקים חוצץ כדי שיציאה גדולה לא תזיז את השער.

כיצד הצבירות נכנסות לדיווח?

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

נדבר על המשימה: אילו נתונים נדרשים להערכה ולהתחלה

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

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

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