Wallets y autocustodia

Firmar sin conexión: QR, microSD y el flujo completo

Cómo viaja una transacción entre tu ordenador y el aparato que guarda las claves sin que estas salgan nunca de él, qué diferencia hay entre QR, microSD, NFC y USB, y qué mirar en la pantalla del firmador antes de aprobar.
En este artículo

Si el aparato no tiene conexión, ¿cómo recibe la transacción?

Una billetera (wallet) que firma sin conexión necesita recibir lo que va a firmar y devolver la firma, y para eso hace falta algún camino. La diferencia está en qué camino es. Firmar sin conexión (air-gapped) significa que el firmador no tiene enlace de datos con ningún aparato conectado: ni red ni cable de datos. Todo lo que entra y sale lo lleva un medio que controlas tú, como una pantalla con una cámara delante o una tarjeta microSD que pasas de mano en mano.

El esquema general de aislamiento ya está en billeteras calientes y frías. Aquí interesa lo que viene después: qué viaja, por dónde y qué debes comprobar en el aparato antes de firmar.

El flujo completo, paso a paso

Un ejemplo con el reparto de papeles habitual: un ordenador con una billetera vigía (watch-only) que ve tus fondos pero no puede gastarlos, y un firmador que guarda las claves. El flujo tiene siete pasos.

  1. Preparación, una sola vez. El firmador exporta los datos públicos de la cuenta por QR o microSD: una xpub con su ruta y su huella (fingerprint), que es un identificador corto de la clave maestra, o directamente un descriptor. La billetera vigía los importa. En multifirma, además, la política de la billetera se registra en cada firmador. Ese registro es en sí una comprobación: el aparato te enseña el quórum y la xpub de cada cosignatario, y tú compruebas cada una antes de aceptar. Compara las xpub enteras y en el mismo formato (xpub con xpub, no con Zpub), no solo las huellas: la huella es una etiqueta que cualquiera puede copiar, y el aparato solo puede comprobar la suya, no la de los demás. Y compáralas con una fuente que no haya pasado por el ordenador: lo más seguro es la xpub que enseña en su propia pantalla cada aparato cosignatario (si al exportarla solo sale un QR, búscala en la pantalla de registro: aparatos como Coldcard o Jade enseñan ahí la xpub de cada cosignatario), o una copia impresa que hiciste a partir de esas pantallas. Un fichero o un PDF exportado por la misma billetera vigía no sirve, porque si el ordenador está comprometido, la xpub cambiada va también en esa copia.
  2. Comprobar una dirección de recepción en la pantalla del firmador antes de recibir fondos. Se explica en hardware wallets.
  3. Crear. La billetera vigía elige los UTXO, las salidas y la comisión, y construye un PSBT. En el lenguaje de BIP-174 hace de creador (Creator) y de actualizador (Updater): añade los datos que el firmador necesita para comprobar importes y cambio. El firmador hace de firmante (Signer), y al final alguien junta las firmas, completa la transacción y la extrae.
  4. Pasar al firmador por QR o con un fichero .psbt en la microSD.
  5. Verificar y firmar en el firmador, con la lista de más abajo. Si algo no cuadra, se rechaza.
  6. Devolver el PSBT firmado, de nuevo por QR o como fichero en la tarjeta, o la transacción final si el firmador la finaliza.
  7. Difundir. La billetera vigía finaliza, extrae la transacción y la envía a la red. En multifirma, antes se combinan las firmas que exige el umbral.

La Coldcard, cuando firma un fichero de la microSD, no sobrescribe el original: guarda el resultado con otro nombre. Así es más difícil cargar en el ordenador el fichero equivocado. El nombre depende de si aún faltan firmas. Si faltan, de «payment.psbt» sale «payment-part.psbt». Si con su firma ya no falta ninguna, con la configuración por defecto guarda el PSBT firmado con «-signed.psbt» al final y, además, la transacción final con «-final.txn». En un 2 de 3 firmado en serie con dos Coldcard, la segunda recibe «payment-part.psbt» y devuelve «payment-part-signed.psbt» y «payment-part-final.txn». La guía de métodos sin conexión de Coldcard, revisada el 5 de junio de 2026, da como ejemplo «payment-signed-signed.psbt». Con el firmware actual, ese nombre solo sale si el fichero que recibe ya se llamaba «payment-signed.psbt» (código de shared/auth.py en las versiones del 30 de septiembre de 2026, consultado el 7 de octubre de 2026).

Existe una versión 2 del formato, BIP-370, que permite añadir entradas y salidas después de crear el PSBT. Para lo que cuenta esta entrada no cambia nada, siempre que el coordinador y el firmador entiendan la misma versión.

