Crypto Mining Profitability (GPU and CPU)

What this calculator actually estimates

The page compares the estimated daily economics of the coins in its active coin table. It does not simulate a blockchain one block at a time. Instead, each listed coin has an algorithm, a hashrate unit, and a USD-per-day index for one unit of hashrate. Your selected hardware contributes a rate for that algorithm. The engine multiplies the rate by the index, reduces the gross amount by the entered pool fee, and then subtracts the fleet electricity cost. The result is a comparable daily figure for each compatible row.

The word profitability here means profit after the modeled electricity charge and pool fee, not complete business profit. The page does not automatically subtract cooling, rent, labor, taxes, network fees, withdrawal fees, maintenance, financing, depreciation, or the purchase price of a device. Hardware cost is an optional input for a separate payback calculation; it is not deducted from the daily profit rows. This separation lets you see operating economics and simple capital recovery as two related but different questions.

The calculator is most useful as a controlled what-if worksheet. Change one assumption at a time and observe which output moves. For example, changing the electricity rate tests energy sensitivity, changing the power draw tests measurement uncertainty, and changing a hashrate override tests a tuning result. A high-ranked row is not a command to mine that coin. It is the row that produces the largest modeled daily profit among the listed and compatible choices under the values currently entered.

• The comparison is deterministic arithmetic over entered values and dated indices.
• Daily profit includes electricity and pool fee, but not every real operating cost.
• The ranking is relative to the active device and coin tables, not a complete market survey.
• Use the result to inspect assumptions, not as investment advice or a live earnings guarantee.

Select a device and set the quantity

Start with Device model. The general page exposes the active hardware list across NVIDIA cards, AMD cards, CPUs, ASIC miners, and any other entries supplied by the site-managed table. Selecting a model fills a typical power draw and the rates that the bundled data associates with that model. Those values are starting points, not locked specifications. The fields remain editable because two units with the same model name can behave differently after firmware changes, memory settings, cooling conditions, drivers, or age.

Quantity is the number of identical devices in the single-device mode. It must be a finite whole number from 1 through 1000. With one selected model, the engine multiplies each compatible model rate by this quantity and multiplies the entered per-device watts by the same quantity. The page therefore treats Quantity as a count of devices, not a multiplier for a single hashrate measurement that already represents an entire farm. If your measurement is for the whole fleet, do not enter it as though it were the draw of one device.

The selected model is still a meaningful input even when you are exploring a small home setup rather than a formal mining rig. It determines the default rates and makes the result reproducible for another reader. If the active site table has been customized, the options may differ from the bundled snapshot. A model must be present in the current device table, and a value that merely resembles a display label is not a substitute for a valid model entry.

• Use one model and Quantity for repeated identical devices.
• Quantity accepts whole devices only: 1 to 1000 inclusive.
• Treat the filled power and hashrates as editable estimates until you measure your own setup.
• Enter per-device watts in single-device mode, not the total wall draw of the fleet.

Use a mixed rig list when devices differ

The optional Mixed rig list is for a fleet that cannot be described well by one model and one quantity. Enter one line per model, using a device key, a lowercase x, a whole-number count, and optionally an at sign followed by per-device watts. A valid example is rtx-3070 x 2 @ 140 followed on another line by rx-6600 x 1 @ 55. The model key identifies the table entry; it is not the longer display label shown in the selector. Blank lines and lines beginning with a number sign are ignored.

When the rig field contains nonblank text, its lines replace the single-device picker, Quantity, and Power draw values for the fleet arithmetic. The handler still validates the ordinary selected model, quantity, and power fields before it enters rig mode, so keep those fields valid even when the list is doing the real work. Every rig line must name a device available to this page, use a count from 1 through 1000, and use positive watts no greater than 100000 when an at-value is supplied. The parser accepts x, the multiplication sign, or an asterisk as the separator, but the plain ASCII x is easiest to review.

The at-value is a per-device draw, not the total draw for that line. In rtx-3070 x 2 @ 140, the line contributes 280 W. If the at-value is omitted, the model's table power is used for each device on that line. The parser permits at most 200 nonempty rig lines. A misspelled key, a zero count, a negative-looking at-value, or a model excluded by a page-specific hardware scope stops the calculation with a validation message rather than silently dropping the line.

• Use one line such as rtx-3070 x 2 @ 140 for two devices at 140 W each.
• A nonempty rig list takes precedence over the single-device quantity and power values.
• Each count is a whole number from 1 through 1000; the list accepts at most 200 lines.
• Use device keys from the active table, and check spelling before interpreting an error.

