Solo Mining for Hosted Fleets: What to Expect

This guide is written for two kinds of readers: hosting providers and fleet managers who run other people’s machines and have to decide whether, and how, to offer solo mining, and operators of their own fleets who are weighing solo against a proportional pool. Home miners with one or two devices will find the general math in Mining Variance & Poisson Math; here the focus is fleets, cash flow, client policies, monitoring and the choice between Bitcoin and Bitcoin Cash.

The first half covers the numbers: what a fleet should expect on each chain and why the average misleads. The second half, from the section on offering solo to clients onwards, is operational: policies, pricing, monitoring, the day a block arrives, and three worked fleet profiles.

Key takeaways

• Expected revenue per terahash is almost the same on BTC and BCH. At the snapshot below, 1 PH/s was worth about 39.7 USD a day on BTC and 39.5 USD a day on BCH.
• The distribution is not. A BCH block takes about 269 times less work than a BTC block and is worth about 269 times less, so the same fleet finds BCH blocks about 269 times more often.
• Expected time is an average, not a schedule. After one expected time there is still about a 37% chance of no block; after three expected times, about 5%.
• Solo vs FPPS changes timing, not the average. The expected-revenue difference is the fee gap: 1% solo against FPPS fees that on most major pools sit between about 2% and 4%.
• Cash flow decides the size of the slice. To be 95% sure of at least one block, a fleet needs runway for about three expected times.
• Accepted shares, not blocks, tell you the fleet works. Weeks without a block are normal; weeks with falling accepted shares are not.
• For providers, the ticket problem is solved before the switch. A written acknowledgement and a dashboard that shows expected blocks next to found blocks turn a support risk into a product.

The snapshot used in this guide

Every number below comes from this snapshot. Network data moves every day, so for current figures use the live calculator and the monthly odds report.

Difficulty is the input that matters most, and it is read directly from the chain. Network hashrate figures published by explorers are estimates derived from block times, and different sources disagree by several percent; the expected time of your own fleet does not depend on them.

The one formula behind everything

The expected time for a fleet to find a block is:

Expected time = difficulty × 2³² ÷ your hashrate

Two details matter for fleets:

• Use effective hashrate, not nameplate hashrate. Downtime, stale shares and network latency all reduce the work that actually reaches the pool. A fleet with 97% uptime has 97% of its nameplate chance, and its expected time is about 3% longer.
• Difficulty and network hashrate are different measures. Difficulty is set by the protocol from past block times; network hashrate is an estimate of how much work is being done right now. Chains using the same algorithm can have very different difficulties, which is exactly the BTC and BCH case.

For a deeper walk through the probability model, including simulations, see Mining Variance & Poisson Math.

Same expected revenue, very different distribution

Here is 1 PH/s of effective hashrate on each chain at the snapshot:

The two expected revenues are within about half a percent of each other. That is not a coincidence and not a law: the same SHA-256 machines can mine either chain, and operators tend to move between them until the revenue per hash roughly evens out. When prices or difficulty move, the gap reopens for a while.

What does not even out is the shape of the income. A BTC block takes about 269 times more work than a BCH block at this snapshot, and is worth about 269 times more. Same average, opposite experience: on BTC a mid-size fleet waits years for one very large payment; on BCH the same fleet collects many small ones.

What a fleet should expect

The table shows the expected time per block, the median wait, the time within which a block arrives in 95% of cases, and the chance of at least one block within 30 days and within one year.

Bitcoin (BTC), difficulty 132.76 T

Bitcoin Cash (BCH), difficulty 494.00 G

Two readings follow directly. On BTC, below roughly 50 PH/s solo stays a long-shot bet even for a professional fleet: at 10 PH/s the chance of no block in a full year is still about 57%. On BCH, from about 1 PH/s up, solo stops being a lottery and becomes an irregular income.

Why the average misleads

The waiting time for a block follows an exponential distribution, and that has consequences that surprise almost everyone the first time.

The median is shorter than the average. Half of all waits end before about 0.69 of the expected time. A few very long waits pull the average up.

Long dry spells are normal. This is the probability of still having no block after a given multiple of the expected time:

A 1 PH/s fleet on BCH has an expected time of 24.6 days. Going 50 days without a block, twice the expected time, happens in about one case out of seven. It is not a sign that anything is wrong.

Mining has no memory. Every hash is an independent trial. After three months without a block, the chance of finding one tomorrow is exactly what it was on the first day. Nobody is ever due a block, and a lucky streak does not use up future luck.

How many blocks in a month: BCH fleets

For fleets large enough to find several BCH blocks a month, the useful question becomes how much the monthly count moves. The number of blocks in a period follows a Poisson distribution, whose relative spread shrinks as the expected count grows.

