Autocustodia de Bitcoin: hardware wallets, entropía y el verdadero costo de ser tu propio banco

Durante años, una de las frases más repetidas dentro de Bitcoin ha sido “not your keys, not your coins”. La idea detrás de ella es sencilla y poderosa: si las claves privadas que controlan nuestros Bitcoin están en manos de un exchange, una empresa o cualquier otro intermediario, nuestra capacidad real de disponer de esos fondos depende de un tercero.

Estoy de acuerdo con esa premisa. Pero después de años siguiendo de cerca el desarrollo de Bitcoin, las wallets y la seguridad del ecosistema, creo que la conversación sobre autocustodia se ha quedado demasiado tiempo en una simplificación: comprar una hardware wallet, escribir 12 o 24 palabras y asumir que el problema está resuelto.

Y NO, NO LO ESTÁ.

La autocustodia es una de las mayores innovaciones prácticas que Bitcoin ofrece al individuo, pero también es una responsabilidad considerable. No consiste simplemente en sacar los fondos de un exchange. Consiste en asumir personalmente una cadena completa de riesgos que antes estaba parcialmente concentrada en un tercero.

Hay que entender cómo se generan las claves, de dónde procede la entropía, qué es realmente una seed phrase, cómo funciona la derivación de claves, qué protege una hardware wallet y qué no puede proteger, qué ocurre si el firmware contiene un error, qué sucede si el dispositivo es manipulado físicamente, cómo deben diseñarse los backups y qué pasará con los fondos si el propietario pierde la memoria, pierde la vida o simplemente olvida cómo construyó su propio sistema de seguridad.

Por eso mi posición es bastante clara: no creo que la autocustodia sea para cualquier persona desde el primer día, pero sí creo que cualquier persona puede aprender lo suficiente para llegar a practicarla correctamente.

Y esa diferencia es fundamental.

“La autocustodia no debería ser presentada como un producto que se compra. Debería entenderse como una habilidad que se aprende”. Felipe Jaramillo, CEO fundador de Criptoinforme.com

El gran error: pensar que la hardware wallet es la seguridad

Una hardware wallet es, en esencia, una herramienta para mantener y utilizar claves criptográficas de una manera mucho más aislada que un ordenador o un teléfono convencional. Su objetivo es reducir la exposición de los secretos que permiten firmar transacciones.

Pero hay una distinción que considero fundamental: una hardware wallet no almacena nuestros Bitcoin.

Los Bitcoin permanecen registrados en la blockchain. Lo que controla la wallet son las claves necesarias para autorizar determinadas operaciones sobre esos fondos. Una wallet jerárquico-determinista puede derivar una estructura completa de claves a partir de una única semilla, siguiendo estándares como BIP-32 y otros esquemas relacionados.

Esto significa que el dispositivo físico es, en cierta forma, reemplazable.

La información criptográfica que permite recuperar el control no lo es.

Por eso una hardware wallet puede romperse, perderse o dejar de fabricarse y, mientras el backup sea correcto y compatible, los fondos pueden seguir siendo recuperables.

Pero también funciona al revés: un dispositivo perfectamente conservado no sirve de mucho si la información fundamental fue generada incorrectamente, quedó expuesta o se perdió.

Esta distinción parece elemental, pero cambia completamente la forma en que deberíamos evaluar la seguridad.

La pregunta no debería ser solamente “¿qué hardware wallet es más segura?”.

Debería ser: ¿qué sistema completo de custodia estoy construyendo alrededor de mis claves?

La autocustodia no elimina el riesgo: lo mueve

Este es, probablemente, el punto central de todo el debate.

Cuando mantenemos nuestros fondos en un exchange, asumimos riesgo de contraparte. Dependemos de una organización para custodiar las claves, procesar retiros, mantener sus sistemas operativos y cumplir con sus obligaciones.

Cuando hacemos autocustodia, reducimos ese riesgo, pero asumimos otros.

Podemos perder la seed.

Podemos revelar la seed.

