Destination tag в XRP Ledger — беззнаковое 32-битное целое число. Поэтому десятичная запись 00042 обозначает то же значение, что 42. Но ноль и отсутствие тега различаются, а номер заявки биржи не становится тегом автоматически. Используйте назначенные получателем реквизиты и до подписи проверьте, какое значение действительно попадёт в транзакцию.
Установите, что скопировали именно тег назначения
На странице депозита могут одновременно находиться адрес счёта, тег и внутренний номер заказа либо клиента. У этих полей разные задачи. Документация XRP Ledger о тегах описывает их как сведения для распределения платежей во внешних системах. Аккаунт получателя существует в реестре, а метка помогает сервису понять, какому внутреннему получателю зачислять поступление.
До толкования нулей прочитайте подпись поля. Строка ORDER-00042 может быть правильным внутренним номером, но не подходить числовому полю DestinationTag. Удалив буквы ради принятия формы, вы самостоятельно придумаете новые реквизиты. Если нужное поле не определено, уточните у получателя, какое значение использовать. Не превращайте любое похожее обозначение в число только потому, что кошелёк отклоняет исходную строку.
Что меняет нормализация и что обязано сохраниться
Протокол хранит числовое значение, а не точную последовательность десятичных символов со снимка экрана. Поэтому приложение может показать тег без начальных нулей. Если число сохранилось, это может быть обычной нормализацией. Она не доказывает изменение адреса получателя и не даёт основания так же обрабатывать внутренний текстовый номер заявки. Внешне похожие изменения могут касаться совершенно разных полей.
| Что скопировано или отображается | Смысл для протокола | Что проверить | Опасное предположение |
|---|---|---|---|
| 00042 в явно числовом поле тега | Десятичное значение равно 42 | Итоговый экран и отправленное поле сохранили это число | Любой длинный номер с окончанием 42 означает этот тег |
| 0 | Поле присутствует со значением ноль | Именно ноль назначил получатель | Ноль равен пустому полю |
| Пустое поле | Тег может отсутствовать в операции | Допускает ли это принимающий счёт | Сеть сама определит внутреннего клиента |
| ORDER-00042 | В таком виде это не числовой DestinationTag | Не является ли строка внутренним номером | Достаточно убрать буквы |
| 4 294 967 295 | Верхняя граница беззнакового 32-битного числа | Настоящее назначенное значение и оформление ввода | Любой допустимый по размеру тег относится к вашему счёту |
| 4 294 967 296 | Число за пределами диапазона | Происхождение и тип обозначения | Можно обрезать цифры до принятия кошельком |
Граничные числа показывают математический диапазон, но не являются реквизитами для использования. Значение назначает принимающий сервис. Допустимый формат не подтверждает принадлежность внутреннему клиенту, а успешная транзакция не доказывает принятие вашей трактовки системой зачисления. Сохраните исходную инструкцию вместе с конечной записью операции. Так можно будет сравнить назначенное и действительно отправленное без догадок.
Ноль — значение, отсутствие — отдельное условие
Если назначен ноль, приложение не должно молча превращать его в отсутствие поля. Но и отправителю не следует придумывать ноль только потому, что форма предлагает необязательный ввод. В описании транзакции Payment DestinationTag определён как необязательное числовое поле. Это допускает отсутствие при соответствующем порядке получения, но не разрешает заменить реквизиты произвольным значением.
У части принимающих аккаунтов включено требование тега. Протокол может отклонить операцию без такого поля. Однако это не означает проверку каждого присутствующего значения по внутренней клиентской базе сервиса. Неверное число и отсутствие числа поэтому способны привести к разным ситуациям. Посмотрите итог исполнения до вывода о доставке и до решения о повторном переводе. Само исчезновение ошибки формы зачисления не подтверждает.
Не переносите тег в другое поле ссылки
Тег источника описывает отправляющую сторону, тег назначения относится к распределению у получателя. Эти поля не взаимозаменяемы лишь потому, что оба принимают числа. Текстовый комментарий также не следует считать заменой обязательного DestinationTag. Если приложение показывает несколько реквизитов, до подготовки платежа определите именно поле тега получателя. Иначе корректное число может оказаться в неподходящем месте.
Как объясняет официальное руководство, X-адрес способен включать классический аккаунт вместе с тегом. Это самостоятельный поддерживаемый формат, а не повод вручную обрезать строку адреса. Если отправитель принимает только обычный адрес и отдельное число, получите проверенное совместимое представление. При поддержке X-адреса изучите расшифрованные значения и не добавляйте поверх них противоречащий тег без объяснения.
Что сравнить до подписи
- Откройте текущую страницу депозита XRP у получателя. Установите адрес и явно назначенный тег, отделив их от внутреннего номера заказа.
- Скопируйте значение в предназначенное поле кошелька. При изменении вида сравните само число и убедитесь, что значащие цифры не исчезли.
- Для назначенного нуля проверьте присутствие поля на итоговом экране. При пустой инструкции не придумывайте значение без подтверждения.
- Сверьте получателя, сеть, сумму и расшифровку X-адреса, если он используется. Несовместимость формата разрешайте через проверенную поддержку.
- После отправки найдите подтверждённую операцию и изучите фактический тег с результатом. Сохраните запись рядом с полученными реквизитами.
Проверка memo и tag напоминает о нужном поле, а инструкция XRPScan помогает найти опубликованный платёж. Ни один инструмент не знает, какую личную клиентскую привязку назначил получатель. Её нужно получать у настоящей принимающей стороны. Число из обучающего примера или чужого снимка не становится вашим тегом, даже если прошло проверку формата.
Если неверный тег уже отправлен
Передайте принимающему сервису хеш, сумму, время, внутренний номер и фактически отправленный тег. Уточните вид расхождения: поле отсутствовало, число отличается или изменилось только дополнение нулями. Объяснение destination tag от BitPay показывает смысл распределения при общем адресе, но порядок ручной сверки устанавливает каждая площадка отдельно.
Не обещайте себе автоматический возврат и не предполагайте единую плату за разбор. После подтверждения нельзя изменить тег редактированием местной формы. Второй перевод также не правит первую запись. Сохраните доказательства, чтобы настоящий получатель установил возможность ручного зачисления. Если исход первой отправки пока неизвестен, разберитесь с ним до нового платежа, иначе появится ещё одна отдельная операция.
Для обмена без регистрации используйте реквизиты действующей заявки и проверьте обязательные метки до отправки. Различение числового тега и внутреннего номера упрощает дальнейший вопрос поддержке. Правильно нормализованное число полезно лишь тогда, когда это действительно назначенное принимающей системой значение. Оно не заменяет остальных условий получения и не подтверждает распределение само по себе.
Частые вопросы
Как выглядит destination tag XRP?
На уровне реестра это беззнаковое целое число в 32-битном диапазоне. Число из примера показывает формат, но использовать нужно значение, назначенное вашим получателем.
Destination tag XRP — это memo?
Приложения могут использовать слово memo как общее обозначение, но в Payment требуется конкретное поле DestinationTag. Проверьте, что назначенное число отправляется именно в него.
Нужен ли destination tag для Trust Wallet?
Требование определяется принимающим аккаунтом, а не одним названием приложения отправителя. Читайте текущие реквизиты получателя и не придумывайте число, если он его не назначил.