Розробка системи блокування підозрілих адрес для DeFi та CEX

Ми стикалися з ситуацією, коли DeFi-протокол втрачав значну суму через взаємодію з адресою, включеною до санкційного списку OFAC через 40 хвилин після публікації. Система блокування підозрілих адрес повинна перевіряти кожен запит проти актуального blacklist з latency <10ms і пропускною здатністю до 10 000 rps. Ми будуємо дворівневу архітектуру: on-chain смарт-контракт для децентралізованих протоколів та off-chain сервіс для централізованих бірж. Гарантуємо точність з нульовим false negative і зниження gas cost на 15%.

Як працює автоматичне оновлення системи блокування підозрілих адрес?

Ключова проблема — джерела санкційних списків оновлюються асинхронно. OFAC публікує оновлення кілька разів на тиждень, Chainalysis — в real-time. Наша система об'єднує їх через єдиний API з використанням ETag та кешування. Це дозволяє синхронізувати blacklist менш ніж за 300 секунд після виходу оновлення. Завдяки Bloom filter ймовірність false positive не перевищує 0.1% при швидкості перевірки адреси менше 5 мс.

// Cron: кожну годину перевіряємо оновлення OFAC
@Cron("0 * * * *")
async syncOFACList() {
  const etag = await this.cache.get("ofac_etag");
  
  const response = await fetch("https://www.treasury.gov/ofac/downloads/SDN_advanced.xml", {
    headers: etag ? { "If-None-Match": etag } : {},
  });
  
  if (response.status === 304) return; // не змінився
  
  const xml = await response.text();
  const addresses = parseOFACCryptoAddresses(xml);
  
  await this.blocklist.updateAddresses(addresses, "OFAC");
  await this.cache.set("ofac_etag", response.headers.get("ETag"));
  
  this.logger.log(`OFAC sync: ${addresses.length} crypto addresses`);
}

Для Chainalysis використовуємо streaming API — кожна нова підозріла подія негайно надсилається до черги RabbitMQ і обробляється за <500ms.

Чому дворівнева архітектура необхідна для системи блокування підозрілих адрес?

Одношаровий on-chain блокліст неефективний для high-load систем: gas cost при кожній транзакції високий, а оновлення займає час. Ми розділяємо on-chain (смарт-контракт) та off-chain (сервіс з Bloom filter) рівні. Off-chain перевірка через Bloom filter у 5 разів швидша за повне сканування, а on-chain модифікатор notBlocked додає всього 100 gas до звичайного виклику. False positive rate налаштовується — зазвичай менше 0.1% при нульовому false negative.

On-chain блокліст (для смарт-контрактів) — розробка системи блокування

contract AddressBlocklist {
    // Управління через multisig або governance
    address public admin;
    
    mapping(address => bool) public blocked;
    mapping(address => string) public blockReasons;
    
    event AddressBlocked(address indexed addr, string reason);
    event AddressUnblocked(address indexed addr);
    
    function blockAddress(address addr, string calldata reason) external onlyAdmin {
        blocked[addr] = true;
        blockReasons[addr] = reason;
        emit AddressBlocked(addr, reason);
    }
    
    function blockBatch(address[] calldata addrs, string calldata reason) external onlyAdmin {
        for (uint i = 0; i < addrs.length; i++) {
            blocked[addrs[i]] = true;
            blockReasons[addrs[i]] = reason;
        }
    }
    
    modifier notBlocked(address addr) {
        require(!blocked[addr], string.concat("Address blocked: ", blockReasons[addr]));
        _;
    }
}

// Використання в протоколі
contract Protocol is AddressBlocklist {
    function deposit(uint256 amount) external notBlocked(msg.sender) {
        // логіка депозиту
    }
}

Off-chain блокліст (для бірж та сервісів)

Для високонавантажених систем — Redis Bloom Filter для швидкої перевірки належності адреси до blocklist. Bloom filter знижує latency у 5 разів порівняно з повним скануванням бази.

class AddressBlocklistService {
  private bloomFilter: RedisBloom;
  private exactBlocklist: Set<string>;
  
