The fee market

Transaction mass, reused exactly from the mass calculator

This demo's three transaction shapes plug the same fixed inputs (1 input, 1 output, 1,000 KAS, no fee) into the identical formulas as demos/mass-calculator.html, so the two demos agree on every number: a plain payment costs 1,624 mass, a covenant costs 5,660, and a ZK-proof-style transaction with an 8,000-byte payload costs 16,528, bound by transient mass rather than compute mass.

tx_mass = max(compute_mass, storage_mass, transient_mass × 500,000/1,000,000) Block limit: 500,000 mass (compute and storage share it; transient's own limit is 1,000,000) capacity per block = floor(500,000 / tx_mass)

Verified against rusty-kaspa mass code and consensus params.

Block rate, k, and mergeset

Blocks per second is a consensus parameter, not a dial that only changes throughput. rusty-kaspa's bps.rs derives GHOSTDAG's k parameter and the mergeset size limit (2×k, bounded 180 to 512) from it, and a higher block rate needs a larger k for the same security margin. The code's own lookup table only defines k up to 32 blocks/second (k=362); anything above that has no coded k value at all in the current consensus code, so this demo does not offer it. This model holds the 500,000 block mass limit fixed across all three rates; it does not model whether that limit itself would need to change at a genuinely different block rate, which would need its own review.

k(1 bps) = 18 mergeset limit = 180 (floor) k(10 bps) = 124 mergeset limit = 248 k(32 bps) = 362 mergeset limit = 512 (ceiling)

Source: consensus/core/src/config/bps.rs. Higher rates than mainnet's 10 bps are a research question, not a shipped setting; KIP-2 (DAGKnight) leaves the optimal rate open rather than naming one.

How the mempool actually picks, not sorts

rusty-kaspa's mempool does not keep a strictly sorted fee queue. Its Frontier weighs each candidate transaction by feerate^alpha with alpha = 3, where feerate is fee divided by mass, in sompi per gram. When total pending mass fits in one block it takes everything (no sampling needed, matching the "every transaction fits" state below). When it doesn't, it draws a weighted random sample rather than a strict ranking, so a lower-fee transaction can get pulled in and a higher-fee one can still be waiting after the draw. Transactions are also grouped into lanes by subnetwork, and once enough lanes are represented, lane assignment freezes and selection continues within those lanes; this demo does not model lanes, only the feerate-weighted sampling itself.

This demo's own "picked vs. waiting" simulation approximates that principle (weighted-random draw, not the literal k·log(n) sampling algorithm or lane logic) using an illustrative, not measured, spread of other transactions' fees, since Kaspa's blocks carry too little real traffic today to have an observed fee distribution to draw from.

weight(tx) = feerate(tx)^3 feerate = fee_sompi / mass_grams

Source: mining/src/mempool/model/frontier.rs and mining/src/feerate/mod.rs.

Traffic scenarios

Bitcoin (7.185 tx/s) and Ethereum (17.793 tx/s) use each chain's own measured 30-day tps_sustained figure. Solana's figure (1,579.6 tx/s) is derived from its cleaned daily_transactions count of 136,477,068 (excluding the roughly 51.5% of its raw count that is validator vote traffic, per this repo's own data caveat), divided by 86,400 seconds; it is a one-day snapshot, not a 30-day mean. Kaspa's own 0.895 tx/s is likewise a cleaned, measured 30-day mean, with 89.5% of its raw transaction count excluded as one coinbase transaction per block.

Source: data/l1-chains.json.

Fees, subsidy, and the schedule

Today's $58,631/day subsidy, $4.86/day fee revenue, and the roughly 12,054× gap between them are reused exactly as computed in CLAIMS.yml's fees_vs_subsidy_2026_08_22 entry, not re-derived here. The subsidy over time uses the same halving formula as demos/emission-schedule.html: reward(n) = 23.12465141 × 2^(−n/12) KAS/second, n in months from today, verified against coinbase.rs's SUBSIDY_BY_MONTH_TABLE. The default KAS price, $0.02934513, is the same CoinGecko snapshot from 22 Aug 2026 used in that CLAIMS.yml entry.

The price slider multiplies both dollar figures (fee revenue and subsidy) by the same factor, since both are really paid in KAS and only converted to dollars for display. That keeps the ratio between them honest: price alone cannot close the gap, because it moves both sides equally. Only a higher fee or more transactions changes the ratio.

Source: api.kaspa.org/info/blockreward, this repo's CLAIMS.yml.