Hardware Wallet vs Cold Wallet: custodia de claves, límites de firma y verificación

Respuesta directa y alcance

Una hardware wallet es un dispositivo físico dedicado que almacena claves privadas y firma transacciones internamente, de modo que el material de la clave está diseñado para nunca salir del dispositivo. Una cold wallet es una wallet cuyas claves privadas se mantienen offline y no son accesibles desde una máquina conectada a internet durante el funcionamiento normal. La diferencia práctica es que hardware wallet describe una clase de dispositivo, mientras que cold wallet describe una postura de seguridad y un modelo de ubicación de claves.

Este artículo cubre el modelo de custodia, el límite de firma, el procedimiento de verificación y las ventajas y desventajas operativas. No recomienda un proveedor o modelo específico. Para elegir endpoints y redes que conecten tu flujo de firma a una cadena, utiliza los recursos del RPC Assistant enlazados abajo en lugar de tratar esta página como una lista de proveedores.

• Hardware wallet: dispositivo físico, almacenamiento interno de claves, firma en el dispositivo.
• Cold wallet: custodia offline de claves, ya sea en hardware, papel o una máquina aislada de la red.
• Hot wallet: claves presentes en un entorno conectado a internet, normalmente software.
• El solapamiento: la mayoría de las cold wallets de consumo son hardware wallets, pero no todas las hardware wallets se operan en frío.

Supuestos y requisitos previos

Los procedimientos siguientes asumen que tienes un dispositivo de firma hardware, un ordenador anfitrión, una red de prueba o una cuenta de bajo valor, y una forma de difundir transacciones firmadas. Deberías sentirte cómodo manejando frases semilla, derivación de direcciones y leyendo una transacción antes de firmarla.

Usa una testnet o una cuenta desechable para cada paso hasta que hayas verificado el flujo completo. Nunca pegues una frase semilla de producción en un shell, una consola del navegador o una variable de entorno visible para otros procesos. Los ejemplos de código usan marcadores como RPC_URL y PRIVATE_KEY; reemplázalos solo en un entorno controlado.

• Una hardware wallet con pantalla y botón de confirmación.
• Una máquina anfitriona con una app complementaria o CLI de wallet.
• Un endpoint RPC para la red objetivo, proporcionado por tu infraestructura o proveedor.
• Un saldo de prueba pequeño en una testnet o una cuenta dedicada de bajo valor.

Modelo mental: ubicación de claves, límite de firma y exposición

Piensa en una wallet como tres capas: generación y almacenamiento de claves, construcción de transacciones y firma. En una hot wallet, las tres capas pueden ejecutarse en la misma máquina conectada a internet. En una hardware wallet, la construcción ocurre en el anfitrión pero la firma ocurre dentro del dispositivo. En una cold wallet, la capa de firma está aislada de la red por completo, y las transacciones se mueven entre los entornos online y offline mediante un archivo, un código QR o una transferencia manual.

La propiedad de seguridad que importa no es la etiqueta en la caja sino dónde existe la clave privada y qué puede alcanzarla. Una hardware wallet que está permanentemente conectada a una extensión del navegador y aprueba llamadas arbitrarias a contratos sigue siendo una hardware wallet, pero su exposición operativa se acerca más a una hot wallet. Una cold wallet que firma en una máquina aislada de la red y difunde desde un anfitrión online separado tiene una superficie de ataque más estrecha, a costa de la comodidad.

• Ubicación de la clave: elemento seguro del dispositivo, máquina offline, papel o keystore de software.
• Límite de firma: qué ruta de código puede producir una firma sin confirmación humana.
• Exposición: qué procesos conectados a la red pueden solicitar firmas o leer direcciones.
• Recuperación: si la semilla o el respaldo pueden restaurar las mismas direcciones en otro dispositivo.

Comprobación ejecutable: verificar el límite de firma con una llamada RPC

Antes de confiar en cualquier configuración de wallet, verifica que tu anfitrión puede leer el estado de la cadena y preparar una transacción sin ver nunca la clave privada. El siguiente comando curl consulta el saldo de una cuenta a través de un endpoint RPC. Es una comprobación de solo lectura y no requiere una clave.

Ejecútalo primero contra una testnet. Una respuesta exitosa confirma que tu endpoint es accesible y que tu anfitrión puede construir solicitudes. No confirma que la firma esté aislada; eso requiere el paso de confirmación en el dispositivo que se describe a continuación.

• Resultado esperado: un objeto JSON con un campo result que contiene un saldo hexadecimal.
• Si el resultado es 0x0, la dirección puede ser válida pero no tener fondos en esa red.
• Si recibes un error, revisa la URL del endpoint, la red y la suma de verificación de la dirección antes de cambiar cualquier otra cosa.

curl -s -X POST "$RPC_URL" \
  -H "Content-Type: application/json" \
  -d '{
    "jsonrpc": "2.0",
    "id": 1,
    "method": "eth_getBalance",
    "params": ["0xYourAddressHere", "latest"]
  }'

Comprobación ejecutable: preparar una transacción y confirmar la firma en el dispositivo

El siguiente paso es preparar una transacción sin firmar en el anfitrión y confirmar que la firma se produce solo tras la aprobación física en el dispositivo. El ejemplo de JavaScript a continuación usa un proveedor y una clave privada de marcador de posición para ilustrar la forma del flujo. En un flujo real de hardware wallet, la llamada de firma se delega al puente del dispositivo o a la app complementaria, y la clave privada nunca aparece en el script.

Usa este patrón para probar el límite: construye la transacción, solicita una firma y observa si el dispositivo muestra el destino y el importe antes de la aprobación. Si el anfitrión puede firmar sin interacción con el dispositivo, la clave no está aislada.

