מדוע חוזי vault נשברים במשיכת כספים
חוזי vault בנויים בפשטות: מפקיד מכניס נכס ומקבל נתח (share) שמתייקר או מוזל יחד עם שווי הפול. כל עוד הכל שקט, שער הנתח מחושב מחדש בכל הפקדה ומשיכה. הכשל במשיכה מתחיל כאשר חשבונאות הנתחים סוטה מהמצב בפועל של הנכסים.
תקן ERC-4626 מגדיר ממשק לאחסון נתחים, אך אינו מתאר מהיכן נלקח השער ברגע התשלום. שווי הפוזיציה נלקח מאורקל או מהערכה אחרונה ידועה, ולא מעובדת ביצוע העסקה. אם ההערכה גבוהה מדי, היוצא מקבל יותר מהמגיע לו, וההפרש משולם על ידי הנשארים.
השכבה השנייה — חוסר נזילות. הנכס פועל באסטרטגיה ולא מונח כיתרה חופשית, לכן משיכה גדולה אינה מבוצעת מיידית גם כשהשער נכון. האחסון או מחזיק חוצץ, או מותח את התשלום: חלק מוחזר מיד, והשאר ממתין להחזרת הכספים.
הקורבן הראשון הוא מפקיד גדול שיוצא ראשון. הוא מרוקן את החוצץ עד תום, חוטף החלקה על פער השער ומתחיל תור למשיכה. תור ללא עדיפויות וללא מועדים הופך עבור האחרים לנכס קפוא.
אנו מפרקים כיצד זה נסגר באופן קונסטרוקטיבי: חישוב שער לפי עובדת הביצוע, מגבלה על משיכה מיידית, חוצץ נזילות ותור עם סדר צפוי.
מה נותנת ארכיטקטורה נכונה של אחסון נזילות
שער ההמרה של הנתח הוא נגזרת של חשבונאות הנכסים והנתחים שהונפקו, ולא של יתרת הטוקנים בכתובת האחסון. אם לחשב אותו לפי יתרת ה'גולמית', כל העברה חיצונית תזיז את מחיר הנתח ותפחית מערכם של הפקדות שאר המשתתפים.
ב-ERC-4626 סוג שגיאות זה סגור באופן נוקשה: ההמרה מעוגלת לטובת האחסון, הנפקת נתחים מתבצעת רק באמצעות הפקדת כספים עם בדיקת הסכום שהתקבל בפועל, והעברה ישירה של טוקנים לחוזה אינה משנה את השער.
עמידות בפני משיכה המונית מתוכננת מראש לפני ההשקה: חלק מההון מוחזק בצורה נזילה, האסטרטגיות מפוזרות לפי מועדי פירעון, ומגבלות המשיכה מוגדרות כחלק מהנפח הכולל.
יציאה גדולה נסגרת אז מהחוצץ, ולא באמצעות פריקה חירום של כל הפוזיציות עם הפסדים על החלקה וקריסת שער הנתח עבור אלה שנשארו באחסון.
כשלים מדורגים — קו הגנה נפרד. האסטרטגיות מבודדות ומוגבלות במגבלות על המקור, לכן נפילה של אחת מהן לא גוררת את האחרות, ונתוני מחיר לא מהימנים אינם פותחים חלון לארביטראז'. כאשר שער ההמרה של הנתח חורג מהמחושב, מופעל עצירת פעולות: האחסון מפסיק לקבל הפקדות חדשות עד שהסיבה נבדקת.
בסך הכל, ארכיטקטורת האחסון מספקת את מה שנבדק על סטנד לפני העלאה לרשת הראשית: פער בין השער המחושב לשער הנתח בפועל — בגבולות שגיאת עיגול, יציאת המפקיד הגדול ביותר נכנסת לחוצץ הנזילות, וכשל של מקור תשואה חיצוני אינו חורג מגבולות האסטרטגיה שלו.
פורמטים של מימוש חוזי vault ומגבלותיהם
פורמט חוזה vault מגדיר שלושה דברים: כיצד מחושב מחיר הנתח, מי ומתי יכול להיכנס או לצאת, ומה יצטרכו לשנות בעת החלפת אסטרטגיה. להלן האפשרויות שביניהן צוותים באמת בוחרים, והמחיר שלהן בתמיכה ובתאימות.
| אפשרות | מתי מתאימה | מגבלות |
|---|---|---|
| תקן נתחים ממוטבעים | נדרשת תאימות עם פאנלים חיצוניים, אגרגטורים של תשואה ומערכות חשבונאות 'מהקופסה' | מקבע את המתמטיקה של הנפקה ופדיון נתחים: תורי משיכה, מגבלות הפקדה ועמלות מדורגות לא משתלבים בממשק כזה |
| פולים מבודדים | מספר אסטרטגיות עם פרופיל סיכון שונה, וכשל של פול אחד לא אמור לפגוע באחרים | יקר יותר לתחזוקה: יותר חוזים ומשטחים לבדיקה, הנזילות מתפצלת בין הפולים |
| לוגיקת חשבונאות משלך | כללים לא סטנדרטיים: משיכה דחויה, חישוב נתח לפי מקור מחיר חיצוני, מגבלות על משתתף | תאימות עם צרכנים חיצוניים נתמכת ידנית, וכל שינוי כללים — בדיקה מחדש וביקורת |
לעתים קרובות יותר נתקלים בגרסה משולבת: ממשק סטנדרטי מבחוץ, תוכן פנימי משלך. צרכנים חיצוניים קוראים לחוזה כאחסון רגיל, ומגבלות המשיכה ומקורות המחיר נשארים בשליטתכם. קבעו מראש אילו פונקציות ממשק אתם מתחייבים לא לשנות — אחרת האינטגרציות נשברות בעדכון הלוגיקה הראשון.
שלבי פיתוח והטמעה של אחסון נכסים
לא ניתן להתחיל את הפיתוח של חוזה vault מהקוד: מחיר הטעות בחשבונאות הנתחים — פער בין יתרת האחסון לנכסים בפועל, שצף כבר בכסף אמיתי ואי אפשר להחזיר לאחור. לכן המסלול נבנה מהמצב הנוכחי לתפעול, ובכל שלב נשאר ארטיפקט שהלקוח יכול לבדוק.
- ניתוח הסכימה הנוכחית: היכן מונחים הנכסים, מי מנהל את הנפקת ופדיון הנתחים, כיצד מחושב שווים.
- תכנון סכימת הנתחים: הצמדת הנתח לפול, סדר חלוקת התשלומים, טיפול בעיגולים במשיכה חלקית.
- הגדרת הרשאות: ניהול אסטרטגיה, שינוי פרמטרים ועצירת חירום — במפתחות שונים, ללא נקודת כשל אחת.
- בדיקה על מודלי התנהגות: הפקדה ומשיכה חדות, ירידת ערך, השהיה וחידוש פעולת האחסון.
- בדיקות וסקירה פנימית: מקרי קצה — הפקדה ראשונה לאחסון ריק, משיכת כל הפוזיציה, החלפת אסטרטגיה.
- ביקורת חיצונית ותיקונים: דוח עם סיווג הערות, תיקונים ובדיקה חוזרת של מסלולים קריטיים.
- מסירה לתפעול: תקנון עדכונים, הפרדת תפקידים, ניטור יתרות ונוהל פעולה בסטיות.
בסיום הלקוח מקבל לא רק חוזה, אלא גם נוהל עבודה: כיצד לעדכן פרמטרים, למי נגישות פעולות בנכסים, ולפי אילו מדדים רואים שהאחסון פועל כשורה. נדון במשימה שלכם — נחזור עם הערכת שלבים ותוכנית עבודה.
מה הצוות מקבל לידיו לאחר ההטמעה
אנחנו מוסרים לא תיקייה עם קבצים, אלא ערכה שלפיה משמרת תורנית ומהנדס חדש עובדים בלעדינו. הכל מקושר לתצורה אמיתית: כתובות ברשת, מגבלות שהוגדרו, תפקידים, ספי ניטור — מה שאי אפשר לשחזר מהזיכרון.
- תרשים זרימות כספים: מהיכן מגיעות הפקדות, כיצד נספרים נתחי ERC-4626, לפי איזו לוגיקה מחושבות המשיכות, היכן הנקודות שמהן הכספים לא ייצאו ללא אישור שני.
- תיעוד האחסון: ייעוד כל חוזה, פרמטרים מתעדכנים וגבולותיהם המותרים, סדר הוצאת גרסה חדשה ללא אובדן מצב.
- מטריצת תפקידים: מי מנפיק, מי משהה פעולות, מי משנה פרמטרים, אילו פעולות דורשות מספר חתימות.
- מערך בדיקות בעת שינויים: בדיקות אינווריאנטיות על התכנסות נתחים ונכסים, הרצת תרחיש משיכה בחוסר נזילות, דוח על פערים לפני שחרור.
- תקנון תגובה: מה נחשב לאירוע, מי מעלה את התורן, תוך כמה זמן נרשמת החלטה — מהשהיה ועד חידוש.
- הוראות שחזור: החזרה מדורגת לגרסה קודמת, ניתוח פעולות תקועות, בדיקת התכנסות המצב לאחר החזרה.
- מפת ניטור: ספים והתראות לפי שיעור הנכסים, סטייה מהתנהגות צפויה ותדירות משיכות.
מקרה בוחן: סגרנו משיכת כספים מאחסון נזילות
הפרויקט הגיע אלינו עם סימפטום, לא עם אבחנה: אחסון נזילות מבוסס ERC-4626 תחת עומס לא נתן כספים לכולם. חלק מהמפקידים קיבלו סירוב למשיכה, העסקה נכשלה בבדיקת היתרה, ובלוח הבקרה 'נתקעו' נתחים שלא הומרו חזרה. התור גדל מהר יותר מההפקדות: עם יציאת מחזיק גדול, אלה שאחריו חיכו לזמן בלתי מוגבל.
האבחון הראה שחשבונאות הנתחים חושבה מהיתרה השוטפת של החוזה, ולא ממשתנה פנימי. כל העברה ישירה של טוקנים לכתובת האחסון שינתה את מחיר הנתח, העיגולים בהמרה עבדו לטובת המפקיד, והפרדת הרשאות לא הייתה כלל — כל הפעולות נוהלו במפתח אחד. המשיכה לא הייתה שבורה, היא סירבה באופן צפוי עם גידול במספר הפעולות.
חשבונאות הנתחים עובדה מחדש: יתרה פנימית במקום קריאה חיצונית, עיגול תמיד לכיוון הגנת האחסון, נתחים וירטואליים מזיזים את מחיר הכניסה — מניפולציה על היתרה מפסיקה להשפיע על שער ההמרה.
ההרשאות הופרדו לפי תפקידים: בנפרד הנפקת נתחים, בנפרד מגבלות והשהיה, המשיכה מוגבלת בתקרה ניתנת להגדרה לפעולה ולתקופה.
מדדים לפני ואחרי: שיעור המשיכות המוצלחות — מ-88% ל-100% בעסקה אחת, התור למשיכה נעלם, הזמן מהבקשה ועד הזיכוי הצטמצם משעות לאישור אחד. בדיקות אינווריאנטיות על שמירת סכום הנתחים ותרחישי מניפולציה על השער סגרו מחלקת כשלים שבעבר שוחזרה רק ברשת חיה.
במה שונה אחסון נתחים מפול טוקנים רגיל?
פול טוקנים רגיל מחזיק יתרה משותפת: ההפקדה של כל משתתף היא רשומה נפרדת, ומחירה בטוקנים אינו קבוע בשום מקום. כדי להבין כמה תקבלו בחזרה, יש לחזור על נוסחת החלוקה — בקריאה לפונקציית חישוב או בהעתקה משלכם. אחסון נתחים בנוי אחרת: ההפקדה הופכת לטוקן נתח לפי שער, והזכות לנכסים חיה בטוקן עצמו.
התקן ERC-4626 מקבע חשבונאות זו: הפקדה, הנפקה, משיכה, פדיון ופונקציות חישוב מקדים, שלפיהן חוזה חיצוני יודע מראש את תוצאת הפעולה. ההבדלים בחשבונאות גוררים גם הרשאות ניהול. בפול יש בדרך כלל מערך מנהלי אחד: השהיה, פרמטרים, משיכת כספים. באחסון התפקידים מופרדים — מנהל האסטרטגיה אינו מקבל הרשאה לכתוב מחדש את יתרת הנתחים.
| אפשרות | מתי מתאימה | מגבלות |
|---|---|---|
| פול טוקנים רגיל | מוצר אחד, אסטרטגיה אחת, אין צרכנים חיצוניים | מחיר הנתח אינו מבוטא בטוקן: כל אינטגרטור כותב חישוב משלו וטועה בעיגולים |
| אחסון נתחים | מספר אסטרטגיות או צרכנים חיצוניים: אגרגטורים, גזברות, דיווח | נדרשת משמעת בעיגול והגנה על שער הנתח בהפקדה הראשונה |
ההבדל ניכר גם במשיכה. באחסון נתחים אתם שורפים נתח ומקבלים נכסים לפי שער מקדים, העיגול תמיד לטובת האחסון, והמפקיד הראשון לא יכול לנפח את השער בתרומה. בפול רגיל השער לעתים קרובות נק בעת העסקה — ומזיזים אותו בהלוואה בעסקה אחת. הפול פשוט יותר כשהמוצר אחד; האחסון משתלם כשמופיע צרכן חשבונאות שני.
ספקות טכניים: גישה, עדכונים, ביקורת
שאלות מגיעות בדרך כלל לא לפני ההתחלה, אלא אחרי הפריסה הראשונה: החוזה כבר מחזיק כספים, וכל שינוי לוגיקה נראה כמו סיכון לאבד את המצב. להלן תשובות קצרות למה ששואלים הכי הרבה בשלב הזה.
יש לנו אחסון פרוס כבר — להתחיל מאפס?
לא. תחילה עורכים מלאי של מה שעובד: כתובות חוזים והתלויות שלהם, פריסת האחסון, תפקידים, מקורות מחיר חיצוניים, נפח וחלוקת הכספים. אחר כך מחליטים מה משאירים כפי שהוא, מה עוטפים בשכבת לוגיקה חדשה, ומה מעבירים — עם תוכנית החזרה בכל שלב.
האם ניתן לעדכן לוגיקה בלי להעביר פוזיציות?
כן, אם האחסון בנוי לפי סכימת פרוקסי: חוזה המימוש החדש יורש את אותה פריסה, והכתובת והיתרות נשארות כשהיו. לפני ההעלאה משווים את פריסת האחסון ומריצים את העדכון על עותק של הרשת — אז החלפת כתובת המימוש אינה הופכת להעברה ידנית של שאריות.
מה נשאר בידי המנהל?
התפקידים מופרדים: השהיה, החלפת פרמטרים ומשיכת עמלה — הרשאות שונות. קריאות קריטיות עוברות דרך חתימה מרובה עם השהיה לביצוע, כדי שהמשתתפים יספיקו לראות את השינוי ולצאת. מפתח יחיד שמסיר מגבלות בבת אחת אינו קיים בסכימה כזו.
מה כלול בדוח הסיכונים?
כל ממצא עם רמת קריטיות, תרחיש ניצול ותיקון קונקרטי בקוד. בנפרד — הנחות שנבדקו, ומה שנשאר מחוץ לגבולות הבדיקה: הרשאות מנהל, תלות במקורות מחיר חיצוניים, התנהגות בתנועת שוק חדה.
נדון במשימה ונחזור עם הערכה ותוכנית
לצורך הערכה ותוכנית עבודה אנו זקוקים לנתוני קלט, ולא לרצונות כלליים. לגבי חוזי vault הסט קומפקטי, אבל דווקא הוא קובע היכן בתקן של אחסון ממוטבע נוצרים פערי שער נתח, חסימות משיכה וסיכוני עיגול.
- תרחישי משיכה: מי ומתי פודה נתחים, האם יש תור למשיכה, מגבלות על נפח לתקופה וכללי טיפול בבקשות גדולות.
- סכימת חשבונאות נוכחית: כיצד מחושב שער הנתח, היכן מצטברות עמלות והכנסה שנצברה, מה קורה להפקדה ברגע החיוב.
- הרשאות ותפקידים: רשימת תפקידים מנהליים, מי משנה פרמטרים, אסטרטגיית חלוקת נכסים וכתובות אחסון חיצוניות.
- היסטוריית שינויים: גישה למאגר, סכימת שחרורים, האם היו עדכונים דרך חוזה פרוקסי וכיצד נפתרה תאימות אחסון הנתונים.
- תנאי תפעול: רשת, אופן שליחת עסקאות, התראות על אירועים, למי יש הרשאה לעצירת חוזה חירום.
- בדיקות ודוחות ביקורת: כיסוי ענפי משיכה ומקרי קצה, הערות פתוחות מבדיקות קודמות.
עם סט זה אנו חוזרים עם הערכה ותוכנית הטמעה: שלבים, סדר עבודות, נקודות בדיקה ברשת בדיקות והרכב קבלה. ניתן לדון במשימה גם עם נתונים חלקיים — לפי החסרים מיד ייראה מה לסגור קודם.