הצוות שלך פרס מאגר נזילות עם נוסחת מוצר קבוע x*y=k. הכל עבד ברשת הבדיקות. ברשת הראשית, שלושה ימים לאחר ההשקה, בוט סנדוויץ' הוציא 180,000$ מהמאגר — מחיר כניסה 12% מעל המחיר האמיתי, מחיר יציאה 11% מתחת. אין בקרת החלקה ברמת החוזה, רק אימות בצד הפרונטאנד. זהו סיפור טיפוסי: מפתחים מעתיקים מכניקת AMM מבלי להבין כיצד תשתית ה-MEV של Ethereum פועלת. צור קשר כדי להימנע מהפסדים כאלה — אנו מתמחים בהגנה על מאגרי נזילות.
בעיות בחוזי AMM בעת פריסה
הפסד בלתי-קבוע כהחלטה ארכיטקטונית, לא באג
הפסד בלתי-קבוע (IL) אינו באג אלא תוצאה מתמטית של איזון מחדש. פרוטוקולים שלא מסבירים את המתמטיקה האמיתית לספקי נזילות מאבדים נזילות: אנשים רואים תשואה שנתית של 40%, מושכים אחרי חודש, ולא מבינים למה הם בהפסד במונחי דולר. תפקיד החוזה הוא לספק נתונים מדויקים על הפוזיציה: ערך נוכחי, עמלות שנצברו, והפסד בלתי-קבוע משוער.
ב-Uniswap v3, זה מסובך יותר בגלל נזילות מרוכזת: פוזיציה פעילה רק בטווח [tickLower, tickUpper]. כשהמחיר יוצא מהטווח, הפוזיציה מפסיקה לצבור עמלות ומומרת לחלוטין לטוקן אחד. ספק נזילות ללא ניטור יכול להחזיק פוזיציה מתה במשך שבועות.
מניפולציית מחיר באמצעות הלוואות פלאש באורקלים ממקור יחיד
מאגר AMM שמשמש בעצמו כאורקל מחירים הוא וקטור התקפה. הלוואת פלאש, עסקת החלפה אחת — מחיר הספוט במאגר זז פי 10. אם פרוטוקול ההלוואות שלך קורא את המחיר מהמאגר הזה, הוא מנפיק הלוואות נגד בטחונות מנופלים. זה קרה ל-Mango Markets (הפסד של 114 מיליון דולר). פתרון: TWAP דרך אורקל Uniswap v3 — IUniswapV3Pool.observe() עם חלון תצפית מינימלי של 30 דקות. או Chainlink כאורקל חיצוני עם מפסק חשמל: אם הספוט ו-Chainlink חורגים ביותר מ-5%, העסקה נדחית.
Reentrancy במכניקת Callback
Uniswap v2/v3 משתמש בתבנית callback: uniswapV2Call ו-uniswapV3SwapCallback. אם המאגר שלך מיישם מכניקה דומה ואינו שם nonReentrant על הפונקציה שמפעילה את ה-callback — וקטור קלאסי. בפועל, נתקלנו בחוזה מאגר עם פונקציית swap שעדכנה את reserve0 ו-reserve1 לאחר קריאה ל-_callback. Reentrancy אפשרה לקבל טוקנים פעמיים על קלט אחד. ReentrancyGuard נדרש על swap, addLiquidity, removeLiquidity — כל השלוש.
למה אורקל TWAP הוא חובה למאגר
ללא TWAP, המאגר פגיע להתקפות הלוואת פלאש. על ידי שימוש בחלון תצפית קצר, אנו מחליקים מניפולציות. בפרויקטים עם TVL גבוה, אנו מוסיפים גיבוי ל-Chainlink כדי להגביר את האמינות.
איך להפחית סיכון הפסד בלתי-קבוע לספקי נזילות
אנו מטמיעים חישוב הפסד בלתי-קבוע בזמן אמת בחוזה ומספקים נתונים דרך פונקציות view. במאגרים מרוכזים, אנו מוסיפים איזון אוטומטי של פוזיציות דרך בוטים של keeper כדי למנוע שהייה ממושכת מחוץ לטווח. זה מפחית הפסדים לספקי נזילות.
איך אנו בונים מאגרי נזילות
החלטות ארכיטקטוניות
לרוב המשימות, אין צורך לכתוב AMM מאפס. פרוטוקולי Uniswap v2/v3, Balancer, Curve הם קוד מנוסה בקרב עם מיליארדי דולרים ב-TVL. המשימה היא לבחור את המכניקה הנכונה לכלכלת הטוקן:
| מכניקה | מתאימה ל | דוגמה |
|---|---|---|
| x*y=k (Uniswap v2) | מקרה כללי, שני טוקנים | כל זוג ERC-20 |
| נזילות מרוכזת (Uniswap v3) | מטבעות יציבים, נכסים מתואמים | USDC/USDT, ETH/stETH |
| StableSwap (Curve) | מטבעות יציבים עם החלקה מינימלית | 3pool, FRAX |
| מאגרים משוקללים (Balancer) | 2-8 טוקנים עם משקלים מותאמים | 80/20 WETH/TOKEN |
| CPMM עם עמלות מותאמות | מאגרי פרוטוקול עם חלוקת עמלות | DEX מותאם אישית |
אם המשימה היא מאגר מותאם אישית לפרוטוקול ספציפי, אנו מבססים אותו על Uniswap v4 Hooks (אם הרשת תומכת בכך) או על ארכיטקטורת Balancer v2 Vault, שבה Vault משותף מחזיק טוקנים ומאגרים מכילים רק לוגיקה.
טוקני LP וחשבונאות פוזיציות
תקן ERC-20 לטוקני LP ב-Uniswap v2 הוא המקרה הפשוט ביותר. חלק במאגר = lpBalance / lpTotalSupply. בעיה: עם ספקי נזילות רבים, כל transfer של טוקני LP משנה חלקים יחסיים מבלי להודיע למשתתפים אחרים. לפוזיציות בסגנון Uniswap v3, אנו משתמשים ב-NFT (ERC-721) — כל פוזיציה ייחודית לפי טיקים וגודל. זה מסבך אינטגרציה אך מספק חשבונאות מדויקת. עמלות נצברות דרך feeGrowthInside0LastX128 — דורש חשבון לא-בדוק עם הערות מפורשות.
הגנת MEV ברמת החוזה
- השתמש ב-commit-reveal לעסקאות גדולות: המשתמש מפרסם hash, ואז אחרי N בלוקים העסקה בפועל. בוטים לא יודעים פרמטרים מראש.
- השתמש בעמלות דינמיות: העמלה עולה בתנודתיות גבוהה (מזוהה דרך סטייה מ-TWAP). מיושם דרך Uniswap v4 Hook או שכבת עמלה מותאמת.
- המלץ על mempool פרטי (Flashbots Protect, MEV Blocker) — פתרון תשתיתי, אנו מזהירים את הלקוח לפני פריסה.
מה כלול בפיתוח מאגר נזילות
| שלב | משך | תוצאה |
|---|---|---|
| מפרט | 2-3 ימים | מסמך עם מכניקת מאגר, כלכלת טוקן, מבנה עמלות, תפקידים |
| פיתוח | 1-6 שבועות | חוזים ב-Solidity 0.8.x עם Foundry, בדיקות fuzz |
| בדיקות Fork | 3-5 ימים | בדיקות על fork של הרשת הראשית עם מחירים אמיתיים |
| ביקורת | 1-2 שבועות | Slither פנימי + אופציונלי חיצוני |
| פריסה | 1-2 ימים | סקריפט Forge, אימות, multisig, timelock |
נוסף: אינטגרציית פרונטאנד (ethers.js, wagmi), ניטור פוזיציות, הדרכת צוות הלקוח.
מדדי הניסיון שלנו
ה-TVL הכולל של המאגרים שפיתחנו עולה על 100 מיליון דולר. 5+ שנים ב-DeFi, 30+ פרויקטי חוזים חכמים. אנו עובדים עם מבקרים מוסמכים מ-Code4rena ו-Sherlock. בפרויקט אחד, אופטימיזציית חוזה הפחיתה עלויות גז ב-40%, וחסכה ללקוח 50,000$ בשנה.
תהליך הפיתוח
מפרט (2-3 ימים). הגדרת מכניקת מאגר, כלכלת טוקן LP, מבנה עמלות, תפקידים (בעלים, גובה עמלות, שומר השעיה). ציור דיאגרמת מצבים: כל מעברי מצב המאגר, כולל השעיית חירום.
פיתוח (1-2 שבועות). חוזים ב-Solidity 0.8.x עם Foundry. בדיקות fuzz על אינווריאנטים: reserve0 * reserve1 >= k אף פעם לא מופר, סכום כל חלקי LP שווה ל-totalSupply, עמלות לא עולות על נפח ההחלפה.
בדיקות Fork. בדיקות על fork של הרשת הראשית/Arbitrum — מחירים אמיתיים, טוקנים אמיתיים, בוטי MEV אמיתיים ב-mempool. השתמש ב-vm.createFork ב-Foundry.
ביקורת פנימית + Slither. לפחות שבוע לפני פריסה. ל-TVL >500,000$, אנו ממליצים על ביקורת חיצונית (Code4rena, Sherlock, Spearbit).
פריסה. forge script עם אימות, Gnosis Safe multisig על פונקציות בעלים, timelock על שינויי פרמטרי עמלות (מינימום 48 שעות).
הערכות זמנים
מאגר בסיסי x*y=k עם טוקני LP ERC-20 — משבועיים עם בדיקות. מאגר נזילות מרוכזת (בסגנון Uniswap v3) — משישה שבועות. מכניקה מותאמת אישית עם טוקנים מרובים, אינטגרציית אורקל חיצוני, וחלוקת עמלות — 2-3 חודשים. זמן ביקורת לא כלול.
קבל ייעוץ על בחירת ארכיטקטורת מאגר — צור קשר להערכה חינמית של הפרויקט שלך.