הערה: כאשר קרן קריפטו נועלת רווחים וצריכה לחלק אותם בין עשרות משקיעים (LPs) עם תאריכי כניסה שונים, יציאות חלקיות ועמלות ביצוע שנצברו, חישובים פרופורציונליים פשוטים מובילים לחוסר הוגנות ולחורים מתמטיים. לדוגמה, קרן עם שלושה משקיעים שנכנסו בימים שונים, כאשר היא משלמת רבעונית ללא שקלול זמן של ההפקדות, תעניק לחלק מהמשקיעים הכנסה שלא מגיעה להם ולאחרים הפסדים. אנו מתכננים ומיישמים מערכת חלוקת רווחים לקרנות קריפטו שהיא מדויקת מתמטית, ניתנת לביקורת ועמידה בפני מניפולציות. פתרון מפתח—מבחירת מודל ועד פריסה עם תיעוד ותמיכה. החיסכון הממוצע בעמלות רשת עבור קרן עם 500 משקיעים מוערך ב-$3,000–$5,000 לחודש. אנו מעריכים את הפרויקט שלך תוך 1–2 ימים—צור קשר.
המשימות של מערכת חלוקת הרווחים
המערכת חייבת להתחשב בצורה הוגנת בזמן ההפקדה של כל משקיע, לגבות עמלת ביצוע רק על רווחים חדשים, ולתמוך באלפי משתתפים. ללא ארכיטקטורה מחושבת היטב, נוצרות בעיות: reentrancy במהלך תשלומים, אובדן דיוק ופגיעות להתקפות flash loan דרך מניפולציה של אורקל. הפתרון שלנו משתמש בדפוסי DeFi מוכחים—EIP-4626 vaults ו-Synthetix staking rewards—ומחזק אותם עם בדיקות invariant על Foundry.
איך לבחור מודל חשבונאות מניות?
לפני כתיבת החוזים, אנו בוחרים את מודל חשבונאות המניות הבסיסי. שתי גישות עיקריות.
מבוסס מניות (Tokenized Shares)
משקיעים מקבלים מניות ERC-20 בעת הכניסה. הרווח בא לידי ביטוי דרך עליית NAV למניה—מניה אחת שווה יותר, אך מספר המניות אינו משתנה. חלוקת רווחים פירושה או עליית ערך הון (עליית ערך המניה) או תשלום דיבידנד עם ירידת NAV למניה. "EIP-4626 מגדיר תקן ל-vaults ממותגים שמפשט אינטגרציה עם פרוטוקולי DeFi"—התקן מפשט את אינטגרציית ה-DeFi אך יוצר מורכבויות עם יציאות חלקיות וחלוקות ביניים.
מבוסס נקודות (Accumulated Points)
כל משקיע צובר "נקודות" ביחס לזמן ולסכום ההפקדה. הרווח מחולק ביחס לנקודות. גישה זו מתאימה לקרנות תשואה עם תשלומים קבועים. דפוס ה-"Rewards per token" הוא דרך מוכחת לחישוב יעיל של תגמולים שנצברו ללא מעבר על כל המשקיעים.
contract ProfitDistributor { uint256 public rewardPerShareStored; uint256 public lastUpdateTime; uint256 public totalShares; mapping(address => uint256) public rewardPerSharePaid; mapping(address => uint256) public pendingRewards; mapping(address => uint256) public shares; modifier updateReward(address account) { rewardPerShareStored = rewardPerShare(); lastUpdateTime = block.timestamp; if (account != address(0)) { pendingRewards[account] = earned(account); rewardPerSharePaid[account] = rewardPerShareStored; } _; } function earned(address account) public view returns (uint256) { return shares[account] * (rewardPerShare() - rewardPerSharePaid[account]) / 1e18 + pendingRewards[account]; } } | מאפיין | מבוסס מניות | מבוסס נקודות |
|---|---|---|
| שקיפות | גבוהה (ערך המניה גלוי) | בינונית (נקודות מחושבות off-chain) |
| גז לכניסה/יציאה | ~80k (העברת ERC-20) | ~50k (עדכון mapping) |
| תמיכה ביציאה חלקית | קשה (יש לשרוף מניות) | קלה (הפחתת נקודות) |
| ביקורת חוזה חכם | קלה יותר (תקן EIP-4626) | מורכבת יותר (חישובי נקודות) |
למה מערכות פשוטות נשברות על מקרים מורכבים?
כניסות ויציאות באמצע תקופה
אם משקיע נכנס באמצע הרבעון, הוא לא אמור לקבל רווח עבור התקופה שלפני כניסתו.反之, ביציאה באמצע תקופה, הוא אמור לקבל את חלקו ברווח שנצבר אך לא חולק. פתרון: חלוקה מבוססת snapshot. בכל שינוי מצב, אנו רושמים checkpoint עם ה-rewardPerShare הנוכחי. בחישוב, אנו משתמשים בהפרש בין הערך הנוכחי לערך ה-checkpoint.
function _updateCheckpoint(address lp) internal { uint256 currentRPS = rewardPerShareStored; uint256 lpShares = shares[lp]; uint256 lastRPS = checkpoints[lp].rewardPerShare; if (lpShares > 0 && currentRPS > lastRPS) { uint256 accrued = lpShares * (currentRPS - lastRPS) / PRECISION; checkpoints[lp].pendingReward += accrued; } checkpoints[lp].rewardPerShare = currentRPS; } עמלת ביצוע עם High Water Mark
עמלת ביצוע (בדרך כלל 20%) צריכה לחול רק על רווח חדש—מעל ה-HWM הקודם. זה מגן על משקיעים מעמלות כפולות לאחר ירידת ערך והתאוששות. בחירה בין Global HWM ל-Per-LP HWM: הראשון פשוט יותר, השני הוגן יותר אך כבד יותר בגז. אם לקרן יש יותר מ-50 משקיעים, הפרש הגז יכול לעלות על 30%. עבור קרנות עם הון מ-$5 מיליון, החיסכון מ-Per-LP HWM יכול להגיע ל-$2,000 בחודש בזכות חשבונאות הוגנת.
mapping(address => uint256) public lpHighWaterMark; function calculatePerformanceFee(address lp, uint256 currentNAVPerShare) public view returns (uint256 feeAmount) { uint256 hwm = lpHighWaterMark[lp]; if (currentNAVPerShare <= hwm) return 0; uint256 profitPerShare = currentNAVPerShare - hwm; uint256 lpShareBalance = shares[lp]; feeAmount = profitPerShare * lpShareBalance * performanceFeeRate / (PRECISION * 10000); } Hurdle Rate
חלק מהקרנות גובות עמלת ביצוע רק אם התשואה עולה על מדד ייחוס (לדוגמה, 8% שנתי). מיושם כסף נוסף מעל ה-HWM.
הגנה מפני מניפולציית אורקל בחישוב עמלת ביצוע
אנו משתמשים ב-TWAP במקום מחירי ספוט ומכניסים cooldown בין עדכון NAV לסילוק העמלה. זה מונע התקפות flash loan שבהן תוקף מעוות זמנית מחירים כדי להפעיל עמלות. בנוסף, multi-sig לפעולות מנהל.
שיטות לארגון תשלומים
| שיטה | גז לתשלום | מתאים ל | סיכונים |
|---|---|---|---|
| השקעה חוזרת | נמוך | כל היקף | אין |
| דפוס משיכה (claim) | ~50k גז | עד 1000 משקיעים | המשקיע חייב לתבוע בעצמו |
| Merkle drop | O(log N) ~60k | אלפי משקיעים (זול פי 10 מדפוס push) | דורש חישוב off-chain |
| דפוס push | O(N) ~100k+ | עד ~50 משקיעים | יכול להיכשל בחוזה מקבל |
חלוקת Merkle היא אופטימלית לאלפי משקיעים: המנהל מחשב תשלומים off-chain, בונה עץ Merkle ומפרסם את השורש on-chain. כל משקיע תובע את התשלום שלו עם הוכחה, גז בלתי תלוי במספר הנמענים. Uniswap משתמשת בדפוס זה לחלוקת UNI.
bytes32 public merkleRoot; function claimMerkle( uint256 index, address account, uint256 amount, bytes32[] calldata merkleProof ) external { require(!isClaimed(index), "Already claimed"); bytes32 node = keccak256(abi.encodePacked(index, account, amount)); require(MerkleProof.verify(merkleProof, merkleRoot, node), "Invalid proof"); _setClaimed(index); IERC20(rewardToken).safeTransfer(account, amount); emit Claimed(index, account, amount); } אבטחה וביקורת: הגנה מפני מניפולציות
פגיעויות מפתח:
- Reentrancy במהלך תשלומים—אפס את
contract ProfitDistributor { uint256 public rewardPerShareStored; uint256 public lastUpdateTime; uint256 public totalShares; mapping(address => uint256) public rewardPerSharePaid; mapping(address => uint256) public pendingRewards; mapping(address => uint256) public shares; modifier updateReward(address account) { rewardPerShareStored = rewardPerShare(); lastUpdateTime = block.timestamp; if (account != address(0)) { pendingRewards[account] = earned(account); rewardPerSharePaid[account] = rewardPerShareStored; } _; } function earned(address account) public view returns (uint256) { return shares[account] * (rewardPerShare() - rewardPerSharePaid[account]) / 1e18 + pendingRewards[account]; } }לפני העברה. - אובדן דיוק—השתמש בחשבון נקודה קבועה עם קנה מידה 1e18, עגל כלפי מטה.
- מניפולציית אורקל—TWAP ו-cooldown בין עדכון NAV לסילוק עמלה.
- ריכוזיות מנהל—timelock 24–48 שעות ו-multi-sig לפעולות settleFee.
פרטי אופטימיזציית גז: השתמש ב-storage packing, צמצם ספירת SSTORE, הפעל unchecked לפעולות בטוחות מפני גלישה. זה מקצץ גז ב-30–40% לעומת יישום נאיבי. בפרויקט אחד עם 500 משקיעים, החיסכון היה משמעותי בעמלות. אנו מבטיחים ביקורתיות חוזה: לצוות שלנו ניסיון עם חוזים חכמים ב-Solidity, Rust (Solana), Vyper. כל חוזה חכם עובר אימות פורמלי ובדיקות invariant על Foundry. מעל 30 פרויקטים מוצלחים: קרנות, DEXes, שווקי NFT. חיסכון בגז דרך אופטימיזציה מגיע ל-40% לעומת יישומים נאיביים.
מה אתה מקבל: שלבים ותוצרים
- עיצוב (3–5 ימים): בחירת מודל, מבנה עמלות, HWM per-LP לעומת גלובלי, מנגנון תשלום. פורמליזציה של invariants. תיעוד סכמה.
- פיתוח חוזים (7–10 ימים): vault, distributor, מודול עמלות. בדיקות יחידה, בדיקות fuzz, בדיקות invariant. קוד מקור + תיעוד מקיף.
- רכיבי Off-chain (3–5 ימים): מחשבון NAV, בונה עץ Merkle, סקריפטים לתביעה. בדיקות אינטגרציה.
- ביקורת (1–2 שבועות): ביקורת חיצונית חובה למערכות המנהלות כספי צד שלישי. דוח עם המלצות. עלות ביקורת חיצונית נעה בין $10,000 ל-$25,000 בהתאם למורכבות—אנו עוזרים לבחור קבלן.
- פריסה וניטור (2–3 ימים): פריסה הדרגתית, ניטור invariant בזמן אמת. גישה לדשבורד.
לאחר הפריסה, אנו מספקים תיעוד טכני מלא, תצורות והדרכת צוות. תמיכה ל-30 יום. אחריות לפגיעויות—6 חודשים. קבל ייעוץ—צור קשר, אנו מעריכים את הפרויקט ללא עלות ובזמן. הזמן פיתוח מערכת חלוקת רווחים לקרן הקריפטו שלך היום.
בנוסף: עבור קרן עם הון של $10 מיליון ו-1000 משקיעים, החיסכון מאופטימיזציית גז מסתכם בכ-$4,000 לחודש.