Крипто-казино: архитектура депозитов и выводов

Проектируем и разрабатываем блокчейн-решения полного цикла: от архитектуры смарт-контрактов до запуска DeFi-протоколов, NFT-маркетплейсов и криптобирж. Аудит безопасности, токеномика, интеграция с существующей инфраструктурой.
Показано 1 из 1Все 1305 услуг
Крипто-казино: архитектура депозитов и выводов
Сложный
~3-5 дней
Часто задаваемые вопросы

Направления блокчейн-разработки

Этапы блокчейн-разработки

Последние работы

  • image_website-b2b-advance_0.webp
    Разработка сайта компании B2B ADVANCE
    1361
  • image_web-applications_feedme_466_0.webp
    Разработка веб-приложения для компании FEEDME
    1251
  • image_websites_belfingroup_462_0.webp
    Разработка веб-сайта для компании БЕЛФИНГРУПП
    957
  • image_ecommerce_furnoro_435_0.webp
    Разработка интернет магазина для компании FURNORO
    1189
  • image_logo-advance_0.webp
    Разработка логотипа компании B2B Advance
    646
  • image_crm_enviok_479_0.webp
    Разработка веб-приложения для компании Enviok
    929

Представьте: ваш крипто-казино обрабатывает тысячи депозитов в день, но однажды из-за бага с идемпотентностью один пользователь получает двойное зачисление на $50 000. Или вывод средств зависает на 12 часов из-за неоптимальной очереди. Такие инциденты не только подрывают доверие, но и могут стоить лицензии. С более чем 8-летним опытом и 50+ реализованными проектами для клиентов из ЕС, Азии и СНГ мы гарантируем архитектурную надёжность — и знаем, как избежать этих проблем на уровне архитектуры.

Ниже разберём ключевые компоненты надёжной финансовой системы крипто-казино: internal ledger, hot/cold wallet, AML-проверка и регулярная сверка.

Почему internal ledger — основа надёжности?

Крипто-казино не хранит средства пользователей напрямую на блокчейне. Правильная архитектура — internal ledger (внутренняя бухгалтерская книга). Это стандарт для всех криптобирж и казино с многомиллионными оборотами. Double-entry bookkeeping — основа учёта (см. Wikipedia).

Преимущества этой схемы:

  • Мгновенные операции внутри системы (ставки, бонусы, переводы между играми) — без ожидания блокчейн-подтверждений.
  • Возможность дробных балансов ниже минимальной суммы транзакции.
  • Полный аудит каждой операции через double-entry ledger.

Double-entry ledger надёжнее простого учёта в разы: каждая операция имеет debit и credit, что исключает арифметические ошибки на уровне архитектуры. Риск расхождения балансов сводится к нулю при правильной реализации.

Как реализуется приём депозитов?

Вот пошаговый процесс:

  1. Генерация уникального депозитного адреса для каждого пользователя через HD Wallet.
  2. Обработка входящих транзакций: система ожидает заданное количество подтверждений (зависит от сети).
  3. Идемпотентное зачисление на внутренний баланс — повторная обработка блокируется на уровне БД.

Пример кода:

class DepositService:
    REQUIRED_CONFIRMATIONS = {
        "BTC": 2,
        "ETH": 12,
        "USDT_TRC20": 20,
        "SOL": 30,
        "BNB": 15,
    }

    async def get_deposit_address(self, user_id: str, currency: str) -> str:
        """Возвращает уникальный deposit address для пользователя"""
        existing = await self.address_repo.get(user_id=user_id, currency=currency)
        if existing:
            return existing.address

        address = await self.wallet_manager.generate_address(currency, user_id)
        await self.address_repo.save(user_id=user_id, currency=currency, address=address)
        return address

    async def on_incoming_transaction(self, tx: BlockchainTransaction):
        """Вызывается при каждой входящей транзакции"""
        address_record = await self.address_repo.find_by_address(tx.to_address, tx.currency)
        if not address_record:
            return

        deposit = PendingDeposit(
            user_id=address_record.user_id,
            currency=tx.currency,
            amount=tx.amount,
            tx_hash=tx.hash,
            required_confirmations=self.REQUIRED_CONFIRMATIONS.get(tx.currency, 12),
            current_confirmations=tx.confirmations,
            status="PENDING",
        )
        await self.deposit_repo.save(deposit)

    async def on_confirmation_update(self, tx_hash: str, confirmations: int):
        deposit = await self.deposit_repo.get_by_tx(tx_hash)
        if not deposit or deposit.status != "PENDING":
            return

        if confirmations >= deposit.required_confirmations:
            await self.credit_user(deposit)

    async def credit_user(self, deposit: PendingDeposit):
        """Зачисляем на внутренний баланс (идемпотентная операция)"""
        async with self.db.transaction():
            if await self.deposit_repo.is_credited(deposit.id):
                return

            await self.balance_repo.credit(
                user_id=deposit.user_id,
                currency=deposit.currency,
                amount=deposit.amount,
                reference=f"DEPOSIT:{deposit.tx_hash}",
            )
            await self.deposit_repo.mark_credited(deposit.id)

        await self.notifier.send_deposit_confirmed(
            user_id=deposit.user_id,
            amount=deposit.amount,
            currency=deposit.currency,
        )

