פיתוח פרוטוקול אופציות On-Chain: ממפרט לפריסה

בואו נתחיל במקרה אמיתי: פרוטוקול Hegic הפסיד 4.7 מיליון דולר עקב שגיאה בחישוב הפרמיה—חלוקת מספרים שלמים ב-Solidity עם סדר פעולות שגוי הביאה לעלות אפסית של אופציה תחת פרמטרים מסוימים. משתמשים קיבלו אופציות בחינם. זו לא פגיעות תיאורטית—זה קורה כשמתמטיקה פיננסית מועברת ל-EVM ללא בדיקות גבול יסודיות.

פיתוח פרוטוקול אופציות על בלוקצ'יין דורש התייחסות קפדנית למודל התמחור, ניהול נזילות ומנגנוני סילוק. כל רכיב הוא וקטור סיכון נפרד, ואנחנו ממזערים אותם באמצעות שילוב של גישות מוכחות ובדיקות מעמיקות. אנחנו עובדים עם L2s מובילות (Arbitrum, Optimism, Base) להפחתת עלויות גז, ומשתמשים בטכנולוגיות מודרניות: Foundry לבדיקות, Chainlink לאורקלים, OpenZeppelin לאבטחה. הניסיון שלנו כולל פיתוח אופציות אירופאיות קלאסיות וגם אמריקאיות מורכבות עם סילוק אוטומטי באמצעות Gelato.

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

מהן ההחלטות הארכיטקטוניות המרכזיות?

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

OptionsFactory
├── OptionsPool (per asset, per expiry)
│   ├── PricingEngine (Black-Scholes approximation)
│   ├── CollateralVault (locked LP funds)
│   └── SettlementModule
├── OracleAdapter (Chainlink + TWAP fallback)
└── FeeCollector

OptionsFactory מפעיל OptionsPool חדש לכל זוג נכס/תאריך פקיעה או מנהל מאגר יחיד עם מיפוי לפי סדרות. מאגר יחיד עם מיפוי קל יותר לביקורת אך יוצר סיכון בין-סדרתי. OracleAdapter הוא מעטפת עם מפסק חשמלי: אם הסטייה של Chainlink > שעה או החריגה > 10% מ-TWAP, המסחר מושהה.

עד כמה מורכב תמחור אופציות על השרשרת?

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

Black-Scholes דורש תנודתיות מרומזת (IV). על הבלוקצ'יין יש שתי אפשרויות: לקבוע IV קבוע (פשוט אך לא מדויק) או לקבל אותו מאורקל (מורכב אך כן). Dopex משתמש ב-Chainlink ל-IV. פרוטוקול Lyra יישם תנודתיות מחוץ לשרשרת עם אימות על השרשרת באמצעות החזקת SNX. Hegic v888 קבע IV קבוע לכל נכס, המעודכן על ידי ממשל.

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

נוסחת הפרמיה ב-Solidity דורשת חשבון נקודה קבועה. ספריית ABDKMath64x64 מספקת דיוק של 64.64 סיביות המספיק למתמטיקת אופציות. uint256 טהור עם קנה מידה של 1e18 עובד אך דורש בקרת גלישה זהירה—אנו משתמשים ב-mulDiv מ-OpenZeppelin במקום פעולות ישירות. אפשרויות אופטימיזציית הגז שלנו יכולות להפחית עלויות בעד 20%.

סוגי סילוק: אירופאי מול אמריקאי

הסגנון האירופאי פשוט יותר: סילוק בעסקה אחת—השוואת מחיר הספוט במועד הפקיעה למחיר המימוש, ותשלום ההפרש. בעיה: מחיר הספוט במועד הפקיעה ניתן למניפולציה. הלוואת פלאש של 10 מיליון דולר לא מזיזה את הספוט של Chainlink עקב אגרגציה עם עיכוב, אך TWAP ממאגר AMM פגיע. הסגנון האמריקאי מורכב משמעותית יותר—נדרש מנגנון keeper (Gelato או Chainlink Automation) למימוש אוטומטי של אופציות ITM.

מודלי נזילות

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

