Бэкенд крипто-необанка: балансы, скрининг и выплаты на одном ключе
Необанк с крипто-счетами обычно упирается не в продуктовую логику, а в интеграционный зоопарк: отдельный API для чтения балансов, отдельный вендор для скрининга адресов, отдельный рельс для выплат. Три договора, три ключа, три биллинга — и это до того, как вы напишете первую строчку бизнес-логики. Референсная сборка ниже показывает, как закрыть чтение балансов, KYT и mass payout по BTC/ETH/TRON через один API-ключ и один prepaid-баланс кредитов, на собственных архивных нодах.
Задача
Пользователь необанка держит USDT-TRC20, немного ETH и BTC на внутренних счетах. Чтобы показать ему единый портфель, провести пополнение и выпустить средства, продукту нужно: одним чтением собрать net-worth по трём сетям, проверить контрагента на on-ramp и off-ramp до зачисления, а затем не терять адрес из виду — мониторить осевшую активность. Классическая реализация тянет три интеграции с рассинхроном лимитов и биллинга: API балансов живёт по своим квотам, скрининговый вендор — по своим, payout-рельс — по третьим. Любой из них становится точкой отказа и искусственным потолком rps.
- Balances / portfolio / net-worthC2
- Address risk-score / exposureC3
- Transaction screening / KYTC3
- Mass payout / settlementC2
Единое чтение портфеля по трём сетям
Net-worth по счёту собирается одним запросом сразу по BTC, ETH и TRON, включая балансы токенов USDT/USDC. Ноды свои и архивные, поэтому историческое состояние адреса читается без ограничений реселлера и без искусственных лимитов rps — можно обновлять портфель ровно с той частотой, которую диктует UX кабинета, а не тариф стороннего RPC-провайдера.
Скрининг на границе ramp и постоянный KYT
На on-ramp и off-ramp адрес контрагента прогоняется через risk-score и sanctions-скрининг до того, как средства зачислены или выпущены — решение принимается на границе, а не постфактум. После зачисления тот же ключ включает KYT-мониторинг: осевшая на счёте активность отслеживается непрерывно, и подозрительное движение попадает в очередь на разбор, а не теряется между вендорами.
Массовые выплаты с того же баланса
Выплаты пользователям идут через mass payout: платформа собирает build/sign/broadcast, но подпись остаётся на стороне клиента — приватные ключи мы не держим. Балансы, скрининг и выплаты списываются с одного prepaid-баланса кредитов, поэтому казначейство видит единую стоимость операции, а не сумму трёх счетов от трёх поставщиков.
Что даёт сборка
- Вместо трёх договоров и трёх ключей — один API-ключ и один баланс кредитов на чтение балансов, KYT и выплаты.
- Скрининг срабатывает на границе on-ramp/off-ramp до движения средств, а KYT продолжает следить за счётом после зачисления.
- Собственные архивные ноды BTC/ETH/TRON снимают искусственные лимиты rps реселлера при частом обновлении портфеля.
Частые вопросы
Вы держите приватные ключи пользователей при выплатах?
Нет. Платформа готовит транзакцию (build) и отправляет её в сеть (broadcast), но подпись выполняется на вашей стороне — MPC или multisig по вашему выбору. Ключи к нам не попадают ни в каком виде.
Можно ли проверять адрес на входящем пополнении, а не только при выводе?
Да. Risk-score и sanctions-скрининг вызываются на on-ramp до зачисления, поэтому вы можете отклонить или отправить на ручной разбор рискованное пополнение ещё до того, как оно отразится на балансе пользователя.
Пополнили, получили ключ, запустили.
Полное самообслуживание. Оплата криптой или картой. Тарификация в кредитах — тяжёлые примитивы дороже, простые дёшевы.
Получить API-ключ