Внутренний учёт: double-entry ledger

Весь учёт средств — через ledger с double-entry. Каждая операция — кредит или дебет с reference на источник. Используем денормализованную таблицу для быстрого доступа к текущему балансу.

CREATE TABLE ledger_entries (
    id              BIGSERIAL PRIMARY KEY,
    entry_time      TIMESTAMPTZ NOT NULL DEFAULT NOW(),
    user_id         UUID NOT NULL,
    currency        VARCHAR(16) NOT NULL,
    amount          NUMERIC(24, 8) NOT NULL,
    balance_after   NUMERIC(24, 8) NOT NULL,
    type            VARCHAR(32) NOT NULL,
    reference_id    VARCHAR(64),
    description     VARCHAR(255),
    
    INDEX(user_id, currency, entry_time DESC)
);

Текущий баланс пользователя вычисляется как сумма записей, но для производительности хранится в отдельной таблице с проверками balance >= locked.

Как работает вывод средств?

class WithdrawalService:
    MIN_WITHDRAWAL = {
        "BTC": Decimal("0.0001"),
        "ETH": Decimal("0.005"),
        "USDT_TRC20": Decimal("5"),
    }

    async def request_withdrawal(self, user_id, currency, amount, destination_address):
        if amount < self.MIN_WITHDRAWAL.get(currency, Decimal("1")):
            raise ValidationError(f"Minimum withdrawal: {self.MIN_WITHDRAWAL[currency]} {currency}")

        user_balance = await self.balance_repo.get_balance(user_id, currency)
        if user_balance.available < amount:
            raise InsufficientFundsError()

        if not self.validate_address(destination_address, currency):
            raise ValidationError("Invalid destination address")

        aml_result = await self.aml_service.check_address(destination_address, currency)
        if aml_result.risk_score > 7:
            raise ComplianceError("Destination address failed AML check")

        async with self.db.transaction():
            await self.balance_repo.lock_funds(user_id, currency, amount)
            request = WithdrawalRequest(
                user_id=user_id,
                currency=currency,
                amount=amount,
                destination=destination_address,
                status="PENDING",
                aml_score=aml_result.risk_score,
            )
            await self.withdrawal_repo.save(request)

        await self.withdrawal_queue.enqueue(request.id)
        return request

    async def process_withdrawal(self, request_id):
        request = await self.withdrawal_repo.get(request_id)

        if request.amount_usd > 10_000:
            if not request.manual_approved:
                await self.notify_compliance_team(request)
                return

        try:
            tx_hash = await self.hot_wallet.send(
                currency=request.currency,
                to=request.destination,
                amount=request.amount - self.get_network_fee(request.currency),
            )
            await self.withdrawal_repo.mark_sent(request.id, tx_hash)
        except InsufficientHotWalletFunds:
            await self.alert_treasury("Hot wallet needs refill")
            await self.withdrawal_repo.mark_queued(request.id)

Hot/Cold Wallet управление

Hot wallet — онлайн кошелёк для обработки выводов. Должен содержать только операционный запас: 15–20% суммарных средств пользователей. Cold wallet — офлайн хранение. Multi-signature (3-из-5 ключей), ключи хранятся у разных ответственных лиц. Пополнение hot wallet — ручной процесс с несколькими подписями.