Podemos equivocarnos al crear un backup.

Podemos olvidar una passphrase.

Podemos utilizar un dispositivo comprometido.

Podemos instalar software malicioso.

Podemos firmar una transacción que no entendemos.

Podemos comprar un dispositivo de una fuente dudosa.

Podemos perder el acceso durante una emergencia.

Incluso podemos construir un sistema tan complejo que terminemos siendo nosotros mismos el principal punto débil.

Por eso me parece mucho más preciso decir que la autocustodia redistribuye el riesgo en lugar de eliminarlo.

Los acontecimientos de 2026 lo demostraron de una manera particularmente contundente.

La lección más importante de Coldcard: la seguridad comienza antes de la seed

El 30 de julio de 2026, Coinkite reveló una vulnerabilidad que afectaba a determinadas versiones del firmware de COLDCARD. El problema estaba relacionado con la generación de semillas: debido a un defecto de integración durante una migración de código iniciada en 2021, determinadas rutas podían utilizar un generador pseudoaleatorio de software en lugar del generador de números aleatorios por hardware previsto por el diseño.

Esto es especialmente importante porque el dispositivo no necesitaba estar conectado a Internet para que existiera el problema.

Tampoco era necesario que un atacante tomara el control remoto de la hardware wallet.

El problema estaba en cómo habían nacido determinadas semillas.

Investigaciones posteriores relacionaron el defecto con fondos robados de wallets creadas con las versiones afectadas. Trezor, citando investigaciones de Galaxy y otros equipos, situó una de las estimaciones en aproximadamente 1.367 BTC y unas 4.585 direcciones afectadas, aunque otras estimaciones del incidente fueron superiores.

Coinkite explicó posteriormente que los atacantes podían regenerar offline las claves correspondientes a las semillas debilitadas. Es decir, el ataque no consistía necesariamente en “hackear” la hardware wallet en tiempo real. El atacante podía atacar matemáticamente el espacio de posibilidades reducido por la generación defectuosa de aleatoriedad.

Para mí, esta es una de las historias de seguridad más importantes de Bitcoin en 2026.

Porque rompe una intuición muy extendida:

“Si mis claves nunca estuvieron conectadas a Internet, nadie puede robarlas”.

No necesariamente.

Si la clave nació mal, el problema existía antes de que comenzaras a utilizarla.

Entropía: la palabra que debería aparecer mucho más en las conversaciones sobre wallets

Aquí llegamos a uno de los conceptos técnicos que considero imprescindibles para entender la autocustodia: la entropía.

En criptografía, la seguridad de una clave depende en gran medida de que sea impredecible. No basta con que una secuencia parezca aleatoria para nuestros ojos. Tiene que existir suficiente incertidumbre para que un atacante no pueda reducir de manera práctica el espacio de búsqueda.

BIP-39 establece uno de los mecanismos más utilizados para convertir entropía generada por una máquina en una frase mnemónica que un ser humano pueda almacenar. El estándar contempla entropías de 128 a 256 bits. A esa entropía se añade un checksum y posteriormente los bits resultantes se dividen en grupos de 11 bits que se traducen a palabras de una lista de 2.048 términos.

Así aparecen las conocidas frases de 12, 15, 18, 21 o 24 palabras.

Una frase de 12 palabras BIP-39 normalmente representa 128 bits de entropía inicial.

Una frase de 24 palabras representa 256 bits.

Pero aquí existe una diferencia conceptual muy importante.

Las palabras no son la fuente original de seguridad.

Son una representación legible de la información aleatoria que generó la wallet.

Por eso BIP-39 no fue diseñado para que una persona invente una frase y el ordenador la convierta mágicamente en una semilla segura. El propio estándar explica que el objetivo es transportar aleatoriedad generada por ordenador de una forma que resulte manejable para seres humanos, y no convertir frases creadas por usuarios en semillas.

Esto también explica por qué una frase como: “Bitcoin is the future”

no se convierte en una seed segura simplemente porque un software sea capaz de transformarla en una clave.