Power draw, watts, and electricity units

Power draw is entered in watts, abbreviated W. A watt is a rate of energy use. The engine first adds the per-device watt contribution across the fleet, then assumes that total remains constant for 24 hours. It converts watt-hours to kilowatt-hours by multiplying watts by 24 and dividing by 1000. The resulting daily kilowatt-hours are multiplied by Electricity price in dollars per kWh. In symbols, daily power cost equals total watts x 24 / 1000 x dollars per kWh.

For a single RTX 3070 at 150 W, continuous operation consumes 150 x 24 / 1000 = 3.6 kWh per day. At $0.12 per kWh, the modeled charge is $0.432 per day. For two of those devices, the draw is 300 W and the daily use is 7.2 kWh, so the charge is $0.864. These are energy charges only. If the value came from a card specification rather than a wall meter, it may omit the power supply, motherboard, fans, storage, networking, and conversion losses.

The engine uses one power value for every algorithm row. It does not assume that a card draws a different amount because it is mining one coin rather than another. If tuning changes power by algorithm, choose a representative measured value for the scenario or run separate scenarios with different power inputs. In a mixed rig, the optional at-value gives a separate per-device power assumption for each line, which is more precise than forcing every model to share one watt value. Electricity price may be zero within the field contract, but a zero entry means the model intentionally excludes the power charge; it does not mean the real meter is free.

• W is instantaneous draw; kWh is the daily energy quantity used for billing.
• Daily energy is total watts x 24 / 1000 under the 24/7 assumption.
• Electricity price accepts $0 through $10 per kWh.
• Wall-measured draw is usually more representative than a component nameplate value.
• Include system overhead in the measured scenario if you want it represented.

Hashrate, algorithms, and unit labels

A hashrate is meaningful only with its algorithm and unit. The active coin table pairs each coin with an algorithm such as ethash, kawpow, autolykos2, octopus, randomx, sha256, or another listed family. The same table also states the unit expected for that algorithm, which may be H/s, MH/s, GH/s, TH/s, or Sol/s. A rate of 30 MH/s is not interchangeable with 30 GH/s. Those prefixes differ by a factor of 1000, so entering a number in the wrong unit can overwhelm every other assumption while still looking numerically tidy.

In normal mode, the engine looks up the selected model's rate for each coin algorithm. If two RTX 3070 devices each supply 165 MH/s for autolykos2, the fleet rate for that algorithm is 330 MH/s. In a mixed fleet, rates are added only from devices that have a rate for the row's algorithm, then multiplied by each line's quantity. A coin whose algorithm receives no rate is skipped. Skipping is a compatibility result, not a zero-profit result, because the page has no basis for pretending that an unsupported device can mine that row.

The rate is not an amount of coins earned and it is not a dollar value by itself. It is the work rate that the coin index expects. The index supplies the estimated USD earned per day for one unit of that rate at the relevant snapshot. Keep the algorithm spelling and unit together when you copy a measured result from a miner screen. If your software reports a different prefix, convert deliberately before entering it; do not rely on the field to infer the conversion.

• Read every hashrate as a number plus its algorithm-specific unit.
• MH/s, GH/s, TH/s, H/s, and Sol/s are different scales.
• Native rates are summed across compatible devices in a mixed fleet.
• Coins with no available rate are omitted from the table unless an override supplies one.
• A hashrate is not a coin quantity, a revenue amount, or a promise of payout.

Enter a per-algorithm hashrate override carefully

Per-algorithm hashrate overrides let you replace a model's typical rate with a measured or tuned value. Use one line such as kawpow = 31.5. The parser requires an algorithm name, one equals sign, and a positive finite number. Use the exact lowercase algorithm spelling shown by the coin data. An unknown name is accepted as text, but it has no effect unless one of the listed coins uses that exact algorithm, so a typo can look like a successful entry while leaving the table unchanged.

An override replaces the calculated native rate for that algorithm. In single mode, the custom number is multiplied by Quantity. In mixed-rig mode, the custom number is multiplied by the total fleet size, not by each model's native rate. This is an important modeling choice: autolykos2 = 200 on a three-device mixed rig means 200 MH/s is assumed for each of the three devices, even if one of the models normally has no autolykos2 entry. Use a fleet-wide override only when that common per-device assumption is what you intend.

Overrides affect hashrate, not power draw, coin price, pool fee, or the device table. A very optimistic rate will raise revenue linearly while leaving energy cost unchanged, which can make a result look unusually attractive. Measure at the pool or miner level over a representative interval, record the unit, and rerun the scenario after the device reaches a stable temperature. If you want different rates for different models in a mixed rig, native table rates or separate scenarios are safer than one fleet-wide override.

