Mineração solo para frotas em hosting: o que esperar

Este guia foi escrito para dois tipos de leitores: provedores de hosting e gestores de frotas que operam máquinas de terceiros e precisam decidir se, e como, oferecer mineração solo, e operadores de frotas próprias que estão comparando o solo com um pool proporcional. Quem minera em casa com um ou dois dispositivos encontra a matemática geral em Mining Variance & Poisson Math; aqui o foco são as frotas, o caixa, as regras para clientes, o monitoramento e a escolha entre Bitcoin e Bitcoin Cash.

A primeira metade trata dos números: o que uma frota deve esperar em cada chain e por que a média engana. A segunda metade, a partir da seção sobre como oferecer solo aos clientes, é operacional: regras, preços, monitoramento, o dia em que um bloco chega e três perfis de frota calculados.

Pontos principais

• A receita esperada por terahash é quase a mesma em BTC e BCH. No retrato abaixo, 1 PH/s valia cerca de 39,7 USD por dia em BTC e 39,5 USD por dia em BCH.
• A distribuição não. Um bloco BCH exige cerca de 269 vezes menos trabalho que um bloco BTC e vale cerca de 269 vezes menos, então a mesma frota encontra blocos BCH cerca de 269 vezes mais vezes.
• O tempo esperado é uma média, não um cronograma. Depois de um tempo esperado ainda há cerca de 37% de chance de nenhum bloco; depois de três tempos esperados, cerca de 5%.
• Solo contra FPPS muda o tempo, não a média. A diferença na receita esperada é a diferença de taxa: 1% no solo contra taxas FPPS que, na maioria dos grandes pools, ficam entre cerca de 2% e 4%.
• É o caixa que decide o tamanho da fatia. Para ter 95% de segurança de pelo menos um bloco, uma frota precisa de reserva para cerca de três tempos esperados.
• São os shares aceitos, não os blocos, que mostram que a frota funciona. Semanas sem bloco são normais; semanas com shares aceitos em queda não são.
• Para provedores, o problema dos tickets se resolve antes da troca. Uma declaração escrita e um painel que mostre os blocos esperados ao lado dos encontrados transformam um risco de suporte em produto.

O retrato usado neste guia

Todos os números a seguir vêm deste retrato. Os dados de rede mudam todos os dias; para valores atuais, use a calculadora ao vivo e o relatório mensal de probabilidades.

A dificuldade é o dado que mais importa, e é lida diretamente da chain. Os valores de hashrate da rede publicados por exploradores são estimativas derivadas dos tempos de bloco, e fontes diferentes divergem em alguns pontos percentuais; o tempo esperado da sua própria frota não depende deles.

A única fórmula por trás de tudo

O tempo esperado para uma frota encontrar um bloco é:

Tempo esperado = dificuldade × 2³² ÷ seu hashrate

Para frotas, dois detalhes importam:

• Use o hashrate efetivo, não o nominal. Paradas, shares stale e latência de rede reduzem o trabalho que realmente chega ao pool. Uma frota com 97% de uptime tem 97% da sua chance nominal, e seu tempo esperado é cerca de 3% maior.
• Dificuldade e hashrate da rede são medidas diferentes. A dificuldade é definida pelo protocolo a partir dos tempos de bloco passados; o hashrate da rede é uma estimativa de quanto trabalho está sendo feito agora. Chains com o mesmo algoritmo podem ter dificuldades muito diferentes, que é exatamente o caso de BTC e BCH.

Para se aprofundar no modelo de probabilidade, com simulações, veja Mining Variance & Poisson Math.

Mesma receita esperada, distribuição muito diferente

Eis 1 PH/s de hashrate efetivo em cada chain, no retrato:

As duas receitas esperadas ficam a cerca de meio ponto percentual uma da outra. Isso não é coincidência nem lei: as mesmas máquinas SHA-256 podem minerar qualquer uma das chains, e os operadores tendem a migrar entre elas até que a receita por hash se iguale mais ou menos. Quando preços ou dificuldade se movem, a diferença se reabre por um tempo.

