פיתוח מערכות נזילות לשווקי תחזיות על Ethereum ו-L2

ספרד של 12% והחלקה של כמה אחוזים הופכים שווקי תחזיות לחסרי תועלת עבור סוחרים. כאן נשבר ה-UX: משתמשים לא מוכנים לשלם עמלה כזו עבור אי-ודאות. אנו מפתחים מערכות נזילות שהופכות שווקים לעמוקים גם לפני שמופיע עניין אורגני. הגישה שלנו משלבת Fixed Product AMM, conditional tokens, ותמריצי LP דינמיים. כתוצאה מכך, אפילו שוק נישתי יכול למשוך נפחים של עד $500k ללא החלקה. כל חוזה עובר ביקורת עבור reentrancy והפצת תוצאות נכונה, מה שמבטיח את בטיחות כספי ה-LP.

איך AMM עובד עבור שווקי תחזיות

LMSR והמגבלות שלו

LMSR (Logarithmic Market Scoring Rule) הוא היסטורית ה-AMM הראשון לשווקי תחזיות. מחירי התוצאות מחושבים כ-p_i = e^(q_i/b) / sum(e^(q_j/b)), כאשר q_i הוא מספר המניות של תוצאה i, ו-b הוא פרמטר הנזילות. יתרון: market maker מובטח מתמטית — השוק תמיד נזיל. חיסרון: הפסדים בלתי מוגבלים ל-market maker בתנועות קיצוניות.

CPMM מאוחר יותר (Constant Product, כמו ב-Uniswap v2) משמש ב-Polymarket: עבור שוק בינארי YES_shares * NO_shares = k. מחיר YES = NO_shares / (YES_shares + NO_shares). יישום פשוט יותר, הפסדים מוגבלים. CPMM יעיל פי 3 בגז מאשר LMSR עבור שווקים בינאריים.

Conditional Tokens (ERC-1155)

התקן המודרני לשווקי תחזיות הוא Gnosis Conditional Tokens Framework. כל תוצאת אירוע היא token ERC-1155 נפרד. בטחון (למשל, USDC) ננעל בחוזה ConditionalTokens. כאשר התנאי נפתר (resolveCondition()), מחזיקי token של תוצאה מנצחת יכולים לפדות בטחון ביחס 1:1. זה מאפשר בניית שווקים מורכבים: שילובים של תוצאות ממספר תנאים עצמאיים — "שווקי AND". לדוגמה, פוזיציה "ETH > $5000 ו-BTC > $100k עד דצמבר" היא חיתוך של שני conditional tokens.

ארכיטקטורת אספקת נזילות

יצירת שוק אוטומטי באמצעות Fixed Product AMM

עבור כל שוק, נפרס מאגר נזילות המבוסס על Fixed Product AMM (FPMM). LPs מפקידים כמויות שוות של כל התוצאות (עבור שווקים בינאריים — tokens של YES ו-NO). מחיר תוצאה ראשוני = 50/50.

החוזה FPMMFactory יוצר מופע FPMM עבור כל שוק:

function create(
    address conditionalTokens,
    address collateralToken,
    bytes32[] memory conditionIds,
    uint[] memory outcomeSlotCounts,
    uint fee // basis points
) external returns (address fpmm)

העמלה הולכת לספקי הנזילות — התמריץ שלהם. אבל עמלות משווקי תחזיות בדרך כלל נמוכות (0.1-2%), והסיכון עבור LPs משמעותי: LPs מחזיקים פוזיציות בתוצאות עד לפתרון. אם השוק הופך לחד-צדדי מאוד, LPs צוברים הרבה tokens מפסידים שעלולים להפוך לחסרי ערך.

מנגנוני תמריץ עבור LPs

הגישה הפשוטה ביותר היא liquidity mining: תגמולים נוספים ב-token של הפרוטוקול עבור LPs. אבל זה זמני; לאחר סיום הכרייה, הנזילות עוזבת.

