XRPL DepositAuth: проверка DepositPreauth и tecNO_PERMISSION

Начните с самого платежа, а не с настройки кошелька

Из подтверждённого `Payment` выпишите сеть, хеш, `Account`, `Destination`, `DestinationTag`, `Amount` и `CredentialIDs`. Сохраните номер подтверждённого реестра. `tecNO_PERMISSION` используется и в других ситуациях, поэтому привяжите код к этой операции и этому получателю.

`DestinationTag` помогает сервису связать перевод с клиентом, но не выдаёт разрешение `DepositPreauth`. Если метки не было, используйте инструкцию по восстановлению служебной заметки или метки получателя. Случайная метка не обходит запрет `DepositAuth`.

Проверьте флаг у получателя

Запросите `account_info` для получателя с `ledger_index: validated`. В `result.account_data.Flags` проверьте бит `lsfDepositAuth` со значением `0x01000000`. Ненулевой бит означает, что обычный входящий `Payment` требует разрешения. Флаг хранится в объекте `AccountRoot`; интерфейс может называть его иначе.

Какую ветку открыть после проверки флага
Что обнаружено	Что проверять	К чему не переходить
`lsfDepositAuth` выключен	Точный код и поля `Payment`	Не создавать `DepositPreauth`: причина другая
Флаг включён, `CredentialIDs` нет	Пару отправитель → получатель через `deposit_authorized`	Не искать разрешение по реквизитам `credentials`
Флаг включён, `CredentialIDs` есть	Тот же набор ID через параметр `credentials`	Не считать разрешение для адреса достаточным
Баланс получателя не выше базового резерва	Узкое исключение для XRP без `CredentialIDs`	Не называть исключение предварительным разрешением

Какую ветку открыть после проверки флага

Что обнаружено: `lsfDepositAuth` выключен
Что проверять: Точный код и поля `Payment`
К чему не переходить: Не создавать `DepositPreauth`: причина другая

Что обнаружено: Флаг включён, `CredentialIDs` нет
Что проверять: Пару отправитель → получатель через `deposit_authorized`
К чему не переходить: Не искать разрешение по реквизитам `credentials`

Что обнаружено: Флаг включён, `CredentialIDs` есть
Что проверять: Тот же набор ID через параметр `credentials`
К чему не переходить: Не считать разрешение для адреса достаточным

Что обнаружено: Баланс получателя не выше базового резерва
Что проверять: Узкое исключение для XRP без `CredentialIDs`
К чему не переходить: Не называть исключение предварительным разрешением

Без CredentialIDs проверяют пару адресов

Передайте адрес плательщика в `source_account`, а адрес получателя — в `destination_account`. Укажите `ledger_index: validated` и не добавляйте параметр `credentials`. Сохраните хеш и номер реестра, а также поле `validated` из ответа. Значение `true` бывает и при выключенном `DepositAuth`, поэтому флаг проверяют отдельно.

Если ответ равен `false`, получатель может создать `DepositPreauth`: в транзакции он указывает себя в `Account`, а плательщика — в `Authorize`. Разрешение одностороннее и действует для отправителя целиком, без привязки к одной валюте. Сам отправитель выдать его себе не может.

Успешная транзакция создаёт отдельный объект и увеличивает резерв владельца. Через `ledger_entry.deposit_preauth` проверьте `owner=получатель` и `authorized=отправитель`. После `tesSUCCESS` снова вызовите `deposit_authorized` на более новом подтверждённом реестре.

С CredentialIDs проверяют предъявленный набор

Передайте в `deposit_authorized.credentials` ровно те ID, которые были в `Payment`. Имя параметра пишется строчными буквами. Нельзя удалить один ID, добавить другой или заменить набор проверкой только по адресам. Пустой массив также недопустим.

Каждый объект `Credential` должен существовать, быть принятым, не истечь и указывать плательщика как `Subject`. Ошибка `badCredentials` означает, что хотя бы одно из этих условий не выполнено. Проверьте каждый исходный ID, а не подбирайте удобный набор.

Получатель разрешает эту ветку через `AuthorizeCredentials`. Объект хранит точный набор `Issuer` и `CredentialType`. Найдите его через `ledger_entry` с `owner` и `authorized_credentials`. Обычный объект `Authorize=отправитель` такую проверку не завершает.

Исключение базового резерва не создаёт разрешение

Есть узкое исключение для XRP. Если баланс получателя не выше текущего базового резерва, неразрешённый платёж может пройти на сумму не выше того же резерва. В `Payment` при этом не должно быть `CredentialIDs`. Дополнительный резерв владельца в расчёт исключения не входит.