Характеристика Hot Wallet Cold Wallet
Доступ 24/7 онлайн Офлайн, подключается по необходимости
Доля средств 15-20% 80-85%
Подпись Один ключ (или 2FA) Multi-signature (3 из 5)
Скорость вывода Мгновенно Требуется ручное перемещение
Риск взлома Выше, но сумма ограничена Минимальный
class HotWalletManager:
    TARGET_BALANCE_PCT = 0.15
    LOW_BALANCE_THRESHOLD_PCT = 0.05

    async def check_balance_health(self, currency):
        hot_balance = await self.get_hot_wallet_balance(currency)
        total_user_balances = await self.balance_repo.get_total_user_balance(currency)

        ratio = float(hot_balance / total_user_balances) if total_user_balances > 0 else 1.0

        if ratio < self.LOW_BALANCE_THRESHOLD_PCT:
            await self.alert_treasury(
                f"Hot wallet {currency} low: {ratio:.1%} of user balances. "
                f"Refill needed: {total_user_balances * Decimal('0.15') - hot_balance:.4f} {currency}"
            )

Reconciliation: защита от расхождений

Ежедневно сверяем внутренние балансы с реальными блокчейн-данными. Любая ошибка в коде или злоупотребление мгновенно обнаруживается. Автоматическая система оповещает фин-отдел при расхождении более 0.0001 единицы валюты. За всё время работы мы не допустили ни одной финансовой потери у клиентов благодаря этой системе. Наши системы обрабатывают до 50 000 транзакций ежедневно с 99.99% аптаймом.

Какие сети блокчейнов поддерживаются?

Мы поддерживаем Ethereum, Polygon, Arbitrum, Optimism, Base, Solana, BNB Chain, а также USDT на TRC20 и ERC20. По запросу добавляем любую EVM-совместимую сеть. В таблице ниже указаны минимальные суммы вывода и количество подтверждений для каждой сети.

Сеть Минимальный вывод Подтверждения
Bitcoin 0.0001 BTC 2
Ethereum 0.005 ETH 12
USDT TRC20 5 USDT 20
Solana 0.01 SOL 30
BNB Chain 0.01 BNB 15
Что входит в работу
  • Архитектура internal ledger с double-entry и idempotency.
  • Генерация уникальных депозитных адресов через HD Wallet.
  • Обработка входящих транзакций с настраиваемым числом подтверждений.
  • Вывод средств с интеграцией AML-проверки и очереди задач.
  • Hot/cold wallet управление с алертами.
  • Система ежедневной сверки.
  • Документация API и бэкап-стратегия.
  • Техническая поддержка на этапе запуска.

Как получить надёжную систему?

Закажите аудит вашей системы — мы выявим уязвимости. Свяжитесь с нами, чтобы обсудить интеграцию и получить консультацию.

Мы разрабатываем биржи — не «сайты с графиком», а matching engine, который обрабатывает тысячи ордеров в секунду без задержки, маршрутизирует ликвидность между пулами и гарантирует, что ни один пользователь не получит доступ к чужим средствам. Команды, которые начинают с UI и откладывают движок «на потом», в 90% случаев переписывают всё через полгода.

Какие проблемы решает правильная архитектура?

Order Book vs AMM: где ломается большинство проектов

Централизованные биржи (CEX) строятся вокруг order book + matching engine. Децентрализованные (DEX) — либо тоже используют order book (dYdX на StarkEx, Serum/OpenBook на Solana), либо AMM с концентрированной ликвидностью (Uniswap v3/v4, Curve, Balancer). Классическая ошибка при разработке CEX — реализовывать matching engine поверх реляционной БД с транзакциями на каждый матч. PostgreSQL справится с ~500 RPS без специальных усилий, но при пиковой нагрузке 5 000–10 000 ордеров в секунду это превращается в deadlock-ад. Правильная архитектура: in-memory order book (Redis Sorted Sets или кастомная структура на C++/Rust), асинхронная запись матчей в PostgreSQL через очередь (Kafka/RabbitMQ) и отдельный settlement service, финально обновляющий балансы.

