פיתוח דשבורד LP לקרנות קריפטו: NAV, פורטפוליו ואנליטיקה

איגום נתוני פורטפוליו מעשרות מקורות הוא האתגר המרכזי שכל קרן קריפטו מתמודדת איתו. שותף מוגבל (LP) רוצה לדעת שלושה דברים: ערך מניה נוכחי, שינוי NAV לאורך תקופה, והרכב פורטפוליו מדויק. אבל נכסי הקרן מפוזרים על פני ארנקים חמים, פרוטוקולי DeFi, סטייקינג, מאגרי נזילות ופוזיציות OTC — כל אחד דורש שיטת הערכה שונה. הניסיון שלנו מראה שאיגום נכון ותמחור הם המכשול הטכני המרכזי. אנו מציעים פתרון מפתח-ביד שמבטל איסוף נתונים ידני, מפחית שגיאות חישוב, ומוריד עלויות תפעול ב-30% — חוסך לקרן טיפוסית 50,000 דולר בשנה.

בעיות שאנו פותרים

איגום נתונים ממקורות הטרוגניים

הקושי העיקרי בדשבורד LP הוא לא ממשק המשתמש אלא איגום נתונים מ-10–15 מקורות שונים עם הערכה נכונה. כל מקור דורש מתאם (adapter) משלו.

פוזיציות און-צ'יין

יתרות פשוטות — טוקני ERC-20 בכתובות שמירה — נקראות באמצעות multicall (Multicall3 פרוס ב-0xcA11bde05977b3631167028862bE2a173976CA11 על 100+ רשתות). קריאת RPC אחת מחזירה יתרות למאה טוקנים:

const calls = tokens.map(token => ({ target: token.address, callData: erc20.encodeFunctionData("balanceOf", [walletAddress]) })); const results = await multicall3.aggregate3(calls); 

פוזיציות במאגרי נזילות

פוזיציות Uniswap V3 כ-NFT (ERC-721). כדי לחשב ערך נוכחי, אנו קוראים const calls = tokens.map(token => ({ target: token.address, callData: erc20.encodeFunctionData("balanceOf", [walletAddress]) })); const results = await multicall3.aggregate3(calls); ומחשבים כמויות באמצעות נוסחת הנזילות של V3. SDK מוכן לשימוש: NonfungiblePositionManager.positions(tokenId) עם @uniswap/v3-sdk.

פוזיציות הלוואות

Aave V3 מחזיר נתונים מלאים דרך Position.fromAmounts() (בטוחה, חוב, גורם בריאות). Compound משתמש ב-getUserAccountData() ו-CToken.borrowBalanceCurrent(). עבור Ethereum ועוד שלוש L2, זה שמונה קריאות נפרדות עבור Aave/Compound בלבד.

סטייקינג

יתרות מאמתים דרך Beacon Chain API (CToken.balanceOfUnderlying()). סטייקינג נזיל (stETH, rETH) — רק יתרות ERC-20 המומרות ל-ETH בשער החליפין הנוכחי.

פוזיציות אוף-צ'יין

פוזיציות CeFi (בורסות, דלפקי OTC) נקראות דרך ה-API שלהן:

• Binance: /eth/v1/beacon/states/finalized/validator_balances (חתימת HMAC-SHA256)
• Coinbase Prime: REST API עם אימות JWT
• פוזיציות OTC לעיתים דרך ייבוא ידני או CSV

תבנית ארכיטקטונית: כל מקור נתונים הוא מתאם נפרד עם ממשק אחיד:

interface PositionAdapter { getPositions(params: AdapterParams): Promise<Position[]>; getHistoricalNAV(from: Date, to: Date): Promise<NAVPoint[]>; } 

למה NAV הוא המדד הראשי

שווי נכסים נטו (NAV) — נכסי הקרן פחות התחייבויות, תקן ההערכה המרכזי (ויקיפדיה). זהו המדד המרכזי שסביבו בנוי כל הדשבורד. חישוב נכון דורש מחירים עדכניים. בפועל, NAV יכול להשתנות עד 50 פעמים ביום עקב תנודתיות שוק, ולכן מחירים טריים וחישוב מחדש מהיר הם קריטיים.

מקורות מחירים