• Resultado esperado: un objeto de transacción sin firmar impreso en la consola.
• En un flujo de hardware wallet, el siguiente paso es pasar este objeto al puente del dispositivo, no firmarlo localmente.
• Si el script firma localmente, estás probando una hot wallet, no un límite de firma aislado.

const { ethers } = require("ethers");

async function prepareTransaction() {
  const provider = new ethers.JsonRpcProvider(process.env.RPC_URL);
  const wallet = new ethers.Wallet(process.env.PRIVATE_KEY, provider);

  const tx = {
    to: "0xRecipientAddressHere",
    value: ethers.parseEther("0.001"),
    gasLimit: 21000n,
    chainId: Number(process.env.CHAIN_ID)
  };

  const populated = await wallet.populateTransaction(tx);
  console.log("Unsigned transaction:", populated);
  return populated;
}

prepareTransaction().catch(console.error);

Tabla de resultados: qué registrar durante la verificación

No confíes en la memoria ni en las afirmaciones del proveedor. Registra las siguientes observaciones para cada configuración de wallet que pruebes. La tabla siguiente es una plantilla; complétala con tus propias mediciones en lugar de copiar números de cualquier artículo.

Las dos últimas filas están intencionalmente en blanco. Mídelas tú mismo con un cronómetro y una transacción de prueba controlada. Informa la red, el modelo del dispositivo, la versión del firmware y el sistema operativo del anfitrión junto con tus números para que el resultado sea reproducible.

Solución de problemas comunes

La mayoría de los fallos de wallet se engloban en unas pocas categorías: conectividad, discrepancia de derivación, desajuste de firmware o app, y error del usuario en el paso de confirmación. Recórrelas en ese orden antes de asumir que el dispositivo está defectuoso.

Si el dispositivo no se detecta, revisa el cable, la versión de la app complementaria y si otra aplicación ha reclamado el dispositivo. Si las direcciones no coinciden después de la recuperación, verifica la ruta de derivación y la configuración de la passphrase; una passphrase diferente produce una wallet diferente. Si una transacción se rechaza en el dispositivo, compara el destino y el importe mostrados con la transacción sin firmar en el anfitrión.

• Dispositivo no detectado: prueba otro cable y puerto, reinicia la app complementaria y cierra el software de wallet que compita.
• Discrepancia de dirección: confirma la ruta de derivación y cualquier passphrase antes de restaurar fondos.
• Transacción rechazada: revisa el destino, el importe, el límite de gas y el chain ID en la pantalla del dispositivo.
• Fallo de difusión: verifica el endpoint RPC y la red; una transacción firmada puede difundirse más tarde desde un anfitrión diferente.
• Interacción inesperada con un contrato: detente y decodifica los datos de la llamada antes de aprobar.

Limitaciones y ventajas y desventajas

La custodia en frío reduce la superficie de ataque online pero aumenta la fricción operativa. Cada transacción requiere una transferencia entre entornos online y offline, y esa transferencia es en sí misma un lugar donde ocurren errores. Las hardware wallets reducen la exposición de claves pero no eliminan el phishing, las aprobaciones maliciosas de contratos ni el riesgo de la cadena de suministro.

Ninguno de los dos modelos protege contra un respaldo de semilla comprometido, un dispositivo perdido sin un plan de recuperación, o un usuario que aprueba una transacción sin leerla. La configuración más sólida suele ser por niveles: una hot wallet para saldos operativos pequeños, una hardware wallet para firma activa y una cold wallet para tenencias a largo plazo que rara vez se mueven.

• Comodidad frente a aislamiento: la firma en frío es más lenta y más fácil de equivocar.
• Disciplina de recuperación: prueba la restauración antes de necesitarla.
• Riesgo de contrato: una hardware wallet aún puede firmar una aprobación maliciosa si no la decodificas.
• Cadena de suministro: compra a una fuente reputada y verifica el firmware.

Conectar wallets a redes sin debilitar la custodia

Tu límite de firma es solo una parte del sistema. El endpoint RPC que usas para leer el estado y difundir transacciones es otra. Un endpoint comprometido o poco fiable puede darte un estado incorrecto o no difundir una transacción válida, incluso cuando tus claves están perfectamente aisladas.

Para orientación sobre endpoints específicos de red, empieza con la guía de endpoints RPC multicadena y la guía de endpoints RPC. Si estás eligiendo un proveedor para una cadena concreta, las páginas del RPC Assistant para API RPC de Ethereum y proveedor RPC de Solana cubren opciones concretas. Para infraestructura dedicada, revisa nodos dedicados y precios de RPC.

• Usa un endpoint de solo lectura para comprobaciones de saldo y nonce.
• Difunde transacciones firmadas desde un anfitrión que nunca tenga la clave.
• Mantén endpoints separados para testnet y mainnet para evitar errores de chain ID.
• Revisa las redes compatibles antes de asumir que una cadena está disponible.

Próximos pasos

Ejecuta las dos comprobaciones anteriores en una testnet, completa la tabla de resultados con tus propias mediciones y solo entonces mueve una pequeña cantidad a la configuración que pretendes usar. Si estás construyendo una aplicación que integra la firma de wallets, revisa la documentación del servicio API y la guía de alojamiento de nodos blockchain para alinear tu backend con tu modelo de custodia.

Para seleccionar endpoints por red y carga de trabajo, usa el RPC Assistant en lugar de una lista genérica. El endpoint adecuado depende de tu cadena, requisitos de latencia y si necesitas datos de archivo o rendimiento dedicado.

• Prueba la recuperación en un segundo dispositivo antes de confiar en el respaldo.
• Documenta la ruta de derivación, la política de passphrase y la versión del firmware.
• Vuelve a ejecutar la tabla de verificación después de cada actualización de firmware o app.
• Separa los saldos calientes, tibios y fríos por propósito y valor.