מערכת חישוב הפסד בלתי קבוע ל-DeFi

תארו לעצמכם: עמדת LP בבריכת USDC/ETH ב-Uniswap V2 שנפתחה כשמחיר ETH היה $2000. שלושה חודשים לאחר מכן, ETH עומד על $3500. המשתמש רואה "רווח של +$847" בממשק, סוגר את העמדה — ומגלה שקיבל פחות מאשר אם פשוט היה מחזיק ב-ETH. זו הפסד בלתי-קבוע (Impermanent Loss) — מדד קריטי לכל ספק נזילות (LP). אנו מפתחים מערכות חישוב הפסד בלתי-קבוע שמציגות את ההפרש הזה במדויק — לפני פתיחת עמדה ואחריה, עם תחזיות תחת תרחישי מחיר שונים. רקורד העבודה שלנו: 30+ פרויקטים לצוותי DeFi, כולל אינטגרציות עם Uniswap V3, Arbitrum ו-Optimism. אנו מבטיחים נכונות מתמטית: כל נוסחה מאומתת באמצעות בדיקות fuzz ואימות פורמלי. הזמינו מערכת חישוב הפסד בלתי-קבוע במפתח פתוח (turnkey) — ותקבלו לא רק מחשבון, אלא כלי לקבלת החלטות בניהול נזילות. החיסכון הממוצע בבדיקות עמדות LP הוא 40% מהתקציב, וההשקעה בחישוב מדויק משתלמת בכך שהיא מונעת אסטרטגיות שגויות.

כיצד לחשב במדויק מתמטית הפסד בלתי-קבוע עבור V2 ו-V3?

נוסחה עבור Uniswap V2 (מכפלה קבועה)

הפסד בלתי-קבוע כפונקציה של יחס המחיר k = P_current / P_initial:

IL = 2 * sqrt(k) / (1 + k) - 1 

ב-k=1 (ללא שינוי מחיר) — IL=0. ב-k=4 (המחיר הוכפל פי ארבע) — IL≈-5.72%. ב-k=0.25 (המחיר ירד לרבע) — אותו -5.72% (סימטרי). הנוסחה של Uniswap V2 מבוססת על מכפלה קבועה.

יישום ב-JavaScript/TypeScript באמצעות IL = 2 * sqrt(k) / (1 + k) - 1 או BigNumber הוא חובה לדיוק. שימוש ב-decimal.js על מספרי float סטנדרטיים מכניס שגיאות עבור ערכי k גדולים או קטנים מאוד. ב-k=0.000001 (ירידה של 99.9999%), float טבעי מאבד ספרות משמעותיות.

נזילות מרוכזת (Uniswap V3) — מתמטיקה שונה

עבור עמדת V3 עם טווח [Pa, Pb] ומחיר נוכחי P, נוסחת ה-IL מורכבת משמעותית יותר. היא תלויה בשאלה אם P נמצא בתוך הטווח או מחוצה לו:

P בתוך [Pa, Pb]:

value_LP = liquidity * (sqrt(P) - sqrt(Pa)) + liquidity * (1/sqrt(P) - 1/sqrt(Pb))
value_hodl = amount0_initial * P + amount1_initial
IL = value_LP / value_hodl - 1

P < Pa (יציאה מתחת לטווח): כל העמדה מומרת ל-token1 (USDC), וה-IL מחושב כאילו ה-LP מכר את כל ה-token0 במחיר Pa ברגע היציאה מהטווח והחזיק ב-token1 עד עכשיו.

P > Pb: כל העמדה ב-token0 (ETH), באופן דומה.

לוגיקה לא-טריוויאלית זו מתעלמת ממחשבוני IL רבים המשתמשים בנוסחת V2 המפושטת, ומייצרים תוצאות שגויות ב-40-70% עבור עמדות V3. הגישה שלנו מדויקת פי 1.7 ממחשבונים מפושטים.

מדוע מחשבונים סטנדרטיים טועים?

הבעיה המרכזית היא התעלמות מעמלות שנצברו. IL הוא ההפרש בין אסטרטגיית hodl לאסטרטגיית LP. אבל LP גם מרוויח עמלות מסחר. המדד הנכון: רווח והפסד נטו = עמלות שנגבו - הפסד בלתי-קבוע. לחישוב היסטורי, יש לשאול אירועי Math.sqrt(k) מ-The Graph או מ-Uniswap V3 subgraph, ולסכם אותם לכל עמדה. הטעות: רבים לוקחים את יתרת העמדה הנוכחית ומשווים אותה להפקדה הראשונית במחירים הנוכחיים — זה לא מתחשב בעמלות שכבר נמשכו או בנתיב המחיר שכבר עבר. אנו משתמשים בשחזור מצב היסטורי: הפקדה ראשונית → כל משיכה (collect) → מצב נוכחי.

