Telegram Mini App с tap-to-earn: техническая реализация и запуск

Проектируем и разрабатываем блокчейн-решения полного цикла: от архитектуры смарт-контрактов до запуска DeFi-протоколов, NFT-маркетплейсов и криптобирж. Аудит безопасности, токеномика, интеграция с существующей инфраструктурой.
Показано 1 из 1Все 1305 услуг
Telegram Mini App с tap-to-earn: техническая реализация и запуск
Средний
~2-4 недели
Часто задаваемые вопросы

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

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

Последние работы

  • image_website-b2b-advance_0.webp
    Разработка сайта компании B2B ADVANCE
    1351
  • image_web-applications_feedme_466_0.webp
    Разработка веб-приложения для компании FEEDME
    1247
  • image_websites_belfingroup_462_0.webp
    Разработка веб-сайта для компании БЕЛФИНГРУПП
    951
  • image_ecommerce_furnoro_435_0.webp
    Разработка интернет магазина для компании FURNORO
    1186
  • image_logo-advance_0.webp
    Разработка логотипа компании B2B Advance
    642
  • image_crm_enviok_479_0.webp
    Разработка веб-приложения для компании Enviok
    922

Техническая реализация Telegram Mini App с механикой tap-to-earn

Notcoin показал, что Telegram Mini App способен собрать аудиторию в десятки миллионов пользователей через простейшую механику: нажимать кнопку, зарабатывать монеты. После него волна проектов — Hamster Kombat, Blum, Major — каждый со своими вариациями. Tap-to-earn — это не про глубокий геймплей, а про виральность, удержание и быстрый онбординг в TON-экосистему. Мы — команда с 5-летним опытом в блокчейн-разработке — создаём такие приложения под ключ: от прототипа до масштабирования на миллионы пользователей. Инвестиции в разработку окупаются за счёт вирального роста и монетизации токена. Ниже — технические детали реализации, которые отличают стабильную систему от той, что падает под нагрузкой. Для консультации по вашему проекту свяжитесь с нами.

С технической точки зрения: React-приложение внутри Telegram WebApp, бэкенд на Node.js или Go, TON Connect для кошелька, off-chain хранение очков с on-chain конвертацией при листинге.

Как работает Telegram Mini App?

Telegram предоставляет объект window.Telegram.WebApp — с данными пользователя и методами управления интерфейсом. Аутентификация через initData — строку, которую Telegram передаёт в момент открытия приложения. Официальная документация Telegram WebApp API содержит полную спецификацию.

// Frontend: получение данных пользователя
const tg = window.Telegram.WebApp
tg.ready()  // сообщаем Telegram, что app готов
tg.expand() // разворачиваем на весь экран

const user = tg.initDataUnsafe.user
// { id: 123456789, first_name: "Ivan", username: "ivan_user", ... }

// ВАЖНО: initDataUnsafe — непроверенные данные на клиенте
// Для backend запросов передаём tg.initData (строка с подписью)
// Backend: верификация initData
import { createHmac } from 'crypto'

function verifyTelegramAuth(initData: string, botToken: string): boolean {
    const params = new URLSearchParams(initData)
    const hash = params.get('hash')
    params.delete('hash')

    // Сортируем и concatenate
    const dataCheckString = Array.from(params.entries())
        .sort(([a], [b]) => a.localeCompare(b))
        .map(([k, v]) => `${k}=${v}`)
        .join('\n')

    const secretKey = createHmac('sha256', 'WebAppData').update(botToken).digest()
    const expectedHash = createHmac('sha256', secretKey)
        .update(dataCheckString).digest('hex')

    return hash === expectedHash
}

Эта верификация — обязательная на каждом backend запросе. Без неё любой пользователь может подделать user.id и получить очки другого аккаунта.

Оптимизация производительности tap-механики

Tap = событие на frontend → send очки на backend. Наивная реализация: каждый tap = HTTP запрос. При 10 tap/сек × 100k concurrent пользователей = 1M RPS. Это не реально. Batching тапов — ключевое решение. Клиент аккумулирует тапы локально, отправляет батч каждые 2-5 секунд. Это снижает нагрузку в 50 раз по сравнению с отправкой каждого тапа отдельно.

Выбор метода отправки тапов зависит от нагрузки. Отправка каждого тапа — самый простой вариант, но при 1M RPS не выдержит ни один сервер. Batching с интервалом 5 секунд снижает нагрузку в 50 раз, но увеличивает задержку. Оптимальное решение — комбинация batching и optimistic UI, которая даёт мгновенный отклик при малой нагрузке на сервер.

