← All proposals

LP-144: Fee Attribution and Rewards for PQ-Native Lux

Abstract

PQ-native Lux has many kinds of work: committee signing, epoch aggregation,

era ZK proof generation, track-chain validation, FHE compute, oracle data

provision, bridge signing. This LP specifies how fees, rewards, and MEV

are attributed to the specific work that earned them and distributed

proportionally to stake within each work class.

Key principle: **every fee is tied to a cryptographically provable

work unit.** No hand-waved rewards, no epoch-level lottery. If you

didn't sign the cert, verify the proof, or relay the message, you

don't get paid for it.

Work classes

Validators opt in to one or more of these:

Each class has its own requirements (stake, hardware, liveness) and its

own reward pool.

Fee sources

Reward split

Primary network block (per block on C-Chain)

Total reward pool = F2 (priority fees in block) + F3 (block subsidy).

Primary network chain splits

When a transaction crosses primary network chains (e.g., a C-Chain contract

calls a precompile that reads X-Chain state), the F2 fee is split:

fee_to_C = base_execution_cost / total_execution_cost · F2
fee_to_X = x_chain_read_cost / total_execution_cost · F2
fee_to_Q = 0 (Q-Chain finality is paid from F3 subsidy, not per-tx)
fee_to_Z = zk_verify_cost / total_execution_cost · F2

Each chain's share goes into that chain's block reward pool for its signing committee.

Track-chain fees

Track-chain validators set their own fee schedule (published in track-chain

genesis). When a cross-chain transaction touches a track-chain:

R-Chain relay: flat 0.001 LUX per message, split 100% among R-Chain committee
B-Chain bridge: 5 bps on bridged amount, split:
  70% to B-Chain committee (signers)
  20% to B-Chain liquidity providers
  10% to Q-Chain for finality stamping
O-Chain oracle: per-feed subscription fee, 100% to data providers
M-Chain signing: per-session fee, 100% to session participants (MPC ceremonies for external-wallet bridge custody, per LP-134)
K-Chain keygen: per-DKG fee, 100% to DKG participants

Track-chains operate as independent economic zones. Fees collected on one

track-chain stay in that track-chain's economy (plus a small primary-network

tax for finality, detailed below).

Primary-network finality tax

Every track-chain pays a small fee to the primary network for Q-Chain

finality stamping:

tax_rate = 5 bps of track-chain fee revenue
tax = collected each epoch, paid to primary network block reward pool

This compensates the primary validators for securing the full PQ finality

chain that track-chains anchor against.

Service fees (F4)

Specific services have dedicated fee schedules:

Stake-weighted splits within classes

Within C2 (committee signers), each validator's share of the signer reward

is proportional to their stake within the committee:

v_share = v.stake / sum(committee.stakes)

This is standard stake-weighted reward distribution.

Slashing

Reward and slashing are symmetric — the same cryptographic evidence that

earns a reward can also prove misbehavior:

Slashed stake goes to:

• 50% burn
• 30% to the block producer that included the challenge
• 20% to P-Chain treasury

Opt-in mechanism

Validators declare opt-in classes in their P-Chain registration record:

ValidatorRegistration {
  NodeID            ids.NodeID
  StakeAmount       uint64
  BondCommitments   map[Class]uint64   // stake bonded per class
  HardwareClaims    []HardwareClaim    // GPU, TEE, storage
  Endpoints         []Endpoint         // where each service can be reached
  MLDSAPubKey       [ML-DSA-65-pk]
  MLKEMTransportKey [ML-KEM-768-pk]
  VRFKey            []byte
}

Opt-in is per-class. A validator running a GPU can opt into C4 (era

archiver) while skipping C5 (track-chain). A light validator might

only do C2 (committee signing) and skip everything else.

Each class has its own minimum stake and hardware requirements:

Incentive alignment

The reward structure encourages:

1. Specialization — high-stake validators with specialized hardware

(GPU, TEE) opt into C4, C6, C7 and capture premium fees.

2. Participation — low-stake validators can still participate via

C2 signing on primary network.

3. Liveness — missed-slot slashing penalizes unreliability.

4. Honesty — cryptographic evidence for rewards means no "free

riders": you must actually do the work to prove you did.

5. Diversity — different classes have different hardware requirements,

naturally distributing roles across the validator population.

Cadence and payouts

Rewards settle on a cadence matching the work:

Example: 100-validator primary network, k=32 committee, 1s blocks

• Block subsidy: 10 LUX / block
• Avg priority fees: 2 LUX / block
• Pool per block: 12 LUX

Per-block splits:

• Proposer (1 validator): 4.2 LUX
• Committee signers (32 validators): 4.2 LUX / 32 = 0.13 LUX each
• Epoch aggregator (escrow): 1.2 LUX
• Era archiver (escrow): 0.6 LUX
• P-Chain treasury: 1.8 LUX

Over 128 blocks (one epoch, about 2 minutes):

• Epoch aggregator receives: 128 × 1.2 = 154 LUX
• Era archiver accumulates: 128 × 0.6 = 77 LUX (toward the 168-epoch total of ~13K LUX)

Over 168 epochs (one era, ~6 hours):

• Era archiver receives: 168 × 154 ≈ 26K LUX

Proposer + signer work at 100-validator scale pays ~2 LUX/validator/hour

assuming uniform participation.

Open questions

• Service fee discovery: how do clients find cheapest C6 provider?

Probably an on-chain registry + off-chain marketplace.

• GPU-class reward premium: should C4/C7 premium be fixed ratio or

market-discovered? Lean toward market-discovered via auction at era boundary.

• Light-client incentive: how do we pay for light-client-oriented

ZK proof generation if no user directly pays for it? Probably roll into

C4 era archiver reward.

• MEV: priority fee mechanism captures most MEV. Explicit MEV auction

(Flashbots-style) can be added per track-chain.

References

• LP-020 Quasar Consensus
• LP-030 Platform VM (staking primitives)
• LP-142 Hierarchical Quorum Certificates (defines C1-C2 work)
• LP-141 Threshold VM (defines C6 threshold signing)
• ~/work/lux/proofs/pq-finality-no-bls.tex
• ~/work/lux/consensus/METASTABLE_SIGNED_QUERIES.md