Under the illustrative assumptions used here, an Antminer KS5 Pro running at 21 TH/s and 3,150 W would generate about $4.17 per day after a 2% pool fee, leaving approximately $0.39 after electricity at $0.05/kWh. That balance is not net profit: it excludes the purchase price, depreciation, hosting, maintenance, external cooling, and other costs. It is a scenario result, not a current earnings quote or a forecast.

A useful Antminer KS5 Pro profitability estimate depends on inputs that move independently: Kaspa's subsidy reductions, network hashrate, KAS price, measured electrical draw, and downtime. The model below shows how to replace those inputs and distinguish powered-off downtime from faults that interrupt mining while the unit continues consuming power.

Confirm the exact device

Before any calculation, the exact hardware model and firmware version should be confirmed, since Bitmain markets several Antminer KS-series units with different specifications. According to Bitmain's published specification sheet, the KS5 Pro is rated at 21 TH/s hashrate, 3,150 W power consumption measured at the wall at 25°C ambient, and a resulting power efficiency of 150 J/TH (Bitmain, KS5 Pro Specifications). These are manufacturer typical values at a stated test condition, not guaranteed outputs for every deployment.

The same specification sheet states a tolerance of ±3% on hashrate and ±5% on both wall power and power efficiency. This means a unit could reasonably measure between roughly 20.4 and 21.6 TH/s, and between about 2,993 W and 3,308 W, while still meeting the published specification. For a profitability test, the operator's own meter or PDU reading should be used in place of the nameplate figure wherever possible, since the nameplate value only represents a typical result under the manufacturer's test conditions. At the nameplate 3,150 W, continuous operation consumes 3.15 kW × 24 hours = 75.6 kWh per day; this figure recalculates proportionally if measured wall power differs from the nameplate rating.

Antminer KS5 Pro power consumption should also be understood as a wall-power figure, not a chip-level estimate. It does not include cooling infrastructure, PDU losses, or other facility loads, which a hosting or colocation cost model would need to add separately.

Collect current network inputs

Kaspa's network conditions change continuously, so a revenue estimate needs network hashrate, block subsidy, block production rate, and KAS/USD price. This worked example assumes a network hashrate of 339.50 PH/s and a subsidy of 2.06017223 KAS per block. These are illustrative model inputs, not a verified network snapshot. Kaspa's 10-blocks-per-second target gives approximately 864,000 blocks per day for this theoretical calculation (Kaspa, KIP-14).

For price, the example uses the KAS/USD daily close of $0.03861142 for October 13, 2026, UTC, as listed by CoinGecko's historical data page, checked on October 14, 2026. Combining that historical price with assumed network inputs creates an illustrative scenario, not a reconstruction of actual earnings on that date.

For an operational estimate, replace the assumed values with sourced network data and record the collection time and time zone, the network-hashrate estimation window, the applicable subsidy, and the price timestamp. When reconciling a completed day, use inputs representative of that same period rather than a single current reading.

Calculate the subsidy-only estimate

Use the same units for miner and network hashrate: 339.50 PH/s = 339,500 TH/s.

Theoretical KAS/day at full availability = (miner hashrate ÷ network hashrate) × blocks per second × 86,400 × subsidy per block

With the assumed inputs:

(21 ÷ 339,500) × 10 × 86,400 × 2.06017223 ≈ 110.10 KAS/day

Estimated revenue (USD/day) = theoretical KAS/day × productive-time fraction × (1 − applicable pool fee) × KAS/USD price

The productive-time fraction is productive mining hours divided by 24. At full availability and an illustrative 2% pool fee:

110.1024 × 1 × 0.98 × $0.03861142 ≈ $4.17/day

This estimates subsidy-derived revenue only; transaction-fee income is excluded. It assumes constant hashrate while productively mining and constant network inputs over the modeled day. Actual credits also depend on accepted work and the pool's payment rules. If measured hashrate already includes downtime or rejected work, do not deduct those losses again through an additional availability factor.

