Проектирование механизмов инфляции/дефляции токена

Проектирование механизма инфляции/дефляции токена

Вопрос «какой должен быть supply» — один из тех, на которые дают уверенный ответ люди, не разбирающиеся в теме. «Фиксированный supply = редкость = ценность» — это упрощение, которое игнорирует utility токена. «Инфляция нужна для вознаграждения участников» — это правда, но без ограничений инфляция уничтожает все другие держатели.

Правильный ответ зависит от того, чем является токен: средством обмена в протоколе, governance инструментом, staking активом, или чем-то ещё. Механизм supply должен обслуживать экономику протокола, а не быть самоцелью.

Инфляционные модели

Фиксированная эмиссия

Простейший вариант: N токенов в год, всегда. Ethereum до Merge имел ~4.5% годовую инфляцию через block rewards. Проблема: фиксированная абсолютная эмиссия при растущем locked supply означает уменьшающийся circulating inflation — это хорошо. Но при падении цены и constant-dollar затратах на mining/validating — экономика рвётся.

Убывающая эмиссия (halvings)

Bitcoin: 210,000 блоков (≈4 года) — halving. Итого ~21M BTC. Предсказуемо, понятно рынку. Минус: halvings создают шок для майнеров, переход к fee-only модели требует высокого transaction throughput.

Для application tokens halvings часто не нужны — они создают циклические спекулятивные нарративы вместо устойчивой экономики.

Алгоритмическая эмиссия на основе метрик

Более продвинутая модель: эмиссия зависит от состояния протокола.

contract AdaptiveMinter {
    uint256 public targetUtilization = 7000; // 70% в basis points
    uint256 public baseEmissionPerBlock = 1e18;
    
    function calculateEmission() public view returns (uint256) {
        uint256 currentUtilization = protocol.getUtilizationRate(); // в basis points
        
        if (currentUtilization >= targetUtilization) {
            // Высокая утилизация → больше токенов для привлечения участников
            uint256 excess = currentUtilization - targetUtilization;
            return baseEmissionPerBlock + (baseEmissionPerBlock * excess / 10000);
        } else {
            // Низкая утилизация → меньше инфляции
            uint256 deficit = targetUtilization - currentUtilization;
            uint256 reduction = baseEmissionPerBlock * deficit / 10000;
            return baseEmissionPerBlock > reduction 
                ? baseEmissionPerBlock - reduction 
                : 0;
        }
    }
}

Compound использует похожую логику для COMP distribution — больше токенов идёт в markets с высоким borrow utilization.

Дефляционные механизмы

EIP-1559 стиль: burn из комиссий

Ethereum после EIP-1559 сжигает baseFee при каждой транзакции. При высокой нагрузке сеть дефляционна — supply уменьшается быстрее, чем выпускается через staking rewards. Это элегантно: burn масштабируется с использованием сети.

Для application token: берёшь X% от protocol fees и сжигаешь:

function _distributeFees(uint256 feeAmount) internal {
    uint256 burnAmount = feeAmount * burnRateBps / 10000;
    uint256 treasuryAmount = feeAmount * treasuryRateBps / 10000;
    uint256 stakersAmount = feeAmount - burnAmount - treasuryAmount;
    
    ERC20Burnable(token).burn(burnAmount);
    token.transfer(treasury, treasuryAmount);
    stakingRewards.notifyRewardAmount(stakersAmount);
}

BNB использует этот механизм: quarterly burns на основе BNB Chain revenue. Это работает, если протокол генерирует реальные fees.

Buyback-and-burn

Protocol treasury использует часть revenue для выкупа токенов с рынка и сжигания. Более предсказуемо для держателей (можно прогнозировать), но требует ликвидного рынка.

Уязвимость: buyback — это фактически возврат стоимости держателям, которые продают. Те, кто держит — получают benefit через reduced supply. В некоторых юрисдикциях buyback токена может классифицироваться как buyback ценной бумаги со всеми вытекающими.

Fee на трансфер (transfer tax)

Popularized Safemoon-like tokens. При каждом трансфере X% сжигается или перераспределяется. Технически:

function _transfer(address from, address to, uint256 amount) internal override {
    if (_isExcludedFromFee[from] || _isExcludedFromFee[to]) {
        super._transfer(from, to, amount);
        return;
    }
    
    uint256 burnAmount = amount * burnFeeBps / 10000;
    uint256 netAmount = amount - burnAmount;
    
    super._transfer(from, address(0), burnAmount); // burn
    super._transfer(from, to, netAmount);
}

Проблема: fee на трансфер ломает composability. DEX, lending протоколы, любые смарт-контракты, которые ожидают получить amount и получают amount * (1 - fee) — работают некорректно. Это причина, по которой большинство DeFi протоколов отказываются листить такие токены. Не рекомендуем.

Реребейзинг (Ampleforth модель)

AMPL меняет supply у всех держателей одновременно (rebase), сохраняя процентные доли. Цель: привязать покупательную способность, не цену. При rebase +10% у каждого держателя становится на 10% больше токенов, но доля в total supply не меняется.

// Rebase механизм через scaling factor
uint256 private _totalSupply;
uint256 private constant INITIAL_FRAGMENTS_SUPPLY = 5e6 * 1e9;
uint256 private _gonsPerFragment;
uint256 private constant MAX_UINT256 = type(uint256).max;
uint256 private constant TOTAL_GONS = MAX_UINT256 - (MAX_UINT256 % INITIAL_FRAGMENTS_SUPPLY);

// balanceOf через gons
function balanceOf(address account) public view returns (uint256) {
    return _gonBalances[account] / _gonsPerFragment;
}

function rebase(int256 supplyDelta) external onlyMonetaryPolicy returns (uint256) {
    if (supplyDelta < 0) {
        _totalSupply -= uint256(-supplyDelta);
    } else {
        _totalSupply += uint256(supplyDelta);
    }
    _gonsPerFragment = TOTAL_GONS / _totalSupply;
    emit Rebase(epoch, _totalSupply);
    return _totalSupply;
}

Rebase также ломает composability — DeFi протоколы должны явно поддерживать rebasing tokens (Aave, Compound делают это через wrapped versions).

Сравнение моделей

Проектирование supply механики — это не технический вопрос. Технически реализуется любая модель. Вопрос в том, какие поведенческие incentives она создаёт для стейкеров, поставщиков ликвидности, долгосрочных держателей и трейдеров — и соответствуют ли они целям протокола.