• Write one override per line, for example kawpow = 31.5.
• Use the exact algorithm label and the unit expected by the matching coin rows.
• An override is per device and then scales by Quantity or total fleet size.
• The override does not alter watts or electricity cost.
• Recheck a measured rate after thermal, driver, or tuning changes.

What the price, device, and coin tables do

Three hidden fields make the page data-driven without asking visitors to maintain a long form. Device table is an array of device records. Each valid record has a unique key and label, positive powerW, a nonempty rates object, and a recognized hardware type. Coin table is an array of records with a symbol, name, algorithm, unit, nonnegative index, and nonnegative priceUsd. Price table is an object keyed by coin symbol. These fields are normally filled by the site rather than typed by hand, but the engine validates injected values because a page should fail clearly when its data contract is broken.

A nonempty device table replaces the bundled device list, and a nonempty coin table replaces the bundled coin list. That means a site-managed update can change which models and coins are available without changing the arithmetic handler. The selected model must exist in the active device table, and the coin rows are evaluated in the order supplied before being sorted by calculated profit. A device record with no positive rate is invalid. A coin record with a missing algorithm or unit is invalid. Duplicate keys or symbols are rejected so one record cannot silently shadow another.

The price table is slightly different. Its entry for a symbol may provide an index used for revenue; if a symbol is absent, or its index is not a finite nonnegative number, the engine falls back to that coin's bundled index. The price value is useful context for a live refresh, while index is the number that directly drives the arithmetic. An invalid nonempty price table must be valid JSON and an object, not an array. A malformed hidden table is an input error, not a signal to trust stale values without telling the visitor.

• Device table supplies model keys, labels, types, power, and native rates.
• Coin table supplies symbols, algorithms, units, indices, prices, and live-data identifiers.
• Price table supplies per-symbol indices for the revenue calculation when present.
• The active tables can replace bundled defaults, so the visible data date matters.
• Hidden fields are managed data inputs and should not be edited casually.

Snapshot data and the live-price refresh

With an empty Price table, the handler uses the bundled snapshot. The reviewed bundled snapshot is dated 2026-09-08, and the result note prints the accepted data date so the baseline is visible. Device rates are typical tuned figures, not a measurement of your hardware. Coin indices are rough snapshot estimates, not exchange quotes. A date tells you when the baseline was assembled; it does not turn an estimate into a historical guarantee or tell you that the network had one fixed difficulty during the entire day.

The browser refresh control can request current USD prices from an external price feed. When a positive current price is available, the page writes a Price table entry whose index equals the snapshot index multiplied by current price divided by snapshot price. This is a price rescaling operation. It does not fetch a new hashrate, difficulty, block reward, pool luck value, or device power measurement. The refresh therefore gives a more current price sensitivity view while intentionally holding the snapshot's other assumptions in place.

If a coin is not mapped, its current quote is unavailable, the response is invalid, the browser is offline, or the service is rate-limited, that coin keeps its dated price and index. The status message distinguishes a live refresh from a fallback, but the calculator can still be recalculated with the last table in the form. A live-price timestamp describes the quote request, while the data date in the result remains the device and index baseline. Treat a refreshed table as a scenario snapshot, not a continuous feed or live guarantee.

• Empty Price table means the dated bundled indices are used.
• Refresh can change price-scaled indices but does not update network difficulty.
• Failed, unmapped, or nonpositive quotes fall back to the prior coin values.
• The data date identifies the baseline; it is not proof that every live input is current.
• Recheck the scenario whenever price, difficulty, reward, or operating conditions change.

How daily revenue is calculated

For each listed coin, gross revenue is the fleet hashrate multiplied by that coin's USD-per-unit-per-day index. The pool fee is entered as a percentage from 0 to 100, converted internally to a fraction, and applied to gross revenue. Net daily revenue is therefore rate x index x (1 - fee fraction). A 1 percent pool fee uses a 0.99 multiplier. It is not entered as 0.01 in the Pool fee field; entering 0.01 means one hundredth of one percent.

The revenue calculation is row-specific because every coin can have a different algorithm, unit, and index. A two-device fleet may produce 330 MH/s for one algorithm, 122 MH/s for another, and no row at all for an algorithm that neither device supports. The index is already expressed as a daily USD amount per unit of hashrate, so the engine does not separately multiply by 24 in the revenue formula. The 24-hour conversion belongs to power cost, where watts must become energy.

