Como um pool de mineração de Bitcoin realmente funciona: do share ao pagamento

A explicação padrão é assim: os mineradores combinam seu hashrate, encontram um bloco juntos e dividem a recompensa. Nada nessa frase é falso, mas também nada de útil decorre dela. Ela não explica por que você recebe pagamento em dias em que o pool não encontra nenhum bloco. Não explica por que o painel mostra um hashrate diferente do da sua máquina. Não explica de onde vêm os 78% de luck, nem por que esse número às vezes não tem nada a ver com sua wallet.

O que segue é a cadeia inteira: o que fisicamente sai da sua máquina, como isso é contado, no que se transforma e em que ponto vira uma transação no seu endereço. Sem metáforas de bilhete de loteria.

A POOL BTC não é um pool. Nós comparamos os termos de outros operadores e calculamos quanto eles custam a um minerador, então nenhum operador é vendido aqui e nenhum é acusado. Apenas mecânica, e aritmética que você mesmo pode refazer.

Seis coisas que importam

1. Um share e um bloco são o mesmo objeto. Só a altura da barra é diferente.
2. O pool atribui a você uma barra pessoal e fácil para poder ver seu trabalho a cada poucos segundos em vez de uma vez por século.
3. Quem constrói o bloco é o pool, não você. Seu hardware itera números dentro de um header que chegou pronto.
4. Um esquema de pagamento é uma regra sobre quem carrega o risco do azar: você ou o operador.
5. A taxa sai da recompensa bruta, então em termos absolutos ela escala com o preço e com seu hashrate.
6. Luck é uma estatística, não um comportamento do operador. No FPPS ele nunca toca no seu pagamento.

O que é um share, e como ele difere de um bloco válido?

Um share é um header de bloco cujo hash ficou abaixo de um alvo fácil que o pool atribuiu a você pessoalmente. Um bloco é o mesmo header cujo hash ficou abaixo do alvo de toda a rede. Só a altura da barra é diferente: o trabalho, o formato dos dados e a validação são idênticos. Qualquer share que por acaso ultrapasse o alvo da rede vira um bloco válido automaticamente.

Um header de bloco Bitcoin tem 80 bytes e contém seis campos: versão, hash do bloco anterior, Merkle root, timestamp, nBits e nonce. nBits é uma codificação compacta do alvo atual da rede, e se expande no número de 256 bits abaixo do qual o duplo SHA-256 do header precisa cair.

Seu ASIC pega esse header e altera o que tem permissão para alterar: o nonce (4 bytes), o extranonce2 (o pool define o tamanho dele no momento da conexão, e ele entra no Merkle root através da transação coinbase) e, se o pool e o firmware suportarem version rolling, alguns bits do campo de versão. Cada header candidato é hasheado duas vezes e comparado com o alvo.

O pool verifica dois alvos em cada submissão. O share recebido é comparado com seu alvo pessoal (se ultrapassar: é contado na sua conta) e com o alvo da rede (se também ultrapassar esse: o pool publica um bloco imediatamente). Não existe um ato separado de "procurar um bloco". Um bloco é um subproduto do fluxo comum de shares.

Uma consequência nada óbvia: um pool não pode esconder um bloco que encontrou sem descartar o próprio share. A transação coinbase no seu template carrega os endereços e a marca do próprio pool, e qualquer bloco construído a partir desse template aparece nos exploradores sob a mesma marca. O procedimento prático para verificar isso está no nosso artigo sobre como verificar se um pool paga de forma justa.

Pelo cálculo da POOL BTC, com uma dificuldade de rede de 127.450.789.715.843 e uma dificuldade de share de 65.536, um bloco leva em média cerca de 1,94 bilhão de shares. Isso não é uma estimativa de ordem de grandeza, mas uma divisão direta: dificuldade da rede sobre dificuldade do share, porque ambas são expressas na mesma unidade de trabalho esperado.

O que é dificuldade de share, e por que o pool a ajusta à máquina (vardiff)?

