Restaurar la semilla en otro fabricante: qué te garantiza BIP39 y qué no

Quien custodia él mismo sus criptoactivos compra para ello, casi siempre, un dispositivo de una empresa. Esa empresa puede cometer errores, perder datos de clientes, descatalogar un modelo o dejar un día de existir. De ahí se sigue una pregunta incómodamente concreta: ¿depende de esa empresa tu acceso a los fondos?

Qué tipos de monedero existen, en qué se diferencian y cuál encaja con tu importe lo explica nuestra guía Cómo guardar criptomonedas: tipos de monedero cripto.

La respuesta no está en el marketing de los fabricantes, sino en tres especificaciones técnicas que llevan más de diez años a disposición pública. Se llaman BIP39, BIP32 y BIP44. Quien entiende lo que en ellas se fija puede responder a la cuestión del fabricante sin creerse una promesa publicitaria. Y quien conoce los límites de esos estándares comprende también por qué una restauración en hardware ajeno sigue saliendo mal con regularidad en la práctica.

Este texto explica las dos caras: qué te garantiza el estándar y en qué puntos te deja solo. Al final hay una prueba que puedes realizar en una noche tranquila y que te da una respuesta sólida en lugar de una suposición.

Dependencia del fabricante en las carteras de hardware: qué depende realmente del proveedor

Una cartera de hardware es un pequeño ordenador con una única tarea. Genera un valor aleatorio, lo guarda aislado y firma con él transacciones sin revelarlo jamás. Del proveedor dependen el firmware, el software acompañante del ordenador y la atención al cliente. La clave en sí depende del proveedor solo si el dispositivo abandona los estándares abiertos.

Esa distinción es todo el núcleo del asunto. Firmware, software acompañante y atención al cliente son sustituibles. Una clave que existiera exclusivamente en un formato propietario no lo sería. Justamente por eso merece la pena leer la especificación antes de que el dinero llegue a un dispositivo.

BIP39: cómo 128 a 256 bits de azar se convierten en doce a 24 palabras

BIP39 describe cómo se traduce un valor inicial aleatorio a una secuencia de palabras memorizable. La especificación establece que la entropía de partida debe ser múltiplo de 32 bits y situarse entre 128 y 256 bits. A partir de esa entropía se forma una suma de verificación añadiendo los primeros ENT/32 bits de su hash SHA256. El resultado se descompone en grupos de once bits, y cada grupo, como número entre 0 y 2047, remite a una entrada de una lista de 2048 palabras. El texto de la especificación es público y lo bastante breve para leerlo en una noche.

De ahí resultan las longitudes conocidas. 128 bits de entropía más cuatro bits de verificación dan doce palabras; 256 bits más ocho bits de verificación dan 24 palabras. En medio quedan las variantes menos frecuentes de 15, 18 y 21 palabras. Una secuencia de 24 palabras emplea, por tanto, la misma técnica que una de doce, simplemente con más azar de partida.

La frase decisiva para la cuestión del fabricante viene después. El valor inicial propiamente dicho se calcula a partir de la secuencia de palabras mediante la función PBKDF2: la secuencia de palabras como contraseña, la cadena de caracteres «mnemonic» junto con una frase de contraseña opcional como sal, 2048 iteraciones, HMAC-SHA512 como función base y 512 bits como resultado. Ese procedimiento es plenamente determinista y no contiene, en ningún punto, identificador alguno del dispositivo, del firmware o del proveedor. Quien introduce las mismas palabras en otro dispositivo que implemente el mismo estándar obtiene el mismo valor de 512 bits. Esa es la garantía de la que aquí se trata, y es de naturaleza matemática.

La suma de verificación detecta erratas, pero no corrige nada

La suma de verificación es corta, y la propia especificación dice lo que de ello se sigue: aproximadamente uno de cada 256 errores aleatorios pasa inadvertido, y el procedimiento no ofrece ayuda de corrección alguna. En la práctica esto significa que una palabra mal copiada suele producir un mensaje de error, pero no siempre. En el caso desfavorable, el dispositivo acepta la entrada y genera una cartera completamente distinta y vacía. Justamente por eso toda copia de seguridad requiere un control en el que las palabras se lean realmente una vez.