O que não se iguala é a forma da renda. Neste retrato, um bloco BTC exige cerca de 269 vezes mais trabalho que um bloco BCH e vale cerca de 269 vezes mais. Mesma média, experiência oposta: em BTC uma frota de porte médio espera anos por um pagamento muito grande; em BCH a mesma frota recebe muitos pequenos.

O que uma frota deve esperar

A tabela mostra o tempo esperado por bloco, a espera mediana, o prazo em que um bloco chega em 95% dos casos e a chance de pelo menos um bloco em 30 dias e em um ano.

Bitcoin (BTC), dificuldade 132,76 T

Bitcoin Cash (BCH), dificuldade 494,00 G

Daqui saem diretamente duas leituras. Em BTC, abaixo de cerca de 50 PH/s, o solo continua sendo uma aposta de longo prazo mesmo para uma frota profissional: a 10 PH/s a chance de não encontrar nenhum bloco em um ano inteiro ainda é de cerca de 57%. Em BCH, a partir de cerca de 1 PH/s, o solo deixa de ser loteria e vira uma renda irregular.

Por que a média engana

O tempo de espera por um bloco segue uma distribuição exponencial, e isso tem consequências que surpreendem quase todo mundo na primeira vez.

A mediana é menor que a média. Metade das esperas termina antes de cerca de 0,69 vez o tempo esperado. Algumas esperas muito longas puxam a média para cima.

Longos períodos secos são normais. Esta é a probabilidade de ainda não ter bloco depois de um múltiplo dado do tempo esperado:

Uma frota de 1 PH/s em BCH tem um tempo esperado de 24,6 dias. Passar 50 dias sem bloco, o dobro do tempo esperado, acontece em cerca de um caso em sete. Não é sinal de que algo está errado.

A mineração não tem memória. Cada hash é uma tentativa independente. Depois de três meses sem bloco, a chance de encontrar um amanhã é exatamente a mesma do primeiro dia. Ninguém nunca tem um bloco garantido, e uma sequência de sorte não gasta a sorte futura.

Quantos blocos por mês: frotas em BCH

Para frotas grandes o bastante para encontrar vários blocos BCH por mês, a pergunta útil passa a ser quanto a contagem mensal varia. O número de blocos em um período segue uma distribuição de Poisson, cuja dispersão relativa diminui à medida que o número esperado cresce.

A 1 PH/s, cerca de três meses em dez terminam sem nenhum bloco. A 10 PH/s, um mês com apenas sete blocos e um mês com dezoito são ambos comuns. A 100 PH/s o resultado mensal fica a cerca de 15% da média em nove meses de cada dez.

O caixa: o verdadeiro limite do solo

Hosting e eletricidade são cobrados todo mês em moeda fiduciária. A receita do solo chega em blocos. A diferença entre os dois é o risco prático do solo para uma frota, e ela pode ser dimensionada.

Regra prática tirada da distribuição exponencial: para ter 95% de segurança de pelo menos um bloco, uma frota precisa conseguir operar por cerca de três tempos esperados sem receita da fatia solo. Para 99%, cerca de 4,6 tempos esperados.

Dois exemplos no retrato:

• 1 PH/s em BCH: tempo esperado de 24,6 dias, portanto cerca de 2,4 meses de reserva para 95% de segurança. Viável para a maioria dos operadores.
• 10 PH/s em BTC: tempo esperado de 21,7 meses, portanto cerca de 5,4 anos de reserva para 95% de segurança. Inviável como plano de renda; apenas como alocação deliberada de longo prazo.

Uma ilustração com premissas declaradas: uma frota a 15 J/TH consome cerca de 15 kW por PH/s, ou 360 kWh por dia. A 0,07 USD por kWh, isso dá cerca de 25 USD por dia, aproximadamente 770 USD por mês, por PH/s. Contra os cerca de 39,5 USD por dia de receita esperada no retrato, a margem média é positiva, mas em BCH a 1 PH/s cerca de três meses em dez não trazem bloco, e em BTC quase todos. Troque a eficiência e a tarifa pelas suas; a estrutura do raciocínio continua a mesma.

Solo contra FPPS: o que a taxa compra

Em valor esperado, o solo e um pool Full Pay Per Share pagam quase a mesma coisa, porque ambos pagam o subsídio do bloco mais as taxas de transação em proporção ao seu trabalho. As diferenças são:

