Адрес депозита NEAR: именной аккаунт или implicit address

Для перевода NEAR используйте точный account ID, выданный принимающим кошельком или платформой. Именной аккаунт и implicit address из 64 символов не становятся взаимозаменяемыми получателями только потому, что связанные ключи используются в одном кошельке. Перед депозитом проверьте сеть, конкретный аккаунт и поддержку его формата обеими сторонами.

Аккаунт, публичный ключ и кошелёк — разные сущности

Кошелёк помогает управлять доступом и готовить транзакции. Публичный ключ относится к авторизации, а account ID обозначает аккаунт, которому направляется действие. Документация адресов NEAR описывает именные идентификаторы и несколько других форм. Не вставляйте публичный ключ в поле получателя лишь потому, что и он, и адрес выглядят как криптографические строки.

Для стандартного NEAR-implicit аккаунта идентификатор является шестнадцатеричной записью публичного ключа Ed25519 в нижнем регистре. У именного аккаунта есть зарегистрированное имя и собственный набор ключей доступа. Описание access keys допускает несколько ключей с разными полномочиями. Поэтому именной account ID нельзя понимать как «тот же публичный ключ, только в удобной записи».

Таблица сравнивает знакомые пользователю значения, а не перечисляет все типы аккаунтов протокола. Актуальная документация также описывает deterministic и universal accounts. Если платформа выдала непривычный формат, проверьте её текущие инструкции. Удаление префикса или самодельная переделка строки под старую статью могут изменить смысл получателя и не являются проверкой адреса.

Почему после импорта ключа отображается другой остаток

Представим вымышленную ситуацию: раньше приложение показывало именной аккаунт, а после импорта связанных данных другой кошелёк открыл представление implicit-аккаунта. Нулевой баланс в этом представлении сам по себе не доказывает пропажу или перемещение средств именного аккаунта. Сначала сравнивают старый адрес получения и тот account ID, который открыт сейчас, обязательно в одной сети.

В справке Crypto.com Onchain о NEAR есть пример ограничения конкретного продукта: поддержка implicit-адресов и предупреждение об ином представлении аккаунта после импорта старого кошелька с именем. Это пример поведения данного приложения, а не правило всех бирж NEAR. Общую фразу справки о преобразуемости адресов не следует понимать как разрешение произвольно заменять получателя.

Связанный ключ может иметь доступ к нескольким аккаунтам, но совпадение ключевого материала не объединяет их балансы. Добавление или удаление ключа также не переименовывает существующий именной аккаунт. Проверяйте адрес и доступ через доверенный кошелёк. Вводить сид-фразу на сайт «конвертации адресов», чтобы выяснить местонахождение средств, для этого не требуется и небезопасно.

Допустимый формат ещё не означает поддержку платформой

Строка может соответствовать синтаксису NEAR и при этом указывать не тому получателю. Отдельно существует поддержка типа аккаунта отправляющим приложением. Руководство проверки получателя разделяет неверный формат, отсутствие инициализации и опечатку, ведущую к другому существующему аккаунту. Зелёная проверка формата отвечает лишь на часть вопросов, а не удостоверяет весь будущий платёж.

Спецификация аккаунтов Nearcore описывает и Ethereum-like идентификаторы внутри NEAR. Знакомый вид 0x не делает сети Ethereum и NEAR одной сетью. Адрес депозита Ethereum и инструкции получения NEAR нельзя считать взаимозаменяемыми только из-за сходства строк. Сеть выбирают по явным реквизитам получателя, а не по внешнему виду.

Если источник отклоняет именной ID, не придумывайте вместо него implicit-адрес. Запросите поддерживаемый маршрут у получателя или уточните поддержку типа аккаунта в отправляющем кошельке. Замена символа, добавление суффикса и вывод другого адреса из ключа могут привести к иному получателю. Успех такого перевода ещё не подтвердит оплату первоначальной заявки.

Проверьте инициализацию без универсального минимума

Руководство создания аккаунтов отличает локальное получение implicit ID от создания аккаунта в блокчейне. Стандартный implicit-аккаунт можно инициализировать подходящим переводом нативного NEAR. Из этого не следует, что любой токен-контракт или депозитный процесс автоматически создаст любого получателя. Порядок зависит от конкретного действия и интерфейса.

Минимум кошелька, требования хранения и нижний порог депозита платформы — отдельные условия. Нельзя переносить сумму активации из справки одного приложения на все аккаунты NEAR. Для депозита проверяют текущий экран получения платформы. Для самостоятельного кошелька — состояние именно его аккаунта и поддерживаемый порядок нативного перевода, без выдуманного общего порога.

Рабочая проверка получателя перед отправкой

1. Откройте свежие инструкции получения в нужном кошельке или на платформе. Зафиксируйте актив, сеть и точный account ID.
2. Сравните весь ID с окончательным просмотром платежа. Сохраните точки, префиксы и суффиксы как выданы; не исправляйте адрес догадками.
3. Убедитесь, что источник поддерживает этот тип аккаунта. Допустимый для протокола ID может не поддерживаться конкретным приложением.
4. Проверьте существование аккаунта либо предусмотренную инициализацию через доверенный источник. Приватные ключи для такой проверки не раскрывают.
5. Для депозита уточните дополнительные реквизиты и минимумы именно этого маршрута. Не придумывайте memo по аналогии с другой сетью.
6. После отправки сохраните хеш и посмотрите окончательный результат с относящимися к получателю receipts до нового платежа.

При выполнении NEAR использует receipts. Описание жизненного цикла разделяет включение транзакции, исполнение receipts и финальность консенсуса. Списание у источника или включённая запись сами по себе не дают полного подтверждения успешного действия у получателя. Нужно прочитать относящийся к нему результат, а затем отдельно сопоставить внутреннее зачисление платформы, если получатель кастодиальный.

Для поддержки подготовьте сеть, точный принимающий ID, хеш при наличии, актив и первоначальный текст ошибки. Укажите этап: подготовка до подписи, отправка или проверка после выполненной операции. Ошибка неподписанной формы не является пропавшим платежом в блокчейне. Публичный хеш также не заменяет собственные требования принимающей платформы к депозиту.

Контекст нативного актива есть на странице NEAR. Для последующего обмена без регистрации используйте аккаунт и сеть из конкретной заявки. Раздел как работает сервис описывает процесс обмена; сравнение форматов не обещает поддержку всех типов NEAR и не доказывает, что любое другое представление кошелька соответствует получателю заявки.