Горячий кошелёк процессинга: где заканчивается каждая защита

У кастодиального процессинга есть ключ, способный двинуть ваш баланс. Ничего из написанного ниже этого не меняет.

Меняется другое: сколько существует способов собрать перевод, который этот ключ согласится подписать. Каждая защита закрывает один путь и оставляет открытыми другие. Названная вместе со своим пределом, она стоит дороже той, что названа без него. Предел — это место, куда придётся поставить человека.

Почему ключ вообще держат в сети?

Потому что вывод приходит в три часа ночи, а собрать, подписать и отправить перевод надо всё равно.

Холодное хранение — это отсутствие такой возможности: ключ, которому нужен человек рядом, на запрос вывода не ответит. Кто выплачивает по требованию, тот держит горячий кошелёк, как бы он его ни называл.

Значит, интересный вопрос никогда не звучал как «в сети ли ключ». Он звучит так: что запрос обязан пережить до того, как ключ его увидит.

Почему самая крупная кража обошлась без сломанного ключа?

Её подписали ровно те люди, которые и должны были её подписать.

21 февраля 2025 года или около того из Bybit ушло примерно 1,5 млрд долларов в виртуальных активах, а через пять дней ФБР назвало исполнителем КНДР.

Спустя неделю после кражи Safe Ecosystem Foundation описала маршрут в собственном заявлении: атака на кошелёк Bybit «была проведена через скомпрометированную машину разработчика Safe{Wallet}», и это вылилось в «предложение замаскированной вредоносной транзакции».

Одобрили её несколько человек. Мультиподпись отработала как задумано, только на неверной транзакции, и число подписей переменной тут не было. Вот проверка, которую стоит прикладывать ко всему ниже: что делает эта защита, когда запрос уже выглядит законным?

От чего изолируют подпись?

Подписывающую сторону — от поверхностей, до которых дотягивается мерчант или плательщик.

Исходящие транзакции Paymos подписываются в стороне от публичного веб-пути, а вывод может назвать только адрес, заранее одобренный мерчантом.

Изоляция — свойство достижимости. Она укорачивает список того, что способно положить запрос перед ключом; работа настоящая и меньшая, чем звучит, потому что против запроса, пришедшего через парадный вход с верной подписью, она не делает ничего.

Право подписи она при этом не делит, и читать её так не нужно. Это управляемое хранение: мерчант распоряжается, поставщик держит подпись и отправку, а подходит ли такой размен конкретному бизнесу — вопрос модели хранения, который решают до того, как начинают читать про защиты.

У казначея следующий вопрос короткий, и ответ на него тоже: баланс в Paymos не отдают в долг и не заставляют ничего зарабатывать, пока он лежит.

Какой из двух ключей двигает деньги?

Ровно один, и разделение тут не описано, а проверяется на каждом запросе.

У мерчанта на каждую среду два ключа: Payment и Payout.

Payment открывает счета и платёжные каналы. Payout — выводы и те чтения, которые выводу нужны, включая балансы. Один набор в другой не заходит, поэтому Payment-ключ, утёкший из плагина, из журнала или с ноутбука, вывода не создаст: прав на вывод у него нет.

Рядом стоят два условия. Payout-ключ обязан нести список разрешённых IP, и аутентификация отклоняет ключ с пустым списком, а не считает его неограниченным; Payment-ключ такого списка не несёт вовсе, потому что платёжный трафик и должен вызываться оттуда, где находятся ваши покупатели.

Отдельного ключа на сайт или на сервис завести не получится: по одному активному ключу каждого типа на среду, всего четыре, и отзыв необратим.

Это строчка для плана реагирования, а не для буклета: утечку не локализовать отзывом той интеграции, которая её допустила, потому что в этой среде тот же самый ключ и у всех остальных.

Что ограничивает белый список адресов?

Направление. Не сумму, не того, кто попросил, и не то, ваш ли ещё этот адрес.

Механику видно целиком:

• Пока в списке пусто, не уходит ничего. Пустой список читают не как отсутствие ограничений, а как выключенные выводы.
• Запись заведена по паре из адреса и группы сетей. Один одобренный адрес EVM разом закрывает Ethereum, BSC, Polygon, Arbitrum, Optimism, Base, Avalanche и Plasma; Tron, TON и Solana — отдельные группы.
• Групп всего четыре, и поэтому NEAR и Sui принимают платежи, а точками выхода не работают.
• Удаление записи — отзыв: строка остаётся, и след того, кому можно было платить и когда, не рвётся.
• В одном одобрении помещается до тысячи адресов, столько же строк берёт файл CSV, а активных записей у аккаунта не больше пяти тысяч.
• Маршрута в API у списка нет. Список живёт в дашборде, и Payout-ключ читает его, чтобы проверить адрес назначения, но добавить в него не может.

На последней строке стоит остановиться. Ключ, который двигает деньги, не может расширить набор мест, куда их двигают, и разделение переживёт ошибку в настройках — потому что маршрута в API для этого никогда не строили.

Теперь пределы. Белый список говорит о направлении и молчит о принадлежности: мерчант вправе намеренно одобрить адрес клиента или игрока и платить на него — так тут и устроен вывод в пользу конечного получателя.

Адрес, одобренный в марте для кошелька уходящего подрядчика, в сентябре остаётся одобренным адресом.