• A taxa. A maioria das taxas FPPS publicadas pelos grandes pools fica entre cerca de 2% e 4%, com pelo menos um pool ligado a uma exchange anunciando menos (fonte: comparativo de pools da Simple Mining, atualizado em 23 set 2026). Contra uma taxa FPPS de 2 a 4%, uma taxa solo de 1% mantém cerca de 1 a 3 pontos percentuais a mais da receita esperada.
• O que a taxa maior paga. Um pool FPPS assume a variância por você e paga todo dia, com bloco ou sem bloco. É um seguro, e para muitos operadores vale o preço.
• As taxas de transação. O FPPS paga uma estimativa das taxas médias; o solo recebe as taxas reais dos blocos encontrados. Em muitos blocos os dois convergem; bloco a bloco eles diferem.

O solo faz sentido financeiro quando uma frota consegue absorver a variância no tamanho que escolhe, e quando os pontos percentuais extras, ou a preferência por receber diretamente da blockchain, importam para o operador.

A estratégia da fatia

Uma forma prática de usar o solo não é mover uma frota inteira, mas separar uma fatia, dimensionada para que sozinha alcance um ritmo previsível, e manter o resto em um pool proporcional.

Um exemplo calculado. Uma frota de 10 PH/s coloca 1 PH/s em solo em BCH e 9 PH/s em FPPS. A fatia tem um tempo esperado de cerca de 25 dias e encontra em média cerca de 15 blocos por ano. Cerca de 90% da renda da frota continua diária e previsível; a fatia acrescenta renda irregular em BCH com um retorno esperado um pouco melhor.

Como dimensionar a fatia. Comece pela regra da reserva: escolha a maior fatia cujos três tempos esperados você consiga financiar com folga sem receita do solo, e na qual um trimestre ruim não mude suas decisões.

Deixe-a quieta. Aumentar a fatia depois de uma semana de sorte, ou retirá-la depois de um mês seco, não muda as probabilidades, porque a mineração não tem memória. Só muda quanto tempo a fatia passa minerando. Decida uma vez, registre a decisão por escrito e revise-a em datas fixas, não depois de cada resultado.

A dificuldade se move: BTC e BCH se comportam de forma diferente

• Bitcoin recalcula a dificuldade a cada 2.016 blocos, cerca de duas semanas, e a mantém fixa entre os ajustes. Entre um ajuste e outro, seu tempo esperado é estável.
• Bitcoin Cash usa o ASERT (aserti3-2d), que recalcula a dificuldade a cada bloco com uma meia-vida de dois dias (especificação; nossa explicação: ASERT explained). Quando hashrate chega ou sai, a dificuldade do BCH acompanha em poucos dias.

Para grandes frotas em BCH há uma consequência que vale planejar: seu próprio hashrate faz parte da rede. No retrato, 100 PH/s seriam cerca de 3% do hashrate estimado da rede BCH, então movê-los para o BCH elevaria a dificuldade mais ou menos na mesma proporção em poucos dias, alongando seu próprio tempo esperado. Em BTC, os mesmos 100 PH/s são cerca de 0,01% da rede e não têm efeito visível.

Cinco interpretações erradas que fazem pensar em defeito

1. Semanas sem bloco, então alguma máquina está com defeito. Verifique primeiro os shares aceitos. Se os shares enviados pela frota correspondem ao seu hashrate, a frota está funcionando, e o período seco é estatística.
2. Esperamos tanto que um bloco é nosso por direito. A mineração não tem memória. A chance de um bloco amanhã não depende de quanto você esperou.
3. Nosso best share foi enorme, então chegamos perto. O best share é o share de maior dificuldade que seu minerador já produziu: mede o quão raro foi aquele hash. Não significa que você chegou perto de um bloco e não prevê o próximo. Mais em Best Share Explained.
4. Um pool solo com mais hashrate dá chances melhores. No solo, o hashrate de outros mineradores não ajuda você: suas chances dependem só do seu hashrate efetivo e da dificuldade. Em um pool solo importam uptime, latência e templates de bloco corretos.
5. Um mês decide se a estratégia funciona. A 1 PH/s em BCH, um único mês pode ir de zero a três blocos sem nada de anormal acontecendo. Avalie uma fatia solo em períodos de vários tempos esperados, nunca em um só.

