Ошибка trustline в Stellar: NO_TRUST, NOT_AUTHORIZED и LINE_FULL

Код актива без issuer не определяет trustline

Выпущенный актив Stellar задаётся парой asset code + issuer. Две линии с одинаковым кодом, но разными issuer — разные активы. Скопируйте оба поля из операции или исходной заявки и ищите balance entry только по этой паре. Нативный XLM не требует trustline; он тоже может вернуть PAYMENT_LINE_FULL из-за ёмкости аккаунта, но формула trustline ниже относится только к выпущенным активам.

Result code показывает, какая сторона не прошла проверку

Читайте код операции, а не только общий статус транзакции и текст кошелька. В одной транзакции может быть несколько операций: точная позиция неудачной Payment связывает ошибку с её source account, destination и asset.

Trustline может существовать, но не давать права на перевод

При включённом контроле доступа эмитент управляет флагами линии. Полная авторизация позволяет использовать актив в обычных операциях. Режим authorized to maintain liabilities ограниченнее: он позволяет сохранить или снять существующие обязательства, но не превращает линию в свободно принимающую новый платёж.

Получатель не может исправить NOT_AUTHORIZED новой попыткой Payment. Нужна операция эмитента над этой trustline. До неё не просите пользователя увеличивать лимит или пересоздавать ту же линию: эти действия не меняют флаг доступа.

LINE_FULL учитывает не только видимый balance

Для входящего Payment выпущенного актива проверьте условие: balance + buying liabilities + amount не превышает limit. Buying liabilities — объём актива, зарезервированный под возможное исполнение открытых offers. Поэтому линия может выглядеть незаполненной по одному balance и всё равно отклонить перевод.

Успех доказывают код операции и новое состояние линии

Не переотправляйте старый envelope после исправления. Сначала проверьте исходный hash: при timeout ответ мог потеряться уже после приёма транзакции. Если прежняя попытка точно не прошла, загрузите актуальный sequence, соберите и подпишите новую транзакцию намеренно — иначе диагностическая попытка может стать дублем.

После новой отправки найдите транзакцию и конкретную Payment operation, проверьте successful, transaction_successful, code + issuer, from, to, amount и состояние линии в следующем ledger. Если в той же транзакции были другие операции с этим активом, учитывайте их отдельно и не приписывайте весь итоговый delta одной Payment. Общий порядок подтверждения перевода помогает не принять надпись интерфейса за доказательство, а разбор raw balance пригодится, если расходятся отображаемые знаки после запятой.

Fee bump отвечает за оплату комиссии и inner result, а sponsored reserves — за резервные обязательства аккаунта. Они могут встречаться рядом с Payment, но не заменяют проверку trustline и не являются исправлением этих трёх кодов.