---
title: "Firmas tipadas EIP-712: dominios, resúmenes y verificación segura"
description: "EIP-712 hace que los mensajes estructurados de Ethereum sean deterministas y legibles, pero firmar con seguridad exige verificar dominio, tipo, valor, nonce, plazo, ejecución y política del firmante."
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.
# Firmas tipadas EIP-712: dominios, resúmenes y verificación segura
> Solo con fines educativos; no constituye asesoramiento de inversión. Invertir puede ocasionar pérdidas.
## Respuesta directa
EIP-712 estandariza cómo las aplicaciones de Ethereum describen, resumen y solicitan firmas sobre datos estructurados tipados. Una solicitud contiene `types`, `primaryType`, `domain` y `message`; su resumen es `keccak256("\x19\x01" || domainSeparator || hashStruct(message))`. Así, la codificación es determinista y una cartera compatible puede mostrar los campos con más claridad que un hash opaco.
Pero **no** convierte el mensaje en verdadero, inocuo, revocable ni resistente a repeticiones. La aplicación debe vincular la autoridad con la cadena y el verificador correctos, definir cada campo sin ambigüedad, aplicar nonces y límites temporales, validar al firmante adecuado y restringir la ejecución. Una firma válida acredita la aprobación de un resumen exacto conforme a una regla de verificación; no acredita la identidad, el consentimiento informado ni la seguridad del sitio o del contrato.
## Cómo funciona
### 1. Identificar la acción y la ruta de verificación
Determine si la solicitud autoriza un inicio de sesión, una orden, un voto, una allowance de tokens, una transferencia, una llamada retransmitida u otra acción. Localice el código que reconstruye el resumen y consume la firma. Para una cuenta de propiedad externa suele recuperarse una dirección desde una firma ECDSA; para una cuenta de contrato puede ser necesario llamar a ERC-1271 `isValidSignature(hash, signature)` y comprobar su valor de éxito `0x1626ba7e`.
### 2. Fijar el dominio
Examine el tipo `EIP712Domain` exacto y sus valores. Los campos estándar son `name`, `version`, `chainId`, `verifyingContract` y `salt`, pero solo se resumen los incluidos. Confirme de forma independiente la cadena activa, el código desplegado y el verificador previsto; un nombre, símbolo, rótulo de proxy o dirección con checksum familiar no bastan. ERC-5267 `eip712Domain()` puede revelar el dominio, aunque su compatibilidad es opcional y aún deben revisarse proxies y actualizaciones.
### 3. Reconstruir el grafo de tipos
Parta de `primaryType`, conserve el orden de los miembros y reúna recursivamente las estructuras referenciadas. `encodeType` agrega sus definiciones ordenadas por nombre de tipo. EIP-712 admite enteros de ancho fijo, `address`, `bool`, de `bytes1` a `bytes32`, `bytes` y `string` dinámicos, matrices y estructuras; el estándar no define los alias `uint` e `int`, tipos de punto fijo ni valores cíclicos.
### 4. Decodificar cada valor y unidad
Relacione cada valor con su tipo declarado y significado en la aplicación. Verifique direcciones completas, unidades enteras sin formatear, signo, orden de matrices, destinatarios, spenders, activos, importes, comisiones, límites, destinos, hashes de calldata y cadenas legibles. Los `bytes` y `string` dinámicos se representan en `encodeData` mediante el hash Keccak-256 de su contenido; las matrices resumen las codificaciones concatenadas y las estructuras anidadas usan su propio `hashStruct`.
### 5. Recalcular el resumen de forma independiente
Calcule `typeHash = keccak256(encodeType(primaryType))` y después `hashStruct(message) = keccak256(typeHash || encodeData(message))`. Calcule igual el separador de dominio y combínelo con los bytes de versión ERC-191 `0x19 0x01`. Compare el resultado del frontend, la biblioteca de firma, el contrato verificador y una implementación independiente; un JSON de aspecto idéntico no demuestra una codificación tipada idéntica.
### 6. Auditar repetición, tiempo y ejecución
EIP-712 no incluye protección contra repeticiones. Confirme que el verificador comprueba al firmante previsto, consume o invalida el nonce correcto, aplica `deadline` o ventanas de validez, vincula todos los parámetros críticos y conserva el resultado previsto si un relayer o un atacante se adelanta. La separación de dominio solo evita colisiones entre los dominios realmente codificados; los campos ausentes o erróneos pueden permitir reutilización entre contratos o cadenas.
### 7. Firmar con alcance mínimo y conciliar el resultado
Rechace campos ocultos, tipos inexplicados, valores ilimitados, plazos lejanos, contratos desconocidos, identificadores de cadena distintos, pantallas de firma ciega o contexto de ejecución incompleto. Conserve el JSON tipado exacto y el resumen, use una cuenta de propósito limitado si es posible y revise transacción, recibo, eventos, saldos, allowances, nonces, estado de la orden y finalidad. Desconectar el sitio no revoca una firma utilizable ni una autoridad ya creada.
## Ejemplos calculados
### Ejemplo 1: Construcción del tipo y el resumen
Para `Order(address maker,address token,uint256 amount,uint256 nonce,uint256 deadline)`, `typeHash` es el hash Keccak-256 de esa cadena exacta, incluido el orden de campos. El hash del mensaje es `keccak256(typeHash || maker || token || amount || nonce || deadline)` y cada miembro codificado ocupa 32 bytes. El resumen final añade `0x1901`, el separador de dominio y el hash del mensaje; cambiar `amount` de `250000000` a `250000001` cambia el resumen e invalida la firma anterior.
### Ejemplo 2: Unidades y plazo
Un importe de `250 USDC` con seis decimales se codifica como `250000000`, no como `250`. Si la marca de tiempo actual es `1727000000` y el plazo `1727000900`, la ventana es `900 seconds = 15 minutes`. La visualización decimal de la cartera y el reloj local solo orientan; el verificador usa el entero sin formatear y su regla temporal en cadena.
### Ejemplo 3: Control de repetición
Una orden lleva el nonce `41` y un máximo de `5 ETH`. Tras marcar el nonce 41 como consumido, una segunda presentación debe fallar aunque la firma siga siendo criptográficamente válida. Si el contrato no consume el nonce ni hace idempotente la ejecución, la misma firma puede autorizar otros `5 ETH`; el separador de dominio no impide por sí solo esa repetición.
### Ejemplo 4: Validez de una cartera de contrato
Una cartera de contrato 2-de-3 aprueba un resumen con los firmantes A, B y C configurados. Las firmas de A y B pueden hacer que ERC-1271 devuelva hoy `0x1626ba7e`. Si una actualización sustituye B por D, los mismos bytes pueden dejar de ser válidos: ERC-1271 puede depender del estado, política, tiempo y llamadas externas actuales, y la mera recuperación de dirección no decide la validez de una cuenta de contrato.
## Riesgos
- `chainId` incorrecto o ausente
- `verifyingContract` falsificado o inesperado
- `name` o `version` de dominio engañosos
- Implementación proxy o dominio cambiado tras una actualización
- `primaryType` incorrecto o tipo sombra con rótulo parecido
- Orden de miembros, dependencias o codificador incompatible
- Dirección truncada, sustituida o etiquetada de forma engañosa
- Error de decimales o de entero con signo frente a sin signo
- Elemento de matriz, estructura anidada o carga `bytes` ocultos
- Importe ilimitado, alcance amplio o destinatario controlado por un atacante
- Nonce ausente, obsoleto, compartido o consumido incorrectamente
- Plazo ausente, lejano, desbordado o interpretado de forma ambigua
- Repetición entre cadenas, contratos, cuentas o acciones
- Retención, censura, front-running o redirección por el relayer
- Maleabilidad de firma o recuperación ECDSA demasiado permisiva
- Cambio de firmante, módulo, umbral, estado o código ERC-1271
- Error de renderizado, firma ciega o tipo no compatible en la cartera
- JSON del frontend distinto del resumen del verificador
- Revocación o cancelación que pierde una carrera de ordenación
- Confundir el resultado del aviso de firma con recibo, estado o finalidad
## Errores frecuentes
### Error 1: Las firmas EIP-712 son transacciones
Son mensajes firmados fuera de la cadena. Un relayer u otro actor puede presentarlos después a un contrato, y la transacción resultante puede gastar Gas y cambiar estado sin que la envíe el firmante.
### Error 2: Una vista estructurada significa que la solicitud es segura
Los campos tipados facilitan la inspección, pero esquemas, valores, contratos, rótulos, anidación oculta o renderizado incompleto maliciosos aún pueden engañar.
### Error 3: El separador de dominio impide toda repetición
Solo separa el dominio codificado. La repetición dentro de él necesita nonce, plazo, cancelación, contabilidad de ejecuciones o idempotencia; un campo de dominio omitido no aporta límite alguno.
### Error 4: Recuperar la dirección esperada demuestra la autorización
La recuperación demuestra una firma EOA sobre el resumen, no la semántica de la aplicación. Las cuentas de contrato requieren su política ERC-1271, no una recuperación ordinaria.
### Error 5: Cerrar la página o desconectar la cartera cancela la firma
Una firma copiada puede usarse hasta que el nonce, plazo, cancelación, estado o política del verificador la invalide. Compruebe el estado en cadena correspondiente, no el estado de la sesión.
## Temas relacionados
- [ID de cadena](/es/crypto/chain-id/)
- [Nonce y plazo de ERC-2612 Permit](/es/crypto/erc2612-permit-nonce-deadline/)
- [Riesgo de firma Permit2](/es/crypto/permit2-signature-risk/)
- [Autorización de cartera](/es/crypto/wallet-approval/)
- [Firma de cartera](/es/crypto/wallet-signature/)
## Fuentes
- [EIP-712: Typed structured data hashing and signing](https://eips.ethereum.org/EIPS/eip-712) - Ethereum Improvement Proposals (consultado: 2026-08-19)
- [ERC-191: Signed Data Standard](https://eips.ethereum.org/EIPS/eip-191) - Ethereum Improvement Proposals (consultado: 2026-08-19)
- [ERC-1271: Standard Signature Validation Method for Contracts](https://eips.ethereum.org/EIPS/eip-1271) - Ethereum Improvement Proposals (consultado: 2026-08-19)
- [ERC-2612: Permit Extension for EIP-20 Signed Approvals](https://eips.ethereum.org/EIPS/eip-2612) - Ethereum Improvement Proposals (consultado: 2026-08-19)
- [ERC-5267: Retrieval of EIP-712 domain](https://eips.ethereum.org/EIPS/eip-5267) - Ethereum Improvement Proposals (consultado: 2026-08-19)
- [EIP-2: Homestead Hard-fork Changes](https://eips.ethereum.org/EIPS/eip-2) - Ethereum Improvement Proposals (consultado: 2026-08-19)
- [Contract ABI Specification](https://docs.soliditylang.org/en/latest/abi-spec.html) - Solidity Documentation (consultado: 2026-08-19)
- [ERC-7730: Structured Data Clear Signing Format](https://eips.ethereum.org/EIPS/eip-7730) - Ethereum Improvement Proposals (consultado: 2026-08-19)
Source: https://wiki.fcontext.com/es/crypto/eip712-typed-signature/index.mdx