Coinbase Contract

The coinbase contract is the core mechanism through which validator earnings are collected, split, and distributed in shMonad.

What is the Coinbase Contract

In blockchain terminology, the coinbase is the address that receives transaction fees from blocks produced by a validator. By default, this is a regular externally-owned address (EOA) - it simply collects fees with no additional logic.

shMonad replaces this with a smart contract as the coinbase address. Using a smart contract enables:

• Automatic distribution of priority fees and MEV rewards each epoch - no manual claiming
• Automatic compounding of staking rewards and MEV revenue back into the protocol
• Configurable commission splits between the validator's wallet, shMON staker yield, and optional donations
• On-chain transparency - all distribution logic is verifiable and deterministic
• Timelocked upgradeability - new and migrated v1.2 coinbase contracts are beacon proxies, and beacon implementation upgrades go through the protocol's code-upgrade timelock

When a validator is onboarded to shMonad:

1. A deterministic coinbase contract is deployed specifically for that validator
2. The validator updates their beneficiary address in node.toml to point to this coinbase contract
3. The config change is applied by restarting monad-bft

Once configured:

• Priority fees are sent directly to the coinbase contract
• MEV rewards flow through the Auction Handler first (10% is retained - of which 5% boosts shMON yield and 5% goes to FastLane on mainnet), then the remaining 90% is sent to the validator's coinbase contract

v1.2 Upgradeability

v1.2 introduces deterministic beacon proxies for new and migrated validator coinbase contracts. Existing legacy coinbase contracts remain in use until each validator is migrated. Validators should use their currently registered coinbase address and coordinate any beneficiary change with the migration process. Validators still configure commission rates, donation rate, commission recipient, and auth address through their coinbase contract.

The upgradeability model changes who can update code:

• Validator auth addresses can update validator-local settings.
• The FastLane operations Safe can migrate validator coinbase mappings and process residual legacy balances.
• Coinbase implementation upgrades go through the ShMonad code-upgrade authority, a 3-day timelock on mainnet.

This means routine validator configuration remains fast, while code changes are delayed and publicly visible before execution.

tip

MEV rewards will be higher if the validator runs the MEV Sidecar (see Onboarding), but rewards can still be received without it if a successful searcher call to the auction handler ends up in one of the validator's blocks.

Validator-Configured Parameters

The validator's coinbase contract has four configurable parameters. All rates use a scale of 1e18 (so 100% = 1e18, 10% = 1e17, 5% = 5e16).

Parameter	What It Does	Typical Range
Priority Fee Commission	% of priority fees kept as the validator's commission	5-20%
MEV Commission	% of MEV rewards kept as the validator's commission	5-20%
Donation Rate	% of priority fees donated to boost shMON APR	0-10%
Commission Recipient	Wallet address receiving the validator's commission	The validator's wallet

Priority Fee Commission

The percentage of priority fee revenue that goes directly to the validator's wallet as commission. By default, this is set to match the validator's staking commission rate (the rate configured in the Monad staking precompile). It can be overridden independently if the validator wants a different commission rate for priority fees than for staking rewards.

MEV Commission

The percentage of MEV rewards (after the 10% auction handler fee) that goes directly to the validator's wallet as commission. Like the priority fee commission, this defaults to the validator's staking commission rate but can be set independently.

Commission Recipient

The wallet address that receives commission payments. By default, this is the validator's auth address. It can be changed to any address - for example, a separate operations wallet or a multisig.

Donation Rate

The donation rate is an optional mechanism where the validator contributes a percentage of priority fee revenue to boost shMON's APR. In return, the Stake Allocation Mechanism directs more stake to that validator.

Think of it as a competitive lever: higher donation → higher APR for shMON holders → more stake allocated to the validator → more total revenue (despite the donation).

Example - 100 MON in priority fees, 10% commission, 5% donation:

Split	Amount	Where It Goes
Validator commission	10 MON	The validator's wallet
Donation	5 MON	Boosts shMON APR (earns the validator more stake)
Staker share	85 MON	Distributed to shMON holders

Key points:

• Donation rate applies to priority fees only (not MEV rewards - those were already counted as revenue when first received by shMonad)
• Donation rate does not reduce the validator's MEV commission

Recommended starting values:

• Commission: 10% (1e17)
• Donation: 0-5% (0 to 5e16)
• Adjust based on stake allocation targets and competitive position

tip

Validators can view current donation rates and stake allocation weights on-chain to see what other validators are setting.

FastLane-Configured Parameters

These parameters are set by FastLane at the protocol level. They are not configurable by validators and do not change the validator's configured commission rates.

Protocol Fee Rate

The PROTOCOL_FEE_RATE is the percentage of MEV revenue retained by the Auction Handler before the remainder is forwarded to the validator's coinbase contract. Currently set to 10%.

When a searcher's MEV bundle is executed through the auction handler, 10% of the payment is retained and 90% is sent to the validator's coinbase contract as MEV revenue. The retained fee is split between shMON staker yield and FastLane (see Boost Commission Rate below).

Boost Commission Rate

