Вы отправляете транзакцию, она подтверждается, но ваш кошелек всё ещё показывает старый баланс. Обновляете — баланс появляется. Обновляете снова — он исчезает. Ничего не сломалось: вы просто попали на другую реплику, которая ещё не успела обновиться. Rialo опубликовала руководство по моделям согласованности, которое именно это и объясняет — и это объяснение полезнее большинства советов по UX кошельков. Распределённые системы реплицируют данные между серверами, и эти серверы получают обновления в разное время. Чтение, попавшее на отстающую реплику, возвращает более раннее зафиксированное состояние. Это корректное поведение при большинстве моделей согласованности, но выглядит крайне запутывающе. Решение имеет название: read my writes. После того как клиент зафиксировал запись в рамках сессии, все последующие чтения в этой же сессии должны отражать эту запись. Вы всегда видите свою собственную транзакцию, даже если другие пользователи её ещё не видят. В сочетании с монотонными чтениями ваша перспектива движется только вперёд, поэтому баланс не может вернуться назад в пределах одной сессии. Документация @RialoHQ указывает, что это следует реализовывать на уровне приложения кошельков, а также отдельно сопоставляет, какая модель подходит для какой части цепочки: строгая согласованность для контрольных точек финализации; согласованность префикса для упорядочивания блоков при синхронизации; ограниченная устарелость для лёгких клиентов. Большинство цепочек не документируют согласованность, оставляя разработчикам открывать её через отчёты об ошибках. Запись того, какие гарантии применяются где, — неприметная работа, которая экономит кому-то неделю поисков проблемы, которая никогда не была багом.