פיתוח מאגרי נזילות להימורים מבוססי בלוקצ'יין

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

פרוטוקולים כמו Azuro בונים תשתית בדיוק מסוג זה: ספק מוסיף USDC למאגר, הימורים נעשים מול המאגר הזה, והסיכויים מתעדכנים דינמית בהתאם לנפחים ולחשיפה הנוכחית. במשך יותר מ-5 שנים, פיתחנו יותר מ-30 פתרונות בלוקצ'יין, כולל מוצרי הימורים עבור Polygon ו-Arbitrum.

הבעיה המרכזית: ניהול חשיפה

חוסר איזון בהימורים

אם 90% מההימורים הולכים לצד אחד של אירוע (למשל, ריאל מדריד מנצחת בדרבי), המאגר נושא סיכון כיווני גדול. תוצאה אחת — ספקי נזילות מפסידים חלק משמעותי מהמאגר; השנייה — הם מרוויחים.

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

function calculateOdds(
    uint256 eventId,
    uint8 outcomeId
) public view returns (uint256 odds) {
    ExposureData memory data = exposures[eventId];
    uint256 totalPool = data.lpLiquidity;
    uint256 sideExposure = data.outcomeExposure[outcomeId];
    // Чем выше exposure на сторону, тем ниже odds
    uint256 adjustedPool = totalPool - sideExposure * MARGIN_FACTOR / 1e18;
    odds = (adjustedPool * 1e18) / (adjustedPool - sideExposure);
}

מערכות ייצור משתמשות במודלים מורכבים יותר המתחשבים באירועים מתואמים (מספר משחקים בטורניר), עומק נזילות, ו-oracle של עושי שוק לסיכויים ראשוניים.

איך להגן על המאגר ממניפולציות? Oracle לתוצאות

זוהי הנקודה הפגיעה ביותר בכל פרוטוקול הימורים. מי קובע את תוצאת המשחק? Oracle מרכזי הוא נקודת כשל יחידה. פגיעה ב-oracle = ניקוז כל הנזילות. אנו משתמשים בהגנה רב-שכבתית:

במערכות ייצור, השילוב האופטימלי הוא: פתרון אוטומטי דרך Chainlink לתוצאות ברורות, Kleros למקרים שנויים במחלוקת. גישה זו מפחיתה את הסבירות למניפולציה ב-95%.

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

מבנה מאגר הנזילות

המאגר דומה ל-LP של Uniswap, אבל עם הבדלים:

• אסימון LP מייצג חלק (בדומה לאסימון LP של AMM)
• הנזילות נעולה למשך האירועים הפעילים
• במקרה של משיכה המונית — תור משיכה

struct LiquidityPool {
    uint256 totalLiquidity; // USDC в пуле
    uint256 lockedLiquidity; // заблокировано для покрытия открытых ставок
    uint256 totalShares; // LP-токены
    mapping(address => uint256) shares;
}

function addLiquidity(uint256 amount) external {
    // shares рассчитываются пропорционально текущей стоимости пула
    uint256 newShares = totalShares == 0 ? amount : amount * totalShares / totalLiquidity;
    // ...
}

function calculateOdds( uint256 eventId, uint8 outcomeId ) public view returns (uint256 odds) { ExposureData memory data = exposures[eventId]; uint256 totalPool = data.lpLiquidity; uint256 sideExposure = data.outcomeExposure[outcomeId]; // Чем выше exposure на сторону, тем ниже odds uint256 adjustedPool = totalPool - sideExposure * MARGIN_FACTOR / 1e18; odds = (adjustedPool * 1e18) / (adjustedPool - sideExposure); } — התשלום המקסימלי האפשרי עבור כל ההימורים הפתוחים. ספקי נזילות לא יכולים למשוך נזילות מתחת לסף הזה. זהו אינווריאנט בטיחותי: המאגר חייב תמיד להיות מסוגל לכסות הימורים נוכחיים.

הימורים כ-NFT או כסחירים?

שתי גישות: הימור כ-ERC-721 NFT (ייחודי, ניתן לסחר בשוק משני) או כרשומה במיפוי חוזה. ERC-721 פותח אפשרות לשוק הימורים — משתמש יכול למכור הימור מנצח לפני סיום האירוע. זה מספק נזילות נוספת למשתמשים והכנסה נוספת לפרוטוקול (עמלה על מסחר משני). Azuro משתמשת בגישה זו דרך הימורי ERC-721. חסרונות: גז מעט גבוה יותר ליצירת הימור (~50k גז לעומת ~30k למיפוי), קשה יותר לביקורת.

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

כל פרויקט כולל:

• תיעוד ארכיטקטוני (דיאגרמות זרימה, אבטחה)
• פיתוח חוזים חכמים וביקורת (Foundry + Slither)
• אינטגרציה של Chainlink או oracles אחרים
• הגדרה ובדיקת לוגיקת מאגר הנזילות
• פריסה ב-testnet וב-mainnet
• תיעוד למשלבים ולמשתמשים
• 3 חודשי תמיכה לאחר השקה

כלכלה עבור ספקי נזילות

תשואת LP = מרווח הפלטפורמה - תשלומים עבור הימורים מנצחים. עם מרווח של 5% והימורים מאוזנים, ספקי נזילות מרוויחים 5-8% APY בתוספת תשואה נוספת מנזילות פנויה (staking של USDC ב-Aave בזמן שאירועים פתוחים). סיכון: בסדרה של תוצאות הפתעה גדולות — ספקי נזילות מפסידים. קרן ביטוח מחלק מהעמלות מרככת חלקית את ההפסדים. כדי להפחית סיכון, אנו ממליצים לפצל מאגרים לפי ספורט ולהגביל חשיפה לכל אירוע.

למה לבחור בנו?

20+ מהנדסים בצוות, 5 שנות פיתוח בלוקצ'יין, 30+ dApps שהושקו. אנו מספקים ערבות אבטחה על חוזים (אימות פורמלי לפי בקשה). צרו קשר — נבחן את הפרויקט שלכם ונציע ארכיטקטורת turnkey.

לוחות זמנים משוערים

מאגר בסיסי עם סיכויים קבועים ו-oracle מרכזי — בין 1 ל-2 שבועות. פרוטוקול מלא עם סיכויים דינמיים, Chainlink, אסימוני LP, ושוק הימורים משני — בין 6 ל-10 שבועות. העלות מחושבת באופן אישי לאחר דיון בארכיטקטורה ובמקורות הנתונים.