La frase puede ser válida matemáticamente.

Eso no significa que sea segura.

128 bits no son “menos seguros” simplemente porque sean menos palabras

Existe otra confusión frecuente.

Una frase de 24 palabras no es automáticamente ocho veces más segura que una de 12 porque tenga el doble de palabras. La diferencia fundamental está en la entropía inicial.

Con 128 bits existen 2¹²⁸ posibilidades.

Con 256 bits existen 2²⁵⁶.

Ambos espacios son astronómicamente grandes cuando la entropía es realmente aleatoria.

El problema aparece cuando la fuente de aleatoriedad no es realmente aleatoria.

Ahí la cantidad de palabras deja de contar como pensamos.

Puedes tener una frase de 24 palabras y, si su generación estuvo comprometida, el espacio efectivo de búsqueda podría ser muchísimo menor de lo que aparenta.

Eso es exactamente lo que hace tan importante el incidente de Coldcard.

El problema no era que alguien hubiera descubierto una forma mágica de romper Bitcoin.

El problema era que determinadas semillas no tenían la impredecibilidad que los usuarios creían que tenían.

De la seed a millones de claves: BIP-32 y la arquitectura jerárquica

La seed phrase tampoco es simplemente una “contraseña de Bitcoin”.

En los sistemas HD —Hierarchical Deterministic— una semilla puede utilizarse para derivar una estructura jerárquica de claves. BIP-32 define precisamente un sistema para construir árboles de pares de claves a partir de una única semilla.

Esto es lo que permite que una sola seed pueda terminar controlando múltiples cuentas, direcciones y ramas de derivación.

El usuario ve una frase.

Debajo existe una estructura criptográfica mucho más compleja.

Esto tiene una consecuencia práctica enorme para la recuperación.

Si una persona pierde su hardware wallet pero conserva correctamente la semilla y conoce la configuración utilizada, puede recuperar el acceso a las claves derivadas.

Pero si utiliza una passphrase adicional, una ruta de derivación específica, una configuración multisig o una arquitectura poco convencional, recuperar una wallet deja de ser simplemente “introducir las 24 palabras”.

Por eso una de las mejores preguntas que podemos hacernos después de crear una wallet es: ¿Podría otra persona competente reconstruir mi sistema si yo no estuviera disponible?

Si la respuesta es no, quizá todavía no tenemos un sistema de custodia suficientemente maduro.

La seed phrase es probablemente el objeto más peligroso de toda la configuración

Existe una paradoja interesante.

Podemos comprar un dispositivo de cientos de dólares diseñado con componentes de seguridad especializados y después escribir el secreto que controla nuestros fondos en una hoja de papel.

La hoja de papel puede convertirse en el elemento más valioso de todo el sistema.

Una persona que obtiene la seed puede no necesitar la hardware wallet original.

Por eso la seed nunca debería almacenarse en un ordenador, teléfono, correo electrónico, servicio en la nube o aplicación de notas.

Tampoco debería fotografiarse.

No debería enviarse por WhatsApp.

No debería introducirse en una página web para “verificarla”.

Y nadie del fabricante debería pedirla.

El principio es sencillo: la seed debe permanecer fuera de sistemas conectados y fuera del alcance de terceros.

La propia industria insiste actualmente en esta regla básica: nunca introducir la frase de recuperación en un ordenador o smartphone y verificar siempre los datos críticos en el dispositivo cuando este disponga de una pantalla independiente.

Pero incluso aquí hay que ir un paso más allá.

La pregunta no es solamente dónde guardo la seed.

Es: ¿qué ocurrirá con ella dentro de diez, veinte o treinta años?

Backup: el dispositivo puede morir, el backup no debería

Una hardware wallet puede perderse.

Puede romperse.

Puede dejar de fabricarse.

Puede sufrir daños por agua.

Puede quedar inutilizada.

Eso no debería significar automáticamente la pérdida de los Bitcoin.

El backup existe precisamente para separar el patrimonio del dispositivo físico.

