Sequence и TicketSequence отвечают за разные режимы
РежимSequenceTicketSequenceЧто меняется после validated result
Обычная транзакцияТекущий номер аккаунтаОтсутствуетAccountRoot.Sequence продвигается
Ticketed transaction0Номер существующего TicketTicket object удаляется; обычный Sequence не расходуется
Оба поля ненулевыеНенулевойУказанMalformed: такой payload нельзя включить
Sequence и TicketSequence отвечают за разные режимы
Режим
Обычная транзакция
Sequence
Текущий номер аккаунта
TicketSequence
Отсутствует
Что меняется после validated result
AccountRoot.Sequence продвигается
Режим
Ticketed transaction
Sequence
0
TicketSequence
Номер существующего Ticket
Что меняется после validated result
Ticket object удаляется; обычный Sequence не расходуется
Режим
Оба поля ненулевые
Sequence
Ненулевой
TicketSequence
Указан
Что меняется после validated result
Malformed: такой payload нельзя включить

Перед подписью безопаснее найти Ticket в validated ledger

TicketCreate резервирует будущие account sequence numbers и создаёт отдельные Ticket ledger objects. Их можно использовать в любом порядке, по одному на транзакцию. Проверяйте account_objects с type ticket на validated ledger и полный Account: Ticket другого аккаунта или уже удалённый object не подходит.

TicketSequence не заменяет назначение операции: Payment, AccountSet, EscrowFinish и другие типы сохраняют собственные поля и ошибки. В escrow TicketSequence может участвовать в идентификации созданного объекта, но здесь задача уже — доказать судьбу самого Ticket и transaction result.

Корректный ticketed payload содержит Sequence 0

Что сохранить перед submit

  1. 1
    Снимок Ticket

    Сохраните Account, TicketSequence, индекс validated ledger и сам Ticket object до использования.

  2. 2
    Точный payload

    Проверьте TransactionType, Account, Sequence=0, TicketSequence, Fee и все поля действия. Ненулевой Sequence вместе с TicketSequence даёт temSEQ_AND_TICKET.

  3. 3
    Граница действия

    Для автоматической отправки задайте LastLedgerSequence. Сохраните его вместе с signed blob и transaction hash до broadcast.

  4. 4
    Контекст операции

    Сверьте получателя, asset, amount, flags и authorization conditions. Ticket не исправляет DepositAuth, trust line или partial-payment ошибки.

DepositAuth способен отклонить входящий платёж независимо от очереди, а delivered_amount нужен для проверки фактически доставленной суммы partial payment. Ticket подставляется вместо account Sequence для уникальности и позволяет отправлять операции вне обычного порядка Sequence; место в очереди xrpld он не резервирует.

Отправка вне обычного порядка Sequence не означает отправку вне consensus или server queue. Если submit вернул terQUEUED, в очереди находится кандидат, а не сам Ticket, и результат остаётся предварительным. terPRE_TICKET означает, что указанного Ticket сейчас нет, но он ещё может быть создан другой транзакцией; tefNO_TICKET — что номер уже ниже текущего Sequence и такой Ticket позже не появится. Ни один из этих ответов не заменяет проверку hash и validated ledger.

Submit возвращает предварительный ответ, ledger — окончательный

engine_result от submit относится к предварительному применению на открытом ledger и может измениться. Опросите transaction hash до validated:true. Если запись появилась, прочитайте meta.TransactionResult и ledger index; только после этого повторно запросите Ticket object.

