Жизненный цикл транзакции

Исходящая транзакция проходит путь от создания пользователем до финализации в блокчейне через несколько этапов: автоматические проверки, согласование, MPC-подписание и отправка в сеть. На каждом переходе платформа присваивает транзакции новый статус и отправляет webhook-событие — по ним ваше приложение может отслеживать процесс, ничего не опрашивая.

Схема

Этапы

1. Создание — консоль или API

Транзакцию создаёт пользователь в консоли или ваше приложение через POST /transaction (см. справочник API и quickstart). Платформа проверяет, что доступный баланс покрывает сумму и комиссию, и создаёт транзакцию в статусе pending; с этого момента средства удерживаются и не доступны для других операций до завершения.

Повторный запрос с тем же X-Idempotency-Key не создаёт дубликата — вернётся уже существующая транзакция, поэтому запросы можно безопасно ретраить.

2. AML-скрининг

Если к workspace подключён AML-провайдер, сумма и адреса транзакции проходят автоматическую проверку по настроенным AML-правилам. Высокий риск не отклоняет транзакцию, а замораживает её (frozen): оператор разбирает инцидент и либо снимает заморозку — обработка продолжается с того же места, — либо отклоняет транзакцию.

3. Проверка политиками

Политики workspace оценивают транзакцию по transfer-правилам: кто инициатор, откуда и куда идёт перевод, какой актив и сумма. Возможны три решения:

4. Сбор подтверждений (аппрувы)

Сколько и чьих подтверждений требуется, задаёт правило Approval — например, «2 из 3 финансистов и 1 из 2 руководителей». Каждый аппрувер подтверждает или отклоняет транзакцию со своего устройства; подтверждение подписывается ключом устройства.

• все требуемые наборы собраны → approved, обработка продолжается;
• хотя бы один аппрувер отклонил → declined;
• аппруверы не ответили за отведённое время → expired.

5. Подготовка и MPC-подписание

Платформа собирает «сырую» блокчейн-транзакцию: рассчитывает комиссию, резервирует необходимые входы (created → awaiting_confirmation) — и выдаёт задание на подпись подписанту.

Подписывает транзакцию устройство клиента — мобильное приложение Pert или Co-Signer (серверный автоподписант). Подпись выполняется по протоколу MPC: приватный ключ никогда не существует целиком, устройство и ноды платформы обмениваются криптографическими раундами и совместно формируют подпись из своих долей ключа.

Подписант может отклонить транзакцию (declined); если подпись не собрана до истечения срока действия транзакции — expired.

6. Отправка в блокчейн и финализация

Подписанная транзакция ставится в очередь на отправку (awaiting_broadcast) и уходит в сеть (broadcast). Дальше источник истины — блокчейн: платформа сверяет состояние транзакции с сетью и после достаточного числа подтверждений переводит её в finished. Если сеть отклонила транзакцию, она завершается как declined.

Что может приостановить или прервать поток

• Заморозка (frozen) — вручную оператором или автоматически по AML. Возможна только до подписания; разморозка возвращает транзакцию в прежний статус, и обработка продолжается.
• Отмена (canceled) — пользователь может отменить транзакцию через POST /transactions/{id}/cancel, пока подпись не собрана. Удержанные средства освобождаются автоматически.
• Ошибка подготовки (failed) — внутренняя ошибка на этапе подготовки блокчейн-транзакции. Средства освобождаются; транзакцию можно создать заново.

Депозиты

Входящие транзакции (deposit) не проходят проверку transfer-политиками, сбор аппрувов и подписание — платформа обнаруживает зачисление в сети и создаёт транзакцию сразу с итоговым статусом; как правило, первым событием по ней будет transaction.finished.

AML при этом применяется и к депозитам: если к workspace подключён AML-провайдер, входящее зачисление проходит скрининг, и рисковый депозит по правилам AML Post-Screening приводит к заморозке vault-получателя — входящие операции по нему блокируются до решения оператора.

Как отслеживать статус

• Webhooks — на каждый переход платформа отправляет событие transaction.<статус>; полный перечень — в типах событий. События не упорядочены между собой: полагайтесь на data.status, а не на порядок доставки.
• REST — текущее состояние и история переходов доступны через GET /api/v1/transactions/{id} (см. справочник API).

Справочник статусов