Утверждения выплат стейблкоинов и контроль казначейства

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

Рассмотрим регулярные платежи поставщику. Пользователь операций готовит запрос; инспектор казначейства проверяет бенефициара и источник финансирования; служба ограниченного исполнения передает авторизованную инструкцию; финансы согласовывают результат. Назначьте владельца исключений перед запуском. Для выплаты с неизвестным результатом нужен кто-то, кто сможет исследовать поставщика и собрать доказательства без создания второго платежа.

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

Разделите роли создателя и проверяющего. Документированный рабочий процесс подтверждения платежей Ripple, если он включен для учетной записи, не позволяет инициирующему пользователю утвердить свой собственный платеж. Используйте это как конкретный оценочный вопрос при выборе поставщика. Отдельно проверьте, может ли администратор изменять правила утверждения, кто санкционирует это изменение и какие события отображаются в журнале аудита.

В своем приложении сохраните отправленный запрос как новую неизменяемую версию. Привяжите каждое одобрение к каноническому отпечатку его пункта назначения, версии бенефициара, идентификатора актива, сети, целочисленной базовой единицы, счета финансирования, потолка сборов, версии полиса и срока действия. Явно определите каноническую сериализацию; хеширования произвольного JSON недостаточно. Перепроверьте отпечаток пальца непосредственно перед отправкой.

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

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

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

Тайм-аут сети после отправки означает, что результат неизвестен. Запросите поставщика, используя исходную ссылку, и проверьте последующие события, прежде чем решить, разрешена ли другая отправка. Не освобождайте резервирование и не создавайте новый ключ идемпотентности только потому, что HTTP-ответ был потерян.

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

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

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

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

Дедупликация Webhook и дедупликация выплат решают разные проблемы. Прежде чем принять событие, проверьте подпись на соответствие исходным байтам запроса. Сохраняйте идентификатор события поставщика в папке «Входящие» с ограничением уникальности, быстро подтверждайте и обрабатывайте надежно. Stripe документирует дублирующие поставки и ограничения на порядок доставки для своих веб-перехватчиков; используйте эти случаи неудач в своих собственных интеграционных тестах.

Сохраняйте историю событий только для добавления, а затем получайте информацию о текущем рабочем состоянии. Отложенный обратный вызов «обработки» не должен перемещать подтвержденный платеж назад. В случае противоречия или нераспознанного статуса поместите событие в карантин и запросите запись авторитетного поставщика. Ни успешное перенаправление в браузере, ни дублированный обратный вызов не должны создавать кредит в бухгалтерской книге.

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

Записывайте идентификаторы аутентифицированных субъектов, временные метки сервера и причину решения для каждого перехода. Защитите хранилище событий от несанкционированных изменений, ограничьте доступ к информации о бенефициаре и определите срок хранения с командой, ответственной за бизнес. Продолжайте подписывать материалы и секреты веб-перехватчиков за пределами этих записей. Экспортируйте достаточно контекста, чтобы восстановить решение, не требуя доступа к активной системе подписи.

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

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

Создайте очередь исключений для несовпадающих сумм, отложенных обратных вызовов, возвращенных банковских выплат и реорганизаций цепочки. Правильный учет с отслеживаемыми компенсационными проводками вместо удаления истории. Владелец финансов должен быть в состоянии объяснить невыполненные оговорки и неразрешенные исключения в конце каждого отчетного периода.

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

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