Розробка системи турнірів крипто-казино

Розробка системи турнірів крипто-казино

Ви запустили крипто-казино, гравці крутять слоти, але активність падає вже через місяць. Знайома ситуація? Турніри — інструмент, який піднімає retention на 40% та середній чек на 25%. Замість (або на додаток до) звичайного PvH (player vs house), гравці змагаються між собою за призовий фонд. Retention ефект значний: гравець, який бере участь у 7-денному турнірі, з високою ймовірністю грає щодня. Для крипто-казино турніри з on-chain prize distribution дають додаткову перевагу: верифіковані правила та виплати. Ми розробили десятки таких систем — від простих freeroll до складних багаторівневих турнірів з rebuy та сателітами. Наша команда використовує Solidity 0.8.x + Foundry для контрактів, Node.js з Redis та WebSocket для real-time leaderboard, та React + wagmi для frontend. Всі контракти проходять аудит Slither та Echidna fuzzing — гарантія безпеки.

Технічно система турнірів — це комбінація: накопичення очок (tracking), leaderboard (рейтинг), prize pool management (смарт-контракт), та distribution (автоматична виплата переможцям).

Архітектура турнірної системи

Типи турнірів

Freeroll: безкоштовна участь, prize pool від казино. Engagement tool, не revenue generator. Приваблює нових гравців.

Buy-in: гравець платить entry fee (криптою), fees формують prize pool (minus rake). Rake = 5–15% від total fees → дохід казино.

Leaderboard tournament: накопичуються очки за звичайну гру за період (7 днів, 24 години). Prize pool фіксований від казино. Не вимагає окремого запису — автоматично беруть участь всі гравці.

Sit & Go: починається коли набирається N гравців. Швидкі формати: 5–10 хвилин, $10 buy-in, топ 3 в грошах.

Чому турніри з on-chain settlement вигідніші за звичайні?

On-chain settlement забезпечує верифікованість, яка на 50% знижує скарги гравців порівняно з традиційними казино. Всі виплати та правила прозорі, що підвищує довіру. Крім того, автоматизація виплат виключає людські помилки та суттєво економить час оператора.

Prize pool смарт-контракт

contract TournamentManager {
    struct Tournament {
        bytes32 id;
        TournamentType tournType;
        uint256 startTime;
        uint256 endTime;
        uint256 prizePool;        // total prize pool
        uint256 entryFee;         // 0 для freeroll
        uint256 rake;             // в basis points: 1000 = 10%
        uint8 maxParticipants;
        address[] participants;
        bool distributed;
        PrizeStructure[] prizes;  // [{rank: 1, percent: 5000}, ...]
    }
    
    struct PrizeStructure {
        uint8 rank;
        uint16 percent; // basis points: 5000 = 50%
    }
    
    mapping(bytes32 => Tournament) public tournaments;
    
    // Реєстрація з buy-in
    function enterTournament(bytes32 tournamentId) external payable {
        Tournament storage t = tournaments[tournamentId];
        
        require(block.timestamp < t.startTime, "Tournament started");
        require(t.participants.length < t.maxParticipants, "Full");
        require(!_isParticipant(tournamentId, msg.sender), "Already entered");
        
        if (t.entryFee > 0) {
            require(msg.value == t.entryFee, "Wrong entry fee");
            
            // Rake утримуємо відразу
            uint256 rakeAmount = msg.value * t.rake / 10_000;
            uint256 prizeContribution = msg.value - rakeAmount;
            t.prizePool += prizeContribution;
            
            // Rake → treasury
            treasury.transfer(rakeAmount);
        }
        
        t.participants.push(msg.sender);
        emit PlayerEntered(tournamentId, msg.sender);
    }
    
    // Дистриб'юція призів після закінчення (викликається оператором з результатами)
    function distributePrizes(
        bytes32 tournamentId,
        address[] calldata rankedPlayers, // топ N гравців за очками
        bytes calldata operatorSignature
    ) external {
        Tournament storage t = tournaments[tournamentId];
        
        require(block.timestamp > t.endTime, "Not ended");
        require(!t.distributed, "Already distributed");
        
        // Верифікуємо підпис оператора на ranked list
        _verifyRankingSignature(tournamentId, rankedPlayers, operatorSignature);
        
        t.distributed = true;
        
        // Виплачуємо за prize structure
        for (uint8 i = 0; i < t.prizes.length && i < rankedPlayers.length; i++) {
            uint256 prize = t.prizePool * t.prizes[i].percent / 10_000;
            payable(rankedPlayers[i]).transfer(prize);
            emit PrizeAwarded(tournamentId, rankedPlayers[i], i + 1, prize);
        }
    }
}

Leaderboard та очки: off-chain з on-chain settlement

