Skip to main content
Every Kronex block pays three kinds of recipient:
  1. the sealer that found the kHeavyHash solution,
  2. uncles, at a reduced rate,
  3. the workshares included in that block.
On top of their block reward, the sealer and the uncles share the block’s priority fees, in proportion to their block rewards. Workshares are paid their own reward only; including them costs the sealer nothing in fees. krnx_getBlockReward returns the whole breakdown for one block: per-recipient amounts, group totals, and the fee split layered on top.

​
The reward curve

Rewards are not a flat subsidy. Two curves are in play, both configured by the same governance-controlled parameter set:
  • Block reward interpolates between rMin and rMax as block difficulty moves from difficultyFloor to difficultyCap.
  • Workshare reward interpolates between a per-parent-chain rMin and rMax as the hashes represented by the share move from floorHashes to capHashes.
Both use a logarithmic weight, curveLogWeightBps, so the curve can be tuned between linear and strongly log-shaped without changing its endpoints. Because the workshare curve is per parent chain, SHA256d and Equihash work can be priced differently while both remain accepted. A workshare mined on an old template is discounted rather than rejected. The age is measured from the moment the template was signed to the share’s parent header time: up to 8 seconds the reward is paid in full; from there it falls linearly to stalePenaltyNumerator / stalePenaltyDivisor of the reward at 23 seconds (32 seconds for Bitcoin Cash, whose blocks are slower). Read the parameters in force at any height with krnx_getRewardParams.

​
Lockups

Rewards do not land as spendable balance. They are locked, and the unlock is time-based:
That is 14 days on mainnet and 5 minutes on testnet. Per-address aggregates come from krnx_getLockedBalance; the indexed schedule of individual future unlocks comes from krnx_getRewardSchedule. Locked coins are why there are two supply figures: Both need the state at the requested block, so historical queries want an archive node.

​
Changing the parameters

Reward parameters are versioned and updated through a signed governance transaction, not a hard fork. Each update carries a version, an activation height and a signature set, and only takes effect at the height it names. An accepted update is part of the chain state from the block that carries it, and is pending until its activation height; only one update can be pending at a time. Read the parameters in force at any height with krnx_getRewardParams.