Розробка системи доступу до VPN через токени

Розробка мультитокенної екосистеми

Більшість протоколів, досягаючи певної зрілості, приходять до мультитокенної архітектури. Один токен не може одночасно бути хорошим засобом обміну (потрібна стабільність), інструментом governance (потрібна концентрація у довгострокових учасників) та інструментом поощрення (потрібна інфляція для привабення ліквідності). Спроба поєднати все в одному токені створює протиріччя — це Curve Finance зрозумів та створив три токени (CRV, veCRV, cvxCRV), Olympus — два (OHM, sOHM), MakerDAO — два (DAI, MKR).

Мультитокенна екосистема потребує тщательного проектування взаємодій між токенами. Неправильний дизайн створює смерть-спіраль (наприклад, коллапс UST/LUNA у травні 2022). Правильний — стійкі токеномічні петлі, де кожний токен виконує свою роль.

Типологіі мультитокенних систем

Governance + Utility розділення

Класичне розділення: governance token (G-token) та utility/protocol token (U-token).

G-token: управління протоколом, capturing value (fee share), довгостроковий hold incentive. Часто vote-escrowed (ve-модель Curve): locked G-token дає veG з boost на rewards та governance power.

U-token: medium of exchange всередині протоколу, стабільний (або менш волатильний), висока швидкість обігу. Наприклад: торговельні комісії беруться в U-token, liquidity rewards виплачуються в G-token.

Приклад потоку стоимості:

Торговельна активність → Protocol fees (у U-token або ETH)
           ↓
Fee distribution → buyback G-token → burn або distribute veG холдерам

Холдери veG отримують: fee share + boosted liquidity rewards + governance power. Це стимулює довгостроковий lock, знижуючи циркулюючу пропозицію G-token та створюючи buy pressure.

Debt-based стабільні системи

Паттерн MakerDAO: collateral token (ETH, wBTC) → debt position → стабільна монета (DAI) + governance token (MKR).

Системні ризики:

• При падінні ціни коллатералю → liquidations → dump коллатералю → ще більше падіння
• При системній нехватці коллатералю (bad debt) → mint та продаж MKR для рекапіталізації → dump ціни MKR

Це не баг, а feature: MKR є страховкою останньої інстанції. Холдери MKR мають governance power та отримують stability fees — в обмін приймають хвістовий ризик рекапіталізації. Правильна токеноміка.

Liquid staking дуальні токени

Staked token (stETH, rETH) представляє застейковані активи з растучим rebasing балансом або exchange rate. Governance token управляє параметрами стейкінгу протоколу.

Взаємодія: staked token генерує staking rewards → частина йде в protocol treasury → buyback/burn або distribute governance token. Governance token holders контролюють validator selection, fee parameters, protocol upgrades.

Проектування токеномічних петель

Value capture механізми

Кожний токен повинен мати ясний механізм value capture — інакше його ціна визначається тільки спекуляцією:

Buyback and burn. X% від protocol revenue використовується для buyback G-token з ринку та його сжигання. Знижує пропозицію → при стабільному demand ціна зростає. Прозорево та зрозуміло інвесторам.

Fee distribution. Прямий fee payout стейкованим/locked G-token холдерам. Потребує lock механізму, щоб не стимулювати краткосрочний dump після отримання distribution.

Governance premium. G-token необхідний для отримання boost на yield або доступу до певних функцій. Створює utility demand крім спекулятивного.

Protocol-owned liquidity (POL). Olympus паттерн: протокол володіє своєю ліквідністю через bonding механізм. Користувачі продають LP tokens у treasury за дисконтований G-token (з vesting). Treasury володіє ліквідністю навсегда, не арендує її в mercenary capital.

Аналіз смерть-спіралей

Перед запуском кожна мультитокенна дизайн повинна бути протестована на stress scenarios:

Сценарій 1: Швидке падіння G-token на 80%.

• Що відбувається з locked стейкерами? Є ли panic unlock механізм?
• Впливає ли на U-token стабільність?
• Як ведуть себе liquidity rewards (у G-token — теряють ценність, TVL падає)?

Сценарій 2: Набег на U-token (bank run).

• Достатньо ли ліквідності для redemption?
• Є ли circuit breaker (тимчасовий pause redemption)?
• Як це впливає на G-token?

Сценарій 3: Oracle failure.

• Якщо ціна коллатералю стала некоректною — що відбувається з debt positions?
• Є ли emergency shutdown?

Simulation: Agent-based modeling або Monte Carlo для перевірки stability при різних market conditions. Gauntlet, Chaos Labs — спеціалізовані компанії для такого аналізу.

Технічний стек контрактів

Token контракти

G-token (ERC20Votes): стандартний governance token з checkpoint історією для голосування.

veG (Vote-Escrowed): користувач локує G-token на строк (1 тиждень — 4 роки), отримує veG пропорційно amount × time_remaining / max_lock_time. veG убувває лінійно зі часом (потребує продовження lock). Non-transferable (soulbound-like).