At 1 PH/s, about three months in ten end with no block at all. At 10 PH/s, a month with only seven blocks and a month with eighteen are both ordinary. At 100 PH/s the monthly result stays within roughly 15% of the average in nine months out of ten.

Cash flow: the real limit of solo

Hosting and electricity are billed every month in fiat. Solo revenue arrives in lumps. The gap between the two is the practical risk of solo for a fleet, and it can be sized.

Rule of thumb from the exponential distribution: to be 95% sure of at least one block, a fleet needs to be able to operate for about three expected times without income from the solo slice. For 99%, about 4.6 expected times.

Two examples at the snapshot:

• 1 PH/s on BCH: expected time 24.6 days, so about 2.4 months of runway for 95% confidence. Workable for most operators.
• 10 PH/s on BTC: expected time 21.7 months, so about 5.4 years of runway for 95% confidence. Not workable as an income plan; only as a deliberate long-shot allocation.

An illustration with stated assumptions: a fleet at 15 J/TH draws about 15 kW per PH/s, or 360 kWh a day. At 0.07 USD per kWh, that is about 25 USD a day, or roughly 770 USD a month, per PH/s. Against the roughly 39.5 USD a day of expected revenue at the snapshot, the average margin is positive, but on BCH at 1 PH/s about three months in ten bring no block, and on BTC almost every month does. Replace the efficiency and tariff with your own; the structure of the reasoning stays the same.

Solo versus FPPS: what the fee buys

In expected value, solo and a Full Pay Per Share pool pay almost the same thing, because both pay the block subsidy plus transaction fees in proportion to your work. The differences are:

• The fee. Most published FPPS fees on major pools sit between about 2% and 4%, with at least one exchange-linked pool advertising less (source: Simple Mining’s pool comparison, updated 23 Sep 2026). Against a 2-4% FPPS fee, a 1% solo fee keeps about 1 to 3 percentage points more of the expected revenue.
• What the higher fee pays for. An FPPS pool takes on the variance for you and pays every day, block or no block. That is insurance, and for many operators it is worth its price.
• Transaction fees. FPPS pays an estimate of average fees; solo collects the actual fees of the blocks you find. Over many blocks the two converge; block by block they differ.

Solo makes financial sense when a fleet can absorb the variance at the size it chooses, and when the extra percentage points, or the preference for being paid directly by the blockchain, matter to the operator.

The slice strategy

A practical way to use solo is not to move a whole fleet, but to set aside a slice, sized so that the slice alone reaches a predictable rhythm, and to keep the rest on a proportional pool.

A worked example. A 10 PH/s fleet puts 1 PH/s on BCH solo and 9 PH/s on FPPS. The slice has an expected time of about 25 days and finds about 15 blocks a year on average. About 90% of the fleet’s income stays daily and predictable; the slice adds lumpy BCH income with a slightly better expected return.

How to size the slice. Start from the runway rule: choose the largest slice whose three expected times you can finance comfortably without solo income, and on which a bad quarter does not change your decisions.

Leave it alone. Moving the slice in after a lucky week, or out after a dry month, does not change the odds, because mining has no memory. It only changes how much time the slice spends mining. Decide once, write the decision down, and review it on a fixed schedule rather than after each result.

Difficulty moves: BTC and BCH behave differently

• Bitcoin recalculates difficulty every 2,016 blocks, about every two weeks, and holds it fixed in between. Between retargets, your expected time is stable.
• Bitcoin Cash uses ASERT (aserti3-2d), which recalculates difficulty at every block with a two-day half-life (specification; our explainer: ASERT explained). When hashrate arrives or leaves, BCH difficulty follows within days.

For large fleets on BCH there is a consequence worth planning for: your own hashrate is part of the network. At the snapshot, 100 PH/s would be about 3% of BCH’s estimated network hashrate, so moving it onto BCH would push difficulty up by roughly the same share within a few days, and lengthen your own expected time accordingly. On BTC, the same 100 PH/s is about 0.01% of the network and has no visible effect.

Five misreadings that make operators think something is broken

1. No block for weeks, so a machine must be faulty. Check accepted shares first. If the shares your fleet submits match its hashrate, the fleet is working, and the dry spell is statistics.
2. We have waited so long that a block is due. Mining has no memory. The chance of a block tomorrow does not depend on how long you have waited.
3. Our best share was huge, so we came close. The best share is the highest-difficulty share your miner has ever produced: it measures how rare that hash was. It does not mean you came close to a block, and it does not predict the next one. More in Best Share Explained.
4. A solo pool with more hashrate gives better odds. In solo, other miners’ hashrate does not help you: your odds depend only on your own effective hashrate and on difficulty. What matters in a solo pool is uptime, latency and correct block templates.
5. One month decides whether the strategy works. At 1 PH/s on BCH, a single month can range from zero to three blocks with nothing unusual going on. Judge a solo slice over periods of several expected times, never on one.

