Розробка системи верифікації гравців крипто-казино під ключ

Система верифікації гравців крипто-казино: модульна архітектура

Спроектувати систему верифікації для крипто-казино — це знайти баланс між анонімністю Web3 та вимогами регуляторів. Крипто-казино працюють під подвійним тиском: користувачі цінують приватність, а ліцензуючі органи та платіжні партнери вимагають KYC, AML та перевірку віку. Це не просто юридична формальність — архітектура повинна забезпечувати комплаєнс, не відлякуючи аудиторію. Наш підхід — модульна tiered-система, яка адаптується під ліцензію та регіон. За 5+ років у блокчейн-розробці ми реалізували понад 30 KYC-рішень під ключ для крипто-проектів, включаючи казино та обмінники, і маємо сертифікати від Sumsub та Chainalysis.

Як працює tiered-верифікація? — розробка системи верифікації

Не всі гравці потребують однакової перевірки. Tiered approach — стандарт для gambling:

Tier 0 (мінімальний): електронна пошта, підключення гаманця та автоматичний AML-скринінг адреси через Chainalysis або Elliptic. Жодних документів, відповідь миттєва. Tier 1 (базовий): ім'я, дата народження, країна проживання. Автоматична перевірка за sanctions lists. Підтвердження акаунту через email або SMS. Tier 2 (розширений): government ID (паспорт, права), liveness check, адреса проживання. Використовуємо Sumsub, Onfido або аналог. Tier 3 (enhanced due diligence): Source of Funds, Source of Wealth, розширений PEP/Sanctions check, ручна перевірка комплаєнс-офіцером.

При налаштуванні рівнів у конфігурації задаються ліміти та вимоги для кожного tier. Наприклад, для Tier 0 ліміт по депозиту — 0.1 BTC/міс, для Tier 1 — 1 BTC. Рівні автоматично підвищуються при досягненні ліміту.

Які AML-інструменти використовувати?

Для казино критично: гроші з darknet markets або stolen funds — пряма відповідальність платформи. Порівняння провайдерів:

Згідно з документацією Chainalysis KYT, категорії ризику включають darknet market, stolen funds, ransomware, sanctions. Для таких адрес — reject депозиту та заморозка акаунту. Grey zone (gambling, P2P exchange, mixing) потребують ручного review. Окремо перевіряємо wallet-адреси в OFAC SDN List через Chainalysis або власний парсер — список оновлюється щоденно.

Sumsub обробляє запити в 3 рази швидше, ніж ручна верифікація, а Chainalysis KYT виявляє підозрілі транзакції на 95% точніше статичного OFAC-скринінгу.

Інтеграція Chainalysis KYT (Know Your Transaction)

async function screenAddress(address: string, asset: string): Promise<RiskScore> {
  const response = await chainalysisClient.post('/v1/users', {
    userId: address,
  });
  
  const transferResponse = await chainalysisClient.post('/v1/transfers', {
    network: asset,
    asset: asset,
    transferReference: address,
    direction: 'received',
  });
  
  return {
    riskScore: transferResponse.data.riskScore,
    cluster: transferResponse.data.cluster?.name,
    category: transferResponse.data.cluster?.category,
  };
}

Як інтегрувати KYC-провайдера?

Sumsub — стандартний вибір для gambling

Sumsub надає WebSDK для вбудованого flow. Генерація токена на бекенді:

async function getSumsubToken(applicantId: string): Promise<string> {
  const timestamp = Math.floor(Date.now() / 1000);
  const method = 'POST';
  const url = `/resources/accessTokens?userId=${applicantId}&levelName=basic-kyc-level`;
  
  const signature = crypto
    .createHmac('sha256', SUMSUB_SECRET_KEY)
    .update(timestamp + method + url)
    .digest('hex');

  const response = await axios.post(
    `https://api.sumsub.com${url}`,
    {},
    {
      headers: {
        'X-App-Token': SUMSUB_APP_TOKEN,
        'X-App-Access-Sig': signature,
        'X-App-Access-Ts': timestamp,
      }
    }
  );
  
  return response.data.token;
}

// Frontend ініціалізація
import SumsubWebSdk from "@sumsub/websdk";

const sdk = SumsubWebSdk.init(
  accessToken,
  () => refreshToken(),
  {
    lang: "uk",
    onMessage: (type, payload) => {
      if (type === "idCheck.onApplicantStatusChanged") {
        if (payload.reviewResult?.reviewAnswer === "GREEN") {
          handleKYCApproved(payload.applicantId);
        }
      }
    },
    onError: (error) => console.error("Sumsub error:", error),
  }
);