עבור NAV היסטורי, אנו זקוקים למחירים היסטוריים. CoinGecko Pro API מספק נתוני OHLCV עם רזולוציה יומית ושעתית. לרזולוציה דקתית — איסוף עצמי מאירועי Uniswap. NAV מחושב בדולרים, אבל לקרנות עשויות להיות פוזיציות במספר מטבעות בסיס. טבלת שערי חליפין (ECB API או Fixer.io) נדרשת להמרת פוזיציות שאינן בדולרים. עד 20% מהפוזיציות עשויות להיות שאינן בדולרים.

חישוב מניית LP

לאחר חישוב NAV, מניית LP ספציפי:

LP Share Value = NAV × (LP Capital / Total Fund Capital) 

לקרנות עם מספר מחלקות מניות (Fund I / Fund II, מבני עמלות שונים) — NAV נפרד לכל מחלקת מניות. דמי ניהול (לדוגמה, 2% שנתי) ודמי ביצוע (ריבית נישאה עד 20%) מפחיתים את NAV של LP בעת צבירה.

איך אנחנו עושים את זה

סקירת ארכיטקטורה

• שכבת איגום נתונים: מתאמי און-צ'יין (Ethereum, Arbitrum, Solana...), מתאמי CeFi (Binance, Coinbase, OTC), קלט ידני (לפוזיציות לא נזילות)
• מנוע תמחור: CoinGecko + Chainlink + Uniswap TWAP
• מחשבון NAV: איגום פורטפוליו, המרת שערי חליפין, לוגיקת מחלקות מניות
• מסד נתונים: PostgreSQL + TimescaleDB לסדרות זמן של NAV
• שכבת API: REST / GraphQL
• דשבורד LP: React

TimescaleDB — הרחבה של PostgreSQL לנתוני סדרות זמן. תמונות NAV נכתבות כל 15–60 דקות. שאילתות היסטוריות רצות דרך אגרגציות רציפות, שהן מהירות פי 10 משאילתות רגילות.

מקרה בוחן: חישוב NAV רב-מטבעי

בפרויקט אחרון, בנינו דשבורד לקרן המחזיקה ETH, LINK, USDC, ופוזיציית נזילות Uniswap V3 (ETH/USDC). התהליך:

1. שליפת יתרות און-צ'יין עבור ETH ו-LINK.
2. קבלת מחירי ETH ו-LINK מ-Chainlink.
3. חישוב ערך פוזיציית Uniswap V3 מהמחיר הנוכחי ו-ticks.
4. המרת הכל לדולרים (כולל USDC דרך שער חליפין אם נדרש).
5. הפחתת התחייבויות (לדוגמה, חוב מ-Aave).
6. כפל בחלק ההון של ה-LP.

כל השלבים אוטומטיים ורצים בלוח זמנים, ומקצרים את מחזור חישוב NAV מדקות לשניות.

אבטחה וגישה

שותפים מוגבלים רואים רק את הפוזיציות שלהם. אימות דרך JWT + MFA (TOTP). מפתחות API של בורסות מאוחסנים מוצפנים (AES-256, מפתחות ב-AWS KMS / HashiCorp Vault) — דשבורד LP משתמש רק במפתחות קריאה בלבד; גישת כתיבה אף פעם לא נדרשת. רשימת IP מורשית לבקשות API של בורסות מוסיפה שכבת הגנה נוספת. הפתרון שלנו מנוסה בשטח עם SLA מובטח של 99.9% וכל האינטגרציות נבדקות על ידי מומחי אבטחה מוסמכים.

התהליך שלנו

מה כלול

• תיעוד: דיאגרמת ארכיטקטורה, תיאור API, מדריך להוספת מקורות חדשים
• גישה: פריסה מאובטחת עם JWT, MFA, הצפנת מפתחות (AES-256, HashiCorp Vault)
• הדרכה: 2–3 סדנאות ל-GP ו-LP על שימוש בדשבורד
• תמיכה: 3 חודשי תמיכה לאחר ייצור עם SLA של 99.9%

טעויות אופייניות בפיתוח דשבורד LP

• התעלמות מנתוני מחירים היסטוריים — בלעדיהם לא ניתן לחשב NAV היסטורי, שהוא מדד LP מרכזי.
• אי-טיפול באיזון מחדש של מאגר Uniswap V3 — פוזיציה עשויה להימשך חלקית אך לא לבוא לידי ביטוי ביתרות.
• אחסון מפתחות API של בורסות בטקסט פשוט — פגיעות קריטית; השתמשו ב-vault.