A dificuldade de share é um multiplicador que indica o quanto seu alvo atribuído é mais fácil que o alvo base do Bitcoin. Na dificuldade 1, um share leva em média 2^32 hashes, cerca de 4,295 bilhões. Na dificuldade 65.536, leva 65.536 vezes isso. O pool ajusta esse número para que seu fluxo de submissões permaneça conveniente de contabilizar.

O mecanismo de ajuste se chama vardiff, de variable difficulty. O pool observa a frequência com que você submete e aumenta ou diminui sua dificuldade, visando um intervalo confortável entre shares. Se ajustada baixa demais, uma farm grande inunda o servidor de tráfego. Se ajustada alta demais, as estatísticas de uma máquina pequena ficam ruidosas: se um share sai a cada dois minutos, o gráfico de hashrate por hora vai oscilar dezenas de por cento só por aleatoriedade.

Pelo cálculo da POOL BTC, uma máquina de 100 TH/s a uma dificuldade de share de 65.536 submete cerca de 21,3 shares por minuto, um aproximadamente a cada 2,8 segundos. A conta: 100 TH/s são 10^14 hashes por segundo, divididos por 65.536 × 2^32 = 2,815 × 10^14 hashes esperados por share, o que dá 0,355 shares por segundo.

A mesma máquina em diferentes dificuldades de share:

E a uma dificuldade fixa de 65.536, em diferentes hashrates:

O que vale a pena reter: a dificuldade de share não afeta sua renda. Ela afeta quão rápido a estimativa do pool converge para seu hashrate real. Dobre a dificuldade e você envia metade dos shares com o dobro do peso. O produto permanece inalterado.

Quem constrói o template do bloco, e o que entra em um bloco?

No Stratum V1 clássico, o pool constrói o template inteiro. Ele roda seu próprio node Bitcoin, seleciona transações da mempool, constrói uma transação coinbase que paga aos seus próprios endereços e calcula a árvore Merkle. O que chega ao minerador não é uma lista de transações, mas um conjunto de ramos Merkle mais as duas metades da coinbase. O minerador fisicamente não pode selecionar ou recusar uma transação.

A mensagem mining.notify que distribui o trabalho carrega um job id, o hash do bloco anterior, ambas as metades da transação coinbase, a lista de ramos Merkle, versão, nBits, tempo e uma flag clean_jobs. O minerador insere seu extranonce2 entre as metades da coinbase, recalcula o Merkle root a partir dos ramos e monta o header.

Essa flag clean_jobs explica metade do que parece estranho nos logs do minerador. Quando um novo bloco aparece na rede, o pool envia um job novo com clean_jobs definido como true, e a partir desse instante todo trabalho no job anterior não vale nada. Shares submetidos depois contra o job antigo voltam rejeitados como stale.

O que realmente está dentro do bloco: a transação coinbase (o subsídio mais a soma das taxas de cada transação incluída, com o subsídio em 3,125 BTC a partir de 24.09.2026) e um conjunto de transações da mempool, geralmente ordenadas por taxa por byte virtual. A parcela de taxas na recompensa total do bloco é pequena atualmente. Segundo a mempool.space em 08.09.2026, foi 0,66% nos últimos 4.320 blocos e 0,57% nos últimos 144, e ao longo do mês o valor ficou entre 0,66% e 0,73%. Outros agregadores que olham janelas de um único dia relatam 0,40% a 0,56%, porque usam um denominador diferente. Não existe um único número correto aqui, apenas um número com uma janela e uma fonte declaradas.

A única parte do protocolo que retira a construção do template do pool é o Job Declaration, parte do Stratum V2. Ele roda em produção em uma dezena de pools, e não deve ser confundido com um pool anunciar que "suporta Stratum V2". Os três números de adoção separados por trás desses anúncios são desmembrados no nosso artigo sobre Stratum V2 e quem escolhe as transações.

Como o pool mede a contribuição de um minerador e a transforma em pagamento?

O pool mantém um registro de shares aceitos com seus pesos, vinculado ao seu worker. No momento da liquidação (o fim do período diário para a família PPS, o momento em que um bloco é encontrado para o PPLNS) ele calcula sua parte segundo sua fórmula, subtrai a taxa, credita um saldo interno e envia uma transação assim que esse saldo ultrapassa o limite de pagamento.