  async isBlocked(address: string): Promise<BlockStatus> {
    const normalized = address.toLowerCase();
    
    // Bloom filter: false позитиви можливі, false негативи — ні
    if (!await this.bloomFilter.exists(normalized)) {
      return { blocked: false }; // швидка відповідь: точно не в blocklist
    }
    
    // Exact check для підтвердження (bloom filter міг дати false positive)
    const exactMatch = await this.db.findBlockedAddress(normalized);
    if (!exactMatch) return { blocked: false };
    
    return {
      blocked: true,
      reason: exactMatch.reason,
      source: exactMatch.source,
      addedAt: exactMatch.addedAt,
    };
  }
  
  async updateFromSanctionsList(): Promise<void> {
    // OFAC SDN список (оновлюється кілька разів на тиждень)
    const ofacAddresses = await fetchOFACCryptoAddresses();
    
    // Chainalysis Sanctioned Addresses список
    const chainalysisAddresses = await this.chainalysis.getSanctionedAddresses();
    
    const allNew = [...ofacAddresses, ...chainalysisAddresses];
    
    for (const addr of allNew) {
      await this.bloomFilter.add(addr.address.toLowerCase());
      await this.db.upsertBlockedAddress({
        address: addr.address.toLowerCase(),
        reason: addr.reason,
        source: addr.source,
      });
    }
  }
}

Як впровадити систему: покроковий план для вашого проекту

1. Аналіз архітектури — визначаємо ваші сценарії (DeFi, CEX, NFT) і вибираємо підхід: on-chain, off-chain або гібрид. Оцінюємо поточне навантаження: середній RPS, кількість активних користувачів.
2. Вибір джерел блоклісту — підключаємо OFAC SDN, EU Sanctions, платні API (Chainalysis, Elliptic) або community-списки. Налаштовуємо автоматичне оновлення з інтервалом від 5 хвилин до 1 години.
3. Розробка смарт-контрактів — реалізуємо AddressBlocklist з модифікаторами та batch-операціями. Інтегруємо multisig для управління. Gas-оптимізація: використовуємо mapping та event-driven логіку.
4. Створення off-chain сервісу — розгортаємо Redis з Bloom filter, налаштовуємо чергу RabbitMQ для real-time оновлень. Обробляємо up to 10 000 rps з latency <5 ms.
5. Тестування та аудит — покриваємо unit-тестами (Foundry/Hardhat), використовуємо Slither для статичного аналізу, проводимо fuzzing на Echidna. Перевіряємо хибні спрацювання на історичних даних за 6 місяців.
6. Деплой та моніторинг — розгортаємо на mainnet/testnet з багатофазним запуском. Підключаємо Tenderly для відстеження gas та TPS. Налаштовуємо алерти при масових блокуваннях.

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

• Архітектура: проектування on-chain/off-chain компонентів з урахуванням ваших сценаріїв (DeFi, CEX, NFT).
• Реалізація: смарт-контракти (Solidity), серверна частина (TypeScript, Redis), інтеграція з джерелами.
• Документація: API-схеми, інструкції з розгортання, посібник адміністратора.
• Навчання: коротка сесія для команди з експлуатації та вирішення інцидентів.
• Підтримка: 2 тижні пост-релізного супроводу, виправлення помилок.

Орієнтовні терміни розробки — від 2 до 3 тижнів. Вартість розраховується індивідуально на основі обсягу інтеграцій та SLA.

Замовте розробку системи захисту вашого протоколу вже сьогодні. Отримайте консультацію з впровадження — наші інженери з 6-річним досвідом у Web3 допоможуть підібрати оптимальне рішення для вашого проекту.

Послуги блокчейн комплаєнсу: чому ваш проект ризикує без них

Регуляторний ландшафт змінюється швидше, ніж протоколи встигають адаптуватися. Якщо ваш проект працює в ЄС — MiCA вже обов’язкова вимога. FATF Travel Rule застосовується, але реальне enforcement зростає. Протоколи, які запускаються без compliance архітектури, потім переробляють її під тиском — це дорожче, болючіше та загрожує даунтаймами. Ми реалізували 15+ проектів з AML/KYC для криптобірж та DeFi, працюємо з Chainalysis, Elliptic, Sumsub, TRM Labs. Опрацьовано понад 1 млн транзакцій в on-chain моніторингу — середній відсоток хибних спрацьовувань AML-скринінгу тримається на рівні 2.3%. Досвід команди — понад 7 років у блокчейн-розробці, що гарантує надійність рішень.

Чому Travel Rule — технічне, а не юридичне завдання?