Pero un backup introduce un problema diferente: disponibilidad frente a confidencialidad.

Si existe una sola copia, podemos perderla.

Si existen veinte copias, aumentamos los puntos donde alguien podría encontrarla.

La seguridad consiste en encontrar un equilibrio.

Para patrimonios pequeños, una copia física correctamente almacenada puede ser suficiente.

Para patrimonios mayores, probablemente tiene sentido pensar en redundancia física, resistencia frente a incendios o inundaciones y separación geográfica.

Y para patrimonios significativamente mayores aparecen otras arquitecturas.

Por ejemplo, multisig.

Multisig: cuando una sola clave deja de tener sentido

Una configuración multisig puede requerir varias firmas para autorizar una transacción.

Un esquema 2-de-3, por ejemplo, puede tener tres claves independientes y requerir dos para gastar.

Esto cambia la naturaleza del riesgo.

Si una clave es robada, el atacante todavía puede no tener suficiente autoridad.

Si una hardware wallet se destruye, todavía pueden existir otras.

Si una ubicación física es comprometida, el patrimonio no necesariamente queda expuesto.

Pero la multisig no es una versión “más segura” de single-sig en todos los casos.

Es una arquitectura más compleja.

Y la complejidad también es un riesgo.

Si el usuario no entiende cómo recuperar la wallet, cómo reconstruir los descriptores, dónde están las claves o qué ocurre si desaparece uno de los dispositivos, puede haber construido un sistema técnicamente sofisticado que no sabe operar.

La seguridad no consiste en añadir capas infinitamente. Consiste en añadir las capas que somos capaces de gestionar correctamente.

La passphrase es otra herramienta que puede protegerte… o dejarte fuera

Las passphrases son un ejemplo perfecto de este dilema.

Una passphrase BIP-39 adicional permite generar una wallet diferente a partir de la misma frase mnemónica. El estándar especifica que la passphrase participa en la derivación del seed mediante PBKDF2-HMAC-SHA512.

Esto puede resultar muy útil.

Una persona que encuentre el backup de la seed puede no encontrar automáticamente los fondos si estos están protegidos mediante una passphrase que no conoce.

Pero existe una contrapartida brutal: si tú pierdes la passphrase, también puedes perder el acceso.

No existe una empresa que pueda recuperarla.

No existe un “¿olvidaste tu contraseña?” al estilo de un banco.

No existe soporte técnico que pueda reconstruirla.

Y cada passphrase produce una wallet válida.

Por eso una passphrase puede aumentar la seguridad técnica y, simultáneamente, aumentar el riesgo operacional.

Esta es una de las razones por las que me opongo a la idea de que “más seguridad” siempre significa “más complejidad”.

No necesariamente.

Una hardware wallet no puede protegerte de todo

Otro error frecuente consiste en pensar que una hardware wallet protege contra cualquier ataque.

No lo hace.

Protege principalmente determinados secretos criptográficos y ayuda a aislar las operaciones críticas.

Pero existen ataques que funcionan alrededor de la wallet.

Un ordenador infectado puede intentar engañarte.

Un sitio web puede mostrar una dirección incorrecta.

Un atacante puede utilizar ingeniería social.

Una aplicación descentralizada puede solicitar una firma peligrosa.

Un malware puede alterar información en la pantalla del ordenador.

Por eso una de las reglas más importantes de la autocustodia es verificar los datos críticos en la propia hardware wallet cuando el dispositivo lo permite.

La pantalla del dispositivo no debería ser vista como una simple interfaz.

Es una frontera de confianza.

Ledger, por ejemplo, resume actualmente este principio indicando que la información mostrada en el ordenador o smartphone debe tratarse con cautela y que los datos críticos deben verificarse en la pantalla de la hardware wallet.

El objetivo es impedir que el usuario firme algo que el ordenador le presentó como una cosa cuando en realidad era otra.

Y entonces aparece el firmware

Aquí es donde la autocustodia se vuelve mucho más interesante.

