Scheduled Transaction в Hedera: каких подписей не хватает и когда расписание истечёт

Не смешивайте две схемы. Native ScheduleInfo возвращает scheduledTransactionBody, primitive signers, execution_time либо deletion_time и scheduledTransactionID. Mirror REST называет близкие поля transaction_body, signatures, executed_timestamp и deleted, но его schedule endpoint не возвращает scheduled_transaction_id. Берите этот ID из receipt ScheduleCreate или native ScheduleInfo, а затем ищите Mirror transaction с фильтром scheduled=true.

Создание Schedule и исполнение тела — разные события

ScheduleCreate записывает расписание и возвращает schedule ID. Успех этой транзакции подтверждает создание объекта, а не перевод, token operation или contract call внутри него. Для запланированного тела сеть формирует отдельный scheduled transaction ID; именно по нему затем ищут record исполнения.

Сохраните schedule ID, scheduled transaction ID и transaction_body в одном расследовании. Если интерфейс показывает только «scheduled», этого недостаточно: из decoded body проверьте получателя, сумму, токен или contract call, а payer_account_id сверяйте отдельным полем ScheduleInfo.

ScheduleSign активирует ключи для неизменяемого body

После создания нельзя заменить тело внутри существующего Schedule. ScheduleSign ссылается на schedule ID, а сеть активирует соответствующие primitive keys для связанного с ним неизменяемого scheduled body. Перед подписью декодируйте body и сравните его с согласованным действием. При наличии admin key неверный Schedule можно удалить; без него отменить объект нельзя.

Список signatories не равен готовому счётчику недостающих подписей

Native ScheduleInfo возвращает активные primitive signers, а Mirror — наблюдённые signatures. ScheduleInfo может не включить подпись, которую сеть сочла маловероятно нужной. Ни один ответ не выдаёт готовый список недостающих требований: сопоставьте body с ключами аккаунтов, токенов, контрактов и других затронутых сущностей. Threshold key допускает разные комбинации, поэтому простой подсчёт даёт ложный ответ.

wait_for_expiry меняет момент попытки исполнения

При wait_for_expiry = false сеть передаёт scheduled transaction на исполнение, когда авторизация достаточна; успех самого действия всё равно определяет его record. При wait_for_expiry = true оценка откладывается до срока, а исполнение происходит в ближайшее доступное consensus time на best-effort основе. Throttling, доступность fee payer и проверки самой операции не позволяют обещать бизнес-результат в ту же секунду, когда появилась последняя подпись.

Executed timestamp открывает проверку, а не закрывает её

Найдите scheduled transaction по scheduled_transaction_id, запросив transaction endpoint с фильтром scheduled=true, и прочитайте consensus result. Требуйте result SUCCESS, затем проверьте наблюдаемый эффект тела: новый token balance, owner, allowance, contract event или другое ожидаемое состояние. Успешная ScheduleSign сообщает только о принятой подписи; она не заменяет record внутренней транзакции.

Если тело содержит token transfer, отдельно проверьте ассоциацию и требуемую подпись получателя. Общий разбор подписи помогает не подтвердить другое действие, а модель multisig полезна для организационных ролей — но Schedule остаётся отдельным on-chain объектом со своим lifecycle.

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