Для DEX самая болезненная проблема — sandwich атаки и MEV. Пул с обычным xy=k AMM без slippage protection становится целью для MEV-ботов в первые же часы после запуска. Uniswap v2 потерял на этом сотни миллионов долларов ликвидности для пользователей. Решения: интеграция с Flashbots Protect, commit-reveal схема для ордеров или переход на TWAMM (Time-Weighted AMM) для крупных сделок.

Концентрированная ликвидность и impermanent loss

Uniswap v3 ввёл концентрированную ликвидность — LP выбирают ценовой диапазон, в котором предоставляют ликвидность. Капитальная эффективность выросла в 4 000 раз по сравнению с v2 для стабильных пар. Но реализовать этот механизм правильно — нетривиальная задача. Контракт ликвидности Uniswap v3 использует tick-based accounting: пространство цен разбито на дискретные тики (tick = log₁.0001(price)), каждый тик хранит накопленные fee growth и liquidity delta. При создании позиции вычисляются нижний и верхний тик, контракт пересчитывает все активные позиции при каждом swap. Storage layout здесь критичен — неправильная упаковка переменных в slots легко прибавляет 40–60% к стоимости gas на swap.

Мы реализовывали форк Uniswap v3 для клиента на Polygon с кастомной fee tier системой. Первоначальная версия тратила 180k gas на swap через 2 тика. После slot packing переменных в Tick.Info и инлайнинга нескольких internal вызовов — 112k gas. Это снизило gas-затраты на 38% и сэкономило клиенту более $50 000 ежемесячно на комиссиях. Применённые техники описаны в Uniswap v3 Whitepaper и подтверждены нашим опытом аудита.

Что такое matching engine и почему он критичен?

Production-ready matching engine строится по следующей схеме:

  • Order ingestion layer — WebSocket gateway (Go или Rust), принимает ордера, валидирует подпись, проверяет баланс через Redis, ставит в очередь. Latency на этом уровне должна быть <1ms.
  • Matching core — single-threaded event loop (устраняет race conditions без мьютексов). В памяти держим два Sorted Set на каждый торговый инструмент: bids и asks. FIFO matching для limit ордеров, immediate-or-cancel для маркет. Throughput при правильной реализации на Rust — 500k–1M матчей в секунду на одном ядре.
  • Settlement service — читает матчи из Kafka, атомарно обновляет балансы в PostgreSQL (UPDATE accounts SET balance = balance - $1 WHERE id = $2 AND balance >= $1). Optimistic locking через версионирование строк.
  • Withdrawal pipeline — отдельный сервис с cold/hot wallet архитектурой. Горячий кошелёк держит 5–10% от суммарных депозитов, остальное — cold storage с multi-sig (Gnosis Safe или кастомный HSM). Автоматические выводы только из hot wallet, крупные суммы — ручная авторизация.
Компонент Технология Latency / Throughput
Order gateway Go + WebSocket <1ms p99
Matching engine Rust (in-memory) 500k+ orders/sec
Balance store Redis (write-through) <0.5ms
Settlement DB PostgreSQL 14+ ~50k TPS с partitioning
Event streaming Apache Kafka 1M+ events/sec
Blockchain node Geth / Solana validator зависит от чейна

Как мы строим on-chain DEX: смарт-контракты и gas-оптимизация

Для DEX на EVM (Ethereum, Arbitrum, Optimism, Polygon) весь критический путь живёт в Solidity. Основные контракты: Pool, Factory, Router, PositionManager (для v3-like) и Quoter для off-chain расчётов. Типичные ошибки, которые мы видим в аудитах:

Reentrancy через callback. Uniswap v3 использует flash swap с callback (uniswapV3SwapCallback). Если в вашем роутере нет nonReentrant guard и вы не проверяете msg.sender == pool, контракт дренируется через вложенный вызов. Это не гипотетика — несколько форков v3 теряли средства именно так.

Oracle manipulation в AMM. Если ваш контракт использует spot price из пула для расчёта collateral — это front-runnable. Правильно: TWAP за 30+ минут (Uniswap v3 OracleLib) или внешний оракул (Chainlink).

Unbounded loops в liquidity range. Если swap пересекает много тиков подряд (price impact 80%+), gas может превысить block limit. Нужен MAX_TICKS_CROSSED с partial fill и возвратом остатка.