The table's Revenue/day column is net of the pool fee but before electricity. This distinction helps isolate two drivers. If revenue changes when you edit a hashrate override or price table, the cause is the work or market assumption. If power cost changes when you edit watts or the kWh price, that is an energy assumption. The row's final Profit/day combines both. Looking only at revenue can select a coin that earns more before electricity but leaves less after the meter charge.

• Gross revenue = fleet hashrate x coin index.
• Net revenue = gross revenue x (1 - pool fee / 100).
• Revenue is daily USD before the modeled electricity charge.
• The table omits rows with no compatible rate unless an override supplies one.
• The index already represents a daily per-unit estimate; do not add another 24-hour factor.

How daily power cost is calculated

Power cost is independent of the coin row. Once the engine knows total fleet watts, it calculates daily kWh as total watts x 24 / 1000 and multiplies that amount by Electricity price. The same power cost is shown in every row because this page assumes the same fleet runs continuously while comparing alternative coins. That repeated value is not a duplication of charges; it is the common cost against which each revenue estimate is compared.

For the default two-device example, total draw is 300 W. Daily energy is 300 x 24 / 1000 = 7.2 kWh. At $0.12 per kWh, the cost is 7.2 x 0.12 = $0.864, displayed as about $0.86 in the headline result. If you change the pool fee, the power cost stays $0.864 because a pool does not change the watt-to-kWh conversion in this model. If you change the device count or per-device watts, both daily energy and cost move proportionally.

Monthly and yearly figures should be read as projections of the same daily assumption. The result panel multiplies the best row's profit by 30 or 365 for those profit projections and multiplies daily power cost by 365 for yearly electricity. It does not model leap days, outages, variable tariffs, time-of-use pricing, or a schedule that mines only part of each day. Use the daily number as the core result and treat longer periods as simple arithmetic extensions.

• The same fleet power cost is compared with every compatible coin row.
• Pool fee changes revenue, not watts or kWh cost.
• 30-day and 365-day outputs are straight-line projections from the daily result.
• Variable tariffs and part-time operation require separate scenarios or a different tool.

Profit, ranking, and the payback line

Daily profit is net daily revenue minus daily electricity cost. The table is sorted from the largest calculated profit to the smallest, so the first row is the best modeled operating result for the current inputs. Best means highest profit, not highest revenue, highest coin price, highest hashrate, or the most familiar coin. If every row is negative, the first row is simply the least negative choice among the rows that were calculated. The ranking does not transform a loss into a recommendation.

Hardware cost has one narrow job. When Rig cost is greater than zero and the best daily profit is positive, the engine reports payback on the best coin as rig cost divided by best daily profit, in days. It does not subtract hardware cost from the daily, monthly, or yearly profit figures. It also does not include resale value, repairs, financing interest, tax, shipping, installation, or the possibility that the best coin changes before the ratio is reached. This is a simple capital-recovery ratio under a fixed scenario.

If Rig cost is zero, or if the best profit is zero or negative, the payback result is the explicit text Not computable (no rig cost or no profit). That behavior is intentional. A negative daily result cannot repay a positive purchase cost by repeating the same loss, and a zero result has no finite recovery time. A positive payback number is also not a promise that the ratio will be achieved, because its denominator is an estimate that can change immediately with market and network conditions.

• Profit/day = revenue/day - power cost/day.
• Rows are ordered by profit, not by revenue or coin price.
• Hardware cost is used only for the simple best-coin payback ratio.
• Payback is reported only for a positive best profit and a rig cost above zero.
• A computed day count assumes the same scenario persists until recovery.

Worked example: two identical RTX 3070 devices

Use the default model RTX 3070, Quantity 2, Power draw 150 W, Electricity price $0.12 per kWh, Pool fee 1 percent, and no hardware cost. For the Ergo row in the bundled snapshot, one RTX 3070 contributes 165 MH/s on autolykos2, so the two-device fleet contributes 330 MH/s. The row's index is $0.03 per MH/s per day. Gross revenue is 330 x 0.03 = $9.90. After the 1 percent pool fee, net revenue is $9.90 x 0.99 = $9.801.

The fleet draws 2 x 150 = 300 W. Its daily energy use is 300 x 24 / 1000 = 7.2 kWh, and its daily power cost is 7.2 x 0.12 = $0.864. Profit for the Ergo row is therefore $9.801 - $0.864 = $8.937. The result renderer rounds the headline to $8.94 per day and the power line to $0.86 per day. The current bundled comparison places Ergo first for these particular snapshot values, while the table still shows the other compatible rows.