The 2% fee corresponds to the PPLNS rate in the cited ViaBTC documentation; it is not a universal fee for all payment methods. For ViaBTC PPS+, the documented subsidy-component fee is 4%, while the transaction-fee component has a separate 2% fee. Replace the fee according to the chosen method and account for transaction-fee income separately (ViaBTC, How are profits calculated?, checked October 14, 2026).

Separate emission from difficulty

Two distinct mechanisms affect how much KAS a given hashrate can expect to earn, and they should not be merged into a single variable. The first is Kaspa's emission schedule: the block subsidy declines according to predetermined monthly subsidy periods, independent of network hashrate. The second is difficulty, which adjusts in response to changes in total network hashrate so that the actual block production rate stays close to the protocol's 10-blocks-per-second target. A rise in network hashrate increases difficulty and reduces a fixed-hashrate miner's expected share of blocks; a subsidy reduction lowers the reward per block regardless of difficulty. Treating these as one variable obscures which factor is driving a change in expected proceeds.

Kaspa's May 2025 Crescendo upgrade raised the target block rate from 1 to 10 blocks per second and adjusted difficulty for the new rate. It also divided the per-block subsidy by the block rate, preserving the emission schedule rather than multiplying issuance tenfold. Historical comparisons therefore need consistent per-block, per-second, or per-day units; pre-upgrade rewards per block cannot simply be combined with the post-upgrade block rate (Kaspa, KIP-14).

For the emission sensitivity test, assume the subsidy falls from 2.06017223 to 1.94454365 KAS/block, approximately 5.61%, while all other inputs remain constant. The theoretical estimate then falls from about 110.10 to 103.92 KAS/day before pool fees. These values illustrate the effect of a monthly subsidy step; they are not presented as a verified current subsidy and a dated future adjustment.

Kaspa's subsidy periods are determined through DAA-score-based protocol calculations, with a protocol month representing 30.4375 days. A calendar date for the next reduction should therefore be treated as an estimate and checked against current network progress, rather than stated as a guaranteed deadline. The subsidy schedule is distinct from changes in network hashrate and difficulty (Kaspa, KIP-14).

Model power and downtime

Electricity cost scales directly with measured wall power and runtime. At the KS5 Pro's nameplate 75.6 kWh/day, illustrative daily electricity costs at several rates are:

These figures cover miner electricity only; they exclude external cooling, hosting fees, pool fees, maintenance, and any other operating cost.

Downtime is where a single daily-earnings figure breaks down most clearly, because not all downtime has the same economic effect. Use measured power for each operating state:

Daily energy (kWh) = mining power (kW) × productive mining hours + fault-state power (kW) × powered-but-unproductive hours + powered-off draw (kW) × powered-off hours

The three time categories must sum to 24 hours. For a fully disconnected unit, powered-off draw is zero. Fault-state power must be measured; a miner remaining powered on does not establish that it still draws its full mining power.

Daily electricity cost = daily energy × electricity rate

Balance after miner electricity = estimated revenue after pool fee − daily electricity cost

The following tables use the subsidy-only example above: approximately $4.17/day at full availability after a 2% pool fee, and electricity at $0.05/kWh. They model two specific power assumptions, not every possible fault behavior.

When a miner is fully powered off, both mining time and electricity use decline together:

For the second scenario, assume the miner cannot submit valid shares during the unavailable period but continues drawing the full 3.15 kW. Under this assumption, electricity use remains at 75.6 kWh/day while estimated mining revenue falls. A pool-connection failure, network interruption, or configuration fault does not by itself prove this power behavior; replace the assumed fault-state power with a measured value for the device and firmware in use.

At 90% share-submission availability, the full-power fault scenario produces an estimated balance of −$0.03/day, while the powered-off scenario leaves about $0.35/day after miner electricity. The difference comes from the assumed fault-state energy use. If the miner reduces power during a fault, the result must be recalculated using that lower draw. Higher electricity rates increase the cost of whatever power continues to be consumed during unproductive periods.

One way to reduce the second scenario's frequency is to configure multiple pool endpoints in priority order, so that a lower-priority pool is used automatically if a higher-priority one becomes unreachable; Bitmain's KS5 manual describes support for up to three configured pools in descending priority. This can help with an unreachable endpoint, but does not resolve a local internet outage or every configuration fault. Whether this failover configuration is worth setting up depends on an operation's own monitoring and connectivity reliability, and should be treated as one option to consider rather than a fixed requirement.