גישה בת-קיימא יותר היא עמלה דינמית: עמלות גבוהות יותר על שווקים עם נזילות נמוכה, נמוכות יותר על שווקים תחרותיים מאוד. יישום: עמלה = function create( address conditionalTokens, address collateralToken, bytes32[] memory conditionIds, uint[] memory outcomeSlotCounts, uint fee // basis points ) external returns (address fpmm) , כאשר base_fee + liquidity_adjustment פרופורציונלי הפוך לעומק המאגר. לדוגמה, מאגר עם TVL של $2M מייצר $5000 בעמלות יומיות במחזור של 0.5%.

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

פתרון אורקל ומנגנון מחלוקת

החלק הרגיש ביותר הוא פתרון התוצאה. שתי גישות:

אורקל מרכזי. כתובת מדווחת מהימנה קוראת ל-liquidity_adjustment. מהיר אבל מרכזי. מקובל לשלב הראשוני עם מדווח multisig.

אורקל אופטימי (בסגנון UMA). מציע מציע תוצאה עם ערבות. חלון מחלוקת של 48-72 שעות. מתנגד יכול לערער עם ערבות. אם מערערים, זה הולך להצבעה דרך UMA DVM או Kleros. המפסיד מאבד את הערבות שלו. עמיד למניפולציה: עלות מחלוקת > רווח מפתרון שגוי.

Chainlink + Sports/Events API. עבור אירועי ספורט, Chainlink Any API עם מקורות מאומתים (ESPN, APIs ספורט רשמיים). הצהרתי, אוטומטי, ללא גורם אנושי. מגבלה: לא לכל האירועים יש APIs ציבוריים.

למה גז הוא צוואר בקבוק עבור שווקי תחזיות

שווקי תחזיות עם תוצאות רבות (>2) יוצרים בעיות גז. עבור אירוע עם 10 תוצאות (למשל, גביע העולם, 32 קבוצות), החלפת FPMM דורשת עדכון יתרות של כל 32 ה-tokens בעסקה אחת. זה O(n) פעולות SLOAD/SSTORE לכל עסקה.

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

עבור שווקים עם >5 תוצאות ב-Ethereum mainnet, זה כלכלית הגיוני יותר לפרוס על Polygon או Base. גז L2 מאפשר עבודה עם שווקים של 20-30 תוצאות ללא בעיות. השוואת עלויות גז:

תהליך הפיתוח

1. אנליטיקה (3-5 ימים). בחירת מכניקת AMM (FPMM לעומת LMSR לעומת מותאם אישית), אסטרטגיית אורקל, מודל תמריץ LP, רשת יעד.
2. חוזים (2-3 שבועות). הגדרת conditional tokens + מפעל FPMM + תמריצי LP + מתאמי אורקל. Foundry עם בדיקות מבוססות מאפיינים: "סכום ההסתברויות תמיד = 1", "פדיון לעולם אינו עולה על הבטחון".
3. אינטגרציית אורקל (שבוע). הגדרת Chainlink API או UMA optimistic oracle, מנגנון מחלוקת.
4. חזית (1-2 שבועות). אינטגרציית wagmi/viem, ממשק מסחר, הצגת הסתברויות, לוח מחוונים ל-LP.

מה כלול בעבודה שלנו:

• חוזים חכמים ב-Solidity (Foundry, בדיקות, ביקורת)
• אינטגרציה עם conditional tokens ו-FPMM
• הגדרת אורקל (Chainlink/UMA/מותאם אישית)
• פיתוח חזית לממשק מסחר ולוח מחוונים ל-LP
• פריסה על L2 (Polygon, Arbitrum) לחיסכון בגז
• תיעוד והדרכת צוות
• תמיכה טכנית לאחר ההשקה

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

פרוטוקול בסיסי לשווקים בינאריים עם אורקל מרכזי — 1-2 שבועות. מערכת מלאה עם אורקל אופטימי, תמריצי LP ותמיכה במספר תוצאות — מ-4-6 שבועות.

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