La lista de palabras forma parte del procedimiento

Como el cálculo parte de la propia secuencia de palabras y no de la entropía original, la misma secuencia de números genera en una lista de palabras de otro idioma un valor inicial totalmente distinto. La especificación lo señala de forma expresa y recomienda por ese motivo la lista inglesa. Quien creó una copia de seguridad con la lista francesa o japonesa necesitará más adelante un dispositivo que conozca exactamente esa lista. Con la lista inglesa el problema no se plantea prácticamente nunca, porque toda implementación seria la admite.

La frase de contraseña es una palabra que no figura en ninguna copia de seguridad

La frase de contraseña opcional entra en el cálculo como parte de la sal. Cada frase de contraseña convierte así la misma secuencia de palabras en una cartera propia y plenamente válida. Una errata en la frase de contraseña no produce ningún mensaje de error. Produce una cartera distinta y vacía, porque el procedimiento no puede distinguir en absoluto entre «erróneo» y «distinto».

Para la restauración en hardware ajeno este es uno de los tropiezos más frecuentes. El nuevo dispositivo acepta la secuencia de palabras, muestra una cartera vacía y parece así demostrar que la portabilidad, después de todo, no funciona. En realidad solo falta un componente que el propio usuario fijó y que no está anotado en ninguna parte. Cómo conservar una frase de contraseña con sentido sin dejarla junto a las palabras lo describimos el 8 de agosto de 2026 en nuestro texto sobre la custodia segura de la frase semilla.

BIP32 y la ruta de derivación: por qué la misma semilla da direcciones distintas

El valor inicial de 512 bits no es todavía una dirección. BIP32 describe cómo derivar de él jerárquicamente cuantos pares de claves se quiera, y BIP44 da a esa derivación un orden fijo de cinco niveles: propósito, tipo de moneda, cuenta, indicador de cambio e índice de dirección. Se escribe como una cadena de números separados por barras, la llamada ruta de derivación.

Los cinco niveles de una ruta BIP44

Una ruta típica es 44'/0'/0'/0/0 y designa la primera dirección de la primera cuenta de bitcoin en el formato de dirección clásico. El apóstrofo marca un nivel endurecido, a partir del cual las claves subordinadas no pueden calcularse sin el valor inicial. El primer número corresponde al formato de dirección: 44 para la forma clásica, 49 para la variante SegWit anidada, 84 para SegWit nativo. Si cambia ese único número, cambian todas las direcciones por debajo.

Este es el punto de mayor importancia práctica de este texto. Dos dispositivos pueden procesar la misma semilla de forma completamente correcta y mostrar aun así direcciones totalmente distintas, porque tienen preconfiguradas rutas diferentes. La semilla es correcta en todos los casos. Un saldo solo se hace visible en la ruta en la que realmente se encuentra.

La ruta de derivación es el motivo más frecuente de una cartera aparentemente vacía

Cuánto se aparta la práctica del estándar lo describe un fabricante en su propia documentación para desarrolladores con notable franqueza. En la documentación de Ledger Live sobre rutas de derivación se lee que ni mucho menos todas las carteras se atienen a BIP44, que muchas preguntan directamente al usuario por una ruta y que con el tiempo se han incorporado numerosas excepciones para absorber esas desviaciones. Para Ethereum, el software recorre por ello las direcciones bajo 44'/60'/0'/x y cuenta hasta diez cuentas vacías antes de dar por terminada la búsqueda.

En el mismo documento está la frase de la que pende la consecuencia práctica: quien se encuentre atascado en una ruta inusual y quiera usar el software tiene que trasladar el saldo a una ruta habitual con la herramienta original. Eso no describe el fallo de un proveedor concreto. Describe un estado con el que trabaja todo el sector, porque las convenciones solo se impusieron después de las primeras implementaciones.

