Você envia uma transação, ela é confirmada, mas sua carteira ainda mostra o saldo antigo. Ao atualizar, o novo saldo aparece. Ao atualizar novamente, ele some. Nada quebrou. Você simplesmente acessou uma réplica diferente que ainda não havia se atualizado. O Rialo publicou um guia sobre modelos de consistência que explica exatamente isso — e a explicação é mais útil do que a maioria das dicas de UX de carteiras. Sistemas distribuídos replicam dados entre servidores, e esses servidores recebem atualizações em momentos diferentes. Uma leitura em uma réplica atrasada retorna um estado comprometido mais antigo. Comportamento correto sob a maioria dos modelos de consistência, mas profundamente confuso ao visualizar. A solução tem um nome: read my writes (leia minhas escritas). Uma vez que um cliente compromete uma escrita em uma sessão, toda leitura subsequente nessa sessão reflete essa alteração. Você sempre vê sua própria transação, mesmo quando outros usuários ainda não a veem. Juntamente com leituras monotônicas, sua visão só avança, então o saldo nunca retrocede durante uma sessão. A documentação do @RialoHQ nomeia isso como algo que as carteiras devem implementar na camada de aplicação, e mapeia separadamente qual modelo se aplica a cada parte da cadeia: consistência forte para pontos de verificação de finalidade; prefixo consistente para ordenação de blocos durante a sincronização; obsolescência limitada para clientes leves. A maioria das cadeias não documenta a consistência e deixa os desenvolvedores descobrirem por meio de relatos de bugs. Escrever explicitamente qual garantia se aplica onde é um trabalho pouco glamoroso, mas que economiza semanas de busca por um problema que nunca foi um bug.