עיצוב מנגנון שריפת טוקנים

שריפת טוקנים אינה מטרה בפני עצמה אלא כלי לניהול היצע. הבעיה ברוב הפרויקטים היא שמנגנון שריפה מתווסף כתחבולה שיווקית ללא קשר למודל הכלכלי. טוקנים נשרפים, ההיצע יורד, אך המחיר לא בהכרח עולה אם הביקוש לא גדל במקביל. אנו מתכננים מנגנונים הקשורים לתועלת אמיתית: לדוגמה, שריפת עמלות על כל עסקה או רכישה חוזרת מהכנסות הפרוטוקול. עם ניסיון של 10+ שנים בפיתוח בלוקצ'יין, ראינו פרויקטים שבהם שריפה רק החמירה את הנזילות—ואחרים שבהם דפלציה יצרה צמיחה בת קיימא.

לפני היישום, חיוני להגדיר איזו התנהגות השריפה אמורה לתמרץ. שריפת עמלות יוצרת דפלציה כאשר הפרוטוקול נמצא בשימוש (BNB, ETH אחרי EIP-1559). רכישה חוזרת ושריפה מקשרת דפלציה להכנסות הפרוטוקול. שריפה לשימוש דורשת השמדת טוקנים כדי לגשת לפונקציונליות. אלה מנגנונים שונים עם תכונות כלכליות שונות. צרו קשר כדי לדון באיזו אפשרות מתאימה לפרויקט שלכם.

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

פרויקטים לא מוצלחים לעיתים קרובות מעתיקים את המנגנון ללא התאמה: הם מטמיעים מס העברה אך שוכחים שהטוקן הופך לבלתי תואם ל-AMMs. או שהם מבצעים רכישה חוזרת רבעונית בשוק הפתוח ללא הגנה מפני MEV. אנו יודעים מניסיון: דפלציה מועילה רק כאשר היא קשורה ישירות לפעילות המשתמשים. לדוגמה, אחד מלקוחותינו יישם שריפת עמלות, שהפחיתה את תנודתיות ההיצע ב-20% והגדילה את ה-TVL.

איך לבחור את מנגנון השריפה הנכון

הבחירה מסתכמת בשני פרמטרים: מקור הכספים (עמלות או הכנסות) ותדירות רצויה. שריפת עמלות היא רציפה; רכישה חוזרת היא בדידה. אנו עוזרים למודל שני תרחישים ולבחור את האופטימלי בהתחשב במאפיינים שלכם.

EIP-1559: דוגמה קנונית לשריפת עמלות

אחרי ה-hard fork של לונדון, את'ריום שורף את העמלה הבסיסית של כל בלוק. המנגנון אלגנטי: משתמשים משלמים עמלה בסיסית (דינמית, תלויה בעומס הרשת) בתוספת עמלת עדיפות (לכורים/מאמתים). העמלה הבסיסית נשרפת—מוסרת לצמיתות מהמחזור. עמלת העדיפות הולכת למאמת. זהו עיצוב נכון: שריפה קשורה ישירות לתועלת הטוקן (גז לביצוע עסקאות). יותר פעילות => יותר שריפה. השוואה עם גישות אחרות מראה ששריפת עמלות נותנת תאימות טובה יותר ב-90% ל-DeFi מאשר מס העברה. חיסכון בעמלות יכול להגיע ל-40% בפעילות גבוהה.

השוואת מנגנוני שריפה

יישום מנגנוני שריפה

שריפה בסיסית דרך ERC-20

// OpenZeppelin ERC20Burnable import "@openzeppelin/contracts/token/ERC20/extensions/ERC20Burnable.sol";

contract MyToken is ERC20Burnable {
    constructor() ERC20("MyToken", "MTK") {
        _mint(msg.sender, 1_000_000 * 10**18);
    }
    // burn() и burnFrom() наследуются из ERC20Burnable
    // burn(): владелец сжигает свои токены
    // burnFrom(): сжигает с approval (для протокольного использования)
}

// OpenZeppelin ERC20Burnable import "@openzeppelin/contracts/token/ERC20/extensions/ERC20Burnable.sol"; contract MyToken is ERC20Burnable { constructor() ERC20("MyToken", "MTK") { _mint(msg.sender, 1_000_000 * 10**18); } // burn() и burnFrom() наследуются из ERC20Burnable // burn(): владелец сжигает свои токены // burnFrom(): сжигает с approval (для протокольного использования) } ב-ERC-20: מקטין את _burn ואת balanceOf[account]. טוקנים נשלחים ל-totalSupply—כתובת האפס. זו מוסכמה, לא השמדה קריפטוגרפית, אבל היא שקולה: לאף אחד אין את המפתחות ל-address(0).

שריפת עמלות בפרוטוקול

contract Protocol {
    IERC20 public token;
    uint256 public constant FEE_BPS = 50; // 0.5%
    uint256 public constant BURN_SHARE = 50; // 50% fee сжигается

    function executeAction(uint256 amount) external {
        uint256 fee = (amount * FEE_BPS) / 10000;
        uint256 burnAmount = (fee * BURN_SHARE) / 100;
        uint256 treasuryAmount = fee - burnAmount;

        // Перевод от пользователя
        token.transferFrom(msg.sender, address(this), amount);

        // Сжигание части fee
        ERC20Burnable(address(token)).burn(burnAmount);

        // Остаток в treasury
        token.transfer(treasury, treasuryAmount);

        // Логика действия с (amount - fee)
        _executeCore(amount - fee);
    }
}