Una hardware wallet es un dispositivo informático.

Tiene software.

Tiene firmware.

Tiene componentes.

Tiene procesos de actualización.

Tiene dependencias.

Y todo software puede contener errores.

El incidente de Coldcard es precisamente una demostración extrema de esto.

El defecto no consistió simplemente en un componente roto. Fue un problema de integración y resolución de funciones dentro del software que terminó haciendo que una ruta crítica para la generación de aleatoriedad utilizara una fuente inadecuada.

La lección que extraigo no es “no utilices Coldcard”.

Sería demasiado simplista.

La lección es que la seguridad de un dispositivo criptográfico depende también de la calidad del proceso mediante el cual se desarrolla, revisa, prueba y actualiza su firmware.

Una hardware wallet no debería evaluarse solamente por su hardware.

Hay que evaluar también su ingeniería.

El secure element tampoco es un escudo mágico

Los secure elements son componentes diseñados para resistir determinadas clases de ataques físicos y proteger secretos.

Son una capa importante.

Pero no son magia.

En enero de 2026, investigadores de Ledger Donjon identificaron una vulnerabilidad en el chip TROPIC01 mediante técnicas de fault injection con láser. El trabajo permitió demostrar que, bajo condiciones físicas extremadamente exigentes, era posible alterar determinados procesos de verificación del chip.

Trezor explicó posteriormente que el ataque requería posesión física, desmontaje, desoldado, decapsulación y equipamiento especializado, y que no implicaba por sí mismo un compromiso directo de los fondos ni un ataque de supply chain persistente contra Trezor Safe 7.

Esta distinción es importante.

Una vulnerabilidad de laboratorio no equivale automáticamente a una amenaza práctica para el usuario promedio.

Pero tampoco debería descartarse.

Lo que demuestra es algo mucho más interesante: la seguridad de una hardware wallet es una arquitectura de capas, no una única barrera.

Cuando una capa falla, las demás deberían seguir dificultando el ataque.

Ese es precisamente el concepto que deberíamos buscar.

El supply chain es una amenaza distinta

También tendemos a pensar que una hardware wallet solo debe protegerse después de llegar a nuestras manos.

Pero la cadena de suministro importa.

¿Dónde compramos el dispositivo?

¿Quién lo manipuló?

¿Fue comprado directamente al fabricante o a un distribuidor confiable?

¿El firmware puede verificarse?

¿El dispositivo puede detectar modificaciones?

¿Existen mecanismos de autenticación?

Estas preguntas forman parte del modelo de seguridad.

Y 2026 añadió otra dimensión que considero particularmente interesante: los datos alrededor de la compra también pueden ser un riesgo.

En agosto, Trezor reveló que uno de sus proveedores logísticos, ShipMonk, había sufrido una brecha que expuso datos de clientes, incluyendo nombres, direcciones, teléfonos y correos electrónicos. Posteriormente, Trezor actualizó la información indicando que una exposición histórica afectaba aproximadamente a otros 67.000 clientes en Estados Unidos.

La hardware wallet en sí no había sido comprometida.

Pero los datos que podían identificar a las personas que compraron una sí.

Esto demuestra que “mi Bitcoin está offline” no significa “yo estoy completamente fuera del modelo de amenazas”.

Si un atacante sabe quién compró una hardware wallet y dónde vive, el problema puede abandonar Internet.

Puede convertirse en phishing dirigido.

Puede convertirse en ingeniería social.

Y, en escenarios extremos, puede convertirse en un riesgo físico.

La seguridad física empieza a importar más de lo que muchos creen

Durante años, la conversación sobre seguridad cripto estuvo dominada por hackers.

Eso está cambiando.

A medida que aumenta el valor almacenado por individuos, también aumenta el incentivo para ataques físicos.

Una seed phrase robada de una caja fuerte es un problema.

Una persona obligada físicamente a entregar un PIN también.

Una familia que guarda millones de dólares en Bitcoin puede convertirse en un objetivo independientemente de que el dispositivo utilizado sea técnicamente excelente.

