Carteira de hardware para os pagamentos do pool: o que ela realmente protege e o que quebra com créditos pequenos e frequentes

O minerador normalmente compra uma carteira de hardware depois do primeiro susto: ou a corretora fez uma pergunta sobre a origem dos fundos, ou simplesmente acumulou-se uma quantia que dá medo manter num aplicativo de celular. Depois começa a prática, sobre a qual as análises de dispositivos quase não falam. O pool paga com frequência e em valores pequenos, o dispositivo foi pensado para operações raras e grandes, e esses dois regimes se encaixam pior do que parece na vitrine da loja.

Quem escreve isto: POOL BTC não é pool, não é carteira e não é loja de hardware. É um site independente de comparação de pools, calculadoras e serviços, por isso no fim do texto não há nenhum dispositivo para vender. Abaixo vem a mecânica e a ordem das ações, não uma recomendação financeira ou jurídica pessoal.

A discussão entre carteira própria e custodial e a análise dos congelamentos estão separadas no artigo sobre carteira custodial ou própria para os pagamentos. Os tipos de carteira, a poeira e o limite de pagamento estão no material sobre carteira para pagamentos de mineração. Aqui partimos do princípio de que a decisão a favor da chave própria já foi tomada, e analisamos apenas o trabalho com o aparelho.

O que a carteira de hardware protege e o que não protege?

A carteira de hardware protege a chave privada daquilo que acontece no seu computador: vírus, área de transferência, instaladores de carteira adulterados, acesso remoto. A chave é gerada dentro do dispositivo e não sai dele, e a transação é assinada ali mesmo. Todo o resto continua sendo sua zona de responsabilidade.

A lista daquilo de que o dispositivo não salva não fica menor com o preço:

1. Perda ou roubo da seed-frase. Quem tem as palavras não precisa do seu dispositivo.
2. Assinatura de uma transação que você não conferiu na tela do próprio dispositivo. Um malware no computador pode trocar o endereço do destinatário, e a única proteção que resta é a conferência com os olhos.
3. Coação física. O dispositivo não distingue você da pessoa que está ao seu lado.
4. Erro ao digitar o endereço de pagamento no painel do pool. O pool vai enviar para onde você escreveu.
5. Perguntas da corretora sobre a origem dos fundos. O hardware não influencia em nada o compliance.

Um ponto à parte sobre a compra. O dispositivo deve gerar a seed sozinho na primeira configuração. Um cartão pronto com as palavras já escritas dentro da caixa significa que a carteira não foi criada por você. Comprar de um vendedor terceiro em marketplace economiza pouco e acrescenta um risco difícil de verificar em casa.

Qual a diferença entre a carteira de hardware, a carteira no celular e um endereço na corretora?

A diferença está em onde vive a chave e em quem pode assinar a transação. Na carteira do celular a chave fica num dispositivo conectado à internet. Na corretora você não tem chave nenhuma, existe um registro na base do serviço. Na carteira de hardware a chave está isolada, e o celular ou o computador funcionam apenas como tela e canal de comunicação com a rede.

A conclusão prática da tabela não é que o aparelho é melhor. Ele é pior em comodidade e custa dinheiro, e ganha exatamente num cenário: quando a quantia no saldo já é tal que o roubo da chave do notebook significa o fim de toda a história com mineração.

Como configurar o recebimento dos pagamentos do pool numa carteira de hardware?

A ordem é praticamente igual em todos os fabricantes: o dispositivo cria a carteira, você recebe o endereço, confere na tela do dispositivo e cola nas configurações de pagamento do pool. Um pagamento de teste de valor pequeno antes de transferir todo o fluxo é obrigatório, porque o formato do endereço o pool pode aceitar ou não.

1. Desembale o dispositivo e verifique a integridade da embalagem antes de ligar.
2. Atualize o firmware pelo aplicativo oficial do fabricante, e não por um link de e-mail ou de busca.
3. Crie uma carteira nova no dispositivo e deixe que ele gere a seed sozinho.
4. Anote a seed em papel ou metal. Não fotografe, não digite no teclado, não salve em notas nem na nuvem.
5. Verifique a seed pelo procedimento de recuperação que o próprio dispositivo oferece, antes de enviar o primeiro dinheiro para o endereço.
6. Obtenha o endereço de recebimento e confira obrigatoriamente com o que a tela do dispositivo mostra, e não apenas a tela do computador.
7. Cole o endereço no campo de pagamento do painel do pool e salve as configurações.
8. Aguarde o primeiro pagamento e confirme que ele aparece na carteira.
9. Anote na sua planilha qual endereço corresponde a qual pool e a qual worker.

