Rutas de derivación: dónde busca tu billetera tus bitcoin

Restauras tu seed phrase y el saldo es cero

Pasa más de lo que parece. Alguien apunta sus palabras, un día cambia de programa, las introduce y la billetera (wallet) aparece vacía. El pánico llega enseguida: «¿se han perdido mis bitcoin?». Casi nunca. Los fondos siguen donde estaban, en la cadena de bloques. Lo que ha cambiado es dónde mira la billetera nueva.

Una seed phrase no contiene direcciones. Contiene el punto de partida de un árbol de claves, y la ruta de derivación es el camino que indica por qué rama bajar. Si el programa baja por otra rama, obtiene otras direcciones, que están vacías. Entender la ruta es entender por qué ocurre.

⚠️ Vectores de prueba comprometidos: la frase «abandon abandon abandon abandon abandon abandon abandon abandon abandon abandon abandon about», la passphrase «TREZOR» y todas las direcciones y huellas de esta entrada son vectores públicos de BIP-39, BIP-84 y BIP-86. Cualquiera conoce sus claves privadas. Nunca les envíes fondos. Y no escribas tu frase real en ninguna web. La herramienta enlazada más abajo ni siquiera tiene dónde: solo trabaja con esta frase de prueba.

Leer una ruta, nivel a nivel

Empecemos por un ejemplo. La primera dirección de recepción del vector de BIP-84 sale de esta ruta:

m / 84' / 0' / 0' / 0 / 0 → bc1qcr8te4kr609gcawutmrza0j4xv80jy8z306fyu

BIP-44, BIP-49, BIP-84 y BIP-86 comparten la misma estructura, m / purpose' / coin_type' / account' / change / address_index. Cada nivel responde a una pregunta (BIP-44, BIP-84 y BIP-86):

m: la clave maestra, que sale de la semilla. Cómo se obtiene esa semilla desde las palabras lo cuenta BIP-39.
purpose: qué estándar sigue la cuenta y, con él, qué tipo de script. BIP-43 recomienda que coincida con el número del BIP que define el esquema: 44, 49, 84 u 86.
coin_type: la red. Según SLIP-44, 0' es Bitcoin y 1' es la testnet de todas las monedas, no solo la de Bitcoin.
account: cuentas independientes dentro de la misma seed phrase. Casi todo el mundo usa solo la 0'.
change: 0 para direcciones de recepción, 1 para el cambio de tus propias transacciones.
address_index: 0, 1, 2... una dirección tras otra.

Para qué sirve cada tipo de dirección, y cuánto ocupa en una transacción, está en tipos de direcciones. Aquí interesa otra cosa: cada estándar fija un purpose distinto, y por eso la misma frase da familias de direcciones distintas.

Los estándares más usados

BIP	Ruta de cuenta	Dirección
44	`m/44'/0'/0'`	BIP-44 no fija el script. En la práctica, P2PKH (`1…`)
49	`m/49'/0'/0'`	P2SH-P2WPKH (`3…`)
84	`m/84'/0'/0'`	P2WPKH (`bc1q…`)
86	`m/86'/0'/0'`	P2TR de clave única (`bc1p…`)
48	`m/48'/0'/0'/script_type'`	Multifirma: `1'` P2SH-P2WSH, `2'` P2WSH

Fuente: BIP-44, 48, 49, 84 y 86, todos en estado Deployed según el README de bitcoin/bips (7 de octubre de 2026). Un detalle que se repite mal: BIP-44 no menciona ningún tipo de dirección. Se usó con P2PKH por costumbre: BIP-49, de 2016, ya describe las billeteras BIP-44 con «the normal P2PKH address». SLIP-132, de 2018, lo registró después para la xpub y m/44' como «P2PKH or P2SH». Y BIP-48 solo define los script_type 1' y 2'; Taproot no aparece en él.

Con la misma frase de prueba y passphrase vacía, las ramas 84' y 86' dan esto (vectores de BIP-84 y BIP-86):

m/84'/0'/0'/0/0 → bc1qcr8te4kr609gcawutmrza0j4xv80jy8z306fyu
m/86'/0'/0'/0/0 → bc1p5cyxnuxmeuwuvkwfem96lqzszd02n6xdcjrs20cac6yqjjwudpxqkedrcr

