Por qué algunas blockchains ocultan lo que firmas

Cuando apruebas una transacción cripto en una billetera de hardware, haces una de dos cosas: o lees un resumen claro en español de lo que está por suceder, o firmas una pared de código hexadecimal esperando lo mejor. La firma ciega es el acto de aprobar una transacción digital sin poder verificar todos sus detalles en un formato legible para humanos.
 

En febrero de 2025, la firma ciega contribuyó al $1.5 billion Bybit hack, el mayor robo de criptoactivos en la historia. Los atacantes no rompieron ninguna criptografía. Aprovecharon el hecho de que los firmantes humanos no podían distinguir entre una transferencia rutinaria y una actualización maliciosa de contrato.
 

Que tu billetera pueda mostrarte un resumen claro y legible antes de firmar no depende de la calidad del software, sino de cómo fue diseñada cada blockchain a nivel de protocolo. Algunas cadenas fueron creadas para que las transacciones se describan a sí mismas. Otras ocultan detalles críticos en bloques binarios que requieren información externa para descifrarse. Este artículo explica cómo esas decisiones de diseño se reflejan en las principales blockchains y qué implican para tu seguridad.

El marco de los tres niveles

La firma clara es un proceso de seguridad que te permite verificar todos los detalles de una transacción digital en un formato legible en pantalla segura antes de aprobarla. 

En 13 de los principales ecosistemas blockchain, el soporte para firma clara se divide en tres niveles distintos según la arquitectura del protocolo. No se trata de cuáles cadenas son buenas o malas, sino de decisiones de diseño tomadas hace años, muchas veces antes de comprender plenamente sus implicaciones de seguridad.

Nivel 1: diseñado para la transparencia

Estas blockchains dejan claro que la firma es una consecuencia natural de su diseño. ¿Por qué? Utilizan un conjunto finito de estructuras de transacción tipadas, donde cada campo tiene un nombre, un tipo y un esquema definido. Una billetera de hardware no necesita información externa para interpretarlas: la transacción misma te dice qué es.

El XRP Ledger ofrece quizá el caso más claro y robusto de firma transparente entre las grandes cadenas. Su formato binario incluye un campo TransactionType que permite un análisis determinista entre más de 50 tipos de transacción: Payment, OfferCreate, TrustSet, EscrowCreate y más. Cada campo tiene un esquema definido. Una billetera de hardware puede mostrar destinatario, monto, tarifa, memo y cualquier parámetro específico sin necesidad de buscar nada externamente. Cerca del 100 % de las transacciones actuales en mainnet pueden firmarse de forma totalmente transparente.

Polkadot desarrolló la solución de firma clara técnicamente más avanzada de la industria mediante su sistema de metadatos en tiempo de ejecución (MetadataV14/V15). Cada transacción referencia índices de pallet y de llamada, y los metadatos indican exactamente qué significan esos índices y cómo decodificar los argumentos. El reto es que los metadatos completos superan los 200 KB, demasiado para billeteras de hardware con memoria limitada. 

La solución, RFC-0078 (Merkleized Metadata), construye un árbol criptográfico a partir de los metadatos, transmite solo el subconjunto relevante y verifica la prueba de inclusión en la cadena. El resultado es una sola aplicación de Ledger que funciona en todos los parachains de Polkadot sin actualizaciones por cadena.
 

Cosmos utiliza una arquitectura de mensajes tipados y el estándar SIGN_MODE_TEXTUAL (ADR-050), introducido en Cosmos SDK v0.50, que muestra las transacciones en pantallas legibles para humanos y adaptadas a pantallas pequeñas. Los montos de monedas se muestran como "2 ATOM" en vez de "2000000uatom". NEAR Protocol lleva la legibilidad aún más lejos con nombres de cuenta legibles como "alice.near" y argumentos de función serializados en JSON que la billetera puede mostrar como texto plano.
 

Nivel 2: funciona para lo básico, falla en lo complejo

Seis ecosistemas ofrecen firma clara sólida para operaciones nativas, pero se degradan notablemente cuando entran en juego los contratos inteligentes. Bitcoin es el caso ilustrativo. El modelo UTXO implica que las transacciones sin procesar no contienen los montos de entrada; una billetera de hardware no puede calcular la tarifa sin información adicional sobre las salidas previas. PSBT (BIP 174) resuelve esto para pagos estándar, cubriendo aproximadamente el 90 % de las transacciones típicas, pero los gastos vía Taproot script-path y configuraciones multisig complejas aún generan opacidad.
 

