Rewards v2 Mainnet Launch (#411)

Author: wesfloyd

docs/developers/rewards.md

@@ -8,16 +8,16 @@ title: AVS Rewards
 Before proceeding, please review the [Rewards Overview](/docs/eigenlayer/rewards-claiming/rewards-claiming-overview.md) for background information on how Rewards distributions work.
 
 
-## Rewards v2 (currently in Testnet)
+## Operator Directed Rewards
 
-With the release of Rewards v2 (currently in Testnet), AVSs have the flexibility to set custom logic for rewards to individual Operators, based on work completed or anything else they may design or desire (e.g., more equal distribution of operator support for decentralization or security reasons). Variable Operator fees per AVS, set by Operators, allows Operators to take less or more than the 10% default fee on rewards. This keeps EigenLayer fee-agnostic as a protocol and unlocks flexibility via a variable take rate for operators in choosing which AVS to run and in attracting new stake.
+With the release of Rewards v2, AVSs have the flexibility to set custom logic for rewards to individual Operators, based on work completed or anything else they may design or desire (e.g., more equal distribution of operator support for decentralization or security reasons). Variable Operator fees per AVS, set by Operators, allows Operators to take less or more than the 10% default fee on rewards. This keeps EigenLayer fee-agnostic as a protocol and unlocks flexibility via a variable take rate for operators in choosing which AVS to run and in attracting new stake.
 
 Please see [ELIP-001 Operator Directed Rewards](https://github.com/eigenfoundation/ELIPs/blob/main/ELIPs/ELIP-001.md#distribution-of-operator-directed-rewards) for more information.
 
 
 ## AVS Integration
 
-AVSs can make rewards submissions via calling `createAVSRewardsSubmission` or `createOperatorDirectedAVSRewardsSubmission()` (per Rewards v2, currently in Testnet) on the `RewardsCoordinator` contract. Each rewards submission specifies:  
+AVSs can make rewards submissions via calling `createAVSRewardsSubmission` or `createOperatorDirectedAVSRewardsSubmission()` on the `RewardsCoordinator` contract. Each rewards submission specifies:  
 
 1. A time range for which the rewards submission is valid. Rewards submissions can be retroactive from the M2 upgrade and last up to 30 days in the future.
 2. A list of strategies and multipliers, which enables the AVS to weigh the relative payout to each strategy within a single rewards submission.

docs/eigenlayer/rewards-claiming/rewards-claiming-overview.md

@@ -14,13 +14,12 @@ By default, Operators will earn a flat 10% split on rewards. The rest of the rew
 - The AVS's relative weighting of strategies in a rewards submission.
 
 
-## Rewards v2 (currently in Testnet)
+## Rewards Flexibility
 
-The EigenLayer Improvement Proposal (ELIP-001) outlines enhancements to the rewards system under the Rewards v2 framework. These enhancements focus on these key areas:
-1. Operator Directed Rewards: AVSs can now direct performance-based rewards to specific Operators using custom logic. This allows rewards to be distributed based on work completion, quality or other parameters determined by the AVS, allowing flexible and tailored incentives. Operators registered to AVSs for the specified duration are eligible. This approach enables customization and diverse reward mechanisms that can be attributed on-chain, aligning incentives with Operator contributions.
-2. Variable Operator Fees for AVS Rewards: Operators can now set their per-AVS fee rate on AVS rewards to any amount from 0% to 100%, deviating from the 10% default split. Changes to this split take effect after a 7-day activation delay. The ability to set a variable split per-AVS allows Operators to align their fee structures with their economic needs and the complexity and diversity of AVS demands.
-3. Variable Operator Splits for Programmatic Incentives: Operators can set their split of Programmatic Incentives to any amount from 0% to 100%, so that Operators have flexibility in determining the appropriate take rate. Changes to this split take effect after a 7-day activation delay. These splits integrate seamlessly with the existing reward distribution model, ensuring that stakers delegating to Operators benefit proportionately.
-4. Batch rewards claiming for stakers and Operators, allowing a gas efficient way to claim on behalf of multiple earners in a single transaction.  
+The protocol also includes the following features to enable additional flexibility for rewards distribution:
+- Operator Directed Rewards: AVSs can now direct performance-based rewards to specific Operators using custom logic. This allows rewards to be distributed based on work completion, quality or other parameters determined by the AVS, allowing flexible and tailored incentives. Operators registered to AVSs for the specified duration are eligible. This approach enables customization and diverse reward mechanisms that can be attributed on-chain, aligning incentives with Operator contributions.
+- Variable Operator Fees for AVS Rewards: Operators can now set their per-AVS fee rate on AVS rewards to any amount from 0% to 100%, deviating from the 10% default split. Changes to this split take effect after a 7-day activation delay. The ability to set a variable split per-AVS allows Operators to align their fee structures with their economic needs and the complexity and diversity of AVS demands.
+- Variable Operator Splits for Programmatic Incentives: Operators can set their split of Programmatic Incentives to any amount from 0% to 100%, so that Operators have flexibility in determining the appropriate take rate. Changes to this split take effect after a 7-day activation delay. These splits integrate seamlessly with the existing reward distribution model, ensuring that stakers delegating to Operators benefit proportionately.
 
 Please see the [EigenLayer Improvement Proposal-001: Rewards v2](https://github.com/eigenfoundation/ELIPs/blob/main/ELIPs/ELIP-001.md#executive-summary) for more detail.
 
@@ -31,7 +30,6 @@ Please see the [EigenLayer Improvement Proposal-001: Rewards v2](https://github.
 Operators and Stakers are both categorized as "Earners" when it comes to claiming and are distinct by their addresses. Actual reward calculations are explained further in the [technical docs](https://github.com/Layr-Labs/eigenlayer-contracts/blob/dev/docs/core/RewardsCoordinator.md). To summarize, reward calculations are performed daily by snapshotting the on-chain state. Once a week on mainnet and daily on testnet, a Merkle root is posted to the contract that allows earners to claim their updated earnings.
 
 
-
 ### Setting Designated Claimers
 Earners (Stakers and Operators) can set a claimer address that can claim rewards for the tokens they've earned. An Earner is its own claimer by default and only the claimer address can claim rewards. If a new claimer is set, the new address can claim all of the previously unclaimed rewards. The Earner can always change their designated claimer address.