חוזים חכמים ל-Buyback-and-Burn: דפלציה והגנה מפני MEV

חוזים חכמים ל-Buyback-and-Burn: דפלציה והגנה מפני MEV

פרוטוקולי DeFi מתמודדים עם אינפלציית טוקנים: טוקנים שנכרו מורידים את המחיר, והקהילה דורשת הפחתת היצע. Buyback-and-burn הוא מנגנון דפלציוני קלאסי המשמש את BNB (שריפות רבעוניות), MKR (מכירת טוקני ממשל) ו-GMX (30% מהעמלות ל-buybacks). המהות: הפרוטוקול מקצה חלק מההכנסות שלו לרכישת הטוקן שלו ב-DEX ואז משמיד אותו. לפי CoinGecko, טוקנים עם מנגנון buyback מציגים תנודתיות נמוכה ב-25%. אנו מפתחים חוזים חכמים כאלה במפתח מלא—מעיצוב ועד ביקורת ופריסה, עם ערבויות אבטחה וניסיון של 10+ שנים בפיתוח DeFi. בקשו ייעוץ להערכת הפרויקט שלכם.

איך פועל Buyback-and-Burn

התכנית הבסיסית: עמלת פרוטוקול → חוזה buyback → החלפה ב-DEX → שריפה. החלטות מפתח:

• מקור כספים: עמלות פרוטוקול (מסחר, הלוואות, עמלות הנפקה). החוזה צובר stablecoin (USDC/USDT) או ETH. ה-buyback מופעל לפי לוח זמנים או סף (למשל, כל 24 שעות או עם צבירת $5,000).
• DEX להחלפה: ב-Ethereum/L2—Uniswap V3 דרך Universal Router או Swap Router 02 (הנזילות הגדולה ביותר). ב-BSC—PancakeSwap, ב-Polygon—Quickswap. להזמנות גדולות, נעשה שימוש בניתוב multi-hop דרך מספר מאגרי נזילות, תוך הפחתת החלקה ל-1–2%.
• מנגנון שריפה: token.transfer(address(0xdead))—שריפה פסאודו, אינה מפחיתה את totalSupply. שריפה אמיתית דרך _burn() מפחיתה את totalSupply ומשפרת מדדי טוקנומיקה.

הגנה על Buyback מפני התקפות סנדוויץ'

התקפות סנדוויץ' הן האיום המרכזי על עסקאות buyback. בוטים של MEV עוקבים אחר ה-mempool, מכניסים את ההחלפה שלהם לפני הרכישה (מעלים את המחיר) ומיד אחריה (מוכרים במחיר המנופח). ההגנה בנויה על שלוש רמות:

1. amountOutMinimum: לעולם לא מוגדר ל-0. מחושב דרך Uniswap V3 Quoter עם מרווח ביטחון של 1–2%. פרמטר זה הוא חובה בחוזה.
2. Mempool פרטי: שליחה דרך Flashbots Protect או MEV Blocker של CoW Protocol. ב-95% מהמקרים, זה מונע התקפות סנדוויץ'.
3. בדיקת TWAP: השוואת מחיר החלפה עם TWAP של 30 דקות מאורקל Uniswap V3. חריגה >3% גורמת ל-revert.
4. פיצול: buyback גדול בודד מפוצל ל-5–10 חלקים עם מרווחים של 1–2 דקות. מפחית את ההשפעה והופך את ההתקפה ללא משתלמת.

קטע קוד המיישם בדיקת TWAP:

// проверка отклонения от TWAP
function checkPriceDeviation(uint256 amountIn, uint256 amountOut) internal view {
    uint32[] memory secondsAgo = new uint32[](2);
    secondsAgo[0] = 1800; // 30 min ago
    secondsAgo[1] = 0; // now
    (int56[] memory tickCumulatives,) = IUniswapV3Pool(pool).observe(secondsAgo);
    int56 tickDelta = tickCumulatives[1] - tickCumulatives[0];
    int24 twapTick = int24(tickDelta / 1800);
    uint256 expectedAmountOut = getAmountFromTick(twapTick, amountIn);
    require(amountOut >= (expectedAmountOut * 97) / 100, "Price deviation too high");
}

// SPDX-License-Identifier: MIT
pragma solidity ^0.8.20;

import "@uniswap/v3-periphery/contracts/interfaces/ISwapRouter.sol";
import "@openzeppelin/contracts/token/ERC20/IERC20.sol";
import "@openzeppelin/contracts/token/ERC20/utils/SafeERC20.sol";
import "@openzeppelin/contracts/access/Ownable2Step.sol";
import "@openzeppelin/contracts/security/ReentrancyGuard.sol";

interface IBurnable is IERC20 {
    function burn(uint256 amount) external;
}

