igneum/docs/design/proving-payment.md

The proving payment: the tip-share discrepancy resolved (Igneum 2.0, D4)

8 October 2026, 17:5x UK, the research lane, under the founder's Igneum 2.0 decision (docs/plans/igneum-2.0.md, D4: "the economics page's tip-share discrepancy resolved; explicit user-funded proving payment with congestion pricing, burn treated separately; hard cap and no development tax kept"). A design decision on text and spec; the one code change it implies is pinned below and is not made here.

The discrepancy

The economics page's fee table says the priority fee (the tip) is 80 percent to the block's miner and 20 percent to the developer registrations, which is what the code on Devnet 3 does (DEVELOPER_SHARE_PERCENT = 20, the rest to the miner). Spec 5.2 says the 80 percent goes to "the block producer and provers ... in the proportion the proving protocol defines (forward reference)", spec 5.3 speaks of "the provers' part of the 80% tip share", open item O-5.7 leaves that proportion to phase 2, and the page's own "proving-fee market" paragraph says a card's second income includes "the provers' part of the priority fee". So the page contradicts itself and the spec contradicts the code: the provers are promised a share of the tip that no rule sizes and no code pays.

The decision

1. The tip stays whole to the block. The priority fee splits 80 percent to the block producer and 20 percent to the developer registrations, exactly as the code does. No part of the tip reaches the provers. O-5.7 is closed by this decision: the provers' proportion of the tip is zero.
2. The provers are paid by an explicit, user-funded proving payment with congestion pricing: the proving base fee. Every transaction already pays pgas used x f_p, where f_p is the proving base fee that spec 5.1 adjusts per chain block by the EIP-1559 step toward a target of half the proving budget (B_p / 2), never below the floor of 5.11. Today that payment is burned. From this decision it is the provers' payment: 90 percent of it is credited to the block's proving pool escrow (PROVING_POOL_ADDRESS) and paid out per shard by consensus proving cost under the rules of 5.3; 10 percent is burned. The price is the congestion price by construction: f_p rises when blocks use more than half the proving budget and falls when they use less, so a proving demand spike raises what users pay provers per unit of proving work, which is the signal that brings capacity in (the operator simulation of D4 reads it as its pricing rule).
3. The burn is treated separately and listed in one place. Burned: the execution base fee in full (anti-stuffing, unchanged), 10 percent of the proving payment, the unregistered developer share of the tip, and 10 percent of IGN-settled external jobs (5.4). Nothing else.
4. The hard cap and the absence of a development tax are untouched. No new emission, no change to the 20 percent proving-pool share of the subsidy (2.5), no address that any team controls.

Why the 10 percent burn on the proving payment: the burn of the proving base fee was the rule that made wash pgas a guaranteed loss (5.1). With 90 percent of it routed to the block's provers, a miner who is also a prover of its own block could recover part of a stuffed block's proving payment; sortition (eight eligible provers per shard, 5.3) makes that recovery a share of the pool's weight at best, and the 10 percent burn plus the execution base fee burned in full keep stuffing a loss at every weight. The 90 and 10 mirror the external job split of 5.4, so a prover's two incomes carry one rule.

The simulation's reason (lane 3's operator simulation, 16:58 UK)

In a capacity-limited world (1 percent of the cards proving at the measured 5.5 percent proving efficiency) a lasting 1,000x proving demand spike is not restored in 150 periods when the internal pool is a fixed sum (the provers go to the external fee market and the internal backlog grows without bound) and is restored in 35 periods with this congestion-priced internal proving fee (peak 2x). The fixed pool is a subsidy, not a price; internal proving needs the user-funded, congestion-priced fee, which this decision gives it (docs/analysis/class-v6/operator-simulation.md).

What a prover earns, in one line

Per block: its shards' part of 20 percent of the block subsidy (2.5, 5.3) plus its shards' part of 90 percent of the block's proving payment (pgas used x f_p); per job: 90 percent of the external job fee (5.4). Nothing from the tip.

The code pin (made by the node-side hand, 17:03 UK, behind its constant)

In the code on branch proving-payment of the fork at eaddbf83 (on release-2.0.0-node's c04674fe; the suites green on build-2): behind Params::proving_payment_activation_daa, u64::MAX on every object until main names a height, the split below applies; the receipt's field proving_payment shows the provers' part beside burned_proving. Before any height: the shard guest (proving/igneum-prove/core/src/executor.rs 290 and 318) must carry the same split behind the same switch and the object must pin the new shard program id, else no shard proof verifies past the floor. The pin as written:

igneum/exec/src/executor.rs (the proving base fee debit at 357 and 360 on Devnet 3): credit 90 percent of pgas used x f_p to PROVING_POOL_ADDRESS and debit the remaining 10 percent to no one, instead of debiting the whole to no one; the pool's per-shard payout (5.3) then carries it with no further change. Behind an activation constant on the devnet objects like proving_v1_activation_daa. The economics page's row reads "designed, in the code behind the constant; the guest's mirror owed before any height".

Where the text changes

Spec 5.1 (the proving-cost gas row and the burn sentence), 5.2 (the 80 percent recipient and the forward reference), 5.3 (the provers' income), 06 O-5.7 (closed); the economics page's "Where fees go" table (the base-fee row split into the two dimensions, a proving-payment row, the duplicated tip row removed) and its "proving-fee market" paragraph.