Billetera de hardware para pagos de un pool: qué protege de verdad y qué se rompe con depósitos pequeños y frecuentes
El minero suele comprar una billetera de hardware después del primer susto: un exchange que pregunta por el origen de los fondos, o simplemente un saldo que ya da miedo tener en una app del teléfono. A partir de ahí empieza una práctica de la que casi no se habla en las reseñas de dispositivos. El pool paga a menudo y en montos pequeños, el dispositivo está pensado para operaciones grandes y poco frecuentes, y esos dos regímenes encajan peor de lo que parece en la ficha del producto.
Quién escribe esto: POOL BTC no es un pool, ni una billetera, ni una tienda de hardware. Es un sitio independiente de comparación de pools, calculadoras y servicios, así que al final del texto no hay ningún dispositivo que vender. Lo que sigue es mecánica y orden de pasos, no una recomendación financiera o legal personalizada.
El debate entre billetera propia y custodial, junto con el análisis de bloqueos, se trata aparte en el artículo sobre billetera custodial o propia para los pagos. Los tipos de billetera, el polvo de UTXO y el umbral de pago están en el material sobre billetera para pagos de mineros. Aquí asumimos que ya se decidió usar una clave propia, y solo se revisa el trabajo con el dispositivo.
¿Qué protege una billetera de hardware y qué no?
La billetera de hardware protege la clave privada de lo que ocurre en tu computadora: virus, portapapeles, instaladores de billetera manipulados, acceso remoto. La clave se genera dentro del dispositivo y no sale de ahí, la transacción se firma en el mismo lugar. Todo lo demás sigue siendo tu propia responsabilidad.
La lista de lo que el dispositivo no evita no se hace más corta con el precio:
- Pérdida o robo de la frase seed. Quien tiene esas palabras no necesita tu dispositivo.
- Firmar una transacción sin verificarla en la pantalla del dispositivo. Un malware en la computadora puede cambiar la dirección de destino, y la única defensa es comparar con los propios ojos.
- Coacción física. El dispositivo no distingue entre vos y la persona que está parada al lado.
- Error al escribir la dirección de pago en el panel del pool. El pool envía a donde vos indicaste.
- Preguntas del exchange sobre el origen de los fondos. El hardware no influye en absoluto en el cumplimiento normativo.
Un punto aparte sobre la compra. El dispositivo debe generar el seed él mismo durante la primera configuración. Una tarjeta lista con las palabras ya escritas dentro de la caja significa que la billetera no la creaste vos. Comprar a un vendedor externo en un marketplace ahorra un poco y suma un riesgo difícil de verificar en casa.
¿En qué se diferencia una billetera de hardware de una billetera de teléfono y de una dirección de exchange?
La diferencia está en dónde vive la clave y quién puede firmar la transacción. En la billetera del teléfono, la clave está en un dispositivo conectado a internet. En el exchange no tenés clave en absoluto, hay un registro en la base de datos del servicio. En la billetera de hardware la clave está aislada, y el teléfono o la computadora funcionan solo como pantalla y canal de comunicación con la red.
| Criterio | Billetera de hardware | Billetera en teléfono o escritorio | Dirección de exchange |
|---|---|---|---|
| Dónde está la clave privada | dentro del dispositivo | en el teléfono o la computadora | en poder del servicio |
| Quién firma la transacción | vos, con un botón en el dispositivo | el software en el dispositivo conectado | el servicio, a tu pedido |
| Riesgo por un virus en la computadora | no es posible firmar sin tu confirmación | la clave puede ser robada | no aplica |
| Bloqueo de fondos por un tercero | imposible sin la clave | imposible sin la clave | posible |
| Estabilidad de la dirección de pago | dirección fija | dirección fija | la dirección de depósito puede rotar |
| Comodidad para operaciones pequeñas y frecuentes | baja, cada gasto exige el dispositivo | alta | alta |
| Qué se pierde si se rompe el dispositivo físico | nada, si tenés el seed | nada, si tenés el seed | nada, el acceso es por login |
| Costo de entrada | precio del dispositivo | cero | cero |
La conclusión práctica de la tabla no es que el hardware sea mejor. Es peor en comodidad y cuesta dinero, y gana exactamente en un escenario: cuando el saldo ya es lo bastante grande como para que el robo de la clave desde una laptop signifique el fin de toda la historia de minería.
¿Cómo configurar la recepción de pagos del pool en una billetera de hardware?
El orden es casi el mismo en todos los fabricantes: el dispositivo crea la billetera, obtenés la dirección, la verificás en la pantalla del dispositivo y la pegás en la configuración de pagos del pool. Un pago de prueba por un monto pequeño antes de mover todo el flujo es obligatorio, porque el pool puede aceptar o no ese formato de dirección.
- Desempaquetá el dispositivo y revisá la integridad del embalaje antes de encenderlo.
- Actualizá el firmware a través de la app oficial del fabricante, no con un enlace de un correo o de una búsqueda.
- Creá una billetera nueva en el dispositivo y dejá que genere el seed él mismo.
- Anotá el seed en papel o metal. No lo fotografíes, no lo tipees en el teclado, no lo guardes en notas ni en la nube.
- Verificá el seed con el procedimiento de recuperación que ofrece el propio dispositivo antes de enviar el primer dinero a la dirección.
- Obtené la dirección de recepción y comparala con lo que muestra la pantalla del dispositivo, no solo la de la computadora.
- Pegá la dirección en el campo de pago del panel del pool y guardá la configuración.
- Esperá el primer pago y confirmá que aparece en la billetera.
- Anotá en tu propia tabla qué dirección corresponde a qué pool y a qué worker.
Lo que más rompe el paso 7 es el formato de dirección. Braiins Pool, Ocean y Kryptex confirman oficialmente las direcciones Taproot tipo bc1p como dirección de pago. ViaBTC enumera oficialmente solo legacy, P2SH y bech32. El resto de los pools de nuestro relevamiento simplemente no detalla el formato en su ayuda, lo que significa que no hay confirmación, no que esté rechazado. Hay que verificarlo en el panel propio, y mejor con un pago de prueba. Comparar las condiciones entre pools es cómodo con la calculadora de rentabilidad.
¿Qué son la frase seed y el passphrase, y cómo guardarlos para no perder el acceso?
La frase seed es un conjunto de palabras del que se derivan de forma determinista todas las claves y direcciones de la billetera. El estándar BIP-39 describe una mnemónica de 12, 15, 18, 21 o 24 palabras. El passphrase es una palabra o cadena adicional sobre el seed: con ella, las mismas palabras generan otra billetera, y sin ella, la original.
De esto se derivan dos cosas que suelen confundirse. El passphrase no es la contraseña del dispositivo ni un PIN: un passphrase olvidado no se puede recuperar, porque la billetera con ese passphrase existe exactamente como resultado de un cálculo. Y el seed sin passphrase sigue siendo una billetera funcional, solo que vacía o con otro monto, si guardás lo principal en la oculta.
Qué dice la documentación oficial sobre modelos concretos al 09.09.2026:
| Modelo | Frase seed en la configuración | Passphrase |
|---|---|---|
| Trezor Safe 3 | 12 palabras BIP39 por defecto, también admite 12, 18 y 24 palabras BIP39 y SLIP39 | sí, billeteras ocultas |
| Trezor Safe 5 | 20 palabras SLIP39 en un solo share por defecto, mediante Legacy Backup Types se pueden usar 12 y 24 palabras BIP39 | sí, varias billeteras con passphrase distinto |
| Coldcard Q | 12 o 24 palabras BIP39 | sí, ingreso por teclado, por CLI, por microSD o por QR |
| Coldcard Mk4 | 12 o 24 palabras BIP39 | sí, ingreso directo en el dispositivo |
| Coldcard Mk5 | 12 o 24 palabras BIP39 según la documentación general de la línea | sí, según la documentación general de Coldcard |
| Ledger Nano S Plus | 24 palabras, Secret Recovery Phrase estándar | declarada en la documentación como la palabra número 25 |
| Ledger Nano X | 24 palabras, Secret Recovery Phrase estándar | declarada en la documentación como la palabra número 25 |
Fuentes sobre Trezor: FAQ de Trezor Safe 3, FAQ de Trezor Safe 5, sobre la longitud del backup. Sobre Coldcard: BIP-39 Passphrase en la documentación y configuración de Coldcard Q. No encontramos una página oficial separada sobre la configuración del Mk5 que indique explícitamente la longitud de la frase, así que para el Mk5 nos basamos en la documentación general de la línea.
Una aclaración aparte sobre Ledger, y es honesta. El soporte de passphrase para Nano S Plus y Nano X está declarado en la ayuda del fabricante (sobre las 24 palabras, sobre el passphrase), pero no logramos obtener el contenido de esas páginas directamente ni citar la formulación exacta. Antes de armar un esquema de guarda en la billetera oculta de Ledger, abrí vos mismo la ayuda actual del fabricante y verificala.
Qué hacer con el soporte físico:
- El papel dura hasta la primera inundación o incendio. Una placa metálica resuelve ese problema y cuesta bastante menos que el contenido de la billetera.
- Guardar la copia en el mismo lugar que el dispositivo significa que robar un bolso resuelve las dos cosas que busca un ladrón a la vez.
- Dividir el seed en dos mitades en dos lugares no da el doble de seguridad, sino dos lugares donde una mitad de la frase queda sin ninguna protección. Para dividirlo existen esquemas propios, como el reparto de secreto en los mismos dispositivos.
- El passphrase se guarda separado del seed y solo vos podés recuperarlo.
- Los herederos y allegados deben saber qué hacer con ese sobre, o de lo contrario la copia de respaldo protege el dinero incluso de vos mismo.
Una noticia aparte de 2026 sobre la confiabilidad de la generación, que vale la pena conocer sin importar la marca del dispositivo. Coinkite publicó una advertencia sobre un bug de generación de entropía en Coldcard: tras la migración de 2021 a libsecp256k1, una coincidencia de nombres de funciones hizo que, al compilar el firmware, el seed tomara la entropía del generador por software de MicroPython en lugar de la fuente de hardware dedicada. Están afectados los seeds creados entre 2021 y julio de 2026. En el Mk3 con firmware 4.0.1 o posterior, el espacio de búsqueda efectivo cayó a aproximadamente 40 bits en lugar de 128; en el Mk4, Mk5 y Q, la entropía adicional de los elementos seguros compensó parcialmente el problema, pero la fortaleza efectiva se estima igual en unos 72 bits. La recomendación del fabricante: actualizar a los firmwares corregidos (4.2.0 para Mk2 y Mk3, 5.6.1 para Mk4 y Mk5, 1.5.1Q para Q), generar un seed nuevo y transferir los fondos, agregando además entropía propia al generarlo, no menos de 65 pulsaciones de teclas, o 50 tiradas de dado, o 128 tiradas de moneda. Fuentes primarias: Coldcard Security Advisory, análisis técnico de la entropía, Security Update 5.6.1 y 1.5.1Q, consultado el 09.09.2026.
No encontramos advertencias oficiales similares sobre bugs de generación de seed o direcciones en Trezor y Ledger en esta pasada. Esto es exactamente una búsqueda incompleta, no una afirmación de que tales advertencias no existieron: no llegamos a revisar a fondo las secciones de seguridad de ambos fabricantes. La conclusión para el dueño no depende de la marca: un seed generado una vez no queda válido para siempre por defecto, y vale la pena abrir la página de seguridad del propio fabricante al menos una vez por trimestre.
¿Por qué los pagos pequeños y regulares a una misma dirección generan un problema con los UTXO y las comisiones?
Porque en Bitcoin la comisión se paga por el tamaño de la transacción, no por el monto. Cada pago del pool se registra en la billetera como un output no gastado independiente, y al gastarlo cada uno de esos outputs hay que incluirlo como input. Cien depósitos pequeños se convierten en cien inputs, y el precio de eso lo conocés en el momento de enviar, no en el momento de recibir.
El orden de magnitud es más fácil de mostrar con un input tipo P2WPKH de unos 68 vB de peso. Con una tarifa de 1 sat/vB, gastarlo cuesta unos 68 satoshis; con 200 sat/vB, ya son unos 13.600 satoshis (Spark, UTXO Management Guide, verificado el 27.08.2026). Un pago menor a esa cifra queda en el saldo como una cifra, pero económicamente no se mueve mientras la red no se descongestione.
En la billetera de hardware esta historia es más dolorosa que en una billetera caliente, por dos razones. Firmar una transacción con muchos inputs exige confirmación en el dispositivo, y en algunos modelos choca con los límites de la interfaz y de la memoria. Y la consolidación en sí, es decir juntar varios outputs pequeños en uno solo, exige sacar el dispositivo, conectarlo y hacer la operación a mano, y es cómodo postergarla justo hasta el momento en que las comisiones están altas.
Qué se hace en la práctica con esto:
- Subir el umbral de pago en el panel del pool para que un depósito supere claramente el costo de gastar un input a una tarifa alta.
- Recibir el flujo en una billetera caliente con coin control, y enviar a la billetera de hardware el monto consolidado cada cierto período.
- Consolidar en días de baja carga de red, no según un calendario fijo.
- No perseguir el umbral mínimo por depósitos diarios: la frecuencia es agradable psicológicamente y cara al gastar.
Cómo se relaciona el umbral con el tiempo de espera del primer depósito se analizó en el artículo sobre el tiempo hasta el primer pago de un pool.
¿Hace falta una dirección distinta para cada pago, y cómo funciona eso con el xpub?
Para la privacidad y el registro contable, una dirección distinta por cada depósito es útil, pero el pool casi siempre acepta en la configuración de pagos exactamente una dirección estática, no una clave pública extendida. Por eso, en la práctica el minero termina reutilizando repetidamente una misma dirección y resuelve el tema de otra manera: una dirección distinta por cada pool, no por cada pago.
Un mecanismo que vale la pena entender. Las billeteras modernas son jerárquicas y deterministas: de un solo seed se deriva un árbol de claves, y la clave pública extendida a nivel de cuenta (xpub, y en los formatos bech32 y Taproot, zpub y sus equivalentes) permite generar cualquier cantidad de direcciones de recepción sin acceso a las claves privadas. Por eso una billetera watch-only en la computadora ve todos los ingresos, pero no puede gastar nada.
Revisamos la documentación pública de nueve pools al 09.09.2026. Ninguno está confirmado como que acepte xpub en el campo de pago. Aun así, los estatus entre pools son distintos, y vale la pena tener presente la diferencia.
| Pool | Qué dice la documentación oficial | Estatus del xpub |
|---|---|---|
| Luxor | la dirección de pago se configura manualmente con New Wallet Address, solo dirección BTC estática (Luxor Pool Reference) | confirmado que la dirección es estática |
| Ocean | direcciones BTC comunes y pagos por Lightning vía BOLT12, no se menciona xpub (OCEAN, Lightning Payouts) | confirmado que la dirección es estática |
| Kryptex | los pagos quedan atados de forma fija a la dirección con la que el worker empezó a trabajar (Kryptex Pool, Address) | confirmado que la dirección es estática |
| F2Pool | solo se describen reglas para direcciones de mainnet, no se menciona xpub (F2Pool, notes for payout address) | no se pudo verificar |
| AntPool | la configuración se describe como una única dirección BTC o BCH (AntPool, Wallet Address) | no se pudo verificar |
| ViaBTC | no se encontró una página específica con respuesta explícita | no se pudo verificar |
| Braiins Pool | se describe el agregado de direcciones comunes mediante Add New Wallet (Braiins Academy, Rewards and Payouts) | no se pudo verificar |
| EMCD | la configuración se describe como una única dirección externa con confirmación por correo (EMCD, cómo funcionan los pagos) | no se pudo verificar |
| NiceHash | los pagos van a la billetera interna de NiceHash, no hay datos sobre un xpub externo (NiceHash, pago a billetera externa) | no se pudo verificar |
La diferencia entre las dos formulaciones es clave. «Confirmado que la dirección es estática» significa que el propio pool describió el campo como una sola dirección. «No se pudo verificar» significa exactamente eso: en la documentación pública no hay ni una palabra sobre xpub, ni a favor ni en contra, y eso no puede tomarse como un rechazo. La conclusión práctica para el minero es la misma en ambos casos: hoy no se puede contar con la rotación de direcciones de recepción vía xpub del lado del pool, y eso golpea directamente la privacidad, porque todo el historial de pagos de un pool se acumula en una sola dirección, visible para cualquiera que la conozca.
De esto se desprenden los siguientes pasos:
- Se crea una dirección distinta por cada pool, no por cada pago. Así, en el explorador se ve cuánto trajo cada pool, y el historial de un pool no se mezcla con el de otro.
- La copia de respaldo del xpub se guarda junto con los registros contables: permite recuperar la lista de direcciones y todo el historial sin recurrir al seed.
- Cambiar la dirección de recepción dentro de la misma billetera no requiere un dispositivo nuevo ni un seed nuevo, es simplemente la siguiente dirección del mismo árbol, y nada impide cambiarla a mano cada cierto período.
- La reutilización repetida de una misma dirección no compromete la seguridad de los fondos, pero revela el vínculo entre todos los ingresos a cualquiera que conozca esa dirección tuya.
¿Qué hacer al cambiar de pool o de billetera?
Cambiar de pool se reduce a cambiar la dirección en el nuevo panel y controlar el saldo del anterior: el pool paga lo acumulado según su umbral, y el dinero por debajo del umbral puede quedar pendiente hasta alcanzarlo. Cambiar de billetera implica transferir los fondos a las nuevas direcciones con tu propia transacción, porque el seed viejo sigue siendo funcional mientras haya algo en sus direcciones.
Orden al migrar a un dispositivo nuevo:
- Configurá el dispositivo nuevo y creá en él una billetera nueva con un seed nuevo.
- Obtené la dirección de recepción y verificala en pantalla.
- Cambiá la dirección de pago en el panel de cada pool en el que trabajás.
- Esperá a que el pool o los pools viejos completen el saldo hasta el umbral y lo paguen a la dirección vieja.
- Transferí el saldo de la billetera vieja a la nueva con una sola transacción, en un período tranquilo por comisiones.
- No destruyas el seed viejo de inmediato: guardalo hasta confirmar que las direcciones viejas están vacías.
- Actualizá la tabla de correspondencia entre direcciones, pools y workers, para que el registro anual se arme sin arqueología.
Cuánto se pierde en la migración entre pools, en dinero y tiempo, se calculó en el material sobre el costo de cambiar de pool.
¿Qué pasa si el dispositivo se rompe, se pierde o el fabricante deja el mercado?
Los fondos están en la blockchain, no en el dispositivo, así que perder el hardware solo significa perder el acceso si también se pierde el seed. Un seed compatible con BIP-39 se recupera en otra billetera, incluso de otro fabricante y puramente por software. Justamente eso hace que la pregunta «¿y si el fabricante cierra?» sea menos aterradora de lo que suena.
Esta protección tiene una sola condición, y hay que verificarla antes de comprar, no después: formato de seed estándar y rutas de derivación estándar. Una billetera con un formato de mnemónica propio y no estándar te ata a un único fabricante, y ahí sí su salida del mercado se vuelve un problema real. Lo segundo que vale la pena anotar junto con el seed es el tipo de direcciones y la ruta de derivación, o la recuperación en un software ajeno mostrará un saldo vacío aun con las palabras correctas.
No damos aquí nombres ni fechas concretos de fabricantes que hayan dejado el mercado: no logramos encontrar en esta pasada ejemplos confirmados por anuncios oficiales, y no encontrarlos no equivale a que no hayan existido. Lo que sí está documentado, y es más útil, es otra cosa: un fabricante puede reconocer públicamente su propio error y pedir a los dueños que regeneren el seed, como hizo Coinkite en el episodio de la entropía descrito arriba. Para el dueño, ese evento es más probable y más costoso en tiempo que un hipotético cierre de la empresa, y en ambos casos la protección es exactamente la misma: seed estándar y ruta de derivación anotada.
Qué hacer si se pierde el dispositivo:
- Considerá que el PIN protege de un intento rápido de acceso, pero no indefinidamente.
- Recuperá el seed en un dispositivo nuevo o en una billetera por software.
- Transferí los fondos a una billetera nueva con un seed nuevo si hay dudas sobre la integridad de las palabras.
- Cambiá la dirección de pago en todos los pools después de la transferencia.
Qué mirar en el propio dispositivo y qué está confirmado oficialmente
Para pagos regulares de un pool, el hardware no se elige por la marca ni por la pantalla. Lo que importa es el tipo de dirección que puede entregar para recepción, la apertura del firmware, el comportamiento al firmar una transacción con muchos inputs, y qué tan activo es el canal de seguridad del fabricante. Los primeros tres puntos se verifican por documentación, el cuarto por el historial de divulgaciones, como el caso de Coldcard con la entropía.
Abajo se reúnen los datos oficiales de los fabricantes al 01.09.2026. Los precios en dólares estadounidenses son de las páginas de los fabricantes, la última columna se refiere al escenario de minería, no a una reseña general de los modelos.
| Modelo | Precio | Taproot para dirección de recepción | Firmware abierto | Qué significa con flujo de pagos |
|---|---|---|---|---|
| Trezor Safe 5 | 129 dólares | sí | sí | bc1p disponible de entrada, pero no todos los pools lo aceptan |
| Trezor Safe 3 | 59 dólares | sí, firmware Trezor Core | sí | la opción más barata para resolver la guarda con el mismo set de formatos de dirección |
| Trezor Model One | no se fijó en fuente oficial en esta pasada | sin confirmación encontrada, dispositivo con firmware de la rama 1.x | sí | no se puede contar con Taproot, para recepción quedan los formatos antiguos |
| Coldcard Q | 289 dólares | solo en el firmware Edge, no en la rama principal | sí | manejo manual de inputs más profundo que el resto, lo cual suma para la consolidación |
| Coldcard Mk5 | 189 dólares | solo en el firmware Edge, no en la rama principal | sí | firma sin conectarse a una computadora, pero cada consolidación es un ritual con tarjeta de memoria |
| Ledger Nano Gen5, Flex, Stax, Nano X, Nano S Plus | no se fijó una cifra en las páginas oficiales | no se obtuvo una formulación oficial directa | no se obtuvo una formulación oficial directa | compatibilidad amplia con software de terceros, el resto debe considerarse desconocido hasta verificarlo |
Los precios de Trezor y Coldcard se tomaron de trezor.io y store.coinkite.com. Ledger, en esta pasada, no dio en sus páginas ni una cifra de precio ni una formulación directa sobre Taproot y apertura del firmware, así que las celdas correspondientes están marcadas como no verificadas, y no rellenadas de memoria. Esto debe leerse como «no encontramos confirmación», no como «la función no existe». El precio de Trezor Model One entró en esta lista por la misma razón.
Sobre Coldcard vale la pena hablar más claro de lo que se ve en la tabla. Taproot vive ahí en un canal de lanzamiento separado, Edge, que el propio fabricante describe como una rama para funciones aún no listas para uso masivo. Si necesitás bc1p como dirección de recepción de trabajo, y no como una línea en una ficha técnica, vas a tener que mantener el dispositivo en esa rama con todo lo que eso implica. Los modelos y sus diferencias se detallan más en la sección sobre billeteras de hardware.
¿Cuándo una billetera de hardware es excesiva para un minero?
Cuando el costo del dispositivo y el trámite que implica es comparable con el monto que guardás. Un solo ASIC doméstico con pagos diarios de unos pocos cientos de satoshis y venta inmediata al recibirlos no ofrece el equilibrio por el que se compra hardware. En ese escenario gana una billetera caliente con coin control y el umbral de pago elevado.
Situaciones donde la billetera de hardware suma más problemas de los que resuelve:
- Vendés lo minado de inmediato y casi no acumulás nada.
- Los pagos llegan tan pequeños que cada uno está cerca del costo de gastar un input.
- No estás listo para la disciplina de guardar el seed, y la copia de respaldo inevitablemente va a terminar en las fotos del teléfono.
- Estás probando la minería el primer mes y todavía no decidiste si vas a continuar.
El límite inverso también es claro. En cuanto en el saldo aparece un monto cuya pérdida cambiaría tus planes, la pregunta deja de ser «¿hace falta?» y pasa a ser «¿qué dispositivo y cómo guardo las palabras?».
Checklist corto
- El dispositivo se compró al fabricante y generó el seed él mismo en la primera configuración.
- El firmware está actualizado, se revisó la página de seguridad del fabricante.
- El seed está anotado offline, verificado con el procedimiento de recuperación y no está guardado junto al dispositivo.
- El passphrase, si existe, se guarda por separado y no se perdió.
- El formato de la dirección de pago se verificó en el panel del pool concreto con un monto de prueba.
- El umbral de pago está subido para no acumular polvo.
- Hay una dirección separada por cada pool, y la tabla de correspondencia se lleva desde el primer día.
- La copia del xpub está guardada para recuperar el historial sin el seed.
- El tipo de direcciones y la ruta de derivación están anotados junto con el seed.
- La consolidación de inputs se hace en períodos tranquilos por comisiones, no en el momento de una venta urgente.
Conclusión
La billetera de hardware resuelve una sola cosa: mantiene la clave privada fuera de la computadora, que puede estar infectada. Todo lo demás, incluido el polvo, las comisiones, el formato de dirección y el orden al cambiar de pool, sigue siendo trabajo organizativo, y es justamente eso lo que determina si el dispositivo va a ayudar o va a quedar en un cajón mientras los pagos se acumulan en la app del teléfono. Para el minero, el orden habitual suele ser este: la billetera caliente recibe el flujo, la de hardware guarda lo acumulado, se abre una dirección distinta por cada pool, y el seed queda offline en dos lugares y no en fotos.