This example demonstrates why quantity appears in both sides of the equation. It doubles the hashrate contribution and doubles the watts. If you doubled only the hashrate while leaving power at one device, the result would be internally inconsistent. If you entered 300 W in the per-device field while retaining Quantity 2, the engine would model 600 W and charge twice the intended electricity cost. Enter the physical meaning of each field before trusting the arithmetic.

• Fleet hashrate for Ergo: 165 x 2 = 330 MH/s.
• Net revenue: 330 x 0.03 x 0.99 = $9.801/day.
• Power cost: 300 x 24 / 1000 x 0.12 = $0.864/day.
• Profit: $9.801 - $0.864 = $8.937/day, displayed as about $8.94.
• Payback remains unavailable because hardware cost was left at zero.

Worked example: a mixed rig with different watts

Now enter rtx-3070 x 2 on one line and rx-6600 x 1 @ 55 on a second line. Keep the electricity price at $0.12 per kWh and the pool fee at 1 percent. The RTX line contributes 300 W and the RX line contributes 55 W, for a total of 355 W. The fleet size is three devices. For Ergo, the two RTX cards still contribute 330 MH/s, while the RX 6600 has no native autolykos2 rate in the bundled table, so the Ergo rate remains 330 MH/s rather than gaining an invented contribution.

Daily energy is 355 x 24 / 1000 = 8.52 kWh. Power cost is 8.52 x 0.12 = $1.0224 per day. Ergo net revenue is still 330 x 0.03 x 0.99 = $9.801 because the price and compatible hashrate did not change. Profit is $9.801 - $1.0224 = $8.7786, which the headline formats as about $8.78 per day. The extra device raises the energy bill in this example without raising the selected row's native Ergo hashrate.

That result is not a judgment about the RX 6600. It is a consequence of this row's algorithm and the rates present in the active table. The RX device may contribute to another row, such as one using a listed algorithm for which it has a rate. Review the entire table instead of assuming every device contributes to every coin. If you use an override for an algorithm, remember that the override is fleet-wide per device and can change this compatibility behavior by assumption.

• The at-value 55 means 55 W per RX 6600, not 55 W for the whole line.
• Total draw is 2 x 150 + 1 x 55 = 355 W.
• Daily power cost is 355 x 24 / 1000 x 0.12 = $1.0224.
• A device contributes to a coin row only when its algorithm rate exists or an override supplies one.
• Mixed-rig output should be checked row by row, not inferred from the device count alone.

Worked example: an override and a simple payback

Suppose one RTX 3070 is selected, but a stable measurement supports 200 MH/s for autolykos2 instead of the typical 165 MH/s. Enter autolykos2 = 200, set Power draw to 200 W, Electricity price to $0.10 per kWh, Pool fee to 0 percent, and Rig cost to $100. For Ergo, the override gives a 200 MH/s rate. At the bundled index of $0.03 per MH/s per day, revenue is 200 x 0.03 = $6.00 per day.

The power calculation is 200 x 24 / 1000 = 4.8 kWh per day, then 4.8 x 0.10 = $0.48 per day. Modeled profit is $6.00 - $0.48 = $5.52 per day. Because the hardware cost is positive and the best profit is positive, the payback ratio is $100 / $5.52 = about 18.1 days. The ratio is mathematical output for the fixed inputs, not a forecast that the market will hold or that the device will operate without interruption for 18 days.

If the same override were entered with three devices in a mixed rig, the engine would treat it as 200 MH/s per device and use 600 MH/s for a matching row. That may be a valid assumption for identical tuned devices, but it is not a way to express three different measured rates. To model three different rates, retain native table values if they are adequate, run separate scenarios, or use a data table whose records reflect those devices rather than forcing one common override.

• Override rate: 200 MH/s for one device on autolykos2.
• Revenue: 200 x 0.03 = $6.00/day before electricity.
• Power cost: 200 x 24 / 1000 x 0.10 = $0.48/day.
• Profit: $5.52/day; $100 / $5.52 gives about 18.1 modeled days.
• Payback changes immediately if the rate, price, watts, fee, or cost changes.

Units, boundaries, and validation behavior

Validation is part of the calculator's meaning, not a cosmetic form feature. The selected device must be a valid key in the active device table. Quantity must be finite, integral, and between 1 and 1000. Power draw must be finite and between 0.01 and 100000 W. Electricity price must be finite and between 0 and 10 dollars per kWh. Pool fee must be finite and between 0 and 100 percent. Rig cost must be finite and between 0 and 1000000000 in the page's dollar convention. A decimal quantity, a negative price, an infinite value, or a zero watt draw is rejected rather than rounded into a different scenario.