Значение резерва меняется. Читайте его в `server_info.validated_ledger.reserve_base_xrp` или `server_state.validated_ledger.reserve_base`. Старую фиксированную сумму не используйте. Подробный расчёт разобран в материале про резерв XRP и OwnerCount.

Перед повтором подтвердите изменение

Что означает следующий ответ
Наблюдение	Вывод	Следующая проверка
`tecDUPLICATE`	Такой `DepositPreauth` уже существует	Проверить направление и нужную ветку на свежем реестре
`tecINSUFFICIENT_RESERVE`	Получателю не хватает доступного XRP для нового объекта	Проверить текущий резерв и `OwnerCount`
`badCredentials`	Один объект `Credential` отсутствует, не принят или истёк	Проверить исходные `CredentialIDs` по одному
`deposit_authorized=false` после `tesSUCCESS`	Использован старый реестр, перепутаны роли или не совпал набор	Повторить исходную ветку на новом подтверждённом реестре
`deposit_authorized=true`, но платёж падает	Разрешение есть, причина находится в другом условии платежа	Разобрать линию доверия, путь, ликвидность, метку, сумму и эмитента

Что означает следующий ответ

Наблюдение: `tecDUPLICATE`
Вывод: Такой `DepositPreauth` уже существует
Следующая проверка: Проверить направление и нужную ветку на свежем реестре

Наблюдение: `tecINSUFFICIENT_RESERVE`
Вывод: Получателю не хватает доступного XRP для нового объекта
Следующая проверка: Проверить текущий резерв и `OwnerCount`

Наблюдение: `badCredentials`
Вывод: Один объект `Credential` отсутствует, не принят или истёк
Следующая проверка: Проверить исходные `CredentialIDs` по одному

Наблюдение: `deposit_authorized=false` после `tesSUCCESS`
Вывод: Использован старый реестр, перепутаны роли или не совпал набор
Следующая проверка: Повторить исходную ветку на новом подтверждённом реестре

Наблюдение: `deposit_authorized=true`, но платёж падает
Вывод: Разрешение есть, причина находится в другом условии платежа
Следующая проверка: Разобрать линию доверия, путь, ликвидность, метку, сумму и эмитента

Ответ `deposit_authorized=true` подтверждает только разрешение для выбранной ветки. Он не гарантирует линию доверия, ликвидность, сумму, комиссию, метку или успех будущего платежа. После подтверждения используйте проверку XRPL Partial Payment и поле `delivered_amount`.

Не лечите отказ серией новых платежей

Не повторяйте платёж, если

адреса отправителя и получателя предлагают поменять местами без проверки исходного `Payment`;
флаг ищут в `AccountRoot` отправителя, хотя `DepositAuth` включается у получателя;
из операции удаляют `CredentialIDs` и считают проверку по адресам равнозначной;
исключение базового резерва рассчитывают по старой фиксированной сумме;
сервис обещает создать `DepositPreauth` от имени получателя без его подписи;
ответ `true` выдают за гарантию любого будущего платежа;
для поддержки просят сид-фразу, закрытый ключ или секретный QR-код.

После исправления сделайте один контролируемый повтор и сохраните подтверждённый код операции. Здесь помогает схема подтверждения перевода: она связывает хеш и адреса. Внутреннее зачисление по-прежнему подтверждает сам получатель или сервис.

Источники

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

XRPL Docs — Deposit Authorization XRP Ledger · Проверено 25 августа 2026 г. в 00:42 GMT+5
XRPL API — deposit_authorized XRP Ledger · Проверено 25 августа 2026 г. в 00:42 GMT+5
XRPL Protocol — DepositPreauth transaction XRP Ledger · Проверено 25 августа 2026 г. в 00:42 GMT+5
XRPL API — ledger_entry DepositPreauth lookup XRP Ledger · Проверено 25 августа 2026 г. в 00:42 GMT+5
XRPL Protocol — tec result codes XRP Ledger · Проверено 25 августа 2026 г. в 00:42 GMT+5
XRPL Protocol — Payment CredentialIDs and reserve exception XRP Ledger · Проверено 25 августа 2026 г. в 00:42 GMT+5
XRPL Docs — live reserve lookup XRP Ledger · Проверено 25 августа 2026 г. в 00:42 GMT+5

Материал носит информационный характер и не является индивидуальной рекомендацией. Криптоактивы связаны с риском волатильности, технических сбоев, хищения и полной потери средств.