En las DApps basadas en EVM, a menudo aparecen cuatro acciones una tras otra: conectar una billetera, firmar un mensaje, firmar una transacción y otorgar permiso para usar tokens criptográficos. Estas acciones no proporcionan el mismo acceso. Una conexión crea un canal de comunicación entre una cuenta y un sitio web. La firma del mensaje demuestra identidad o expresa intención. La firma de transacciones crea una transacción que se puede transmitir. Un permiso ficha permite que una parte aprobada (Spender) utilizar activos dentro de límites definidos. Un monto cero o la ausencia de una tarifa de red (Gas) no hace que una solicitud sea segura; comprender cada solicitud antes de confirmarla.

Distinción importante: Un permiso ficha es un estado de permiso, no un cuarto tipo de firma paralela a las tres primeras acciones. Una transacción cadena de bloques puede ejecutar la función aprobación (approve) para crear o cambiar el permiso. Alternativamente, un mensaje de permiso firmado (Permit) se puede enviar más tarde. La firma por sí sola no cambia el cadena de bloques; el permiso se puede registrar solo después de que el mensaje firmado se envíe correctamente.

Una conexión de billetera normalmente utiliza la interfaz de conexión de billetera (Provider). Una solicitud de conexión estándar no le otorga al sitio web un clave privada o frase semilla, y no firma ni transfiere activos automáticamente. Sin embargo, el sitio web puede recibir la dirección pública y la red seleccionada por el usuario y puede enviar solicitudes posteriores a la billetera. Una vez que el sitio web conoce una dirección pública, puede continuar consultando el historial público cadena de bloques de esa dirección después de que finalice la conexión. Deténgase inmediatamente y verifique el punto de entrada oficial si algún sitio web solicita un frase semilla o clave privada.

La firma de mensajes se usa comúnmente para iniciar sesión, aceptación de términos, órdenes fuera de cadena, votaciones o datos estructurados definidos por EIP-712. Normalmente no registra datos en el cadena de bloques y el firmante normalmente no paga una tarifa de red (Gas). Sin embargo, no pagar una tarifa no significa que la solicitud esté libre de riesgo patrimonial. Cuando la billetera muestre información legible, revise cada campo mostrado. Verifique el dominio, el identificador de red (Chain ID), el campo de dirección del contrato (verifyingContract), la parte aprobada (Spender), el importe y el tiempo de vencimiento. Si la billetera muestra solo datos sin procesar o contenido hexadecimal que no comprende, deténgase. No continuar con la solicitud. Ver ¿Qué es la estafa de transacciones de importe cero con datos hexadecimales?.

La firma crea una transacción firmada; no cambia el estado de cadena de bloques por sí solo. El saldo de una cuenta, el estado del contrato o el permiso cambian solo después de que la transacción se transmite, se incluye en un bloque y se ejecuta exitosamente. Es posible que una transacción firmada no se envíe a la red. También podría reemplazarse, caducar o fallar durante la ejecución. Si la interfaz muestra 0 ETH, solo significa que la transacción no incluye directamente ETH. El usuario aún puede pagar una tarifa de red (Gas), y la operación del contrato aún puede crear un permiso, transferir tokens criptográficos o cambiar otro estado de cadena de bloques.

Una operación de permiso firmada (Permit) normalmente crea un mensaje que se puede enviar más tarde. La creación de la firma no cambia la cantidad de permiso en el cadena de bloques. El mensaje firmado debe enviarse correctamente. En ese momento, su valor de secuencia (nonce), el tiempo de vencimiento y otras condiciones de validación aún deben ser válidos. Sólo entonces se podrá registrar el permiso en el cadena de bloques. Una vez que el permiso entre en vigor, la parte aprobada (Spender) puede luego usar el permiso dentro de sus reglas, monto aprobado y saldo de cuenta. Para conocer los riesgos de Permisos de larga duración, consulte ¿Qué es Unlimited Approval?.

Un intercambio cripto-ficha (Swap) puede requerir solo dos acciones: conectar la billetera y firmar una transacción. En otros casos, el DApp puede solicitar primero una acción independiente. Por ejemplo, puede pedirle al usuario que firme un mensaje iniciar sesión. Puede pedirle al usuario que firme una transacción cadena de bloques que ejecuta la función aprobación (approve). O puede pedirle al usuario que firme un mensaje de permiso (Permit). Si la cuenta ya otorga suficientes permisos de gasto, el DApp normalmente no solicita un nuevo permiso. Un intercambio que utiliza el activo nativo de la red en lugar de un ERC-20 ficha normalmente no requiere un permiso de gasto ERC-20. No juzgues la seguridad por el número de pasos; revise cada mensaje como una solicitud separada.

Desconectar el sitio web de la billetera solo finaliza la conexión local. No cambia un permiso ya registrado en el cadena de bloques. Para saber dónde se almacenan los Permisos, cuánto tiempo siguen siendo válidos y cómo funciona la revocación, consulte ¿Desconectar una DApp revoca los permisos existentes?.

Para obtener una lista de verificación más completa, consulte ¿Qué debo comprobar antes de confirmar una transacción en una billetera de hardware?. Para obtener información legible sobre transacciones y riesgos phishing, consulte ¿Cómo protegen SignGuard y Clear Signing contra el phishing en Web3?.

Principio clave: Un billetera de hardware puede proteger las claves de firma, pero no puede decidir si un sitio web, mensaje, transacción o permiso coincide con la verdadera intención del usuario.