Por que a calculadora de rentabilidade "mente": análise da diferença entre previsão e realidade
TL;DR
A calculadora não mente, ela resolve outro problema. Ela pega a dificuldade de hoje, a cotação de hoje e assume que a máquina entrega o hashrate nominal 24 horas por dia sem um único share rejeitado. O pagamento real na sua conta difere por cinco razões, e elas são muito diferentes em magnitude. A maior e mais subestimada: a dificuldade é recalculada a cada 2016 blocos, aproximadamente a cada duas semanas (artigo 96), enquanto uma previsão de um mês a mantém constante silenciosamente. Depois vêm a sorte do pool no PPLNS, a perda de shares e o tempo de inatividade, a diferença entre a eficiência nominal e a real do hardware, e por último a taxa de saque somada ao spread da exchange.
Tabela das fontes de divergência
| Fonte do erro | Direção | Como considerar |
|---|---|---|
| Crescimento da dificuldade ao longo do horizonte de previsão | Quase sempre para baixo | Calcule por blocos: reinsira os dados a cada duas semanas em vez de multiplicar a receita diária por 30 |
| Sorte do pool no PPLNS | Nos dois sentidos, média próxima de zero no longo prazo | Avalie em um mês ou mais, não em um dia; ou migre para FPPS ou PPS+ se as oscilações incomodarem (artigo 96) |
| Shares stale e rejeitados, tempo de inatividade | Somente para baixo | Compare o hashrate real no painel do pool com o nominal; diferença acima de 5% se resolve com hardware ou conexão (artigo 96) |
| Eficiência real do hardware versus nominal | Para baixo na receita e para cima na conta de energia | Meça com um wattímetro na tomada, não use o número da ficha técnica |
| Taxa de saque e spread da exchange | Somente para baixo | Conte não a recompensa creditada, mas o que realmente chegou em fiat ou na sua carteira |
Por que a calculadora mostra mais do que chega na conta?
A calculadora calcula um dia perfeito com os dados de hoje: dificuldade fixa, hashrate nominal, zero shares perdidos, uptime total e um pagamento sem taxa de saque. A realidade se desvia de cada uma dessas premissas na mesma direção, exceto a sorte do pool, que oscila nos dois sentidos. Por isso o resultado real fica sistematicamente abaixo da previsão, e não oscila aleatoriamente ao redor dela.
Quanto o crescimento da dificuldade corrói a previsão?
Esta é a principal fonte de divergência em um horizonte maior que duas semanas. A dificuldade é recalculada a cada 2016 blocos, cerca de duas semanas, e aumenta se a rede ganhou hashrate. O seu próprio hashrate não muda, ou seja, sua fatia da rede diminui, e junto dela a receita em BTC. A calculadora não sabe nada sobre recálculos futuros.
A escala do problema fica clara no recorte que usamos para a comparação de pools por receita líquida: em 14.08.2026 o hashrate da rede era 933,99 EH/s, a dificuldade 127.479.855.693.691, a recompensa de bloco 3,125 BTC, a cotação do BTC 64.558 USD. No momento em que você lê uma previsão de um mês, essas quatro cifras já mudaram. As duas primeiras se movem conforme o cronograma da rede, a terceira conforme o cronograma do halving, a quarta a cada minuto.
Como corrigir isso na prática: não multiplique a receita diária por 30. Calcule em blocos de duas semanas e, após cada recálculo de dificuldade, insira o novo valor na calculadora FPPS vs PPLNS. Uma previsão estendida por um trimestre sem um único recálculo não é uma previsão, é um panfleto publicitário.
Por que a receita oscila no PPLNS e não no FPPS?
No PPLNS você é pago com base nos blocos que o pool efetivamente encontrou. Se a sorte foi ruim no período, a receita fica abaixo da expectativa teórica; se foi boa, fica acima (artigo 96). FPPS e PPS+ pagam pelo valor esperado e mantêm o risco da sorte do lado do pool, cobrando uma taxa por isso. O valor esperado é quase idêntico nos dois casos.
Aqui é importante não confundir variância com perda. Segundo nossa análise dos esquemas de pagamento, a receita esperada quase não depende do esquema: sua fatia da rede é a mesma independentemente do pool para onde você direciona seu hashrate, e 100 TH/s contra 933,99 EH/s dão a mesma expectativa em qualquer pool. O esquema redistribui não a soma, mas sua distribuição no tempo, e decide o destino das taxas de transação.
Medimos a magnitude do efeito das taxas de transação: no recorte de 14.08.2026, a parcela das taxas na recompensa dos últimos 4320 blocos era de 0,70%. Ou seja, a diferença entre PPS puro e FPPS naquele período era de 0,70% da receita. Bem menor que a variação da sorte no PPLNS ao longo de uma semana.
Para onde vão os shares stale e rejeitados
Parte dos shares enviados não é contabilizada pelo pool: chegaram depois que a rede passou para o próximo bloco, ou não passaram na validação. A calculadora assume que esses shares simplesmente não existem. Somam-se a isso quedas breves de conexão e reinicializações que, ao longo do dia, se acumulam em uma perda perceptível, mesmo que o worker pareça saudável neste momento (artigo 96).
Deliberadamente não citamos percentuais concretos: eles dependem da qualidade do link, da distância geográfica até o servidor do pool, da versão do firmware e da configuração. Não existe um número universal aqui, e qualquer autor que apresente um sem descrever seu ambiente de teste o inventou.
Mas você pode medir sua própria taxa, isso leva alguns minutos. No painel do pool, abra as estatísticas do worker e compare accepted e rejected nas últimas 24 horas, o pool mostra os dois valores separadamente. A taxa de stale você vê na interface web do próprio minerador, geralmente na seção de estatísticas de pools, ao lado do contador de shares aceitos. Compare os números obtidos não com prints de terceiros, mas com o limite do artigo 94 e do artigo 97: uma diferença de até 5% entre o hashrate do lado do pool e do lado do minerador é considerada normal, e tudo acima disso aponta para hardware, firmware ou conexão.
A referência prática do artigo 96 continua a mesma: compare o hashrate real do worker no painel do pool com o declarado pelo fabricante. Uma diferença acima de 5% indica um problema de hardware ou conectividade, não um pool ruim.
Por que a eficiência real do hardware é pior que a nominal
O número nominal foi medido nas condições do fabricante: temperatura de entrada especificada, chips novos, tensão nominal. Em um galpão ou garagem o ar é mais quente, os chips degradam, e a fonte de alimentação e as ventoinhas também consomem energia. O resultado é duplo: o hashrate fica um pouco mais baixo e o consumo um pouco mais alto, e ambos os ajustes comprimem a margem.
No cálculo do artigo 97 usamos o Antminer S21 XP Hyd: 473 TH/s, 5676 W, eficiência de 12 J/TH conforme o Guia do Usuário oficial da Bitmain V4.0.2. Este é um modelo hidro, um dos mais eficientes do mercado. ASICs refrigerados a ar têm eficiência pior, então para a maioria dos leitores os gastos com energia serão mais altos do que os apresentados, não mais baixos. Se você inserir na calculadora o número da ficha técnica de uma máquina refrigerada a ar de três anos atrás, sua previsão já estará inflada antes de qualquer outro ajuste.
O quanto isso importa fica visível na análise do limiar de desligamento: o shutdown price, ou seja, a cotação de BTC abaixo da qual a máquina opera no prejuízo, é determinado pela eficiência em J/TH, pela tarifa de energia e pela taxa do pool. A mesma máquina dá um limiar diferente para dois mineradores com tarifas diferentes, por isso os $46.787 daquela análise não são um número universal, mas um exemplo de cálculo para um conjunto específico de dados de entrada.
O que o saque e a conversão consomem
A última camada é a menor em percentual, mas é justamente ela que transforma "creditado" em "recebido". O limiar de saque retém o dinheiro, a taxa de rede pela transferência corta o valor, e o spread da exchange corta de novo na conversão para fiat. A calculadora não considera nenhum dos três.
Sobre o limiar temos a aritmética no artigo 98: a 100 TH/s, um limiar de 0,005 BTC leva cerca de 107 dias para ser atingido, e um limiar de 0,001 BTC cerca de 21 dias. Isso não é dinheiro perdido, mas é a diferença entre uma receita que está com você e uma receita que está com o pool.
Não apresentamos tarifas concretas aqui de propósito: a taxa de saque varia de pool para pool e muda conforme a carga da rede, e cada exchange tem seu próprio spread. A regra funciona melhor que uma tabela. Antes de escolher o limiar de saque, abra a página de saque do seu pool e veja quanto ele retém por uma transferência on-chain. O spread da exchange se calcula com a mesma simplicidade: compare a cotação dela com o preço à vista do BTC em uma corretora no mesmo momento, a diferença é o spread. Depois compare os dois números com a escala dos demais itens de custo. O spread entre uma taxa de 1% e 4% a 100 TH/s equivale a cerca de 9 centavos por dia segundo o cálculo do artigo 97. Se uma taxa de saque única consome mais do que esses 9 centavos ao longo de todo o período de acúmulo até o limiar, você está economizando no lugar errado.
O que realmente move o seu resultado
Já calculamos a ordem de influência no artigo 98, e ela é contraintuitiva. O primeiro lugar é da tarifa de energia: a diferença entre $0,05 e $0,12 por kWh a 100 TH/s era de $2,02 por dia no cálculo de 14.08.2026. O segundo lugar é da taxa do pool: o spread entre 1% e 4% é exatamente 3% da receita, cerca de 9 centavos por dia nos mesmos 100 TH/s. O terceiro lugar é da parcela das taxas de transação, PPS contra FPPS, aqueles mesmos 0,70% do recorte.
A diferença entre o primeiro e o segundo lugar é mais de vinte vezes. É por isso que discutir qual pool é meio por cento mais barato quase sempre é um debate vazio, enquanto uma tarifa de energia digitada errada arruína toda a previsão.
Checklist: como calcular honestamente
- Insira sua tarifa real por kWh, incluindo tudo que aparece na conta, não a tarifa promocional diurna.
- Pegue o consumo de um wattímetro na tomada, não da ficha técnica.
- Pegue o hashrate real das últimas 24 horas no painel do pool, não o nominal. Diferença acima de 5% conserte primeiro, depois calcule (artigo 96).
- Insira a taxa real do pool e seu esquema de pagamento. Taxas e limiares de doze pools estão reunidos no artigo 97.
- Calcule em horizontes de duas semanas, até o próximo recálculo de dificuldade. Depois recalcule tudo de novo.
- Acrescente em uma linha separada a taxa de saque e o spread de conversão se o objetivo for medido em fiat.
- Observe a receita em BTC, não em USD. Se o BTC está estável e o USD caindo, a causa está na cotação, não na mineração (artigo 96).
- Depois de fazer tudo isso, confira o resultado na calculadora FPPS vs PPLNS e na comparação de pools.
Perguntas frequentes
Minha receita caiu alguns pontos percentuais em uma semana. O pool está roubando?
Provavelmente não. Verifique em ordem: o recálculo da dificuldade da rede nesse período, o hashrate real do worker contra o nominal, o histórico de inatividade, e só depois o esquema de pagamento. Das cinco causas de queda na recompensa analisadas no artigo 96, quatro não têm relação com a honestidade do pool.
Qual calculadora é mais precisa?
A precisão da calculadora é determinada pelos seus dados de entrada, não pelo algoritmo: a fórmula é a mesma em todas. A diferença está em usar ou não a dificuldade atual e em permitir escolher o esquema de pagamento. Nossa calculadora de rentabilidade permite comparar FPPS e PPLNS com os mesmos dados de entrada.
Vale a pena sair do PPLNS por estabilidade?
Se as oscilações diárias atrapalham o planejamento, sim. O valor esperado quase não muda, o que muda é a distribuição no tempo: FPPS e PPS+ dão resultados mais estáveis (artigo 98). Você paga por essa estabilidade com a taxa que o pool cobra por assumir o risco da sorte.
Por que a previsão de um ano é sempre otimista demais?
Porque ela mantém a dificuldade e a cotação constantes ao longo de 26 recálculos futuros. A dificuldade acompanha o crescimento do hashrate da rede, e com sua capacidade inalterada, sua fatia da rede segue diminuindo. Uma projeção anual só faz sentido como cenário com uma premissa explícita sobre o crescimento da dificuldade, nunca como uma promessa.