Para ti se sigue de ahí una regla sencilla: la ruta de derivación forma parte de la copia de seguridad. Una secuencia de palabras sin una nota sobre qué dispositivo y qué formato de dirección estaban en uso sigue siendo recuperable, pero en caso de necesidad cuesta tiempo de búsqueda. Qué dispositivos preconfiguran qué rutas y con cuánta transparencia lo maneja el software acompañante puede consultarse en nuestra comparativa de carteras de hardware antes de decidirse por un modelo.

SLIP-0044 da a cada cadena su propio número en la ruta

El segundo nivel de la ruta es el tipo de moneda. Qué número corresponde a qué cadena figura en una lista pública llamada SLIP-0044. Bitcoin lleva allí el 0, Litecoin el 2, Dogecoin el 3, Ether el 60, Bitcoin Cash el 145, Solana el 501 y la cadena BNB el 714. La lista abarca ya varios miles de entradas y crece con cada nueva cadena.

En la práctica esto significa dos cosas. Las tenencias de distintas cadenas se alojan, a partir de la misma semilla, en ramas separadas, razón por la cual un dispositivo que no conoce una cadena tampoco puede mostrar su saldo. Y algunas cadenas han cambiado de tipo de moneda a lo largo de su historia o mantienen varios números en paralelo. Quien eche en falta un saldo tras cambiar de dispositivo debería conocer esta lista antes de dar por hecha una pérdida.

El gap limit explica por qué un software pasa por alto un saldo existente

Incluso dentro de la ruta correcta acecha una trampa. Un software de cartera recorre cuentas y direcciones por orden y termina la búsqueda en cuanto un determinado número de direcciones consecutivas queda sin entrada de pago. Ese límite de corte se llama gap limit. BIP44 prescribe expresamente ese comportamiento, porque de lo contrario la búsqueda no terminaría nunca.

La consecuencia es incómoda. Si en el pasado se utilizó a mano una dirección situada muy atrás, un software conforme al estándar puede pasarla por alto y mostrar una cuenta vacía. El saldo sigue en la cadena y es visible a través de cualquier explorador de bloques; solo la lógica de búsqueda no llega lo bastante lejos. La solución pasa por una aplicación en la que el gap limit pueda elevarse o una ruta introducirse a mano. Quien se ha visto una vez en esa situación entiende por qué los usuarios experimentados no toman sus direcciones al azar de la mitad de una lista.

Donde termina el estándar: partes de Shamir, multifirma y formatos propietarios

No toda copia de seguridad es una secuencia de palabras BIP39, aunque a primera vista lo parezca. Hay tres casos que deberías distinguir, porque limitan la portabilidad en distinta medida.

El primero es el procedimiento de Shamir según SLIP-0039, en el que el secreto se divide en varias partes y basta un número mínimo de ellas para la restauración. Esas partes parecen una secuencia de palabras, pero siguen otro procedimiento y solo funcionan en dispositivos que dominan exactamente ese procedimiento. El segundo caso son los montajes de multifirma, en los que varias claves firman conjuntamente: allí necesitas, además de las palabras, el descriptor de la cartera con todas las claves públicas y la regla sobre cuántas firmas hacen falta. Sin ese archivo el saldo no es alcanzable solo con las palabras, y la experiencia dice que se pierde más a menudo que las propias palabras. El tercer caso son los dispositivos que guardan la clave exclusivamente en un formato propio y no la entregan nunca como secuencia de palabras legible.

Antes de comprar, todo se resuelve con una única pregunta: ¿entrega el dispositivo una secuencia de palabras BIP39 que pueda leerse en hardware ajeno? Si en el manual solo aparece un término propietario para la copia de seguridad, sin remisión a un estándar abierto, hay motivo para mirar con más detenimiento.

Qué significa en la práctica la caída de un fabricante y qué no

