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)).

LMR settlement

A managed veNFT has a LockedManagedReward (LMR) contract. Claiming its distributor rebase sends MEZO into that LMR. The LMR assigns the funding to the epoch in which it receives it, even when the rebase was earned in an earlier epoch. Funding is not yet a claimable child-NFT reward or an Aurove RewardSink payout.

Mezo epochs begin Thursday at 00:00 UTC. If a rebase earned in epoch n is claimed into LMR during n+1, the usual sequence is:

This is not a fixed two-week waiting period. LMR waits for its funding epoch to close; a later distributor claim moves that boundary later. Allocations use each child's final deposited balance divided by the final LMR supply, not time-weighted participation. Aurove still needs to account for eligible inventory growth before holders can claim it.

Deposit in n, redeem in n+1

LMR tracks child NFTs; Aurove distributes recognized growth across eligible tranche holders. The minted units do not reserve a personal share of their original NFT's pending LMR rewards. Completed-epoch child rewards are accounted for during redemption; current-epoch funding is not yet included. Rewards already accrued to an account in RewardSink are separate and are not erased by burning its tranche units.

Example: veMEZO 2586

This mainnet example shows an early exit before LMR settlement. All dates are in 2026 and all times are UTC; displayed token amounts are rounded.

1. September 7, 15:25:16 (n): Deposit of veMEZO 2586 minted 122,008.532919 avNFT tranche units. Epoch n ran September 3-10.
2. September 10, 00:21:30 (n+1): Distributor claim for managed veNFT 2805 sent 2,786.496591 MEZO from the September 3-10 rebase period into LMR, tagged to its September 10-17 funding epoch. This was the manager's total, not 2586's share.
3. September 10, 00:21:37: Ledger claimRebases checked children 2621, 2808, and 2586. All showed zero inventory growth, so no avNFT rewards were minted to RewardSink and no reward-funding fee was collected in this call.
4. September 10, 08:19:02: Redemption of 2586 burned the same 122,008.532919 units. LMR paid zero and checkpointed the child's balance to zero. The NFT returned with unchanged principal.
5. September 17, 00:00 (n+2):the funded LMR epoch would close. Under the contract rules, 2586 would receive none of that bucket unless it re-entered before the boundary. Other children's allocations would depend on their final balances.

These transactions show funded MEZO waiting in LMR, not a payout to 2586 or proof that it captured other holders' rewards. Receiving unchanged principal did not preserve its prospective LMR entitlement.

If all children leave

If a funded epoch closes with no children deposited in the managed veNFT, every child's final balance is zero. That bucket remains in LMR with no eligible claimant and no normal recovery path in the current contracts. It does not roll forward, and a new child deposited in a later epoch cannot claim it. This concerns all children in the managed position, including any deposited outside Aurove custody.

If a child enters before the funded epoch closes, it can share that bucket; as the only remaining child, it can receive the entire bucket. Merely emptying the position briefly does not strand rewards: the balance at the epoch boundary is what matters. Returning after the boundary cannot recover the old bucket.

Contract reference: Tigris Reward and LockedManagedReward source in the verified managed-rewards factory.

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.