איך לבנות פרוטוקול הלוואות מותאם אישית על Fork של Compound?
אנו מפתחים פרוטוקולי הלוואות מותאמים אישית על Fork של Compound. הניסיון שלנו: 5+ שנים ב-DeFi ו-20+ פריסות. במבט ראשון, "לעשות Fork" נשמע פשוט: להעתיק את המאגר, לשנות פרמטרים, לפרוס. בפועל, זהו מקור רוב הפריצות בקטגוריית ההלוואות: חישוב שער חליפין שגוי, לוגיקת תמריץ פירוק שבורה, מקור מחיר אורקל יחיד. אנו מפרקים מה אתה באמת צריך לעשות כדי ש-Fork של Compound יעבוד כראוי.
מה בדרך כלל נשבר בעת Fork של Compound
שער חליפין וריבית מצטברת
Compound משתמש בקונספט cToken: משתמש מפקיד DAI, מקבל cDAI. עם הזמן, שער החליפין עולה עקב ריבית שנצברה מהלווים. חישוב השער עובר דרך accrueInterest(), שחייב להיקרא לפני כל פעולת יתרה.
טעות נפוצה ב-Forks: accrueInterest() לא נקרא בכל מקום שצריך—לדוגמה, הוא מושמט בפונקציית פירוק מותאמת אישית. תוצאה: שער החליפין הופך למיושן, משתמשים רואים יתרות שגויות, או שהמפרק מקבל פחות בטחונות ממה שהוא צריך. באחד ה-Forks הידועים, זה הוביל להצטברות חובות אבודים שלא הבחינו בהם במשך שבועות.
בדיקה: בבדיקות, קרא במפורש ל-vm.roll(block + N) וודא ש-exchangeRateCurrent() גדל נכון באופן יחסי ל-borrowRate ולזמן.
מקדם בטחונות מול סף פירוק
ב-Compound V2, collateralFactor ממלא שני תפקידים: הוא קובע כמה ניתן ללוות וקובע את סף הפירוק. משמעות הדבר היא שעמדה נכנסת לפירוק כמעט מיד בחציית מגבלת ההלוואה—אין חיץ בין הלוואה מקסימלית לפירוק. Aave V3 טיפל בכך על ידי הפרדת LTV (יחס הלוואה לערך, כמה ניתן ללוות) ו-liquidationThreshold (מתי לפרק). חיץ של 10-15% נותן ללווה זמן להוסיף בטחונות.
אם אתה בונה Fork לייצור עם משתמשים אמיתיים—אנו ממליצים להוסיף הפרדה זו. זה לא משנה את המתמטיקה המרכזית של Compound, אבל זה משפר משמעותית את חוויית המשתמש ומפחית פירוקים מיותרים בתנודתיות קצרת טווח.
אורקל: עדכון Chainlink יחיד אינו מספיק
Compound V2 משתמש ב-Chainlink כמקור מחיר יחיד. אם עדכון ה-Chainlink נתקע מסיבה כלשהי (וזה קורה—עדכונים לנכסים פחות נזילים עשויים שלא להתעדכן במשך שעות), הפרוטוקול פועל עם מחירים מיושנים. בתנודתיות גבוהה, זה יוצר הזדמנויות ארביטראז' או סיכון לחובות אבודים.
הגנה מינימלית: בדוק את חותמת הזמן של updatedAt מ-Chainlink וחסום פעולות אם הנתונים ישנים מ-N שניות. הגנה מורחבת: אורקל משני (לדוגמה, Uniswap V3 TWAP כגיבוי) עם מפסק חשמל—אם שני מחירי האורקל חורגים ביותר מ-X%, הפעולות מושהות.
מה אנו מתאימים אישית ב-Fork
התאמות אישיות טיפוסיות לפרויקט ספציפי:
-
רשימת נכסים נתמכים. Compound תומך בנכסים מרכזיים—ETH, WBTC, USDC, DAI. אם אתה צריך הלוואות עבור אסימוני נישה (LST, LP tokens, RWA), אנו מוסיפים שווקים חדשים עם פרמטרי סיכון אישיים. אסימוני LP כבטחונות דורשים לוגיקת הערכה נפרדת דרך הנכסים הבסיסיים.
-
מודל ריבית. Compound משתמש ב-JumpRateModel: ריבית נמוכה בניצול נמוך, עלייה תלולה אחרי נקודת ה-kink (בדרך כלל 80%). עבור מאגרי stablecoin, kink יכול להיות גבוה יותר (90%); עבור נכסים תנודתיים, נמוך יותר (60%). אנו קובעים פרמטרים (baseRate, multiplier, jumpMultiplier, kink) כדי להתאים לטוקונומיקה הספציפית.
-
ממשל ופונקציות אדמין. ל-Compound V2 יש כתובת אדמין יחידה עם זכויות רחבות. עבור פרוטוקול ייצור, מינימום: Gnosis Safe multisig לאדמין, timelock על שינויים קריטיים (פרמטרי סיכון, אורקל, שומר השהה). ממשל מבוזר דרך Governor Bravo ניתן להוסיף מאוחר יותר.
-
מצב בידוד. Compound V2 אינו מבודד סיכון בין נכסים—בעיה באסימון אחד יכולה להשפיע על כל הפרוטוקול. Compound V3 (Comet) טיפל בזה באופן קיצוני על ידי הצגת שווקים עם בטחון יחיד. עבור Fork, אנו ממליצים לפחות על בידוד בסיסי: מאגרים נפרדים לנכסים בסיכון גבוה.
למה Fork של Compound הוא לא רק העתקה?
Fork ללא התאמה אישית הוא העתק עם באגים של מישהו אחר. Compound V2 מפגר אחרי Aave V3 בחוויית המשתמש בגלל היעדר חיץ פירוק, אבל ההתאמה האישית שלנו מגשרת על הפער הזה. אנו מוסיפים מאגרים מבודדים, אורקל גיבוי, ופרמטרי סיכון גמישים כדי להפוך את הפרוטוקול לבטוח וידידותי יותר למשתמש.
טכנולוגיה ותהליך
בסיס: מאגר compound-protocol או compound-v2-subgraph עבור אינדוקס ב-The Graph. פיתוח ב-Foundry: בדיקות יחידה לכל שוק, בדיקות אינטגרציה עם Fork של mainnet כדי לוודא אינטגרציית אורקל.
ביקורת היא חובה. Fork של Compound אינו אומר "בטוח אוטומטית"—התאמות אישיות יוצרות וקטורים חדשים. אנו ממליצים על תחרות Code4rena או Sherlock לכיסוי רחב של מבקרים בתקציב קבוע.
מה כלול בעבודה
- ניתוח דרישות ועיצוב ארכיטקטורה
- פיתוח והתאמה אישית של חוזים חכמים
- בדיקות יחידה ואינטגרציה (כיסוי >90%)
- ביקורת פנימית עם Slither, Echidna, סקירה ידנית
- פריסה ב-Testnet ו-mainnet
- אינטגרציה עם Gnosis Safe, timelock, subgraph
- תיעוד טכני והכשרת צוות הלקוח
לוחות זמנים משוערים
| שלב | משך | תוכן |
|---|---|---|
| עיצוב | 1-2 שבועות | פרמטרי סיכון, רשימת נכסים, מודל ממשל |
| פיתוח | 4-8 שבועות | חוזים, התאמות אישיות, בדיקות |
| ביקורת פנימית | 1-2 שבועות | Slither, Echidna, סקירה ידנית |
| ביקורת חיצונית | 2-4 שבועות | חובה לפני mainnet |
| פריסה וניטור | שבוע אחד | Gnosis Safe, subgraph, dashboard |
Fork בסיסי עם שינויי פרמטרים מינימליים: 4-6 שבועות פיתוח. Fork עם התאמות אישיות משמעותיות (מודל ריבית חדש, מאגרי בידוד, אורקל מותאם): 8-12 שבועות. ביקורת רצה במקביל לשבועות האחרונים של הפיתוח, אבל הקוד הסופי חייב להיות קפוא שבועיים לפני תחילת הביקורת.
השוואה: Compound V2 מול Fork מותאם אישית
| תכונה | Compound V2 | ה-Fork המותאם שלנו |
|---|---|---|
| חיץ פירוק | אין | 10-15% (LTV מול liquidationThreshold) |
| אורקל | Chainlink בלבד | Chainlink + Uniswap V3 TWAP כגיבוי |
| ממשל | אדמין יחיד | Multisig + timelock (עד DAO מלא) |
| בידוד סיכון | אין | מאגרי בידוד בסיסיים |
מוכן לדון בפרויקט שלך? צור קשר לייעוץ. הזמינו פיתוח turnkey וקבלו פרוטוקול הלוואות אמין עם הבטחת איכות.