A valid block can earn its miner an RVN subsidy and transaction fees. Pool miners share rewards according to the pool’s payment method. These rewards are denominated in RVN, Ravencoin’s native coin; user-issued asset tokens are separate from the mining subsidy.

Ravencoin Core’s documented block-subsidy calculation starts at 5,000 RVN and halves at the interval configured for the network. The documented mainnet interval is 2,100,000 blocks. Under that schedule, the subsidy is 1,250 RVN from block height 4200000 through 6299999, before transaction fees. The original 5,000 RVN figure therefore doesn’t describe every reward period.

The network targets one-minute block intervals, but individual intervals vary. For a fixed hashrate, expected RVN output depends on difficulty and the applicable subsidy. Increasing network competition can reduce that rig’s expected output after difficulty adjusts. The RVN price changes the currency value of the rewards without changing how much work the GPU performs.

Tron Black’s August 14, 2026 report on the KAWPOW consensus bug describes forged mainnet blocks beginning at height 4487776 on August 7, 2026. It identifies v4.8.0, released on August 11, 2026, as superseding v4.6.1.1-hf1. The later release combined block-height validation and checkpoint 4487775 with an asset-transfer overflow fix that the earlier hotfix lacked.

His operator guidance specified v4.8.0 or an equivalent patched binary and directed miners toward the patched chain. These are node software releases; GPU mining programs have their own versions. Pool miners depend on the node software and chain that their pool uses.

View image file

The report also states that network explorers agreed on the recovered chain. That recovery didn’t guarantee every individual payment survived: transactions spending coinbase outputs from replaced blocks, along with dependent transactions, couldn’t be re-mined. Black also reported reversals of pool balances earned during the attack window. Those historical reversals are different from an ordinary payout delay.

Compatibility comes before a benchmark: the mining program must support KAWPOW on the GPU and driver being used. Compare KAWPOW results with other KAWPOW results. A hashrate measured on another algorithm doesn’t provide an equivalent RVN earnings estimate.

View image file

A miner’s displayed hashrate and the rate inferred from pool shares measure different things. Shares demonstrate submitted work, and a pool estimates hashrate from them over time. Rejected work and interruptions reduce the work that earns credit, so a brief peak reading is a poor basis for comparing settings.

Measure electricity at the wall for the complete setup. GPU software power readings can omit the CPU, fans and power-supply losses. Include additional cooling electricity when the mining setup causes that consumption. A lower power limit is useful when its reduction in electricity cost exceeds the value of any rewards lost through reduced effective hashrate.

Electricity cost

Whole-system power in watts divided by 1,000, multiplied by operating hours and the electricity tariff per kWh.

Reward value

Expected RVN after applicable fees, multiplied by the RVN valuation used for the comparison.

Operating surplus

Reward value minus electricity and other operating costs. Hardware purchase costs remain separate.

A positive operating surplus doesn’t establish hardware payback. Purchase cost, repairs and any conversion charges still affect the result. Holding mined RVN also leaves its eventual sale value exposed to price changes; valuing a reward today doesn’t lock in that value.

PPLNS

Pay Per Last N Shares distributes rewards from valid blocks that the pool finds according to eligible shares within its defined window. The window measures shares, so it isn’t a universal waiting period measured in hours.

PPS

Pay Per Share bases compensation on accepted shares under the provider’s terms. It reduces the miner’s direct exposure to the pool’s block-finding luck. Transaction-fee treatment and wallet payout timing depend on the particular service.

Solo mining

The miner earns a block reward when their own work finds a block that the network accepts. Long periods without a reward are possible. A hosted solo service may still charge a fee.

The fee that the pool charges and the mining program’s developer fee are separate costs. Some mining programs collect their fee by spending part of the runtime mining for the developer. An estimate that already accounts for that time shouldn’t have the same fee deducted again.

View image file

Credited work, an unpaid pool balance and a wallet payment are separate states. Block rewards can await confirmation, while an unpaid balance can await the pool’s threshold and payment schedule. Wallet synchronization affects what the wallet displays. Compare these conditions before treating a delayed payment as evidence that another pool earns more.

Does a faster mining profile leave more after power costs?

All setup values, reward estimates and market inputs in this comparison are hypothetical. Both profiles run for 24 hours under the same network difficulty, subsidy and pool terms. Their effective hashrates already account for developer-fee time and rejected work. The electricity tariff is 0.17 USD/kWh and the RVN valuation is 0.062 USD/RVN.

Assume profile A earns an expected 11.2 RVN after fees during that period. With the same reward conditions, profile B’s expected output scales with effective hashrate: 11.2 * 22.1 / 18.2 = 13.6 RVN .

Profile A’s electricity cost is 112 / 1000 * 24 * 0.17 = 0.45696 USD. Profile B’s cost is 152 / 1000 * 24 * 0.17 = 0.62016 USD. B’s additional 2.4 RVN is valued at 0.1488 USD, while its additional electricity costs 0.1632 USD.

Profile A therefore leaves 0.0144 USD more over the hypothetical 24-hour period. This comparison excludes hardware costs, repairs, external cooling and conversion charges. Its result applies only while the stated inputs hold; different reward conditions, electricity tariffs or RVN valuations can reverse the outcome.