Qué mirar en la pantalla del firmador

Esta es la parte que protege tu dinero. El ordenador puede estar comprometido, así que su pantalla puede mentir. La del firmador es la única que cuenta. La misma guía de Coldcard lo resume así: un ordenador comprometido podría escribir un PSBT malicioso en la tarjeta, y el aparato se defiende enseñando todos los detalles de la transacción en su propia pantalla de confianza antes de que lo apruebes. Y añade: la comprobación del usuario no es opcional. Antes de aprobar:

  • Cada dirección de destino, entera. Compárala con la que te dio el destinatario por un canal fiable, no solo el principio y el final.
  • El importe de cada salida.
  • La comisión. Si el aparato la da también en sat/vB, mejor. Si solo da el importe, compáralo con lo que esperabas pagar. Una comisión desproporcionada es una alarma.
  • El cambio. Tiene que salir marcado como cambio, es decir, el aparato ha comprobado, derivándola él mismo, que la dirección es suya (en multifirma, que sale de la política registrada). La ruta la pone el ordenador en el PSBT, así que por sí sola no prueba nada. Si el cambio aparece como una salida externa, o hay una salida que no esperabas, para. Es por ahí por donde un atacante intenta colar una salida suya.
  • El número de salidas. Si pagabas a una persona y ves tres, algo ha cambiado.
  • En multifirma, con qué billetera firma. El aparato debe decirte el nombre de la billetera registrada y su quórum.
  • Que no te pidan firmar otra vez. Si el ordenador dice que la firma falló y te pide repetirla con la misma transacción, desconfía. Con las direcciones SegWit anteriores a Taproot (las bc1q y también las que empiezan por 3, de SegWit anidado) es así como se monta el robo de la comisión que se explica más abajo, y ver la misma comisión en pantalla las dos veces no te protege: el truco está en juntar las dos firmas.
  • Los avisos del aparato: un tipo de firma (sighash) distinto del normal, que permite cambiar partes de la transacción después de firmarla; cambio en una ruta rara; una multifirma sin registrar.

Y una regla que lo cierra: si el aparato no puede enseñarte algo de lo anterior, no firmes a ciegas.

La comisión merece una nota de historia. En las direcciones SegWit anteriores a Taproot (bc1q, y las 3… de SegWit anidado), la firma de BIP-143 recoge solo el importe de la entrada que se firma. Un ordenador malicioso podía pedir dos firmas mintiendo cada vez sobre el importe de la otra entrada y acabar gastando como comisión casi todo un UTXO. Es la CVE-2020-14199, publicada en junio de 2020: según la ficha de NVD afectaba a todas las hardware wallets, y Trezor la corrigió en la versión 1.9.1 de la Trezor One y la 2.3.1 de la Model T. Trezor lo resolvió exigiendo la transacción previa completa también para entradas SegWit. No todos los firmadores lo hacen: BIP-174 lo deja como opción. La Coldcard, por ejemplo, no la exige para entradas SegWit y se defiende recordando los importes que ya ha visto. Y algunos coordinadores no mandan esa transacción por QR para que la secuencia sea más corta: Sparrow no la incluye en billeteras SegWit salvo con algunos modelos de aparato y más de una entrada, según su código a 7 de octubre de 2026.

Taproot lo arregla en el propio protocolo. La firma de BIP-341 se compromete con los importes de todas las entradas, lo que según sus notas elimina la posibilidad de mentir sobre la comisión a un firmador sin conexión. Pero solo si gastas desde direcciones Taproot (bc1p) y con el tipo de firma normal. Con bc1q o con 3…, la defensa sigue siendo no firmar dos veces la misma transacción.

Los cuatro caminos: QR, microSD, NFC y USB

QR. El ordenador muestra la transacción como un QR, o como una secuencia animada si es grande, y el firmador la lee con su cámara. Para devolverla, el firmador muestra otro QR y lo lee la cámara del ordenador. Es un canal visible y estrecho: con el firmador solo se comunica lo que ve su cámara. Se vuelve lento con PSBT grandes, como los de multifirma o con muchas entradas.

microSD. Cabe un PSBT de cualquier tamaño y es lo más compatible. Coldcard pide una tarjeta FAT32. El inconveniente es que la tarjeta pasa por el ordenador, que puede escribir lo que quiera en ella. De nuevo, la defensa es la pantalla del firmador.