Rate override text is parsed line by line. Empty lines and comment lines beginning with a number sign are ignored, but a nonempty line must have exactly an algorithm side and a positive finite numeric rate. A mixed rig line must match the key-count pattern and its optional watts must be positive. Device and coin tables must be nonempty arrays when supplied, and each entry must carry the fields needed for arithmetic. Price table text must parse as a JSON object. These checks protect against malformed hidden data as well as ordinary visitor mistakes.

The data date is accepted when it matches the YYYY-MM-DD text pattern; otherwise the engine uses the bundled snapshot date. A hardware scope can restrict the available device types on specialized pages, while the general crypto-mining record leaves that scope empty. If no coin rows remain compatible, the handler asks for a valid rate or override. If a numeric result becomes nonfinite, the result formatter asks for smaller inputs. Validation cannot prove that a hashrate is honest or that a price is current; it can only enforce the shape and range of the arithmetic contract.

• Whole-number fields are not silently rounded.
• Bounds protect predictable arithmetic and browser behavior.
• Text tables and override lines are parsed and validated before calculation.
• A valid shape does not prove a measured rate, current market, or real payout.
• Correct an invalid input instead of replacing it with a nearby value without recording that change.

Reading positive, zero, and negative profit

A positive daily profit means the entered net revenue is greater than the entered electricity cost for that row. It does not mean the whole operation is profitable after cooling, equipment, taxes, fees outside the pool fee, or your time. A positive result can be useful for comparing two electricity rates or two measured devices, but it should be described as positive under the modeled assumptions. The word positive should never be expanded into a promise about future cash flow.

A zero result means the modeled revenue and modeled power cost are equal. A negative result means the revenue after the pool fee is less than the electricity charge. If all compatible rows are negative, the first row is the least negative under the current data, not a profitable exception. The negative sign is valuable information: it shows that changing the electricity price, power draw, hashrate, pool fee, or market assumption may be more important than choosing among the currently listed coins.

You can calculate a simple electricity break-even rate for a positive-revenue row by dividing its net daily revenue by its daily kWh. This is an interpretation aid, not a separate displayed result. For example, if a row makes $2.00 before power and consumes 4 kWh per day, its modeled break-even electricity price is $0.50 per kWh before all other costs. Real break-even analysis should also include the omitted costs and the possibility that the revenue assumption changes.

• Positive means the modeled row covers the modeled electricity charge.
• Zero means modeled revenue and modeled power cost match.
• Negative means electricity exceeds net modeled revenue for that row.
• The first row can be the least negative row when every option loses money.
• Do not turn a positive arithmetic result into investment advice.

Stale data, volatility, and operating reality

Mining economics can change faster than a carefully written spreadsheet. A coin price can move between the moment you read a result and the moment a pool records a share. Network difficulty, block reward, algorithm competition, pool conditions, and payout rules can also change. The bundled index compresses many of those realities into one dated estimate. A live price refresh changes only the price-linked portion of that estimate. It does not recalculate the whole network economy, so a refreshed number can still be stale in an important way.

Hardware figures have their own uncertainty. A typical rate may assume a particular memory timing, core setting, fan curve, driver, firmware version, or temperature. A wall meter may show more power than the device table because the meter includes the power supply and host system. Conversely, a software reading may omit conversion loss. A device that reaches its stated rate for ten minutes may not sustain it overnight. Use a sustained observation and note whether the value is per device or for the whole fleet.

The 24/7 assumption is also a source of drift. Planned downtime, heat protection, internet outages, rejected or stale shares, pool luck, maintenance, and intermittent throttling all reduce realized output. The calculator's note explicitly warns that power is treated as constant across algorithms and that Scrypt figures exclude merged-mined Dogecoin bonuses. Keep a dated copy of the inputs used for a comparison, refresh or replace them when conditions change, and avoid presenting one favorable screen as a durable annual return.

• Price movement alone can make a previously attractive row less attractive.
• Difficulty, rewards, pool behavior, and downtime are not updated by a price refresh.
• Typical device rates and watts can differ from sustained wall measurements.
• The model assumes continuous operation and does not model pool luck or stale shares.
• Scrypt rows do not include merged-mined Dogecoin bonuses in this contract.

Common input and interpretation mistakes

