Rewards and epochs

Core uses InstantRewards. ID20 gauges use the same model via RewardsBook. There is no streaming reward contract in this deployment.

Epochs

An epoch is block.timestamp / 1 weeks. Units minted in epoch E stay inactive through E and become eligible at the boundary into E+1. Time passing does not drip rewards. A notification immediately increases a Q128 index over currently active units.

Mezo Earn inventory growth

Anyone may call Ledger.claimRebases(trancheId, tokenIds). The deprecated claimRebases(uint256[] trancheIds) is a no-op.

1. The manager claims the Mezo RewardsDistributor if claimable. The distributor address is pinned on first claim.
2. The Vault measures inventory growth on listed custodied ids (locked amount, or weights plus LockedManagedReward earned for managed children). Only positive deltas mint.
3. The Ledger mints that growth as ERC-1155 units to the tranche RewardSink.
4. The sink syncRewardFunding reads the active Ledger fee config, transfers the protocol fee, then notifies the net amount.

Holders claim with RewardSink.claimRewards. ID20 wrappers harvest with claimRewardsAndCall(abi.encode(gauge)).

Protocol fee collection

Fees are collected from newly detected RewardSink funding, not from a holder's claim transaction. The fee is paid in the same ERC-1155 tranche units that were minted or transferred into the sink; it is not paid in BTC, MEZO, MUSD, or another ERC-20. The sink computes feeAmount = grossAmount * feeBps / 10_000, rounded down, transfers that amount from the sink to the configured collector, then notifies only the remaining net amount to reward accounting.

Rebase inventory growth is the normal source of gross funding. A direct ERC-1155 tranche transfer into a RewardSink can also become gross funding when syncRewardFunding runs, because the sink accounts for any balance above its stored reward reserve. If the active fee is zero or the rounded fee amount is zero, no fee transfer is made.

Fee config lifecycle

This documentation does not assume the current deployed fee setting. To check live state, open the Ledger on the Mezo explorer Contract tab and read feeConfig() for the active fee plus nextFeeConfig() for any pending update.

1. The active config returned by feeConfig() is what each RewardSink uses the next time syncRewardFunding charges fees.
2. The Ledger owner proposes a new config with proposeFeeConfig(feeBps, recipient).feeBps cannot exceed 10_000, and a non-zero fee requires a non-zero recipient.
3. A proposal must be submitted before the final 48 hours of the current weekly epoch. A valid proposal becomes pending for currentEpoch() + 1 and is visible through nextFeeConfig().
4. Once the chain reaches the effective epoch, anyone may call executeFeeConfig(). Execution copies the pending values into the active config and clears the pending config.
5. Until executeFeeConfig() succeeds, RewardSinks keep using the previously active config.

ID20 gauge

AuroveId20.rewardSink() returns the Id20Gauge, not the core RewardSink. auroveRewardSink() is the upstream core sink. Permissionless AuroveId20.claimRewards() harvests upstream units into the gauge.

Id20Gauge.activate() is a permanent opt-in. Existing untracked balance becomes settled for the next epoch. Activated holders claim with claim(receiver), paid in the same ID20. Transfers involving non-activated accounts use credit/debt; credit-classified balance cannot be unwrapped until settleCredit.

Four different payouts

Free managed rewards claimed with Vault.claimFreeManagedRewards split 1% to the caller and 99% to the VeNftManager. They are not distributed to fraction holders. Maintainer claimBribes / claimFees also land on the manager.