O ponto que quebra o passo 7 com mais frequência: o formato do endereço. Oficialmente, endereços Taproot do tipo bc1p como endereço de pagamento são confirmados por Braiins Pool, Ocean e Kryptex. A ViaBTC lista oficialmente apenas legacy, P2SH e bech32. Os demais pools do nosso recorte simplesmente não detalham o formato na ajuda, o que significa ausência de confirmação, e não recusa. É preciso verificar no seu próprio painel, e melhor ainda com um pagamento de teste. Comparar as condições dos pools entre si é cômodo na calculadora de rentabilidade.

O que são a seed-frase e a passphrase e como guardá-las para não perder o acesso?

A seed-frase é um conjunto de palavras a partir do qual todas as chaves e endereços da carteira são derivados de forma determinística. O padrão BIP-39 descreve uma mnemônica de 12, 15, 18, 21 ou 24 palavras. A passphrase é uma palavra ou linha adicional por cima da seed: com ela, das mesmas palavras sai outra carteira, e sem ela sai a original.

Disso decorrem duas coisas que costumam ser confundidas. A passphrase não é a senha do dispositivo nem o PIN: uma passphrase esquecida não pode ser recuperada, porque a carteira com ela existe exatamente como resultado de um cálculo. E a seed sem passphrase continua sendo uma carteira funcional, apenas vazia ou com outra quantia, se você mantém o principal na carteira oculta.

O que diz a documentação oficial sobre modelos concretos em 09.09.2026:

Fontes sobre a Trezor: FAQ do Trezor Safe 3, FAQ do Trezor Safe 5, sobre o tamanho do backup. Sobre a Coldcard: BIP-39 Passphrase na documentação e configuração do Coldcard Q. Uma página oficial separada sobre a configuração do Mk5 com indicação explícita do tamanho da frase nós não encontramos, por isso para o Mk5 nos apoiamos na documentação geral da linha.

Uma ressalva à parte sobre a Ledger, e ela é honesta. O suporte a passphrase para o Nano S Plus e o Nano X está declarado na ajuda do fabricante (sobre as 24 palavras, sobre a passphrase), mas obter o conteúdo dessas páginas diretamente e citar a formulação nós não conseguimos. Antes de montar um esquema de guarda em carteira oculta da Ledger, abra a ajuda atual do fabricante com as próprias mãos e confira com ela.

O que fazer com o suporte físico:

1. O papel vive até a primeira inundação ou incêndio. A placa de metal resolve essa tarefa e custa bem menos do que o conteúdo da carteira.
2. Guardar a cópia no mesmo lugar do dispositivo significa que o roubo da bolsa resolve as duas tarefas do ladrão de uma vez.
3. Dividir a seed em duas metades em dois lugares não dá o dobro de segurança, dá dois lugares onde metade da frase está sem proteção nenhuma. Para a divisão existem esquemas próprios, como a divisão do segredo dentro dos próprios dispositivos.
4. A passphrase é guardada separadamente da seed e é recuperada somente por você.
5. Herdeiros e familiares precisam saber o que fazer com esse envelope, senão a cópia de segurança protege o dinheiro inclusive de você.

Uma notícia à parte de 2026 sobre a confiabilidade da geração, e vale a pena o dono de qualquer marca conhecê-la. A Coinkite publicou um aviso sobre um bug de geração de entropia na Coldcard: depois da migração, em 2021, para a libsecp256k1, a coincidência de nomes de funções fez com que, na compilação do firmware, a seed pegasse entropia do gerador de software do MicroPython, e não da fonte de hardware dedicada. Foram afetadas as seeds criadas de 2021 até julho de 2026. No Mk3 com firmware 4.0.1 e mais recente o espaço efetivo de busca caiu para cerca de 40 bits em vez de 128; no Mk4, Mk5 e Q a entropia adicional dos elementos seguros compensou parcialmente o problema, mas a resistência efetiva ainda assim é estimada em cerca de 72 bits. Recomendação do fabricante: atualizar para os firmwares corrigidos (4.2.0 para Mk2 e Mk3, 5.6.1 para Mk4 e Mk5, 1.5.1Q para o Q), gerar uma seed nova e transferir os fundos para ela, e além disso, na nova geração, acrescentar entropia própria, no mínimo 65 toques de tecla, ou 50 lançamentos de dado, ou 128 lançamentos de moeda. Fontes primárias: Coldcard Security Advisory, análise técnica da entropia, Security Update 5.6.1 e 1.5.1Q, consulta em 09.09.2026.

