Files
zeekayandHanzo Dev a10a2f1e0e fee: decomplect the split RATIO from the fee DESTINATION
The fee split braided two independent concerns into one line: how much of a
fee is kept (a protocol constant, floor(fee/2)) and where the kept part goes
(compiled-in extras.FeeRewardVault = 0x0100..02). The second half made the
destination ungovernable and silently bypassed the RewardManager precompile
the moment FeeSplit activated, so turning the burn on would have DISABLED the
one on-chain knob the chain already has.

Split the concerns:

  ratio       -> stays a right shift. Fixed, auditable, not settable by any
                 transaction. Changing it remains a release plus a coordinated
                 fork, deliberately: monetary policy should not move at the
                 speed of a multisig.
  destination -> the configured coinbase, i.e. BlockChain.GetCoinbaseAt, i.e.
                 the RewardManager precompile's stored address. Already part of
                 header validity (dummy.verifyCoinbase), so it is verifiable
                 from the header and movable by one admin transaction.

creditTxFee collapses to one credit site; extras.FeeRewardVault is deleted.

Also adds the ordering gate this created a need for: ChainConfig.Verify now
refuses a config that schedules feeSplitTimestamp while rewardManagerConfig is
not enabled at that time (and allowFeeRecipients is off). Without RewardManager
GetCoinbaseAt falls back to the keyless blackhole, so such a config would burn
half of every fee and strand the other half forever -- the C-Chain already has
~3867 LUX stuck at that address. mainnet/cchain.json currently ships exactly
that shape (feeSplitTimestamp 1785715200, no rewardManagerConfig in any of the
49 precompileUpgrades); the node will now refuse to start on it instead.

This is a no-op on every live chain: mainnet 96369's running config has no
feeSplitTimestamp at all (eth_getChainConfig), the vault balance is 0, and the
branch has never executed. The correction is free today and costs a fork later.

Tests:
  core: destination follows the configured coinbase; a redirect mid-chain moves
        the whole reward stream while the burn is unchanged; supply conservation
        on executed blocks; genesis refuses the ungoverned shape.
  dummy: a proposer naming any other coinbase is rejected with ErrInvalidCoinbase,
        so crediting the header coinbase is not a validator-capture hole.
  extras: the verbatim upgrade.json fragment activating rewardManagerConfig and
        feeManagerConfig with the DAO Safe as adminAddresses parses through the
        registry, and feeManager's governable surface contains no ratio.

Co-authored-by: Hanzo Dev <[email protected]>
2026-07-27 12:34:18 -07:00
..
2025-08-01 01:23:42 +00:00