Настройка приема ставок в множественных криптовалютах для казино

Настройка приёма ставок в нескольких криптовалютах для казино

Принимать ставки в BTC, ETH, USDT, BNB, SOL и ещё двадцати токенах — технически нетривиальная задача. Каждая сеть имеет свою модель адресации, финальности, комиссий и скорости. Если не спроектировать это правильно, получите либо frozen funds (depозит не зачислен из-за неверного подтверждения), либо дыру в учёте (USDT на Ethereum и USDT на TRON — разные токены, разные сети, но одна строчка в базе).

Архитектура мультивалютного приёма ставок

HD-кошельки и уникальные адреса

Каждому пользователю нужен уникальный адрес для каждой сети — иначе нельзя автоматически сопоставить входящий платёж с конкретным аккаунтом. Стандартный подход: HD-кошелёк (BIP-32/BIP-44) с деривацией адресов.

Master seed → деривация по пути m/44'/coin_type'/account'/0/index:

import { HDKey } from '@scure/bip32'
import { mnemonicToSeedSync } from '@scure/bip39'

const masterSeed = mnemonicToSeedSync(process.env.MASTER_MNEMONIC!)
const masterKey = HDKey.fromMasterSeed(masterSeed)

function deriveAddress(coinType: number, userId: number): string {
  // BIP-44: m/44'/coinType'/0'/0/userId
  const child = masterKey.derive(`m/44'/${coinType}'/0'/0/${userId}`)
  // Для EVM-сетей coinType=60, Bitcoin=0, Solana=501
  return toChecksumAddress(child.publicKey)
}

Для EVM-совместимых сетей (Ethereum, BNB Chain, Polygon, Arbitrum) — один адрес работает во всех сетях, но это РАЗНЫЕ балансы. Не смешивайте: пользователь может отправить ETH на его BSC-адрес — монеты будут на другой сети и никогда не зачислятся.

Мониторинг входящих транзакций

Два подхода:

Webhook-based через платёжный провайдер (NOWPayments, CoinsPaid, Binance Pay API). Провайдер мониторит адреса и шлёт webhook при поступлении. Быстро интегрировать, но: провайдер имеет доступ к вашим средствам, fees выше, меньше контроля.

Self-hosted мониторинг — собственный сервис слушает ноды и индексирует входящие транзакции. Полный контроль, ниже затраты при объёме, но: ответственность за инфраструктуру.

// Мониторинг EVM адресов через eth_getLogs + transfer topic
const TRANSFER_TOPIC = '0xddf252ad1be2c89b69c2b068fc378daa952ba7f163c4a11628f55a4df523b3ef'

async function monitorIncomingTransfers(
  addresses: string[],
  fromBlock: number
) {
  const logs = await client.getLogs({
    fromBlock: BigInt(fromBlock),
    toBlock: 'latest',
    topics: [
      TRANSFER_TOPIC,
      null,                           // from: любой
      addresses.map(padAddress),      // to: наши адреса
    ],
  })

  for (const log of logs) {
    const token = log.address          // ERC-20 контракт
    const to = unpadAddress(log.topics[2])
    const amount = BigInt(log.data)
    await processDeposit({ token, to, amount, txHash: log.transactionHash, blockNumber: log.blockNumber })
  }
}

Финальность по сетям: сколько подтверждений ждать

Главная ошибка — зачислять ставку после 1 подтверждения во всех сетях. Реорги случаются, и ставка окажется зачисленной без реальных средств.

Для ставок разумный компромисс: Ethereum — 12 подтверждений, быстрые L1 (BSC, Tron) — 20 подтверждений, Solana — finalized status.

Учёт мультивалютного баланса

База данных должна различать не просто "токен", а "токен + сеть":

CREATE TABLE user_balances (
    user_id       BIGINT NOT NULL,
    network       VARCHAR(50) NOT NULL,  -- 'ethereum', 'bsc', 'tron'
    token_address VARCHAR(100),          -- NULL для native token
    token_symbol  VARCHAR(20) NOT NULL,
    raw_amount    NUMERIC(78, 0) NOT NULL, -- wei/lamports, без decimals
    decimals      SMALLINT NOT NULL,
    PRIMARY KEY (user_id, network, COALESCE(token_address, 'native'))
);

-- USDT на разных сетях — РАЗНЫЕ строки
-- user_id=1, network='ethereum', token='0xdAC17F...', symbol='USDT'
-- user_id=1, network='tron',     token='TR7NHqjeKQ...', symbol='USDT'

Никогда не складывайте raw_amount токенов с разными decimals без нормализации. USDT = 6 decimals, большинство ERC-20 = 18 decimals.

Конвертация в единую валюту учёта

Казино нужно считать GGR (Gross Gaming Revenue) в единой валюте (обычно USD или EUR). Для этого нужен price feed:

// Фиксируем USD-стоимость на момент ставки
async function recordBet(userId: number, currency: string, network: string, rawAmount: bigint, decimals: number) {
  const humanAmount = Number(rawAmount) / Math.pow(10, decimals)
  const usdPrice = await priceOracle.getPrice(currency) // Chainlink, CoinGecko, Binance
  const usdValue = humanAmount * usdPrice

  await db.query(`
    INSERT INTO bets (user_id, currency, network, raw_amount, decimals, usd_value_at_time, placed_at)
    VALUES ($1, $2, $3, $4, $5, $6, NOW())
  `, [userId, currency, network, rawAmount.toString(), decimals, usdValue])
}

Фиксируйте USD-стоимость в момент ставки — иначе PnL отчёты будут зависеть от текущего курса, что делает финансовую отчётность непредсказуемой.

Безопасность: горячий и холодный кошельки

Не держите все средства пользователей на hot wallet. Стандартная схема:

• Hot wallet — 5-10% от суточного оборота. Мгновенные выплаты.
• Cold/warm wallet (multisig) — остальное. Sweep происходит по расписанию.

Автоматический sweep: как только баланс депозитного адреса превышает пороговое значение, автоматически переводить на hot wallet агрегационный адрес. Иначе средства разбросаны по тысячам адресов и управлять ими невозможно.

Провайдеры vs self-hosted

Для небольшого казино (< $100k оборота/день) — провайдер оправдан. При росте объёмов комиссия провайдера становится значительной статьёй расходов, self-hosted окупается за месяцы.