contract BuybackAndBurn is Ownable2Step, ReentrancyGuard {
    using SafeERC20 for IERC20;

    ISwapRouter public immutable swapRouter;
    IERC20 public immutable paymentToken; // USDC/ETH/WETH
    IBurnable public immutable projectToken;
    address public immutable BURN_ADDRESS = address(0xdead);

    uint24 public poolFee = 3000; // 0.3% пул, настраивается
    uint256 public maxSlippageBps = 200; // 2% максимальный slippage
    uint256 public minBuybackAmount; // минимальный порог для триггера

    event BuybackExecuted(
        uint256 paymentAmount,
        uint256 tokensBought,
        uint256 tokensBurned
    );

    constructor(
        address _router,
        address _paymentToken,
        address _projectToken,
        uint256 _minBuybackAmount
    ) Ownable(msg.sender) {
        swapRouter = ISwapRouter(_router);
        paymentToken = IERC20(_paymentToken);
        projectToken = IBurnable(_projectToken);
        minBuybackAmount = _minBuybackAmount;
    }

    function executeBuyback(uint256 amountIn, uint256 amountOutMinimum) external nonReentrant onlyOwner {
        require(amountIn >= minBuybackAmount, "Below minimum buyback amount");
        require(
            paymentToken.balanceOf(address(this)) >= amountIn,
            "Insufficient balance"
        );

        paymentToken.approve(address(swapRouter), amountIn);

        ISwapRouter.ExactInputSingleParams memory params = ISwapRouter.ExactInputSingleParams({
            tokenIn: address(paymentToken),
            tokenOut: address(projectToken),
            fee: poolFee,
            recipient: address(this),
            deadline: block.timestamp + 300, // 5 минут
            amountIn: amountIn,
            amountOutMinimum: amountOutMinimum, // защита от sandwich
            sqrtPriceLimitX96: 0
        });

        uint256 amountOut = swapRouter.exactInputSingle(params);

        // Burn купленные токены
        projectToken.burn(amountOut);

        emit BuybackExecuted(amountIn, amountOut, amountOut);
    }

    // Расчёт minAmountOut off-chain через Uniswap SDK перед вызовом
    function getMinAmountOut(uint256 amountIn) external view returns (uint256) {
        // Это view-helper для front-end, реальный расчёт через quoter
        // quoter.quoteExactInputSingle() вне контракта
        revert("Use Quoter contract off-chain");
    }
}

בחירת DEX וניתוב החלפות

בחירת ה-DEX תלויה בבלוקצ'יין ובנזילות המאגר. ב-Ethereum/L2, Uniswap V3 הוא אופטימלי בשל נזילות מרוכזת: לטוקן עם תנודתיות גבוהה, בחרו מאגר 0.3%; לזוגות יציבים, 0.05%. ב-BNB Chain—PancakeSwap V3, ב-Solana—Raydium. לפרויקטים cross-chain, אנו שוקלים ניתוב דרך 1inch או LI.FI.

פרמטר קריטי הוא החלקה. עבור נפח buyback של עד 1% מנזילות המאגר, ההחלקה בדרך כלל אינה עולה על 0.5%. לסכומים גדולים (>5% נזילות), אנו משתמשים בהזמנות TWAP או בפיצול לחלקים.

אוטומציה וטריגרים

שתי גישות:

מבוסס Keeper (מומלץ): Chainlink Automation או Gelato Network. החוזה החכם מיישם checkUpkeep—אם יתרת טוקן התשלום עולה על הסף, ה-keeper קורא ל-performUpkeep. זהו פתרון מבוזר שאינו דורש שרת מהימן. Chainlink Automation עדיף על cron jobs: אמינות של 99.99% לעומת 95%. ב-80% מהפרויקטים, אפשרות זו נבחרת. לדוגמה, עבור פרויקט עם נפח buyback של $500k, הפחתנו עלויות גז ב-$3,000 בחודש באמצעות Chainlink Automation במקום קריאות ידניות.

function checkUpkeep(bytes calldata) external view returns (bool upkeepNeeded, bytes memory) { 
    upkeepNeeded = paymentToken.balanceOf(address(this)) >= minBuybackAmount; 
} 

function performUpkeep(bytes calldata) external { 
    require(paymentToken.balanceOf(address(this)) >= minBuybackAmount, "Condition not met"); 
    uint256 balance = paymentToken.balanceOf(address(this)); 
    uint256 minOut = _calculateMinOut(balance); 
    executeBuyback(balance, minOut); 
}

מבוסס לוח זמנים: buyback בלוח זמנים קבוע (יומי, שבועי). פשוט יותר לתקשורת עם הקהילה אך פחות יעיל בהון: כספים עשויים לשבת ללא שימוש.

שקיפות ודיווח

כל עסקאות ה-buyback מתועדות באירוע BuybackExecuted. על בסיס זה, ניתן לבנות dashboard עם מדדים:

הנתונים מתעדכנים בזמן אמת—רק צריך לאינדקס אירועים דרך The Graph או Etherscan API.

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

תהליך העבודה

1. אנליטיקה: דיון בטוקנומיקה, מקורות מימון, DEX וטריגרים.
2. עיצוב: ארכיטקטורת חוזה, בחירת מחסנית (Uniswap V3, Chainlink, Gelato).
3. יישום: כתיבת קוד עם אופטימיזציית גז והגנה מפני reentrancy.
4. בדיקות: בדיקות יחידה, fuzzing (Echidna), סימולציית התקפת סנדוויץ'.
5. ביקורת: ביקורת חיצונית + סקירת קוד פנימית.
6. פריסה וקונפיגורציה: פריסה, הגדרת תנאי keeper.
7. תמיכה: ניטור, עדכוני פרמטרים לפי בקשה.

לוח זמנים ועלות משוערים

• מערכת בסיסית: 2 עד 4 שבועות, החל מ-$10,000.
• מורחבת (מספר DEXים, TWAP, הגנת MEV מתקדמת): 4 עד 6 שבועות, החל מ-$25,000.
• קונפיגורציה מותאמת אישית (גשר cross-chain, אוטומציה מותאמת): נדון בנפרד.

העלות מחושבת באופן פרטני לפי מורכבות. באמצעות אופטימיזציית גז, ניתן להשיג חיסכון בעמלות של עד 30%—עבור פרויקט עם נפח buyback של $500k, זה $3,000 בחודש. קבלו הערכת עלות מפורטת לפרויקט שלכם—צרו קשר לייעוץ.

Token burn - ויקיפדיה — הגדרה בסיסית של המנגנון.