You send a transaction, it confirms, and your wallet still shows the old balance. Refresh, it appears. Refresh again, it's gone. Nothing broke. You just hit a different replica that hadn't caught up yet. Rialo published a guide on consistency models that explains exactly this, and the explanation is more useful than most wallet UX advice. Distributed systems replicate data across servers, and those servers receive updates at different moments. A read landing on a lagging replica returns an older committed state. Correct behavior under most consistency models, deeply confusing to look at. The fix has a name: read my writes. Once a client commits a write within a session, every subsequent read in that session reflects it. You always see your own transaction even when other users don't yet. Paired with monotonic reads, your view only moves forward, so a balance never regresses mid session. @RialoHQ's documentation names this as something wallets should implement at the application layer, and separately maps which model suits which part of a chain. Strong consistency for finality checkpoints. Consistent prefix for block ordering during sync. Bounded staleness for light clients. Most chains leave consistency undocumented and let developers discover it through bug reports. Writing down which guarantee applies where is unglamorous work that saves somebody a week chasing a problem that was never a bug.