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
When a validator is onboarded to shMonad:
- A coinbase contract is deployed specifically for that validator
- The validator updates their beneficiary address in
node.tomlto point to this coinbase contract - The config change is applied on the fly — no restart needed:
monad-debug-node --control-panel-ipc-path /home/monad/monad-bft/controlpanel.sock reload-config
Once configured:
- Priority fees are sent directly to the coinbase contract
- MEV rewards flow through the Auction Handler first (10% is retained - of which 7.5% boosts shMON yield and 2.5% goes to FastLane), then the remaining 90% is sent to the validator's coinbase contract
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% (
0to5e16) - Adjust based on stake allocation targets and competitive position
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 reduce the validator's commission.
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. This fee funds the shMonad protocol - most of it goes back to shMON stakers as boosted yield (see Boost Commission Rate below).
Boost Commission Rate
The BOOST_COMMISSION_RATE determines how the protocol fee (above) is split. Currently set to 25%, meaning:
- 75% of the protocol fee (7.5% of total MEV) → boosts shMON staker yield
- 25% of the protocol fee (2.5% of total MEV) → FastLane Labs revenue
This split ensures the majority of the protocol fee goes back to shMON holders as enhanced APR, while sustaining FastLane's operations.
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 (7.5% boosts shMON yield, 2.5% to FastLane) |
| Staking Rewards | Distributed by shMonad to stakers | 5% of net (see Parameters & Fees) |
The 10% MEV auction fee is split: 75% goes to shMON stakers as boosted yield and 25% goes to FastLane Labs as revenue. Neither fee reduces the validator's commission.
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
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.
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 |
getCommissionRecipient() | Returns the current commission recipient address |
AUTH_ADDRESS() | Returns the validator's auth address |
Contract Interface
interface ICoinbase {
// 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 getCommissionRecipient() external view returns (address);
function AUTH_ADDRESS() external view returns (address);
// Immutable values
function VAL_ID() external view returns (uint64);
function SHMONAD() external view returns (address);
}