Taxa de 1% contra taxa de 4%: por que comparar pools por um único número falha, e como montar uma avaliação com quatro fatores

TL;DR

A taxa do pool é apenas uma entrada entre quatro, e não a mais decisiva. Ao lado dela estão o risco do operador, a confiabilidade do que o pool publica sobre si mesmo e a liquidez dos pagamentos: em quantos dias o dinheiro chega até sua carteira e quanto se perde pelo caminho. Abaixo está detalhada a metodologia que reúne esses quatro componentes em um único número, e onde esse número mente.

POOL BTC não é um pool de mineração, e sim um site independente de comparação de pools. As avaliações abaixo se referem a serviços de terceiros, e a metodologia é aberta justamente para poder ser contestada.

A ideia da pontuação multifator não é nossa. A Minerstat publicou em setembro de 2026 uma análise do próprio opportunity score composto por quatro elementos (profit, risk, data confidence, liquidity), e foi isso que nos motivou a descrever abertamente nossa própria abordagem. Não copiamos a fórmula da concorrente nem apresentamos os coeficientes dela como nossos: só a composição dos componentes coincide, porque é óbvia para qualquer um que já calculou rendimento na mão.

Por que comparar pools por uma única taxa dá uma resposta errada?

Porque a taxa não descreve nem o que exatamente é dividido, nem se o dinheiro vai chegar. Um pool com 2% em PPLNS e um pool com 4% em FPPS cobram por coisas diferentes: no segundo caso, a base inclui as taxas de transação do bloco. Além disso, o limite mínimo de saque, a taxa de rede na retirada e a probabilidade de o operador mudar as regras simplesmente não aparecem na porcentagem.

Vamos analisar com números verificados. Na F2Pool, para bitcoin coexistem oficialmente três esquemas: FPPS 4%, PPS+ 2.5% e PPLNS 2% (central de ajuda da F2Pool, verificação em 29.08.2026). Não dá para simplesmente escolher a linha mais barata e parar por aí, porque o PPLNS credita a você as taxas de transação reais dos blocos encontrados, enquanto o FPPS faz uma média do dia anterior e paga independentemente de o pool ter tido sorte com blocos ou não. O que é mais vantajoso depende do seu horizonte de tempo e de quanto estão valendo as taxas de transação no momento.

E elas valem ora quase nada, ora mais que o subsídio:

Em um regime tranquilo como o de setembro de 2026, a diferença entre "divide a parcela de taxas" e "não divide" representa frações de um por cento da renda, e nesse cenário a taxa declarada é de fato o fator principal. Mas em 20 de abril de 2024 essa mesma diferença custou três quartos da renda diária. Uma metodologia que se apoia inteiramente em um único número quebra justamente nesses dias.

Segunda coisa que a porcentagem não mostra: quanto custa retirar o dinheiro. Na Luxor o limite de saque é 0.001 BTC mais uma taxa de rede de 0.000075 BTC, ou seja, é preciso acumular mais de 0.001075 BTC no saldo, e a taxa de rede é arcada pelo usuário (documentação da Luxor). Na NiceHash a taxa de serviço é de 2% no crédito, e a retirada da carteira do serviço é uma operação separada: mínimo de 0.0005 BTC e taxa a partir de 0.0001 BTC adicional (páginas oficiais da NiceHash, consultadas em 02.09.2026). O que é mais caro para um minerador específico depende do seu hashrate, não da porcentagem exibida na vitrine.

Uma análise detalhada de tudo o que é deduzido além da porcentagem declarada está em um artigo separado sobre o custo real da taxa do pool. O importante aqui é outra coisa: mesmo uma taxa efetiva calculada com perfeição continua sendo apenas um componente entre quatro.

De quais componentes é formada uma avaliação honesta de um pool?

De quatro, e eles respondem a quatro perguntas diferentes. O rendimento responde "quantos BTC por dia". O risco do operador responde "qual a probabilidade de esses BTC não chegarem até mim". A confiabilidade dos dados responde "até que ponto dá para confiar nas duas primeiras avaliações". A liquidez responde "quando exatamente vou ver o dinheiro e quanto vou perder na retirada".