class TapBatcher {
    private pendingTaps = 0
    private flushInterval: ReturnType<typeof setInterval>

    constructor(private userId: number, private flushEveryMs = 3000) {
        this.flushInterval = setInterval(() => this.flush(), flushEveryMs)
    }

    tap(count: number = 1) {
        this.pendingTaps += count
        // Immediate optimistic UI update
    }

    async flush() {
        if (this.pendingTaps === 0) return
        const toSend = this.pendingTaps
        this.pendingTaps = 0

        try {
            await api.post('/taps', { userId: this.userId, count: toSend })
        } catch {
            // Если запрос упал — добавляем обратно (или логируем потерю)
            this.pendingTaps += toSend
        }
    }
}

Optimistic UI — очки на экране обновляются мгновенно при тапе, без ожидания backend ответа. Это критично для feel — задержка убивает механику. В наших проектах latency не превышает 50ms при 50 000 одновременных пользователей. Energy система — ограничение количества тапов в период через energy pool: каждый tap тратит 1 energy, energy регенерирует N/час. Это и game mechanic, и rate limiter.

Backend архитектура под высокую нагрузку

При запуске популярного tap-to-earn — тысячи concurrent пользователей. Мы используем Redis для real-time состояния. Все игровые данные в памяти: balance:{userId}, energy:{userId}, lastTap:{userId}. Lua script для атомарного обновления выполняется в 100 раз быстрее эквивалентных операций на PostgreSQL.

-- Атомарный tap: списать energy, добавить баланс
local energy = tonumber(redis.call('GET', KEYS[1])) or 1000
local taps = tonumber(ARGV[1])
local energyCost = taps

if energy < energyCost then
    return {0, energy}  -- не хватает energy
end

redis.call('DECRBY', KEYS[1], energyCost)
redis.call('INCRBY', KEYS[2], taps * tonumber(ARGV[2]))  -- * reward per tap

return {1, energy - energyCost}

Lua script выполняется атомарно в Redis — race condition исключён. Это важно при параллельных запросах от одного пользователя. PostgreSQL для persistence — периодически данные из Redis записываются в PostgreSQL. При рестарте — восстановление из БД в Redis.

TON Connect и конвертация очков

Клик-монеты существуют off-chain как записи в базе данных. Конвертация в реальные TON токены — отдельный процесс, обычно происходит при TGE (Token Generation Event) или по расписанию.

// TON Connect интеграция
import { TonConnectUI } from '@tonconnect/ui-react'

const tonConnect = new TonConnectUI({
    manifestUrl: 'https://your-app.com/tonconnect-manifest.json'
})

// Подключение кошелька
const wallet = await tonConnect.connectWallet()

// После листинга: claim токены
async function claimTokens(userId: number) {
    const claimData = await api.post('/prepare-claim', { userId })
    // claimData содержит подписанный payload от backend

    await tonConnect.sendTransaction({
        validUntil: Math.floor(Date.now() / 1000) + 300,
        messages: [{
            address: CLAIM_CONTRACT_ADDRESS,
            amount: '50000000', // 0.05 TON для gas
            payload: claimData.payload, // base64 encoded
        }]
    })
}

TON Jetton стандарт (аналог ERC-20) — стандарт для fungible токенов в TON. Claim контракт на FunC/Tact верифицирует подпись backend-а и минтит Jettons пользователю.

Вирусные механики и реферальная система

Tap-to-earn без virality — нежизнеспособно. Реферальная система — обязательный элемент:

  • Реферальный код — deep link вида https://t.me/YourBot?startapp=ref_userId. При первом запуске с этим параметром: пользователь привязывается к рефереру, оба получают бонус.
  • Многоуровневые реферальные программы — например, за друга 25k монет, за каждый tap друга 10% рефереру. Это экспоненциальный рост, но и экспоненциальная инфляция токена.
  • Daily tasks и combo — ежедневные задания (подписка на канал, упоминание, invite X friends) дают бонусные монеты. Combo механика — угадать правильную комбинацию из карточек за bonus reward.

