GameFi розробка: ігрова економіка, контракти та on-chain механіка
Ми бачили цей сценарій не раз. Axie Infinity на піку мала великий дохід, але через 18 місяців токен різко знецінився, а аудиторія значно скоротилася. Причина — відсутність sink'ів: гравці заробляли SLP і виводили, а механізмів спалювання не вистачало. Ми пропонуємо GameFi розробку під ключ: від токеноміки до смарт-контрактів, щоб ваша економіка не повторила цю помилку. Оцінимо ваш проєкт на meetup або онлайн. Наш досвід — 5+ років, десятки реалізованих проєктів, включно з аудитом 15+ P2E ігор.
Чому ламається Play-to-Earn економіка?
Інфляційна токеноміка без sink'ів — головна причина смертельної спіралі. Гравець отримує токени за геймплей. Якщо sink'ів (механізмів спалювання або споживання) недостатньо — supply зростає швидше за demand. Ціна падає. Дохід гравця у fiat зменшується. Гравці йдуть.
Правильна конструкція — dual-token модель з чітким розподілом: governance/value token з обмеженим supply і utility/reward token для внутрішньоігрової економіки. Utility token має активно споживатися: крафтинг предметів, апгрейди, entry fees, breeding. Приклади: GODS/FLUX у Gods Unchained, AXS/SLP у Axie (хоча sink'ів там виявилося недостатньо). Ефективна економіка балансує mint та burn: типовий ratio — 1.2—1.5 burn на 1 mint для запобігання інфляції.
Які sink-механізми реально працюють?
| Механізм | Опис | Приклад |
|---|---|---|
| Breeding / крафтинг | Спалювання utility token за створення нового NFT | Axie (але з правильним balancing) |
| Апгрейди персонажів | Кожна еволюція вимагає спалювання токена | Більшість P2E RPG |
| PvP entry fee | Вхід у турнір спалює токени, частина йде в призовий пул | Splinterlands |
| Дурабилити предметів | Після N боїв предмет ламається, токен витрачається на ремонт | Успадковано з MMORPG |
| Фінансові механіки | Стейкінг з lock-up, що виводить токени з обігу на строк | DeFi-шари |
Наш досвід — десятки реалізованих проєктів у Web3, включно з аудитом 15+ P2E ігор. Ми знаємо, які sink'и працюють у довгостроковій перспективі. Наприклад, у проєкті з breeding RPG ми збільшили спалювання utility token на 300% за рахунок введення «ремеслу зношуваності» та обов'язкових апгрейдів.
On-chain vs Off-chain: де проходить межа
Всю ігрову логіку on-chain виносити не потрібно — кожна транзакція коштує газу і триває 12 секунд. Ігровий цикл — мілісекунди. Баланс:
| Компонент | On-chain | Off-chain | Приклади |
|---|---|---|---|
| Ownership активів | + | – | NFT предмети, land |
| Передача/торгівля | + | – | Маркетплейси |
| Фінанси (стейкінг, rewards) | + | – | Staking vaults, DAO |
| Random generation | + (через VRF) | – | Chainlink VRF |
| Ігровий процес | – | + | Бойова система, рух |
| State ігрового світу | – | + | Координати, health points |
| Матчмейкінг | – | + | Серверна логіка |
Результати геймплею переносяться на блокчейн через signed message від сервера або ZK-proof. Verifiable off-chain з ZK: ігровий сервер генерує ZK-proof коректності сесії, контракт верифікує proof і нараховує винагороду. Реалізації: Cartridge (Starknet), zkSync game rollups.
Реалізація NFT ігрових предметів
Стандарт: ERC-1155 для взаємозамінних предметів (ресурси, consumables) + ERC-721 для унікальних (персонажі, land). ERC-1155 дає до 60% економії на газі при batch transfer у порівнянні з окремими ERC-721 переказами — для гри з сотнями предметів це економія сотень доларів на день.
Як реалізувати динамічні NFT без перевантаження блокчейна?
Характеристики предмета змінюються в процесі гри (experience, durability, upgrades). Два підходи:
- Fully on-chain: атрибути зберігаються в mapping контракту,
tokenURIгенерується з атрибутів через SVG/JSON encoding. Дорого за газом при частому оновленні. Використовується для land і ключових активів. - Hybrid: атрибути зберігаються off-chain, в
tokenURI— hash стану. Оновлення підписується сервером, верифікується on-chain при transfer або продажі. Дешевше, але вимагає довіри до сервера або ZK.
Breeding і crafting. Контракт: два батьківських NFT → оплата utility token (burn) → мінт нового NFT з атрибутами, що залежать від батьків + Chainlink VRF для випадковості. Без VRF майнери можуть маніпулювати рандомом через вибір блоку.
// Simplified breeding with Chainlink VRF
function breed(uint256 parent1Id, uint256 parent2Id) external {
require(ownerOf(parent1Id) == msg.sender);
require(ownerOf(parent2Id) == msg.sender);
require(breedingToken.burnFrom(msg.sender, BREEDING_COST));
uint256 requestId = vrfCoordinator.requestRandomWords(...);
pendingBreeds[requestId] = BreedRequest(parent1Id, parent2Id, msg.sender);
}
function fulfillRandomWords(uint256 requestId, uint256[] memory randomWords) internal override {
BreedRequest memory req = pendingBreeds[requestId];
uint256 childAttributes = deriveAttributes(req.parent1Id, req.parent2Id, randomWords[0]);
_mintWithAttributes(req.requester, childAttributes);
}
Маркетплейс і роялті
Вбудований маркетплейс дає контроль над fee структурою та кастомною логікою (заборона торгівлі предметами до певного рівня). Роялті за EIP-2981 — стандарт, але не enforceable: Blur та інші маркетплейси ігнорують on-chain роялті. Для enforcement — whitelist-only transfer (тільки через контракти, що платять роялті). Жертвуємо composability заради захисту прав.
Staking та розподіл винагород
Staking NFT — механіка для утримання гравців. Проблема: нарахування rewards при тисячах стейкерів вимагає постійних транзакцій (дорого). Рішення — reward-per-share паттерн (як у MasterChef від SushiSwap): глобальний accRewardPerShare, при claim або change state перераховується заборгованість за формулою pendingReward = stakedAmount * (accRewardPerShare - userRewardDebt). O(1) складність незалежно від кількості стейкерів. Економія газу — до 70% порівняно з поелементним нарахуванням.
Детальніше про reward-per-shape реалізацію
Алгоритм працює так: при кожному депозиті/знятті стейку або при оновленні глобального пулу (наприклад, додаванні нових токенів винагороди) контракт оновлює accRewardPerShare = totalPendingReward / totalStaked. Потім для конкретного користувача розраховується pending = user.staked * (accRewardPerShare - user.rewardDebt). Після виплати user.rewardDebt встановлюється рівним accRewardPerShare. Це дозволяє не зберігати історію внесків кожного користувача. На практиці ми використовуємо для GameFi проєктів версію з multiplier для врахування різних ваг стейку (наприклад, рідкісні NFT дають більше винагороди).
Процес та терміни
Починаємо з game economics документа: token flows, mint/burn механіки, projected supply schedule, sink analysis. До написання коду економіка моделюється (Cadence, Python simulation).
Як ми будуємо GameFi: 5 етапів
- Економічне моделювання — 1-2 тижні. Розробляємо dual-token модель, розраховуємо sink'и, прописуємо стимули для long-term holding.
- Розробка токен-контрактів — 2-3 тижні. ERC-20 для governance, ERC-20 для utility, з настроюваною політикою mint/burn.
- Смарт-контракти NFT — 3-5 тижнів. ERC-721 / ERC-1155 з dynamic metadata, breeding/crafting, Chainlink VRF.
- Staking + rewards — 2-3 тижні. Контракт на базі reward-per-share, інтерфейси для frontend.
- Маркетплейс (опціонально) — 2-4 тижні. Кастомний маркетплейс з enforced royalty.
Що входить у роботу
- Вихідний код усіх смарт-контрактів з тестами (Foundry/Hardhat)
- Документація архітектури та економіки
- Інтеграція з Chainlink, Tenderly для моніторингу
- Аудит коду та формальна верифікація (Slither, Mythril, Echidna)
- Навчання команди роботі з контрактами
- Підтримка після деплою (3 місяці)
Базовий GameFi стек (токени + NFT + staking + маркетплейс) — від 8 до 16 тижнів. Повна гра з on-chain рандомом, breeding, dynamic NFT — 4-8 місяців. ZK-based verifiable gameplay — окремий проєкт від 6 місяців.
Зв'яжіться з нами для аудиту вашої токеноміки — оцінимо ризики та доопрацюємо sink-механізми. Замовте розробку GameFi проєкту — отримайте готовий продукт з перевіреною економікою. Наш досвід — десятки реалізованих проєктів у Web3, включно з аудитом 15+ P2E ігор. Гарантуємо стабільність контрактів і прозорість коду. Сертифіковані аудитори перевіряють кожен контракт на типові вразливості (reentrancy, flash loan, oracle manipulation).







