Rewards Controller

The controller's core function is to execute distribution rules defined by governance or admins. This logic determines:

• Eligibility: Which assets (e.g., specific LP tokens) or actions (e.g., borrowing) qualify.
• Rate Calculation: How rewards are calculated (e.g., per-second emission, pro-rata based on share).
• Claim Conditions: Rules for when and how users can claim accrued rewards.

A robust controller can manage rewards for multiple staking pools or vaults simultaneously, each with its own reward token and emission schedule. For example, a single controller might handle:

• Pool A: Distribute REWARD tokens for staking ETH/USDC LP tokens.
• Pool B: Distribute GOV tokens for staking wBTC. This architecture centralizes management and reduces gas costs for protocol upgrades.

Rewards are typically accrued in real-time (per block or per second) and stored within the contract until claimed. This involves:

• Accrual Accounting: Updating a user's rewardsDebt or accruedRewards variable on every deposit/withdrawal action.
• Pull vs. Push Distribution: Most controllers use a pull model where users initiate a claim transaction, saving gas for inactive users.
• Claim Forfeiture: Some designs include penalties for unclaimed rewards after expiry.

Key emission parameters are upgradeable, often controlled by governance or a multisig. These parameters include:

• Emission Rate: The speed at which the reward pool is depleted.
• Duration: The start and end timestamps (startTimestamp, endTimestamp) for the program.
• Reward Treasury: The address holding the reward tokens for distribution. This allows protocols to dynamically adjust incentives in response to market conditions.

The controller must ensure mathematical correctness and fund safety. Critical features include:

• Overflow/Underflow Protection: Using SafeMath libraries or Solidity 0.8+.
• Reward Token Safeguards: Ensuring the contract has sufficient allowance and balance before distribution.
• Accurate Pro-Rata Distribution: Precise calculation of user shares to prevent dilution or excess claims, often using a rewardPerTokenStored global accumulator.

Advanced controllers integrate external data and automation:

• Oracle Feeds: To adjust emission rates based on Total Value Locked (TVL) or other market metrics (e.g., higher APY when TVL is low).
• Keeper Networks: For automating periodic tasks like topping up the reward treasury or ending deprecated programs, reducing administrative overhead.

Compound's reward system, often called a Flywheel, automatically compounds COMP governance tokens to users based on their market activity. Its controller:

• Tracks a reward index for each market, accruing COMP per block.
• Updates a user's supplier and borrower indices upon interaction.
• Transfers accrued COMP when a user executes a transaction (claim-on-action). This design minimizes gas costs and incentivizes protocol engagement.

Synthetix employs a Rewards Controller for its inflationary rewards system. SNX stakers (miners) earn weekly SNX and fee rewards by minting sUSD.

• The controller calculates rewards based on a user's debt ratio and staking percentage.
• It manages claims from the Fee Pool and the inflationary supply.
• Early versions inspired the reusable StakingRewards.sol contract, a foundational model for liquidity mining.

While Uniswap core contracts do not have a native controller, its Uniswap V3 Staker contract is a canonical example of an external rewards controller. It:

• Allows third parties (e.g., DAOs, projects) to create incentive programs for specific liquidity positions (NFTs).
• Distributes reward tokens to LPs who stake their NFTs for a defined period.
• Uses a reward calculation based on liquidity-seconds to ensure fair, pro-rata distribution.

Protocols like Pendle build entire systems around a yield-tokenizing Rewards Controller. It:

• Separates yield-bearing assets into principal tokens (PT) and yield tokens (YT).
• The controller automatically collects underlying protocol rewards (e.g., COMP, STETH rewards).
• Distributes them to YT holders, enabling the trading of future yield streams. This represents an advanced, financialized application of reward distribution logic.

The controller's primary function is to execute the distribution logic for rewards. This includes:

• Calculating user entitlements based on staked assets or activity.
• Tracking emission schedules and reward rates.
• Handling reward claims and vesting periods.
• Updating user reward balances in a secure, non-custodial manner.

A Rewards Controller is typically a separate, upgradeable contract that interfaces with core protocol contracts like staking vaults, liquidity pools, or governance modules. This separation of concerns allows for:

• Modular design where reward logic can be updated independently.
• Gas efficiency by isolating complex calculations.
• Security by limiting the attack surface of main contracts.

Controllers implement various incentive models:

• Liquidity Mining (LM): Rewards for providing assets to Automated Market Makers (AMXs) like Uniswap or Curve.
• Staking Rewards: Incentives for locking governance tokens in a protocol's vault.
• Vote-Escrowed (ve) Models: Used by protocols like Curve and Balancer, where rewards are weighted by lock duration and token amount.
• Quest & Engagement Rewards: Distributing points or tokens for completing specific on-chain actions.

Sophisticated controllers include features for precise and fair distribution:

• Merklized Distributions: Using Merkle trees (like MerkleDrop) for efficient, gas-less claim proofs of historical rewards.
• Multi-Asset Support: Distributing multiple reward tokens from a single controller.
• Dynamic Emissions: Adjusting reward rates based on Total Value Locked (TVL) or other metrics.
• Access Control: Role-based permissions for admin functions like pausing emissions or adding new reward tokens.

Aave's ecosystem uses a Rewards Controller to manage incentives for Safety Module stakers. Users stake AAVE tokens to backstop protocol shortfall events and earn stkAAVE rewards and Aave Ecosystem Reserve tokens. The controller:

• Manages the emission per second (EPS) rate.
• Calculates user rewards based on their share of the staking pool.
• Allows users to claim rewards or cooldown for unstaking.

As a central point for value distribution, Rewards Controllers are critical attack vectors. Key security considerations include:

• Accurate Math: Precision in reward calculations to prevent inflation or loss of funds.
• Reentrancy Guards: Protecting state during reward claims.
• Upgrade Safeguards: Ensuring upgradeability does not compromise user funds.
• Timelocks & Multisigs: For administrative control over parameters. Major protocols undergo extensive audits before deploying these contracts.

Clearly defining and enforcing who can do what is fundamental. The controller must have robust role-based access control (RBAC). Key permissions to secure include:

• Adding/removing reward tokens or staking pools.
• Starting/stopping reward emission for a pool.
• Changing reward rates or distribution schedules.
• Claiming rewards on behalf of users (should be restricted). Failure here can lead to unauthorized fund allocation or denial-of-service for legitimate users.

Reward claiming and staking actions are vulnerable to Maximal Extractable Value (MEV) strategies. Specific risks:

• Claim Sniping: Bots monitor the mempool for large reward claims and front-run the transaction to steal the rewards if the claim function is poorly designed.
• Stake Timing: Manipulating stake/unstake timing around reward distribution snapshots to maximize gain at others' expense. Mitigations include using commit-reveal schemes for claims or designing snapshot mechanisms that are not predictable or gameable in a single block.

The reward schedule must be designed to avoid perverse economic incentives that threaten protocol stability. This is a security consideration at the mechanism design level.

• Reward Token Inflation: Excessive emissions can crash the token price, making rewards worthless and undermining the system.
• Ponzi-like Dynamics: If rewards are funded primarily by new deposits, the system becomes unsustainable.
• Liquidity Mining Dumps: Incentives that encourage immediate selling of reward tokens can create constant sell pressure. Secure design involves sustainable emission schedules and vesting mechanisms.