Reward Manager

Overview

The Reward Manager precompile controls where the transaction fees of your L1 go. It has three fee routes, and only one route is active at a time (Figure 1):

• Send all fees to one reward address, for example a treasury.
• Let each validator collect the fees of the blocks that it builds.
• Burn all fees.

Configuration

Activate the precompile in your genesis file. Set one fee route in initialRewardConfig:

{
  "config": {
    "rewardManagerConfig": {
      "blockTimestamp": 0,
      "adminAddresses": ["0x8db97C7cEcE249c2b98bDC0226Cc4C2A57BF52FC"],
      "initialRewardConfig": {
        "allowFeeRecipients": true // validators collect the fees
        // Or: "rewardAddress": "0x..." to send the fees to one address.
        // Or: an empty object {} to burn the fees.
      }
    }
  }
}

Do not set allowFeeRecipients to true and a rewardAddress together. The chain rejects that config.

Fee routes

The Reward Manager has three fee routes. They are mutually exclusive.

1. Validator fee recipients (allowFeeRecipients)

   • Each validator sets a fee recipient in the chain config of its node (feeRecipient).
   • The fees of a block go to the fee recipient of the validator that built the block.
   • Use this route to pay validators for their work.

2. Reward address (rewardAddress)

   • All fees go to one address on the L1.
   • The address can be a contract or an externally owned account.
   • Use this route for a treasury or a DAO.

3. Burn (the default, or disableRewards)

   • All fees go to the blackhole address.
   • The total token supply falls over time.

Interface

interface IRewardManager {
  event RewardAddressChanged(
    address indexed sender,
    address indexed oldRewardAddress,
    address indexed newRewardAddress
  );
  event FeeRecipientsAllowed(address indexed sender);
  event RewardsDisabled(address indexed sender);

  function setRewardAddress(address addr) external;
  function allowFeeRecipients() external;
  function disableRewards() external;
  function currentRewardAddress() external view returns (address rewardAddress);
  function areFeeRecipientsAllowed() external view returns (bool isAllowed);
}

The Reward Manager precompile uses the AllowList interface to restrict access to its functionality.

Best Practices

1. Reward Management:

   • Choose reward mechanism based on network goals
   • Consider using a multi-sig or DAO as reward address
   • Monitor fee collection and distribution
   • Keep documentation of fee policy changes

2. Security Considerations:

   • Use multi-sig for admin addresses
   • Test reward changes on testnet first
   • Monitor events for unauthorized changes
   • Have a plan for reward parameter adjustments

Implementation

You can find the Reward Manager implementation in the subnet-evm repository.

Interacting with the Precompile

For information on how to interact with this precompile, see:

• Interacting with Precompiles
• Reward Manager Console