Por eso la seguridad profesional no puede separar completamente el mundo digital del mundo físico.

Dónde vivimos.

Dónde guardamos los backups.

Quién sabe que tenemos Bitcoin.

Quién sabe qué dispositivo utilizamos.

Qué información publicamos.

Qué dirección utilizamos para recibir la hardware wallet.

Todo puede formar parte del modelo de amenaza.

Tangem y la batalla más importante: hacer la autocustodia comprensible

Aquí es donde considero interesante el caso de Tangem.

No porque crea que exista una hardware wallet perfecta, sino porque Tangem representa una dirección importante de la industria: reducir la fricción de entrada a la autocustodia.

El formato de tarjeta, el uso de NFC y una experiencia centrada en el teléfono pueden resultar mucho más intuitivos para un usuario que nunca ha interactuado con una hardware wallet tradicional.

Tangem también ha publicado auditorías independientes de sus componentes de hardware, firmware y aplicación, y mantiene un historial público de actualizaciones y correcciones.

Pero simplificar la experiencia no significa eliminar el modelo de amenaza.

En julio de 2026, Ledger Donjon publicó una investigación en la que demostró un ataque físico de fault injection contra una tarjeta Tangem utilizando un láser de nanosegundos dirigido al chip. Los investigadores consiguieron evadir determinadas contramedidas y modificar el comportamiento de una comprobación para establecer una contraseña controlada por el atacante.

Es un ataque extraordinariamente sofisticado.

Requiere acceso físico a la tarjeta y herramientas que están muy lejos de las capacidades de un atacante convencional.

Por eso sería absurdo interpretar el descubrimiento como “Tangem es insegura”.

Pero también sería absurdo interpretarlo como “Tangem es imposible de atacar”.

La conclusión profesional es otra: todo sistema de seguridad tiene un modelo de amenaza y una superficie de ataque.

La pregunta es si esa superficie resulta razonable para el usuario y el patrimonio que intenta proteger.

¿Es Tangem para todo el mundo?

No. Pero tampoco lo es Ledger.

Ni Trezor.

Ni Coldcard.

Ni una multisig de tres dispositivos.

La mejor solución depende del usuario.

Para alguien que quiere reducir la fricción y tener una experiencia sencilla, una solución basada en tarjeta puede resultar atractiva.

Para alguien que necesita verificar independientemente cada operación en una pantalla dedicada, la ausencia de una pantalla puede ser un factor importante.

Para un usuario avanzado de Bitcoin preocupado por minimizar dependencias y trabajar con una arquitectura específica, las prioridades serán otras.

Y para alguien con un patrimonio extremadamente elevado, quizá la pregunta ni siquiera debería ser qué hardware wallet comprar.

Debería ser cómo diseñar una política de custodia completa.

Ese es el nivel al que debería evolucionar la conversación.

Una aclaración necesaria sobre Tangem y Criptoinforme

Incluyo Tangem en este análisis porque considero que su propuesta resulta relevante para discutir la evolución de la autocustodia y no porque crea que deba convertirse en una recomendación universal.

Además, Criptoinforme dispone actualmente de códigos de descuento para Tangem.

El código CRIPTOINFORME permite obtener un 10% de descuento en el pedido, mientras que SHIPZERO permite obtener envío gratuito. Ambos códigos pueden utilizarse conjuntamente.

Lo considero importante aclararlo precisamente porque este artículo pretende mantener una separación entre análisis editorial y promoción comercial.

Tener un código de descuento no cambia mi evaluación de una tecnología.

Y, sobre todo, ningún descuento convierte una hardware wallet en una garantía de seguridad.

La responsabilidad sigue siendo del usuario.

El mayor riesgo puede ser la persona que sostiene la clave

Esta es probablemente la parte de mi opinión con la que más personas pueden estar en desacuerdo.

La industria habla muchísimo del atacante.

Yo creo que debería hablar más del usuario.