sdk.launch("#sumsub-container");

Важливий момент — перевірка підпису webhook, щоб не прийняти підроблений callback:

function verifySumsubWebhook(req: Request): boolean {
  const signature = req.headers['x-payload-digest'];
  const secret = process.env.SUMSUB_WEBHOOK_SECRET;
  
  const expectedSignature = crypto
    .createHmac('sha256', secret)
    .update(req.rawBody)
    .digest('hex');
    
  return crypto.timingSafeEqual(
    Buffer.from(signature),
    Buffer.from(expectedSignature)
  );
}

async function handleSumsubWebhook(payload: SumsubWebhookPayload) {
  const { applicantId, reviewResult, type } = payload;
  
  if (type === "applicantReviewed") {
    if (reviewResult.reviewAnswer === "GREEN") {
      await db.updateUserKYCStatus(applicantId, "APPROVED", reviewResult.reviewRejectType);
      await updateUserTier(applicantId);
    } else if (reviewResult.reviewAnswer === "RED") {
      await db.updateUserKYCStatus(applicantId, "REJECTED", reviewResult.moderationComment);
      await notifyUser(applicantId, "kyc_rejected");
    }
  }
}

Верифікація віку без документів

Для ринків, де документальний KYC неприйнятний, використовуємо Yoti Age Verification. Користувач отримує signed age token; казино бачить тільки "старше 18". AgeID (UK стандарт) — аналогічний підхід. Інтеграція через OAuth 2.0: Yoti виступає identity provider. KYC через Yoti виконується в 10 разів швидше за ручну перевірку віку.

Геоблокування та IP-верифікація

KYC не замінює геоблокування. Обов'язкові перевірки:

async function checkPlayerEligibility(ip: string, walletAddress: string): Promise<EligibilityResult> {
  const geoResult = await maxmindClient.country(ip);
  const country = geoResult.country.isoCode;
  
  if (BLOCKED_COUNTRIES.includes(country)) {
    return { allowed: false, reason: 'geo_blocked', country };
  }
  
  const ipRisk = await ipqualityscore.check(ip);
  if (ipRisk.vpn || ipRisk.proxy || ipRisk.tor) {
    return { allowed: false, reason: 'vpn_detected' };
  }
  
  return { allowed: true, country };
}

Списки заблокованих країн визначаються ліцензією: Кюрасао, Мальта, Естонія — кожна зі своїм списком restricted jurisdictions.

Чому необхідна відповідальна гра?

Ліцензовані казино зобов'язані реалізувати функції responsible gambling:

• self-exclusion (блокування від 1 дня до перманентного)
• deposit limits (денні/тижневі/місячні — зменшення миттєво, збільшення через cooling-off 24-72 години)
• reality check (сповіщення про час та втрати)
• cooling-off period (тимчасова пауза)

Ці заходи не лише відповідають вимогам регуляторів, але й знижують ризики негативного користувацького досвіду. Автоматизація відповідальної гри — обов'язковий елемент комплаєнсу.

Процес роботи

1. Аналітика: вивчення вимог ліцензії та вибір провайдерів.
2. Проектування: архітектура KYC/AML, схема потоків.
3. Інтеграція: підключення Sumsub, Chainalysis, MaxMind, Yoti.
4. Тестування: регрес та навантаження.
5. Деплой та навчання комплаєнс-команди.

Терміни

Повна комплаєнс-система — 6-10 тижнів. Економія на автоматизації досягає 60% порівняно з ручною верифікацією. Орієнтовна вартість системи — від $15,000. Вартість розраховується індивідуально залежно від набору провайдерів та складності інтеграції. Ми гарантуємо якість інтеграцій та надаємо сертифікати від провайдерів.

Що входить у роботу

• Архітектурна документація
• Інтеграція провайдерів (Sumsub, Chainalysis, Yoti, MaxMind)
• Написання смарт-контрактів (при необхідності)
• Навантажувальне тестування
• Навчання комплаєнс-команди
• Підтримка на запуску

Отримайте оцінку вашого проекту — зв'яжіться з нами. Ми допоможемо підібрати провайдерів та оптимізувати бюджет. Замовте розробку системи верифікації під ключ — обговоріть деталі з нашими інженерами.

Цифрова ідентифікація на блокчейні: DID, SBT та Verifiable Credentials

