Настройка приёма ставок в нескольких криптовалютах для казино
Мы разработали и внедрили систему мультивалютных депозитов для казино с оборотом $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 подтверждения во всех сетях. Реорги случаются, и ставка окажется зачисленной без реальных средств.
| Сеть | Рекомендуемые подтверждения | Примерное время |
|---|---|---|
| Bitcoin | 3-6 | 30-60 мин |
| Ethereum | 12-15 (PoS safe) | 3-4 мин |
| BNB Chain | 15-20 | 60-90 сек |
| Polygon | 256 (checkpoint на ETH) | ~10 мин |
| Solana | 32 (finalized) | ~15 сек |
| TRON | 19 (SR solid) | ~60 сек |
| Arbitrum | 1 (L2 finality) | сек (soft), 7 дней (challenge period) |
Для ставок разумный компромисс: 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: что выбрать?
| Параметр | Провайдер (NOWPayments, CoinsPaid) | Self-hosted |
|---|---|---|
| Время интеграции | 1-3 дня | 2-4 недели |
| Комиссия | 0.5-1% с оборота | Только gas |
| Контроль приватных ключей | У провайдера | У вас |
| Мультисеть | 30-200+ монет из коробки | Сколько реализуете |
| Кастомизация подтверждений | Ограничена | Полная |
Для небольшого казино (< $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. Свяжитесь с нами для бесплатной оценки вашего проекта. Получите консультацию нашего технического лида.