Qué revisar antes de conectar una billetera a una dapp
Una guía práctica para revisar el dominio, los permisos y el contexto.
Este artículo puede contener enlaces de afiliados. Las relaciones comerciales se detallan en la política de afiliados.
Conectar una billetera no es un paso administrativo: es el momento en que una aplicación obtiene la posibilidad de pedirte firmas. Hasta ese momento, nada se ha movido. Desde ese momento, cada pantalla que aceptes forma parte de una sesión, y cada firma que tengas a la vista puede implicar dinero. La pregunta útil no es si la aplicación es popular, sino qué información puede leer de tu cuenta y qué acción concreta te está pidiendo en este momento.
La dificultad mayor es que la pantalla de conexión y la pantalla de firma parecen del mismo tipo, cuando no lo son. La primera abre una ventana de lectura sobre tus direcciones y saldos. La segunda es una acción que se ejecuta en la red.
La ventana de conexión no es una autorización
Cuando una aplicación solicitará conexión, lo que normalmente obtiene es acceso de lectura: ver tus direcciones públicas, tus saldos y, según el navegador, tu historial. Esa capacidad por sí sola no mueve fondos.
El riesgo aparece porque la conexión crea un canal. Una aplicación a la que leíste saldos puede pedirte después una firma concreta, y esa petición aparecerá con el mismo aspecto que la ventana que ya aceptaste. La secuencia de dos pantallas refuerza la confusión: la primera se acepta con un clic, la segunda se acepta con el mismo clic.
Por eso conviene separar las dos acciones. Conectar es leer. Firmar es actuar. Ninguna de las dos es gratuita: la segunda cuesta comisión de red, y esa comisión se paga incluso si la transacción falla.
Los cuatro datos que debes leer antes de firmar
Una pantalla de firma o de aprobación muestra una cantidad pequeña de datos, y los cuatro se pueden comprobar:
El contrato que recibe el permiso es la dirección que lo obtiene. Debe ser una dirección del protocolo que hayas confirmado por separado, no una que solo aparece dentro de la página que te la pide.
El activo es a qué token se aplica el permiso. Una aprobación sobre una moneda estable y una aprobación sobre una versión envuelta o traspasada del mismo activo son permisos distintos, y muchos incidentes ocurren sobre el activo más fácil de mover de los dos que posees.
El límite es el techo. Si el número es mayor que tu saldo completo, esa es una decisión deliberada de la interfaz, no un valor por defecto que puedas ignorar. La recomendación de seguridad publicada por Ethereum es directa: no concedas límites de gasto ilimitados, porque un gasto ilimitado podría permitir que el contrato vacíe tu billetera.
La red decide a quién afecta. Una aprobación en la red principal y la misma aprobación en una red secundaria son permisos separados, y revocar una no anula la otra.
La diferencia entre aprobar y transferir
Es la confusión más común y la más costosa. Una transferencia mueve tokens de tu cuenta a un destinatario en ese momento. Una aprobación escribe un límite en el contrato y no mueve nada.
La consecuencia práctica es que una aprobación parece inocua: no sale dinero, no hay destinatario que lo reciba y el saldo no cambia. El riesgo queda hacia adelante, en una transacción que alguien más inicia más tarde. Esa es exactamente la forma que toman las estafas conairdrops: la página de reclamo pide “aprobar” una transacción, y esa aprobación entrega las claves privadas o el límite de gasto.
El dominio se comprueba aparte
Ninguno de los cuatro datos se puede verificar desde dentro de la interfaz que pide la firma. La dirección del contrato no significa nada si no sabes qué dominio la generó, y el mecanismo de suplantación más común es la vista previa de enlaces: el texto muestra un dominio legítimo y el clic lleva a otro sitio.
Por eso la revisión no se separa del lugar de origen. Una aprobación correcta para un protocolo legítimo, firmada en una copia de su interfaz, es la forma más habitual de este incidente y la más difícil de detectar después.
Anotar la transacción en el momento
Lo que determina si puedes reaccionar a tiempo es lo que haces justo después de firmar. Anota el hash de la transacción, la red, el contrato o destinatario, el activo y el límite, en un lugar que no sea la propia billetera.
Una transacción documentada se puede nombrar con precisión cuando algo no cuadra. Sin ese registro, tienes que reconstruir la sesión de memoria, y para entonces ya se ha ido el tiempo útil.
Lo que esta revisión no cubre
Leer la pantalla no te dice qué hará el contrato después con el permiso. Una aprobación razonable puede entregarse a un contrato cuya lógica no puedes verificar desde la interfaz, y ese contrato puede usar el límite de una forma que no tenías prevista.
Tampoco te dice si el protocolo es solvente o ha sido auditado. El riesgo de permiso y el riesgo del protocolo son preguntas distintas, y confundirlas hace que un protocolo conocido parezca que vuelve seguro cualquier contrato.
Lecturas relacionadas
- Diferencia entre aprobación de token y transferencia
- Cómo revisar los permisos de una aplicación descentralizada
- Cómo verificar un contrato de token antes de usarlo