Ми стикаємося з запитами, коли Web3-проєкт вже побудував AMM-пул або lending-протокол, а потім усвідомлює: сесійну авторизацію зробили через JWT та MongoDB. Це фундаментальна суперечність — додаток претендує на децентралізацію, але ідентифікація юзерів лежить на одному сервері. Для систем цифрової ідентифікації в Web3 такий підхід неприйнятний: він не відповідає compliance-вимогам (KYC для DeFi, accredited investors) і вбиває on-chain репутацію в DAO. Ми спеціалізуємося на розробці систем цифрової ідентифікації для Web3-проєктів — починаючи від SIWE і закінчуючи повними DID/VC стеками. Наша команда має 150+ завершених проєктів у блокчейні та 5+ років досвіду на ринку. Ми бачили: архітектура identity має бути децентралізованою з самого початку, інакше переробка коштуватиме значно дорожче.

Як Sign-In with Ethereum вирішує проблему аутентифікації?

EIP-4361 SIWE — найпряміший шлях прибрати логін/пароль. Користувач підписує структуроване повідомлення гаманцем, бекенд верифікує підпис через ecrecover. Жодних витоків credentials.

Реалізація: бібліотека siwe (JS/TS) на фронтенді, SiweMessage.verify() на бекенді. Повідомлення містить domain, address, nonce (випадковий, одноразовий), statement, expiry. Nonce живе в Redis до верифікації — захист від replay attacks. Сьогодні SIWE використовують понад 80 проєктів з топ-100 DeFi.

Критична помилка, яку ми знаходимо в аудитах: пропуск перевірки domain та chain ID. Якщо бекенд не звіряє message.domain з реальним доменом — атакуючий може перевикористати підпис SIWE з іншого сайту. Ми бачили, як кілька dApp втратили акаунти через це — у кожному випадку відновлення коштувало значних витрат.

Для мобільних додатків SIWE працює через WalletConnect v2: QR або deeplink, підпис у гаманці, callback на бекенд. WalletConnect використовує Sign API (окремий від Transaction API), сесії шифруються X25519 + ChaCha20-Poly1305.

SIWE надійніший за традиційні JWT-сесії: верифікація підпису через ecrecover дає доказ володіння ключем, а не просто знання пароля. Витрати на управління сесіями знижуються на 40–60% — це в 1.5–2 рази менше ресурсів порівняно з JWT. Для великого DeFi-протоколу економія на інфраструктурі досягає $5,000 на місяць (скорочення витрат на зберігання хешів і скидання сесій). Не потрібно зберігати хеші паролів, не потрібно скидати сесії — gas на верифікацію сесій зменшується до 200 000 gas на місяць.

Чому цифрова ідентифікація має бути децентралізованою?

Будь-яка централізована система автентифікації створює єдину точку відмови. Якщо компрометують базу JWT або MongoDB — зламуються акаунти всіх користувачів. Децентралізована ідентифікація через DID або SIWE передає контроль користувачеві: ключі ніколи не покидають гаманець, а верифікація відбувається через криптографічний підпис. Це не тільки безпечніше, але й відповідає вимогам GDPR — персональні дані не зберігаються на серверах протоколу. Ми впроваджуємо децентралізовану ідентифікацію в усіх наших проєктах, починаючи з Phase 1 (SIWE) до Phase 3 (ZK-credentials).

Що таке DID і який метод обрати?

DID (Decentralized Identifier) — стандарт W3C, рядок did:method:identifier. Метод визначає, де зберігається DID Document і як він резолвиться. Основні методи, які ми використовуємо в продакшені:

Для більшості DeFi-проєктів достатньо did:ethr або did:key. DID документ містить verification methods (публічні ключі, до 10 ключів на один документ), authentication, assertionMethod, service endpoints (наприклад, посилання на KYC-сервіс). Ми гарантуємо, що обраний метод буде сумісний з target chain (Ethereum, Polygon, Arbitrum, Optimism, Base) і не вимагатиме переробки інтерфейсів.

Типові помилки при виборі DID-методу:

• Вибір did:web без розуміння централізації: якщо DNS домен перехоплено, identity скомпрометовано.
• Ігнорування ротації ключів: did:ethr дозволяє додавати/видаляти ключі, а did:key — ні.
• Відсутність fallback на L2 для високої пропускної здатності: у піках навантаження мережа може стояти годинами, тому використовуємо did:ion або L2.

Як працює верифікація через Verifiable Credentials?

Verifiable Credential (VC) — підписане заявлення від issuer про subject. Формат W3C: JSON-LD або JWT. Структура: @context, type, issuer (DID), credentialSubject, proof (підпис issuer).

