פיתוח כספות אסטרטגיה מאובטחות (ERC-4626) במפתח

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

שירותי פיתוח בלוקצ'יין

שאלות נפוצות

העבודות האחרונות

  • פיתוח אפליקציית ווב עבור FEEDME
    פיתוח אפליקציית ווב עבור FEEDME
    1376
  • פיתוח חנות מקוונת לחברת FURNORO
    פיתוח חנות מקוונת לחברת FURNORO
    1350
  • עיצוב לוגו לחברת B2B Advance
    עיצוב לוגו לחברת B2B Advance
    798
  • פיתוח אפליקציית ווב עבור Enviok
    פיתוח אפליקציית ווב עבור Enviok
    1088
  • פיתוח לוגו חברת AIDER
    פיתוח לוגו חברת AIDER
    1034
  • פיתוח CRM עבור Chasseurs
    פיתוח CRM עבור Chasseurs
    1130

פיתוח vault: היכן נשברת הלוגיקה של אסטרטגיית תשואה

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

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

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

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

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

מה נותנת כספת אסטרטגיות מנוהלת

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

זמן משיכת הכספים

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

עמידות בתנודתיות

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

רישום החלקים ושקיפות

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

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

מודלים של כספות: פרוטוקול פתוח או מעגל סגור

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

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

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

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

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

כיצד מתנהלת פיתוח vault: שלבי העבודה ההנדסית

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

מביקורת ועד העברת הניהול

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

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

תוצרי הפרויקט: קונפיגורציות, תפקידים ונהלים

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

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

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

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

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

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

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

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

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

במה strategy vault נבדל ממאגר נזילות רגיל

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

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

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

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

הרשאות גישה, עדכון האסטרטגיה ותרחישי חירום

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

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

כיצד מועברים מפתחות הניהול?

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

האם אפשר לעדכן את הלוגיקה בלי למשוך כספים?

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

מה קורה אם מקור המחיר אינו זמין?

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

כיצד בנויה עצירת החירום?

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

מה להכין כדי שנחזור עם הערכה ותוכנית

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

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

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