Ipinapadala mo ang isang transaksyon, kumikinabang ito, ngunit ang iyong wallet ay nagpapakita pa rin ng lumang balanse. I-refresh mo, lumalabas ito. I-refresh muli, nawawala ito. Wala namang nasira. Basta lang, napadpad ka sa isang iba’t ibang replica na hindi pa nakarehistro. Ipinakilala ni Rialo ang isang gabay tungkol sa mga modelong pangkonsistensya na naglilinaw nang eksakto sa ganitong sitwasyon, at mas kapaki-pakinabang ang paliwanag nito kaysa sa karamihan sa mga payo sa UX ng wallet. Ang mga distributed system ay nagrereplica ng data sa iba’t ibang server, at ang mga server na ito ay natatanggap ang mga update sa iba’t ibang oras. Ang isang pagbasa na tumutok sa isang naghihintay na replica ay babalik sa isang mas lumang komitadong estado. Ito ay tamang pag-uugali sa ilalim ng karamihan sa mga modelong pangkonsistensya, ngunit lubos na nakakalito kapag tingnan. Ang solusyon ay may pangalan: read my writes. Pagkatapos mag-commit ng isang write ang isang client sa loob ng isang session, ang bawat susunod na pagbasa sa session na iyon ay magpapakita nito. Laging nakikita mo ang iyong sariling transaksyon kahit na hindi pa nakikita ng iba. Kasama nito ang monotonic reads, ang iyong pananaw ay tanging umaabot pataas, kaya’t hindi babalik ang balanse sa gitna ng session. Inilalarawan ng dokumentasyon ni @RialoHQ ang ganitong bagay bilang isang dapat i-implement sa application layer ng wallet, at hiwalay na inilalarawan kung anong model ang angkop sa bawat bahagi ng chain. Strong consistency para sa mga checkpoint ng finality. Consistent prefix para sa block ordering habang nagsisync. Bounded staleness para sa light clients. Ang karamihan sa mga chain ay hindi inilalathala ang konsistensya at pinapahintulutan ang mga developer na matuklasan ito sa pamamagitan ng mga ulat ng bug. Ang pagsulat kung anong garantiya ang umiiral saan ay isang hindi nakakaakit na gawain na nagliligtas sa isang tao ng isang linggo sa paghahanap ng isang problema na hindi talaga isang bug.