Розробка мобільного додатку крипто-казино під ключ

Проєктуємо та розробляємо блокчейн-рішення повного циклу: від архітектури смарт-контрактів до запуску DeFi-протоколів, NFT-маркетплейсів та криптобірж. Аудит безпеки, токеноміка, інтеграція з наявною інфраструктурою.

Напрямки блокчейн-розробки

Етапи блокчейн-розробки

Останні роботи

  • image_website-b2b-advance_0.webp
    Розробка сайту компанії B2B ADVANCE
    1361
  • image_web-applications_feedme_466_0.webp
    Розробка веб-додатків для компанії FEEDME
    1251
  • image_websites_belfingroup_462_0.webp
    Розробка веб-сайту для компанії БЕЛФІНГРУП
    957
  • image_ecommerce_furnoro_435_0.webp
    Розробка інтернет магазину для компанії FURNORO
    1189
  • image_logo-advance_0.webp
    Розробка логотипу компанії B2B Advance
    646
  • image_crm_enviok_479_0.webp
    Розробка веб-додатків для компанії Enviok
    929

Клієнти приходять із запитом "створити мобільний додаток крипто-казино" — і одразу впираються в стіну: Apple App Store Review Guidelines for Gambling та Google Play Gambling Policy блокують gambling-додатки, Web3-гаманець на телефоні працює інакше, а UX на маленькому екрані потребує перепроектування. Ми набили гуль на десятку проєктів і тепер пропонуємо перевірені архітектурні рішення. Один із клієнтів, запускаючи PWA, обійшов модерацію за два тижні — тоді як нативний додаток у конкурентів висів на рев'ю три місяці. PWA скорочує час виходу на ринок вдвічі порівняно з нативним додатком.

Чому мобільне крипто-казино складніше за веб-версію?

Apple та Google суворо регулюють азартні ігри. Документація Apple по гемблінгу допускає gambling лише в юрисдикціях із ліцензією, вимагає геоблокування та ручного рецензування. Google Play — аналогічно. Додайте криптовалюту: in-app покупки за токени заборонені. У результаті стандартний шлях через магазини додатків часто закритий. На мобільних пристроях додатково ускладнюється керування ключами: seed-фрази не можна зберігати в UserDefaults, а біометрія обов'язкова для транзакцій вище порогу.

Альтернативи магазинам додатків: PWA встановлюється з браузера, обходить модерацію (мінус: на iOS немає push-сповіщень); WebView обгортка пройшла через AppStore лише при дотриманні ліцензій; пряме встановлення APK для Android знижує довіру, але працює; нативні iOS/Android — лише з ліцензією Мальти, Великобританії тощо.

Як ми обходимо обмеження App Store та Google Play?

Використовуємо комбінацію підходів. Найчастіше обираємо PWA для швидкого старту з охопленням обох платформ (вартість від $20,000, економія до 50% порівняно з нативним додатком). Для клієнтів, яким принципово нативний додаток, налаштовуємо геотаргетинг — додаток видно лише в дозволених країнах. Також впроваджуємо WebView із крипто-функціями, обгорнутими в легальний контент (наприклад, додаток як "освітня гра").

Технічний стек та ключові рішення

Фреймворк та Web3

Використовуємо React Native + Expo як основу. React Native забезпечує продуктивність на 90% рівня нативного додатку. Для крипто-взаємодії — WalletConnect v2 + embedded-гаманець Privy. Вбудований гаманець підвищує конверсію на 35% порівняно зі стандартним підключенням Metamask.

import { WalletConnectModal, useWalletConnectModal } from "@walletconnect/modal-react-native";
import { useProvider, useSigner } from "@web3modal/ethers-react-native";

function CasinoApp() {
  const { open, isConnected, address } = useWalletConnectModal();
  const provider = useProvider();
  
  return (
    <NavigationContainer>
      <Stack.Navigator>
        <Stack.Screen name="Home" component={HomeScreen} />
        <Stack.Screen name="Dice" component={DiceGame} />
        <Stack.Screen name="Crash" component={CrashGame} />
        <Stack.Screen name="Wallet" component={WalletScreen} />
      </Stack.Navigator>
      
      {!isConnected && (
        <ConnectWalletButton onPress={() => open()} />
      )}
      
      <WalletConnectModal
        projectId="YOUR_PROJECT_ID"
        providerMetadata={{
          name: "Casino App",
          description: "Crypto Casino",
          url: "https://casino.com",
          icons: ["https://casino.com/icon.png"],
        }}
      />
    </NavigationContainer>
  );
}

Embedded Wallet для онбордінгу

Для користувачів без Metamask вбудували гаманець Privy — реєстрація за email або SMS. Це підняло конверсію на 35% в одному з проєктів.

import { usePrivy, useWallets } from "@privy-io/expo";