Avisos oficiais parecidos sobre bugs de geração da seed ou do endereço na Trezor e na Ledger nós não encontramos nesta rodada. Trata-se justamente de uma busca inacabada, e não de uma afirmação de que tais avisos não existiram: não tivemos tempo de percorrer a fundo as seções de segurança dos dois fabricantes. A conclusão para o dono não depende da marca: uma seed gerada uma vez não se torna eternamente válida por padrão, e a página de segurança do seu fabricante vale ser aberta ao menos uma vez por trimestre.

Por que pagamentos pequenos e regulares no mesmo endereço criam problema com UTXO e taxas?

Porque a taxa no bitcoin é paga pelo tamanho da transação, e não pelo valor. Cada pagamento do pool entra na carteira como uma saída não gasta separada, e, na hora de gastar, cada uma dessas saídas precisa ser incluída nas entradas. Cem créditos pequenos viram cem entradas, e o preço disso você descobre na hora do envio, não na hora do recebimento.

A ordem de grandeza fica mais fácil de mostrar numa entrada do tipo P2WPKH com peso de cerca de 68 vB. A uma taxa de 1 sat/vB, gastá-la custa por volta de 68 satoshis; a 200 sat/vB já são cerca de 13 600 satoshis (Spark, UTXO Management Guide, verificado em 27.08.2026). Um pagamento menor do que esse valor fica no saldo como número, mas economicamente não se move até a rede desafogar.

Na carteira de hardware essa história é mais dolorosa do que na quente, por duas razões. Assinar uma transação com muitas entradas exige confirmação no aparelho e, em alguns modelos, esbarra em limites de interface e de memória. E a própria consolidação, ou seja, juntar as saídas pequenas numa só, exige pegar o dispositivo, conectá-lo e fazer a operação à mão, e é cômodo adiar isso justamente até o momento em que as taxas estão altas.

O que se faz com isso na prática:

1. Elevam o limite de pagamento no painel do pool de modo que um crédito supere com folga o custo de gastar uma entrada com taxa alta.
2. Recebem o fluxo numa carteira quente com coin control, e para a de hardware enviam a quantia consolidada uma vez por período.
3. Consolidam em dias de rede tranquila, e não pelo calendário.
4. Não perseguem o limite mínimo para ter créditos diários: a frequência é agradável psicologicamente e cara na hora de gastar.

Como o limite se relaciona com o prazo de espera do primeiro crédito foi analisado no artigo sobre o tempo até o primeiro pagamento do pool.

É preciso um endereço separado para cada pagamento e como isso funciona via xpub?

Para privacidade e contabilidade um endereço separado para cada entrada é útil, mas o pool quase sempre aceita nas configurações de pagamento exatamente um endereço estático, e não uma chave pública estendida. Por isso, na prática, o minerador acaba com a reutilização múltipla de um mesmo endereço e resolve a questão de outro jeito: com um endereço separado por pool, e não por pagamento.

A mecânica que vale entender. As carteiras modernas são hierárquicas e determinísticas: de uma seed é derivada uma árvore de chaves, e a chave pública estendida no nível da conta (xpub, e nos formatos para bech32 e Taproot zpub e as correspondentes) permite gerar qualquer quantidade de endereços de recebimento sem acesso às chaves privadas. É exatamente por isso que uma carteira watch-only no computador enxerga todas as entradas, mas não consegue gastar nada.

Verificamos pela documentação aberta nove pools em 09.09.2026. Nenhum está confirmado como aceitando xpub no campo de pagamento. Ao mesmo tempo os status dos pools são diferentes, e vale guardar essa diferença na cabeça.

