---
title: "Firma de cartera"
description: "Una firma de cartera prueba que una clave o cuenta de contrato aprobó datos exactos bajo reglas de verificación concretas. Distingue mensajes, transacciones, permisos, repetición y phishing."
image: "https://wiki.fcontext.com/og.png"
---
> Documentation Index
> Fetch the complete documentation index at: https://wiki.fcontext.com/llms.txt
> Use this file to discover all available pages before exploring further.
# Firma de cartera
> Solo con fines educativos; no es asesoramiento de inversión ni de seguridad. Una solicitud de firma maliciosa puede causar pérdidas irreversibles.
## Respuesta directa
Una firma de cartera es evidencia criptográfica de que una clave privada, o la política de una cuenta inteligente, aprobó un mensaje codificado concreto. La verificación identifica la cuenta firmante para esos bytes y esas reglas; no demuestra la identidad legal, la comprensión del firmante ni que un sitio haya descrito la acción con honestidad.
Firmar no es una acción uniforme. La firma de una transacción autoriza directamente una operación de red. Un mensaje fuera de cadena puede ser un reto de inicio de sesión sin autoridad sobre activos, o una orden, un permiso de tokens, una instrucción de gobernanza u otra autorización que un relayer presente después. Que no haya aviso de gas no elimina el riesgo.
Antes de firmar, identifica el tipo de solicitud, la acción legible, el dominio o verificador previsto, la cadena, el contrato verificador, las direcciones, los importes, el nonce y el vencimiento. Rechaza hashes sin explicación, bytes ilegibles, campos inesperados o solicitudes que la cartera no muestre con detalle suficiente.
## Cómo funciona
1. La aplicación codifica una transacción, un mensaje simple o datos tipados. Un cambio mínimo en los datos produce otro resumen.
2. La cartera muestra lo que puede decodificar y pide aprobación. La clave privada permanece en la cartera o dispositivo; se firma el resumen y se devuelve la firma.
3. El verificador reconstruye el mismo resumen. Para una cuenta externa suele recuperar o comprobar la dirección; una cuenta de contrato puede aplicar su política vigente mediante ERC-1271.
4. El verificador interpreta el resultado según las reglas de la aplicación. Un servidor puede crear una sesión; un contrato puede consumir un permit, ejecutar una orden, cambiar la gobernanza u otra llamada autorizada.
5. La protección contra repetición depende de la aplicación. EIP-712 aporta codificación tipada y separación de dominios, pero no evita repeticiones; la aplicación debe imponer nonce, deadline, verificador previsto, cadena u otro límite de un solo uso.
ERC-191 separa los datos firmados de la codificación de transacciones Ethereum y define formatos como `personal_sign`. EIP-712 vincula campos estructurados a un dominio que puede incluir `name`, `version`, `chainId` y `verifyingContract`. Los mensajes ERC-4361 añaden dominio, URI, ID de cadena, nonce y hora de emisión, pero el servicio también debe validarlos.
## Ejemplo
Leah visita el servicio oficial y recibe un inicio de sesión ERC-4361 con el dominio y URI esperados, un nonce nuevo y marcas de tiempo breves. Solo solicita autenticación. Tras comprobar dominio y cuenta, firma; el servidor valida el mensaje y crea una sesión. Ese mensaje no crea por sí mismo una allowance ni una transacción en cadena.
En un sitio imitador, el botón aún dice «Iniciar sesión», pero la cartera muestra datos EIP-712 `Permit` con token, spender, importe, nonce y deadline. La firma puede permitir que un relayer cree autoridad de gasto según el contrato del token. Leah debe rechazarla: el texto del botón no altera los bytes firmados.
## Riesgos y controles
- **Significado engañoso:** una página puede llamar inicio de sesión a un permit o una orden. Confía en la carga decodificada y el contrato verificado, no en el botón.
- **Firma ciega:** hashes y bytes opacos impiden revisar. Cancela si no puedes reproducir el mensaje exacto y su ruta de ejecución con una herramienta fiable.
- **Dominio incorrecto:** una marca conocida no autentica `chainId`, `verifyingContract`, dominio web ni URI. Comprueba cada campo y la dirección completa por separado.
- **Repetición o ejecución tardía:** quien obtenga una firma válida puede usarla hasta consumir el nonce o vencer el deadline. Usa nonces nuevos y plazos cortos; no publiques firmas.
- **Autoridad amplia:** permits, órdenes, claves de sesión y operaciones de cuentas inteligentes pueden habilitar acciones posteriores sin otra alerta. Verifica activo, spender, destinatario, importe, alcance y cancelación.
- **Firmante comprometido:** una cartera física protege contra la extracción de claves, no contra mensajes maliciosos. Si se expuso la frase semilla o clave privada, trata toda la cuenta como comprometida.
Si firmaste algo sospechoso, conserva la carga decodificada y la firma sin publicarlas, desconecta el sitio e identifica el esquema exacto. Para una aprobación o transacción en cadena, verifica el estado en la cadena correcta y usa la revocación, invalidación de nonce o migración documentada. No existe una revocación universal para firmas fuera de cadena y desconectar el sitio no las invalida.
## Errores comunes
- **«Toda firma mueve fondos».** Muchas solo autentican o expresan intención; otras autorizan una acción capaz de mover fondos más tarde.
- **«Sin gas no hay peligro».** Un relayer puede pagar el gas y presentar un permit, una orden u otra autorización firmada.
- **«EIP-712 garantiza seguridad».** Mejora la presentación y separación de dominios; no evita repeticiones ni valida lo que afirma la aplicación.
- **«La dirección recuperada prueba consentimiento informado».** Vincula datos exactos con una clave bajo una regla, no prueba identidad legal, comprensión ni libertad.
- **«Las firmas de cartera de contrato funcionan como las normales».** La validez ERC-1271 puede depender del estado y política actuales; el verificador debe consultar el contrato.
## Temas relacionados
- [Firma tipada EIP-712](/es/crypto/eip712-typed-signature/)
- [Aprobación de cartera](/es/crypto/wallet-approval/)
- [Riesgo de firma Permit2](/es/crypto/permit2-signature-risk/)
- [Simulación de transacciones](/es/crypto/transaction-simulation/)
- [Estafa de phishing](/es/crypto/phishing-scam/)
## Fuentes
- [ERC-191: Signed Data Standard](https://eips.ethereum.org/EIPS/eip-191) - Ethereum Improvement Proposals (consultado: 2026-08-22)
- [EIP-712: Typed structured data hashing and signing](https://eips.ethereum.org/EIPS/eip-712) - Ethereum Improvement Proposals (consultado: 2026-08-22)
- [ERC-1271: Standard Signature Validation Method for Contracts](https://eips.ethereum.org/EIPS/eip-1271) - Ethereum Improvement Proposals (consultado: 2026-08-22)
- [ERC-2612: Permit Extension for EIP-20 Signed Approvals](https://eips.ethereum.org/EIPS/eip-2612) - Ethereum Improvement Proposals (consultado: 2026-08-22)
- [ERC-4361: Sign-In with Ethereum](https://eips.ethereum.org/EIPS/eip-4361) - Ethereum Improvement Proposals (consultado: 2026-08-22)
Source: https://wiki.fcontext.com/es/crypto/wallet-signature/index.mdx