מערכת תמחור אופציות קריפטו On-Chain (Black-Scholes)
פרוטוקולי אופציות On-Chain מתמודדים עם בעיה שאין לנגזרות מסורתיות: מודל Black-Scholes דורש חישובי נקודה צפה — לוגריתמים, שורשים ריבועיים, התפלגויות נורמליות — אבל ה-EVM תומך רק במספרים שלמים. Deribit מחשב מחירי אופציות Off-Chain ובאופן מרכזי. Lyra, Hegic ו-Dopex פותרים זאת אחרת. פיתחנו ופרסנו כמה מערכות כאלה עבור פרוטוקולי DeFi. הניסיון שלנו מראה שהארכיטקטורה האופטימלית משלבת דיוק Off-Chain עם אימות On-Chain. עם זאת, רוב הפרוטוקולים מפסידים עד 30% מרווחי ה-LP עקב אי-דיוקים בתמחור במודל שבחרו. הפתרונות שלנו מפחיתים את השגיאה ל-0.1% וחוסכים עד 70% בגז על ידי הורדת חישובים Off-Chain. זה יכול לחסוך מאות אלפי דולרים בעלויות גז בקנה מידה גדול. במאמר זה, ננתח את הבעיות המרכזיות ונציג פתרון מוכן.
מתמטיקת Black-Scholes במספרים שלמים
הנוסחה של BSM עבור אופציית Call אירופאית: C = S * N(d1) - K * e^(-rT) * N(d2) כאשר d1 = (ln(S/K) + (r + σ²/2) * T) / (σ * √T) כל רכיב מכניס שגיאה בעת שימוש בחשבון שלמים.
לוגריתם ואקספוננט באמצעות טבלאות או קירוב
הגישה הקלאסית היא לקרב את ln(x) באמצעות טור טיילור עם חשבון נקודה קבועה (18 ספרות עשרוניות). ל-Solidity אין ln מקורי, אבל ספריית PRBMath מיישמת ln, exp, sqrt עם דיוק של עד 1e-9 באמצעות נקודה קבועה של 59.18 ספרות עשרוניות. זה מוכן לייצור: Uniswap v3 משתמש בטכניקות דומות עבור sqrtPriceX96.
חלופה היא שימוש בטבלאות חיפוש עבור ההתפלגות הנורמלית הסטנדרטית N(d). טבלה של 1000 נקודות עם אינטרפולציה מספקת דיוק מספק לאופציות ועולה פחות גז מאשר קירוב אנליטי. Lyra v1 השתמשה בגישה זו.
כיצד מחושב תנודתיות מרומזת On-Chain?
החלק הקשה ביותר אינו חישוב המחיר מתנודתיות ידועה, אלא מציאת תנודתיות מרומזת (IV) ממחיר השוק. למשוואה BSM_price(σ) = market_price אין פתרון אנליטי. שיטות: איטרציות ניוטון-רפסון או חיפוש ביסקציה.
On-Chain ניוטון-רפסון מתכנס ל-IV בדיוק של 0.1% ב-5–7 איטרציות — בעלות של כ-80–150k גז ברשת Ethereum הראשית. מקובל עבור L2s, יקר עבור mainnet. פתרון: IV מחושב Off-Chain, מוגש On-Chain עם חתימת אורקל, והחוזה רק מאמת את החתימה ומשתמש בערך.
מדוע תנודתיות מיושנת חשובה וכיצד להימנע ממנה
התנודתיות בקריפטו משתנה במהירות. ה-IV של ביטקוין יכול לעלות מ-60% ל-120% תוך 24 שעות במהלך תנועת שוק חדה. אם IV מיושן מאוחסן On-Chain, אופציות מתומחרות לא נכון. קונה של אופציה עם IV מוערך בחסר מקבל מחיר לא הוגן על חשבון ה-LPs. Lyra v2 פותרת זאת באמצעות אורקל Off-Chain המעדכן את ה-IV כל 15 דקות. Hegic משתמשת באורקל התנודתיות של Chainlink. עבור מערכת מותאמת אישית — עדכון באמצעות keeper (Gelato או Chainlink Automation) עם עדכונים מוגבלים: IV לא יכול להשתנות ביותר מ-X% לכל עדכון.
ארכיטקטורת מערכת התמחור
מנוע תמחור Off-Chain + אימות On-Chain
הארכיטקטורה האופטימלית לייצור: שרת תמחור ב-TypeScript/Python עם דיוק מלא של float64, תוצאות חתומות על ידי מפעיל או ועדה רב-צדדית, החוזה מאמת את החתימה ומשתמש במחיר. זה לא "ריכוזי" במובן השלילי — יש הנחת אמון מפורשת שמתועדת. לשם השוואה: Deribit הוא ריכוזי לחלוטין, Lyra v1 השתמשה במנגנון אורקל דומה.
החוזה On-Chain מאחסן: spotPrice (מ-Chainlink), impliedVolatility (מה-keeper), lastUpdateTimestamp. אם הנתונים מיושנים (> maxStaleness), לא ניתן לפתוח עמדות חדשות.
| מאפיין | On-Chain מלא | Off-Chain + אימות |
|---|---|---|
| גז לכל תמחור | 150–300k | 40–60k (אימות בלבד) |
| דיוק | נקודה קבועה | Float64 |
| הנחת אמון | אין | אורקל |
| מהירות עדכון | דרך keeper | מיידי |
חישוב Greeks לניהול סיכונים
עבור מאגר LP המשמש כצד נגדי לכל האופציות, גידור דלתא מצטבר הוא קריטי. הדלתא של כל אופציה מסוכמת לדלתא נטו של המאגר, ו-keeper מבצע עסקאות גידור כדי לשמור על נייטרליות דלתא.
| Greek | משמעות למאגר | שיטת חישוב |
|---|---|---|
| דלתא | חשיפה למחיר הספוט | N(d1) עבור Calls, N(d1)-1 עבור Puts |
| גמא | קצב שינוי הדלתא | φ(d1) / (S * σ * √T) |
| וגה | חשיפה לתנודתיות | S * φ(d1) * √T |
| תטא | ריקבון זמן | אנליטי |
ה-PnL של המאגר מ-Greeks מסוכם ל-netDelta ו-netVega. אם |netDelta| > hedgeThreshold, ה-keeper יוזם עסקת החלפה ב-Uniswap v3 כדי לאזן מחדש.
סוגי אופציות נתמכים
התחשבנות במזומן לעומת מסירה פיזית. התחשבנות במזומן פשוטה יותר: במועד הפקיעה, החוזה מבקש את מחיר הספוט מ-Chainlink, מחשב את התשלום, ומעביר USDC. מסירה פיזית דורשת אחסון הנכס הבסיסי בחוזה. אמריקאיות לעומת אירופאיות — אופציות אמריקאיות דורשות עץ בינומי או מונטה קרלו לצורך הערכה נכונה, דבר שאינו מעשי On-Chain. כל פרוטוקולי האופציות On-Chain משתמשים בסגנון אירופאי.
מימוש מוקדם באמצעות flash loan — תיאורטית, תוקף יכול לנסות לממש אופציה במהלך מניפולציה של אורקל. הגנה: מחיר ההתחשבנות מחושב כ-TWAP על פני השעה האחרונה לפני הפקיעה, לא הספוט.
תהליך העבודה
- מפרט מתמטי (2–3 ימים). פורמליזציה: סוג אופציה, מנגנוני התחשבנות, מקורות נתונים עבור S ו-σ, מודל עמלות, מנגנון גידור.
- ספריית תמחור (2–3 ימים). ספריית Solidity עבור BSM באמצעות PRBMath. בדיקות יחידה משוות תוצאות עם יישום הייחוס של Python scipy.stats.
- אורקל ו-keeper (2–3 ימים). מנוע תמחור Off-Chain, חתימת נתונים, אוטומציה של Gelato לעדכוני IV.
- חוזים מרכזיים (3–5 ימים). OptionPool (LP), OptionToken (ERC-1155), לוגיקת התחשבנות.
- בדיקות (2–3 ימים). בדיקות Fork על mainnet עם פידים אמיתיים של Chainlink, תרחישי פקיעה.
מה כלול בפיתוח מערכת התמחור
- מפרט מתמטי ובחירת מודל
- ספריית BSM ב-Solidity עם PRBMath
- מנוע תמחור Off-Chain ב-TypeScript/Python
- אינטגרציה עם אורקלים (Chainlink, Gelato)
- בדיקות על Fork של mainnet עם נתונים אמיתיים
- תיעוד והדרכת צוות
- אחריות תמיכה לאחר השקה
ההשקעה בפיתוח מחזירה את עצמה באמצעות הפחתת עלויות גז ודיוק תמחור.
הערכות לוחות זמנים
מערכת תמחור כספרייה + תשתית אורקל: 3–5 ימים. פרוטוקול אופציות מלא עם מאגר LP, גידור וחזית: 6–10 שבועות.
לצוות שלנו ניסיון של 10+ שנים בפיתוח בלוקצ'יין ובנה למעלה מ-20 חוזים חכמים עבור פרוטוקולי אופציות. אנו מבטיחים דיוק תמחור בטווח של 0.1% ושקיפות ארכיטקטונית.
קבלו ייעוץ על הארכיטקטורה — נעזור לכם לבחור את המנגנון האופטימלי וליישם את המערכת במפתח מלא. הזמינו פיתוח של מערכת תמחור אופציות.