Como verificar que a frota funciona sem esperar blocos

• Shares aceitos contra shares esperados. O trabalho aceito deve acompanhar o hashrate da frota ao longo de horas e dias. Uma diferença constante é um problema de configuração ou de hardware; a ausência de blocos não é.
• Shares rejeitados e stale. Alguns pontos percentuais são comuns; um aumento repentino geralmente indica latência de rede, uma porta errada ou uma máquina instável. O limite exato é uma regra prática que depende do hardware e da conexão, não uma constante do protocolo.
• Uptime por máquina. É o hashrate efetivo, não o nominal, que define as chances. Uma máquina parada um dia por semana perde cerca de 14% da sua chance.
• Estatísticas do pool via API. As frotas devem ler hashrate, workers e blocos encontrados de forma programática, não a olho. Para a SoloFury, os endpoints públicos estão documentados em solofury.com/api-docs.

Oferecer solo a clientes de hosting: a visão do provedor

Os provedores de hosting que avaliaram o solo e disseram não costumam dar o mesmo motivo: um cliente novo na mineração poderia escolher solo sem entender a variância, ficar semanas sem pagamentos e abrir um ticket convencido de que as máquinas estão com defeito. A preocupação é fundada, e também tem solução, porque tudo o que o cliente interpretaria mal é previsível e pode ser explicado antes da troca, e não depois.

Para quem o solo serve, e para quem não serve. O solo serve para clientes que entendem que a recompensa chega em blocos, que conseguem financiar a reserva e que são grandes o bastante em BCH para ver blocos com regularidade ou escolhem deliberadamente uma aposta de longo prazo em BTC. Não serve para um cliente de primeira viagem cujo plano depende de um pagamento diário. A regra mais limpa é deixar o solo fora da lista padrão e torná-lo uma opção sob pedido, para clientes que pedem ou que atingem um tamanho mínimo.

A declaração que evita tickets. Antes de apontar a primeira máquina para o solo, o cliente confirma por escrito uma lista curta de fatos, em linguagem simples:

• o tempo esperado por bloco para o seu hashrate na chain escolhida, e a data do retrato usado no cálculo;
• que depois de um tempo esperado ainda há cerca de 37% de chance de nenhum bloco, e depois de três cerca de 5%;
• que a métrica que prova que as máquinas funcionam são os shares aceitos, não os blocos encontrados;
• que separou os custos operacionais de pelo menos três tempos esperados;
• como a data de revisão é definida, e que resultados recentes não são motivo para mudar a fatia.

O objetivo é dar ao cliente um número para comparar em vez de uma sensação, antes do primeiro período seco e não durante.

Tornar o período seco visível. Um cliente que vê, em um painel, os shares aceitos acompanhando seu hashrate, o número de blocos esperados até agora e os blocos realmente encontrados, consegue responder sozinho à pergunta se algo está errado. Essa visão é a medida contra tickets mais eficaz que um provedor pode adicionar, e pode ser construída a partir da API pública do pool.

Modelos de preço e onde o solo se encaixa

Tarifa fixa de hosting por quilowatt-hora. O cliente paga energia e operação, fica com a recompensa inteira e escolhe o pool. O solo se encaixa sem nenhuma mudança: a receita do provedor não depende de quando os blocos chegam.

Participação na receita. O provedor fica com uma porcentagem do que as máquinas mineram. Alguns provedores cobram isso no nível do pool, por meio de uma integração com um pool proporcional que divide os pagamentos diários. Com um pool solo esse mecanismo hoje não existe: a coinbase paga o minerador e a taxa do pool, e não há uma terceira saída para o provedor. Um provedor com participação na receita ainda pode oferecer solo de duas formas: faturando sua parte a partir dos blocos encontrados, que são públicos on-chain e na API do pool, ou cobrando um valor fixo pela fatia solo. Nos dois casos, o acordo deve estar no contrato antes do primeiro bloco, e não ser discutido depois.

