Nano: send подтверждён, но баланс не изменился

Подтверждённая отправка завершает только половину маршрута

Каждый Nano-аккаунт ведёт собственную цепочку. Блок `send` принадлежит отправителю: он уменьшает его баланс и содержит в поле `link` публичный ключ получателя. Адресат меняет свою цепочку отдельным блоком состояния. Для открытого аккаунта это `receive` с `previous`, равным текущей вершине (`frontier`); для первого получения — `open` с нулевым `previous` и выбранным представителем (`representative`).

Если `send` подтверждён, отправитель уже не может его отменить, а сумма остаётся доступной для получения без срока истечения. Офлайн-получатель не мешает подтверждению отправки. Потратить сумму можно лишь после подтверждения `receive` или `open`. Поэтому общий статус перевода полезен только вместе с состоянием обеих цепочек аккаунтов.

Где находится сумма на каждом этапе
Наблюдение	Состояние суммы	Кто может завершить следующий шаг
`send` не подтверждён	Нет необратимого результата	Сеть должна подтвердить исходную отправку
`send` подтверждён и есть в `receivable`	Списана у отправителя, ещё не записана в баланс получателя	Кошелёк, контролирующий ключ получателя
Есть подтверждённый `receive` или `open`	Записана в цепочку получателя	Никто: получение уже завершено
Интерфейс не обновил баланс, `receive` подтверждён	Сетевое состояние готово, локальный экран отстал	Кошелёк должен перечитать вершину и баланс

Где находится сумма на каждом этапе

Наблюдение: `send` не подтверждён
Состояние суммы: Нет необратимого результата
Кто может завершить следующий шаг: Сеть должна подтвердить исходную отправку

Наблюдение: `send` подтверждён и есть в `receivable`
Состояние суммы: Списана у отправителя, ещё не записана в баланс получателя
Кто может завершить следующий шаг: Кошелёк, контролирующий ключ получателя

Наблюдение: Есть подтверждённый `receive` или `open`
Состояние суммы: Записана в цепочку получателя
Кто может завершить следующий шаг: Никто: получение уже завершено

Наблюдение: Интерфейс не обновил баланс, `receive` подтверждён
Состояние суммы: Сетевое состояние готово, локальный экран отстал
Кто может завершить следующий шаг: Кошелёк должен перечитать вершину и баланс

Receivable связывает отправку с адресом получателя

Возьмите хеш исходного `send` и точный адрес назначения из подтверждённого блока. Запрос `accounts_receivable` для этого адреса возвращает подтверждённые отправки, для которых ещё нет `receive`. В актуальном RPC термин `receivable` заменил прежнее название `pending`; старый интерфейс может показывать pending, хотя речь идёт не о неподтверждённой отправке.

По умолчанию `include_active` равен `false`, поэтому ответ не включает ещё не подтверждённые отправки. Если хеш найден вместе с `amount` и `source`, сверьте адрес, сумму и отправителя. Отсутствие хеша может означать неверный адрес, уже выполненный приём, неподтверждённый исходный блок либо отстающий или загружающийся узел. Запросите исходный блок через `blocks_info` с `receive_hash: true`: ненулевой `receive_hash` указывает уже созданный блок получения. Нулевой ответ проверяйте вместе с подтверждением источника и `accounts_receivable` на втором синхронизированном узле; устройство RPC объясняет такие расхождения.

Диагностический алгоритм

1
Подтвердите исходную отправку
Через `blocks_info` проверьте хеш, подтип `send`, адрес назначения в `link`, сумму и признак `confirmed`. Не полагайтесь на уведомление биржи или кошелька.
2
Найдите источник в receivable
Запросите `accounts_receivable` точного адреса получателя. Совпадение хеша означает, что `receive` или `open` ещё не подтверждён.
3
Проверьте receive_hash
Запросите исходный `send` через `blocks_info` с `receive_hash: true`. Нулевой хеш означает, что узел не знает связанного подтверждённого приёма; ненулевой даёт следующий объект проверки.
4
Синхронизируйте кошелёк получателя
Откройте официальный кошелёк, который контролирует адрес, восстановите его штатным способом при необходимости и дождитесь публикации `receive` или `open`. Не передавайте секреты третьей стороне.
5
Перечитайте подтверждённое состояние
Через `account_info` и блок получения сверьте новую вершину, подтверждённый баланс и исчезновение исходного хеша из `receivable`.

Новый и существующий аккаунт строят разные блоки

Как распознать блок получения
Состояние аккаунта до получения	Ожидаемый блок	Ключевые поля
Аккаунт ещё не открыт	Блок состояния `open`	`previous` — нулевой, `link` — хеш отправки, указан `representative`, баланс равен получению
Цепочка аккаунта уже существует	Блок состояния `receive`	`previous` — текущая подтверждённая вершина, `link` — хеш отправки, баланс увеличен на `amount`
`receive` уже подтверждён	Новая вершина аккаунта	`receive_hash` исходной отправки указывает на него, источник исчез из `receivable`

Как распознать блок получения

Состояние аккаунта до получения: Аккаунт ещё не открыт
Ожидаемый блок: Блок состояния `open`
Ключевые поля: `previous` — нулевой, `link` — хеш отправки, указан `representative`, баланс равен получению

Состояние аккаунта до получения: Цепочка аккаунта уже существует
Ожидаемый блок: Блок состояния `receive`
Ключевые поля: `previous` — текущая подтверждённая вершина, `link` — хеш отправки, баланс увеличен на `amount`

Состояние аккаунта до получения: `receive` уже подтверждён
Ожидаемый блок: Новая вершина аккаунта
Ключевые поля: `receive_hash` исходной отправки указывает на него, источник исчез из `receivable`

Кошелёк может не опубликовать `receive` автоматически, если приложение давно не запускали, отключена фоновая обработка, выбран другой аккаунт, выведенный из seed-фразы, или локальный узел не синхронизирован. Начните с точного адреса: восстановление одной seed-фразы не гарантирует, что интерфейс уже открыл нужный индекс аккаунта. Поддержка может попросить публичный адрес и хеш отправки, но не seed-фразу и не закрытый ключ.

Если отправителем была биржа и она не дала сетевой хеш, сначала отделите внутреннюю запись сервиса от отправки в блокчейне. Внутренний перевод без tx hash не создаёт `receivable`, пока сервис действительно не опубликует вывод в Nano.

Получение доказано тремя совпадающими фактами

исходный `send` подтверждён и его `receive_hash` указывает на конкретный блок `receive` или `open`;
этот блок получения подтверждён, подписан аккаунтом адресата и ссылается через `link` на исходную отправку;
подтверждённые баланс и вершина получателя соответствуют новому состоянию, а хеш отправки исчез из `accounts_receivable`.

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

Повторная отправка запрещена, пока не объяснён исходный send

поле `link` отправки не соответствует ожидаемому публичному ключу получателя;
кошелёк открыт на другом аккаунте или индексе аккаунта, выведенном из seed-фразы;
RPC возвращает активную неподтверждённую отправку;
предлагают исправить отсутствие `receive` новым платежом;
сайт просит seed-фразу, приватный ключ или удалённый доступ к устройству.

Источники

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

Nano Docs — Ledger Nano Foundation · Проверено 28 августа 2026 г. в 03:52 GMT+5
Nano Docs — Integration basics Nano Foundation · Проверено 28 августа 2026 г. в 03:52 GMT+5
Nano Docs — RPC protocol Nano Foundation · Проверено 28 августа 2026 г. в 03:52 GMT+5
Nano Docs — Key management Nano Foundation · Проверено 28 августа 2026 г. в 03:52 GMT+5

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