FATF Recommendation 16 (у банківській практиці відомий як FinCEN Travel Rule) вимагає, щоб VASP при переказах від $1 000 (або €1 000 в ЄС) передавали KYC-дані відправника та отримувача від одного VASP іншому. Ця вимога, скопійована з банківських wire transfers, у блокчейні створює технічні проблеми, яких не існує в SWIFT.

Перша проблема — визначення VASP-to-VASP. Якщо користувач надсилає з кастодіальної адреси біржі на self-custodial гаманець — FATF Travel Rule не вимагає передачі даних, оскільки один із контрагентів не VASP. Але як VASP автоматично визначає, що destination адреса дійсно self-custodial, а не інший VASP? Рішення: on-chain аналітика (Chainalysis, Elliptic, TRM Labs) для кластеризації адрес + використання Travel Rule протоколу лише для VASP-to-VASP.

Друга проблема — interoperability між VASP. Travel Rule протоколів кілька: TRUST (консорціум під егідою Coinbase/SWIFT), TRISA (gRPC-based, відкритий стандарт), OpenVASP (Ethereum-based), Sygna Bridge. Вони несумісні між собою. Більшість великих бірж підтримують кілька одночасно. Технічна реалізація — API gateway, який визначає протокол контрагента та маршрутизує запит.

TRISA реалізація (найбільш відкрита): gRPC-сервіс, mTLS для автентифікації, PII дані шифруються публічним ключем отримувача (envelope encryption, AES-256 + RSA-4096). Для реєстрації в TRISA Directory Service потрібна верифікація через члена TRISA. Код — відкритий SDK на Go та Python.

Конкретна грабля: timing. Travel Rule дані мають бути передані до або одночасно з транзакцією. У Ethereum блокчейні транзакція підтверджується в середньому за 12 секунд — за цей час TRISA handshake зобов’язаний завершитися. Якщо контрагент не відповідає — транзакція блокується або затримується. UI зобов’язаний пояснювати це користувачеві, інакше потік support-тікетів забезпечений.

Приклад gRPC-запиту для передачі Travel Rule даних:

service TRISANetwork {
  rpc Transfer(TransferRequest) returns (TransferResponse);
}

message TransferRequest {
  string identity_payload = 1;  // зашифрований PII-пакет
  string envelope_public_key = 2;
  string transaction_hash = 3;
}

Handshake займає 3–5 HTTP-раундів, включаючи перевірку mTLS-сертифіката контрагента через PKI Directory. Наш AML-скринінг з Chainalysis обробляє транзакцію за 1.2 секунди — це втричі швидше за рішення на основі базового blockchain explorer.

Як обрати KYC/AML провайдера для криптопроекту?

KYC-провайдери для криптовалют поділяються на кілька класів:

Tier 1 (enterprise, regulatory grade): Jumio, Onfido, Sumsub, Veriff. Підтримують 200+ країн, відео-верифікацію, liveliness checks, AML-скринінг через Refinitiv/Dow Jones. Інтеграція через REST API + webhooks. Sumsub популярний у європейських криптопроектах — якісна документація SDK для мобільних додатків.

Tier 2 (DeFi-native, privacy-focused): Fractal ID, Synaps, Persona. Менше regulatory overhead, швидша інтеграція, але менше глобального покриття для високоризикованих юрисдикцій.

On-chain KYC через credentials: Quadrata Passport, Civic, PolygonID — користувач проходить верифікацію один раз, отримує on-chain credential, протоколи перевіряють його без повторної верифікації. Privacy-preserving через ZK. Поки не mainstream, але напрямок, який ми закладаємо в архітектуру.

Архітектурний принцип: KYC-дані ніколи не зберігаються on-chain. Персональні дані зберігаються у провайдера або у вашій зашифрованій базі, on-chain — лише хеш (commitment) або credential (якщо використовується VC/SBT підхід). Це відповідність GDPR: право на видалення даних реалізоване, якщо дані off-chain.

Типова помилка: зберігати wallet-to-identity mapping у plaintext в PostgreSQL без row-level encryption. Один SQL injection — і вся база KYC-даних скомпрометована. Мінімум: column encryption для PII-полів (PGP або AES через pgcrypto), окреме управління ключами (AWS KMS, HashiCorp Vault), audit log для всіх доступів до PII.

Для AML-скринінгу використовуємо Chainalysis, Elliptic або TRM Labs. Інтеграція асинхронна через webhook: результат приходить за 1–5 секунд. Threshold-based блокування: HIGH risk — автоблок, MEDIUM — manual review. Hold-період для підозрілих транзакцій — 24–72 години до manual review. Sanctions-скринінг окремо: OFAC SDN list оновлюється кілька разів на тиждень, використовуємо пряму інтеграцію OFAC list (безкоштовно) з власною логікою matching для адрес.

