Одна цепочка ключей была заново сгенерирована — это не означает, что кошелёк уже полностью восстановлен. Я увидел в документации W3sper для Dusk очень жёсткое напоминание: не следует напрямую использовать новый сгенерированный Profile для построения перевода, потому что у него нет записей Bookkeeper, которые появляются после синхронизации; из‑за этого он не сможет получить необходимые балансы и nonce. W3sper очень чётко прописывает границу: клиент, который сам подписывает, должен не только хранить восстанавливаемые ключи, но и поддерживать состояние активов, которое уже было синхронизировано — включая nonce публичного аккаунта и shielded notes. Этот нюанс разделяет «у меня есть приватный ключ» и «я могу безопасно потратить эти деньги» на две разные вещи.
Обычно давление возникает после восстановления. Если приложение очищает локальные данные и заново создаёт идентичность, а на странице всё ещё отображается прежний аккаунт, пользователь естественно решит, что всё уже вернулось; однако пока синхронизация ещё не завершена, перевод не может корректно собраться. Активы никуда не исчезли, но пользователя сначала «затыкает» проблема, которая выглядит как отсутствие баланса или сбой сети. Если разработчик сделает только восстановление ключей и не покажет восстановление состояния, то стоимость проверки и устранения проблем он переложит на пользователей и поддержку. Это не изъян протокола $DUSK ; напротив, это показывает, что «потрачиваемое состояние» shielded‑активов нельзя заменить одним адресным строковым представлением. @Dusk экосистеме нужно разделять отображение «идентичность найдена» и «состояние средств синхронизировано», и до завершения последнего пункта явно блокировать переводы. #dusk