פיתוח מערכת פירוק נכסים עבור DEX תמידי
התרסקות בזק של 50% תוך דקות ספורות—ואם מודול הפירוק לא מעבד פוזיציות בזמן, הפרוטוקול סופג חוב אבוד. בורסה תמידית פופולרית אחת נתקלה בכך בשנה שעברה כשהנפחים גדלו פי עשרה ורשת ה-keeper לא עמדה בקצב. בתרחישים כאלה, מערכת פירוק מתוכננת היטב עם תמריצים למפרקים עומדת במשימה: המפרק מקבל חלק מהעמלה, אך רק על ביצוע מהיר. ארכיטקטורה גרועה או מפספסת פוזיציות או מייצרת חוב בלתי ניתן לטיפול עבור ספקי נזילות. אנו מתכננים פתרונות שעומדים בתנודות שוק קיצוניות. צרו קשר לבדיקת הפרוטוקול שלכם.
למהנדסים שלנו יש ניסיון של 5+ שנים בפיתוח DeFi והם יישמו למעלה מ-15 פתרונות פירוק על Ethereum, Arbitrum ו-Polygon. אנו מבטיחים פעולה תקינה גם במהלך קפיצות מחיר חדות.
כיצד מחושב סף הפירוק?
ב-DEX תמידי (ויקיפדיה), סוחר פותח פוזיציה עם מינוף: 10x לונג ETH, מפקיד 1000 USDC כבטוחה, פוזיציה = 10,000 USDC נומינלי. אם ETH יורד ב-9%, ההפסד הלא ממומש הוא 900 USDC, הבטוחה יורדת ל-100 USDC. יחס מרווח = 100/10,000 = 1%. אם זה מתחת למרווח התחזוקה (בדרך כלל 0.5-1%), הפוזיציה כפופה לסגירה כפויה.
נוסחת יחס המרווח: marginRatio = (collateral + unrealized_pnl) / notional_value. הפרוטוקול חייב לפרק את הפוזיציה לפני collateral + unrealized_pnl < 0—אחרת נוצר חוב אבוד.
מדוע סיכון פער הוא האיום המרכזי?
פער (קפיצת מחיר חדה, למשל על רקע חדשות) מדלג על מספר רמות פירוק בטיק אחד. פוזיציה יכולה להיכנס מיד להון עצמי שלילי ללא פירוק ביניים. מסמכי dYdX v4 מציינים שסיכון פער הוא הגורם המרכזי לחוב אבוד.
GMX v2 ו-dYdX v4 משתמשים במספר מנגנונים להפחתת סיכון פער:
- קרן ביטוח—עתודה מחלק מעמלות המסחר
- ADL (Auto-Deleveraging)—אם קרן הביטוח אינה מספיקה, פוזיציות רווחיות של הצד הנגדי נסגרות בכוח
- מגבלות פתיחת פוזיציות מקסימליות—הגבלת OI כולל לנכס מפחיתה חוב אבוד פוטנציאלי
השוואת גישות: Keeper לעומת פירוק On-Chain
| פרמטר | מבוסס Keeper | אוטומטי On-Chain |
|---|---|---|
| מהירות תגובה | תלויה בגז ובתחרות | מיידית לכל בלוק |
| מורכבות | בינונית (תשתית Off-Chain) | גבוהה (גז, מורכבות) |
| שליטת הפרוטוקול | עקיפה (באמצעות תמריצים) | ישירה |
| סיכון MEV | גבוה | נמוך |
| דוגמה | GMX, dYdX | Synthetix (גרסאות קודמות) |
הגישה מבוססת ה-Keeper מפחיתה עלויות גז לפירוק פי 2-3 בהשוואה לאוטומטי On-Chain. זה מאושר בפועל בפרויקטים שלנו.
ארכיטקטורת מערכת הפירוק
רכיב On-Chain
החוזה מאחסן פוזיציות ומעדכן כל הזמן את מחיר הסימון דרך אורקל. הפירוק מתרחש בשני שלבים:
1. בדיקת יכולת פירוק (פונקציית view):
function isLiquidatable(uint256 positionId) public view returns (bool) {
Position memory pos = positions[positionId];
uint256 markPrice = oracle.getMarkPrice(pos.indexToken);
int256 unrealizedPnl = calculatePnl(pos, markPrice);
int256 equity = int256(pos.collateral) + unrealizedPnl;
// Вычитаем накопленный funding fee
int256 pendingFunding = calculateFundingFee(pos);
equity -= pendingFunding;
uint256 notional = pos.size; // size = notional value
// Ниже maintenance margin threshold
return equity < int256(notional * MAINTENANCE_MARGIN_BPS / 10000);
}2. ביצוע הפירוק:
function liquidate(uint256 positionId, address recipient) external nonReentrant {
require(isLiquidatable(positionId), "Not liquidatable");
Position memory pos = positions[positionId];
uint256 markPrice = oracle.getMarkPrice(pos.indexToken);
// Рассчитываем остаток коллатераля после убытков
int256 remainingCollateral = calculateRemainingCollateral(pos, markPrice);
uint256 liquidationFee = pos.collateral * LIQUIDATION_FEE_BPS / 10000;
// Выплата keeper'у
uint256 keeperFee = liquidationFee * KEEPER_SHARE / 100;
token.transfer(recipient, keeperFee);
// Остаток в insurance fund или протокол
if (remainingCollateral > 0) {
uint256 toInsurance = uint256(remainingCollateral) - keeperFee;
insuranceFund.deposit(toInsurance);
} else {
// Bad debt — списываем из insurance fund
insuranceFund.cover(uint256(-remainingCollateral));
}
_closePosition(positionId);
emit PositionLiquidated(positionId, msg.sender, keeperFee, block.timestamp);
} מערכת Keeper
Keeper—משתתף חיצוני המנטר פוזיציות וקורא ל-function isLiquidatable(uint256 positionId) public view returns (bool) { Position memory pos = positions[positionId]; uint256 markPrice = oracle.getMarkPrice(pos.indexToken); int256 unrealizedPnl = calculatePnl(pos, markPrice); int256 equity = int256(pos.collateral) + unrealizedPnl; // Вычитаем накопленный funding fee int256 pendingFunding = calculateFundingFee(pos); equity -= pendingFunding; uint256 notional = pos.size; // size = notional value // Ниже maintenance margin threshold return equity < int256(notional * MAINTENANCE_MARGIN_BPS / 10000); } . תמריץ—עמלת keeper, היוצרת שוק תחרותי של מפרקים.
דוגמה לתצורת בוט keeper ב-TypeScript עם viem
class LiquidationKeeper {
private positionCache: Map<bigint, Position> = new Map();
async monitorPositions(): Promise<void> {
contract.on('PositionUpdated', (positionId, position) => {
this.positionCache.set(positionId, position);
});
provider.on('block', async (blockNumber) => {
const markPrice = await oracle.getMarkPrice(INDEX_TOKEN);
const liquidatable = [...this.positionCache.entries()]
.filter(([_, pos]) => this.isLiquidatable(pos, markPrice))
.sort((a, b) => this.prioritize(a, b, markPrice));
// Самые выгодные первыми
for (const [positionId] of liquidatable) {
await this.attemptLiquidation(positionId);
}
});
}
private prioritize(a: [bigint, Position], b: [bigint, Position], price: bigint): number {
return Number(b[1].collateral - a[1].collateral);
}
} אורקל מחיר סימון
אלמנט מפתח: מחיר הסימון חייב להיות בלתי ניתן למניפולציה באמצעות הלוואות בזק. dYdX v4 משתמש באורקל Pyth עם חציון מצטבר ממספר מקורות. GMX v2 משתמש ב-Chainlink (תיעוד רשמי) בתוספת אורקל keeper מותאם עם אימות חתימה.
דרישות האורקל:
- בדיקת טריות: מחיר לא ישן מ-N שניות (בדרך כלל 30-60)
- בדיקת סטייה: מחיר חדש לא שונה ביותר מ-X% מהקודם (מפסק חשמל)
- צבירה מרובת מקורות: חציון מ-3+ מקורות
function getMarkPrice(address token) external view returns (uint256) {
PriceData memory data = priceData[token];
require(block.timestamp - data.timestamp <= STALENESS_THRESHOLD, "Stale price");
require(data.numSources >= MIN_SOURCES, "Insufficient sources");
return data.medianPrice;
} מה קורה כשקרן הביטוח נגמרת? (ADL)
Auto-Deleveraging—קו ההגנה האחרון. אם קרן הביטוח מוצתה, הפרוטוקול סוגר בכוח פוזיציות רווחיות במחיר הסימון (ללא החלקה). סדר הסגירה: פוזיציות עם הרווח והמינוף הגבוהים ביותר תחילה—כיוון שהן המסוכנות ביותר למערכת.
ADL הוא מנגנון כואב עבור סוחרים. חשוב:
- לחשוף בבירור את סיכון ה-ADL בתיעוד
- להציג מחוון ADL בממשק המשתמש (כמו בחוזים עתידיים של Binance)
- להגביל OI כדי למזער את הצורך ב-ADL
מה כלול בפיתוח מערכת סוהר
| שלב | משך | תוצאה |
|---|---|---|
| ניתוח סיכונים ומודלים | 3-5 ימים | פרמטרים למרווח תחזוקה, עמלה, גודל קרן ביטוח |
| פיתוח חוזה חכם | 2-4 שבועות | חוזי פירוק, קרן ביטוח, מתאם אורקל |
| שילוב בוט keeper | 1-2 שבועות | תשתית Off-Chain ב-TypeScript |
| בדיקות Fork | שבוע | סימולציה של תרחישי לחץ (התרסקות בזק וקריסת stablecoin) |
| ביקורת | 2-3 שבועות | דוח מבקר עצמאי |
| פריסה וניטור | שבוע | תיעוד, סקריפטים, לוח מחוונים |
המחזור המלא אורך 8-12 שבועות. העלות מחושבת באופן אישי.
ערימת טכנולוגיות
Solidity + Foundry—חוזי פירוק, אורקל, קרן ביטוח. TypeScript + viem—בוט keeper, ניטור. Chainlink + Pyth—הזנות מחיר. Gelato Network—גיבוי לקריאה לפונקציות keeper. בדיקות Foundry fork—סימולציה על fork של mainnet.
כיצד אנו מבטיחים אמינות
אנו מסתמכים על 5 שנות ניסיון ב-Web3 ועשרות ביקורות מוצלחות. אנו מיישמים אימות פורמלי לחוזים קריטיים. אנו מספקים אחריות על הקוד למשך 6 חודשים לאחר הפריסה.
קבלו ייעוץ: תארו את הפרוטוקול שלכם, ואנו נעריך את הסיכונים ונציע ארכיטקטורה.