Seleção de pool gerenciada. Alguns provedores escolhem o pool pelo cliente. Nesse modelo, o solo pode ser oferecido como opção explícita com sua própria declaração, ou excluído; o que não funciona é mudar um cliente para o solo sem a explicação acima.

Configuração da frota para o solo

• Um endereço de pagamento por cliente, workers nomeados por máquina. Na maioria dos pools solo o nome de usuário é o endereço de pagamento, e um sufixo identifica o worker. As estatísticas por cliente saem de graça, e um bloco encontrado por qualquer máquina daquele cliente paga aquele cliente.
• Portas de alta dificuldade para máquinas industriais. O tráfego de shares de um rack de mineradores da classe S21/S23 é muito maior que o de dispositivos domésticos. Use as portas de alta dificuldade ou Stratum V2 do pool quando existirem, e uma dificuldade inicial fixa para a instalação; isso reduz o tráfego de rede sem mudar as chances.
• Região mais próxima. Shares stale são trabalho que chega tarde demais para contar. Aponte as máquinas para a região do pool com menor latência a partir do local e meça a taxa de stale depois da troca.
• Pool de reserva. A maioria dos firmwares suporta um pool secundário. Configurar como reserva a conta do cliente em um pool proporcional mantém o hashrate produtivo durante uma eventual indisponibilidade do pool solo, e mantém o cliente informado de que a reserva foi usada.
• Formatos de conexão por firmware. Firmwares Stratum V2 diferem entre esperar host e porta ou uma URL completa com a chave de autoridade do pool. Consulte a documentação do pool para cada firmware antes de configurar um rack inteiro.

O que monitorar, por cliente

O indicador de sorte que muitos pools mostram compara o trabalho feito desde o último bloco com o trabalho esperado por bloco. Um valor abaixo de 100% significa que a espera atual é mais longa que a média; descreve o passado, não é uma previsão, e as definições variam entre pools.

O dia em que um bloco chega

1. Confirme on-chain, não só no pool. Verifique a altura do bloco em um explorador independente e confira se a coinbase paga o endereço do cliente.
2. Espere a maturidade. As recompensas da coinbase ficam gastáveis depois de 100 confirmações, uma regra de consenso tanto em BTC quanto em BCH: cerca de 17 horas a dez minutos por bloco.
3. Fique atento a órfãos. Raramente, um bloco encontrado perde a corrida para outro bloco na mesma altura e não entra na chain definitiva. Se depois de algumas confirmações a altura não estiver mais na chain principal, a recompensa não é gastável; isso é uma propriedade do protocolo, não do pool.
4. Registre. Altura, hash, horário, endereço, recompensa e saída da taxa, para a contabilidade do cliente e para uma eventual fatura de participação na receita.
5. Explique ao cliente o que acontece agora, incluindo que o próximo bloco não é nem mais nem menos provável que antes. Nosso passo a passo depois de uma vitória está em You Found a Block, Now What?.

Três perfis de frota calculados

Todos os números usam o retrato do início deste guia.

Perfil A: um cliente com 2 PH/s que quer experimentar o solo. O provedor recomenda BCH para toda a alocação ou, de forma mais conservadora, uma fatia de 500 TH/s. A 2 PH/s em BCH o tempo esperado é de cerca de 12 dias, cerca de 30 blocos por ano, e uma janela de 30 dias traz de zero a cinco blocos em nove casos de dez; um mês sem bloco acontece cerca de uma vez em onze. A 500 TH/s o tempo esperado é de cerca de 49 dias e um mês sem bloco acontece mais da metade das vezes: é o número a colocar na declaração.

Perfil B: um operador com 30 PH/s que quer o solo como segunda fonte de renda. Dez por cento da frota, 3 PH/s, vai para solo em BCH: tempo esperado de cerca de 8 dias, cerca de 45 blocos por ano, de um a sete blocos em um mês típico, e uma janela de 90 dias sem bloco é praticamente impossível se as máquinas estiverem funcionando. Os outros 27 PH/s ficam em FPPS. Se o provedor cobra participação na receita, a fatia de 3 PH/s é faturada a partir dos blocos registrados on-chain.