Result class и судьба Ticket
НаблюдениеTicketВывод
validated:true + tesSUCCESSИзрасходованОперация применена; проверить ожидаемое state change
validated:true + tec...ИзрасходованОперация не достигла цели, fee списана
tem malformedНе израсходован этим payloadИсправить поля и заново подписать
terQUEUED в submitНе доказаноКандидат помещён в очередь; результат предварительный
terPRE_TICKET или tefNO_TICKETНе доказаноСверить точный код, Account.Sequence и validated Ticket objects
Другой tel, ter или tef в submitНе доказаноОтвет может быть предварительным или локальным; проверить hash и срок
txnNotFound до LastLedgerSequenceНе доказаноТранзакция ещё может попасть в допустимый ledger
Не найдена после LastLedgerSequence при непрерывной historyНе израсходован этой транзакциейДополнительно проверить наличие Ticket и другие tx
Result class и судьба Ticket
Наблюдение
validated:true + tesSUCCESS
Ticket
Израсходован
Вывод
Операция применена; проверить ожидаемое state change
Наблюдение
validated:true + tec...
Ticket
Израсходован
Вывод
Операция не достигла цели, fee списана
Наблюдение
tem malformed
Ticket
Не израсходован этим payload
Вывод
Исправить поля и заново подписать
Наблюдение
terQUEUED в submit
Ticket
Не доказано
Вывод
Кандидат помещён в очередь; результат предварительный
Наблюдение
terPRE_TICKET или tefNO_TICKET
Ticket
Не доказано
Вывод
Сверить точный код, Account.Sequence и validated Ticket objects
Наблюдение
Другой tel, ter или tef в submit
Ticket
Не доказано
Вывод
Ответ может быть предварительным или локальным; проверить hash и срок
Наблюдение
txnNotFound до LastLedgerSequence
Ticket
Не доказано
Вывод
Транзакция ещё может попасть в допустимый ledger
Наблюдение
Не найдена после LastLedgerSequence при непрерывной history
Ticket
Не израсходован этой транзакцией
Вывод
Дополнительно проверить наличие Ticket и другие tx

Общая проверка криптоперевода помогает связать hash, сеть и recipient, но в XRPL добавьте validated flag, LastLedgerSequence и meta.TransactionResult. Баланс или красная метка интерфейса не заменяют эту связку.

Перед retry докажите и expiry, и состояние Ticket

Если transaction не найдена, дождитесь, пока validated ledger пройдёт LastLedgerSequence. Сервер должен иметь непрерывную историю за весь допустимый диапазон; иначе txnNotFound не финален. Затем проверьте account_objects. Ticket всё ещё существует — можно строить новый payload с этим Ticket; Ticket исчез — найдите validated transaction, которая его израсходовала.

Официальный tutorial допускает убрать LastLedgerSequence у Ticket-транзакции, которую долго собирают для multisigning. Это компромисс: payload не истечёт во время сбора подписей, но простого ledger-boundary для окончательного «не была включена» не будет. Для автоматической отправки безопаснее подписывать свежий bounded payload ближе к submit.

Стоп-сигналы перед повтором

  • смотрят open ledger, но называют результат validated;
  • terQUEUED называют успешным расходом Ticket;
  • Ticket исчез, а transaction metadata не найдена;
  • validated tec трактуют как свободный Ticket;
  • LastLedgerSequence прошёл, но у сервера есть пробел в истории;
  • в новом payload меняют действие вместе с очередью и не проводят повторную проверку.

Источники

Мы используем прямые ссылки и фиксируем дату проверки. Полный текст чужих материалов не перепечатывается.

  1. XRPL Docs — Tickets XRP Ledger Foundation · Проверено 30 августа 2026 г. в 15:40 GMT+5
  2. XRPL Docs — Use Tickets XRP Ledger Foundation · Проверено 30 августа 2026 г. в 15:40 GMT+5
  3. XRPL Docs — Reliable Transaction Submission XRP Ledger Foundation · Проверено 30 августа 2026 г. в 15:40 GMT+5
  4. XRPL Docs — Finality of Results XRP Ledger Foundation · Проверено 30 августа 2026 г. в 15:40 GMT+5
  5. XRPL Docs — Basic Data Types XRP Ledger Foundation · Проверено 30 августа 2026 г. в 15:40 GMT+5
  6. XRPL Docs — tem Codes XRP Ledger Foundation · Проверено 30 августа 2026 г. в 15:40 GMT+5
  7. XRPL Docs — Transaction Queue XRP Ledger Foundation · Проверено 30 августа 2026 г. в 15:40 GMT+5
  8. XRPL Docs — ter Codes XRP Ledger Foundation · Проверено 30 августа 2026 г. в 15:40 GMT+5
  9. XRPL Docs — tef Codes XRP Ledger Foundation · Проверено 30 августа 2026 г. в 15:40 GMT+5
Материал носит информационный характер и не является индивидуальной рекомендацией. Криптоактивы связаны с риском волатильности, технических сбоев, хищения и полной потери средств.