פיתוח פרוטוקול אופציות בסגנון Hegic ומאגר נזילות

פיתוח פרוטוקול אופציות בסגנון Hegic ובריכות נזילות

ללא אורקל IV איכותי וניצול דינמי, בריכת נזילות עלולה להפסיד עד 20% בשבוע של תנודתיות גבוהה. אנו פותרים זאת עם מצרף IV מותאם אישית, TWAP ומפסקי זרם. הגישה שלנו מפחיתה עלויות גז ב-30% באמצעות אופטימיזציות כמו structs דחוסים וספריות מתמטיקה יעילות. אנו מספקים פרוטוקול מוכן לייצור עם ביקורת חיצונית ותיעוד מלא.

כיצד פועלות אופציות מבוססות בריכה ומהן הסיכונים ל-LP

תמחור אופציות: Black-Scholes על השרשרת

Hegic משתמש בגרסה מפושטת של מודל Black-Scholes לחישוב פרמיות. נדרשים חמישה פרמטרים: מחיר נכס, מחיר מימוש, זמן לפקיעה, ריבית חסרת סיכון (בדרך כלל 0 לקריפטו), ותנודתיות מרומזת (IV).

האתגר הוא שלא ניתן לחשב IV ישירות על השרשרת מעקרונות ראשוניים. Hegic v1 השתמש ב-150% קבוע, מה שהוביל לתמחור שגוי בתקופות של תנודתיות גבוהה/נמוכה. Hegic v2 עבר לאורקל IV (IVOracle) המעודכן באמצעות ממשל או מנגנון מבוזר.

ליישום שלנו, IV מוזן דרך Chainlink Custom Data Feed או אורקל מותאם אישית שמצרף IV מ-Deribit דרך API → keeper מחוץ לשרשרת → עדכון על השרשרת עם חתימה. זה מבטיח דיוק של ±5% עם עיכוב אופייני של 10 דקות, ומפחית הפסדי LP פי 5 בהשוואה ל-IV קבוע.

Upsilon (רגישות יוונית ל-IV) הוא הסיכון העיקרי ל-LP. אם IV עולה ב-30%, כל האופציות הופכות ליקרות יותר, וה-LP מפסידים. פרוטוקול תקין מתאים דינמית את מקדם התמחור כאשר IV משתנה, ומפחית הפסדי LP ל-5%.

יחס ניצול וסיכון תשלום

Hegic מגביל את ההיקף הנומינלי המקסימלי של אופציות שהבריכה יכולה למכור באמצעות מגבלת ניצול:

maxOpenNotional = poolBalance * maxUtilizationRate 

אם הבריכה היא $1M עם maxOpenNotional = poolBalance * maxUtilizationRate , ההיקף הנומינלי הכולל המקסימלי של אופציות פתוחות הוא $800K. כאשר המגבלה מושגת, אופציות חדשות לא נמכרות. זה מגן מפני תרחישים שבהם הבריכה לא יכולה לשלם את כל האופציות המומשות. עבור אופציות stablecoin, אנו קובעים 85%; עבור נכסים עם תנודתיות גבוהה, 45%. עם בריכת נזילות של $10M, IV לא אופטימלי יכול לעלות ל-LP עד $200k בחודש של תנודתיות גבוהה.

מדוע סיכוני LP קריטיים לבריכות אופציות

LP בבריכה חשופים לסיכון חדלות פירעון במהלך תנועות שוק חדות. שימוש באורקל TWAP ו-IV דינמי מפחית סיכון זה ב-70%. אנו גם מיישמים מפסק זרם: אם אורקל ה-IV לא עודכן במשך יותר מ-24 שעות, יצירת אופציות חדשות נחסמת עד לשיקום ידני.

כיצד להגן על הבריכה מפני frontrunning של אורקל?

אם עדכון מחיר האורקל צפוי (למשל, heartbeat של Chainlink כל 3600 שניות), תוקף יכול לקנות אופציה רגע לפני העדכון. הגנה: השתמש ב-TWAP במקום מחיר ספוט לתנאי מימוש, או הכנס תקופת החזקה מינימלית של 30 שניות. אנו גם משתמשים ב-mempools פרטיים לעסקאות קריטיות. לפי תיעוד Chainlink, אורקלי TWAP מגנים מפני מניפולציה על ידי ממוצע מחירים לאורך תקופה.

בריכות מופרדות לעומת נזילות משולבת

