Gas Fee Distribution & Proposer Rewards

Source: src/core/execution/mod.rs (fee accounting), src/core/execution/types.rs

Overview

Gas fees are split using an EIP-1559-style model:

• Base fee is burned (removed from supply).
• Priority fee goes to the block proposer.

This keeps fee pricing predictable while still rewarding validators for block production.

Definitions

• gas_used: total VM gas consumed by the transaction
• base_fee: per-gas base fee (from the block header)
• max_fee: user-specified maximum fee in the transaction
• total_fee_paid: actual fee charged

Fee Flow

VM Transactions

For VM calls, the engine charges gas as execution proceeds and refunds any unused gas to the payer:

fee_cap = max_fee
consumed = gas_used
refund = fee_cap - gas_used

Simple Transfers

For non-VM transfers, the full fee cap is charged:

consumed = fee_cap
refund = 0

Split Between Burn and Proposer

burned_fees   = min(base_fee * gas_used, total_fee_paid)
proposer_fees = total_fee_paid - burned_fees

• burned_fees are not credited to any account.
• proposer_fees are credited to the block proposer’s fee recipient address.

Proposer Recipient

The proposer recipient is derived from the consensus leader for the block. If no proposer is available, no proposer fees are credited.

Fee Breakdown in Receipts

Clients receive an explicit fee breakdown:

• gas_limit, gas_used
• effective_gas_price (v1 uses 1:1 unit pricing)
• max_fee, priority_tip
• total_fee_paid
• base_fee_per_gas, burned_fees, proposer_fees

Notes

• Fee accounting is asset-aware: refunds and credits use the same fee asset as the transaction’s FeeIntent.
• Simulations do not distribute proposer fees.

Related Docs

• docs/design/vault-gas-token.md (future gas token model)
• docs-site/src/content/docs/concepts/gas-and-fees.md