Es la misma frase y la misma huella maestra, 73c5da0a. Dos direcciones sin parecido alguno. Si tus fondos están en la primera y tu billetera restaurada mira la segunda, verá cero. Puedes comprobarlo con el explorador de rutas de derivación.

El apóstrofo no es decoración

En 84', la comilla marca una derivación endurecida (hardened). BIP-32 reparte los índices en dos mitades: los hijos normales usan del 0 al 2³¹-1 y los endurecidos, del 2³¹ al 2³²-1. Así, 84' es el índice 2³¹ + 84, es decir 2.147.483.732 (BIP-32). Algunos programas escriben h o H en lugar de la comilla. Es la misma idea. Ojo: los descriptores de BIP-380 aceptan h y ', pero no H.

La diferencia tiene consecuencias. Dada una clave pública padre, se pueden calcular las claves públicas de sus hijos normales, pero no las de los endurecidos: la función falla. BIP-44 aplica la derivación endurecida a purpose, coin_type y account, y la pública a change y address_index. El resultado es práctico: una xpub de cuenta (m/84'/0'/0') genera todas las direcciones de esa cuenta sin ninguna clave privada. BIP-32 avisa de un riesgo: quien tenga esa xpub y una sola clave privada que descienda de ella sin endurecer, por ejemplo la de una dirección, puede calcular la clave privada de toda la cuenta. Como account, coin_type y purpose son endurecidos, el cálculo no pasa de ahí: la clave maestra y las demás cuentas no corren peligro. Qué riesgos tiene compartir esa xpub se explica en HD wallets, BIP32 y xpub, y no se repite aquí.

Un detalle sobre los prefijos. ypub, zpub y xpub son la misma clave serializada con otros bytes de versión, una pista sobre el script que definieron BIP-49 y BIP-84 y registra SLIP-132. BIP-86 no definió bytes nuevos: usa xpub. BIP-380 critica ese enfoque como una «layer violation» y los descriptores de salida lo sustituyen por una declaración explícita del script.

Saldo cero: qué revisar, de lo más grave a lo más leve

Antes de nada, un principio de diseño. BIP-49, BIP-84 y BIP-86 eligieron cuentas separadas a propósito: según BIP-84, una billetera incompatible «will not discover accounts at all and the user will notice that something is wrong». Ver cero es el síntoma esperado de una discrepancia, no una señal de pérdida.

Haz estas pruebas sin sacar la seed phrase de donde está. Si sigue en una hardware wallet, conéctala a un coordinador como Sparrow y prueba allí cada tipo de script: el aparato da las claves públicas de cada ruta sin enseñar las palabras. Si tienes que introducir la frase y salió de una hardware wallet que se rompió o se borró, hazlo en una hardware wallet vacía que admita tu copia (la misma, si se ha borrado; restaurar borra lo que tenga dentro) y luego prueba igual desde el coordinador. Si las que tienes ya guardan fondos, no las uses para esto: consigue una vacía o sigue el caso del aparato limpio. Si vivía en un móvil o un ordenador, o perdiste o te robaron el aparato, no la metas en una hardware wallet. En ese caso, o si no tienes ninguna que admita tu copia, usa un solo programa en un aparato limpio (restablecido de fábrica y sin otras aplicaciones), es decir, un móvil o un ordenador que no uses para otra cosa, con la billetera instalada desde el enlace de su web oficial, y haz ahí todas las pruebas. Antes de restaurar en él, prepara la billetera nueva (o usa otra que ya tengas, con su propia seed y la copia comprobada): cuando aparezcan los fondos, los moverás ahí, porque la antigua ya está expuesta (los pasos, en recuperar tu billetera). Cada programa en el que tecleas la frase es una copia más que proteger. Revisa en este orden:

Passphrase distinta o ausente. Es la causa más grave porque la billetera no protesta: con cualquier passphrase te da una billetera válida, vacía. La passphrase entra en el cálculo de la semilla (BIP-39) y cambia todo el árbol, así que cada dirección sale diferente aunque la ruta sea la misma. La FAQ de Sparrow lo resume: la billetera mostrará que no hay fondos, pero no se han perdido (consultada el 7 de octubre de 2026). La pista es la huella maestra: si no coincide con la que apuntaste, la passphrase está mal, o alguna palabra. Compruébalo en el explorador: con la frase de prueba y la passphrase «TREZOR», la huella deja de ser 73c5da0a y pasa a ser b4e3f5ed. Si usabas una, introdúcela exacta, con mayúsculas y espacios. Más en passphrase.
Tipo de script o purpose equivocado. Fondos en bc1q (84') con una billetera restaurada en 44' o 86': la cuenta no aparece. Prueba cada purpose. Aquí sirve la primera dirección que apuntaste: indica el tipo de script y la ruta.
Cuenta distinta de 0'. BIP-44 descubre cuentas de una en una y se detiene en la primera sin transacciones en la cadena de recepción. También pide que el software no deje crear una cuenta si la anterior no tiene historial. Si usaste la cuenta 1' sin haber usado nunca la 0' (algún programa lo permite, aunque BIP-44 pide que no), una billetera que siga BIP-44 se para en la 0' y no la ve. Hay que añadir la cuenta a mano.
Límite de huecos (gap limit). BIP-44 fija 20: si el software encuentra 20 direcciones seguidas sin usar, deja de buscar. BIP-44 pide también que la billetera avise cuando vas a generar una dirección más allá de ese hueco. Ejemplo con números. Cobraste en las direcciones 0 a 4. Después generaste 25 direcciones más para facturas que nadie pagó (de la 5 a la 29), y luego te pagaron en la 30. Al restaurar, un programa con límite 20 ve fondos en la 0 a la 4, recorre de la 5 a la 24 sin encontrar nada, se para y nunca llega a la 30. Aparecen los fondos antiguos y falta el reciente. Si en cambio hubieras cobrado en todas, llegaría a la 30 y seguiría hasta dar con 20 vacías seguidas: lo que cuenta es el hueco, no el número de la dirección.
Seed phrase que no es BIP-39, o red equivocada. Las frases que genera Electrum y las copias SLIP-39 siguen otras reglas. Y coin_type 1' es testnet: una billetera en esa red nunca verá fondos de mainnet.
Multifirma o ruta no estándar. Aquí la frase no basta. Hace falta el descriptor completo o los datos de la configuración (ver descriptores de salida).

Sobre el límite de huecos del punto 4, tres datos más. Primero, la cadena de cambio no suele esconder nada. BIP-44 decide hasta dónde buscar mirando solo la de recepción, porque al cambio solo llega dinero que antes entró por ella. En la práctica, las billeteras recorren también la de cambio al restaurar, con su propio límite: Electrum mira 10 por defecto (gap_limit_for_change en wallet.py, consultado el 7 de octubre de 2026). Segundo, en Sparrow el límite es 20 por defecto y se sube en Settings > Advanced. Su FAQ lo recomienda cuando faltan transacciones recientes tras restaurar (consultada el 7 de octubre de 2026). Tercero, Bitcoin Core no usa ese 20: reserva un keypool de 1.000 por defecto (DEFAULT_KEYPOOL_SIZE en scriptpubkeyman.h, consultado el 7 de octubre de 2026). No es una regla del protocolo, sino una convención de cada billetera.

Los pasos concretos de una restauración están en recuperar tu billetera.

Qué significa esto para ti

Apunta con tu copia de seguridad algo más que las palabras. El tipo de billetera (por ejemplo «84, bc1q»), si usas passphrase y, si no usas la cuenta 0, cuál. Y dos comprobaciones: la huella maestra (8 caracteres, la muestran casi todas las billeteras) y la primera dirección de recepción. La huella confirma la seed phrase y la passphrase; la dirección confirma el tipo de script y la ruta. No se guarda la passphrase junto a las palabras, pero sí el hecho de que existe. Si usas passphrase, la huella y la primera dirección de esa billetera van con la copia de la passphrase, no con las palabras: a quien robe las palabras le dirían si ha acertado la passphrase y cuánto hay en juego. Cómo repartir esas copias se trata en estrategias de copia de la seed. Y cuando restaures y veas cero, no crees billeteras nuevas para probar ni teclees la frase en programas nuevos: recorre la lista de arriba. Casi siempre es una de las cuatro primeras causas.