← All strategies

In plain English

Your miner keeps SOL in its Autodeploy balance. Every successful fire sends some of that SOL onto the board. After each round, most of that SOL comes back and can be used again. Only a smaller permanent “haircut” — protocol burn plus your deployer/protocol fees — is gone forever.

Estimated runway answers one question:

It does not predict ORE earnings, Motherlode wins, USD profit, or how many minutes until you run dry if the strategy often skips.

Where you see it

1. Open Mining and select your miner.
2. Look at the STRATEGY card. Under the strategy summary you should see a line like ≈ 68 fires at 0.044 SOL and, when the net estimate is live, Net burn ≈ 0.0051 SOL per fire.
3. Hover the line for a short tooltip. Unavailable / limited-history states are honest empty messages — the UI will not silently fall back to the old “balance ÷ gross send” count.

Fires, not clock time

A fire is a successful Autodeploy that actually places SOL on tiles. Skipped rounds (EV Gate miss, Crowded-round skip, Motherlode range skip, low balance, and so on) spend zero bankroll and do not reduce the fire count — they only stretch calendar time.

So “≈ 100 fires” means about a hundred full deployments, not “100 minutes” or “100 wall-clock rounds.”

Why net burn, not gross send

Before ORE #167, it was tempting to estimate runway as:

That treats every deploy as permanently spent. After #167, almost all of the SOL returns:

• Missed tile ≈ 89.1% of that tile’s stake comes back
• Winning tile ≈ 99% comes back
• Across an equal N-tile plan, the expected protocol-side permanent burn is 10.504% of gross (exactly 2626 / 25000)

Returned SOL lands as claimable rewards and is recycled back into Autodeploy SOL before later fires. The old gross helper therefore understated runway by roughly an order of magnitude.

How the estimate is built

1. Forecast bankroll

The estimator starts from spendable Autodeploy float, not only the raw on-screen balance:

• Rent (the account’s rent-exempt reserve) is not spendable.
• Claimable rewards SOL is counted once — recycled SOL, not double-counted.
• Pending unsettled stake is haircut by the same post-#167 return fraction (22374 / 25000) and is forecast only. It is never treated as crank-safe spendable.

2. Expected permanent burn per successful fire

Fees come from the miner’s live on-chain deployer config, not product defaults. Wallet compute and Jito tips are not part of this runway.

3. Required float for the next full fire

Same affordability idea the crank uses: gross deploy + live fees + checkpoint, compared against forecast bankroll that already excluded rent.

The fire-count formula

The leading 1 is the next full fire you can place right now. The floor term is how many additional full fires the remaining float can fund after that burn loop.

All arithmetic is in the smallest SOL units (lamports, integer). Do not divide floating-point SOL strings — display rounding is separate from the math.

Which strategy gets which view

Strategy	Runway view
Lotto, Fixed Tiles, X Random, EV Gate, V4 presets, OG Sniper, Custom Equal	Single expected fire count (fixed equal-N / fixed gross when it fires)
Shadow	Standard / Best / Worst from recent same-config gross spends
Custom + OccupancyMatch sizing	Standard / Best / Worst (same as Shadow)

Variable-spend scenarios use trailing successful fires from the same strategy config:

• Best — lower typical spend → more fires
• Standard — typical spend after trimming outliers
• Worst — higher typical spend → fewer fires

Fewer than 10 same-config successful fires → honest “need more history” state (no fake trio). 10–19 → three-case with a limited-history note. Skips and zero-deploy rounds are excluded from the spend distribution. A config change starts a new history window.

Example for lotto-mining strategy

On 2026-09-22 a miner’s Strategy card looked inconsistent:

Miner address (the public address shown on Mining): DKw9TC5VRfb3Sgw6q1EuqrFoNJhc6E8mnW4gQimYEDwX

What we proved

1. The fire-count formula is correct. A live runway snapshot matched an independent recalculation.
2. The screenshot’s 814 is exact for a 0.0001 SOL gross with this miner’s live fees — not a math bug.
3. The displayed 0 SOL net burn was a 4-decimal formatting issue. The true net burn was 36,754 lamports (0.000036754 SOL).
4. By the time of a later production capture, the miner’s configured gross had moved to 0.0005 SOL, so remaining fires were in the mid-300s and falling as the miner kept firing — still formula-exact at every snapshot.

Screenshot-class inputs (0.0001 SOL gross)

Live fee schedule for this miner (not product defaults):

bps fee	25
flat fee	15,000 lamports
deploy fee	1,000 lamports
checkpoint fee	10,000 lamports
gross	100,000 lamports (0.0001 SOL)
protocol-side 10.504%	10,504 lamports
bps on gross	250 lamports
expected net burn	36,754 lamports
required float	126,250 lamports
forecast bankroll (reconciled)	30,017,252 lamports

At 4 decimal places, 36,754 lamports rounds to 0 — that is why the card said “Net burn ≈ 0 SOL per fire” next to hundreds of fires. With precise display it reads 0.000036754 SOL, and the two lines reconcile.

Live production snapshot (0.0005 SOL gross)

Captured 2026-09-22 ≈ 09:51 UTC:

gross	500,000 lamports (0.0005 SOL)
expected net burn	79,770 lamports
required float	527,250 lamports
forecast bankroll	29,063,763 lamports
remaining fires	358
Independent recalculation	1 + floor((29063763 − 527250) / 79770) = 358

A follow-up capture ~12 minutes later showed 347 fires with the same net and required float — the bankroll was still mining; the formula still matched exactly.

Limits and caveats