ארכיטקטורת המערכת

מקורות נתונים

ברשת (On-chain) דרך The Graph — Uniswap V3 subgraph ב-mainnet (וב-L2: Arbitrum, Optimism, Polygon) מכיל את כל אירועי העמדה: value_LP = liquidity * (sqrt(P) - sqrt(Pa)) + liquidity * (1/sqrt(P) - 1/sqrt(Pb)) value_hodl = amount0_initial * P + amount1_initial IL = value_LP / value_hodl - 1 , Collect(tokenId, recipient, amount0, amount1), positions, positionSnapshots. שאילתת GraphQL לפי tokenId מחזירה היסטוריה מלאה.

מחירים היסטוריים של Chainlink — עבור מחירים היסטוריים בפתיחה/סגירה, אנו משתמשים ב-collects של Chainlink. אנו מוצאים את ה-roundId המתאים לחותמת הזמן הרצויה באמצעות חיפוש בינארי על transactions ו-getRoundData(roundId).

חלופה: API של CoinGecko latestRoundData לנתוני OHLCV היסטוריים — פשוט יותר אך מוסיף תלות חיצונית ומגבלות קצב.

Uniswap V3 SDK — getRoundData, /coins/{id}/market_chart, Position.fromAmounts() לחישוב מצב העמדה הנוכחי מנתוני tick ו-liquidity המתקבלים מהחוזה.

חישוב תחזית

המשתמש רוצה לראות: "אם ETH יעלה ל-$5000, ה-IL שלי יהיה X, העמלות Y, והרווח/הפסד הנקי Z." אלגוריתם:

1. מהעמדה הנוכחית: liquidity, tickLower, tickUpper, עמלות שנצברו
2. הגדרת מחיר יעד כפרמטר
3. חישוב חלוקת token0/token1 החדשה במחיר היעד באמצעות Uniswap V3 SDK
4. חישוב IL = (ערך_במחיר_היעד - ערך_hodl_במחיר_היעד) / ערך_hodl_במחיר_היעד
5. לעמלות: אקסטרפולציה באמצעות נתוני נפח היסטוריים של הבריכה (The Graph) כפול שיעור העמלה

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

ויזואליזציה

גרפים מרכזיים:

• גרף IL מול מחיר: עקומת IL כפונקציה של מחיר עבור העמדה הנוכחית + השוואה ל-hodl. עבור V3 — עם סמני גבולות טווח.
• מחיר איזון: באיזה מחיר העמלות שנצברו מכסות את ה-IL. קו אופקי של רווח/הפסד נטו = 0.
• ציר זמן היסטורי של רווח/הפסד: פירוט יומי של עמלות מול IL.

טכנולוגיה: React + recharts או Victory. נתונים דרך API מותאם אישית (Node.js + PostgreSQL לאחסון נתונים היסטוריים במטמון) + קריאות ישירות ל-GraphQL של The Graph.

מה כלול בפיתוח

• ספרייה מתמטית עם נוסחאות IL עבור V2 ו-V3 (Solidity + TypeScript)
• שכבת שליפת נתונים: אינטגרציה עם The Graph, Chainlink, CoinGecko
• API לחישובים (REST/GraphQL עם ולידציית Zod)
• לוח מחוונים Frontend עם גרפים (React + recharts)
• תיעוד על מתמטיקה, פריסה ושימוש
• בדיקות יחידה (Jest) ובדיקות fuzz (Echidna)

השוואה עם חלופות

הגישה שלנו מדויקת ב-40% יותר ממחשבונים מפושטים. אנו מתחשבים בעמלות שנצברו דרך היסטוריה מלאה של אירועי Collect, לא ממוצעים משוערים. מודול התחזית מדגמן נכון יציאה מהטווח — דבר ש-90% מהפתרונות הקיימים מתעלמים ממנו. קבלו ייעוץ לפרויקט שלכם — נעריך את המורכבות ונציע פתרון אופטימלי. צרו קשר כדי להזמין פיתוח של מערכת חישוב הפסד בלתי-קבוע עוד היום.

תהליך ולוח זמנים

אנליטיקה (יום אחד). קביעה: רק Uniswap V3 או שצריך גם V2/Curve/Balancer (לכל אחד מתמטיקת IL משלו). אילו רשתות: mainnet + L2.

פיתוח (3-5 ימים). פונקציות מתמטיות → שכבת שליפת נתונים → API → גרפי Frontend. TypeScript + Zod לוולידציה של נתונים מ-The Graph (subgraph עשוי להחזיר null עבור עמדות חדשות).

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

מחשבון לעמדות V2 עם חישוב היסטורי — החל מ-3 ימים. מערכת מלאה עם נזילות מרוכזת של V3, מחשבון תחזית וויזואליזציה — מ-5 עד 7 ימים. התמחור אישי. צרו קשר לקבלת הצעת מחיר.