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

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

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

Предлагаем готовое решение под ключ: от генерации HD-кошельков до мониторинга транзакций и интеграции с бухгалтерией. Вы получаете единый интерфейс для приёма ставок в любых токенах, конвертацию в USD для расчёта GGR и безопасное хранение средств с автоматическим выводом на cold wallet. Оценим ваш проект.

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

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 агрегационный адрес. Иначе средства разбросаны по тысячам адресов и управлять ими невозможно.

Провайдер или self-hosted: что выбрать?

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

Что входит в работу

• Анализ требований и подбор архитектуры (провайдер или self-hosted, список сетей).
• Генерация master seed и HD-кошельков, деривация адресов для всех пользователей.
• Настройка мониторинга транзакций (webhook или собственный сервис).
• Интеграция с вашей платформой (API для депозитов, выплат, проверки баланса).
• Реализация конвертации в USD для финансовой отчётности.
• Настройка hot/cold wallet и автоматического sweep.
• Тестирование на testnet и mainnet, включая edge-кейсы (reorg, fee spikes).
• Документация по API и администрированию.
• Обучение вашей команды.
• Гарантия на код и поддержка 3 месяца после запуска.

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

Мы — команда блокчейн-инженеров с 5+ годами опыта в смарт-контрактах и DeFi. Сертифицированные разработчики Solidity и Rust. Запустили 30+ проектов с совокупным оборотом более $50M. Гарантируем безопасность: используем Slither, Mythril и формальную верификацию. Наши ноды имеют 100% uptime. Свяжитесь с нами для оценки вашего проекта. Получите консультацию нашего технического лида.