GameFi разработка: экономики, контракты, on-chain логика
Axie Infinity на пике генерировал $800M в месяц. Через 18 месяцев после запуска токен упал на 98%, ежедневная аудитория — на 95%. Не потому что игра была плохой. Потому что экономика была построена как схема Понци: новые игроки покупали аксов у старых, старые выводили SLP. Когда приток новых игроков остановился — collapse. Это не разовый случай. Большинство P2E-игр умерли по той же причине.
GameFi разработка — это в первую очередь game economics design, и только потом Solidity.
Где ломается Play-to-Earn экономика
Инфляционная токеномика без sink'ов. Игрок получает токены за геймплей. Если sink'ов (механизмов сжигания или потребления токенов) недостаточно — supply растёт быстрее demand. Цена падает. Доход игрока в fiat уменьшается. Игроки уходят. Цена падает ещё. Смерть спираль.
Правильная конструкция: dual-token модель с чётким разделением. Governance/value token (ограниченный supply, для стейкинга и governance) и utility/reward token (инфляционный, для внутриигровой экономики). Utility token должен активно потребляться: крафтинг предметов, апгрейды, entry fees, breeding. Примеры: GODS/FLUX в Gods Unchained, AXS/SLP в Axie (хотя реализация sink'ов в Axie оказалась недостаточной).
NFT предметы без реальной utility. Если NFT item — это просто JPEG с рарностью и нет игровой механики, делающей его ценным — цена держится только на спекуляции. Устойчивая модель: предмет имеет gameplay utility (даёт преимущество или открывает контент), предмет потребляется или деградирует в процессе использования (durability mechanic), предмет нужен для прогрессии (crafting materials).
On-chain vs Off-chain: где проходит граница
Всю игровую логику on-chain не нужно и не нужно пытаться. Транзакция на Ethereum стоит газа и занимает 12 секунд. Игровой цикл — миллисекунды.
On-chain должно быть: ownership активов (NFT items, land), передача и торговля активами, финансовые операции (staking, rewards, распределение DAO), random generation для mint (с Chainlink VRF — иначе атакуемо).
Off-chain (centralized или verifiable): игровой процесс, боевая механика, state игрового мира, матчмейкинг. Результаты геймплея → on-chain checkpoint через signed message от сервера или ZK-proof.
Verifiable off-chain с ZK: игровой сервер генерирует ZK-proof корректности игровой сессии. Контракт верифицирует proof и начисляет награду. Это убирает необходимость доверять серверу. Реализации: Cartridge (Starknet-based gaming engine), zkSync-powered game rollups.
Реализация NFT игровых предметов
Стандарт: ERC-1155 для взаимозаменяемых предметов (ресурсы, consumables) + ERC-721 для уникальных (персонажи, land). ERC-1155 значительно дешевле при batch transfer: одна транзакция передаёт несколько типов предметов.
Динамические метаданные. Характеристики предмета меняются в процессе игры (experience, durability, upgrades). Два подхода:
Fully on-chain: атрибуты хранятся в mapping внутри контракта. tokenURI генерируется on-chain из атрибутов через SVG или JSON encoding. Дорого по газу при частом обновлении. Используется для land и ключевых активов.
Hybrid: атрибуты хранятся off-chain, в tokenURI — hash состояния. Обновление состояния подписывается сервером, верифицируется on-chain при необходимости (например, при transfer или продаже). Дешевле, но требует доверия к серверу или ZK.
Breeding и crafting. Breeding (как в Axie) — классический source инфляции. Контракт: два родительских 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);
}
Маркетплейс и роялти
Встроенный маркетплейс или интеграция с OpenSea/Blur/Magic Eden. Для GameFi обычно нужен собственный маркетплейс: контроль над fee структурой, кастомная логика (например, запрет торговли certain items до определённого уровня персонажа).
Роялти: EIP-2981 — стандарт, но не enforceable. Blur и другие маркетплейсы игнорируют on-chain роялти. Для enforcement: whitelist-only transfer (только через контракты, которые платят роялти). Жертвуем composability ради royalty enforcement.
Staking и rewards distribution
Staking NFT — типичная механика для удержания игроков. NFT локируется в контракте, начисляются reward tokens. Проблема: начисление rewards per NFT при тысячах стейкеров требует либо постоянных транзакций (дорого), либо паттерна lazy evaluation.
Reward-per-share паттерн (как в MasterChef от SushiSwap): глобальный accRewardPerShare, при claim или change state пересчитывается задолженность по формуле pendingReward = stakedAmount * (accRewardPerShare - userRewardDebt). O(1) сложность независимо от числа стейкеров.
Процесс и сроки
Начинаем с game economics документа: token flows, mint/burn механики, projected supply schedule, sink analysis. До написания кода это должно быть смоделировано (Cadence, Python simulation).
Разработка: токен-контракты → NFT контракты с game attributes → breeding/crafting → staking → marketplace → Chainlink VRF интеграция → frontend (wagmi, ethers.js) → тестирование экономических сценариев на fork.
Базовый GameFi стек (токены + NFT + staking + маркетплейс) — 8-16 недель. Полная игра с on-chain рандомом, breeding, dynamic NFT, собственным маркетплейсом — 4-8 месяцев. ZK-based verifiable gameplay — отдельный проект от 6 месяцев.