Reconcile actual KAS credits

A profitability test is only useful if its inputs are compared over matching time windows and the different measurement types are kept separate. Local miner hashrate, pool-estimated hashrate, submitted shares, and credited rewards describe different things and should not be substituted for one another.

ViaBTC's documentation notes that its real-time pool hashrate is calculated from a 10-minute rolling average, while a miner's own dashboard may refresh far more frequently; a persistent gap between the two can also reflect network latency, rejection rate, firmware compatibility, or device settings rather than a pool error (ViaBTC Support, Why is the Hashrate Shown in the Mining Pool Lower than that of the Mining Machine). Comparing readings with different averaging windows can create an apparent mismatch without establishing a performance problem. For a daily profitability check, compare average hashrate, energy use, and credited rewards over the same complete 24-hour period, retaining and labeling all reboot, warm-up, and outage periods. ViaBTC's Profit Detail uses UTC+8, so align the comparison to that reporting window. If the purpose is a separate stable-operation test, filter both datasets to identical operating intervals and do not present that result as whole-day profitability.

Payout method also affects how closely a short-period result will track the theoretical model above. ViaBTC's current published options for KAS mining are PPS+ and PPLNS, with a 2% fee listed for PPLNS in its profit-calculation documentation; PPS+ applies a documented 4% fee to the block-reward component and 2% to the transaction-fee component (ViaBTC Support, How are profits calculated). Under PPLNS, a short measurement window can diverge from the theoretical network-share estimate because actual rewards depend on which blocks the pool finds during that window; under PPS+, the subsidy component is paid through PPS and is less exposed to the pool's short-term block-finding luck, while the transaction-fee component uses PPLNS accounting. Recheck the applicable terms when running the model (ViaBTC Support, KAS Mining).

Reconciling actual credited KAS against the model in this article means checking: the exact subsidy and network hashrate in effect during the measured period, the operator's own measured wall power and uptime (not the nameplate figure), the rejected-share rate shown on the miner or pool dashboard, and the payout method's accounting rules. A gap between the model and the credited result is not automatically an error — it may reflect pool luck under PPLNS, a different subsidy than the one used in the model, or downtime that was not recorded. Isolating which of these explains the gap is more useful than treating either the model or the credited total as the single correct number.

FAQ

Is 21 TH/s and 3,150 W a guaranteed result for every KS5 Pro unit?

No. These are Bitmain's manufacturer typical specifications at 25°C ambient, with published tolerances of ±3% on hashrate and ±5% on wall power and efficiency; actual results depend on the individual unit and operating conditions.

Why would the same uptime percentage produce different profitability results?

Because electricity use depends on the power drawn during the unavailable period. A fully powered-off miner consumes no miner electricity during that time. A powered-but-unproductive miner may continue consuming power, but the amount must be measured. The full-power fault scenario in this article assumes 3.15 kW throughout; that assumption is not a universal consequence of losing connectivity.

Does Kaspa's subsidy decline on a fixed schedule like Bitcoin's halving?

Kaspa also has a predetermined emission schedule, but implements reductions in monthly steps rather than Bitcoin's multi-year halving steps. Its protocol uses DAA-score-based subsidy periods, so check the applicable subsidy and treat the calendar date of a future adjustment as an estimate.

Why might pool-reported hashrate differ from the miner's own dashboard?

Pool-side hashrate is typically calculated as a rolling average over a stated window (for example, 10 minutes), while a miner's local dashboard may refresh more frequently; differences can also reflect network latency, rejected shares, firmware, or device configuration.

References

• Bitmain Support. "KS5 Pro Specifications."
• CoinGecko. "Kaspa Historical Data."
• ViaBTC Support. "Why is the Hashrate Shown in the Mining Pool Lower than that of the Mining Machine."
• ViaBTC Support. "How are profits calculated."
• ViaBTC Support. "KAS Mining."
• Kaspa. "KIP-14: The Crescendo Hardfork."
• Bitmain. "KS5 Manual," September 2024.