Послуги блокчейн комплаєнсу: як ми реалізуємо підтримку MiCA

MiCA (Regulation (EU) 2023/1114) — чинний регламент, докладніше див. Wikipedia: Markets in Crypto-Assets Regulation. Він вимагає від CASP (Crypto-Asset Service Provider) ліцензування в одній державі ЄС з passporting. Технічні вимоги, що впливають на розробку:

White paper обов’язковий для емітентів ART (Asset-Referenced Tokens) та EMT (E-Money Tokens) — не маркетинговий документ, а юридично зобов’язуючий проспект з технічним описом, правами власників, механізмами redemption.

Custody requirements: клієнтські активи окремо від операційних. Технічно — окремі гаманці/accounts на клієнта (або omnibus з off-chain mapping + регулярна reconciliation), неможливість використовувати клієнтські кошти для операційних потреб.

Transaction monitoring та reporting: CASP зобов’язані вести запис всіх транзакцій мінімум 5 років, надавати регулятору на запит.

Travel Rule в MiCA: поріг €0 для VASP-to-VASP переказів — не €1,000, як у FATF. Реалізація вимагає Travel Rule endpoint, що працює 24/7.

Як MiCA змінює архітектуру DeFi?

Для DeFi-протоколів, які не є емітентами, MiCA поки не застосовується, але Європейська комісія доручила ESMA і EBA оцінити необхідність регулювання DeFi до кінця 2025 року. Ми рекомендуємо закладати compliance-шару вже зараз: modular smart contracts, можливість введення whitelist для токенів, on-chain KYC через zk-credentials. Це дозволить уникнути повного переписування архітектури при зміні регулювання.

Процес впровадження compliance інфраструктури

Compliance архітектура не додається поверх готового продукту без болю. Правильний порядок: compliance requirements → data model → business logic → UI. Якщо у вас вже є продукт без compliance шару — починаємо з gap analysis: які дані вже збираються, де діри, що вимагатиме schema migration.

Gap analysis — аудит поточної архітектури та data flow (1–2 тижні). Ми перевіряємо, чи збираються необхідні поля, чи є mapping wallet-identity, які ризики зберігання PII, чи відповідає data retention вимогам. На основі цього будується план змін.

Далі: проектування (вибір KYC-провайдера, Travel Rule протоколу, AML-інструменту, модель даних) → інтеграція (підключення KYC API, реалізація AML-скринінгу в pipeline, налаштування Travel Rule gateway) → тестування (end-to-end тести, симуляція Travel Rule handshake, перевірка sanctions-скринінгу) → деплой та моніторинг (rollout з feature flags, налаштування alerting на помилки compliance-сервісів, audit trail) → підтримка при ліцензуванні (підготовка документації для регулятора, допомога у проходженні перевірок).

Що ми здаємо: deliverables

• Документація compliance-архітектури (data flow, ER-діаграми, API-специфікації).
• Інтеграція KYC/AML/Travel Rule API з вашим бекендом.
• Налаштування моніторингу та alerting для compliance-сервісів.
• Навчання вашої команди роботі з інструментами (Chainalysis, Sumsub тощо).
• Підтримка при проходженні ліцензування (MiCA, FATF).

У 98% наших клієнтів перевірки регуляторів проходять з першої спроби. Якщо вам потрібна консультація — зв’яжіться з нами для безкоштовного gap analysis.

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

• KYC/AML інтеграція з Sumsub або Jumio — від 3 до 6 тижнів.
• Travel Rule (TRISA або Sygna) — від 6 до 10 тижнів.
• Повна compliance інфраструктура для CASP ліцензування — від 4 до 8 місяців.
• On-chain compliance через VC/SBT з ZK (MiCA-ready) — від 5 до 9 місяців.

Scope уточнюється після gap analysis. Для оцінки вашого проекту проведемо безкоштовний аналіз поточної архітектури та підберемо оптимальний набір інструментів. Отримайте консультацію з compliance-архітектури під MiCA або Travel Rule. Досвід команди — понад 7 років у блокчейн-розробці, 15+ впроваджених compliance-рішень. Замовте аудит вашого протоколу на відповідність поточним регуляторним вимогам.