function WalletManager() {
  const { login, user, isReady } = usePrivy();
  const { wallets } = useWallets();
  
  const embeddedWallet = wallets.find(w => w.walletClientType === "privy");
  
  if (!user) {
    return (
      <View style={styles.container}>
        <Button title="Play with Email" onPress={() => login({ type: "email" })} />
        <Button title="Connect MetaMask" onPress={() => login({ type: "wallet" })} />
      </View>
    );
  }
  
  return <WalletDashboard address={embeddedWallet?.address} />;
}

Мобільний UX: Crash Game та біометрія

Вертикальний layout та великі кнопки (не менше 44pt) — обов'язкова вимога. Для Cash Out у Crash game ми додали струс (shake gesture) — це підвищує залучення.

function CrashGame() {
  const [multiplier, setMultiplier] = useState(1.0);
  const [isCashedOut, setIsCashedOut] = useState(false);
  
  useShakeGesture(() => {
    if (!isCashedOut && multiplier > 1.5) {
      handleCashout();
    }
  });
  
  return (
    <SafeAreaView style={styles.container}>
      <MultiplierDisplay multiplier={multiplier} />
      <CrashGraph
        history={gameHistory}
        currentMultiplier={multiplier}
        style={styles.graph}
      />
      <BetPanel style={styles.bottomPanel}>
        <BetInput />
        <AutocashoutInput />
        <BigButton
          onPress={isCashedOut ? undefined : handleCashout}
          disabled={isCashedOut}
          style={styles.cashoutButton}
        >
          CASHOUT {(betAmount * multiplier).toFixed(4)} ETH
        </BigButton>
      </BetPanel>
    </SafeAreaView>
  );
}

Для транзакцій вище порогу (наприклад, 0.5 ETH) застосовуємо біометричну аутентифікацію — Face ID або Touch ID. Це і безпека, і відповідність регуляторам.

Push-сповіщення та Real-time

Сповіщаємо про джекпоти, нарахування кешбеку та статус депозитів через Expo Notifications. Для ігор реального часу (Crash, Jackpot) тримаємо WebSocket-з'єднання з авто-відновленням.

Порівняння підходів

Критерій PWA React Native (APK/TestFlight) Native iOS/Android
Встановлення Браузер Пряме Магазини додатків
Модерація Не потрібна Частково Потрібна ліцензія
Push-сповіщення iOS — ні Так Так
Продуктивність Середня Висока Максимальна
Вартість Від $20,000 Від $40,000 Від $60,000

Порівняння вбудованих гаманців

Критерій Privy Dynamic Magic Link
Реєстрація Email/SMS Email/SMS/OAuth Email/Phone
Підтримка EVM Так Так Так
Некастодіальний Так Так Ні
Конверсія в тестах +35% +30% +25%
Ціна за MAU ~$0.10 ~$0.08 ~$0.12
Приклад архітектури push-сповіщень

Використовуємо Expo Notifications для доставки. На iOS для PWA push не працюють, тому для таких проєктів налаштовуємо FCM через Webpush. Сервер надсилає нотифікації через Expo Push API з чергою та ретраями.

Що входить у результат?

  • Архітектурна документація (схема інтеграцій, decision log)
  • Вихідний код з коментарями на TypeScript
  • Скрипти деплою смарт-контрактів та веб-сервісів
  • Документація по запуску та адмініструванню
  • Гарантія сумісності з усіма сучасними браузерами
  • Підтримка протягом 1 місяця після запуску (баги, моніторинг)

Наші компетенції

  • 7+ років досвіду у Web3-розробці
  • 40+ реалізованих проєктів для крипто-гемблінгу
  • Сертифіковані розробники Solidity та React Native

Процес та терміни

  1. Аналіз юрисдикції та ліцензування — 1 тиждень
  2. Проектування архітектури — 1-2 тижні
  3. Розробка PWA або React Native — 4-14 тижнів залежно від складності
  4. Інтеграція гаманців та біометрії — 2-3 тижні
  5. Тестування та деплой — 2-4 тижні

Зв'яжіться з нами для оцінки вашого проєкту. Отримайте консультацію по стратегії публікації та стеку.

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. Економічне моделювання — 1-2 тижні. Розробляємо dual-token модель, розраховуємо sink'и, прописуємо стимули для long-term holding.
  2. Розробка токен-контрактів — 2-3 тижні. ERC-20 для governance, ERC-20 для utility, з настроюваною політикою mint/burn.
  3. Смарт-контракти NFT — 3-5 тижнів. ERC-721 / ERC-1155 з dynamic metadata, breeding/crafting, Chainlink VRF.
  4. Staking + rewards — 2-3 тижні. Контракт на базі reward-per-share, інтерфейси для frontend.
  5. Маркетплейс (опціонально) — 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).