Envías una transacción, se confirma y tu monedero aún muestra el saldo anterior. Actualizas, aparece. Vuelves a actualizar, se va. Nada se rompió. Simplemente accediste a una réplica diferente que aún no se había actualizado. Rialo publicó una guía sobre modelos de consistencia que explica exactamente esto, y la explicación es más útil que la mayoría de los consejos de UX de monederos. Los sistemas distribuidos replican datos entre servidores, y esos servidores reciben actualizaciones en momentos distintos. Una lectura que cae en una réplica retrasada devuelve un estado comprometido anterior. Comportamiento correcto bajo la mayoría de los modelos de consistencia, pero profundamente confuso al observarlo. La solución tiene un nombre: read my writes. Una vez que un cliente compromete una escritura dentro de una sesión, cada lectura posterior en esa sesión refleja dicha escritura. Siempre ves tu propia transacción, incluso cuando otros usuarios aún no la ven. Combinado con lecturas monotónicas, tu vista solo avanza, por lo que tu saldo nunca retrocede durante una sesión. La documentación de @RialoHQ señala que esto debe implementarse en la capa de aplicación de los monederos, y además mapea qué modelo conviene para cada parte de una cadena: consistencia fuerte para puntos de control de finalidad; prefijo consistente para el ordenamiento de bloques durante la sincronización; antigüedad acotada para clientes ligeros. La mayoría de las cadenas no documentan la consistencia y dejan que los desarrolladores la descubran a través de informes de errores. Escribir qué garantía aplica en cada lugar es un trabajo poco glamoroso que le ahorra a alguien una semana persiguiendo un problema que nunca fue un error.