¿Qué es el ERC-7730? Explicación del estándar de firma «Clear Signing» en Ethereum

Quicknode

19 de mayo de 2026 — 5 minutos de lectura

Compartir

Añadir como fuente preferida

ERC-7730 es el primer intento normativo de resolver un problema de 2.000 millones de dólares.

Y el problema radica, en esencia, en la base misma del dinero criptográfico: la firma de transacciones. Hablemos de cifras:

• Bybit sufrió un ataque informático por valor de unos 1.46B $ debido a una manipulación de la interfaz de firma.

• Los ataques de phishing contra el Ledger Connect Kit han supuesto un coste de 600 000 dólares.

• Radiant Capital sufrió unas pérdidas de unos 50 millones de dólares debido a la manipulación de datos de transacciones.

Todo lo anterior pone de manifiesto la misma vulnerabilidad: los usuarios aprueban lo que muestra el monedero, mientras que la cadena ejecuta datos de llamada o firmas opacas.

A esto se le denomina «firma a ciegas». En pocas palabras, las personas tienen la capacidad de autorizar y aprobar datos de transacciones en forma de códigos de bytes que no pueden leer.

ERC-7730 es el primer intento coordinado de Ethereum para cambiar la firma de las transacciones, pasando de «confiar en la interfaz» a «verificar la intención».

En este blog se explica en detalle qué son la firma clara y el estándar ERC-7730, cómo funcionan y qué implicaciones tienen para el ecosistema de las criptomonedas en su conjunto.

¿Qué es Clear Signing?

Clear Signing permite que los monederos muestren la intención y los detalles de forma legible para el usuario antes de que este firme la transacción, sustituyendo así la «firma a ciegas» del bytecode sin procesar.

En lugar de mostrar datos de llamada sin procesar, hash o un mensaje genérico del tipo «Firma el mensaje», la cartera debería explicar la acción en un lenguaje sencillo:

• enviar USDC,

• aprobar a un usuario,

• intercambiar fichas,

• activos de puente, o

• transferir la titularidad del contrato.

ERC-7730 es el estándar de Ethereum para llevar esto a cabo de forma coherente.

Este estándar permite a los equipos de contratos inteligentes publicar descriptores que indican a las carteras cómo descodificar y mostrar interacciones específicas con los contratos.

Recuerda que una firma clara no garantiza automáticamente la seguridad de las transacciones. Lo que hace es que los datos y la intención de la transacción sean legibles, lo que ayuda a los usuarios a verificar lo que están firmando.

Vale. Ahora bien, ¿cómo funcionan el ERC-7730 y la firma «clear»?

Cómo funciona el ERC-7730

El preámbulo de esta norma de Ethereum reza : «Lo que ves es lo que firmas».

Para que esto sea posible, el estándar ERC-7730 utiliza descriptores de transacción. Se trata de archivos JSON estructurados que asocian las funciones de los contratos inteligentes a mensajes de firma legibles para las personas.

Un descriptor indica al monedero:

• a qué contrato y cadena se aplica

• ¿qué función se está llamando?

• ¿Qué parámetros son importantes?

• cómo deben mostrarse esos parámetros

• qué mensaje final debería ver el usuario antes de firmar

En lugar de mostrar un archivo sin procesar aprobar(dirección, uint256) Al llamar a la función, las carteras que utilicen el descriptor ERC-7730 pueden mostrar: Aprobar que {spender} gaste {amount} {token}

Veamos cómo funciona esto en la práctica.

La anatomía de un descriptor ERC-7730

Un descriptor ERC-7730 es un archivo JSON que indica a los monederos cómo convertir las llamadas a contratos en mensajes de firma legibles.

Consta de tres secciones principales:

Contexto

En la sección «Contexto» se explica cuándo debe utilizar la cartera un descriptor. Este vincula el archivo a una o varias implementaciones de contratos, normalmente mediante el «chainId» y la dirección.

Cuando un usuario firma una transacción, el monedero comprueba si el contrato de destino y la red coinciden con un descriptor conocido.

Metadatos

La sección de metadatos aporta contexto adicional. Puede incluir el propietario del protocolo, la URL del proyecto, el nombre del contrato, los detalles del token, las constantes, las enumeraciones o los valores de reserva.

Esto ayuda a que las carteras muestren los valores de forma más clara, en lugar de mostrar direcciones sin formato, números enteros o parámetros sin explicar.

Pantalla

La sección de visualización se encarga del trabajo de traducción propiamente dicho. En su interior formatos de visualización, cada clave es una firma de función ABI legible para el usuario, como por ejemplo:

swapExactTokensForTokens(
  uint256 amountIn,
  uint256 amountOutMin,
  address[] path,
  address to,
  uint256 deadline
)

Para cada función, el descriptor define una intención, una opción opcional interpolatedIntent, y una lista de los campos que debe mostrar el monedero.

Cada campo apunta a un valor de «calldata» descodificado mediante rutas como #.amountIn, #.to, o #.fecha límite, y a continuación indica al monedero cómo formatearlo.

Por ejemplo:

{
  "path": "#.amountIn",
  "label": "Send",
  "format": "tokenAmount",
  "params": {
    "tokenPath": "#.path[0]"
  }
}

Esto le indica a la cartera:

• toma el importeEn parámetro,

• asignarle la etiqueta «Enviar»,

• dar formato a esa cantidad como una cantidad simbólica, y

• uso path[0] para identificar qué token proporciona el símbolo bursátil y los decimales.

Recuerda que la transacción se ejecuta igual en la cadena de bloques. El estándar ERC-7730 solo ofrece a los monederos una forma estandarizada de explicar lo que el usuario está a punto de firmar.

Sin embargo, la visualización es solo una parte de la seguridad de la firma. A continuación explicamos por qué el estándar ERC-7730 sigue siendo una solución incompleta.

Lo que el ERC-7730 no resuelve

El estándar ERC-7730 es importante, pero es fácil exagerar sus funciones. Precisamente por eso es importante comprender las limitaciones que se describen en esta sección.

Que sea legible no significa que esté verificado. Un descriptor puede indicar «Autorizar al usuario a utilizar USDC», pero el estándar ERC-7730 no garantiza que el descriptor sea exacto, completo o veraz.

Incluso unas indicaciones claras pueden dar lugar a una acción indebida. Es posible que la cartera muestre la transacción correctamente, pero que el usuario apruebe un contrato malicioso, una autorización insegura o una interfaz de usuario comprometida flow. Una cartera puede mostrar la transacción con precisión, pero el usuario puede seguir aprobando un contrato malicioso, una autorización excesiva o una interacción arriesgada con el protocolo.

Los descriptores pueden quedar desfasados con respecto a los contratos. Si se actualiza un proxy, cambia el comportamiento de un enrutador o varía el significado de una función, es posible que un descriptor antiguo siga mostrando un mensaje de comando correcto.

Los descriptores tienen dificultades con las rutas de ejecución complejas. Las llamadas por lotes, las llamadas delegadas, los enrutadores y los datos de llamada anidados pueden hacer que una transacción realice más operaciones de las que sugiere la función visible.

Además, para que la firma clara funcione de forma fiable y sea eficaz, depende en gran medida de los siguientes factores clave:

• registros de confianza,

• simulación de transacciones,

• comprobaciones de metadatos, y

• advertencias de riesgo a nivel de cartera.

Por eso es importante volver a insistir en esta limitación: el estándar ERC-7730 hace que las transacciones sean más fáciles de entender, pero no garantiza automáticamente que sean seguras a la hora de firmarlas.

ERC-7730: ¿Qué nos depara el futuro?

El estándar ERC-7730 ya está operativo en el nivel de registro, y Ledger es, a día de hoy, la implementación en producción más clara. Sin embargo, el ámbito de aplicación de la firma clara es aún más amplio.

A medida que la abstracción de cuentas vaya madurando, los usuarios firmarán menos transacciones puntuales y concederán más permisos con alcance limitado:

• límites de gasto,

• claves de sesión,

• contratos aprobados,

• acciones delegadas, y

• pólizas recurrentes.

Esto hace que la intención de la transacción sea aún más importante.

Una cartera inteligente no puede hacer cumplir las normas adecuadas si no es capaz de comprender claramente qué significa una acción.

Lo mismo se aplica a la IA Agentes y la ejecución autónoma.

Si Agentes van a iniciar permutas, pagos, reequilibrios o ejecuciones de contratos en nombre de los usuarios, necesitan algo más que datos de ejecución sin procesar.

Necesitan una capa semántica que puedan leer los monederos, los motores de políticas, los simuladores y, en última instancia, otros Agentes.

El estándar ERC-7730 supone un primer paso en esa dirección.

Comienza con la firma legible para las personas, pero su valor a largo plazo podría residir en la intención legible para las máquinas: una forma común para que los monederos, las aplicaciones y Agentes entender qué es lo que se está autorizando antes de que se produzca la ejecución.