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 cripto de la historia. Los atacantes no rompieron ninguna criptografía. Aprovecharon el hecho de que los firmantes humanos no podían distinguir una transferencia rutinaria de 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. Depende de cómo fue diseñada cada blockchain a nivel de protocolo. Algunas cadenas se crearon para que las transacciones se describan a sí mismas. Otras ocultan detalles críticos dentro de datos binarios que requieren información externa para ser descifrados. Este artículo explica cómo esas decisiones de diseño se reflejan en las principales blockchains y qué significa 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 una 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 qué cadenas son buenas o malas, sino de decisiones de diseño tomadas hace años, muchas veces antes de comprender plenamente las 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. La razón principal: 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 te dice exactamente qué es.

El XRP Ledger ofrece quizás el mejor ejemplo de firma clara entre las cadenas principales. Su formato binario incluye un campo TransactionType que permite un análisis determinista entre más de 50 tipos de transacciones: Payment, OfferCreate, TrustSet, EscrowCreate y más. Cada campo tiene un esquema definido. Una billetera de hardware puede mostrar destinatario, monto, comisión, memo y cada parámetro específico sin consultar nada externo. Cerca del 100 % de las transacciones actuales en mainnet pueden firmarse de forma completamente clara.

Polkadot desarrolló la solución técnicamente más avanzada de firma clara en la industria gracias a su sistema de metadatos en tiempo de ejecución (MetadataV14/V15). Cada transacción referencia índices de pallet y de llamada, y los metadatos te dicen exactamente qué significan y cómo decodificar los argumentos. El reto es que los metadatos completos superan los 200KB, 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 transacciones en pantallas legibles para humanos y adaptadas a dispositivos pequeños. Los montos de moneda se muestran como "2 ATOM" en vez de "2000000uatom". NEAR Protocol va aún más allá 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 bajo presión

Seis ecosistemas ofrecen firma clara sólida para sus operaciones nativas, pero pierden transparencia cuando se introducen contratos inteligentes. Bitcoin es el caso más ilustrativo. El modelo UTXO implica que las transacciones en bruto no contienen los montos de entrada; una billetera de hardware no puede calcular la comisión 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 con Taproot script-path y configuraciones multisig complejas siguen siendo opacos.
 

Stellar muestra claramente esta división de nivel 2. Sus 26 tipos de operaciones clásicas (Payment, ManageSellOffer, ChangeTrust) tienen esquemas fijos y se visualizan 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 descifrarse, reduciendo la cobertura de casi 95 % en operaciones clásicas a casi cero en interacciones Soroban en bruto. Algorand, Cardano, Aptos y Tezos siguen patrones similares: cobertura fuerte para operaciones nativas, pero grandes vacíos para lógica programable compleja.
 

Nivel 3: la opacidad está en el diseño

Tres ecosistemas tomaron decisiones arquitectónicas que hacen que la firma clara sea casi imposible, sin importar cuán bueno sea el software de la billetera. Entender esto ayuda a explicar por qué existen advertencias de firma ciega en casi todas las interfaces DeFi.
 

Ethereum y todas las cadenas compatibles con EVM comparten el mismo problema: la codificación ABI no se describe a sí misma. Cuando interactúas 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 archivo JSON del ABI del contrato, esto es solo ruido hexadecimal. Ese ABI no se almacena en la cadena. Una billetera de hardware no tiene forma de saber que 0xa9059cbb... significa "transferir 1,000 USDC a 0xABC..." a menos que cuente con metadatos externos. 
Los contratos proxy, que redirigen la ejecución a contratos de implementación cuyas direcciones pueden cambiar, agravan el problema, que fue exactamente como se ejecutó el hack de Bybit.
 

La respuesta de la industria es ERC-7730, un estándar de metadatos creado en 2024 que proporciona archivos JSON que describen cómo decodificar y mostrar interacciones específicas de 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 incluso 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 semi-está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 de Solana requiere firma ciega. 

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

 Conclusiones

El consejo más práctico: conoce en qué nivel está tu cadena antes de usar una billetera de hardware para DeFi. En cadenas de nivel 1, la firma clara funciona como debe. En nivel 2, las transferencias simples pueden firmarse con confianza, pero deberías investigar cualquier interacción compleja con contratos inteligentes. En nivel 3, trata cada transacción en un protocolo DeFi con escepticismo extra 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 detalles de la transacción en 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. La industria 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 profundidad técnica sobre los protocolos y estándares mencionados en este artículo.