Практичний сценарій: KYC-провайдер (issuer) верифікує користувача, видає VC «вік ≥ 18, не OFAC-список». Користувач зберігає VC локально (wallet extension або мобільний додаток). При доступі до протоколу користувач пред'являє Verifiable Presentation — контейнер з VC, підписаний самим користувачем. Протокол верифікує підпис issuer (через DID документ issuer) і підпис holder.

Жодні персональні дані не потрапляють on-chain. Протокол не зберігає базу користувачів, що пройшли KYC. Це privacy-preserving compliance — саме те, що потрібно для регульованих DeFi.

Zero-knowledge proof для VC виводить приватність на новий рівень. Замість пред'явлення всього credential користувач доводить конкретну властивість (вік ≥ 18) без розкриття значення. Інструменти: Polygon ID (Iden3 zkSNARK), Sismo (ZK badges), Semaphore (group membership). Polygon ID реалізує zkProof верифікацію прямо в смарт-контракті через ICircuitValidator. Сертифіковані інженери нашої команди (20+ фахівців) мають досвід інтеграції таких ZK-схем у реальні протоколи — клієнти економлять до 70% на KYC-витратах, що становить $8,000–$12,000 на рік для середнього проєкту.

Стандарт W3C Verifiable Credentials: vc-data-model

Чому Soulbound Tokens не підходять для mass adoption?

SBT (EIP-5192, концепція Vitalik Buterin) — NFT, який не можна перевести. Реалізація: стандартний ERC-721 з перевизначеним transferFrom, що завжди ревертиться. Або ERC-5192 з locked().

Застосування в production:

• DAO Governance — Snapshot + SBT для голосування «одна людина — один голос». Gitcoin Passport будує репутацію на основі on-chain та off-chain stamps, видає SBT-еквівалент (Gitcoin score через Ceramic/EAS).
• Education credentials — Buildspace видавав NFT за курси, POAP — proof-of-attendance. SBT робить їх non-transferable — не можна купити чужу історію.
• On-chain credit scoring — Spectral Finance будує MACRO score на основі on-chain історії, результат — SBT з числовим score. Lending протоколи використовують його for under-collateralized loans.

Ethereum Attestation Service як стандарт identity layer

EAS розгорнуто на Ethereum mainnet, Optimism, Arbitrum, Base. Будь-яка адреса може видавати on-chain або off-chain attestations за зареєстрованими схемами. Схема — ABI-encoded структура. Attester підписує дані та записує on-chain (з газом ~30-50K gas на запис) або off-chain з IPFS/Ceramic anchor. Verifier читає через IEAS.getAttestation(uid).

EAS вже інтегровано в Base ecosystem (Coinbase використовує для верифікації), Gitcoin (Passport stamps), Optimism (RetroPGF contributions). Стає де-факто стандартом on-chain identity layer в L2. Наші розробники сертифіковані для роботи з EAS (досвід 5+ проєктів).

Процес роботи

1. Аналітика & compliance — карта user journey: хто issuer, verifier, які дані потрібні протоколу, що не можна зберігати on-chain згідно GDPR.
2. Проектування архітектури — вибір між on-chain SBT, EAS, DID/VC stack. Схема даних, ZK-циркуіт (якщо потрібен).
3. Реалізація — смарт-контракти (Solidity 0.8.x, Foundry/Hardhat), issuer service (Node.js/Go), holder wallet (ethers.js viem), verifier контракт.
4. Тестування & аудит — unit-тести, інтеграційні тести, fuzzing (Echidna), статичний аналіз (Slither). Залучення стороннього аудитора.
5. Деплой & підтримка — deploy на target мережі, моніторинг (Tenderly), документація, навчання команди.

Що входить у роботу (deliverables)

• Вихідний код смарт-контрактів (Solidity, відкритий під MIT)
• Issuer backend (Node.js/Go) з API для видачі VC/SBT
• Holder wallet integration (ethers.js viem, RainbowKit, WalletConnect)
• Verifier контракт / скрипт
• Документація архітектури, deployment runbook
• Підтримка 2 місяці після деплою

Орієнтири за термінами

Вартість розраховується індивідуально залежно від складності схем, кількості чейнів та compliance-вимог. Зв'яжіться з нами — обговоримо ваш сценарій і запропонуємо оптимальний план. Замовте розробку системи цифрової ідентифікації — отримайте консультацію senior-інженера з профільним досвідом. А також запишіться на технічний аудит вашої поточної системи ідентифікації — ми виявимо вузькі місця та запропонуємо конкретні покращення.