NFC. Es un enlace de radio de muy corto alcance: acercas el aparato al móvil o al lector, a menos de 4 cm según Coldcard, y el PSBT pasa sin cable. Con la definición del principio, el NFC no es firma sin conexión: es un enlace de datos por radio con un aparato conectado. Coinkite lo cuenta entre sus métodos sin conexión porque cada toque es corto y no deja ninguna sesión abierta, a diferencia de Bluetooth. En la Coldcard viene apagado por defecto y hay que activarlo en los ajustes. Pero apagarlo es un ajuste del firmware, y la antena sigue ahí. En la Q, además, Coinkite permite bloquear los datos por NFC y USB de forma irreversible cortando una pista de la placa (coldcard.com/q, consultada el 2026-10-07). Si no quieres ninguna radio, elige un aparato que no la tenga.

USB. El flujo PSBT es el mismo, pero hay un cable de datos entre el firmador y el ordenador. Eso es una conexión, no firma sin conexión. Puede ser una elección razonable por comodidad, siempre que se entienda lo que se cede: el aislamiento ya no es el mismo. Un cable que solo da corriente, o las pilas, no cuentan como conexión.

Dos formatos de QR: UR y BBQr

Un PSBT de una firma suele caber en un solo QR (Coldcard dice que basta para una transacción normal de una firma). Los grandes (multifirma, muchas entradas) no caben, así que se trocean en cuadros. Para eso hay dos especificaciones y no son intercambiables.

UR (Uniform Resources), de Blockchain Commons (BCR-2020-005, versión 2.1.0, revisada el 21 de agosto de 2023). Usa datos CBOR codificados con Bytewords y un formato ur:tipo/mensaje. Cuando hay varias partes, emplea un sistema de redundancia (fountain codes): el lector recompone el mensaje con cualquier subconjunto suficiente de cuadros, en cualquier orden, y se recupera aunque se pierdan algunos. El registro de Blockchain Commons pide escribir ur:psbt y dejar el antiguo ur:crypto-psbt solo para leer (BCR-2020-006, revisado el 26 de abril de 2025). Pero muchos programas siguen escribiendo el antiguo: Sparrow, por ejemplo, a octubre de 2026. Ver uno u otro en pantalla es normal.

BBQr, de Coinkite. Cada cuadro lleva una cabecera fija de 8 caracteres: B$, la codificación, el tipo de fichero (P para PSBT) y dos pares de dígitos en base 36 con el total de QR y el índice del actual. Admite hasta 1.295 partes. La diferencia práctica con UR: hay que leer todos los cuadros, sin saltarse ninguno, aunque da igual el orden. Con UR basta un subconjunto suficiente.

La lista de programas compatibles con BBQr la comprobó Coinkite el 27 de julio de 2026 contra su código publicado. Entre otros, Coldcard Q, Sparrow, Nunchuk Desktop, BTCPay Server y Krux leen y escriben BBQr. SeedSigner, en su versión 0.8.7, solo lo lee.

Antes de comprar o configurar nada, comprueba qué formato entiende cada lado. Sparrow elige por su cuenta BBQr o UR según el modelo de aparato que tengas configurado. Ninguno de los dos formatos cifra: son codificaciones. Un PSBT no contiene lo necesario para gastar, pero sí datos privados: entradas, salidas, rutas y a veces las xpub, que dan todo tu historial. Quien fotografíe la pantalla ve la transacción.

Lo que el aislamiento no resuelve

Sin conexión no quiere decir sin riesgo. Contra un firmware malicioso, el aislamiento no protege. Todo lo que sale del aparato (el fichero, el QR, la propia firma) puede llevar escondida tu seed phrase, o la clave maestra que sale de ella. En la firma ni siquiera se puede detectar, porque es la parte que tiene que llegar a la red. Así funciona Dark Skippy: el firmware usa como número aleatorio de cada firma (nonce) trozos de la seed, y según sus autores con dos firmas basta para sacar una de 12 palabras. Lo que sí hace el aislamiento es dificultar que alguien meta ese firmware por el cable.

Contra eso sirven el firmware verificado, una multifirma que no use el mismo aparato para todas las claves y el anti-exfil: el ordenador añade aleatoriedad a la firma para que el aparato no pueda esconder nada en ella. Según la página de mitigaciones de Dark Skippy (2024), lo ofrecían Jade y BitBox, y solo para firmas ECDSA, no para las de Taproot. Para tenerlo, el aparato tiene que firmar conectado a una aplicación que lo pida; por QR o por microSD no hay anti-exfil. Y ni siquiera conectado basta. En Jade solo lo usan las aplicaciones que firman con su orden sign_tx, como Blockstream App (antes Green), que se apoya en la biblioteca gdk de Blockstream; las que le pasan un PSBT no lo usan, y así firma también Sparrow por cable, según los controladores de Jade de HWI y de Lark. Así que, si firmas sin conexión, con una aplicación que no lo usa o desde direcciones Taproot, no cuentes con esa protección. Pregunta a tu aplicación si lo usa.

