The ICERIVER KS7 can produce a positive operating result only when the value of its KAS earnings exceeds electricity or hosting charges and other operating costs. Recovering the purchase and deployment cost is a separate question. Its rated 30 TH/s and 3,500 W imply 116.67 J/TH, but those specifications alone cannot establish profitability.
A credible profitability check requires three separate inputs: the amount actually paid to receive and commission the unit, the electricity actually consumed at the wall or host meter, and the KAS actually credited by a pool over a matched period. This article walks through each input using the KS7 as the working example.
Verify model and batch
Before any calculation, confirm that the physical unit matches the specification sheet being used. ICERIVER's March 2025 announcement lists the KS7 at 30 TH/s rated hashrate and 3,500 W rated power. These are vendor-rated figures, not an independent measurement, and they should be checked against the label or control-panel readout on the delivered unit, since firmware revisions or hashboard batches can carry different nameplate values over a product's production run.
From the rated figures, efficiency is a direct calculation: 3,500 W ÷ 30 TH/s = 116.67 J/TH. This number is only valid for the paired 3,500 W / 30 TH/s rating; it cannot be recalculated from pool-reported hashrate unless a matching, independently measured power reading for the same period is also available. Pool dashboards estimate hashrate from submitted shares, not from power draw, so the two data sources should not be combined into a single efficiency figure without a dedicated power meter.
Include deployment cost
On October 14, 2026, the KS7 product page on iceriver.io, the website linked in BGIN's product announcement, displayed US$1,999 for the delivery model. This is a dated equipment-price reference, not a delivered-cost quote; buyers should confirm the selected model, availability, and final order total before purchasing. The product page states that the retail price excludes shipping, value-added tax, and applicable customs duties.
A more complete deployment budget follows this structure:
Delivered and commissioned cost = miner price + shipping + insurance + applicable sales or use tax + customs duty and brokerage + payment processing fees + required electrical or network equipment + any separate setup charge
Include each charge only once. For a hosted deployment, itemize the hosting setup charge and check whether it is already included in the quote. Because customs classification, duty rates, and tax treatment vary by destination and shipment value, this article does not assign a universal percentage; buyers should request a written quote that itemizes freight terms, the destination, tax handling, and customs responsibility before comparing miners on a cost basis.
A new KS7 purchase needs the full deployment budget for an investment-return calculation. For a unit already deployed, the original acquisition cost is sunk when assessing whether continued operation covers ongoing costs, although it still matters when evaluating the investment's overall return.
Test arrival-date assumptions
A KS7 on order typically does not begin hashing on the day it is purchased. Manufacturing lead time, freight transit, and customs clearance can place the commissioning date weeks after the order date. This gap matters because several of the inputs used in a profitability estimate are time-sensitive rather than fixed.
Kaspa's block subsidy follows a scheduled monthly reduction, so the per-block reward used in any projection should reflect the subsidy applicable around the unit's expected start date, including any reductions that occur before arrival. When checking emission data, distinguish KAS per second from KAS per block and confirm the applicable network parameters.
Likewise, Kaspa's network hashrate changes over time; a snapshot taken when the order is placed can differ materially from network conditions once the KS7 is actually mining. Because expected KAS output per unit of hashrate is inversely related to network hashrate, a rising network hashrate between order and arrival generally lowers expected output per TH/s, all else equal.
Model these inputs separately. Use the subsidy applicable to the expected commissioning period, then test explicitly labeled lower, unchanged, and higher network-hashrate assumptions against a dated baseline. These are planning scenarios, not forecasts, and the next subsidy reduction does not set an upper or lower bound on network hashrate.
Model net operating result
With the unit commissioned and running at its rated 3,500 W, theoretical daily energy use is:
3.5 kW × 24 hours = 84.0 kWh/day
This figure excludes facility overhead such as ventilation, transformers, or cooling infrastructure, and it assumes continuous operation at rated power with no downtime. A practical electricity-cost illustration, using 84 kWh/day, looks as follows:
| Electricity rate | Daily electricity cost |
|---|---|
| US$0.05/kWh | US$4.20 |
| US$0.10/kWh | US$8.40 |
Readers should substitute their own confirmed rate; hosting agreements in particular may bundle power with infrastructure or other services, so a hosting invoice should not be treated as a pure electricity rate without checking the contract terms.
On the KAS-output side, a subsidy-only estimate can be derived from the miner's share of network hashrate:
Estimated KAS/day = (miner hashrate ÷ network hashrate) × network subsidy per day
Use the same units for miner and network hashrate. The following worked example uses assumed network inputs to demonstrate the calculation; it is not a verified snapshot of current KS7 earnings.
| Input | Value | Basis |
|---|---|---|
| Miner hashrate | 30 TH/s | Manufacturer's rating; assumed sustained for 24 hours |
| Network hashrate | 338.2061 PH/s | Illustrative assumption, not a dated network observation |
| Block subsidy | 2.06017223 KAS/block | Illustrative assumption, not a verified current subsidy |
| Block rate | 10 blocks/second | Rate described by Kaspa; held constant for the example |
| KAS valuation price | US$0.03861142 | CoinGecko close for October 13, 2026, UTC |
The block-rate reference is Kaspa's network overview, and the valuation price comes from CoinGecko's historical data, accessed October 14, 2026. The dated price does not make the assumed network inputs observations from that date. For a purchase estimate, replace those assumptions with sourced network data, recording the observation time, hashrate estimation window, and applicable subsidy.
Under these assumptions, network subsidy is 20.6017223 KAS/second, or approximately 1,779,988.8 KAS/day. A 30 TH/s KS7 represents roughly 8.87 × 10⁻⁵ of network hashrate, producing an estimated 157.89 KAS/day. This assumes the miner sustains its full rated hashrate continuously and excludes pool fees, downtime, rejected shares, transaction-fee rewards, and any gap between rated and actual device hashrate.
Valuing that estimated output at US$0.03861142 per KAS gives approximately US$6.10/day. Combined with the electricity illustration above, the result before pool fees and non-electric operating costs is:
| Electricity rate | Illustrative gross KAS value | Electricity cost | Result before pool fees and other operating costs |
|---|---|---|---|
| US$0.05/kWh | US$6.10 | US$4.20 | +US$1.90/day |
| US$0.10/kWh | US$6.10 | US$8.40 | −US$2.30/day |
This comparison does not establish a current or universal profit or loss for the KS7. It demonstrates how electricity rates can change the result under the same production and valuation assumptions. Neither result establishes that the equipment will recover its purchase cost.
Once operating data is available, use a consistent period and calculate:
Net operating result at the chosen KAS valuation = (net KAS credited × KAS valuation price) − electricity or hosting charges − other operating costs not already included
State the valuation date or pricing method. This is a valuation-based result, not necessarily realized cash proceeds; a cash calculation should instead use actual sale proceeds after selling fees and the relevant cash expenses.
If credited KAS is already net of pool fees, do not deduct those fees again. If the hosting bill includes electricity, do not subtract a second electricity estimate. In a forecast, account for downtime by adjusting production and energy consumption, including any idle draw or fixed hosting charges. In an observed result, actual credited KAS and billed kWh already reflect the operating period; do not apply another generic downtime deduction.
Keep the initial deployment outlay separate when evaluating capital recovery. Depreciation belongs in an accounting-profit calculation, not as another cash payment in the operating calculation above. None of these daily figures should be treated as a stable annual or long-term rate given Kaspa's scheduled subsidy reductions and KAS price volatility.
Check observed performance
Once the KS7 is mining, replace the estimate with observed data collected over a matched period, drawn from three distinct sources:
- Device dashboard: local hashrate, temperature, and fan status reported directly by the miner.
- Power meter or host invoice: actual kWh consumed and the billing basis used by the host.
- Pool dashboard: effective hashrate, accepted and rejected shares, and KAS credited to the account.
On ViaBTC's KAS pool, the configuration guide specifies the Stratum endpoints and worker-naming convention. It says miners can check operation status and earnings on the Workers and Earnings pages after the miner has stabilized for around 10–15 minutes. Because pool-reported effective hashrate is a rolling estimate, it can lag a local instantaneous reading; a single short dashboard check is not a reliable basis for judging a 30 TH/s miner's actual output, and a multi-day comparison against uptime and power data gives a more representative picture.
As checked on October 14, 2026, ViaBTC's KAS support documentation lists PPS+ and PPLNS as supported payout methods. The two allocate pool rewards differently and carry different fee and variance characteristics, so neither should be assumed to produce a permanently higher return without checking the pool's current fee schedule. ViaBTC's KAS PPS+ announcement links to fee information. The KAS mining guide also describes withdrawal options, including a zero-fee automatic withdrawal processed daily and a normal transfer available at other times for a fee; confirm current terms on the official page before relying on them.
Compare the Workers and Earnings pages against the local device log and electricity bill using the same dates, time zone, and billing boundaries. Net KAS credited and actual operating charges support the operating-result calculation; the delivered and commissioned cost remains a separate input for evaluating investment recovery.
FAQ
Is the ICERIVER KS7's listed price the full cost of ownership?
No. The listed equipment price is only one component. Shipping, applicable tax, customs duty, brokerage, and any required electrical or hosting setup should be checked in a written quote. Ongoing electricity or hosting and other operating costs also contribute to ownership cost.
Does 30 TH/s mean the KS7 will mine at that hashrate continuously?
30 TH/s is the manufacturer's rated specification. Actual device hashrate reported on the dashboard, and the pool's effective hashrate, can differ from this rating and should be monitored over a multi-day period rather than assumed.
Will a KS7 earn 157.89 KAS every day?
No. That figure is an illustrative subsidy-only estimate using the assumed network hashrate and block subsidy listed above. Actual output depends on network conditions, device performance, uptime, and pool settlement. Use dated network inputs for planning and net credited KAS to assess observed results.
Can I calculate J/TH from pool-reported hashrate alone?
No. J/TH requires a measured power reading paired with a hashrate average covering the same period. Pool-side effective hashrate estimates and power measurements are collected independently and should not be combined without confirming both figures cover the same operating window. Clearly identify whether the denominator is device-reported or pool-estimated hashrate.