A diferença entre as duas formulações é fundamental. «Confirmado que o endereço é estático» significa que o próprio pool descreveu o campo como um endereço só. «Não foi possível verificar» significa exatamente o que está escrito: na documentação aberta não há uma palavra sobre xpub, nem a favor nem contra, e isso não pode ser tratado como recusa. A conclusão prática para o minerador é a mesma nos dois casos: contar hoje com rotação de endereços de recebimento via xpub do lado do pool não dá, e isso bate direto na privacidade, porque todo o histórico de pagamentos de um pool se junta num endereço e fica visível para qualquer um que conheça esse endereço.

O que decorre disso, passo a passo:

1. Um endereço separado é criado para cada pool, e não para cada pagamento. Assim, no explorador dá para ver quanto cada pool rendeu, e o histórico de um pool não se mistura com o de outro.
2. A cópia de segurança do xpub é guardada junto com os registros contábeis: ela permite restaurar a lista de endereços e todo o histórico sem recorrer à seed.
3. Trocar o endereço de recebimento dentro da mesma carteira não exige dispositivo novo nem seed nova, é apenas o próximo endereço da mesma árvore, e ninguém proíbe trocar o endereço à mão uma vez por período.
4. O uso repetido de um mesmo endereço não quebra a segurança dos fundos, ele revela a ligação de todas as entradas entre si para qualquer um que conheça um endereço seu.

O que fazer ao trocar de pool ou ao trocar de carteira?

Trocar de pool se resume a trocar o endereço no painel novo e controlar o saldo no antigo: o pool paga o acumulado conforme o seu limite, e o dinheiro abaixo do limite pode ficar pendurado até alcançá-lo. Trocar de carteira significa transferir os fundos para os novos endereços com uma transação sua, porque a seed antiga continua funcional enquanto houver algo nos seus endereços.

Ordem na mudança para um dispositivo novo:

1. Configure o dispositivo novo e crie nele uma carteira nova com seed nova.
2. Obtenha nele o endereço de recebimento e confira na tela.
3. Troque o endereço de pagamento no painel de cada pool em que você trabalha.
4. Espere até o pool ou os pools antigos completarem o resto até o limite e pagarem no endereço antigo.
5. Transfira o saldo da carteira antiga para a nova numa única transação, em período tranquilo de taxas.
6. Não destrua a seed antiga na hora: guarde-a até ter certeza de que os endereços antigos estão vazios.
7. Atualize a planilha de correspondência entre endereços, pools e workers, para que a prestação de contas do ano se monte sem arqueologia.

Quanto se perde na própria mudança entre pools, em dinheiro e em tempo, foi calculado no material sobre o preço de trocar de pool.

O que acontece se o dispositivo quebrar, se perder ou o fabricante sair do mercado?

Os fundos ficam no blockchain, e não no dispositivo, por isso perder o aparelho significa perder o acesso apenas se a seed for perdida. Uma seed compatível com BIP-39 é restaurada em outra carteira, inclusive de outro fabricante e puramente em software. É justamente isso que torna a pergunta «e se o fabricante fechar» menos assustadora do que soa.

Essa garantia tem uma condição, e ela precisa ser verificada antes da compra, não depois: formato padrão de seed e caminhos de derivação padrão. Uma carteira com formato de mnemônica próprio e fora do padrão prende você a um fabricante, e aí a saída dele vira mesmo um problema. A segunda coisa que vale anotar junto com a seed é o tipo de endereços e o caminho de derivação, senão a recuperação em software de terceiros vai mostrar saldo vazio com as palavras completamente corretas.

Nomes e datas concretos de fabricantes que saíram do mercado nós não trazemos aqui: exemplos confirmados por anúncios oficiais não conseguimos encontrar nesta rodada, e a ausência de achado não é o mesmo que a ausência de tais casos. Documentado está outra coisa, mais útil: um fabricante pode reconhecer publicamente o próprio erro e pedir aos donos que gerem a seed de novo, como fez a Coinkite na história da entropia acima. Para o dono esse evento é mais provável e mais caro em tempo do que o hipotético fechamento da empresa, e o seguro nos dois casos é o mesmo: seed padrão e caminho de derivação anotado.

O que fazer em caso de perda do dispositivo:

1. Considere que o PIN protege contra uma tentativa rápida de acesso, mas não para sempre.
2. Restaure a seed num dispositivo novo ou numa carteira de software.
3. Transfira os fundos para uma carteira nova com seed nova, se houver dúvida sobre a integridade das palavras.
4. Troque o endereço de pagamento em todos os pools depois da transferência.

