Специфікація інтеграції системи оплати криптовалютою
Щоб підвищити гнучкість платежів та глобальну доступність для користувачів, ми плануємо інтегрувати функціональність нативних платежів криптовалютою на нашому веб-сайті. Система повинна підтримувати прийом активів та моніторинг транзакцій через основні блокчейн-мережі, з прямими з'єднаннями з нативними RPC-вузлами кожного ланцюга (не сторонніми агрегаторами), забезпечуючи безпеку, контроль та відповідність децентралізованим принципам.
Цільові блокчейн-мережі
Потрібно підтримувати наступні блокчейни та їх відповідні нативні активи та стандарти токенів:
- Bitcoin (BTC): Нативні перекази Bitcoin
- Ethereum (ERC-20): Підтримка USDT, USDC та інших токенів ERC-20
- BNB Smart Chain (BEP-20): Підтримка BUSD, USDT-BSC та інших токенів BEP-20
- TRON (TRC-20): Підтримка USDT-TRC20 та інших токенів TRC-20
- Solana (SPL): Підтримка USDC, USDT та інших токенів стандарту SPL
- TON (The Open Network): Підтримка нативних монет TON та токенів стандарту Jetton
Основні функціональні вимоги
1. Генерація та управління адресами гаманців
- Динамічно генерувати унікальні адреси депозитів криптовалюти для кожного користувача (ізольовані гаманці або похідні адреси)
- Уніфікована система управління адресами для кількох ланцюгів
2. Моніторинг транзакцій у реальному часі та підтвердження
- Опитувати або підписуватися на дані блоків через нативні RPC-інтерфейси для кожного ланцюга
- Виявляти вхідні транзакції (як нативні перекази монет, так і токенів)
- Перевіряти легітимність транзакцій (наприклад, кількість підтверджень, сума, адреса отримувача)
3. Автоматизоване агрегування коштів (очищення холодного гаманця)
- Автоматично очищати кошти на основний/холодний гаманець, коли баланс користувача перевищує попередньо визначений поріг
- Обробляти комісії за газ/енергію під час очищення (з автоматичним поповненням, якщо необхідно)
- Підтримувати управління комісіями через ланцюги (наприклад, енергія/пропускна здатність на BSC/Tron)
4. Функціональність виведення
- Дозволити виведення з основного гаманця на зовнішні адреси як для нативних монет, так і для токенів
- Забезпечити відстеження статусу транзакцій та ведення журналу в базі даних
5. Безпека та контроль ризиків
- Приватні ключі повинні зберігатися офлайн; ніколи не підлягають розкриттю в коді програми або змінних середовища
- Використовувати MPC-гаманці, HSM або апаратні пристрої підписання для критичних операцій
- Реалізувати робочі процеси затвердження для великих виведень
6. Синхронізація даних та звірка
- Зберігати записи транзакцій в блокчейні в локальній базі даних
- Забезпечити API для запитів статусу транзакцій
- Підтримувати конверсію вартості у фіаті за допомогою API обмінного курсу
7. Архітектура високої доступності
- Інтегрувати черги повідомлень (наприклад, Redis + BullMQ) для асинхронної обробки та механізмів повторної спроби
Технічні вимоги до реалізації
- Підключитися безпосередньо до **публічних або самостійно розгорнутим повноцінним RPC** для кожного ланцюга. Уникати залежності від сторонніх шлюзів (наприклад, Alchemy, Infura, TronGrid), щоб забезпечити операційну автономію.
- Використовувати офіційно рекомендовані SDK для кожного ланцюга:
- Bitcoin**: `bitcoinjs-lib` + самостійно розгорнутий `bitcoind` вузол
- Ethereum/BSC: `ethers.js` або `web3.js`
- Tron: `tronweb`
- Solana: `@ solana/web3.js`
- TON: `ton`, `ton-core`
Майбутня розширюваність
- Спроектувати модульну архітектуру для легкого додавання нових блокчейнів (наприклад, Polygon, Avalanche)
- Забезпечити внутрішні адміністративні API для ручного очищення, перевірок балансу, затвердження виведень тощо.
Ця система буде служити основним компонентом нашої фінансової інфраструктури і повинна відповідати високим стандартам **безпеки, надійності та спостережуваності**, щоб забезпечити безпеку активів користувачів та безперервність бізнесу.
