Интеграция крипто-казино с провайдерами игр

Интеграция крипто-казино с провайдерами игр

Крипто-казино технически сложнее обычного online casino по одной причине: транзакции необратимы и публично верифицируемы. Если классическое казино может откатить выплату "по техническим причинам", крипто-казино не может. Если смарт-контракт выплатил неправильную сумму — это уже on-chain. Поэтому интеграция с игровыми провайдерами должна быть спроектирована с учётом этих реалий.

Архитектура интеграции: где казино встречается с провайдером

Типичные игровые провайдеры

Большинство крупных провайдеров (Pragmatic Play, Evolution, Hacksaw, BGaming, Spinomenal) предоставляют Seamless wallet integration или Transfer wallet integration:

Seamless wallet — провайдер обращается к вашему API за каждой ставкой и выплатой в реальном времени. Ваш сервер авторизует дебет/кредит мгновенно. Latency критична: провайдер ожидает ответ < 1–2 секунды.

Transfer wallet — у игрока есть два баланса: ваш основной и временный у провайдера. Игрок сам делает transfer перед игрой и выводит после. Проще технически, но хуже UX.

Для крипто-казино seamless wallet создаёт challenge: провайдер ожидает мгновенный ответ, а крипто-транзакции не мгновенны. Решение — off-chain баланс в вашей базе данных, который синхронизируется с on-chain средствами.

Двухуровневый баланс

On-chain: пользователь держит USDC в смарт-контракте казино
                ↕ deposit / withdrawal
Off-chain: ваша БД хранит "игровой баланс" (мгновенные обновления)
                ↕ seamless API calls
Провайдер игры: делает bet/win вызовы к вашему API

Депозит: пользователь отправляет USDC в контракт → ваш сервис детектирует on-chain событие → зачисляет на off-chain баланс → пользователь может играть.

Вывод: пользователь запрашивает вывод → вы резервируете сумму → инициируете on-chain withdrawal из контракта → при подтверждении помечаете как выполненный.

Seamless Wallet API: что должен реализовать ваш бэкенд

Провайдер обращается к вашим эндпоинтам. Стандартный набор:

POST /wallet/balance     — получить баланс игрока
POST /wallet/debit       — списать ставку
POST /wallet/credit      — зачислить выигрыш
POST /wallet/rollback    — откат транзакции (при ошибке на стороне провайдера)
POST /wallet/check       — проверка статуса транзакции

Ключевые требования к реализации:

Идемпотентность — провайдер может прислать один и тот же запрос несколько раз (retry при timeout). Каждый debit/credit имеет уникальный transactionId. Если такой ID уже обработан — возвращаем тот же результат без повторного применения:

async function processDebit(req: DebitRequest): Promise<DebitResponse> {
  // Проверяем идемпотентность
  const existing = await db.transactions.findByProviderTxId(req.transactionId);
  if (existing) {
    return { balance: existing.balanceAfter, transactionId: req.transactionId };
  }

  return await db.transaction(async (trx) => {
    const user = await trx.users.lockForUpdate(req.userId);
    if (user.balance < req.amount) {
      throw new InsufficientFundsError();
    }
    const newBalance = user.balance - req.amount;
    await trx.users.updateBalance(req.userId, newBalance);
    await trx.transactions.create({
      providerTxId: req.transactionId,
      userId: req.userId,
      type: "debit",
      amount: req.amount,
      balanceAfter: newBalance,
    });
    return { balance: newBalance, transactionId: req.transactionId };
  });
}

Атомарность — баланс и запись транзакции обновляются в одной БД транзакции. SELECT FOR UPDATE чтобы избежать race conditions при параллельных запросах.

Rollback — провайдер вызывает rollback если на их стороне произошла ошибка после debit. Вы должны восстановить баланс. Rollback может прийти через часы после оригинальной транзакции.

On-chain контракт казино

Базовая структура