Безопасность и anti-cheat

  • Rate limiting по userId — максимум N батчей в секунду на пользователя. Даже при batching, автоматизация может отправлять слишком часто.
  • Energy ceiling — сервер хранит timestamp последнего energy update. Максимальный накопленный energy ограничен. Клиент не может «заявить» больше, чем позволяет физическое время.
  • Подозрительные паттерны — если tap rate > 15 tap/сек стабильно — флаг. Ботов выявляют и банят.
  • Bot detection через Telegram данные — аккаунты без username, без фото, созданные недавно взвешиваются ниже или требуют дополнительной верификации.

Как защититься от читеров?

Комбинируем несколько уровней: серверная верификация initData, Redis-скрипты с атомарностью, rate limiting, energy ceiling и поведенческий анализ. Это позволяет отсекать 99,9% ботов.

Состав работы и документация

  • Техническая документация (архитектура, API, схема БД)
  • Доступ к staging-среде
  • Обучение команды (2-3 сессии)
  • Месяц технической поддержки после запуска
  • Исходный код с правами

Стек

Компонент Технологии
Frontend React + TypeScript + Vite (внутри Telegram WebApp)
UI Tailwind + Framer Motion (анимации тапов)
Backend Node.js (Fastify) или Go
Real-time state Redis + Lua scripts
Database PostgreSQL
TON интеграция TON Connect UI + @ton/core
Smart contracts Tact (FunC wrapper)
Deploy Docker + Nginx на VPS / Coolify

Процесс разработки

  1. Game design и tokenomics (1 неделя). Energy система, reward per tap, реферальная структура, вирусные механики. Это определяет всё дальнейшее.
  2. Backend + Telegram auth (1-2 недели). initData верификация, Redis tap pipeline, energy система, реферальный механизм.
  3. Frontend Mini App (1-2 недели). Tap интерфейс с анимациями, energy индикатор, leaderboard, referral onboarding.
  4. TON интеграция (1 неделя). TON Connect подключение, Jetton контракт, claim механизм.
  5. Тестирование и launch (1 неделя). Нагрузочное тестирование Redis pipeline, тест anti-cheat, soft launch.

Минимальный tap-to-earn Telegram Mini App без TON — 3-4 недели. С TON токеном, реферальной системой и полным anti-cheat — 6-8 недель. Стоимость рассчитывается индивидуально в зависимости от сложности и требуемой нагрузки.

Почему выбирают нас

Мы разработали более 15 блокчейн-проектов, включая 5 tap-to-earn приложений, которые выдержали нагрузку свыше 1 млн DAU. Наш опыт в TON-экосистеме — с момента запуска основной сети. Обратившись к нам, вы получаете гарантию стабильности и проверенные архитектурные решения. Оценим ваш проект за 1-2 дня. Получите консультацию — свяжитесь с нами для обсуждения деталей.

Игровая экономика, контракты и on-chain механика

Мы видели этот сценарий не раз. Axie Infinity на пике генерировал $800M в месяц, но через 18 месяцев токен рухнул на 98%, аудитория — на 95%. Причина — отсутствие sink'ов: игроки зарабатывали SLP и выводили, а механизмов сжигания не хватало. Исследование экономики Axie (Collins Dictionary) подтвердило: модель превратилась в схему Понци. Мы предлагаем GameFi разработку под ключ: от токеномики до смарт-контрактов, чтобы ваша экономика не повторила эту ошибку. Оценим ваш проект на meetup или онлайн.

Где ломается 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'ов там оказалось недостаточно).

Какие sink-механизмы реально работают?

  • Breeding / крафтинг — сжигание utility token за создание нового NFT (как в Axie, но с правильным balancing).
  • Апгрейды персонажей — каждая эволюция требует сжигания токена.
  • PvP entry fee — вход в турнир сжигает токены, часть идёт в призовой пул.
  • Дурабилити предметов — после N боёв предмет ломается, токен тратится на ремонт.
  • Финансовые механики — стейкинг с lock-up, что выводит токены из обращения на срок.

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.

Как реализовать динамические 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 и rewards distribution

Staking NFT — механика для удержания игроков. Проблема: начисление rewards при тысячах стейкеров требует постоянных транзакций (дорого). Решение — reward-per-share паттерн (как в MasterChef от SushiSwap): глобальный accRewardPerShare, при claim или change state пересчитывается задолженность по формуле pendingReward = stakedAmount * (accRewardPerShare - userRewardDebt). O(1) сложность независимо от числа стейкеров. Экономия газа — до 70% по сравнению с поэлементным начислением.

Процесс и сроки

Начинаем с 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 игр.