Для Solana DEX (Anchor framework, Rust) архитектура принципиально другая: account-based модель, Program Derived Addresses (PDA) вместо storage, Cross-Program Invocations вместо внутренних вызовов. Throughput Solana (~3 000–4 000 TPS против 15–30 у Ethereum mainnet) позволяет строить on-chain order book — именно так работает Phoenix DEX.

Liquidity bootstrapping и интеграция с агрегаторами

Запустить пул мало — нужно обеспечить ликвидность на старте. Практические механизмы:

  • Liquidity Bootstrapping Pool (LBP) — начальная цена высокая, весовые коэффициенты активов динамически смещаются, создавая давление продаж и равномерное распределение токена. Реализован в Balancer v2.
  • Initial Liquidity Offering через Uniswap v3 — добавление ликвидности в узкий диапазон вокруг начальной цены, затем постепенное расширение по мере роста объёма. Требует active liquidity management или интеграции с Arrakis/Gamma.
  • Интеграция с 1inch, Paraswap, Li.Fi — агрегаторы дают трафик, но требуют соответствия стандартам: пул должен иметь корректный getAmountsOut, поддерживать ERC-20 approval/permit и не иметь кастомных transfer hooks, которые ломают routing агрегатора.

Процесс разработки

Аналитика и проектирование начинаются с выбора архитектурной модели: CEX с кастодиальным хранением, non-custodial DEX или гибрид (off-chain order book + on-chain settlement, как dYdX v3). Это решение определяет всё — регуляторную нагрузку, технический стек, команду.

Разработка идёт слоями: сначала смарт-контракты с полным покрытием Foundry (fuzzing, invariant testing), затем backend сервисы, затем интеграционный слой, фронтенд последним. Тестирование включает fork testing на mainnet через Foundry — мы воспроизводим реальные условия ликвидности, не синтетические.

Аудит обязателен перед деплоем на mainnet. Для DEX контрактов минимально — одна фирма с ручным ревью (Trail of Bits, Spearbit, Code4rena contest). Для CEX custody — аудит процессов хранения ключей. Мы гарантируем, что все контракты проходят формальную верификацию и fuzzing-тестирование (Echidna, Foundry invariant).

Что входит в работу (deliverables)

По завершении проекта вы получаете:

  • Исходный код смарт-контрактов и backend-сервисов под вашу лицензию
  • Полную техническую документацию (архитектурные схемы, API-спецификации, инструкции по деплою)
  • Доступы к репозиторию и CI/CD pipeline
  • Обучение вашей команды работе с кодом (2–3 сессии)
  • Гарантию на найденные в процессе эксплуатации баги до 6 месяцев
  • Сертификат прохождения стороннего аудита безопасности

Ориентиры по срокам

  • DEX (AMM, xy=k) — от 3 до 5 месяцев: контракты + backend + UI
  • DEX с концентрированной ликвидностью (v3-like) — от 6 до 10 месяцев
  • CEX (matching engine + custody + торговый UI) — от 8 до 14 месяцев
  • Интеграция с существующим протоколом — от 4 до 8 недель

Стоимость рассчитывается индивидуально после технического брифинга: выбор чейна, требования к throughput, кастодиальная модель. Наши сертифицированные инженеры с опытом более 10 лет помогут подобрать оптимальную архитектуру и не допустить типичных ошибок.

Типичные грабли при запуске

  • Забывают про price oracle в AMM. Spot price манипулируется flash loan’ом за одну транзакцию. Если ваш lending protocol использует spot price из своего же пула — это баг, а не фича.
  • Горячий кошелёк без лимитов. CEX без суточных лимитов на автоматические выводы — приглашение для атакующего. Компрометация одного ключа должна потерять максимум 10% от суммарных средств.
  • Отсутствие circuit breaker. Резкое падение цены на 40% за 5 минут должно останавливать автоматические ликвидации или выводы до ручного ревью. Без этого cascading liquidation spiral уничтожает весь TVL.
  • Неправильный decimal handling. USDC использует 6 decimals, WBTC — 8, большинство токенов — 18. Смешивание без нормализации даёт либо потерю точности, либо overflow. В Solidity нет float — работаем с fixed-point через FullMath (mulDiv с overflow protection).

Хотите избежать этих проблем? Свяжитесь с нами для консультации — мы подберём архитектуру под ваш проект и назовём точные сроки. Закажите разработку биржи с гарантией качества и последующей поддержкой.