Rewards Distributor

The primary function is to manage the emission schedule and distribution logic for rewards. It typically holds a treasury of reward tokens and executes transfers based on on-chain data, such as:

• Staking duration and amount
• Liquidity provider (LP) share in a pool
• Completion of specific on-chain actions or quests This automation ensures transparency and trustlessness, removing manual intervention.

Common implementation patterns include:

• Staking Rewards: Linear emissions per block to stakers of a specific token.
• Liquidity Mining: Distributing tokens to users who provide liquidity to designated pools, often using a veToken model to weight rewards.
• Fee Rebates / Revenue Sharing: Distributing a portion of protocol fees back to users, often proportional to their activity or stake.
• Meritocratic Airdrops: Retroactively rewarding past users based on snapshot data, calculated off-chain but distributed on-chain.

As a central treasury manager, this contract is a high-value target. Key security aspects include:

• Access Control: Strict, often timelocked, multi-signature control over critical functions like setting new reward rates or withdrawing funds.
• Reward Math Verification: Ensuring calculations for APR and allocations are correct and cannot be manipulated to drain funds.
• Front-running Protection: Mitigating bots that could exploit timing between reward calculation and claim transactions.

A canonical example is the StakingRewards contract used by Synthetix and forked by many DeFi protocols. It:

• Accepts user stakes of an LP token.
• Distributes a fixed amount of SNX or other reward tokens per second.
• Calculates user rewards as (userShare / totalShares) * rewardsPerSecond * timeStaked.
• Allows users to claim() accrued rewards at any time. This simple, audited template has secured billions in value.

The assets distributed are typically governance tokens (e.g., UNI, COMP) or protocol-owned liquidity tokens. Their economic design is crucial:

• Inflation Schedule: Defines the total supply and emission rate over time.
• Vesting: Often applied to team or investor allocations, but can also be used for user rewards to encourage long-term alignment.
• Value Accrual: Rewards must ultimately be backed by protocol utility or cash flow to sustain long-term incentives.

For rewards based on complex or off-chain data, distributors often rely on oracles or Merkle proofs.

• Oracles: Provide external data (e.g., trading volume, social metrics) to calculate rewards on-chain.
• Merkle Distributors: A gas-efficient pattern where reward entitlements for all users are calculated off-chain, hashed into a Merkle root, and stored on-chain. Users submit a proof to claim, reducing contract computation and cost. Used extensively for airdrops.

Protocols like SushiSwap (xSUSHI) and Frax Finance (veFXS) use rewards distributors to share protocol revenue with stakers. When users stake their governance token, the distributor automatically allocates a portion of trading fees or other revenue to them. This transforms a governance token into a yield-bearing asset, aligning long-term holder incentives with protocol growth.

The veToken model, pioneered by Curve, tightly integrates rewards distribution with governance. Users lock tokens (e.g., CRV, BAL) to receive veCRV/veBAL, which grants:

• Voting power to direct emissions
• A share of protocol fees
• Often a boost on personal farming rewards

The rewards distributor is programmed to respect these lock-up durations and voting weights, rewarding long-term alignment.

Bridging and cross-chain liquidity protocols like Stargate Finance and LayerZero employ rewards distributors to incentivize liquidity across multiple blockchains. Emissions are often managed by a DAO multisig or off-chain keeper that updates reward rates on different chains, aiming to balance liquidity depth and usage across the network.

A typical rewards distributor is a separate, upgradeable smart contract that is permissionlessly called by user actions (e.g., staking, claiming) or by a keeper bot. Key functions include:

• notifyRewardAmount(): Funds the distributor with reward tokens.
• getReward(): Allows a user to claim accrued rewards.
• rewardRate(): Calculates the emission rate per second. Security is critical, as these contracts hold substantial token inventories.

Many distributors have admin keys or owner addresses with privileged functions like pausing distributions, changing reward rates, or withdrawing funds. A compromised private key or malicious insider can drain the contract.

• Single Point of Failure: Loss of the admin key can lead to total loss of funds.
• Timelock Solutions: Implementing a timelock contract for privileged actions is a critical mitigation, providing a delay for community review.

Flaws in the reward calculation or distribution logic can lead to incorrect payouts or fund lockup.

• Rounding Errors: Incorrect integer math can be exploited for rounding attacks, allowing users to claim slightly more rewards than entitled.
• Reentrancy: If the contract interacts with untrusted external contracts during distribution, it may be vulnerable to reentrancy attacks, draining funds.
• Accurate Accrual: The contract must correctly track reward per share or user stakes to prevent over- or under-distribution.

Distributors that calculate rewards based on external data (e.g., token prices, TVL) rely on oracles. Manipulating this data is a primary attack vector.

• Oracle Attack: An attacker could manipulate a DEX price feed to artificially inflate the calculated value of rewards, allowing them to claim an unfairly large share.
• Solution: Using a decentralized oracle network (like Chainlink) with multiple data sources and heartbeat updates reduces this risk significantly.

The claim() function is a frequent target. Users must often grant token approvals to the distributor.

• Infinite Approval Risk: Users granting infinite approval (type(uint256).max) risk losing all tokens if the distributor contract is compromised.
• Front-running: Malicious actors can front-run legitimate claim transactions if reward calculations are sensitive to block state.
• Recommendation: Use permit signatures (EIP-2612) for gasless, single-use approvals instead of persistent allowances.

Many distributors are built using proxy patterns (e.g., Transparent or UUPS) to allow for future upgrades. This introduces specific risks.

• Proxy Admin Control: Similar to admin key risk, control over the proxy admin can be used to upgrade to a malicious implementation.
• Storage Collisions: Improperly managed storage layouts during an upgrade can corrupt critical data.
• Implementation Freeze: A best practice is to eventually renounce upgradeability after the contract is battle-tested and stable.

The reward mechanism itself can be gamed, undermining the protocol's economic security.

• Sybil Attacks: A single entity creates many wallets (Sybils) to claim a disproportionate share of distribution meant for unique users.
• Wash Trading: Artificially inflating trading volume or liquidity provision to earn rewards without real economic activity.
• Mitigations: Implement proof-of-personhood, staking thresholds, or graduated reward curves to disincentivize these behaviors.