החלטת עיצוב: איזה אחוז מהעמלות לשרוף לעומת לשלוח לאוצר. שריפה של 100% היא מקסימלית דפלציונית אך מונעת מהפרוטוקול הכנסות. BNB Auto-Burn שורף 100% מעמלות BNB Chain רבעונית דרך רכישה חוזרת. בפרויקט אחד, בחרנו בשריפה של 70%, שנתנה אפקט מאוזן: דפלציה שנתית של 15% תוך שמירה על תקציב פיתוח.

רכישה חוזרת ושריפה

הפרוטוקול צובר הכנסות (USDC/ETH), קונה מעת לעת את הטוקן שלו בשוק, ושורף אותו.

contract BuybackBurner {
    IUniswapV2Router02 public router;
    address public token;
    address public revenueToken; // USDC или ETH
    address[] private path;

    constructor(address _router, address _token, address _revenueToken) {
        router = IUniswapV2Router02(_router);
        token = _token;
        revenueToken = _revenueToken;
        path = [_revenueToken, _token];
    }

    function executeBuyback(uint256 revenueAmount, uint256 minTokenOut) external onlyAdmin {
        IERC20(revenueToken).approve(address(router), revenueAmount);
        uint256[] memory amounts = router.swapExactTokensForTokens(
            revenueAmount,
            minTokenOut, // slippage protection
            path,
            address(this),
            block.timestamp + 300
        );
        uint256 tokensBought = amounts[amounts.length - 1];
        ERC20Burnable(token).burn(tokensBought);
        emit BuybackExecuted(revenueAmount, tokensBought);
    }
}

Slippage ו-MEV. רכישה חוזרת גדולה נראית ב-mempool—front-runners קונים לפניכם, אתם קונים במחיר גבוה יותר, הם מוכרים. פתרונות: שימוש באגרגטור DEX (1inch), mempool פרטי (Flashbots Protect), או פיצול הרכישה החוזרת לחלקים קטנים דרך TWAP.

מס העברה דפלציוני

כל העברה שורפת X%—פופולרי על ידי memecoins. הבעיה עם מס העברה: חוסר תאימות לרוב פרוטוקולי ה-DeFi. Uniswap V2 אינו תומך בטוקנים עם fee-on-transfer כראוי ללא פרמטרים מיוחדים. Uniswap V3 אינו תומך בהם כלל. Aave, Compound אינם מקבלים fee-on-transfer כבטוחה. זהו מגבלה יסודית: מס העברה מבודד את הטוקן ממערכת האקולוגית של DeFi.

לוח זמנים לשריפה: בדיד לעומת רציף

שריפה בדידה (רכישה חוזרת רבעונית, שריפה מבוססת תקופות): צפויה, יוצרת אירועים צפויים בשוק. סיכון: front-running לפני תאריכים ידועים.

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

מודל כלכלי

לפני יישום מנגנון שריפה, נדרש מודל כמותי. פרמטרים מינימליים:

כלים: TokenTerminal, Dune Analytics למודל על נתונים היסטוריים של פרוטוקולים דומים. מודל גיליון אלקטרוני עם Monte Carlo לרגישות.

התהליך שלנו

1. עיצוב כלכלי (1–2 שבועות). קביעת סוג המנגנון למודל הפרוטוקול הספציפי שלכם. בניית מודל דינמיקת היצע כמותי.
2. פיתוח (1–3 שבועות). מנגנון שריפה בחוזה הטוקן או בחוזה Burner נפרד. בדיקות על מקרי קצה: שריפת כמות 0, שריפה מעבר ליתרה, reentrancy בגביית עמלות.
3. מיקוד ביקורת. בדיקה: אין אפשרות לתמרן מחיר אורקל דרך שריפה (אם totalSupply משמש בחישובים), הרשאות נכונות לקריאות שריפה, הגנה על רכישה חוזרת מהתקפות sandwich.

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

לוחות זמנים: 3 עד 6 שבועות תלוי במורכבות המנגנון. העלות מחושבת באופן אישי—אנו מעריכים לאחר brief. אנו מבטיחים איכות ביקורת: החוזים שלנו עוברים בדיקות Slither ו-Echidna fuzzing. לצוות שלנו יש 10+ פרויקטי בלוקצ'יין בייצור. בקשו ייעוץ כדי לדון בפרויקט שלכם.

מה כלול

• מודל כלכלי עם Monte Carlo
• קוד מקור של חוזה חכם (Solidity 0.8.x)
• ערכת בדיקות (Hardhat, Mocha)
• תיעוד אינטגרציה
• מיקוד ביקורת והמלצות הגנה
• תמיכה בפריסה

קבלו ייעוץ—כתבו לנו, נדון בטוקונומיקה שלכם ונבחר מנגנון שריפה מתאים במפתח מלא.