Qué hace una billetera cuando firmas y qué queda registrado
Firmar no es entrar en una cuenta. Explicamos qué se autoriza, qué queda guardado y cómo revisar tus permisos después.
Este artículo puede contener enlaces de afiliados. Las relaciones comerciales se detallan en la política de afiliados.
Firmar no es iniciar sesión
Cuando una aplicación pide conexión, no te está pidiendo un usuario y una contraseña. Está pidiendo que tu billetera firme un mensaje que autoriza direcciones concretas y, con frecuencia, límites de gasto. La interfaz lo muestra como una lista de líneas legibles, pero esas líneas se generan a partir de la solicitud real que tu billetera va a aprobar.
La consecuencia práctica es importante: alguien que cree que está iniciando sesión en un sitio web aprobará un permiso sin leerlo, y ese permiso sobrevive a la sesión del navegador.
Los cuatro elementos de toda solicitud
Primera elemento: el dominio que solicita acceso. Ese sitio debería coincidir con la dirección que tú mismo abriste, y no con una que llegó por un enlace, un anuncio o un mensaje.
Segundo elemento: las cuentas ofrecidas. Puede que aparezcan varias direcciones tuyas. Si la tarea solo necesita una, mostrar más de la necesaria amplía la superficie que luego tendrás que revisar.
Tercero elemento: el acceso a redes. Si el sitio necesita leer posiciones en más de una cadena, pedirá acceso a cada una. Cada red adicional es un permiso más que gestionar después.
Cuarto elemento, y el que casi nadie lee: la aprobación de gasto. Leer saldos y gastar son permisos distintos. Una interfaz de intercambio necesitará una allowance; un panel de consulta normalmente no.
Cómo leer la solicitud antes de aprobar
Fíjate en el dominio contra la barra de direcciones, no contra el texto de la solicitud, porque ese texto lo escribe el sitio que la envía y puede estar redactado para parecer tranquilizador. Lee el token y el límite de cada línea de gasto, y anota si el límite es una cantidad concreta, un porcentaje o ilimitado. Ilimitado no significa que la aplicación vaya a vaciar la cuenta, pero sí que nadie te está protegiendo de un error en su propio código.
Qué hacer si un permiso no debía haberse aprobado
Revocar es posible y no es difícil, pero prevenir es más sencillo que deshacer. Si ya aprobaste algo que no correspondía, la secuencia práctica es: usa el gestor de permisos de tu billetera para revocar la allowance, trata cualquier hash de transacción de esa sesión como sospechoso hasta comprobarlo en un explorador de bloques, y cambia de cuenta solo si hubo una firma que no reconoces.
Si la aplicación es una interfaz conocida y revocaste a mitad de sesión, ábrela de nuevo en una sesión nueva en lugar de reconectar dentro de la anterior. La pestaña antigua puede conservar un token que acabas de invalidar.
Dónde encontrar la fuente oficial
La documentación de la billetera es la respuesta autoritativa a la pregunta “qué estoy firmando”. Los artículos de centros de ayuda y los blogs quedan desactualizados justo donde los permisos cambiaron. Cuando ambas fuentes se contradigan, gana la documentación actual de la billetera, porque es el código que se ejecutará.
Comprueba que la red que vas a usar coincide con la que aparece en la solicitud. Una solicitud que menciona la red principal de Ethereum no es una solicitud para una red de pruebas.
Lo que este artículo no afirma
No afirma que una interfaz concreta sea insegura, ni que las aprobaciones sean la causa principal de las pérdidas. No indica qué límites son seguros, porque eso depende del diseño de la aplicación y del tamaño de la operación.
Este material es educativo y no constituye asesoramiento financiero, legal, fiscal ni de seguridad. El comportamiento de las billeteras y los textos de las interfaces cambian; revisa la documentación vigente.