--- id: TIP-1075 title: Deprecate TIP-20 Rewards description: Disable TIP-20 rewards while preserving settled reward claims. authors: Dan Robinson (@danrobinson), @0xrusowsky status: Approved related: TIP-20, TIP-1065 protocolVersion: T7, T8 --- # TIP-1075: Deprecate TIP-20 Rewards ## Abstract This TIP deprecates TIP-20 rewards at T7, with a rollout plan extending until T8. After activation, TIP-20 tokens no longer support new reward opt-ins or new reward distributions. Existing rewards-related state remains in storage, and already-accrued rewards remain claimable indefinitely through the existing `claimRewards()` API. ## Motivation TIP-20 rewards are not currently seeing meaningful use, and the expected product demand has shifted toward vaults and wrapped yield-bearing assets rather than protocol-level holder rewards. Keeping rewards active also preserves complexity in TIP-20 transfer, mint, burn, and fee-refund paths. TIP-1065 proposed optimizing this complexity by packing reward opt-in cache state into balance slots at T6. If rewards are deprecated instead, the protocol should avoid activating that reward-specific balance-bit optimization and should remove reward update checks from ordinary TIP-20 balance-changing paths. ## Assumptions - No known production contract depends on successful reward opt-in or reward distribution behavior. - Already-accrued rewards may exist and must remain claimable. - Existing rewards storage may remain in state indefinitely. - SDK, docs, and client cleanup can happen outside this TIP. If the first assumption is wrong, deprecated opt-in and distribution calls still remain non-reverting no-ops, preserving caller compatibility at the ABI level. # Specification At T7 activation, TIP-20 rewards are deprecated. ## Deprecated Functions The following functions remain present in the TIP-20 ABI: ```solidity function distributeReward(uint256 amount) external; function setRewardRecipient(address recipient) external; function claimRewards() external returns (uint256); ``` After T7 activation: - `setRewardRecipient(address recipient)` MUST be a no-op. - `distributeReward(uint256 amount)` MUST be a no-op. - `claimRewards()` MUST continue to use the existing claim API and accounting for already-accrued rewards. The deprecated opt-in and distribution calls are non-reverting no-ops, rather than reverts, to preserve ABI-level compatibility for deployed callers that may expect these calls to succeed. No new reward opt-in, opt-out, delegation, or reward-distribution state transitions occur after T7. Checkpointing of reward accumulators on transfers continues between T7 and T8, in order to allow pre-T7 lazy rewards to be checkpointed before T8. Already-accrued rewards remain claimable indefinitely. `claimRewards()` MUST preserve the current external API and claim accounting. A successful claim transfers the caller's accrued reward balance according to the existing TIP-20 claim semantics. This TIP does not introduce a sunset period for claims. After T8 activation, TIP-20 transfers, mints, burns, fee-refunds, and other internal balance-changing paths MUST NOT update reward accumulators for affected addresses. This replaces the reward-accounting optimization proposed in TIP-1065. The reward-specific balance-bit optimization MUST NOT be activated if rewards are deprecated under this TIP. This TIP does not require any one-time storage cleanup or migration. Existing rewards-related storage, including reward recipient, reward balance, global reward-per-token, and opted-in supply state, must remain untouched. This TIP does not reserve any special pending or in-flight reward distributions before activation. Any rewards accrued and checkpointed before T8 remain claimable. New distributions after T7 are no-ops. # Rollout Plan TIP-20 rewards should be disabled through a progressive rollout across T7 and T8. The two-hardfork rollout preserves enough legacy reward accounting after T7 to settle pre-T7 lazy rewards, then removes ordinary balance-changing reward update checks at T8 after affected holders have had a checkpointing window. At T7 activation: - `distributeReward(uint256 amount)` and `setRewardRecipient(address recipient)` become non-reverting no-ops. - Existing reward update logic remains available only as needed to settle pre-T7 lazy rewards. - No new reward distributions or reward-recipient changes are accepted. Between T7 and T8, a volunteer SHOULD checkpoint any opted-in holders that may have unclaimed, untracked rewards. A zero-value or dust transfer to each affected holder can force lazy rewards to accrue into settled reward balances. This window would ensure that rewards distributed before the T7 activation block can be collected by those holders. At T8 activation: - Reward tracking is fully deprecated. - `claimRewards()` remains available for settled reward balances. # Security Considerations This TIP relies on TIP-20 callers tolerating successful no-op behavior for deprecated reward opt-in and distribution calls. Callers that require new rewards to accrue after T7 are out of scope because new reward accrual is intentionally disabled. The protocol must continue to protect already-accrued reward balances. Implementations must not remove, overwrite, or migrate legacy rewards-related storage in a way that prevents holders from claiming rewards accrued before T8. # Test Cases - After T7, `setRewardRecipient` does not change reward-recipient state, opted-in supply, or any balance. - After T7, `distributeReward` does not change global reward-per-token, opted-in supply, reward balances, token balances, or total supply. - After T8, ordinary TIP-20 balance-changing paths do not update reward accumulators for affected addresses. - Existing accrued reward balances remain claimable through `claimRewards()`. - Claiming rewards preserves the existing `claimRewards()` API and accounting. - Rewards-related storage is not migrated or cleaned up as part of activation. - The reward-specific balance-bit optimization from TIP-1065 is not activated.