contract VotingEscrow {
    struct LockedBalance {
        int128 amount;
        uint256 end; // unlock timestamp
    }
    
    mapping(address => LockedBalance) public locked;
    
    // veBalance убувває лінійно до нуля до unlock time
    function balanceOf(address addr) external view returns (uint256) {
        LockedBalance memory _locked = locked[addr];
        if (_locked.end <= block.timestamp) return 0;
        
        uint256 timeLeft = _locked.end - block.timestamp;
        return uint256(uint128(_locked.amount)) * timeLeft / MAXTIME;
    }
}

U-token: залежить від типу. Якщо стабільна монета — CDP (collateralized debt position) контракт з liquidation engine. Якщо rebasing staked token — vault контракт з shares-based accounting (ERC4626).

Fee Router

Центральний контракт, що збирає fees та розповсюджує по протоколу:

contract FeeRouter {
    struct FeeDistribution {
        address recipient;
        uint256 basisPoints; // з 10000
    }
    
    FeeDistribution[] public distributions;
    
    function distributeFees(address token, uint256 amount) external {
        for (uint i = 0; i < distributions.length; i++) {
            uint256 share = amount * distributions[i].basisPoints / 10000;
            IERC20(token).safeTransfer(distributions[i].recipient, share);
        }
    }
}

Distributions конфігруються через governance. Типові отримувачі: veG stakers reward pool, buyback contract, treasury, liquidity rewards distributor.

Gauge та Rewards система

Curve-style gauges: для кожного supported pool — окремий gauge контракт. Холдери veG голосують за distribution G-token emissions між gauges (gauge weight). Pool з більшим вагом отримує більше G-token emissions → вищий APY → привабує більше ліквідності.

Це створює "gauge wars": протоколи, які бажають мати deep ліквідність свого токена, купують veG та голосують за свій gauge. Convex Finance побудував цілий протокол поверх цієї механіки.

contract GaugeController {
    // veG holders голосують за gauge weights
    mapping(address => mapping(address => uint256)) public voteUserSlopes;
    mapping(address => uint256) public gaugeWeights;
    
    function voteForGaugeWeights(address gauge, uint256 userWeight) external {
        // userWeight з 10000 (basis points)
        // Користувач розповсюджує свій veG vote power
    }
    
    function getGaugeWeight(address gauge) external view returns (uint256) {
        return gaugeWeights[gauge]; // перераховується щотижня
    }
}

Мультичейн токеноміка

При деплої на кілька чейнів виникають додаткові складнощі:

Canonical token. G-token — canonical на mainnet Ethereum. На L2 (Arbitrum, Optimism, Base) — bridged версія через official bridge. Governance voting відбувається тільки на mainnet (де зберігається veG). Але rewards можна отримувати на будь-якому chain.

Cross-chain rewards distribution. Merkle-based: раз на тиждень snapshot veG holdings на mainnet → Merkle root опублікований → користувачи claim rewards на будь-якому chain через proof. LayerZero або CCTP для cross-chain messaging якщо потрібна більш realtime синхронізація.

Supply accounting. Supply G-token повинен враховуватися агрегованим по всім chainам. Total supply на mainnet — canonical джерело істини, bridged tokens на L2 backed 1:1 через bridge escrow.

Governance мультитокенної екосистеми

При кількох токенах governance складніше: хто управляє параметрами (fee rates, emission schedule, gauge weights)?

Рекомендоване розділення:

Multisig guardian з veto/pause power — на перехідному періоді поки governance не обкатан. Roadmap до повної decentralization з конкретними датами — важливий для community trust.

Аудит та ризики

Мультитокенна система — множення attack surface. Кожний токен, кожний їхній інтерфейс — потенційна точка уразливості. Історично значимі взломи:

• Beanstalk ($182M, 2022): governance attack через flash loan. Злоумисник занив токени, пройшов governance vote в одному блоці, слив treasury.
• Mango Markets ($116M, 2022): oracle price manipulation → штучно завищений collateral → drain treasury через borrowing.

Специфічні аудит вимоги для мультитокенних систем:

• Invariant testing для кожної взаємодії токенів
• Flash loan attack simulation на governance
• Oracle manipulation scenarios
• Cross-chain bridge security review (якщо multi-chain)

Мінімум два незалежних аудити від різних компаній + публічний contest (Code4rena, Sherlock) для широкого охвату.

Стек та терміни

Smart contracts: Solidity + Foundry + OpenZeppelin + Curve VotingEscrow fork (або Solidly fork для gauge system).

Testing: Foundry invariant tests, Echidna fuzzing, Foundry fork-tests на mainnet стані для realistic scenarios.

Deployment: Hardhat Ignition або Foundry scripts з детальним deployment runbook (порядок деплоя контрактів важливий — залежності).

Повна мультитокенна екосистема з двома незалежними аудитами — 9-12 місяців від початку проектування до mainnet launch. Термін сильно залежить від складності U-token компонента (stablecoin vs staked asset).