O caminho completo de um share, do ASIC até as moedas na sua wallet:

1. O pool envia mining.notify com um job e a dificuldade atual do seu worker.
2. O ASIC itera nonce, extranonce2 e bits de versão até que o duplo SHA-256 do header fique abaixo do seu alvo.
3. O ASIC envia mining.submit: job id, extranonce2, tempo, nonce.
4. O pool verifica se o job está atual, se o share não é duplicado, e se o hash realmente está abaixo do seu alvo. Ao mesmo tempo ele compara com o alvo da rede.
5. O share aceito entra no registro com um peso igual à sua dificuldade.
6. O pool credita sua parte: ou uma taxa fixa por share ou uma fatia da recompensa de um bloco encontrado, dependendo do esquema.
7. A taxa do pool sai desse crédito, calculada sobre o valor bruto.
8. O que resta fica no saldo interno, geralmente exibido como "não pago" no painel.
9. Assim que o saldo ultrapassa o limite, o pool constrói uma transação, deduz a taxa de rede segundo sua própria política e a envia para seu endereço.
10. Depois das confirmações, o valor finalmente é seu. Até esse momento é uma obrigação do operador, não o seu dinheiro.

Os passos nove e dez merecem uma pausa. Entre "creditado" e "chegou" fica o limite de pagamento, e com hashrate pequeno esse limite vira um período de espera.

Pelo cálculo da POOL BTC, uma máquina de 100 TH/s com um hashrate de rede de 930,73 EH/s e um subsídio de 3,125 BTC ganha 0,00004835 BTC por dia em subsídio bruto (parâmetros de rede: mempool.space, snapshot de 08.09.2026). Somando a parcela de taxas de 0,66%, chega a 0,00004867 BTC, e depois de uma taxa de pool de 2% restam 0,0000477 BTC por dia. Contra o limite de 0,001 BTC publicado por F2Pool, AntPool e Luxor, o primeiro pagamento chega por volta do dia 21 de operação ininterrupta. Contra o limite da Ocean, listado em fontes secundárias como 0,01048576 BTC, a espera seria de aproximadamente 220 dias.

Isso não é uma crítica à Ocean, que também paga via Lightning sem limite algum. Isso ilustra que um limite de pagamento significa uma coisa para uma única máquina e algo totalmente diferente para uma farm de 10 PH/s. Você pode comparar o limite com seu próprio hashrate e calcular o intervalo entre pagamentos na calculadora da POOL BTC.

Como PPS, FPPS, PPLNS e SOLO diferem mecanicamente e não em marketing?

Um esquema de pagamento responde exatamente uma pergunta: quem carrega o risco de os blocos chegarem mais tarde do que o esperado. Em PPS e FPPS o operador assume esse risco e vende a você previsibilidade por uma taxa mais alta. Em PPLNS e TIDES o risco fica com os mineradores e é espalhado por uma janela de shares. Em SOLO ele é inteiramente seu, sem nenhuma média.

A diferença mecânica aparece em dois pontos. Primeiro: no FPPS a taxa por share é conhecida antecipadamente, então o crédito diário precisa ser plano com hashrate constante, e qualquer degrau nesse gráfico é uma mudança de dificuldade da rede ou um problema do seu lado. Segundo: uma janela PPLNS é definida em unidades de trabalho, não de tempo, então a janela encolhe em horas por conta própria conforme a dificuldade da rede sobe.

A forma como os operadores realmente descrevem suas janelas varia mais do que as pessoas presumem. A ViaBTC diz oficialmente "as últimas 5 rodadas de dificuldade". A Ocean documenta sua janela como shares equivalentes a oito vezes a dificuldade do bloco. AntPool e F2Pool se referem a "as últimas N rodadas de dificuldade" sem publicar N. A Braiins só roda BTC em FPPS desde dezembro de 2023 e não oferece nenhum esquema no estilo PPLNS.

As fórmulas de cada esquema, junto com o que acontece com seus shares quando você sai de um pool, são abordadas no nosso artigo dedicado sobre esquemas de pagamento. A divisão de risco acima é a parte que importa aqui.