A frequent mistake is entering total fleet watts in a per-device field. If a two-card setup measures 300 W at the wall, entering Quantity 2 and Power draw 300 W models 600 W before any other factor. In a mixed list, the same error happens when 280 W is entered after rtx-3070 x 2 @ 280; the parser reads 280 W per card and models 560 W. Write down whether each measurement is per unit or total before opening the page.

Another mistake is confusing an algorithm, a unit, and a coin. An ethash rate cannot be pasted into a kawpow override merely because both values are written in MH/s. Equal prefixes do not make algorithms interchangeable. Similarly, a Pool fee of 1 means 1 percent, while 0.01 means 0.01 percent. A hardware cost of zero intentionally disables payback; it does not mean the page estimated that the equipment was free.

Finally, remember that any text left in Mixed rig list changes the mode. A previous experiment can continue to replace the visible model and quantity until the field is cleared. Check the data date, the live-price status, the units beside each rate, and the first table row before sharing a result. If a custom hidden table or Price table was injected, confirm that it is the table you intended rather than assuming the page silently restored the bundled snapshot.

• Do not enter whole-fleet watts as per-device watts.
• Do not use a rate from one algorithm as an override for another algorithm.
• Enter 1 for a 1 percent pool fee, not 0.01.
• Clear old mixed-rig text when returning to single-device mode.
• Check row labels, units, data date, and price status before comparing outputs.

Programming the arithmetic safely

The mining engine is a pure calculation layer. It does not need the page DOM, a network request, or a wallet connection to calculate a result. The browser layer supplies defaults and site-managed tables, optionally obtains price quotes, and then passes ordinary values to the handler. Keeping those responsibilities separate makes the arithmetic testable: the same input object can be evaluated repeatedly without relying on a browser clock or a network response.

A safe implementation validates choices and numeric ranges before doing multiplication. It parses the single-device path or the mixed-rig path, builds a fleet specification, totals watts and device count, parses overrides, chooses a price index for each coin, calculates revenue and profit, skips unsupported algorithms, and sorts rows by profit. It should preserve the unit associated with every rate and should not use formatted currency strings as inputs to later arithmetic. Currency rounding belongs at display time, after the numerical result has been calculated.

The payback branch deserves its own condition. The denominator is the best row's numeric profit, not its formatted headline text. Only a positive denominator produces a finite recovery ratio. A zero or negative denominator must remain an explanatory nonnumeric result. Likewise, a custom table should be validated as data before its fields are read. Accepting malformed JSON, silently treating a bad rate as zero, or converting a whole-fleet measurement to a per-device value inside the handler would create plausible but false output.

• Keep input validation, table parsing, arithmetic, and display formatting conceptually separate.
• Calculate with numeric values and round only when formatting a result for visitors.
• Treat mixed-rig parsing and payback eligibility as explicit branches.
• Do not put network access or DOM assumptions inside the pure arithmetic handler.
• Preserve algorithm and unit metadata alongside every hashrate.

Testing the calculation and its edge cases

A useful test suite starts with a known-answer example. The two RTX 3070 scenario should produce 300 W, $0.864 daily power cost, 330 MH/s for the matching Ergo algorithm, $9.801 net revenue after a 1 percent fee, and $8.937 profit. The single-device version should produce 150 W, $0.432 daily power cost, and a formatted best-profit headline near $4.47. These checks catch a missing quantity multiplier, a misplaced fee, or an incorrect watt-to-kWh conversion.

The next layer tests behavior rather than only one answer. Set a fee to zero and confirm that gross and net revenue match. Change an override and verify that only matching algorithms use it. Add a hardware cost and confirm that payback is cost divided by positive best profit while daily profit itself does not change. Set the best profit to zero or below and confirm that payback becomes the explicit noncomputable message. Inject a small device and coin table to prove that the data contract can expand without hardcoding a new branch.

Boundary tests should include Quantity 1 and 1000, invalid fractional quantity, power just below the minimum, electricity price zero and its maximum, pool fee zero and 100, an empty or comment-only rig, 200 rig lines, an unknown model, malformed JSON, an invalid device or coin entry, a missing compatible rate, and a valid negative-profit scenario. A live-price test should verify that an index rescales in proportion to a supplied price while the power cost remains unchanged. A synchronization test should ensure the bundled fleet file agrees with the engine's snapshot so a displayed default cannot drift from the tested one.

• Test exact arithmetic for one device, repeated devices, and a mixed rig.
• Test fees, overrides, custom tables, price rescaling, and payback separately.
• Test validation boundaries and malformed hidden data, not only happy paths.
• Verify that live price changes do not silently change watts or difficulty assumptions.
• Keep the generated fleet data synchronized with the source snapshot.