How to verify the fleet is working without waiting for blocks

• Accepted shares against expected shares. Accepted work should track the fleet’s hashrate over hours and days. A steady gap is a configuration or hardware problem; the absence of blocks is not.
• Rejected and stale shares. A few percent is common; a sudden rise usually points to network latency, a wrong port or an unstable machine. The exact threshold is a rule of thumb that depends on hardware and connection, not a protocol constant.
• Uptime per machine. Effective hashrate, not nameplate, sets the odds. A machine offline for a day a week costs about 14% of its chance.
• Pool-side statistics through an API. Fleets should read hashrate, workers and found blocks programmatically rather than by eye. For SoloFury, the public endpoints are documented at solofury.com/api-docs.

Offering solo to hosting clients: the provider’s view

Hosting providers who have looked at solo and said no usually give the same reason: a client new to mining could pick solo without understanding the variance, see no payouts for weeks, and open a ticket convinced the machines are broken. The concern is well founded, and it is also solvable, because everything the client would misread is predictable and can be explained before the switch rather than after.

Who solo is for, and who it is not for. Solo suits clients who understand that the reward arrives in lumps, who can finance the runway, and who are either large enough on BCH to see blocks regularly or deliberately choosing a long shot on BTC. It does not suit a first-time client whose plan depends on a payout every day. The cleanest policy is to keep solo off the default list and make it an opt-in for clients who ask for it or who meet a size threshold.

The acknowledgement that prevents tickets. Before the first machine is pointed at solo, the client confirms in writing a short list of facts, in plain language:

• the expected time per block for their hashrate on the chosen chain, and the date of the snapshot it was calculated from;
• that after one expected time there is still about a 37% chance of no block, and after three about 5%;
• that the metric proving the machines work is accepted shares, not blocks found;
• that they have set aside operating costs for at least three expected times;
• how the review date is set, and that recent results are not a reason to change the slice.

The purpose is to give the client a number to compare against instead of a feeling, before the first dry spell rather than during it.

Make the dry spell visible. A client who can see, on a dashboard, accepted shares tracking their hashrate, the expected number of blocks so far and the blocks actually found, can answer the question is something wrong by themselves. That view is the single most effective ticket-prevention measure a provider can add, and it can be built from the pool’s public API.

Pricing models and where solo fits

Flat hosting fee per kilowatt-hour. The client pays for power and operations, keeps the whole reward, and chooses the pool. Solo fits without any change: the provider’s revenue does not depend on when blocks arrive.

Revenue share. The provider keeps a percentage of what the machines mine. Some providers collect it at the pool level, through an integration with a proportional pool that splits the daily payouts. With a solo pool that mechanism does not exist today: the coinbase pays the miner and the pool fee, and there is no third output for the provider. A revenue-share provider can still offer solo in two ways: invoicing its share from the blocks found, which are public on-chain and in the pool API, or pricing the solo slice on a flat fee. In both cases the arrangement should be in the contract before the first block, not discussed after it.

Managed pool selection. Some providers choose the pool for the client. In that model, solo can be offered as a named option with its own acknowledgement, or excluded; what does not work is switching a client to solo without the explanation above.

Fleet configuration for solo

• One payout address per client, workers named per machine. In most solo pools the username is the payout address, and a suffix identifies the worker. Per-client statistics then come for free, and a block found by any machine of that client pays that client.
• High-difficulty ports for industrial machines. Share traffic from a rack of S21/S23-class miners is far higher than from home devices. Use the pool’s high-difficulty or Stratum V2 ports where available, and a fixed start difficulty for the farm; it reduces network chatter without changing the odds.
• Nearest region. Stale shares are work that arrives too late to count. Point machines at the pool region with the lowest latency from the site and measure the stale rate after the switch.
• Fallback pool. Most miner firmware supports a secondary pool. Configuring the client’s proportional pool account as fallback keeps hashrate productive during any solo pool outage, and keeps the client informed that the fallback was used.
• Firmware-specific connection formats. Stratum V2 firmware differs in whether it expects a host and port or a full URL with the pool’s authority key. Check the pool’s documentation for each firmware before rolling out a rack.

What to monitor, per client

The luck figure many pools display compares the work done since the last block with the work expected per block. A figure below 100% means the current wait is longer than average; it is a description of the past, not a prediction, and definitions differ between pools.

The day a block arrives