De onde vem a taxa do pool e o que ela cobre?

A taxa do pool é um percentual que o operador retém da recompensa bruta antes da distribuição. Ela custeia nodes Bitcoin e servidores stratum em várias regiões, uma equipe de plantão, o risco de variância que o operador absorve sob esquemas PPS, e a infraestrutura de liquidação. As taxas nos grandes pools ficam entre 1% e 4%, e compará-las diretamente entre esquemas não funciona.

O detalhe que as pessoas ignoram: a taxa sai do crédito bruto, não do lucro e não do que sobra depois da eletricidade. Então o mesmo percentual significa dinheiro absoluto diferente em preços e hashrates diferentes, e isso também é por que os esquemas PPS cobram mais. Embutido nesse percentual está o preço de o operador garantir seu pagamento em uma semana ruim.

O que está confirmado sobre pools específicos a partir deste snapshot:

Pelo cálculo da POOL BTC, a diferença entre uma taxa de 2% e uma de 4% em uma máquina de 100 TH/s é de 0,00000097 BTC por dia, cerca de 0,000355 BTC ao ano. Esse número parece trivial até você multiplicar pela quantidade de máquinas: em uma farm de 100 ASICs idênticos, os mesmos dois pontos percentuais chegam a 0,0355 BTC por ano.

Por que classificar pools por um único percentual ainda assim falha é explicado no nosso artigo sobre taxas e uma pontuação de pool de quatro fatores: o limite de pagamento, a política de taxa de rede e o spread de conversão automática superam a diferença percentual com mais frequência do que o próprio percentual.

O que são luck e variância, e por que um pool pode ficar abaixo do esperado durante uma semana?

Luck é a razão entre o custo esperado de shares e os shares realmente gastos nos blocos encontrados, mostrada como percentual. Um valor de 78% significa que os blocos custaram ao pool mais trabalho do que o esperado, 130% que custaram menos. Variância é a dispersão estatística da qual o luck decorre. A descoberta de blocos é um processo de Poisson, então o desvio é inevitável e só encolhe conforme a amostra cresce.

Uma propriedade útil da distribuição de Poisson: o desvio padrão é igual à raiz quadrada da expectativa. A dispersão relativa, portanto, cai com a raiz quadrada da quantidade de blocos, não proporcionalmente ao hashrate.

Pelo cálculo da POOL BTC, com um hashrate de rede de 930,73 EH/s e 1.008 blocos por semana:

A linha do topo é a mesma máquina de 100 TH/s, minerando solo: o tempo esperado até um bloco a uma dificuldade de 127,45 trilhões é de cerca de 173 anos, e a chance de encontrar um em determinada semana é de aproximadamente 0,011%.

A linha de baixo corresponde à Foundry USA. Conforme a tabela da ChainBulletin de 08.09.2026 (reproduzida na publicação da KuCoin de 10.09.2026), o pool detém cerca de 244,6 EH/s, cerca de 27% da rede, com a AntPool perto de 156 EH/s e a F2Pool perto de 127 EH/s. O coeficiente de Nakamoto, o número de pools que produzem mais da metade de todos os blocos, está em 3 segundo o relatório da D-Central para o primeiro semestre de 2026.

Duas conclusões saem dessa tabela. Um pool de 10 EH/s perfeitamente honesto e sem incidentes vai fechar aproximadamente uma semana em três abaixo de 70% ou acima de 130% de luck, e isso é comportamento normal para uma variável aleatória. Ao mesmo tempo, se você está em FPPS, nada dessa linha se aplica a você, porque você recebe uma taxa por share independente de o pool encontrar um bloco ou não. Luck em FPPS é a métrica do operador, não a sua.

O inverso também vale. Uma única semana de luck não prova nada em nenhuma direção. Uma amostra significativa para discutir a honestidade de um pool PPLNS começa em um trimestre.

O que acontece quando você se desconecta: shares stale, taxa de rejeição, failover?

Quando o link cai, o ASIC continua hasheando contra o último job que recebeu, mas não há para onde enviar os resultados, então esse trabalho se perde. Assim que a conexão retorna, shares contra o job desatualizado são rejeitados como stale. Seu saldo acumulado fica intocado: fica na conta esperando o limite de pagamento. O que você perde é o trabalho atual, mais sua posição na janela se você estiver em PPLNS.

