Розробка мобільного GameFi: економіка, wallet, античит

Гравці знаходять способи фармити токени швидше розрахункового — ринок GameFi колапсує. Це стандартна проблема Play-to-Earn: економічна модель не витримує навантаження, якщо технічна реалізація дірява. Ми вирішуємо задачу на рівні архітектури: клієнт не довіряє розрахунок нагород, всі події верифікуються на сервері, а читери блокуються до того, як встигнуть завдати шкоди. Якщо ви зіткнулися з подібними проблемами, зв'яжіться з нами для аудиту вашого проекту. Ми реалізували 20+ GameFi-проектів, де off-chain модель дозволила знизити витрати на газ на 90% та збільшити retention вдвічі.

Клієнтський розрахунок нагород — вразливість

Якщо додаток сам рахує, скільки токенів заробив гравець, і надсилає це число на сервер — читерство тривіально через Charles Proxy або Frida instrumentation. Тому ігрові події повинні верифікуватися на сервері: клієнт надсилає game_session_id + дії з підписаним timestamp, сервер перераховує результат незалежно. Це закриває основний вектор атаки.

NFT ownership: перевіряйте на сервері, не на клієнті

Якщо гра вимагає володіння NFT (персонаж, земля), перевірка ownerOf(tokenId) повинна виконуватися через eth_call до смарт-контракту на сервері. Клієнт може підробити відповідь. Сервер кешує ownership з TTL 30–60 секунд через Redis, щоб не перевищувати RPC-ліміти.

Чому on-chain транзакції при кожній дії неможливі?

Виплата токенів через on-chain транзакцію при кожній ігровій дії — надто дорого і повільно. Працює схема: off-chain баланс в базі даних → періодичний або за запитом claim → on-chain mint/transfer. Кнопка Claim в додатку запитує підпис від сервера (EIP-712 typed data), користувач підтверджує через WalletConnect або embedded wallet, смарт-контракт верифікує підпис і переводить токени. Off-chain модель скорочує витрати на газ на 90% порівняно з поточною on-chain дією. Для контексту: одна on-chain транзакція в Ethereum при піку коштує $5-50, а off-chain операція — долі цента.

Embedded wallet vs external wallet: що обрати для P2E?

Для казуальних P2E краще embedded wallet (Privy, Thirdweb In-App Wallet, Dynamic). Ключі розподілені за схемою Shamir Secret Sharing: частки у провайдера, у користувача, на пристрої. Для відновлення потрібно m з n часток — це виключає єдину точку компрометації. Користувач не бачить seed phrase, доки не експортує. На мобілці: Privy iOS SDK, Thirdweb React Native SDK. Транзакції підтверджуються пін-кодом або біометрією — LocalAuthentication або BiometricPrompt.

Як забезпечити економічну стійкість P2E?

Dual-token модель (governance token + utility/reward token) — стандарт після колапсу Axie Infinity: governance token з обмеженою емісією зберігає цінність, utility token — інфляційний, витрачається на gameplay. Смарт-контракт reward pool з vesting schedule — нагороди виплачуються з лінійним вестингом, знижуючи selling pressure. На клієнті — два баланси, два окремих Claim flow з різними підтвердженнями транзакцій. Ми гарантуємо стабільність економіки на етапі проектування та тестування на testnet.

Ігровий двигун: Unity, React Native чи Flutter?

Unity з нативним плагіном для блокчейн-операцій — стандарт для складних P2E ігор. Unity WebGL build не підходить для мобілки, тільки нативний iOS (.xcframework) та Android (.aar) export. Thirdweb Unity SDK або ChainSafe Web3.Unity для on-chain взаємодій з C#. Для простих P2E (клікери, idle games) — React Native з react-native-game-engine або Flutter з flame. Блокчейн-інтеграція через JSI або Flutter Platform Channel без втрати продуктивності.

Anti-cheat на мобілці: заходи захисту

Базовий шар: SSL pinning (запобігає MITM через Charles), certificate transparency check, RASP (Runtime Application Self-Protection) через Guardsquare DexGuard (Android) або iXGuard (iOS). Детектування root/jailbreak через RootBeer або DTTJailbreakDetection — не як hard block, а як сигнал для посиленого моніторингу сервером. Геймплейні аномалії: якщо гравець робить 200 tap'ів за секунду на клікері — це бот. Серверна аналітика з Z-score відхиленням від медіани по когорті виявляє підозрілі сесії. Щоб переконатися, що ваша гра захищена, зв'яжіться з нами для перевірки поточної архітектури.

