Разработка системы доступа к 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. Это incentivizes долгосрочный lock, снижая circulating supply 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 с рынка и сжигания. Снижает supply → при стабильном demand цена растёт. Прозрачно и понятно инвесторам.

Fee distribution. Прямая выплата fee держателям staked/locked G-token. Требует lock mechanism чтобы не стимулировать краткосрочный dump после получения distribution.

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

Protocol-owned liquidity (POL). Olympus паттерн: протокол владеет своей ликвидностью через bonding mechanism. Пользователи продают 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 vote for gauge weights
    mapping(address => mapping(address => uint256)) public voteUserSlopes;
    mapping(address => uint256) public gaugeWeights;
    
    function voteForGaugeWeights(address gauge, uint256 userWeight) external {
        // userWeight из 10000 (базисные пункты)
        // Пользователь распределяет свой 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 можно receive на любой chain.

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

Supply accounting. Suply 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).