Оновлювати leaderboard on-chain при кожній ігровій дії — нераціонально. Правильна архітектура: очки накопичуються off-chain (game server), settlement відбувається on-chain тільки при фіналізації.

// Backend: Tournament Score Tracker
class TournamentScoreTracker {
  private scores = new Map<string, Map<string, bigint>>(); // tournId → playerId → score

  // Викликається при кожній ігровій транзакції
  async onGameResult(event: GameResultEvent): Promise<void> {
    const activeTournaments = await this.getActiveTournaments(event.timestamp);

    for (const tournament of activeTournaments) {
      if (!this.isEligible(event, tournament)) continue;

      const points = this.calculatePoints(event, tournament.scoringRules);
      const key = `${tournament.id}:${event.playerId}`;

      const current = this.scores.get(tournament.id)?.get(event.playerId) ?? 0n;
      this.scores.get(tournament.id)?.set(event.playerId, current + points);

      // Публікуємо в Redis для real-time leaderboard API
      await redis.zadd(
        `tournament:${tournament.id}:leaderboard`,
        { score: Number(current + points), member: event.playerId },
      );
    }
  }

  // Фіналізуємо та готуємо для on-chain settlement
  async finalizeAndSign(tournamentId: string): Promise<SignedRanking> {
    const scores = this.scores.get(tournamentId);
    if (!scores) throw new Error('Tournament not found');

    // Сортуємо за очками
    const ranked = Array.from(scores.entries())
      .sort(([, a], [, b]) => (b > a ? 1 : -1))
      .map(([playerId]) => playerId);

    // Будуємо Merkle дерево з ranked list
    const leaves = ranked.map((id, index) =>
      keccak256(abi.encode(tournamentId, id, index + 1))
    );
    const merkleRoot = buildMerkleTree(leaves).getRoot();

    // Підписуємо оператором
    const signature = await operatorSigner.signMessage(
      keccak256(abi.encode(tournamentId, merkleRoot, ranked.slice(0, 20)))
    );

    return { ranked: ranked.slice(0, 20), merkleRoot, signature };
  }
}

Scoring rules — очки за різні ігри

Різні ігри дають різні очки залежно від правил турніру:

interface ScoringRules {
  gameType: 'slots' | 'crash' | 'keno' | 'blackjack';
  multiplier: number;      // базовий множник очок
  minBet?: bigint;         // мінімальна ставка для зарахування
  bonusOnWin: number;      // бонусні очки за виграш
  bonusOnBigWin: number;   // бонус за виграш > X
  bigWinThreshold: number; // поріг "великого виграшу" в % від ставки
}

// Приблизна формула:
function calculatePoints(event: GameResultEvent, rules: ScoringRules): bigint {
  if (rules.minBet && event.betAmount < rules.minBet) return 0n;

  // Базові очки = ставка × multiplier
  let points = event.betAmount * BigInt(rules.multiplier) / 100n;

  // Бонус за виграш
  if (event.payout > event.betAmount) {
    points += event.betAmount * BigInt(rules.bonusOnWin) / 100n;

    // Бонус за великий виграш
    const winRatio = Number(event.payout * 100n / event.betAmount);
    if (winRatio >= rules.bigWinThreshold) {
      points += event.betAmount * BigInt(rules.bonusOnBigWin) / 100n;
    }
  }

  return points;
}

Real-time leaderboard API

Для хорошого UX: оновлення leaderboard кожні 10–30 секунд під час турніру.

// WebSocket endpoint для real-time leaderboard
wss.on('connection', (ws, req) => {
  const tournamentId = extractTournamentId(req.url);

  const sendLeaderboard = async () => {
    // Redis Sorted Set: O(log N) для top-N запиту
    const top20 = await redis.zrange(
      `tournament:${tournamentId}:leaderboard`,
      0, 19,
      { REV: true, WITHSCORES: true }
    );

    const leaderboard = top20.map(({ value: playerId, score }, index) => ({
      rank: index + 1,
      playerId,
      score: BigInt(score),
      displayName: playerNames.get(playerId),
      prize: calculatePrize(tournamentId, index + 1),
    }));

    ws.send(JSON.stringify({ type: 'leaderboard_update', data: leaderboard }));
  };

  // Відправляємо відразу і потім кожні 15 секунд
  sendLeaderboard();
  const interval = setInterval(sendLeaderboard, 15_000);
  ws.on('close', () => clearInterval(interval));
});

Для гравця важливо бачити свою позицію: Redis підтримує ZRANK — O(log N) отримання рангу конкретного гравця.

Спеціальні механіки турнірів

Rebuy система