Що входить в проект

• Аудит ігрової механіки та економічної моделі
• Проектування смарт-контрактів і серверної валідації нагород
• Розробка ігрового ядра на Unity, React Native або Flutter
• Інтеграція embedded wallet або WalletConnect v2
• Впровадження античит-шару (SSL pinning, RASP, детектування аномалій)
• Тестування економіки на testnet
• Публікація в App Store та Google Play з урахуванням вимог до gambling/finance
• Технічна підтримка 3 місяці після запуску

Як ми працюємо: етапи

1. Аналітика та проектування — розбираємо механіку, економіку, токеноміку.
2. Розробка смарт-контрактів і серверної валідації.
3. Реалізація ігрового ядра — Unity/React Native/Flutter з блокчейн-інтеграцією.
4. Інтеграція гаманця — embedded або external, залежно від аудиторії.
5. Античит шар — захист на клієнті та сервері.
6. Тестування на testnet — завантаження економіки, перевірка всіх сценаріїв.
7. Mainnet деплой та публікація в стори.

Орієнтири за термінами

Простий P2E-клікер з embedded wallet, off-chain балансом та claim-механікою — 6–10 тижнів. Повноцінна GameFi-платформа з NFT, Unity-грою, dual-token економікою та античитом — від 3 до 5 місяців. Терміни уточнюються після аудиту ваших механік. Вартість розраховується індивідуально під проект.

Ми маємо досвід у 20+ GameFi-проектах, інженери розбираються в тонкощах блокчейн-інтеграції, економічного моделювання та античита. Якщо хочете, щоб ваша P2E гра не повторила долю колапсованих проектів — отримайте консультацію. Зв'яжіться з нами для обговорення вашого проекту.

Монетизація мобільних додатків: IAP, підписки та рекламна медіація

Додаток з погано реалізованими покупками втрачає гроші не тому що користувачі не хочуть платити, а тому що StoreKit транзакція зависає, Receipt Validation падає з помилкою або restore purchases не працює — і користувач пише в підтримку або залишає 1 зірку. Наш досвід (більше 7 років у мобільній розробці) показує, що грамотна монетизація збільшує LTV на 30–60% вже в перші три місяці після впровадження. Отримайте консультацію з монетизації вашого додатка — проаналізуємо поточну модель і знайдемо точки зростання.

Чому StoreKit 2 — найкращий вибір для IAP?

StoreKit 2 (iOS 15+) — сучасний API з async/await та верифікованими транзакціями на стороні пристрою без сервера. Transaction.currentEntitlements повертає всі активні покупки. Ключова зміна порівняно з StoreKit 1: верифікація JWS-підпису на пристрої через VerificationResult<Transaction> — не потрібно надсилати receipt на сервер для базової перевірки.

Але сервер-сайд валідація все одно потрібна для consumable покупок та проти fraud. App Store Server API замінює старий /verifyReceipt endpoint. Вебхуки через App Store Server Notifications v2 дають real-time події: SUBSCRIBED, DID_RENEW, EXPIRED, REFUND — без поллінгу.

Типова помилка: не обробляють paymentQueue(_:updatedTransactions:) у фоні для незавершених транзакцій. Користувач купив consumable, додаток впав до finishTransaction — покупка висить у черзі, при наступному запуску відновлюється та вимагає повторної обробки на сервері. Без ідемпотентності сервера — подвійне нарахування.

Як не втратити дохід на підписках?

Підписочна модель вимагає відстеження станів: тріал → активна → grace period → expired → refunded. RevenueCat — фактичний стандарт для керування підписками в продакшні. Абстрагує StoreKit та Google Play Billing, дає unified API, webhooks, аналітику когорт та A/B тести paywall.

Альтернатива RevenueCat — власна реалізація з Adapty або Qonversion. Повністю кастомна — тільки якщо дані не повинні залишати інфраструктуру або є нестандартна логіка. Ми гарантуємо, що налаштування webhooks та обробка подій життя підписки виконується без втрат — перевірено на проектах з аудиторією понад 500 тис. DAU.