Os motivos pelos quais um pool rejeita um share significam coisas diferentes e vale a pena separá-los nos seus logs:

1. Stale, ou job não encontrado: o share chegou contra um job que não está mais atual. Geralmente rede, latência ou um novo bloco na rede.
2. Share de baixa dificuldade: o hash não alcançou seu alvo atual. Frequentemente uma dessincronização logo após uma mudança de vardiff.
3. Share duplicado: a mesma combinação de nonce e extranonce2 submetida duas vezes. Um sinal de problema de firmware ou falha no controlador.
4. Acima do alvo: o header falha totalmente na validação. Geralmente hardware empurrado longe demais em overclock ou temperatura.

Cada operador define seu próprio normal para rejects, e não existe um limite padrão do setor. A AntPool chama de normal abaixo de 1% e cita separadamente uma taxa média de stale de 0,5% ou menos. A ViaBTC diz até 3%. A F2Pool chama cerca de 2% de uma taxa razoável de shares atrasados. Braiins e Luxor não publicam limite numérico.

Pelo cálculo da POOL BTC, cada 2 pontos percentuais de taxa de rejeição custam exatamente o que 2 pontos percentuais de taxa de pool custam, já que ambos saem do crédito bruto. Para uma máquina de 100 TH/s isso é os mesmos 0,000355 BTC por ano. Um pool a 2% com uma rota ruim até seu servidor perde para um pool a 3% com uma rota estável.

O que torna o failover menos opcional do que parece. A configuração stratum de um ASIC aceita vários endereços de pool, e o firmware passa para o próximo quando o principal cai. Preencha cada slot disponível, e mantenha pelo menos um backup em um operador diferente ou pelo menos em uma região diferente, ou ambos vão falhar no mesmo momento. O firmware padrão do Antminer tem três slots (Pool 1, 2 e 3, segundo o suporte da Bitmain), e o Whatsminer tem os mesmos três.

Um detalhe específico do PPLNS: sair de um pool não queima seus shares como penalidade. Eles simplesmente saem da janela conforme novo trabalho chega. A Ocean documenta isso explicitamente, dizendo que os shares nunca são removidos do log de shares e simplesmente param de contar quando o volume de trabalho os empurra para além do limite da janela. O efeito prático é o mesmo, mas "o pool fica com seus shares" é a descrição errada.

Como um pool é diferente de hosting e de cloud mining?

Um pool é coordenação de trabalho: o hardware é seu, onde quer que você o mantenha, e o pool distribui jobs e paga por shares aceitos. Hosting é um local: o hardware ainda é seu, mas energia, resfriamento e conectividade pertencem a outra pessoa, e você ainda escolhe o pool sozinho. Cloud mining é um contrato: você não possui nenhum hardware, apenas a promessa de uma contraparte de te pagar um fluxo.

Hosting mais um pool é um arranjo normal, e os dois não competem entre si. Cloud mining fica à parte porque remove o único elo verificável de toda a cadeia: a correspondência entre seu hardware, seus shares e moedas na blockchain. Com um pool e com hosting esse elo sobrevive, e você pode recalculá-lo sozinho.

Como ler os termos de um pool na hora de escolher, e o que observar além do percentual, é abordado na nossa comparação de 12 pools.

Perguntas frequentes sobre a mecânica de pools de mineração

Um pool pode roubar um bloco que encontrou e não dizer nada?

Um bloco construído a partir do template de um pool carrega uma transação coinbase com os endereços e a marca daquele pool, e aparece em qualquer explorador. Escondê-lo não é possível. O que de fato não pode ser verificado de fora é a contabilidade interna: a fatia de um minerador específico em uma janela PPLNS e o hashrate real do pool continuam sendo o relatório próprio dele.

A dificuldade de share afeta minha renda?

Não. A dificuldade de share muda apenas a frequência e o peso das submissões, e o produto permanece o mesmo. Dobre a dificuldade e você envia metade dos shares, cada um valendo o dobro. Ela afeta sim a precisão estatística: uma dificuldade alta demais deixa o gráfico de hashrate de uma máquina pequena ruidoso.

