O pool caiu: como saber que o problema não está no seu ASIC e o que fazer na primeira hora

*Last updated: 09.09.2026. POOL BTC.*

TL;DR

Quando o hashrate no painel do pool cai a zero, nem sempre a culpa é do pool. Na maioria dos casos a causa está entre o seu ASIC e o servidor stratum: roteador, provedor, alimentação, placa superaquecida, firmware recém-instalado. Dá para distinguir uma coisa da outra em cinco minutos, sem sair da frente do notebook: olhar o que o próprio minerador mostra, verificar se o pool caiu para outros mineradores e comparar o hashrate local com o do pool. A primeira hora vale gastar não com pânico nem com troca de pool, e sim com um diagnóstico em ordem e com a ativação do stratum reserva, que deveria estar na configuração desde antes.

A POOL BTC não é um pool, e sim um site independente de comparação de pools. Não atribuímos aqui falhas a nenhum pool específico: abaixo vem método, não a análise da queda de alguém.

Como distinguir uma queda do pool de um problema do seu lado?

O principal sinal de queda do pool: o minerador funciona, o hashrate no aparelho está normal, mas a conexão com o stratum cai ou os shares vão embora sem resposta. Já se no painel do próprio ASIC o hashrate afundou, os chips sumiram ou o aparelho reinicia em looping, o pool não tem nada a ver com isso, o problema está no hardware, na alimentação ou na rede até o provedor.

Vamos separar por sintomas. É preciso olhar dois lugares ao mesmo tempo: o painel do minerador (hashrate local) e a estatística da conta no pool (hashrate do pool).

Um caso à parte, o mais confundido com queda de pool: a configuração recém-feita. Se o hashrate nunca chegou a aparecer no pool, isso não é falha, e sim um erro de digitação no nome do worker ou uma porta fechada. A falha tem outra cara: funcionou por dias seguidos e parou de uma vez.

O que o painel do minerador mostra na queda de conexão e o que significam accepted, rejected e stale?

No painel do ASIC há três contadores por pool: accepted (shares aceitos), rejected (rejeitados), stale (chegaram tarde, o trabalho já não vale). Na queda da conexão com o stratum o status do pool muda para dead ou disconnected, o contador accepted congela e o minerador começa a tentar conexão com o próximo pool da lista, se houver algum ali.

O que está por trás das palavras:

• Accepted. O pool aceitou o seu share e contabilizou na estatística. É o único contador que vira dinheiro.
• Rejected. O pool recebeu o share, mas não contabilizou. As razões variam: trabalho desatualizado, duplicata, dificuldade baixa demais, erro de autorização.
• Stale. Caso particular de rejeição: o share foi calculado para uma tarefa que o pool já havia cancelado porque um bloco novo foi encontrado na rede. Quanto maior a latência até o servidor, mais isso acontece.
• Difficulty accepted. Em alguns firmwares aparece em linha separada a soma da dificuldade dos shares aceitos. Ela informa mais do que o contador de unidades, porque com vardiff a quantidade de shares por si só não diz nada.

Mais uma linha que vale observar: o tempo do último share aceito (last share). Se ele cresce e já passou de vários minutos com hashrate estável, a conexão está de fato morta, mesmo que o status do pool ainda esteja verde.

A mecânica dos shares e o porquê de a quantidade deles não ser igual à receita estão explicados com mais detalhe no artigo sobre os esquemas de pagamento FPPS e PPLNS.

Qual percentual de rejeições é considerado normal e qual já é um sinal?

Não existe número universal: a parcela de shares rejeitados depende da distância até o servidor stratum, da qualidade do canal, do firmware e das configurações de vardiff. É preciso se guiar não pelo valor absoluto, e sim pela sua própria linha de base: anote o seu percentual habitual num dia tranquilo e considere desvio tudo o que subir nitidamente acima dele e se mantiver.

Abordagem prática no lugar de um número mágico:

1. Meça a parcela de rejected ao longo de um dia de operação normal. Esse é o seu zero.
2. Acompanhe não o valor instantâneo, e sim a média de uma hora. Picos isolados na troca de bloco são normais, não são falha.
3. Crescimento da parcela com hashrate local inalterado significa problema no canal ou no pool, não no hardware.
4. Crescimento da parcela junto com queda do hashrate local significa hardware.