Entre lo publicado por esta redacción en las últimas semanas hay varios casos en los que un proveedor decepcionó a sus clientes. El 31 de julio de 2026 informamos sobre un fallo de firmware que hacía calculables las semillas generadas. El 13 de agosto de 2026 el asunto fue una filtración de datos en un proveedor de servicios que dejó al descubierto nombres y domicilios de clientes de un fabricante de carteras. En el lado de la custodia por parte de los mercados de negociación la cuestión se plantea aún con más crudeza, porque allí, además de la técnica, entra el derecho concursal; cuándo las monedas custodiadas pueden separarse de la masa lo expusimos por separado el 18 de agosto de 2026.

Para la autocustodia cabe extraer de ello un balance sobrio. Una filtración de datos afecta a tu privacidad y eleva el riesgo de intentos de fraude dirigidos por correo postal, teléfono o email, pero no toca tu clave. La insolvencia del fabricante pone fin al mantenimiento del firmware y a la atención al cliente, pero deja intacta una semilla conforme al estándar; el dispositivo se convierte en un modelo descatalogado, el saldo no. La cosa solo se pone seria en el tercer caso, un fallo en la generación del valor aleatorio. Contra eso no ayuda ningún estándar. Ahí no queda más que migrar a una semilla recién generada, y sin demora.

La frase tan extendida de que las monedas están en la cadena de bloques y no en el dispositivo es por ello correcta e incompleta a la vez. Se cumple precisamente cuando la semilla se generó de forma limpia y sigue el estándar abierto. Ambas cosas pueden comprobarse, y sin conocimientos especializados.

La prueba de restauración: así compruebas hoy si tu copia de seguridad aguantará mañana

Una copia de seguridad que nunca se ha leído es una suposición. La siguiente prueba la convierte en una constatación. Dura unos veinte minutos y no cuesta nada más allá de las comisiones de red de una transferencia mínima.

La prueba con una cuenta vacía

Consigue primero un segundo software de cartera, de código abierto, en un dispositivo que restablecerás después, e introduce allí tu secuencia de palabras junto con la frase de contraseña. Selecciona en ese software la misma ruta de derivación que emplea tu dispositivo principal. Compara luego la primera dirección de recepción con la que tu dispositivo principal muestra en esa misma posición. Si ambas cadenas de caracteres coinciden, la portabilidad queda demostrada: tu saldo depende de la secuencia de palabras y de la ruta, de ninguna empresa.

Quien lo quiera más estricto, que transfiera un importe mínimo a una dirección derivada exclusivamente de la copia de seguridad y lo devuelva desde allí. Con ello queda comprobada también la firma, y no solo la visualización de la dirección. Restablece después el dispositivo de prueba y elimina el software.

Al final anotas dos datos junto a las palabras: la ruta de derivación completa y el número de palabras. La frase de contraseña va en otro sitio, porque de lo contrario anulas su propósito. Quien de todos modos esté regulando qué debe ocurrir con el acceso llegado el caso, que incorpore esta nota directamente a la documentación sucesoria.

Comprobar la restauración de la semilla: lo que debes retener

1. Haz la prueba de restauración antes de necesitarla. Lee tu secuencia de palabras una vez en una segunda aplicación independiente y compara la primera dirección de recepción con la de tu dispositivo principal. Qué programas son de código abierto y admiten rutas de derivación propias está en nuestra comparativa de carteras de software.
2. Anota la ruta de derivación junto a la copia de seguridad. Las palabras solas bastan técnicamente; la ruta te ahorra horas llegado el caso. En tu próxima compra de dispositivo, fíjate en que el proveedor preconfigure rutas habituales y entregue una secuencia de palabras BIP39; los modelos de nuestra comparativa de carteras de hardware se diferencian claramente en esto.
3. Separa las tenencias de negociación de las de custodia. Lo que quieras custodiar tú mismo a largo plazo no debe estar de forma permanente en una cuenta de negociación, porque allí ninguno de los estándares descritos aquí juega a tu favor. Qué mercados están regulados y cómo son sus vías de retirada lo muestra nuestra comparativa de exchanges de criptomonedas.

(19 de agosto de 2026. Este artículo no constituye asesoramiento de inversión. Los precios y las tarifas cambian; comprueba las condiciones con el proveedor antes de comprar.)