Perfil C: um operador com 150 PH/s avaliando uma aposta de longo prazo em BTC. Em BTC, os 150 PH/s completos têm um tempo esperado de cerca de 44 dias e cerca de oito blocos por ano, mas metade dos meses termina sem bloco e um período seco de 90 dias acontece cerca de uma vez em oito. Uma fatia de 20 PH/s em BTC tem um tempo esperado de cerca de 11 meses: duas chances em três de pelo menos um bloco no primeiro ano, e uma em três de um ano inteiro sem nada. É uma alocação deliberada para um operador que pode sustentá-la, não um plano de renda. Os mesmos 20 PH/s em BCH encontrariam, em vez disso, um bloco a cada cerca de 30 horas.

Um registro de riscos para o solo em escala de frota

BTC ou BCH para uma fatia solo?

A liquidez faz parte da decisão: BTC e BCH estão listados nas principais exchanges centralizadas, o que importa quando uma frota precisa converter recompensas para pagar contas em moeda fiduciária.

Antes de apontar uma frota para o solo: uma checklist

• Coloque as regras por escrito. Tamanho da fatia, chain, data de revisão e o que não conta como motivo para mudá-la.
• Financie a reserva. Pelo menos três tempos esperados de custos operacionais para a fatia.
• Combine a leitura com o hosting ou o cliente. Todos os envolvidos devem saber que períodos secos de dois tempos esperados são normais, antes que o primeiro aconteça.
• Use uma carteira que você controla. As recompensas do solo vão para o endereço na configuração do minerador; endereços de depósito de exchanges podem funcionar, mas acrescentam uma contraparte. As recompensas ficam gastáveis depois da maturidade da coinbase prevista pelo protocolo, 100 blocos.
• Planeje a contabilidade. Uma renda irregular pode mudar como e quando as moedas mineradas são registradas na sua jurisdição. Confirme com um consultor qualificado.
• Configure o monitoramento. Shares aceitos, taxas de rejeitados e stale e uptime por máquina, lidos via API.

O que esta matemática não captura

• Mudanças de dificuldade. Todos os números supõem que a dificuldade do retrato se mantém. Em BTC ela muda a cada duas semanas; em BCH, continuamente.
• Preços. Os valores de bloco em USD são um retrato, não uma previsão.
• Taxas de transação. As moedas por bloco incluem uma média; os blocos reais variam.
• Blocos órfãos. Raros, mas um bloco encontrado pode ocasionalmente perder a corrida para outro bloco na mesma altura. Baixa latência e um nó bem conectado reduzem o risco.
• Seu próprio efeito sobre a dificuldade, relevante em BCH para frotas acima de alguns pontos percentuais do hashrate da rede.

Como a SoloFury lida com o hashrate de frotas

Esta seção trata do nosso próprio serviço; tudo o que veio antes vale para qualquer pool solo.

• Pagamentos non-custodial: quando uma máquina encontra um bloco, a recompensa é paga na coinbase diretamente ao endereço do minerador. Não há saldo no pool, nem etapa de saque, nem cadastro: o endereço da carteira é o nome de usuário.
• Taxa de 1%, paga como saída separada da coinbase.
• Portas Stratum V2 de alta dificuldade para máquinas da classe S21/S23: 3343 para BTC e 7343 para BCH. Stratum V1 em todas as moedas, com TLS em todas as portas.
• Dificuldade inicial fixa para instalações: defina a senha como d=50000 para reduzir o tráfego de shares.
• 9 regiões de servidores, e uma API pública de estatísticas por moeda para o monitoramento de frotas.

Os detalhes de configuração estão na página inicial de configuração e na documentação da API. As probabilidades atuais para qualquer hashrate estão na calculadora.

Leituras relacionadas

• Mining Variance & Poisson Math: o modelo de probabilidade completo, com simulações.
• Solo Mining vs Pool Mining: taxas, métodos de pagamento e comparação das taxas efetivas.
• Solo Mining Odds: probabilidades por dispositivo e por chain.
• ASERT explained: como a dificuldade do BCH reage a cada bloco.
• You Found a Block, Now What?: o que acontece depois de uma vitória e como verificá-la on-chain.