Розробка токеноміки DePIN-проекту

Розробка токеноміки DePIN-проекту

DePIN (Decentralized Physical Infrastructure Networks) — це протоколи, де фізичне обладнання (сенсори, роутери, GPU, сонячні панелі, камери) управляється економічними стимулами через токен. Helium (бездротові мережі), Filecoin (сховища), Render (GPU), DIMO (автомобільні дані), Hivemapper (картографія) — різні реалізації однієї ідеї.

Токеноміка DePIN проекту принципово відрізняється від DeFi або gaming токенів. Основні учасники — це фізичні провайдери з реальними капітальними витратами (купити залізо, заплатити за електроенергію). ROI для провайдера повинен бути економічно обґрунтований, інакше мережа не вирастить. Це не «вайтпейпер з красивими цифрами» — це бізнес-модель з робочою unit economics.

Двосторонній ринок: провайдери та споживачі

DePIN це marketplace. Одна сторона: провайдери фізичної інфраструктури. Інша: споживачі послуг. Токен повинен координувати обидві сторони.

Проблема холодного старту: спочатку немає провайдерів, значит немає послуг, значит немає споживачів, значит немає доходу провайдерам. Класичний chicken-and-egg. Рішення в більшості DePIN — інфляційні token-субсидії на ранній стадії: провайдери отримують токени за надання інфраструктури до появи реального спросу.

Ключове питання: коли token-субсидії замінюються реальним protocol revenue? Якщо цей перехід не спроектований — токен буде падати нескінченно (див. більшість DePIN 2022–2023).

Proof of Coverage: верифікація фізичної роботи

Центральна проблема будь-якого DePIN — провайдер заявляє, що його пристрій працює та надає послугу. Як верифікувати це on-chain без довіри?

Підходи до верифікації

Cryptographic beacon verification (Helium): спеціалізовані пристрої відправляють RF beacon, сусідні пристрої його отримують та звітуються. Фізичне розташування верифікується через радіосигнал, підробити який складно без фізичної присутності.

Challenge-response з геолокацією: пристрій повинен відповісти на випадкове challenge, включаючи GPS-координати та timestamp. Відповідь підписана TPM-чипом. Верифікатор перевіряє: координати правдоподібні? Затримка відповіді відповідає фізичній відстані?

Data proof через sampling (Hivemapper): картографічні дані від провайдера порівнюються з еталонними або між кількома незалежними провайдерами одного маршруту. Статистично аномальні дані — slashing.

Trusted Hardware (TEE): пристрій містить secure enclave, що підписує proof of work з attestation. Chainlink DECO забезпечує приватні oracle proofs через TLS.

contract ProofOfCoverage {
    struct DeviceRegistration {
        address operator;
        bytes32 devicePublicKey;    // публічний ключ TPM пристрою
        bytes32 locationHash;       // хеш географічної позиції
        uint256 registeredAt;
        bool active;
        uint256 totalProofsSubmitted;
        uint256 reputationScore;    // 0-1000
    }
    
    struct CoverageProof {
        bytes32 deviceId;
        uint256 timestamp;
        bytes32 challengeHash;      // хеш випадкового challenge
        bytes deviceSignature;      // підпис TPM
        int32 latitude;
        int32 longitude;
        bytes32 dataHash;           // хеш надісланих даних
    }
    
    mapping(bytes32 => DeviceRegistration) public devices;
    mapping(bytes32 => uint256) public lastProofTimestamp;
    
    uint256 public constant PROOF_INTERVAL = 1 hours;
    uint256 public constant MIN_REPUTATION_TO_EARN = 200;
    
    function submitCoverageProof(
        CoverageProof calldata proof,
        bytes32[] calldata witnessDevices  // сусідні пристрої
    ) external {
        bytes32 deviceId = proof.deviceId;
        DeviceRegistration storage device = devices[deviceId];
        
        require(device.active, "Device not registered");
        require(device.operator == msg.sender, "Not operator");
        require(
            block.timestamp >= lastProofTimestamp[deviceId] + PROOF_INTERVAL,
            "Too soon"
        );
        
        // Верифікуємо підпис пристрою
        bytes32 proofHash = keccak256(abi.encodePacked(
            proof.challengeHash,
            proof.timestamp,
            proof.latitude,
            proof.longitude,
            proof.dataHash
        ));
        
        require(
            _verifyDeviceSignature(device.devicePublicKey, proofHash, proof.deviceSignature),
            "Invalid device signature"
        );
        
        lastProofTimestamp[deviceId] = block.timestamp;
        device.totalProofsSubmitted++;
        
        // Вознаграджуємо пропорційно репутації
        if (device.reputationScore >= MIN_REPUTATION_TO_EARN) {
            _distributeReward(device.operator, device.reputationScore, witnessDevices);
        }
        
        emit ProofSubmitted(deviceId, block.timestamp, proof.dataHash);
    }
}

