Сначала спросите сам FT-контракт
Аккаунт NEAR может существовать и получать нативный NEAR, но оставаться неизвестным контракту токена. Вызовите `storage_balance_of` у точного `contract_id` токена с `account_id` получателя. Ответ `null` означает отсутствие регистрации. Нулевой ответ `ft_balance_of` этого не доказывает: стандарт возвращает строку `"0"` и для отсутствующей записи.
Зафиксируйте сеть, адрес FT-контракта и номер финализированного блока ответа. Поддельный токен с тем же символом имеет другой реестр. Общая проверка перевода помогает сверить хеш и сеть, но регистрацию показывает только метод нужного контракта.
| Наблюдение | Что оно означает | Следующее действие |
|---|---|---|
| `storage_balance_of = null` | Получатель не зарегистрирован в этом контракте | Запросить `storage_balance_bounds`, затем вызвать `storage_deposit` |
| `total` не меньше `min` | Регистрационная запись есть | Перепроверить получателя, сумму, приложенную минимальную единицу и исход перевода |
| `available > 0` | Часть депозита не занята данными | Рассмотреть `storage_withdraw`, не удаляя регистрацию |
| `ft_balance_of > 0` | У аккаунта остались токены | Не выполнять обычный `storage_unregister` до вывода баланса |
| `storage_unregister = false` | Записи уже не было | Не ждать второго возврата; сверить прежние квитанции |
- Наблюдение
- `storage_balance_of = null`
- Что оно означает
- Получатель не зарегистрирован в этом контракте
- Следующее действие
- Запросить `storage_balance_bounds`, затем вызвать `storage_deposit`
- Наблюдение
- `total` не меньше `min`
- Что оно означает
- Регистрационная запись есть
- Следующее действие
- Перепроверить получателя, сумму, приложенную минимальную единицу и исход перевода
- Наблюдение
- `available > 0`
- Что оно означает
- Часть депозита не занята данными
- Следующее действие
- Рассмотреть `storage_withdraw`, не удаляя регистрацию
- Наблюдение
- `ft_balance_of > 0`
- Что оно означает
- У аккаунта остались токены
- Следующее действие
- Не выполнять обычный `storage_unregister` до вывода баланса
- Наблюдение
- `storage_unregister = false`
- Что оно означает
- Записи уже не было
- Следующее действие
- Не ждать второго возврата; сверить прежние квитанции
Размер регистрации берут из текущих границ
Вызовите `storage_balance_bounds` у того же контракта. Поле `min` задаёт минимум, а необязательное `max` — верхнюю границу. Не переносите сумму из чужой инструкции: разные контракты могут хранить разные данные и менять реализацию. Все значения передаются в минимальных единицах NEAR строкой без округления интерфейсом.
`storage_deposit` разрешает зарегистрировать себя или другой `account_id`. При `registration_only: true` контракт обязан вернуть сумму сверх минимума для новой записи. Если запись уже была, возвращается весь приложенный депозит. Проверяйте этот возврат отдельно от токенов: он выражен в NEAR и идёт плательщику регистрации.
После окончательного исполнения снова вызовите `storage_balance_of`. Только ненулевой объект подтверждает регистрацию. Затем отправляйте `ft_transfer`: стандарт требует ровно 1 yoctoNEAR (10⁻²⁴ NEAR). У отправителя также должно хватать токенов. Если перевод всё равно падает, найдите конкретную квитанцию и ошибку, а не вносите депозит повторно.
Вывести свободный депозит и удалить запись — разные операции
`storage_withdraw` возвращает доступную часть поля `available`, но не должен удалять данные. Метод принимает необязательную сумму; без неё возвращает весь доступный остаток. Он требует ровно 1 yoctoNEAR и вызывается владельцем записи. Если запрошено больше доступного, стандарт требует ошибку.
`storage_unregister` удаляет регистрацию и возвращает депозит владельцу. Без `force: true` контракт обязан остановиться, если у аккаунта остаются данные, например положительный FT-баланс. Сначала переведите токены, дождитесь окончательного результата и перечитайте баланс.
Принудительный вариант — не способ ускорить возврат. Стандарт разрешает контракту сжечь оставшиеся токены либо применить собственную логику; контракт также может не поддерживать такое удаление. Подписывать `force: true` стоит только после проверки исходного кода или явной документации конкретного токена.
Возврат проверяют по пяти признакам
Что должно сойтись после операции
- транзакция дошла до окончательного результата, а нужная квитанция не содержит `Failure`;
- `storage_balance_of` теперь возвращает ожидаемый объект после регистрации или `null` после удаления;
- изменение баланса NEAR соответствует возврату за вычетом сетевой комиссии, а не предполагаемой сумме из интерфейса;
- для перевода отдельно подтверждён новый FT-баланс получателя, а при наличии NEP-297 — и событие токена;
- все запросы относятся к одному контракту, сети и более позднему финализированному блоку.
Если старый публичный RPC не возвращает квитанцию, запросите архивный источник. Устройство блокчейн-узла объясняет, почему отсутствие истории на одном сервере не равно отсутствию возврата в сети.
Остановитесь до подписи, если
- неизвестен точный FT-контракт или перепутана сеть;
- сумму депозита предлагают взять из старого скриншота вместо `storage_balance_bounds`;
- кошелёк скрывает `account_id`, `registration_only` либо флаг `force`;
- у аккаунта остаются токены, а интерфейс предлагает принудительное удаление без предупреждения;
- возврат считают завершённым по отправке вызова, не проверив квитанции и состояние;
- для диагностики просят seed-фразу, закрытый ключ или удалённый доступ к кошельку.
Источники
Мы используем прямые ссылки и фиксируем дату проверки. Полный текст чужих материалов не перепечатывается.
- NEAR Docs — Fungible Token Standard NEAR · Проверено 25 августа 2026 г. в 09:22 GMT+5
- NEAR Docs — Using Fungible Tokens NEAR · Проверено 25 августа 2026 г. в 09:22 GMT+5
- NEP-145 Storage Management at commit dcc0bcbd452f NEAR · Проверено 25 августа 2026 г. в 09:22 GMT+5
- NEP-141 Fungible Token Standard at commit dcc0bcbd452f NEAR · Проверено 25 августа 2026 г. в 09:22 GMT+5
- NEAR RPC — Transaction status NEAR · Проверено 25 августа 2026 г. в 09:22 GMT+5
- NEAR mainnet RPC status NEAR · Проверено 25 августа 2026 г. в 09:22 GMT+5