О размере он молчит тоже. Размер стерегут два лимита аккаунта: потолок на один вывод и число выводов, которым разрешено идти одновременно. Остаток мест форма показывает до того, как в неё что-то ввели, — отказом после он не приезжает.

Эти два ограничивают движение; список ограничивает направление. Вывод спокойно укладывается в оба и всё равно уходит туда, куда вы сегодня утром не выбрали бы.

Кто может добавить адрес назначения?

Меньше людей, чем может отправить туда деньги, и сделано это нарочно.

Список по умолчанию меняет только владелец аккаунта. Пользователь с ролью Finance отправляет выводы на адреса, одобренные владельцем, и одобрить новый не может; у роли Admin права на вывод по умолчанию нет вовсе.

Глоссарий NIST излагает принцип фразой про зарплату: ни у кого не должно быть прав, которых хватит, чтобы злоупотребить системой в одиночку, и человек, утверждающий выплату, не должен быть тем, кто её готовит.

Роли — стартовая позиция, и отдельным участникам можно выдать дополнительные права.

Разделение держится ровно до того дня, когда кто-то выдал их и забыл, так что экран прав — часть этой защиты.

Второй слой в этот момент — подтверждение вторым фактором, и оно не безусловно. Пользователя мерчанта без TOTP и без passkey не спрашивают: подтверждение усиливает существующий фактор и не может потребовать того, которого нет.

Считать его имеющейся у аккаунта защитой не стоит. Держит в любом случае сам список: вывод может назвать только адрес из него, добавление — отдельное записанное действие, а пустой список означает, что выводов нет.

Там, где подтверждение всё-таки срабатывает, оно привязано к одобряемому действию и тратится на нём, а не остаётся открытым на аккаунте.

Заметьте, где оно стоит. У вывода подтверждения нет; у изменения списка — есть. Охраняют дверь, а не каждый выход через неё, и в этом весь смысл держать список коротким.

Что останавливает уже запущенный вывод?

С каждым шагом всё меньше, и форму этого лучше знать заранее.

Отмена — окно в начале, а не отзыв. Вывод отменяют, пока он ещё в состоянии created и исполнение не началось; повторная отмена уже отменённого отвечает 200 и не делает ничего.

Дальше перевод принадлежит сети, и выясняется, что между запросом и необратимой транзакцией стоял только белый список.

Заморозки работают выше отдельного вывода. Есть общая заморозка исходящих и заморозка на пару из актива и сети, и вторая умеет подниматься сама: когда учёт и кошелёк расходятся больше допуска, пара останавливается, не дожидаясь, пока кто-нибудь это заметит.

Предохранитель и ведёт себя как предохранитель: расхождение в учёте останавливает ровно то, о чём расхождение, ещё до того, как кто-то разберётся, какая сторона неправа.

Отдельно маршрут одного актива в одной сети бывает какое-то время недоступен. Его отклоняют на входе, а не ставят в очередь: пары нет в выборе, запрос с ней отклоняют при создании, баланс не трогают.

Отказы здесь дёшевы по устройству. Создание вывода уводит сумму вместе с сетевой комиссией в удержание, а вывод, закончившийся, не уйдя в сеть, возвращает удержание целиком, вместе с комиссией.

Дёшев и повтор: external_order_id уникален в пределах мерчанта, и повторное создание вернёт существующий вывод вместо второй отправки. Это закрывает расчётную задачу, упавшую на середине, и ничего не говорит про запрос, который действительно другой.

Почему по неудавшемуся выводу так мало сказано?

Альтернатива этому — сырая внутренняя строка на экране мерчанта.

Причину отказа мерчанту не показывают. Показывают то, что выведено из состояния, а состояний закрытый набор: вывод не ушёл, удержание снято, вот куда написать.

За этим полем лежит сырой текст исключений, внутренние цифры и заметки операторов. Закрытое состояние в точке отображения, никогда не строка из глубины — вот и весь приём.

Цена ложится на мерчанта. Вывод, который не ушёл, не отправляет письма и ничего не кладёт в колокольчик, так что о неудаче узнаете из вебхука — или не узнаете вовсе.

На вопрос, сколько потом идёт сам вывод, отвечает соседняя статья.

Что спросить у кастодиального поставщика?

Начните с баланса, который лежит без дела, потом переходите к людям.

Отдают ли его в долг, размещают ли, зарабатывает ли он что-нибудь поставщику, пока лежит. Дальше: какая роль одобряет адрес назначения, может ли та же роль отправить туда деньги и что делает подтверждение при изменении списка на аккаунте, где второй фактор никто не включил. Хороший ответ называет роль и подтверждение, а не отдел. Последним спросите, что вам скажут, когда вывод не уйдёт, и по какому каналу: тот, кто отвечает «мы пишем вам на каждом шаге», либо построил то, чего не построили мы, либо не читал собственный код уведомлений.

Одна защита несёт больше остальных, и это список одобренных адресов. Работает он ровно настолько, насколько он короткий, а беречь стоит момент, когда он меняется. Поэтому в Paymos это действие по умолчанию закреплено за владельцем аккаунта, записывается, не имеет маршрута в API и единственное из всех просит второй фактор — тогда как сам вывод, который оно потом разрешает, не просит ничего.