En multifirma, el firmador tiene que tener registrada la política completa (quórum y todas las xpub), no solo su propia clave. Sin ella no puede demostrar que el cambio vuelve a la misma billetera (BIP-388).

Qué significa esto para ti

Elige el camino con el que puedas ser disciplinado: el QR cuando el PSBT es pequeño, la microSD cuando es grande. Y haz siempre lo mismo antes de aprobar: leer en el firmador destino, importe, comisión y cambio, sin fiarte de la pantalla del ordenador.

Antes de mover el grueso, haz el recorrido entero con una cantidad pequeña: recibe en una dirección que hayas comprobado en el firmador y gástala de vuelta por el mismo camino. En multifirma, firma con cada aparato. Eso prueba que el flujo funciona. No prueba que el firmware sea honrado: para eso está verificarlo.

Las prestaciones de cada modelo están en sus propias entradas, como Coldcard Q y Sparrow Wallet. Qué amenazas cubre cada decisión se ve en modelo de amenazas.

Errores habituales

  • Creer que, si el aparato no tiene conexión, nada puede salir mal: el ordenador puede mandarte un PSBT trampa (te salva la pantalla del firmador) y un firmware malicioso puede filtrar tus claves por las firmas.
  • Pensar que firmar por USB también es firmar sin conexión: hay un cable de datos. El flujo PSBT es el mismo, el aislamiento no.
  • Comprobar la transacción en la pantalla del ordenador: se comprueba en la del firmador. La otra puede mentir.
  • Firmar otra vez la misma transacción porque el ordenador dice que la primera firma falló: con direcciones bc1q o 3… de SegWit anidado, dos firmas pueden bastar para convertir casi todo un UTXO en comisión.
  • Creer que el QR va cifrado: UR y BBQr son codificaciones. Un PSBT no puede gastar, pero revela entradas, salidas, rutas y a veces las xpub.
  • Dar por hecho que UR y BBQr son lo mismo o que cualquier aparato lee los dos: son especificaciones distintas y hay que ver cuál admite cada lado.
  • Pensar que en multifirma basta con que el firmador conozca su propia clave: sin la política completa registrada no puede validar ni el cambio ni las direcciones.
  • No mirar el cambio porque «es mío de todas formas»: es por donde se cuela una salida del atacante.

Conceptos relacionados

Fuentes primarias

  1. Ava Chow, «BIP-174: Partially Signed Bitcoin Transaction Format» (2017)
  2. Ava Chow, «BIP-370: PSBT Version 2» (2021)
  3. BIP-341: Taproot, nota sobre los importes de todas las entradas
  4. BIP-388: Wallet Policies for Descriptor Wallets
  5. NVD, «CVE-2020-14199» (2020)
  6. Trezor, «Details of firmware updates for Trezor One (1.9.1) and Model T (2.3.1)» (2020)
  7. Blockchain Commons, «BCR-2020-005: Uniform Resources (UR)» (v2.1.0, 2023)
  8. Blockchain Commons, «BCR-2020-006: UR Registry of Types» (revisado en 2025)
  9. Coinkite, «BBQr: Better Bitcoin QR»
  10. Coinkite, lista de compatibilidad de BBQr (verificada el 27 de julio de 2026)
  11. Coldcard, «Bitcoin Air-Gap Signing Methods» (revisada el 5 de junio de 2026)
  12. Coldcard, firmware 5.6.3 (Mk4) y 1.5.3Q (Q): shared/auth.py, función _save_to_disk (consultado el 2026-10-07)
  13. Sparrow Docs, «Airgapped wallet: QR»
  14. Sparrow, código de HeadersController (PSBT por QR)
  15. Dark Skippy
  16. Blockstream, documentación del protocolo de Jade (sign_tx y sign_psbt)
  17. Dark Skippy, «Mitigations» (2024)
  18. HWI, controlador de Jade (hwilib/devices/jade.py; consultado el 2026-10-07)
  19. Lark (Sparrow), controlador de Jade (JadeDevice.java; consultado el 2026-10-07)
  20. Blockstream gdk, «Green C/C++ SDK» (ga_auth_handlers.cpp, consultado 2026-10-07)
  21. Blockstream, README de green_android: la aplicación se llama hoy Blockstream App (consultado el 2026-10-07)