פיתוח Vault נייטרלי לדלתא: ארכיטקטורה, איזון מחדש, אופטימיזציה

פעם בנינו vault שהבטיח 20% APY ללא קשר לכיוון השוק. מתחת למכסה המנוע: ETH ארוך ב-Aave, ETH שורט ב-GMX, וגביית הכנסה משיעור המימון. כאשר ETH זינק ב-40% בשבוע, ה-perp השורט דרש מרווח נוסף. ה-vault ביצע איזון מחדש אוטומטי על ידי מכירת חלק מהפוזיציה הארוכה כדי לכסות את קריאת המרווח. לאחר מספר איזונים מחדש, ה-vault סטה ממצב נייטרלי לדלתא (ויקיפדיה), צבר הטיה כיוונית, ותיקון של 15% פגע בפוזיציה פי שניים. זו לא הייתה באג—זה היה אלגוריתם איזון מחדש מכוון בצורה גרועה. הניסיון שלנו מראה שארכיטקטורה נכונה מונעת תרחישים כאלה. אם אתה מתמודד עם מצב דומה, קבל ייעוץ בשלב מוקדם.

למה קשה לשמור על נייטרליות לדלתא

דלתא ב-vaults של DeFi מודדת את רגישות ערך הפורטפוליו לשינוי במחיר נכס הבסיס. דלתא = 0 פירושו: ETH עולה ב-10% או יורד ב-10%—ערך ה-vault נשאר ללא שינוי (לפני עמלות).

מבחינה טכנית, נייטרליות לדלתא נראית פשוטה: קנה 1 ETH ספוט (דלתא = +1) ושורט 1 ETH חוזים עתידיים (דלתא = -1). סכום הדלתא = 0. הבעיה היא שדלתא הפורטפוליו נסחפת כל הזמן בגלל:

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

vault אמיתי דורש ניטור דלתא רציף ואיזון מחדש תקופתי כדי לחזור לנייטרליות.

ארכיטקטורה של Vault נייטרלי לדלתא

מקורות תשואה

התשואה של vault נייטרלי לדלתא מגיעה ממספר מקורות בו-זמנית:

האסטרטגיה העמידה ביותר משלבת מספר מקורות. תצורה קלאסית: stETH ארוך (תשואת סטייקינג ~4%) + ETH שורט ב-GMX v2 או Synthetix (הכנסה משיעור מימון בשוק שורי). כאשר המימון הופך לשלילי (שוק דובי), עבור רק לתשואת הפקדת Aave.

ארכיטקטורת חוזה חכם

ה-vault בנוי על תקן ERC-4626 עם מודולים נוספים:

• HedgeManager—מנהל את פוזיציית ה-perp. קורא את דלתא ה-vault הנוכחית, מחשב את גודל השורט הנדרש, קורא לפתיחה/סגירה ב-perp DEX. מפשט את פרוטוקול ה-perp הספציפי מאחורי ממשק, ומאפשר מעבר בין GMX ו-dYdX ללא שינוי בלוגיקת ה-vault.
• RebalanceEngine—מחליט מתי לבצע איזון מחדש. פרמטר מפתח: deltaTolerance (לדוגמה, ±5%). כל עוד דלתא ה-vault המוחלטת נשארת בטווח [-5%, +5%] מה-NAV, אין צורך באיזון מחדש. מחוץ לטווח זה מופעל איזון מחדש.
• YieldAccumulator—אוסף תשואה מכל המקורות (תשלומי מימון, תגמולי סטייקינג, עמלות LP), ממיר ליחידה אחת, ומשקיע מחדש.
• OracleModule—מאגד הזנות מחיר של Chainlink עם TWAP לחישוב דלתא. קריטי להשתמש באותו מקור מחיר לשני צידי הגידור, אחרת הבדלי אורקל יוצרים דלתא פנטום.

אלגוריתם איזון מחדש

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

גישה טובה יותר: היברידית של סף + טיימר:

function shouldRebalance() public view returns (bool) { int256 currentDelta = calculateDelta(); uint256 deltaDriftPercent = abs(currentDelta) * 10000 / totalNAV; bool thresholdBreached = deltaDriftPercent > DELTA_TOLERANCE; // 500 = 5% bool timerExpired = block.timestamp > lastRebalance + REBALANCE_INTERVAL; // 24h return thresholdBreached || (timerExpired && deltaDriftPercent > MIN_REBALANCE_DRIFT); } 

איזון מחדש לפי סף בסטייה קריטית, איזון מחדש לפי טיימר לסחיפה מצטברת. זה מפחית את תדירות האיזון מחדש ב-70–80% בהשוואה לניטור קבוע, מה שהופך את האיזון מחדש ליעיל פי 3 תוך חיתוך עלויות גז. לדוגמה, vault שהוציא בעבר $3,000 לחודש על גז לאיזון מחדש מוציא כעת רק $800—חיסכון של 73%.

ניהול מרווח בפוזיציות Perp

הנקודה המסוכנת ביותר היא חיסול ה-perp השורט במהלך עלייה חדה. אם ה-vault מחזיק 10 ETH stETH ארוך ו-10 ETH perp שורט, עלייה של 50% ב-ETH פירושה הפסד לא ממומש על השורט = 5 ETH. עם מרווח תחזוקה = 5%, אתה צריך לפחות 0.5 ETH מרווח לכל 10 ETH נומינלי. בתנועה חדה, זה עשוי לא להספיק. מניעת הפסדים של עד $1M דורשת מנגנוני הגנה נכונים.

מנגנוני הגנה:

• מרווח דינמי: גודל המרווח אינו קבוע אלא פרופורציונלי לפוזיציה הנוכחית ולתנודתיות הצפויה (דרך תנודתיות היסטורית של 30 יום). כאשר התנודתיות עולה, המרווח מתווסף אוטומטית מרזרבות ה-vault.
• יחס גידור חלקי: אל תגדר 100% דלתא. גידור של 80% שומר על דלתא חיובית קטנה, ומפחית לחץ מרווח במהלך עליות. פשרה: ה-vault מתאם חלש חיובית לעליות נכס.
• מינוף חירום: אם יחס המרווח יורד מתחת ל-function shouldRebalance() public view returns (bool) { int256 currentDelta = calculateDelta(); uint256 deltaDriftPercent = abs(currentDelta) * 10000 / totalNAV; bool thresholdBreached = deltaDriftPercent > DELTA_TOLERANCE; // 500 = 5% bool timerExpired = block.timestamp > lastRebalance + REBALANCE_INTERVAL; // 24h return thresholdBreached || (timerExpired && deltaDriftPercent > MIN_REBALANCE_DRIFT); } , סגור אוטומטית חלק מהפוזיציה הארוכה כדי למלא את המרווח, גם במחיר של נייטרליות דלתא. הגנה מחיסול מקבלת עדיפות על טוהר הגידור.

השוואת פרוטוקולי Perp ל-Vaults

כלי בדיקה לאחור: Python + CCXT לנתוני perp היסטוריים, Dune Analytics לתשואת סטייקינג על השרשרת ושיעורי Aave.

תהליך הפיתוח שלנו

מה אנחנו מספקים

• תיעוד ארכיטקטורה ומפרט
• פיתוח ERC-4626 vault, HedgeManager, RebalanceEngine
• אינטגרציה עם פרוטוקול ה-perp הנבחר ופרוטוקול ההלוואות
• כתיבת בדיקות (fork, fuzz, אינווריאנטים) עם כיסוי >95%
• ביקורת חיצונית (חובה, עם דוח)
• פריסה דרך Gnosis Safe עם timelock
• הגדרת Chainlink Automation לאוטומציה של איזון מחדש
• תת-גרף The Graph למדדי vault
• הכשרת צוות ותיעוד תפעולי
• תמיכה של 3 חודשים לאחר פריסה

שלבים ולוח זמנים

1. אנליטיקה (5–7 ימים): בחירת אסטרטגיה, בדיקה לאחור, הגדרת deltaTolerance, תדירות איזון מחדש, חיץ מרווח.
2. פיתוח חוזה חכם (4–6 שבועות): קידוד מודולים ואינטגרציות.
3. בדיקות (2–3 שבועות): בדיקות fork של mainnet עם תרחישי שוק שונים, בדיקות fuzz אינווריאנטים.
4. ביקורת חיצונית (חובה): 1–2 שבועות תלוי בנפח הקוד.
5. פריסה וניטור: שבוע אחד.

vault MVP עם אסטרטגיה אחת (stETH + GMX שורט על Ethereum) לוקח 6–8 שבועות. vault מלא עם ריבוי אסטרטגיות, איזון מחדש אוטומטי, וממשל לוקח 2–4 חודשים כולל ביקורת. העלות מחושבת באופן אישי.

5+ שנים ב-DeFi | 50+ פרוטוקולים שפותחו | $100M+ TVL מאובטח

אנחנו צוות עם 5 שנות ניסיון ב-DeFi, שפיתחנו מעל 50 פרוטוקולים. אנו מבטיחים איכות והשלמת ביקורת מוצלחת. הזמינו פיתוח vault עם הארכיטקטורה הנכונה. צרו קשר לייעוץ והערכת פרויקט.