Limitations and decisions outside the model

This page does not predict future coin prices, network difficulty, block rewards, payout frequency, or pool luck. It does not connect to your wallet, confirm that a pool will accept a share, or measure whether a device is actually hashing. A live quote refresh is not the same as a live profitability feed because the index still carries snapshot assumptions. It also does not identify every mineable coin in existence; it compares the rows present in the active coin table and skips rows for which no rate is available.

Operating costs beyond the entered electricity price are outside the formula. That includes cooling, ventilation, extra air conditioning, facility rent, internet service, labor, insurance, taxes, conversion or withdrawal charges, repairs, replacement parts, firmware work, financing, and equipment depreciation. If the wall measurement excludes the host computer or power supply, those watts are outside the result too. Hardware cost is not a total-cost-of-ownership model, and payback does not value the hardware left at the end of the period.

The page also cannot decide whether mining is legal, suitable for a building, safe for a circuit, acceptable to a utility contract, or appropriate for your financial situation. It gives arithmetic about the values you enter. Add local technical, financial, tax, and operational review before acting on any scenario. The clearest honest description is: this is an entered-estimate comparison tool, not investment advice and not a guarantee that a live operation will earn the displayed amount.

• Not modeled: difficulty changes, reward changes, pool luck, stale shares, outages, and payout timing.
• Not modeled: cooling, host-system overhead unless entered, rent, taxes, maintenance, or financing.
• Not modeled: every possible coin or every device outside the active tables.
• Not provided: legal, electrical, tax, financial, or investment approval.
• A displayed estimate is not a live guarantee.

A repeatable review before trusting a comparison

Begin by recording the device model or each mixed-rig line, the date of the measurement, and whether watts and hashrate are per device. Clear Mixed rig list if you intend to use the single-device fields. Confirm that the selected algorithm and unit match the source of any override. Then enter the electricity price from the bill's applicable rate and decide whether the value includes time-of-use, demand, or a currency conversion that this simple field cannot represent.

Next, read the data status rather than skipping it. Note whether the result uses the dated snapshot or a refreshed price table. Compare the snapshot date with the date of your own device measurement. Scan the table for the actual compatible rows, not just the first label. Check that daily power cost is plausible from total watts, 24 hours, and kWh price. If the number is surprising, recompute those three factors before blaming the coin ranking.

Finally, separate three questions: does the row cover modeled electricity, how much hardware cost would the simple ratio recover, and what other costs or risks remain? Record the assumptions with the result and rerun the scenario when a material input changes. A result that survives this review is easier to explain and compare, but it remains an estimate. The disciplined habit is not to search for the most exciting number; it is to understand exactly which entered assumption produced it.

• Record whether each watt and hashrate value is per device or fleet-wide.
• Check units, fee format, data date, and live-price status.
• Recompute daily kWh and power cost independently for a surprising result.
• Distinguish operating profit, hardware payback, and total ownership cost.
• Keep the assumptions with the result and rerun after meaningful changes.

Questions visitors commonly ask

Why is the first row not always the coin with the highest revenue? Because the table is sorted by profit after electricity. A coin can have higher net revenue and still leave less profit if the fleet's power cost is common to the row or if its compatible hashrate assumption differs. Read Revenue/day and Profit/day separately.

Why does a price refresh not make the result fully live? The refresh rescales the coin index from a current price, but the calculation keeps the snapshot difficulty and other index assumptions. Hardware rates, watts, pool behavior, rewards, and downtime are not refreshed by that action.

Why is payback missing when the table shows a result? Payback requires both a positive hardware cost and a positive best daily profit. A zero cost gives no capital to recover, while a zero or negative profit cannot produce a finite recovery time under the same scenario.

Can I use the result as an earnings promise? No. It is arithmetic over entered estimates. Prices and network conditions move, devices vary, and several costs are intentionally outside the contract. Use it to compare clearly labeled scenarios, not to guarantee income or replace financial advice.

Why can a device disappear from a vendor-specific page? Some pages use a hidden hardware scope that filters the active device table. The general crypto-mining record leaves that scope empty, but a model still must be present in the current site-managed table.

• Highest revenue and highest profit are different rankings.
• A price refresh updates a price-linked scenario, not every mining variable.
• Payback is intentionally unavailable without positive cost and positive profit.
• The tool compares entered estimates and never guarantees future earnings.
• Hardware scope can limit which device keys are valid on a specialized page.