Емісійна модель: від субсидій до protocol revenue

Фази життєвого циклу

Фаза 1: Bootstrap (0–2 роки)

Висока інфляція для привернення провайдерів. Токен це субсидія за раннє участь. ROI провайдера повинен бути позитивним навіть при нульовому реальному спросі.

Типова крива: 30–40% першого року supply йде провайдерам як Bootstrap Rewards. Емісія зменшується по halving-кривій або степеневій функції.

def emission_schedule(epoch: int, base_emission: float, decay_rate: float) -> float:
    """
    epoch: номер періоду (тиждень/місяць)
    base_emission: початкова емісія
    decay_rate: коефіцієнт зниження (0.95 = зниження на 5% кожен період)
    """
    return base_emission * (decay_rate ** epoch)

# Приклад: 1,000,000 токенів у тиждень 1, зниження 2% щотижня
total_4_years = sum(emission_schedule(i, 1_000_000, 0.98) for i in range(208))
# ~26,700,000 токенів за 4 роки на bootstrap rewards

Фаза 2: Transition (2–4 роки)

Protocol revenue починає покривати частину наград. Інфляція зменшується. Ключовий KPI: Protocol Revenue / Total Token Emissions. Якщо це відношення досягає 50%+ — протокол жизнеспособний без субсидій.

Фаза 3: Sustainability (4+ років)

Емісія близька до нуля. Вознаграждення провайдерів із protocol fees. Токен перестає бути інфляційним.

Розрахунок ROI провайдера

Для обґрунтованої токеноміки потрібно змоделювати unit economics провайдера:

Вартість обладнання: $500 (сенсорний пристрій)
Щомісячна електроенергія: $5
Щомісячні вознаграждення: X токенів × ціна токена

Breakeven: (500 + 5 × місяців) / (X × ціна_токена) = місяці

Якщо breakeven > 18 місяців при реалістичній ціні токена — провайдери не будуть участвувати. Токеноміка повинна забезпечити breakeven 6–12 місяців при conservative оцінці ціни.

Helium провалився саме тут: hotspot коштував $500, вознаграждення упали, ROI став негативним, провайдери відключили пристрої, мережа деградувала.

Структура token-розподілу для DePIN

Критично: Network Rewards не маркетинг. Це операційний бюджет привернення фізичних ресурсів. 40–55% правильний діапазон для DePIN, на відміну від gaming де 20–30% достатньо.

Підкатегорії провайдерів та диференціація наград

Не всі пристрої однаково цінні. Геолокація, технічна якість, uptime впливають на цінність внеску.

contract RewardDistribution {
    enum CoverageZone { Oversupplied, Normal, Undersupplied, Critical }
    
    // Множники наград по зонах
    mapping(CoverageZone => uint256) public zoneMultipliers;
    
    constructor() {
        zoneMultipliers[CoverageZone.Oversupplied] = 50;   // 0.5x
        zoneMultipliers[CoverageZone.Normal] = 100;         // 1x
        zoneMultipliers[CoverageZone.Undersupplied] = 200;  // 2x
        zoneMultipliers[CoverageZone.Critical] = 500;       // 5x
    }
    
    function calculateReward(
        bytes32 deviceId,
        uint256 baseReward,
        uint256 uptimePercent,  // 0-100
        CoverageZone zone
    ) public view returns (uint256) {
        uint256 uptimeMultiplier = uptimePercent; // 95% uptime = 0.95x
        uint256 zoneMultiplier = zoneMultipliers[zone];
        uint256 reputationMultiplier = devices[deviceId].reputationScore; // 0-1000
        
        return baseReward 
            * uptimeMultiplier / 100
            * zoneMultiplier / 100
            * reputationMultiplier / 1000;
    }
}

