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

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

Запитання «якою повинна бути пропозиція» — це одне з тих запитань, на які впевнено відповідають люди, які не розуміються на темі. «Фіксована пропозиція = рідкість = вартість» — це спрощення, яке ігнорує корисність токена. «Інфляція потрібна для винагород учасникам» — це правда, але без обмежень інфляція знищує всіх інших лримачів.

Правильна відповідь залежить від того, чим є токен: середовищем обміну в протоколі, інструментом governance, staking активом, або чимось іншим. Механізм пропозиції повинен обслуговувати економіку протоколу, а не бути самоцеллю.

Інфляційні моделі

Фіксована емісія

Найпростіший варіант: N токенів в рік, завжди. Ethereum до Merge мав ~4.5% річну інфляцію через block rewards. Проблема: фіксована абсолютна емісія при зростаючій locked пропозиції означає зменшення circulating інфляції — добре. Але при падінні ціни і постійних витратах у долларах на майнінг/валідацію — економіка рвется.

Спадна емісія (Halvings)

Bitcoin: 210,000 блоків (~4 року) — halving. Всього ~21M BTC. Передбачуване, зрозуміле ринком. Мінус: halvings створюють шок для майнерів, перехід на fee-only модель потребує високої пропускної здатності транзакцій.

Для application токенів 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 розподілу — більше токенів йде на ринки з високою borrow утилізацією.

Дефляційні механізми

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

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

Для application tokena: беремо X% комісій протоколу і спалюємо:

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 використовує цей механізм: квартальні burns на основі BNB Chain доходу. Це працює, якщо протокол генерує реальні комісії.

Buyback-and-Burn

Казна протоколу використовує частину доходу для купівлі токенів на ринку і їх спалювання. Більш передбачувано для власників (можна прогнозувати), але потребує ліквідного ринку.

Уразливість: buyback — це по суті повернення вартості власникам, які продають. Ті, хто тримає — отримують користь через зменшену пропозицію. У деяких юрисдикціях buyback токена може класифікуватися як buyback цінного папера зі всіма наслідками.

Fee на трансфер (Transfer Tax)

Популяризовано Safemoon-like токенами. При кожному трансфері 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 змінює пропозицію для всіх власників одночасно (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 токени (Aave, Compound роблять це через wrapped версії).

Порівняння моделей

Проектування механіки пропозиції — це не технічне запитання. Технічно реалізується будь-яка модель. Запитання в тому, які поведінкові incentives вона створює для стейкерів, постачальників ліквідності, довгострокових власників та трейдерів — і відповідають вони цілям протоколу?