לעמית-למאגר, חישוב דרישות הבטחונות הוא קריטי. אופציות Call מכוסות על ידי הנכס הבסיסי (או שווה ערך מזומן). אופציות Put—stablecoin במחיר מימוש * כמות. חוסר בטחונות הוא וקטור התקפה דרך תנועת מחיר מהירה ועיכוב בפירוק, מה שהוביל להפסדים העולים על 10 מיליון דולר.

השוואת פרוטוקולים

Greeks וניהול סיכונים

גידור דלתא/גאמה מלא על השרשרת אינו כלכלי בעלויות הגז הנוכחיות. Lyra v2 משתמש ב-market maker מחוץ לשרשרת עם סילוק על השרשרת: ה-MM מנהל את ה-Greeks מחוץ לשרשרת, ומסנכרן מעת לעת את הפוזיציה עם המאגר. Dopex הציג SSOV (Single Staking Option Vaults)—מחירי מימוש קבועים ותקופות פקיעה, מה שמפשט את ניהול הנזילות.

לפרוטוקול שלנו: מגבלת open interest (OI) לכל מחיר מימוש ותאריך פקיעה באמצעות הפרמטרים maxCallsOI ו-maxPutsOI. מגבלה אופיינית—500 ETH למחיר מימוש (כ-1.5 מיליון דולר במחירים נוכחיים).

בדיקות ואבטחה

Foundry מריץ בדיקות פי 10 מהר יותר מ-Truffle, מה שחיוני לבדיקות fuzz עם אלפי מקרים. בדיקות fuzz מכסות:

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

בדיקות fork על mainnet: קניית אופציה, מניפולציה של TWAP של Uniswap באמצעות החלפה גדולה, ניסיון לממש במחיר המנופל—הפרוטוקול חייב להשתמש ב-Chainlink או לחזור. ביקורת חיצונית חובה (Trail of Bits, Spearbit)—פרוטוקולי אופציות נמצאים בחמישייה הראשונה בגובה ההפסדים בפריצות DeFi. עלויות הביקורת נעות בדרך כלל בין 50,000 ל-150,000 דולר.

סקירת תהליך

1. מפרט (3-5 ימים). סוג אופציה, סגנון נזילות, נכסים נתמכים, מנגנוני פקיעה, ממשל.
2. עיצוב (שבוע). מבנה אחסון, ממשקים, מתמטיקת תמחור מאומתת מול ייחוס Python.
3. פיתוח (4-6 שבועות). חוזים + בדיקות (יחידה, fuzz, fork). מודול מנוע תמחור נפרד הניתן לשדרוג באמצעות UUPS.
4. ביקורת (2-4 שבועות). פנימית + חיצונית. אין פריסה ל-mainnet ללא ביקורת.
5. פריסה וניטור. בוטים של Forta לניטור נפח חריג, Tenderly להתראות על אירועים על השרשרת.

מה כלול (תוצרים)

התוצרים שלנו כוללים:

• תיעוד מלא של חוזים חכמים עם דוגמאות אינטראקציה
• כיסוי בדיקות >95% (יחידה, fuzz, fork)
• הוראות פריסה והפעלה
• תמיכה בשלבי הבדיקות וההשקה
• אפשרות לביקורת המשך עם שותפים מאומתים
• גישה למאגר GitHub פרטי עם כל הקוד
• מפגש הדרכה לצוות שלכם (שעתיים)
• תמיכה לאחר ההשקה למשך חודש

הערכות זמן ועלות

פרוטוקול מינימלי (נכס יחיד, סגנון אירופאי, IV קבוע)—6-8 שבועות פיתוח ללא ביקורת, החל מ-50,000 דולר. פרוטוקול מלא עם נכסים מרובים—2-3 חודשים, בעלות של 100,000–250,000 דולר. ציר הזמן של הביקורת הוא תוספת של 2-4 שבועות (30,000–80,000 דולר). תהליך הפיתוח המאופטימלי שלנו יכול לחסוך לכם עד 30% בעלויות הביקורת בהשוואה למתחרים. עלויות הפיתוח מתחילות ב-50,000 דולר.

// Example of premium calculation
function calculatePremium(uint256 amount, uint256 strike, uint256 expiry) public view returns (uint256) {
    // Simplified example
    return amount * strike * block.timestamp / expiry;
}