Una persona puede comprar una hardware wallet excelente y destruir su seguridad en cinco minutos.

Puede hacer una fotografía de la seed.

Puede guardarla en la nube.

Puede introducirla en una aplicación falsa.

Puede perderla.

Puede olvidar la passphrase.

Puede crear cinco backups y no recordar dónde están.

Puede poner todos los backups en la misma casa.

Puede configurar una multisig que no sabe recuperar.

Puede morir sin explicar cómo acceder a los fondos.

Puede firmar una transacción que no comprende.

Ningún secure element puede solucionar estos problemas.

Ninguna certificación puede hacerlo.

Ningún fabricante puede hacerlo.

Por eso creo que la verdadera evolución de la autocustodia no consiste solamente en construir hardware más resistente.

Consiste en construir usuarios más competentes.

¿Debería todo el mundo autocustodiar sus Bitcoin?

Mi respuesta es no. Al menos, no inmediatamente.

Y decirlo no significa estar en contra de Bitcoin.

De hecho, creo que reconocerlo es una forma más responsable de defender la autocustodia.

Una persona que acaba de comprar sus primeros 50 dólares en Bitcoin probablemente no necesita comenzar diseñando una arquitectura multisig.

Una persona que apenas entiende qué es una dirección tampoco debería experimentar inmediatamente con una passphrase compleja.

Una persona que no sabe restaurar una wallet no debería almacenar allí sus ahorros de toda la vida.

El proceso debería ser progresivo.

Primero aprender.

Después practicar.

Después custodiar una cantidad pequeña.

Después probar una recuperación.

Después aumentar la exposición.

Y solamente cuando el usuario entiende completamente su sistema debería plantearse almacenar cantidades que cambiarían significativamente su vida si desaparecieran.

La primera wallet debería ser un laboratorio, no una caja fuerte con los ahorros de toda una vida.

El conocimiento mínimo que debería tener un autocustodio

No creo que alguien necesite ser criptógrafo.

Pero sí debería comprender algunas cosas fundamentales.

Debe saber qué es una clave privada.

Debe entender qué es una dirección.

Debe comprender qué representa una seed phrase.

Debe saber por qué la entropía es importante.

Debe saber que una seed no debe inventarse.

Debe entender qué hace una passphrase.

Debe saber cómo restaurar una wallet.

Debe comprender qué significa firmar una transacción.

Debe saber verificar una dirección.

Debe tener un plan para recuperar sus fondos si el dispositivo desaparece.

Debe saber dónde está el backup.

Y debería haber pensado qué ocurre si él mismo deja de estar disponible.

Ese conocimiento no requiere una carrera universitaria.

Requiere estudiar y practicar.

La verdadera prueba de una wallet no es crearla: es recuperarla

Existe una prueba que considero mucho más importante que mirar una hardware wallet y comprobar que genera una seed.

La prueba es: ¿puedo recuperar mi wallet correctamente?

Porque una wallet que funciona mientras todo está perfecto no demuestra demasiado.

El verdadero escenario de seguridad es el desastre.

El dispositivo se pierde.

El teléfono se rompe.

El ordenador desaparece.

El propietario se muda.

La casa se incendia.

Una copia se destruye.

El fabricante deja de existir.

Un familiar necesita recuperar el patrimonio.

En todos esos casos, el sistema de custodia debe seguir funcionando.

Por eso la recuperación debería formar parte del diseño desde el primer día.

No debería ser una idea para cuando algo salga mal.

La herencia: el problema que Bitcoin todavía obliga a resolver personalmente

Hay una pregunta que todos los autocustodios deberían responder: ¿qué sucede con mis Bitcoin si muero mañana?

En un banco existen procesos legales.

En un exchange existen procedimientos de recuperación y sucesión.

En Bitcoin, si nadie sabe dónde está la información necesaria o cómo utilizarla, el patrimonio puede desaparecer.

Esto no significa que debamos entregar nuestra seed a nuestros familiares.

De hecho, normalmente sería una mala idea.