Três pools declaram seus próprios parâmetros, e eles divergem entre si mais do que os mineradores que discutem nos chats. A AntPool escreve na central de ajuda que se considera normal uma parcela de rejeitados abaixo de 1 por cento e de shares obsoletos em torno de 0,5 por cento ou menos. A ViaBTC chama de faixa normal desvios dentro de 3 por cento. A F2Pool considera razoável uma parcela de shares atrasados em torno de 2 por cento. A dispersão de 0,5 a 3 por cento entre três pools grandes já é a resposta à pergunta sobre a norma: norma geral não existe, existem as configurações de um pool específico.

Ressalva sobre a fonte: as páginas de suporte desses pools estão fechadas à verificação automática, e as formulações acima nós registramos a partir dos snippets públicos de busca deles, não do texto completo das páginas. Antes de se apoiar num número específico, abra a central de ajuda do seu pool e confira a redação atual.

O limiar a partir do qual as perdas ficam perceptíveis ninguém publica, e não é preciso inventá-lo: a mecânica se calcula de cabeça. Share rejeitado não é pago, portanto a parcela de rejeições é aproximadamente igual à parcela de receita perdida. Um por cento de rejects é cerca de um por cento de receita fora do caixa, três por cento são três. Se vale a pena reconfigurar a fazenda por causa disso depende do tamanho dela, não da recomendação alheia.

O que com certeza não é normal e não exige estatística: parcela de rejeitados perto de cem por cento. Isso é quase sempre dificuldade errada, firmware corrompido ou bloqueio da conexão por um intermediário, e não sobrecarga do pool.

Onde olhar para confirmar a queda do pool?

Confirmação de queda é sempre uma segunda fonte independente. Só o seu painel não basta: ele mostra igual a falha do pool e a queda no seu provedor. A ordem de verificação, do mais rápido ao mais lento, leva uns cinco minutos e quase sempre dá resposta inequívoca.

1. Estatística de hashrate da conta no pool. Se o painel web abre e mostra zero no seu worker, o servidor está vivo, e são justamente os seus shares que não chegam até ele. Se o painel não carrega de jeito nenhum, o problema é mais amplo.
2. Página de status do pool. Parte dos pools tem uma página separada de estado dos serviços. Vale achar o endereço dela com antecedência e guardar nos favoritos, em vez de procurar na hora da falha.
3. Monitores e exploradores externos. Observadores públicos da distribuição de hashrate mostram se o pool está achando blocos agora mesmo. Uma pausa longa em um pool grande é um sinal indireto, mas forte.
4. Redes sociais e chats do pool. A conta oficial e o canal de Telegram costumam saber da falha mais rápido do que a página de status é atualizada. Ali também dá para ver se outros mineradores estão reclamando.
5. Verificação da rota do seu lado. Um telnet ou nc comum no endereço e na porta do stratum, a partir de qualquer computador na mesma rede, separa a queda do pool do bloqueio no provedor em dez segundos.

Se o painel do pool abre, os blocos estão sendo achados, o chat está calmo e os seus shares não são aceitos, então a falha é sua, não do pool.

Para que serve um backup pool e como configurar corretamente o stratum reserva?

Pool reserva é uma linha na configuração do minerador para a qual o aparelho troca sozinho quando o stratum principal não responde. Sem ela, na queda de conexão o ASIC apenas gira os ventiladores e não ganha nada até você intervir. Com ela, a parada encolhe para o tempo de reconexão, que se mede em segundos, não nas horas do seu sono.

Como isso aparece na configuração. Os firmwares diferem nos detalhes, mas o princípio é um só: lista de pools por prioridade, o minerador vai de cima para baixo.