No que reparar no próprio dispositivo e o que está confirmado oficialmente

Para pagamentos regulares de pool, o aparelho não se escolhe pela marca nem pela tela. O que importa é o tipo de endereço que ele consegue entregar para recebimento, a abertura do firmware, o comportamento ao assinar transação com muitas entradas e quão vivo é o canal de segurança do fabricante. Os três primeiros pontos se verificam pela documentação, o quarto pelo histórico de divulgações, como a história da Coldcard com a entropia.

Abaixo estão reunidos os dados oficiais dos fabricantes em 01.09.2026. Preços em dólares americanos, tirados das páginas dos fabricantes; a última coluna é sobre o cenário de mineração, e não sobre uma análise geral dos modelos.

Os preços de Trezor e Coldcard foram tirados de trezor.io e store.coinkite.com. A Ledger nesta rodada não deu, pelas suas páginas, nem preços em número nem formulação direta sobre Taproot e abertura do firmware, por isso as células correspondentes estão marcadas como não verificadas, e não preenchidas de memória. Isso deve ser lido como «não encontramos confirmação», e não como «a função não existe». O preço do Trezor Model One entrou nessa mesma lista pela mesma razão.

Sobre a Coldcard vale dizer de forma mais direta do que a tabela mostra. O Taproot ali vive num canal de release separado, o Edge, que o próprio fabricante descreve como o ramo para funções ainda não prontas para uso em massa. Se o bc1p é para você um endereço de trabalho para receber pagamentos, e não uma linha na especificação, será preciso manter o dispositivo nesse ramo com tudo o que isso implica. Os próprios modelos e suas diferenças estão analisados em detalhe na seção sobre carteiras de hardware.

Quando a carteira de hardware é excessiva para o minerador?

Quando o custo do dispositivo e da lida com ele é comparável à quantia que você guarda. Um ASIC doméstico com pagamentos diários de algumas centenas de satoshis e venda logo no recebimento não gera o saldo pelo qual se compra hardware. Nesse cenário ganha a carteira quente com coin control e o limite de pagamento elevado.

Situações em que a carteira de hardware acrescenta mais problemas do que resolve:

1. Você vende o minerado na hora e quase não acumula nada.
2. Os pagamentos chegam tão pequenos que cada um deles fica perto, em tamanho, do custo de gastar uma entrada.
3. Você não está pronto para a disciplina de guarda da seed, e a cópia de segurança vai inevitavelmente parar nas fotos do celular.
4. Você está testando mineração no primeiro mês e ainda nem decidiu se continua.

A fronteira inversa também é clara. Assim que aparece no saldo uma quantia cuja perda mudaria os seus planos, a questão passa do plano «é preciso ou não» para o plano «qual dispositivo e como guardar as palavras».

Checklist curto

1. O dispositivo foi comprado do fabricante e gerou a seed sozinho na primeira configuração.
2. Firmware atualizado, página de segurança do fabricante verificada.
3. Seed anotada offline, verificada pelo procedimento de recuperação e guardada longe do dispositivo.
4. A passphrase, se existir, é guardada separadamente e não foi perdida.
5. O formato do endereço de pagamento foi verificado no painel do pool concreto com um valor de teste.
6. O limite de pagamento foi elevado de modo a não acumular poeira.
7. Para cada pool foi criado um endereço separado, e a planilha de correspondência é mantida desde o primeiro dia.
8. A cópia do xpub está salva para restaurar o histórico sem a seed.
9. O tipo de endereços e o caminho de derivação estão anotados junto com a seed.
10. A consolidação de entradas é feita em períodos tranquilos de taxas, e não no momento de uma venda urgente.

Conclusão

A carteira de hardware resolve uma tarefa: ela mantém a chave privada fora do computador, que pode estar infectado. Todo o resto, incluindo poeira, taxas, formato do endereço e a ordem na troca de pool, continua sendo trabalho organizacional, e é justamente ele que define se o dispositivo vai ajudar ou ficar na gaveta enquanto os pagamentos se acumulam no aplicativo do celular. Para o minerador a ordem costuma ser esta: a carteira quente recebe o fluxo, a de hardware guarda o acumulado, um endereço separado é criado para cada pool, e a seed fica offline em dois lugares e não nas fotos.