1. Confirm on-chain, not only in the pool. Check the block height on an independent explorer and verify that the coinbase pays the client’s address.
2. Wait for maturity. Coinbase rewards become spendable after 100 confirmations, a consensus rule on both BTC and BCH, roughly 17 hours at ten minutes a block.
3. Watch for an orphan. Rarely, a found block loses a race with another block at the same height and is not part of the final chain. If the height is no longer in the main chain after a few confirmations, the reward is not spendable; this is a property of the protocol, not of the pool.
4. Record it. Height, hash, timestamp, address, reward and fee output, for the client’s accounting and for any revenue-share invoice.
5. Tell the client what happens next, including that the next block is no more and no less likely than before. Our walkthrough of the steps after a win is in You Found a Block, Now What?.

Three worked fleet profiles

All figures use the snapshot at the top of this guide.

Profile A: a client with 2 PH/s who wants a taste of solo. The provider recommends BCH for the whole allocation or, more conservatively, a 500 TH/s slice. At 2 PH/s on BCH the expected time is about 12 days, about 30 blocks a year, and a 30-day window brings zero to five blocks in nine cases out of ten; a month with no block happens about one time in eleven. At 500 TH/s the expected time is about 49 days and a month with no block happens more than half the time, which is the number to put in the acknowledgement.

Profile B: an operator with 30 PH/s who wants solo as a second income stream. Ten percent of the fleet, 3 PH/s, goes to BCH solo: expected time about 8 days, about 45 blocks a year, one to seven blocks in a typical month, and a 90-day window without a block is practically impossible if the machines are working. The other 27 PH/s stays on FPPS. If the provider bills a revenue share, the 3 PH/s slice is invoiced from the blocks recorded on-chain.

Profile C: a 150 PH/s operator considering a BTC long shot. On BTC the full 150 PH/s has an expected time of about 44 days and about eight blocks a year, but half of all months end with no block and a 90-day dry spell happens about one time in eight. A 20 PH/s slice on BTC has an expected time of about 11 months: a two-in-three chance of at least one block in the first year, and a one-in-three chance of a full year with nothing. That is a deliberate allocation for an operator who can carry it, not an income plan. The same 20 PH/s on BCH would instead find a block roughly every 30 hours.

A risk register for solo at fleet scale

BTC or BCH for a solo slice?

Liquidity is part of the decision: BTC and BCH are both listed on major centralized exchanges, which matters when a fleet has to convert rewards to pay fiat bills.

Before pointing a fleet at solo: a checklist

• Write the policy down. Slice size, chain, review date, and what does not count as a reason to change it.
• Finance the runway. At least three expected times of operating costs for the slice.
• Agree the reading with the host or client. Everyone involved should know that dry spells of two expected times are normal, before the first one happens.
• Use a wallet you control. Solo rewards go to the address in your miner configuration; exchange deposit addresses can work but add a counterparty. Rewards become spendable after the protocol’s coinbase maturity of 100 blocks.
• Plan the accounting. Lumpy income can change how and when mined coins are recorded in your jurisdiction. Check with a qualified advisor.
• Set up monitoring. Accepted shares, rejected and stale rates, and uptime per machine, read through an API.

What this math does not capture

• Difficulty changes. Every figure assumes the snapshot difficulty holds. On BTC it moves every two weeks; on BCH, continuously.
• Prices. Block values in USD are a snapshot, not a forecast.
• Transaction fees. Coins per block include an average; real blocks vary.
• Orphaned blocks. Rare, but a found block can occasionally lose a race with another block at the same height. Low latency and a well-connected node reduce the risk.
• Your own effect on difficulty, relevant on BCH for fleets above a few percent of network hashrate.

How SoloFury handles fleet hashrate

This section is about our own service; everything above applies to any solo pool.

• Non-custodial payouts: when a machine finds a block, the reward is paid in the coinbase directly to the miner’s own address. There is no pool balance, no withdrawal step and no registration: the wallet address is the username.
• 1% fee, paid as a separate coinbase output.
• High-difficulty Stratum V2 ports for S21/S23-class machines: 3343 for BTC and 7343 for BCH. Stratum V1 on every coin, with TLS on every port.
• Fixed start difficulty for farms: set the password to d=50000 to reduce share traffic.
• 9 server regions, and a public stats API per coin for fleet monitoring.

Configuration details are on the start page and in the API documentation. Current odds for any hashrate are in the calculator.

Related reading

• Mining Variance & Poisson Math: the full probability model, with simulations.
• Solo Mining vs Pool Mining: fees, payout methods and effective fee comparison.
• Solo Mining Odds: odds by device and chain.
• ASERT explained: how BCH difficulty reacts at every block.
• You Found a Block, Now What?: what happens after a win, and how to verify it on-chain.