Monedas, saldos y cuentas: por qué «cuánto tengo» tiene tres respuestas distintas
Abre un monedero que admita varias cadenas y, si te fijas bien, notarás algo raro. El saldo de Bitcoin y el de Ethereum son ambos meros números en una pantalla, pero por debajo se calculan de maneras completamente distintas; y en Solana hay todavía un tercer arreglo.
Esto no es una curiosidad. Explica por qué las comisiones de Bitcoin dependen de tu historial de transacciones, por qué una transacción de Ethereum puede fallar y aun así costarte dinero, y por qué una cuenta de Solana no puede simplemente vaciarse hasta cero.
El modelo UTXO: posees monedas, no un saldo
Bitcoin no tiene cuentas y no almacena saldos. Lo que almacena es un conjunto de salidas de transacción no gastadas —UTXO—, cada una de las cuales es un trozo discreto de valor bloqueado a alguna condición de gasto.
Piensa en dinero en efectivo. No tienes «47 euros» en el bolsillo; tienes un billete de 20, dos de 10, uno de 5 y dos monedas de 1. Para pagar 23 entregas el de 20 y el de 5 y te devuelven 2. No puedes partir un billete por la mitad.
Los UTXO funcionan exactamente así. Cada uno debe gastarse entero. Para pagar 0,3 BTC desde una salida de 1 BTC, tu monedero consume el BTC completo y crea dos salidas nuevas: 0,3 para el destinatario y unos 0,7 de vuelta para ti como cambio. El UTXO de 1 BTC deja de existir.
Tu «saldo» es, por tanto, una cifra derivada: tu monedero recorre la cadena buscando salidas bloqueadas a condiciones que puedes satisfacer, y las suma. En ningún lugar de la cadena de Bitcoin hay un registro que diga que tienes una cantidad concreta.
De ahí se siguen tres consecuencias, y las tres son prácticas:
Las comisiones dependen de tu historial, no solo del importe. Se cobran por byte, y cada entrada que gastas añade bytes. Pagar 50 euros desde un único UTXO grande sale barato; pagar esos mismos 50 combinando treinta diminutos sale caro, porque la transacción es físicamente mayor. Por eso vale la pena consolidar UTXO cuando las comisiones están bajas.
El cambio es una salida real que tiene que ir a alguna parte. Todos los monederos lo gestionan automáticamente, pero es el mecanismo que hay detrás de las heurísticas de dirección de cambio que usan los analistas de cadena para enlazar tus direcciones entre sí.
El gasto es naturalmente paralelo. Distintos UTXO son independientes, así que nada obliga a tus transacciones a seguir un orden estricto.
Bitcoin, Litecoin, Dogecoin, Bitcoin Cash, Zcash, Ravencoin y Flux funcionan todos así. Es el modelo más antiguo, y aquel en el que «si no son tus claves, no son tus monedas» resulta más literalmente cierto: no hay cuenta, solo monedas con condiciones adosadas.
El modelo de cuentas: posees un saldo, y un contador
Ethereum descartó todo eso y usó algo más parecido al libro mayor de un banco. La cadena guarda un estado: un enorme mapa de direcciones a saldos (y, para los contratos, a datos almacenados). Enviar 0,3 ETH resta 0,3 de un número y lo suma a otro. Sin entradas, sin salidas, sin cambio.
Eso es más sencillo, y es lo que hace prácticos los contratos inteligentes: un contrato necesita almacenamiento persistente que pueda leer y escribir, algo incómodo cuando el mundo está hecho de monedas discretas.
Pero el modelo de cuentas introduce un problema que los UTXO no tienen. Si una transacción es solo «resta 0,3 a Alicia», cualquiera que la vea podría retransmitirla una y otra vez y vaciarle la cuenta. La solución es el nonce: un contador por cuenta, incluido en cada transacción, que debe incrementarse exactamente en uno. La transacción número 7 solo puede minarse después de la 6, y solo una vez.
El nonce es la razón de que las cadenas EVM se comporten como lo hacen:
Tus transacciones van estrictamente ordenadas. Una transacción atascada bloquea todas las posteriores de la misma dirección, porque no pueden procesarse fuera de secuencia.
Las comisiones se pagan incluso cuando una transacción falla. El gas paga el cómputo intentado, no el cómputo logrado. Una llamada a contrato revertida igualmente consumió el trabajo de los validadores, así que igualmente cuesta. Esto sorprende a la gente constantemente, y es una diferencia real con el mundo UTXO, donde una transacción inválida sencillamente nunca confirma y no cuesta nada.
La gestión de nonces es infraestructura de verdad. Para un monedero normal esto es invisible. Para una multifirma en la que dos dispositivos deben ponerse de acuerdo antes de difundir, el nonce hay que reservarlo, seguirlo y liberarlo; por eso el manejo de nonces es un tema recurrente en la firma con dos dispositivos y no un detalle de implementación.
Ethereum, Polygon, BSC, Avalanche, Base y XDC usan todos este modelo.
Solana: cuentas que pagan alquiler
Solana también está basada en cuentas, pero con un giro que pilla desprevenida a la gente.
En Solana, prácticamente todo es una cuenta: tu monedero, cada token que tienes, los datos de cada programa. Y como esas cuentas ocupan memoria de los validadores, deben mantener un saldo mínimo para seguir vivas. Eso es la exención de alquiler: deposita lo suficiente y la cuenta persiste indefinidamente; baja de ahí y puede ser reclamada.
El efecto práctico es que tener un token SPL exige una cuenta de token aparte, financiada con una pequeña cantidad de SOL, antes de que nadie pueda enviarte ese token siquiera. Recibir no es gratis. Es algo inusual y conviene entenderlo antes de necesitarlo, porque «te mandé los tokens y no llegó nada» a menudo es solo una cuenta de token que falta.
Por qué un monedero multicadena tiene que modelar los tres
Un monedero que admita estas cadenas no puede compartir una única noción interna de «saldo». Necesita:
- Para cadenas UTXO: un conjunto de salidas, cada una con importe y script, más una lógica de selección de monedas que decida cuáles gastar.
- Para cadenas EVM: una única cifra de saldo más un nonce, y una cola que respete el orden.
- Para Solana: un saldo, un conjunto de cuentas de token asociadas y conciencia de los mínimos de alquiler.
La arquitectura de seguridad también tiene que adaptarse. En cadenas UTXO, el 2 de 2 de SSP es un script: una salida P2WSH que exige dos firmas para desbloquearse, impuesta por las propias reglas de scripting de la cadena. En cadenas EVM no hay un sistema de scripts equivalente para cuentas ordinarias, así que la multifirma se implementa mediante abstracción de cuentas: una cuenta de contrato inteligente cuya lógica de validación exige ambas firmas. En Solana es una dirección derivada de programa, controlada por un programa en cadena.
Tres mecanismos completamente distintos, una sola idea de cara al usuario: nada se mueve sin los dos dispositivos. Que las implementaciones subyacentes no se parezcan en nada es justamente la razón por la que la garantía debe reestablecerse, y volver a auditarse, en cada cadena en lugar de darse por heredada.
Qué significa esto para ti
Cuando las comisiones de Bitcoin parezcan altas para un pago pequeño, mira tus entradas. Importa menos el importe que en cuántos pedazos está hecho.
Cuando una transacción de Ethereum se atasque, las posteriores de esa misma dirección quedan atrapadas detrás. Eso es el nonce, no un fallo. Arreglar la primera desbloquea la cola.
Cuando una transacción EVM fallida te cobre igualmente, el modelo está funcionando según su diseño. La simulación ayuda a evitarlo, y por eso simular antes de firmar resulta más valioso en cadenas basadas en cuentas que en las UTXO.
Cuando una transferencia de tokens de Solana «desaparezca», busca una cuenta de token. No se ha perdido nada; puede que el destino aún no existiera.
Ninguna de estas cosas es una rareza de un monedero concreto. Son consecuencias de una decisión de diseño que cada cadena tomó hace años y, en cuanto ves en qué modelo estás, un montón de comportamientos por lo demás desconcertantes se vuelven predecibles.