\`\`\`

pool1: stratum+tcp://[ENDEREÇO DO POOL PRINCIPAL]:[PORTA] worker: conta.worker

pool2: stratum+tcp://[ENDEREÇO DO POOL RESERVA]:[PORTA] worker: conta2.worker

pool3: stratum+tcp://[ENDEREÇO DO TERCEIRO POOL]:[PORTA] worker: conta3.worker

\`\`\`

Regras sem as quais a reserva não funciona:

1. O segundo pool é outro pool, não outra porta do mesmo. Endereço reserva dentro da mesma infraestrutura não salva da queda dessa infraestrutura. Ponha a porta reserva do pool principal na terceira linha, não na segunda.
2. A conta no pool reserva precisa estar criada e testada com antecedência. Cadastro na hora da falha devora justamente aquela primeira hora.
3. O endereço de pagamento no pool reserva precisa estar preenchido. Senão o que for minerado fica pendurado num saldo ao qual você só volta daqui a um mês.
4. Teste a troca manualmente. Desligue o pool principal na interface por uns minutos e confirme que os shares foram para a reserva e que, depois do retorno, o minerador voltou para o principal.
5. Leve em conta o esquema de pagamento. A mudança de ida e volta entre pools PPLNS zera o acúmulo na janela duas vezes, por isso é mais sensato colocar como reserva um pool com esquema mais simples. A diferença de mecânica está explicada na comparação entre FPPS e PPLNS.

O número de pontos de entrada disponíveis varia entre os pools, e isso se vê na documentação deles mesmos. Contamos os hosts stratum únicos para BTC nas páginas de conexão de seis pools.

Aqui o importante não é que um pool tenha oito hosts e outro tenha um. O importante é que todos esses endereços levam a uma mesma infraestrutura: eles salvam da queda de uma região, mas não da queda do pool. É exatamente por isso que a segunda linha da configuração deve apontar para fora.

Quanto dinheiro o minerador perde de verdade por hora parada e como calcular sozinho?

A perda por hora parada se calcula em uma linha: a receita diária do seu equipamento, dividida por 24, multiplicada pela fração de parada. Nenhum modelo complexo é necessário aqui, porque a receita no pool é linear em relação ao hashrate. Só importa pegar o hashprice atual, e não um número de um artigo de meio ano atrás, senão o erro será de várias vezes.

Fórmula:

\`\`\`

perda = (hashrate em TH/s × hashprice em USD por TH/s ao dia) / 24 × horas de parada

\`\`\`

Hashprice é a receita por um terahash ao dia antes de descontar a eletricidade. Ele muda todo dia junto com a cotação e a dificuldade, por isso use um valor recente.

O hashprice nós deliberadamente não fixamos em número no texto. Ele muda todo dia junto com a cotação e a dificuldade, e um valor de um artigo de um mês atrás dá erro de várias vezes, não de alguns por cento. Coloque o valor recente do dia do cálculo: ele aparece nos índices públicos de hashprice e na nossa calculadora.

O que é importante não esquecer na conta:

• A eletricidade durante a parada é gasta em parte. Se o minerador está ligado mas não consegue enviar shares, ele consome mesmo assim. O prejuízo real por hora é maior que a receita não recebida pelo valor desse consumo.
• PPLNS pune a parada duas vezes. Em esquemas de acúmulo você não só deixou de ganhar durante uma hora, como perdeu posição na janela, que não se recupera instantaneamente. Em esquemas do tipo PPS a perda é exatamente igual à fórmula.
• Calcule pela fazenda inteira, não por uma máquina. Uma hora parada de dez aparelhos custa dez vezes mais, e diante desse número a decisão sobre o pool reserva se toma sozinha.

Calcular a receita conforme o seu hashrate e os parâmetros atuais da rede é mais cômodo na calculadora do que de cabeça.

O que fazer na primeira hora: checklist passo a passo

1. Minutos 0-2. Olhe o hashrate local no painel do minerador. Caiu junto com o do pool, então é hardware, e não é preciso seguir esta lista adiante.
2. Minutos 2-5. Verifique o status dos pools e o tempo do último share aceito. Status dead e tempo crescendo confirmam a queda de conexão.
3. Minutos 5-10. Abra o painel do pool e a página de status. Se nada abre, inclusive outros sites, então a coisa é no seu canal.
4. Minutos 10-15. Verifique a disponibilidade do stratum a partir de outro aparelho na mesma rede, depois pela internet móvel. A diferença no resultado aponta para o provedor ou o roteador.
5. Minutos 15-20. Dê uma olhada no chat e nas redes sociais do pool. Reclamações em massa nos últimos minutos encerram a questão.
6. Minutos 20-30. Confirme que a reserva entrou. Se não há pool reserva na configuração, escreva-o agora, é a única ação que devolve receita neste exato momento.
7. Minutos 30-45. Não mexa em mais nada. Reboot em massa da fazenda, reinstalação de firmware e mudança de dificuldade durante a falha alheia adicionam a você uma segunda falha por cima da primeira.
8. Minutos 45-60. Registre os fatos. Horário de início, captura de tela do painel, horário do último share, resposta do pool. Sem isso a conversa sobre compensação vira uma discussão sobre memória.

Quando a parada é motivo para trocar de pool e quando não é?

Uma falha não é motivo de mudança. Infraestrutura cai para todo mundo, e o custo de trocar de pool muitas vezes supera a perda de algumas horas paradas. O motivo aparece quando as paradas se repetem, duram muito e não vêm acompanhadas de comunicação clara: o silêncio do pool durante a falha custa mais caro que a própria falha.

Antes da mudança, calcule o preço da própria mudança: zeragem da janela no PPLNS, espera pelo novo limiar de pagamento, tempo de reconfiguração. Se você se inclina ao solo mining como jeito de escapar da dependência de infraestrutura alheia, veja primeiro a comparação entre solo e pool, ali a mesma dependência apenas muda de forma.

Por que quase nenhum pool publica uptime e como avaliar a confiabilidade indiretamente?

Página pública de uptime é um compromisso que não compensa assumir: qualquer número vira motivo de reclamação e comparação, e medi-lo honestamente exige medição de fora. Por isso a maioria dos pools se limita à estatística de blocos encontrados e de hashrate. A confiabilidade acaba sendo avaliada de forma indireta, por sinais observáveis, e não por percentuais declarados.

No que reparar quando não há número de uptime:

• Regularidade dos blocos encontrados. Num pool grande as pausas são previsíveis pela participação dele na rede. Um silêncio anormalmente longo aparece em qualquer explorador público.
• Existência de página de status e histórico de incidentes. O simples fato de o pool manter um registro público de falhas diz mais do que um bonito número 99,9.
• Rapidez e conteúdo da comunicação. Uma mensagem no chat nos primeiros minutos da falha vale mais do que um post de desculpas no dia seguinte.
• Quantidade de pontos de entrada independentes. Regiões diferentes, endereços stratum diferentes, suporte a várias portas. Isso reduz a chance de você perder a conexão por completo.
• Relatos de mineradores sobre falhas passadas. Não sobre a existência de falhas, e sim sobre se a estatística fechou depois delas.

Verificamos os materiais públicos de oito pools em 09.09.2026. Uma página de estado completa, com histórico de incidentes e números de uptime, foi encontrada em um: a Luxor publica a dela em uptime.luxor.tech, com divisão por serviços (interface do pool 99,766 por cento, processamento de estatística 99,956 por cento, parte dos serviços 100 por cento) e com registro de três meses. A Foundry tem o status.foundry.ac, mas isso é o status dos serviços corporativos da Foundry Digital, não uma página separada do pool de mineração. A F2Pool mantém uma seção de anúncios com posts sobre incidentes, mas isso não é página de estado. Na ViaBTC o número 99,99 por cento aparece em materiais de marketing, mas a página onde ele possa ser conferido nós não encontramos. Em AntPool, Braiins Pool, Binance Pool e Ocean não foi encontrada por busca nenhuma página pública de estado. O último significa exatamente «não encontrado no âmbito desta verificação», e não ausência garantida.

Verificação das páginas públicas dos pools, 09.09.2026.

Os parâmetros consolidados dos pools, incluindo esquemas de pagamento, comissões e limiares, estão reunidos nos cartões dos pools. Dados de uptime não há ali exatamente pelo motivo acima: não há o que comparar enquanto os pools não publicam.

Em resumo

O pool cai menos vezes do que parece no primeiro minuto. A ordem das ações é sempre a mesma: primeiro separar o seu hardware do servidor alheio, depois confirmar a parada com uma segunda fonte, depois se certificar de que o stratum reserva assumiu a carga. Pool reserva na configuração custa zero e economiza horas de receita, e configurá-lo deve ser feito num dia tranquilo, não num dia de falha.