// SPDX-License-Identifier: MIT
pragma solidity ^0.8.20;

import "@openzeppelin/contracts/token/ERC20/IERC20.sol";
import "@openzeppelin/contracts/access/AccessControl.sol";
import "@openzeppelin/contracts/utils/ReentrancyGuard.sol";
import "@openzeppelin/contracts/utils/Pausable.sol";

contract CasinoVault is AccessControl, ReentrancyGuard, Pausable {
    bytes32 public constant OPERATOR_ROLE = keccak256("OPERATOR_ROLE");
    
    IERC20 public immutable token;
    
    // Резервы для выплат (всегда должно быть достаточно)
    uint256 public playerFundsReserve;
    
    event Deposit(address indexed player, uint256 amount);
    event Withdrawal(address indexed player, uint256 amount);
    
    function deposit(uint256 amount) external nonReentrant whenNotPaused {
        token.transferFrom(msg.sender, address(this), amount);
        playerFundsReserve += amount;
        emit Deposit(msg.sender, amount);
    }
    
    // Только оператор инициирует выплату (после off-chain авторизации)
    function withdraw(
        address player, 
        uint256 amount,
        bytes calldata signature  // EIP-712 подпись от авторизующего сервера
    ) external nonReentrant whenNotPaused {
        _verifyWithdrawalSignature(player, amount, signature);
        require(playerFundsReserve >= amount, "Insufficient reserves");
        playerFundsReserve -= amount;
        token.transfer(player, amount);
        emit Withdrawal(player, amount);
    }
}

Provably fair механика

Для on-chain игр (не провайдерских, а собственных) важна доказуемая честность. Классический подход — commit-reveal:

1. Сервер публикует commitment = keccak256(serverSeed) перед раундом
2. Игрок делает ставку с clientSeed
3. После ставки сервер reveals serverSeed
4. Результат = keccak256(serverSeed + clientSeed + nonce) — верифицируемо любым

Для VRF (Verifiable Random Function) на-chain — Chainlink VRF v2. Запрос случайности стоит LINK, ответ приходит в отдельной транзакции (~1–3 минуты). Подходит для jackpot и редких событий, не для real-time слотов.

Безопасность и compliance

Ограничения и лимиты

uint256 public maxDailyWithdrawal = 100_000 * 1e6; // 100k USDC
mapping(address => uint256) public dailyWithdrawn;
mapping(address => uint256) public lastWithdrawalDay;

modifier checkDailyLimit(address player, uint256 amount) {
    uint256 today = block.timestamp / 1 days;
    if (lastWithdrawalDay[player] < today) {
        dailyWithdrawn[player] = 0;
        lastWithdrawalDay[player] = today;
    }
    require(dailyWithdrawn[player] + amount <= maxDailyWithdrawal, "Daily limit exceeded");
    dailyWithdrawn[player] += amount;
    _;
}

KYC/AML интеграция

Несмотря на Web3, большинство юрисдикций требует KYC при выводе выше определённых сумм. Chainalysis или Elliptic для on-chain AML screening — проверка входящих депозитов на принадлежность к санкционированным адресам или миксерам.

Workflow: wallet address screening при первом депозите → manual review если risk score > threshold → block withdrawal если confirmed high-risk.

Мониторинг и операционка

Баланс резервов: контракт всегда должен иметь достаточно средств для покрытия всех off-chain балансов игроков. Автоматический мониторинг: если playerFundsReserve < sum(all player balances) * 1.05 — алерт.

Аномалии выплат: необычно большой выигрыш, подозрительный паттерн ставок (идеальное использование rollback), массовые выводы — триггеры для manual review.

Провайдер uptime: если провайдер недоступен — нужен graceful degradation, не 500 ошибки у пользователя. Circuit breaker: после N ошибок — временно отключить провайдера, показать "игра на техобслуживании".

Срок разработки MVP интеграции с одним провайдером: 6–10 недель с учётом тестирования на staging окружении провайдера.