Кто за что отвечает во внешней и внутренней транзакции
Сохраните `envelope_xdr` до декодирования. Во внешней части найдите `feeSource`, заявленную комиссию и подписи этой оболочки. Во внутренней — исходную оболочку, её аккаунт-источник, порядковый номер, временные границы, операции и прежние подписи. Fee-bump не разрешает незаметно поменять получателя или сумму: любое изменение внутренней оболочки требует заново собрать и подписать транзакцию.
Для `feeSource` нужна подпись, которая достигает низкого порога (low threshold) — минимального уровня полномочий аккаунта для этой операции. Плательщик не становится владельцем актива или источником внутренней операции и не подтверждает её успешность. Чтобы не принять понятную подпись кнопки за содержание XDR, сначала разберите, что именно подписывает кошелёк.
| Поле или результат | К какой части относится | Что из него можно заключить |
|---|---|---|
| `feeSource` и внешние подписи | Внешняя | Кто разрешил списать комиссию |
| Внешняя комиссия | Внешняя | Верхний предел комиссии всей fee-bump транзакции; это не сумма перевода |
| Исходный аккаунт и порядковый номер | Внутренняя | Чья очередь операций и защита от повтора используются |
| Внутренние операции и подписи | Внутренняя | Какое действие просили выполнить и кто его разрешил |
| `FEE_BUMP_INNER_SUCCESS` или `FEE_BUMP_INNER_FAILED` | Верхний результат | В какую ветку вложенного результата перейти |
| `innerResultPair.result` и результаты операций | Внутренняя | Почему действие прошло или остановилось |
- Поле или результат
- `feeSource` и внешние подписи
- К какой части относится
- Внешняя
- Что из него можно заключить
- Кто разрешил списать комиссию
- Поле или результат
- Внешняя комиссия
- К какой части относится
- Внешняя
- Что из него можно заключить
- Верхний предел комиссии всей fee-bump транзакции; это не сумма перевода
- Поле или результат
- Исходный аккаунт и порядковый номер
- К какой части относится
- Внутренняя
- Что из него можно заключить
- Чья очередь операций и защита от повтора используются
- Поле или результат
- Внутренние операции и подписи
- К какой части относится
- Внутренняя
- Что из него можно заключить
- Какое действие просили выполнить и кто его разрешил
- Поле или результат
- `FEE_BUMP_INNER_SUCCESS` или `FEE_BUMP_INNER_FAILED`
- К какой части относится
- Верхний результат
- Что из него можно заключить
- В какую ветку вложенного результата перейти
- Поле или результат
- `innerResultPair.result` и результаты операций
- К какой части относится
- Внутренняя
- Что из него можно заключить
- Почему действие прошло или остановилось
Сохраните исходный ответ Horizon
При ответе Horizon сохраните HTTP-код, хеш транзакции, `extras.envelope_xdr`, `extras.result_xdr` и весь `extras.result_codes`. Поле `result_codes.transaction` — краткая подсказка. Массив `result_codes.operations` показывает коды операций, но полная вложенная структура остаётся в `result_xdr`. Для спора или повторной диагностики нужны оба XDR, а не скриншот уведомления.
Таймаут тоже оставляет результат неизвестным. Сначала запросите транзакцию по тому же хешу и сохраните номер реестра, в котором она появилась, либо зафиксируйте, что записи пока нет. Различие между отправкой, включением и окончательным состоянием разобрано в материале о подтверждениях и финальности.
Сначала прочитайте общий результат, затем внутреннюю ошибку
Порядок чтения XDR результата
- Сверьте XDR результата с сохранённой внешней оболочкой и правильной сетью.
- Запишите внешнюю `feeCharged` и верхний `TransactionResultCode`.
- Из `innerResultPair` возьмите хеш внутренней транзакции и её собственный код результата.
- Если вложенный результат содержит результаты операций, найдите первую неуспешную операцию и прочитайте её точный код.
- Сопоставьте код с полями внутренней оболочки и состоянием исходного аккаунта, получателя, линии доверия, ордера или другого затронутого объекта в этом реестре.
Если fee-bump включён в реестр, сеть считает порядковый номер внутреннего исходного аккаунта использованным даже при отказе самой операции: так работает защита от повтора. Ответ, полученный до включения, этого не доказывает. Проверьте запись транзакции и новый текущий номер аккаунта. После его изменения старая подписанная внутренняя транзакция больше не подходит.
Не смешивайте fee-bump со спонсируемым резервом (sponsored reserves). Fee-bump оплачивает комиссию транзакции. Спонсируемый резерв означает, что один аккаунт держит обязательный минимальный остаток за запись другого аккаунта. Если в одной операции встречаются оба механизма, проверяйте их независимо.
Повышение комиссии не исправляет внутреннюю ошибку
| Факт | Чего не делать | Что проверить |
|---|---|---|
| Невалидны внешняя комиссия или подпись плательщика | Не менять внутреннюю транзакцию | Ставку, баланс плательщика, порог подписи аккаунта, код сети и внешнюю подпись |
| Внутренняя проверка вернула `BAD_SEQ` или `BAD_AUTH` | Не добавлять только более высокую комиссию | Текущий порядковый номер, набор подписей, пороги и сеть |
| Внутренняя операция завершилась ошибкой | Не повторять вслепую с новым порядковым номером | Код операции и прикладное состояние, которое сделает повтор допустимым |
| Статус всё ещё `PENDING` или был таймаут | Не собирать конкурирующий платёж | Тот же хеш, временные границы, включение в реестр и порядковый номер аккаунта |
| Нужно поднять только ставку комиссии | Не менять операции и внутренние подписи | Правило замены fee-bump с повышенной комиссией (`replace-by-fee`) и точное совпадение внутренней транзакции |
- Факт
- Невалидны внешняя комиссия или подпись плательщика
- Чего не делать
- Не менять внутреннюю транзакцию
- Что проверить
- Ставку, баланс плательщика, порог подписи аккаунта, код сети и внешнюю подпись
- Факт
- Внутренняя проверка вернула `BAD_SEQ` или `BAD_AUTH`
- Чего не делать
- Не добавлять только более высокую комиссию
- Что проверить
- Текущий порядковый номер, набор подписей, пороги и сеть
- Факт
- Внутренняя операция завершилась ошибкой
- Чего не делать
- Не повторять вслепую с новым порядковым номером
- Что проверить
- Код операции и прикладное состояние, которое сделает повтор допустимым
- Факт
- Статус всё ещё `PENDING` или был таймаут
- Чего не делать
- Не собирать конкурирующий платёж
- Что проверить
- Тот же хеш, временные границы, включение в реестр и порядковый номер аккаунта
- Факт
- Нужно поднять только ставку комиссии
- Чего не делать
- Не менять операции и внутренние подписи
- Что проверить
- Правило замены fee-bump с повышенной комиссией (`replace-by-fee`) и точное совпадение внутренней транзакции
Завершённая проверка показывает два независимых результата: сколько комиссии списано с внешнего плательщика и что произошло с внутренней операцией. Сохраните хеши обеих транзакций, номер реестра, исходный аккаунт, использованный порядковый номер и коды операций. Добавьте фактическое изменение: например, новый остаток получателя при успехе или неизменное состояние при отказе. Тогда видно, была ли только списана комиссия или внутренняя операция тоже исполнилась.
Источники
Мы используем прямые ссылки и фиксируем дату проверки. Полный текст чужих материалов не перепечатывается.
- Stellar Docs — Fee-bump transactions Stellar Development Foundation · Проверено 25 августа 2026 г. в 09:18 GMT+5
- Stellar protocol CAP-15 — Fee-bump transactions Stellar Development Foundation · Проверено 25 августа 2026 г. в 09:18 GMT+5
- Stellar Horizon API — Error response Stellar Development Foundation · Проверено 25 августа 2026 г. в 09:18 GMT+5
- Stellar Horizon API — Error handling Stellar Development Foundation · Проверено 25 августа 2026 г. в 09:18 GMT+5