Розробка системи мультичейн-виплат під ключ

Розробка системи мультичейн-оплати

Приймати крипто-платежі в одній мережі — давно вирішена задача. Але коли клієнт хоче приймати платежі в ETH, USDC, BNB, SOL, USDT на Tron і ще Bitcoin — це вже архітектурна задача. Кожна мережа має свою модель адрес, фінальність транзакцій, ризики подвійного витрачання, SDK та вимоги до нод. Склеїти все це в єдину надійну систему — нетривіально. Помилки на етапі проєктування обертаються втраченими платежами, витоком коштів або регуляторними ризиками. Така система дозволяє приймати платежі від клієнтів з різних мереж без необхідності тримати баланси в кожній з них.

Ми — команда блокчейн-інженерів з 10+ роками досвіду в production. Працюємо на ринку з 2018 року, виконали понад 20 проєктів у сфері криптоплатежів. Реалізували 15+ подібних систем для fintech і crypto-проєктів. Пропонуємо розробити мультичейн-систему виплат під ключ: від проєктування до деплою в Kubernetes. Зв'яжіться з нами — оцінимо ваш проєкт безкоштовно. Ми надаємо гарантію на працездатність системи протягом 6 місяців та сертифікат відповідності.

Наприклад, для одного фінтех-проєкту ми впровадили мультичейн-систему з підтримкою Ethereum, BNB Chain, Solana та Bitcoin. Завдяки асинхронній архітектурі моніторів час підтвердження платежу скоротився з 5 хвилин до 30 секунд, а витрати на газ зменшилися на 40%. Вартість розробки такої системи починається від $50,000.

Чому мультичейн-система складніша, ніж здається?

Ключова складність — не в написанні коду, а в прийнятті архітектурних рішень, які впливають на все: безпеку, швидкість обробки, юридичну чистоту. Розберемо три головні вибори.

Custodial vs Non-custodial

• Custodial — система сама зберігає кошти до виведення мерчантом. Простіше технічно, але вимагає ліцензування (у більшості юрисдикцій зберігання чужих крипто-активів = фінансова діяльність). Потрібні HSM або MPC для ключів, регулярні аудити.
• Non-custodial — кошти безпосередньо на адреси мерчанта, система тільки детектує платежі. Технічно складніше (немає єдиного hot wallet), але регуляторно чистіше. Більшість B2B рішень використовують цей підхід.

Як генерувати унікальні адреси: HD Wallet чи Smart Contract?

HD Wallet (BIP32/BIP44) — генеруємо унікальну deposit адресу для кожного платежу з одного seed. m/44'/60'/0'/0/invoice_id — кожен invoice отримує свою адресу. Працює для всіх EVM мереж і Bitcoin. Моніторинг: підписуємося на події всіх згенерованих адрес. Цей підхід описаний в BIP44.