Por que o painel do pool mostra menos hashrate do que meu ASIC?

Sua máquina relata a velocidade de hash instantânea, enquanto o pool estima seu hashrate depois do fato, a partir de shares aceitos ao longo de uma janela de média. Elas não podem coincidir por construção. Shares rejeitados e stale ampliam ainda mais a diferença, assim como a latência até o servidor stratum. Compare um número diário com um número diário.

O que acontece com meus shares se eu sair antes de o pool encontrar um bloco?

Em PPS e FPPS, nada: você foi creditado com uma taxa por cada share aceito e ela já está no seu saldo. Em PPLNS seus shares ficam na janela e participam de blocos encontrados depois que você sai, até que novo trabalho os empurre para além do limite. O saldo acumulado não queima, ele espera o limite.

Por que o pool precisa do meu hashrate se ele paga por shares?

Ele não conhece seu hashrate diretamente. O pool o deriva do fluxo de shares: shares aceitos multiplicados pela sua dificuldade, divididos pela duração da janela. Isso é uma estimativa, não uma medição, o que explica exatamente por que um gráfico de cinco minutos pula de um lado para outro enquanto um diário parece suave.

O que permanece não confirmado nos nossos dados a partir de 24.09.2026

1. Percentuais de taxa na Luxor e na Foundry USA. Nenhuma publica um único número: a Luxor chama sua taxa de desconto sobre o FPPS spot, a Foundry precifica por faixa de hashrate.
2. O limite de pagamento da EMCD: os artigos da central de ajuda que deveriam declará-lo retornaram 404 em 24.09.2026.
3. Os 3% da Kryptex vêm da nossa verificação manual de 29.08.2026; em 24.09.2026 o percentual não aparecia no texto de suas páginas públicas de taxas.
4. Os parâmetros de rede nos cálculos acima são um snapshot de 08.09.2026 (hashrate 930,73 EH/s, dificuldade 127.450.789.715.843, mempool.space). Em 24.09.2026 a mesma API mostrava 917,89 EH/s e uma dificuldade de 132.757.073.449.487, então uma máquina de 100 TH/s agora ganha cerca de 4% menos de subsídio por dia do que nos exemplos acima. O próximo reajuste no bloco 969.696 foi estimado em cerca de menos 5,5%.
5. Os valores de dificuldade de share nas tabelas acima são potências de dois arredondadas, escolhidas para tornar a aritmética legível. F2Pool, AntPool e Braiins não publicam dificuldade de share padrão ou mínima. A ViaBTC publica o mecanismo em vez de um número: um parâmetro d= na senha do worker define a dificuldade inicial e md= define o piso.

Em resumo

Um share é um bloco com a barra rebaixada, e nada mais. O pool escolhe a altura dessa barra para se adequar à sua máquina, para poder ver seu trabalho em tempo real, e a configuração não afeta sua renda.

Quem constrói o bloco é o pool, não você. Sob o Stratum V1 o minerador recebe ramos Merkle e um stub de coinbase, nunca uma lista de transações. Isso só muda sob Job Declaration, e apenas uma dezena de pools o roda em produção.

Um esquema de pagamento responde uma pergunta: o risco de quem. PPS e FPPS vendem a você previsibilidade pelo percentual, PPLNS deixa a dispersão com os mineradores, SOLO não faz média de nada. Luck é a métrica do pool, e em FPPS nunca alcança seu pagamento.

A taxa de rejeição custa exatamente o que a taxa custa, porque ambas saem do crédito bruto. Dois pontos percentuais perdidos por conectividade consomem o mesmo valor que dois pontos percentuais de tarifa, motivo pelo qual um pool bem conectado com uma taxa mais alta frequentemente vence um pool barato e distante.

Este artigo contém links de indicação para pools de mineração (marcados como patrocinados). Podemos receber uma recompensa se você se cadastrar por meio deles. Isso não altera os números nem a ordem das linhas nas tabelas: as condições foram tiradas das páginas oficiais dos pools.