Google Play Billing Library 6+ вимагає обробки PurchasesUpdatedListener та явного виклику acknowledgePurchase() або consumePurchase() протягом 3 днів — інакше Google автоматично скасовує покупку та повертає гроші. Середня вартість такої помилки — втрата значної суми на користувача на місяць (за даними наших проектів).

Рекламна медіація: підвищення CPM через bidding

Показувати рекламу через одне джерело — означає втрачати дохід. Медіація (waterfall або bidding) запитує рекламу у декількох мереж і показує найкращу ставку. Google AdMob — основа для banner, interstitial, rewarded. Медіація через AdMob Mediation або MAX (AppLovin) — другий де-факто стандарт. MAX використовує In-App Bidding — real-time аукціон без водоспаду. На практиці MAX дає CPM на 15-30% вище класичного waterfall (залежить від гео та аудиторії). У США для rewarded відео CPM може перевищувати певну суму. При 100 000 показів rewarded відео на день перехід з waterfall на In-App Bidding може приносити додатково значну суму щоденно.

ironSource (Unity Ads) — сильна позиція в ігровому сегменті, особливо rewarded video. Mintegral — добре закриває азійську аудиторію.

Налаштування медіації вимагає ATT (App Tracking Transparency) на iOS 14+. Без requestTrackingAuthorization рекламний CPM падає в 3-5 разів для користувачів, які не погодилися. SKAdNetwork та Privacy Manifest (iOS 17) — обов'язкові вимоги, без яких рев'ю падає.

Як вибрати рекламні мережі для медіації?

Як ми впроваджуємо монетизацію: покроковий процес

1. Аудит поточної моделі — аналіз воронки, paywall, цінових тирів та виявлення вузьких місць.
2. Проектування моделі — вибір типу (subscription, consumable, non-consumable) та оптимізація цінових точок.
3. Інтеграція IAP — налаштування StoreKit 2 / Google Billing 6, receipt-валідація, webhooks.
4. Рекламна медіація — підключення 3-6 мереж, налаштування waterfall або In-App Bidding, тестування fill rate.
5. Аналітика та когорти — інтеграція RevenueCat, Amplitude або Firebase для відстеження LTV.
6. A/B тестування paywall — використання Remote Config для експериментів без релізу.
7. Запуск та моніторинг — 2 тижні безкоштовної підтримки після запуску, фікс багів по SLA 24 години.

Freemium: проектування моделі та paywall

Freemium працює коли межа між безкоштовним та платним проведена правильно. Занадто жорсткий paywall на старті — користувач видаляє. Занадто щедрий безкоштовний тир — немає стимулу платити.

Як проєктувати paywall для freemium?

Паттерн, який працює технічно: feature flags з сервера (Remote Config у Firebase або LaunchDarkly) керують доступом до фіч. Це дозволяє A/B тестувати paywall без релізу, змінювати умови тріалу, проводити акції.

Реалізація на рівні коду: EntitlementManager — єдина точка перевірки доступу до фіч, яка знає про статус підписки, флаги та промо. Жодних перевірок isPremium розкиданих по всьому коду. Досвід показує: такий підхід знижує кількість багів з paywall на 80% (підтверджено на 30+ проектах).

Обсяг робіт з монетизації

• Аудит поточної моделі — аналіз воронки, paywall, цінових тирів.
• Інтеграція IAP — StoreKit 2 / Google Billing 6, receipt-валідація, webhooks.
• Рекламна медіація — налаштування MAX / AdMob, підключення 3-6 мереж, тестування fill rate.
• Налаштування аналітики — RevenueCat, Amplitude / Firebase, когортний аналіз.
• Документація — опис ентайтлментів, процедура відновлення, чек-лист рев'ю.
• Навчання команди — розбір типових помилок, рекомендації з підтримки.
• Гарантія — безкоштовна підтримка 2 тижні після запуску, фікс багів по SLA 24 години.

Терміни орієнтовно

Вартість розраховується індивідуально. Ми працюємо в цій сфері більше 8 років і реалізували більше 40 проектів з монетизацією — багато з них пройшли App Store Review без жодного блокування. Зв'яжіться з нами для аудиту або замовте консультацію — розповімо, які точки зростання є у вашому додатку.

Джерела: Apple StoreKit 2 Documentation, RevenueCat Best Practices, Wikipedia: Freemium.