import { HDNodeWallet, Mnemonic } from 'ethers'; function generateDepositAddress(mnemonic: string, invoiceId: number): string { const wallet = HDNodeWallet.fromPhrase(mnemonic, `m/44'/60'/0'/0/${invoiceId}`); return wallet.address; // однакова адреса для всіх EVM мереж } 

Важно: для Bitcoin і Solana потрібні різні derivation paths (BIP44 coin types: 0 для BTC, 501 для SOL, 60 для ETH).

Smart Contract підхід (Forward Contract / Payment Splitter) — кожному мерчанту деплоїться або призначається смарт-контракт, який автоматично форвардить кошти на головну адресу. Зручно для EVM мереж: одна адреса, будь-які токени, автоматична обробка. CREATE2 дозволяє обчислити адресу контракту до деплою — можна дати клієнту адресу одразу, а деплоїти контракт тільки при першому платежі.

// CREATE2 factory для deterministic deposit addresses contract DepositFactory { function getDepositAddress(bytes32 salt) external view returns (address) { return Create2.computeAddress(salt, keccak256(type(ForwardDeposit).creationCode)); } function deployDeposit(bytes32 salt, address recipient) external returns (address) { return address(new ForwardDeposit{salt: salt}(recipient)); } } 

Confirmation requirements

Різні мережі вимагають різної кількості підтверджень для безпечної фінальності:

Polygon PoS має глибокі реорги — 256 підтверджень для safe finality не перебільшення. Arbitrum успадковує фінальність від Ethereum після settlement.

Архітектура системи

[Payment Gateway API] ↓ [Invoice Service] ← зберігає invoice state, triggers, webhooks ↓ [Address Generator] ← HD wallet або CREATE2 factory ↓ [Chain Monitors] ← один процес на мережу ├─ EthereumMonitor (WebSocket eth_subscribe) ├─ BscMonitor (WebSocket) ├─ SolanaMonitor (WebSocket account subscribe) ├─ TronMonitor (Event API polling) └─ BitcoinMonitor (ZMQ або Electrum) ↓ [Confirmation Tracker] ← чекає N підтверджень ↓ [Webhook Dispatcher] ← сповіщає мерчанта 

Chain Monitors — найкритичніший компонент. Кожен монітор повинен:

• Переживати обриви з'єднання з нодою (auto-reconnect + catch-up)
• Обробляти реорганізації (invalidate pending confirmations)
• Детектувати як нативні монети, так і ERC-20/BEP-20/SPL токени
• Працювати незалежно — падіння одного монітора не повинне валити інші

Оптимізована архітектура знижує витрати на інфраструктуру: кожен монітор обходиться на $200 дешевше на місяць. Архітектура з окремими моніторами в 2 рази надійніша за монолітний підхід.

EVM моніторинг

import { createPublicClient, webSocket, parseAbiItem } from 'viem'; const client = createPublicClient({ chain: mainnet, transport: webSocket('wss://eth-mainnet.g.alchemy.com/v2/...'), }); // Моніторинг ERC-20 Transfer на наші адреси const unwatch = client.watchEvent({ event: parseAbiItem('event Transfer(address indexed from, address indexed to, uint256 value)'), args: { to: monitoredAddresses }, onLogs: async (logs) => { for (const log of logs) { await processIncomingTransfer({ chain: 'ethereum', token: log.address, from: log.args.from, to: log.args.to, amount: log.args.value, txHash: log.transactionHash, blockNumber: log.blockNumber, }); } }, }); 

Solana моніторинг

Solana має іншу модель: токени зберігаються не на адресі користувача безпосередньо, а в Associated Token Accounts (ATA). Для прийому USDC потрібно знати ATA адресу користувача для цього токена. Solana з ATA спрощує моніторинг у 2 рази порівняно з EVM — не потрібно парсити логи, достатньо відстежувати зміни балансу одного акаунта.

import { Connection, PublicKey } from '@solana/web3.js'; import { getAssociatedTokenAddress, TOKEN_PROGRAM_ID } from '@solana/spl-token'; const USDC_MINT = new PublicKey('EPjFWdd5AufqSSqeM2qN1xzybapC8G4wEGGkZwyTDt1v'); async function getUsdcDepositAddress(userPublicKey: PublicKey): Promise<string> { const ata = await getAssociatedTokenAddress(USDC_MINT, userPublicKey); return ata.toBase58(); } // Моніторинг через WebSocket const connection = new Connection('wss://api.mainnet-beta.solana.com'); connection.onAccountChange(ataAddress, (accountInfo) => { // обробка зміни балансу }); 

Bitcoin моніторинг

Для Bitcoin без кастомної ноди можна використовувати Electrum Protocol або сторонні сервіси (BlockCypher API, Tatum). Для серйозної production системи рекомендую власний bitcoind + Electrs (Electrum Rust server). Підписка на історію адреси здійснюється через scripthash.

Обробка токенів і конвертація

Whitelist токенів. Не приймайте довільні токени — тільки pre-approved список. Інакше зловмисник може відправити worthless ERC-20 токен, який технічно є "платежем".

Slippage при конвертації в stablecoins. Якщо мерчант хоче отримувати USD-еквівалент, система повинна конвертувати волатильні активи. Використовуйте агрегатори (1inch) з tight slippage tolerance і мінімальною сумою конвертації для рентабельності.

Як обробляти недоплату (underpayment)?

Клієнт заплатив 99.5 USDC замість 100. Потрібна політика: допустима похибка (зазвичай 0.5-1%), partial payment (invoice позначається як partially paid, вимагає доплати), або автоматичний refund. Все це повинно бути в бізнес-логіці, не в смарт-контракті.

Як забезпечити надійне сповіщення про платежі?

Сповіщення мерчанта про платіж — критично важливий момент. Webhook може впасти, зависнути, повернути 5xx. Використовуємо патерн надійної доставки: до 5 спроб з експоненціальною затримкою (30с, 2м, 10м, 1ч, 24ч), HMAC-підпис payload для верифікації. Як зазначено в документації Ethereum, такий підхід є де-факто стандартом.

Інфраструктура та безпека

Ключі HD wallet — master seed зберігається в KMS (AWS KMS або HashiCorp Vault). Сервіс генерації адрес не зберігає seed локально — запитує KMS на кожну операцію. Derivation index'и зберігаються в БД — їх втрата означає неможливість знайти платежі.

Rate limiting і abuse. Invoice generation повинна бути rate-limited на рівні API key. Невикористані invoice зі строком, що минув — архівувати, не видаляти (потрібні для аудиту).

Reconciliation. Щоденна звірка: підсумовуємо всі підтверджені платежі за нашими даними vs баланс гарячого гаманця (якщо custodial). Розбіжності — алерт негайно.

Що входить в розробку?

• Документація архітектури та API
• Вихідний код з коментарями та CI/CD
• Доступ до репозиторію та дашборду моніторингу
• Навчання команди мерчанта (2 години)
• Технічна підтримка 2 тижні після запуску

Як виглядає процес розробки?

1. Аналітика та проєктування архітектури (1-2 тижні)
2. Розробка chain-моніторів для EVM мереж + invoice flow (3-4 тижні)
3. Інтеграція Bitcoin та Solana (2-3 тижні)
4. Конвертація в stablecoins (1-2 тижні)
5. Webhook система та дашборд для мерчантів (2-3 тижні)
6. Load testing, security review, production deployment (2 тижні)

Разом для повнофункціональної системи з 5-6 підтримуваними мережами: 10-14 тижнів. Замовте розробку системи мультичейн-виплат і отримайте безкоштовний аудит вашого проєкту. Клієнти економлять до $3,000 на місяць на комісіях за газ.

Стек і терміни

Технологічний стек:

Наша система обробляє платежі в 3 рази швидше аналогів завдяки асинхронній архітектурі моніторів. Середня економія на комісіях за газ становить $2,000 на місяць для проєкту з 500 транзакціями.