Stellar muestra la división del nivel 2 de forma clara. Sus 26 tipos de operación clásica (Payment, ManageSellOffer, ChangeTrust) tienen esquemas fijos y se muestran perfectamente en billeteras de hardware. Pero los contratos inteligentes Soroban, lanzados en 2024, reintroducen la opacidad estilo EVM: los parámetros llegan como tipos binarios codificados que requieren conocimiento específico del contrato para ser interpretados, reduciendo la cobertura de aproximadamente 95 % para operaciones clásicas a casi cero para interacciones Soroban crudas. Algorand, Cardano, Aptos y Tezos siguen patrones similares: buena cobertura en operaciones nativas, grandes vacíos en lógica programable compleja.
 

Nivel 3: la opacidad está en el ADN

Tres ecosistemas tienen decisiones arquitectónicas que hacen que la firma clara sea una batalla cuesta arriba, sin importar cuán bueno sea el software de la billetera. Entender esto explica por qué las advertencias sobre firma ciega aparecen en casi todas las interfaces DeFi.
 

Ethereum y todas las cadenas compatibles con EVM comparten el mismo problema central: la codificación ABI no se describe a sí misma. Al interactuar con un contrato inteligente, el campo de datos de la transacción contiene un selector de función de 4 bytes (los primeros cuatro bytes del hash del nombre de la función), seguido de parámetros codificados en bloques de 32 bytes. Sin el JSON del ABI del contrato, esto es ruido hexadecimal puro. Ese ABI no se almacena en la cadena. Una billetera de hardware no puede saber que 0xa9059cbb... significa "transferir 1,000 USDC a 0xABC..." a menos que tenga metadatos externos. 
Los contratos proxy, que redirigen la ejecución a contratos de implementación cuyas direcciones pueden cambiar, agravan el problema, que es exactamente como se ejecutó el Bybit hack.
 

La respuesta de la industria es ERC-7730, un estándar de metadatos creado en 2024 que proporciona archivos JSON para decodificar e interpretar interacciones específicas con contratos. Funciona, pero requiere que alguien escriba y mantenga esos metadatos para cada contrato con el que puedas interactuar. Es, en esencia, un parche aplicado a una arquitectura que no fue diseñada para la transparencia.
 

Solana es aún más desafiante. Las instrucciones de transacción contienen un ID de programa y un arreglo de bytes opaco con datos de instrucción sin un ABI estandarizado; cada programa define su propio formato de serialización. El framework Anchor ofrece un enfoque semiestándar usando discriminadores de 8 bytes, pero muchos programas no usan Anchor ni publican sus definiciones de interfaz. Para interacciones DeFi, la mayoría del volumen de transacciones en Solana requiere firma ciega. 

TON añade más complejidad con ejecución asíncrona: solo firmas el mensaje inicial, y todo lo que sucede después en bloques subsiguientes es invisible al momento de firmar.

 Conclusiones

La lección más práctica: conoce en qué nivel se encuentra tu cadena antes de usar una billetera de hardware para DeFi. En cadenas de Nivel 1, la firma clara funciona como debe. En el Nivel 2, las transferencias simples son seguras de firmar, pero deberías investigar cualquier interacción compleja con contratos inteligentes. En el Nivel 3, trata cada transacción en un protocolo DeFi con escepticismo adicional y verifica si la combinación de dApp y billetera soporta metadatos ERC-7730 antes de aprobar algo importante.
 

Los fabricantes de billeteras de hardware están trabajando activamente en esto. El Generic Parser de Ledger lee archivos de metadatos ERC-7730 y muestra los detalles de la transacción en la pantalla segura. 

El enfoque de Metadatos Merkleizados de Polkadot es probablemente la solución más elegante de la industria: sin confianza, verificado criptográficamente y nativo del protocolo. El sector avanza hacia mejores estándares, pero las limitaciones de protocolo de las cadenas de Nivel 3 no desaparecerán.
 

La regla más simple: si tu billetera te muestra un hash o una secuencia de bytes hexadecimales y te pide firmar, considéralo una señal de alerta.

Recursos y lecturas recomendadas

Los siguientes recursos ofrecen información técnica sobre los protocolos y estándares tratados en este artículo.