A ordem aqui não é aleatória. O rendimento é calculado primeiro porque sem ele o resto não faz sentido, e a confiabilidade dos dados vem em terceiro, mas na prática funciona como um filtro antes de todos os demais: se a taxa do pool não está publicada, você não calculou o rendimento, você o adivinhou.

Nossa página de metodologia de ranqueamento atualmente descreve apenas o primeiro componente, o cálculo de net BTC/day. Os outros três nós aplicamos na seleção, mas nunca formalizamos em nenhum lugar, e este artigo preenche essa lacuna.

Como calcular o componente de rendimento, e por que net BTC/day e não a porcentagem declarada?

Porque a porcentagem da taxa é um coeficiente dentro da fórmula, não o resultado. O que interessa ao minerador é o resultado líquido após a taxa do pool e após a eletricidade, expresso em BTC por dia com seu próprio hashrate. O mesmo pool pode ser o melhor para uma fazenda a 3 centavos e o pior para um minerador doméstico com tarifa cara.

Fórmula usada pela POOL BTC:

\`\`\`

net BTC/day = (seu hashrate / hashrate da rede) × 144 × (subsídio + taxas médias do bloco) × (1 - taxa do pool) - eletricidade em BTC

\`\`\`

O que importa em cada fator:

1. O hashrate da rede vem de uma API pública e muda todo dia. No corte de 29.08.2026 era 896.89 EH/s com dificuldade de 125 807 076 547 197.5, e no corte de 09.09.2026 já era 943.73 EH/s com dificuldade de 127 450 789 715 843.1 (mempool.space). Em onze dias a rede cresceu 5.2%, e qualquer "tabela de rendimento" sem data de captura é inútil.
2. Subsídio de 3.125 BTC por bloco após o halving de 2024. É a única entrada verdadeiramente estável na fórmula.
3. As taxas médias do bloco só são creditadas nos esquemas que as dividem. FPPS e PPS+ dividem, o PPS clássico paga apenas com base no subsídio. É daí que vem a diferença entre a taxa declarada e a efetiva.
4. A eletricidade é convertida em BTC pela cotação atual. É a única entrada que só você conhece, e também a que mais decide o resultado da comparação.

A partir daqui começa a parte desagradável. Na fórmula está "taxa do pool", mas não há de onde tirá-la em cerca de metade dos grandes pools, e esse já é o terceiro componente, não o primeiro. Sobre como o esquema de pagamento afeta tanto a variância quanto a renda final, há uma análise detalhada em FPPS versus PPLNS.

Não é preciso calcular isso de cabeça, é para isso que existe a calculadora de pagamentos: ela usa os parâmetros atuais da rede e o preço do seu kWh.

O que é o risco do operador de um pool, e como avaliá-lo de fora?

O risco do operador é a probabilidade de que o rendimento calculado não chegue até você: o pool fecha, muda as regras de pagamento, fica indisponível por uma semana ou zera seu saldo com base em algum motivo formal. De fora ele não é medido com precisão, mas tem sinais observáveis, e quase todos estão em documentos abertos que ninguém lê.

O que dá para verificar de fato, sem informação privilegiada:

• Os termos de serviço na parte do saldo e do resíduo não pago. Na F2Pool isso está escrito diretamente: se o endereço de pagamento não for definido por mais de 90 dias, a recompensa "may be treated as a donation", e pelos termos de serviço, na ausência de um endereço válido por 6 meses após aviso por escrito, o usuário perde o direito ao valor acumulado. Não é escândalo nem pegadinha, é uma cláusula contratual comum, mas vale a pena ler antes, não depois.
• Custódia. Um pool que retém seu saldo até o limite é, durante esse tempo, seu credor. Um pool com pagamento direto na carteira e limite baixo mantém você como credor por menos tempo.
• O esquema de pagamento como transferência de risco. Nos esquemas do tipo PPS, o operador assume a variância, e isso é conveniente até o momento em que o operador deixa de ser solvente. No PPLNS a variância fica com você, mas as obrigações do pool com você são menores.
• Concentração de hashrate. Uma fatia grande da rede significa previsibilidade nos pagamentos e, ao mesmo tempo, risco sistêmico para o próprio bitcoin. Ambos os efeitos são reais, e somá-los em uma única avaliação sem ressalva não é honesto.
• Histórico de incidentes e como o pool falou sobre eles. Um registro público de falhas pesa mais que um número bonito de uptime sem metodologia de medição.
• Jurisdição e requisitos de verificação. Eles mudam, e mudam retroativamente para saldo já minerado.

Como o hashrate da rede é distribuído entre os pools

Não existe medição direta do hashrate de um pool, então o setor calcula a fatia pelos blocos encontrados: um explorador atribui o bloco a um pool pela tag na transação coinbase e divide pelo total de blocos na janela. Abaixo estão os dados da mempool.space em 09.09.2026 para duas janelas de média, semanal e mensal. As fatias mudam o tempo todo, e qualquer tabela desse tipo só vale junto com a data do corte.

Fonte de ambas as janelas: API Mining Pools da mempool.space, consultada em 09.09.2026.

O que essa tabela tem de útil para o leitor. Os três primeiros mantêm cerca de 58% da rede em ambas as janelas, e este é o caso em que a previsibilidade de pagamento de um pool grande e o risco sistêmico para o bitcoin crescem juntos. Além disso, a diferença entre as janelas mostra o quanto o número é ruidoso: na SECPOOL a fatia semanal é cerca de um terço maior que a mensal, e na NiceHash o 1.33% semanal simplesmente sai dos primeiros doze na janela mensal. Comparar pools por fatia tirada em dias diferentes e com janelas diferentes não faz sentido.

Quais pools têm página pública de status

Quase nenhum. Verificamos nove pools em 09.09.2026, e uma página de status completa foi encontrada em exatamente um.

Isso é mais significativo do que parece. O uptime declarado é praticamente impossível de verificar de fora: oito dos nove pools não têm histórico de incidentes nem indicador de disponibilidade mensurável, e a frase sobre 99.9% no marketing continua sendo uma afirmação sem forma de refutá-la. A única grandeza verificável aqui não é a porcentagem, mas o próprio fato de existir a página.

Sobre o uptime como métrica, separadamente. Nenhum dos pools no nosso levantamento publica um indicador de disponibilidade mensurável com metodologia descrita: o número se tornaria um compromisso, e medi-lo honestamente exigiria fazer isso de fora. Por isso, na avaliação de risco, o uptime entra como um sinal observável (existe página de status, existem múltiplos pontos de entrada), não como porcentagem.

Como saber o quanto se pode confiar nos números que o pool publica sobre si mesmo?

Por um único critério: o pool abriu, em seu próprio site, sem login e com data, uma página com a taxa e o limite? Se a taxa só é conhecida por agregadores, você não está comparando o pool, e sim o relato de terceiros sobre o pool. Esse componente é totalmente verificável de fora e por isso é o único que não exige confiar na palavra do operador.

Como isso funciona na prática. Na verificação de 29.08.2026 abrimos manualmente no navegador as páginas em disputa, e o resultado foi este:

Dessa tabela vem uma conclusão bem mais importante que qualquer ranking: para quatro pools da lista, o número da taxa em qualquer comparação, incluindo a nossa, não é um fato, é um boato com data. E se dois pools diferem em 0.5 ponto percentual, e um deles não tem a taxa publicada em nenhum lugar, essa diferença de 0.5 ponto não significa nada.

A escala simples que usamos:

1. Publicado na página oficial, abre sem login, existe data da nossa verificação manual.
2. Publicado, mas incompleto: parte dos parâmetros está lá, parte só no suporte ou no chat.
3. Só atrás de login ou só via agregadores, sem confirmação oficial.
4. As fontes se contradizem, e a contradição não foi resolvida.

O quarto nível aparece com mais frequência do que gostaríamos. No caso da EMCD, temos um conflito entre dois limites que não foi resolvido desde agosto, e a conclusão correta aqui não é "vamos escolher o que parece mais plausível", mas "marcar como não resolvido e não construir comparação nenhuma em cima disso".

O que é a liquidez dos pagamentos, e por que o limite mínimo e a frequência de pagamento importam mais do que parecem?

Liquidez é a velocidade de transformar o que foi minerado em dinheiro na sua carteira. O cálculo é elementar: limite de pagamento dividido pelo seu net BTC/day. Para uma fazenda são horas, para um único ASIC doméstico podem ser meses, e durante todo esse tempo o saldo fica com o operador, e as regras dele podem mudar.

Limites e deduções verificados em vários pools:

Três coisas que mais quebram o cálculo de liquidez:

O limite de crédito e o limite de saque não são a mesma coisa. Na NiceHash, 0.00001 BTC caem no saldo, mas só dá para sacar a partir de 0.0005 BTC, ou seja, cinquenta vezes mais. Comparar esse primeiro número com o limite de um pool comum não faz sentido.

Uma taxa de saque fixa vira uma porcentagem que depende do valor. Uma taxa de 0.00003 BTC sobre um saque de 0.00025 BTC é 12% do valor, e sobre um saque de 0.01 BTC é 0.3%. A mesma linha de tarifa significa coisas diferentes para um minerador doméstico e para uma fazenda.

O saldo remanescente ao sair. A regra de que "o saldo abaixo do limite acumula e não se perde" está confirmada oficialmente para F2Pool, ViaBTC e Luxor. Para os demais pools não encontramos formulação oficial direta, então, ao trocar de pool, o saldo remanescente no antigo é uma questão em aberto, não uma garantia.

Em quantos dias se atinge o limite de pagamento

Calculado pela expectativa, sem a variância do esquema específico:

\`\`\`

fatia do minerador = hashrate do minerador / hashrate da rede

renda BTC por dia = fatia do minerador × 144 × recompensa_efetiva

dias até o limite = limite / renda BTC por dia

\`\`\`

Recompensa_efetiva é o subsídio mais as taxas médias do bloco. No corte de 09.09.2026, hashrate da rede de 943.73 EH/s, participação das taxas de transação nos últimos 4320 blocos de 0.669%, logo recompensa_efetiva = 3.125 × 1.00669 = 3.1459 BTC (mempool.space, consultado em 09.09.2026). Contra os 896.89 EH/s de 29.08.2026, a rede cresceu 5.2%, e o tempo de espera cresceu exatamente na mesma proporção para quem não trocou de equipamento.

Este é o nosso cálculo pela fórmula acima, não dados dos pools. A variância real do PPLNS e do TIDES não entra aqui, e nesses esquemas a dispersão em torno do prazo esperado é considerável. A conclusão prática é simples: um ASIC doméstico de 100 TH/s espera pelo limite de 0.001 BTC cerca de três semanas, e durante todo esse tempo o dinheiro fica com o operador. Com o limite de 0.01 BTC, a espera passa de meio ano. Dá para colocar seu próprio hashrate e sua própria tarifa na calculadora de pagamentos.

Como reunir esses componentes em uma única avaliação, e com qual peso?

Com uma soma ponderada de quatro avaliações normalizadas, em que a confiabilidade dos dados também funciona como filtro de admissão. Os pesos abaixo são nossa escolha e nossa responsabilidade, não um padrão do setor: qualquer um que pense diferente tem o direito de usar os próprios pesos e obter outra ordem de pools. É justamente por isso que os pesos são publicados, e não escondidos no código.

Ordem do cálculo:

1. Calcule o net BTC/day para cada pool com o mesmo hashrate e o mesmo preço de eletricidade. Usar entradas diferentes para pools diferentes é o erro de comparação mais comum.
2. Normalize o rendimento em uma escala de 0 a 100 dentro do conjunto comparado: o melhor pool do conjunto recebe 100, o pior 0. A avaliação é relativa, e é preciso lembrar disso ao lê-la.
3. Avalie o risco do operador pelos sinais observáveis da seção anterior. A escala é grosseira: 0, 25, 50, 75, 100. A precisão aqui é ilusória, e não vale a pena fingir que o risco foi medido até a porcentagem.
4. Avalie a confiabilidade dos dados pela escala de quatro níveis e converta em pontos: nível 1 vale 100, nível 2 vale 66, nível 3 vale 33, nível 4 vale 0.
5. Calcule a liquidez como o limite dividido pela sua renda diária, e normalize da mesma forma que o rendimento: mais rápido significa mais alto.
6. Some com os pesos e obtenha o resultado final.

Pesos propostos:

Uma regra rígida sobre essa soma: um pool com confiabilidade de dados no nível 3 ou 4 não participa do ranqueamento. Ele aparece na lista com a marca "dados não confirmados" e sem pontuação final. Do contrário chegaríamos ao absurdo de um pool marcar pontos altos por uma taxa bonita que ninguém conseguiu confirmar.

Como isso funciona em um pool:

\`\`\`

Rendimento 82 × 0.50 = 41.0

Risco 75 × 0.20 = 15.0

Confiabilidade 100 × 0.20 = 20.0

Liquidez 60 × 0.10 = 6.0

Total 82.0

\`\`\`

Por que não publicamos uma tabela com a pontuação final de todos os pools

Porque uma tabela assim, válida para todos os leitores, não existe, e publicá-la criaria uma falsa impressão de objetividade. Os motivos são concretos, não argumentos genéricos.

Primeiro: três dos quatro componentes dependem de entradas que são próprias de cada um. O rendimento é calculado com seu hashrate e sua tarifa por kWh, a liquidez com seu próprio prazo de acúmulo até o limite. Um ASIC doméstico de 100 TH/s espera pelo limite de 0.001 BTC cerca de três semanas, uma fazenda de 1 PH/s cerca de dois dias. O mesmo limite dá avaliações diferentes para leitores diferentes, e não há como tirar uma média disso.

Segundo: metade dos pools comparados não passa no filtro de admissão. Na AntPool, Binance Pool, Foundry USA e Luxor a taxa não é publicada oficialmente, e pela nossa própria regra eles ficam sem pontuação final. Uma tabela com quatro linhas vazias em dez não é um ranking.

Terceiro: os pesos são uma escolha, não uma grandeza mensurável. Nossos 50/20/20/10 refletem uma visão sobre o que importa, e qualquer outra distribuição dará outra ordem. A avaliação geral de um pool é sempre uma decisão autoral, não uma propriedade do pool.

Como ajustar os pesos para o seu caso. Se você tem uma ou duas máquinas e o limite leva semanas para ser atingido, aumente o peso da liquidez e diminua o da renda: meio ponto percentual de taxa nesse volume vale menos que um mês de espera. Se você costuma manter um saldo relevante acumulado, aumente o peso do risco do operador. Se você simplesmente não está disposto a confiar em números não confirmados, transforme a confiabilidade dos dados não em peso, mas em filtro rígido: pools de nível 3 e 4 simplesmente saem da comparação.

Em quais casos a avaliação composta mente, e o que verificar manualmente?

Ela mente em três situações típicas: quando a média esconde uma falha em um único componente, quando o conjunto de pools comparados é escolhido de forma que a normalização distorce o quadro, e quando os números dentro dos componentes se referem a datas diferentes. A pontuação composta é uma convolução conveniente, não uma sentença, e a decisão se toma depois de verificar as fontes.

Onde exatamente ela quebra:

• A média esconde o zero. Um pool pode conseguir um resultado final razoável com confiabilidade de dados zero, se o rendimento no papel for o melhor. É justamente disso que vem a regra de admissão da seção anterior.
• A normalização depende do conjunto. O mesmo pool, em um grupo de cinco pools caros, ganha 100 em rendimento; num grupo de quinze, ganha 60. A pontuação é comparável dentro de um mesmo corte e incomparável entre cortes diferentes.
• As datas divergem. A taxa foi verificada em agosto, os parâmetros de rede foram tirados em setembro, a cotação do BTC é de ontem. O resultado final parece um número único, embora seja montado com dados de três dias diferentes.
• Os pesos são uma questão de gosto. Nossos 50/20/20/10 refletem nossa visão do que importa. Os seus podem ser diferentes, e nesse caso a ordem dos pools muda, e a culpa não é da aritmética.
• O custo de trocar de pool não entra na pontuação. Na ViaBTC a janela PPLNS é descrita como as últimas 5 rodadas de dificuldade; na Ocean, o esquema TIDES usa uma janela de 8 dificuldades de rede. Sair de um pool assim zera a posição acumulada na janela, e uma diferença de um ponto não compensa isso.
• O pool muda as condições dentro da janela de avaliação. A taxa e o limite não são constantes, são valores atuais. Uma verificação mensal significa que você passa um mês usando um número desatualizado.

O que verificar manualmente antes de direcionar o hashrate:

1. Abra você mesmo a página oficial de taxas do pool escolhido e confirme que vê o mesmo número da comparação.
2. Encontre o limite de pagamento e a regra sobre o saldo abaixo do limite. Se a regra não estiver disponível abertamente, considere que você perde o saldo ao sair.
3. Leia a seção dos termos de serviço sobre recompensas não pagas e prazos.
4. Verifique se o esquema de pagamento na sua conta é o mesmo usado na comparação. Em vários pools o esquema é escolhido nas configurações e o padrão não é o mais barato.
5. Recalcule o rendimento com sua própria tarifa de eletricidade, não com a média de mercado.

Como usar essa metodologia na prática, na hora de escolher um pool?

Como filtro, não como ranking. Primeiro você elimina os pools com dados não confirmados, depois calcula o rendimento com suas próprias entradas, depois olha a liquidez para o seu hashrate, e só no final compara a pontuação final dos dois ou três candidatos restantes. Todo o processo leva uma noite e economiza meses com um pool ruim.

Sequência de ações:

1. Monte a lista de candidatos. Um panorama pronto com taxas, esquemas e limites está nos cartões de pools, e lá também dá para ver quais números são confirmados oficialmente e quais não são.
2. Elimine todos com confiabilidade de dados no nível 3 ou 4. Isso não significa que o pool seja ruim, significa que não há como compará-lo com nada.
3. Calcule o net BTC/day na calculadora com o seu próprio hashrate e a sua própria tarifa de kWh. Não com a média, não com o "típico da região".
4. Divida o limite de pagamento de cada candidato pela renda diária obtida. Você terá o prazo até o primeiro pagamento em dias. Se for mais de um mês, a liquidez é o fator principal para você, não a taxa.
5. Leia, nos dois finalistas, os termos sobre o saldo remanescente e sobre recompensas não pagas.
6. Atribua pontos e pesos para o seu caso. Se dois pools diferem em menos de 5 pontos, a diferença está dentro da margem de erro dos dados de origem, e vale escolher pelo que não é numérico: idioma do suporte, velocidade de resposta, existência de página de status.
7. Anote a data da verificação e volte a ela em um trimestre. Taxas e limites mudam, e uma decisão tomada com dados do ano passado não é melhor que uma decisão baseada em boato.

Um caso à parte em que a metodologia não se aplica: se você está considerando seriamente a mineração solo, os componentes são os mesmos, mas os pesos são completamente diferentes, porque a variância deixa de ser um parâmetro e passa a ser o enredo principal. Há uma comparação entre mineração solo e em pool sobre isso.

Resumo

Comparar por uma única taxa só funciona em um mercado de taxas de transação tranquilo, e apenas para um minerador indiferente aos prazos de pagamento. Assim que entram em cena tarifas não divulgadas, limites de 0.001 BTC e regras sobre saldo não pago, um único número deixa de descrever a realidade.

Quatro componentes em vez de um não tornam a avaliação exata. Eles a tornam honesta: fica visível do que ela é feita, qual peso foi dado a quê e onde simplesmente não há dados. A pontuação de um pool cuja taxa não é publicada não é uma pontuação baixa, é a ausência de pontuação, e reconhecer isso é mais útil do que colocar na fórmula um número tirado de um agregador.