| Проверка | Что подтверждает | Чего не подтверждает |
|---|---|---|
| Wallet address и code/version | Какой контракт проверит request | Кому дошло исходящее сообщение |
| seqno совпадает с storage | Request находится в ожидаемой очереди этого wallet | Успешную action phase |
| now не позже valid_until | Подпись ещё находится в своём временном окне | Включение в блок до дедлайна |
| Signature и wallet/subwallet ID корректны | Request предназначен этой инстанции кошелька | Получение Jetton или TON адресатом |
- Проверка
- Wallet address и code/version
- Что подтверждает
- Какой контракт проверит request
- Чего не подтверждает
- Кому дошло исходящее сообщение
- Проверка
- seqno совпадает с storage
- Что подтверждает
- Request находится в ожидаемой очереди этого wallet
- Чего не подтверждает
- Успешную action phase
- Проверка
- now не позже valid_until
- Что подтверждает
- Подпись ещё находится в своём временном окне
- Чего не подтверждает
- Включение в блок до дедлайна
- Проверка
- Signature и wallet/subwallet ID корректны
- Что подтверждает
- Request предназначен этой инстанции кошелька
- Чего не подтверждает
- Получение Jetton или TON адресатом
Сначала определить wallet contract, а не гадать по приложению
Один публичный ключ может использоваться в нескольких wallet instances с разными subwallet_id, а в Wallet V5 поле wallet_id дополнительно кодирует параметры инстанции. У каждого такого контракта собственные address, state и seqno. Поэтому seqno из другого адреса или другой сети не исправляет ошибку. Полезно декодировать форму user-friendly адреса и сверить её с raw account ID, но она сама не раскрывает версию кода.
Сохраните workchain, account ID, code hash или точно определённую wallet version и результат getter `seqno` на конкретном block/LT. Для Wallet V4 подписываемая часть включает subwallet_id, valid_until и seqno; Wallet V5 использует свой signed-request layout и walletId. Не переносите exit codes или порядок полей между версиями без сверки документации и кода контракта.
Три состояния перед повтором
Диагностический алгоритм без новой подписи
- 1Зафиксировать исходник
Сохраните BOC или точные serialized bytes, его hash, время создания и все поля signed request. Скриншота суммы недостаточно.
- 2Найти message onchain
Ищите внешний message и транзакцию именно этого wallet address. Если запись есть, сравните hash и прочитайте transaction phases.
- 3Прочитать текущее seqno
Берите getter из того же wallet contract. Совпадение означает лишь возможность приёма; увеличение требует найти, какой request его изменил.
- 4Сопоставить время
Сравните valid_until с временем сети/блока, а не только с часами телефона. Истёкший request надо считать неприемлемым.
- 5Выбрать действие
Повторяйте только идентичные bytes при текущем seqno и живом окне. Во всех остальных случаях сначала завершите onchain-диагноз.
| Наблюдение | Безопасный вывод | Следующее действие |
|---|---|---|
| Message не найден; seqno прежний; valid_until жив | Контракт ещё мог не принять exact request | Разрешён повтор тех же bytes через доверенный endpoint |
| Message не найден; valid_until истёк | Старая подпись больше не подходит | Не ретранслировать; заново проверить намерение перед новой подписью |
| seqno вырос | Wallet принял какой-то request этого номера | Найти его transaction/trace; не создавать замену вслепую |
| External message найден, action/result неясен | Pre-admission завершён, но бизнес-результат неизвестен | Разобрать compute/action и outbound messages |
| Два разных подписанных message претендуют на действие | Есть риск двойного результата | Остановить автоматические retries и вручную сопоставить hashes |
- Наблюдение
- Message не найден; seqno прежний; valid_until жив
- Безопасный вывод
- Контракт ещё мог не принять exact request
- Следующее действие
- Разрешён повтор тех же bytes через доверенный endpoint
- Наблюдение
- Message не найден; valid_until истёк
- Безопасный вывод
- Старая подпись больше не подходит
- Следующее действие
- Не ретранслировать; заново проверить намерение перед новой подписью
- Наблюдение
- seqno вырос
- Безопасный вывод
- Wallet принял какой-то request этого номера
- Следующее действие
- Найти его transaction/trace; не создавать замену вслепую
- Наблюдение
- External message найден, action/result неясен
- Безопасный вывод
- Pre-admission завершён, но бизнес-результат неизвестен
- Следующее действие
- Разобрать compute/action и outbound messages
- Наблюдение
- Два разных подписанных message претендуют на действие
- Безопасный вывод
- Есть риск двойного результата
- Следующее действие
- Остановить автоматические retries и вручную сопоставить hashes
После принятия seqno перестаёт быть доказательством перевода
Когда wallet transaction существует, дальнейший вопрос принадлежит фазам исполнения и цепочке внутренних сообщений. Успешная проверка подписи и seqno может сменить state кошелька, но исходящее действие способно не выполниться или породить отдельный bounce. Для этого читайте compute, action, aborted, fees и downstream trace — это отдельная диагностика TON-транзакции.
Для Jetton одного wallet seqno особенно мало: токен хранится в отдельном Jetton wallet и перевод разворачивается в несколько сообщений. Сверяйте canonical Jetton master, адрес вычисленного Jetton wallet и уведомление/зачисление. Если спор относится к обычному переводу, подготовьте hash, сеть, адреса и фактические суммы как доказательство перевода, не раскрывая seed-фразу или private key.
Источники
Мы используем прямые ссылки и фиксируем дату проверки. Полный текст чужих материалов не перепечатывается.
- TON Docs — How TON wallets work TON Docs · Проверено 22 августа 2026 г. в 10:38 GMT+5
- TON Docs — Wallet V4 TON Docs · Проверено 22 августа 2026 г. в 10:38 GMT+5
- TON Docs — Wallet V5 API TON Docs · Проверено 22 августа 2026 г. в 10:38 GMT+5
- TON Docs — Wallet comparison TON Docs · Проверено 22 августа 2026 г. в 10:38 GMT+5