Геозонування — потужний інструмент управління розповсюдженням мережі. Якщо у Токіо 1000 пристроїв а у Найробі 5 — множник у Найробі повинен бути кратно вищим.

Механізм сжигання та buyback

Контроль інфляції через дефляційні механізми:

Burn від protocol fees: споживачі платять за послуги у токені (або stablecoin з buyback-burn). Частина платежу спалюється. Створює зв'язок: більше використання → більше burn → менше інфляція.

Staking для провайдерів: обов'язковий stake для реєстрації пристрою. Замораживає частину supply. При плохій поведінці — slashing (slashed токени burn або іють у insurance fund).

Governance-controlled burn rate: DAO може голосувати за зміну % burn від fees по мірі зростання мережі.

Сезонність та цикличність

DePIN мережі мають фізичну сезонність: зимою в північних регіонах менше трафіку (Hivemapper), влітку вища споживання енергії тощо. Токеноміка повинна враховувати це через динамічні параметри наград або буферні резерви.

Governance структура

DePIN протоколи управляють реальною фізичною інфраструктурою. Governance повинен мати механізми:

• Оновлення зональних параметрів (множники наград)
• Зміна мінімальних вимог до пристроїв (технічні стандарти)
• Emergency pause при обнаруженні масового sybil attack
• Treasury розподіл для екосистемних грантів

Timelock на governance actions обов'язково. Зміни параметрів наград напрямку впливають на економіку провайдерів, вони повинні мати час адаптуватися.

Математичне моделювання

Перед фіналізацією токеноміки — обов'язкове моделювання в Python/Excel:

• Скільки провайдерів потрібно для досягнення product-market fit
• При якій кількості провайдерів наступає oversupply (вознаграждення падають нижче breakeven)
• Як буде змінюватися ціна токена при різних сценаріях зростання

import numpy as np

def simulate_depin(
    initial_providers: int,
    growth_rate_monthly: float,
    monthly_emission: float,
    token_price_init: float,
    price_elasticity: float  # як спрос впливає на ціну
) -> list:
    """Спрощена симуляція DePIN економіки"""
    
    results = []
    providers = initial_providers
    token_price = token_price_init
    
    for month in range(48):  # 4 роки
        monthly_rewards = monthly_emission / providers
        monthly_roi = (monthly_rewards * token_price) / DEVICE_COST
        
        # Провайдери додаються якщо ROI > threshold
        if monthly_roi > 0.05:  # 5% місячний ROI = 60% річних
            new_providers = int(providers * growth_rate_monthly)
        else:
            new_providers = -int(providers * 0.02)  # відтік при плохому ROI
        
        providers = max(providers + new_providers, 1)
        
        # Ціна падає від інфляції, зростає від спросу
        supply_pressure = monthly_emission / (providers * 10)  # умовна модель
        token_price = token_price * (1 - supply_pressure) * (1 + price_elasticity * monthly_roi)
        
        results.append({
            "month": month,
            "providers": providers,
            "token_price": token_price,
            "monthly_roi": monthly_roi
        })
    
    return results

Таймлайн розробки

Дослідження та проектування (3–5 тижнів): конкурентний аналіз (Helium, DIMO, Hivemapper, Render), розробка Proof of Coverage механіки, unit economics провайдера, емісійна модель, математичне моделювання сценаріїв.

Смарт-контракти (4–8 тижнів): device registry, proof submission, reward distribution, staking/slashing, governance.

Аудит та тестування (3–4 тижні): обов'язковий зовнішній аудит для контрактів управління staking та slashing.

Всього: 2.5–4 місяці до production-ready токеноміки з робочими контрактами. Маркетинговий вайтпейпер та документація окремо.