// Гравець може купити додаткові спроби (rebuys) на ранній фазі турніру
function rebuy(bytes32 tournamentId) external payable {
    Tournament storage t = tournaments[tournamentId];
    require(block.timestamp < t.rebuyDeadline, "Rebuy period ended");
    require(msg.value == t.rebuyFee, "Wrong rebuy fee");
    
    PlayerTournamentData storage pd = playerData[tournamentId][msg.sender];
    require(pd.rebuys < t.maxRebuys, "Max rebuys reached");
    
    pd.rebuys++;
    uint256 rakeAmount = msg.value * t.rake / 10_000;
    t.prizePool += msg.value - rakeAmount;
    treasury.transfer(rakeAmount);
    
    // Game server отримує сигнал: скинути очки гравця до стартових
    emit RebuyPurchased(tournamentId, msg.sender, pd.rebuys);
}

Satellite tournaments: вхід у великі турніри через дрібні

Класична poker механіка: виграй у $5 сателіті → отримай квиток на $100 турнір. У крипто: prize — NFT ticket або SBT (Soulbound Token), що дає право входу.

// Prize: NFT tournament ticket
function distributeSatellitePrizes(
    bytes32 satelliteId,
    address[] calldata winners,
    bytes calldata signature
) external {
    _verifyRankingSignature(satelliteId, winners, signature);
    
    Tournament storage sat = tournaments[satelliteId];
    require(block.timestamp > sat.endTime, "Not ended");
    
    uint256 numTickets = sat.prizes.length; // тільки топ N отримують квитки
    for (uint256 i = 0; i < numTickets && i < winners.length; i++) {
        // Мінтимо tournament ticket NFT
        uint256 ticketId = ticketNFT.mint(winners[i], sat.targetTournamentId);
        emit TicketAwarded(satelliteId, winners[i], ticketId, sat.targetTournamentId);
    }
}

Як налаштувати anti-fraud у турнірній системі?

Collusion detection

У PvP турнірах гравці можуть домовлятися. On-chain методи обмежені, але:

• Rate limiting: не більше 1 ставки за N секунд у турнірні ігри
• IP/device fingerprinting на backend (off-chain)
• Обмеження: гравці з одного wallet cluster не можуть брати участь в одному турнірі

Anti-self-dealing

Оператор не повинен мати можливість маніпулювати підсумками. Рішення: результати записуються від game server через GAME_SERVER_ROLE, ranking підписується оператором через multisig (не single signer).

// Багатопідписна фіналізація (2-of-3 серед операторів)
function finalizeRanking(
    bytes32 tournamentId,
    address[] calldata ranked,
    bytes[] calldata signatures // 2 з 3 операторів
) external {
    require(_verifyMultisig(tournamentId, ranked, signatures, 2), "Need 2 signatures");
    _distributePrizes(tournamentId, ranked);
}

Стек розробки

Контракти: Solidity + Foundry. OpenZeppelin AccessControl. ERC-721 для tournament tickets. Backend: Node.js + TypeScript. Redis Sorted Sets для leaderboard. PostgreSQL для історії. Real-time: WebSocket сервер. Bull/BullMQ для фонових завдань (score aggregation, finalization). Frontend: React + wagmi + Socket.io client.

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

Що входить у роботу

• Аналіз вимог та проектування архітектури
• Розробка смарт-контрактів (prize pool, tickets, distribution) з аудитом
• Backend (score tracking, leaderboard, WebSocket)
• Frontend (dashboard, leaderboard widget)
• Інтеграція з ігровим сервером (метрики, scoring rules)
• Деплой та налаштування моніторингу (Tenderly, Grafana)
• Навчання команди (admin panel)
• Технічна підтримка 3 місяці

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

MVP (leaderboard tournament, один тип гри, автоматична дистриб'юція): 4–5 тижнів. Повна система (всі типи турнірів, rebuy, сателіти, real-time leaderboard, fraud detection): 10–14 тижнів.

Більше 5 років досвіду в блокчейн-розробці, 15+ реалізованих проєктів для крипто-казино. Гарантуємо безпеку та прозорість. Замовте розробку системи турнірів під ключ — оцінимо ваш проєкт за 1 день. Зв'яжіться з нами для консультації.

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-механізми реально працюють?

Наш досвід — десятки реалізованих проєктів у Web3, включно з аудитом 15+ P2E ігор. Ми знаємо, які sink'и працюють у довгостроковій перспективі. Наприклад, у проєкті з breeding RPG ми збільшили спалювання utility token на 300% за рахунок введення «ремеслу зношуваності» та обов'язкових апгрейдів.

On-chain vs Off-chain: де проходить межа

Всю ігрову логіку on-chain виносити не потрібно — кожна транзакція коштує газу і триває 12 секунд. Ігровий цикл — мілісекунди. Баланс:

Результати геймплею переносяться на блокчейн через 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% порівняно з поелементним нарахуванням.

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

Починаємо з 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).