Significa que deberíamos diseñar mecanismos para que las personas adecuadas puedan reconstruir el sistema cuando sea necesario.

En patrimonios importantes, esto puede involucrar multisig, distribución de claves, instrucciones de recuperación, documentación y asesoramiento legal.

La herencia debería ser considerada parte de la seguridad.

No un problema posterior.

El futuro no será “más hardware”: será mejor arquitectura

Creo que la industria de hardware wallets está entrando en una etapa interesante.

La primera generación se concentró en demostrar que las claves podían mantenerse fuera de un ordenador convencional.

La siguiente se centró en secure elements, pantallas, autenticación y mejores interfaces.

Ahora el problema es mucho más complejo.

Necesitamos sistemas que permitan a usuarios normales alcanzar niveles de seguridad mucho mayores sin convertir la experiencia en un proceso imposible de comprender.

Eso significa mejores mecanismos de recuperación.

Mejores herramientas para multisig.

Mejores estándares.

Mejores interfaces de firma.

Mejor verificación.

Mejor documentación.

Mejores sistemas de herencia.

Y, sobre todo, mejor educación.

Porque el objetivo no debería ser crear dispositivos tan complejos que el usuario simplemente tenga que confiar en ellos.

El objetivo debería ser que el usuario entienda qué está confiando, qué está protegiendo y qué ocurre cuando una de las capas falla.

Mi conclusión: la libertad también tiene un precio

Bitcoin permite algo que ningún sistema financiero tradicional ofrece de la misma manera: la posibilidad de controlar directamente un activo digital sin depender necesariamente de un custodio.

Eso es extraordinario. Pero esa libertad tiene un precio.

Cuando el banco desaparece de la ecuación, también desaparece buena parte de su responsabilidad.

Cuando el exchange desaparece, desaparece el soporte.

Cuando la contraseña deja de ser recuperable, la responsabilidad cambia de manos.

Y cuando la clave privada está bajo nuestro control, también lo están las consecuencias de perderla.

Por eso no creo que debamos convertir la autocustodia en una competición ideológica.

No deberíamos decirle a alguien que es menos bitcoiner porque utiliza un exchange.

Tampoco deberíamos decirle que está completamente protegido porque compró una hardware wallet.

Ambas posiciones son demasiado simplistas.

La autocustodia debería entenderse como una disciplina de gestión de riesgos.

Primero hay que entender qué estamos protegiendo.

Después debemos comprender cómo se genera.

Tenemos que conocer la importancia de la entropía, las semillas, las claves y la derivación.

Tenemos que conocer las limitaciones del hardware.

Tenemos que considerar el firmware.

Tenemos que pensar en los backups.

Tenemos que pensar en ataques físicos.

Tenemos que pensar en phishing.

Tenemos que pensar en multisig.

Tenemos que pensar en herencia.

Y, sobre todo, tenemos que pensar en nuestros propios errores.

Porque una hardware wallet puede protegernos de determinados atacantes.

Una buena arquitectura puede protegernos de determinados errores.

Una multisig puede protegernos de la pérdida de una clave.

Un backup puede protegernos de la destrucción de un dispositivo.

Pero ninguna tecnología puede proteger completamente a una persona que no entiende el sistema que está utilizando.

Por eso mi posición sobre la autocustodia es sencilla: no creo que sea para cualquiera.

Pero tampoco creo que deba ser exclusiva para expertos.

Creo que cualquiera puede aprender.

Y probablemente ese debería ser uno de los objetivos más importantes de la industria: no conseguir que más personas compren hardware wallets, sino conseguir que más personas comprendan realmente qué significa tener sus propias claves.

Porque la frase “not your keys, not your coins” sigue siendo una de las mejores advertencias de Bitcoin.

Pero en 2026 necesitamos añadir una segunda: Tus claves, tu responsabilidad.

La entrada Autocustodia de Bitcoin: hardware wallets, entropía y el verdadero costo de ser tu propio banco se publicó primero en Criptoinforme.