The boost commission rate determines how the protocol fee (above) is split. Currently set to 50% on mainnet, meaning:

• 50% of the protocol fee (5% of total MEV) → boosts shMON staker yield
• 50% of the protocol fee (5% of total MEV) → FastLane Labs revenue

This mainnet split shares the protocol fee equally between shMON yield and FastLane's operations. Check Parameters and Fees for the latest documented values.

Staking Commission Rate

The STAKING_COMMISSION_RATE is FastLane's commission on the staking rewards that accrue to shMonad. Currently set to 5% of net staking rewards (after the validator's own staking commission has already been applied at the precompile level).

This is a protocol-level fee charged by FastLane on shMonad's staking yield - it does not change or affect the validator's own staking commission in any way. The validator's staking commission rate (configured in the Monad staking precompile) is applied first and remains entirely under the validator's control.

See Parameters & Fees for the full fee schedule.

How Your Earnings Work

The coinbase contract automatically distributes funds each epoch (~4-5.5 hours):

In summary:

Revenue Type	Path	FastLane Fee
Priority Fees	Directly to the validator's coinbase contract	None
MEV Rewards	Auction Handler takes 10% → 90% to the validator's coinbase contract	10% total on mainnet (5% boosts shMON yield, 5% to FastLane)
Staking Rewards	Distributed by shMonad to stakers	5% of net (see Parameters & Fees)

note

On mainnet, the 10% MEV auction fee is split equally between shMON stakers as boosted yield and FastLane Labs as revenue. The validator's configured commission rate still applies to the remaining MEV sent to the coinbase contract.

From the coinbase contract, funds are split according to the validator's configured rates:

• Validator Commission → sent to the validator's wallet
• Donation (optional) → boosts shMON APR (earns the validator more stake via the Stake Allocation Mechanism)
• Remainder → distributed to shMON stakers

note

No manual claiming needed. Rewards are distributed automatically at each epoch rollover. After updating the beneficiary address, the first rewards will appear at the next epoch change (~4-5.5 hours).

Access Control

All configuration changes to the coinbase contract are restricted to the validator's auth address - the same address registered as the validator's authentication key in the Monad staking precompile.

Action	Who Can Call
Update commission rates	Auth address only
Update donation rate	Auth address only
Change commission recipient	Auth address only
Update auth address	Previous or new auth address

If the validator's auth address changes in the staking precompile (e.g., due to a key rotation), call updateAuthAddress() on the coinbase contract to sync it. Either the old or new auth address can make this call.

tip

The current auth address can be verified at any time by calling AUTH_ADDRESS() on the coinbase contract.

Configuration Options

The coinbase contract provides the following functions for managing configuration.

Default Values

Parameter	Default Value
Priority Fee Commission Rate	Same as staking commission rate
MEV Commission Rate	Same as staking commission rate
Donation Rate	0
Commission Recipient	Auth address

Update Functions

All rate parameters use a scale of 1e18 (so 10% would be 1e17).

Function	Description
updatePriorityCommissionRate(uint256)	Update the commission rate for priority fees
updateMEVCommissionRate(uint256)	Update the commission rate for MEV rewards
updateShMonadDonationRate(uint256)	Update the donation rate for priority fees
updateCommissionRecipient(address)	Change where commissions are sent
updateCommissionRateFromStakingConfig()	Reset both priority fee and MEV commission rates to match the staking commission rate
updateAuthAddress()	Update auth address when it changes in the staking precompile

View Functions

Function	Description
getPriorityCommissionRate()	Returns the current priority fee commission rate
getMEVCommissionRate()	Returns the current MEV commission rate
getShMonadDonationRate()	Returns the current priority-fee donation rate
getCommissionRecipient()	Returns the current commission recipient address
getUnpaidBalances()	Returns unpaid commission and rewards if a prior payout could not be completed
AUTH_ADDRESS()	Returns the validator's auth address

Contract Interface

interface ICoinbase {
    // Init / migration
    function initialize(uint64 validatorId, address legacyCoinbase) external returns (bool legacyConfigMigrated);

    // Core functions
    function process() external returns (bool success);
    function handleMEVPayable() external payable;

    // Update functions (only callable by auth address)
    function updatePriorityCommissionRate(uint256 newCommissionRate) external;
    function updateMEVCommissionRate(uint256 newCommissionRate) external;
    function updateShMonadDonationRate(uint256 newDonationRate) external;
    function updateCommissionRecipient(address newRecipient) external;
    function updateCommissionRateFromStakingConfig() external;

    // Auth address update (callable by previous or new auth address)
    function updateAuthAddress() external;

    // View functions
    function getPriorityCommissionRate() external view returns (uint256);
    function getMEVCommissionRate() external view returns (uint256);
    function getShMonadDonationRate() external view returns (uint256);
    function getCommissionRecipient() external view returns (address);
    function getUnpaidBalances() external view returns (uint256 commission, uint256 rewards);
    function AUTH_ADDRESS() external view returns (address);

    // Immutable values
    function VAL_ID() external view returns (uint64);
    function SHMONAD() external view returns (address);
    function SELF() external view returns (address);
}