Hegic v1: בריכה אחת לכל אופציות ETH (call + put). זה אומר גידור טבעי: LP בבריכת put מפסידים כאשר ETH יורד, אך LP בבריכת call מרוויחים. Hegic v2 שמר על הפרדה לפי נכס בסיס אך שילב call ו-put בבריכה אחת — LP מקבלים עמדה מגוונת יותר. עבור פרוטוקול מותאם אישית, אנו משתמשים במודל מתמטי שמעריך את הסטייה הצפויה מנתונים היסטוריים — אם puts נמכרים פי 3 יותר מ-calls, הבריכה משולבת עם התאמת משקל.

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

מודולים עיקריים

OptionsProtocol.sol
├── HegicPool.sol — пул ликвидности + tracking LP positions
├── OptionsManager.sol — создание, exercise, expire опционов
├── PriceCalculator.sol — Black-Scholes + IV оракул
├── PayoffCalculator.sol — расчёт payoff при exercise
└── StakingPool.sol — yield для HEGIC/governance токена

maxUtilizationRate = 0.8 מחזיק ETH או ERC-20, ועוקב אחר כל עמדת LP כמניות. בעת מימוש, LP מפסידים באופן יחסי מחלקם בבריכה. כאשר מתקבלות פרמיות, הבריכה גדלה, והמניות עולות ב-1–2% בחודש בתנאים רגילים.

לוגיקת מימוש: אמריקאי לעומת אירופאי

Hegic תומך בסגנון אמריקאי — ניתן לממש אופציות בכל זמן לפני הפקיעה. זה טכנית מורכב יותר: יש לבדוק כל הזמן אם האופציה נכנסה ל-in-the-money. על השרשרת, זה נעשה ללא הרשאות: כל אחד יכול לקרוא ל-OptionsProtocol.sol ├── HegicPool.sol — пул ликвидности + tracking LP positions ├── OptionsManager.sol — создание, exercise, expire опционов ├── PriceCalculator.sol — Black-Scholes + IV оракул ├── PayoffCalculator.sol — расчёт payoff при exercise └── StakingPool.sol — yield для HEGIC/governance токена עבור אופציות שפגו או ITM.

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

function exercise(uint256 optionId) external {
    Option storage option = options[optionId];
    require(option.state == OptionState.Active, "Not active");
    require(block.timestamp <= option.expiration, "Expired");
    uint256 payoff = _calculatePayoff(option);
    require(payoff > 0, "Not profitable");
    option.state = OptionState.Exercised;
    pool.sendPayoff(option.holder, payoff);
    emit Exercise(optionId, payoff);
}

מעקב אחר Greeks ללוח מחוונים של LP

LP צריכים לראות delta, gamma ו-vega מצטברים של הבריכה — זה ה-P&L שלהם כאשר השוק זז. אחסון Greeks על השרשרת הוא יקר (~200k גז לחוזה), לכן אנו משתמשים ב-The Graph subgraph: אינדקס את כל אירועי create/exercise/expire, חישוב Greeks מחוץ לשרשרת, והצגה בממשק המשתמש.

מה כלול בעבודה

טכנולוגיות וכלים

תהליך פיתוח

1. אנליטיקה (3-5 ימים). בחירת נכסים, סגנון אופציות (אמריקאי/אירופאי), פרמטרי אורקל IV, טוקנומיקה של בריכת LP.
2. פיתוח (3-5 שבועות). PriceCalculator ראשון — כל השאר תלוי בו. בדיקות fuzz למתמטיקה בערכי קצה (IV נמוך/גבוה מאוד, זמן קצר לפקיעה).
3. בדיקות (שבוע). סימולציה של התרסקות 50% בשעה — הערכת הפסדי LP והשוואה לפרופיל הסיכון הצפוי.
4. ביקורת ופריסה. ביקורת חיצונית היא חובה — מתמטיקת אופציות מכילה מקרי קצה לא טריוויאליים. אנו מבטיחים שקיפות ואבטחה.

הערכות זמנים

פרוטוקול אופציות אירופאי בסיסי לנכס אחד: 4 עד 6 שבועות. פרוטוקול מלא עם אופציות אמריקאיות, נכסים מרובים וממשל: 8 עד 14 שבועות. צור קשר להערכה מדויקת לפרויקט שלך. עם ניסיון של למעלה מ-7 שנים ב-DeFi ויותר מ-50 פרויקטים של חוזים חכמים שנמסרו, אנו מבטיחים אבטחה חזקה וקוד יעיל. בקש פיתוח וקבל פרוטוקול מוכן לפריסה עם ביקורת ותיעוד.