[RFC] Delegate Rewards Framework V2

1. Executive Summary

This proposal introduces Delegate Rewards V2, a redesigned incentive framework for Lazy Summer DAO’s recognized delegate program. Recognizing that the current framework (SIP5.6) has demonstrated a structural misalignment between treasury spend and governance workload, this proposal replaces it with a Dual-Pool system anchored to a fixed maximum quarterly budget of $4,200 USD ($1,400 USD monthly). To protect quorum stability and elevate contribution quality, the monthly budget features an 85% baseline allocation ($1,200) strictly rewarding delegates who maintain at least an 80% on-chain voting participation rate, alongside a 15% allocation ($200) reserved exclusively for the top 3 delegates driving high-value forum discussions as measured by the Peer Recognition Score (PRS). Finally, to align delegate incentives with the long-term economic health of the protocol, mitigate sell pressure, and reduce administrative strain, all funds will be managed by a dedicated Delegate Rewards Multisig and distributed as 30-day Superfluid streams following a monthly performance audit.

2. Motivation

The delegate compensation system formalized in SIP5.6 served Lazy Summer DAO well during its early governance phase. As the protocol’s complexity has grown—with DAO-managed vaults, expanded risk frameworks, and increasing governance throughput—the structural weaknesses of a static retainer model have become measurable and well-documented.

2.1 The Data Case for Reform

  • Inverted Pay-to-Workload Ratio: In June 2025, the DAO processed 1 proposal and paid out approximately 152,000 SUMR—the second-highest monthly total of the year. In May 2025, the DAO processed 14 proposals and paid only ~126,500 SUMR. Treasury spend had a negative correlation with governance workload.

  • Rising Fixed Cost Baseline: As the delegate set grew from 14 members (March) to 23 (December), the treasury baseline crept from ~118k to ~165k SUMR per month, driven by headcount rather than governance output.

2.2 Treasury Constraint

The design of this framework was ultimately dictated by our current financial constraints. As of March 5, 2026, the Lazy Summer treasury holds a total balance of ~$298k USD. However, it is heavily weighted in SUMR (93.4%), with light stablecoin (2.8%) and ETH (3.8%) balances.

While forum discussions initially suggested a $1,500/month payout for high-value contributors, the DAO agreed this must serve as a long-term “north star.” Implementing that model today would require ~$25,000/month, which creates an unsustainable sell-side pressure given our lean stablecoin runway. Consequently, all V2 framework decisions have been heavily optimized to fit within our current fiscal constraints.

3. Goals and Objectives

To directly address the issues outlined above, Delegate Rewards V2 was designed with three primary objectives:

Goal How this framework addresses it
Quorum Stability Pool A heavily weighted to make voting participation financially attractive
Contribution Quality Pool B rewards top PRS scorers; pre-vote forum engagement > post-vote
Treasury Sustainability Fixed quarterly budget cap; streaming reduces sell cliffs; quarterly reporting

4. Proposed Framework Specifications

To execute the goals outlined above, the V2 Delegate Reward Framework will operate under the following parameters:

4.1 The Quarterly Budget Cap All delegate rewards will be drawn from a fixed quarterly SUMR budget, denominated in USD to provide predictability and recalculated at the start of each month.

The budget for this framework is capped at $4,200 USD equivalent per quarter (distributed as $1,400 USD per month).

4.2 The Pricing Mechanism & Buffer

To protect both delegates and the treasury from SUMR price volatility, the SUMR payout amount is calculated at the start of each month using a 7-Day Time-Weighted Average Price (TWAP).

  • The Conditional 10% Buffer: If the DAO opts to stream payouts continuously over 30 days (e.g., via Superfluid), delegates face exposure to mid-month price drops. To mitigate this, a 10% buffer is added to the calculated base amount. Importantly, this buffer falls outside the $1,400 reward budget and is funded from the multi-sig operations costs. If the token price holds steady, delegates receive a small bonus; if the token drops up to 10% mid-month, their baseline USD compensation remains perfectly protected. (Note: If the DAO ultimately chooses to execute payouts retroactively via standard Tally lump-sum transfers instead of streaming, this buffer becomes unnecessary and will be removed to save treasury funds).

    • Example calculation (Streaming scenario): If the 7-day TWAP at the start of the month is $0.20, the base $1,400 USD budget equals 7,000 SUMR. Adding the 10% buffer (700 SUMR) brings the total streamed amount to 7,700 SUMR.

4.3 The Dual-Pool Split

The $1,400 monthly budget is divided into two distinct pools. This 85/15 split deliberately prioritizes quorum stability under a lean budget, while ensuring the contribution pool remains concentrated enough to be financially meaningful.

  • Pool A — Voting Baseline (85% / ~$1,200/month): Rewards consistent onchain participation. Making this pool highly attractive ensures quorum remains stable even as the delegate set grows.

  • Pool B — Contributions (15% / ~$200/month): Rewards high-value forum contributions that shape outcomes before the voting phase (forum analysis, proposal feedback, and thoughtful contributions) via the PRS leaderboard.

4.4 Baseline Eligibility (Pool A) To unlock Pool A rewards, a delegate must achieve a minimum 80% voting participation rate across all onchain proposals within the calendar month. This is a strict, binary outcome with no partial credit:

Tier Participation Rate Outcome
Standard 80–100% Qualifies for the full Pool A reward.
Ineligible < 80% No reward. Half-effort does not qualify.
  • Rationale: The 80% floor secures quorum while providing a realistic buffer for missed proposals, balancing the protocol’s need for stability with the explicit part-time nature of the delegate role.

  • Open Question for the DAO: Should a perfect 100% voting record unlock an additional bonus from Pool B?

Voting Power Threshold To ensure the program attracts high-value contributors rather than becoming a low-effort yield source, the minimum delegated voting power required to qualify as a recognized delegate is being raised.

  • Proposed Minimum Threshold: Exploring an increase from the current 10,000 SUMR to 60k, 500k, or 1M SUMR.

    • Rationale: The V2 framework increases the delegate reward value by approximately 6x, so the entry threshold must rise proportionally. Given our lean budget, the DIWG is seriously considering the higher 1M SUMR minimum to ensure absolute conviction.
  • Supporting Small Delegates (Future Initiative): Raising the threshold creates a real risk of excluding highly active contributors who lack initial support from their delegators. To solve this, the DIWG might propose a separate DAO delegation program in the future. This program would identify top-performing delegates and formally grant them treasury voting power so they can qualify.

4.5 PRS Utilization (Pool B Payouts)

The $200 Contribution Pool is highly concentrated to incentivize deep protocol work (e.g., forum analysis, proposal feedbacks, thoughtful forum contributions). It will be split exclusively among the top 3 highest-scoring delegates on the monthly Peer Recognition Score (PRS) leaderboard. Capping payouts to the top 3 performers ensures the reward is financially impactful and creates healthy competition for high-value forum work.

The Peer Recognition Score (PRS)

Contribution quality will be measured through the Peer Recognition Score (PRS) which is an objective way to measure forum contribution using likes. To distinguish high-value insights from standard noise, the system weighs validation through likes based on reputation, meaning an endorsement from a delegate carries significantly more weight than a random like. For full details on PRS, please check this link: Summer Forum Peer Recognition Score

4.6 Technical Execution & Streaming Logic

The optimal technical execution for payouts is currently under review to ensure cost-efficiency. Delegate rewards will be disbursed either via continuous Superfluid streams managed through a dedicated Delegate Rewards Multisig, or via direct onchain execution through standard Tally proposals.

The payout process runs on a strict monthly rolling cycle:

  • Monthly Qualification Audit: At the end of each month, eligibility is assessed. Jensei will track and confirm onchain voting participation rates (at no additional cost to the DAO, as this is supported by Labs), while Curia will finalize and report the offchain PRS leaderboard

4.7 Success Metrics & Reporting (KPIs)

Curia will publish a quarterly report

  • Governance Stability: Quorum consistency, actual increase in active voting power, increase in voting power

  • Forum contribution: Amount of comments, amount of proposals month by month

  • Decentralization Growth: Increase in active delegates, Nakamoto coefficient

  • Protocol Impact: TVL growth, New yield sources added.

  • Monthly Top Contributors

5. Open Questions for Community Discussion

The following parameters remain unresolved and require broader delegate input before this proposal moves to a formal SIP:

Open Question Current Options / Notes
Voting power threshold 60k SUMR (proportional increase) vs. 500k–1M SUMR (high-conviction threshold).
100% voting bonus Should delegates achieving perfect participation receive a bonus from Pool B?
Pool split DIWG landed on 85/15. Is this the right balance? A 70/30 or 60/40 split would elevate contribution quality incentives but reduces quorum protection.
Core Team Eligibility Should core Labs team members be eligible for Pool B contribution rewards, or strictly reserved for independent delegates to encourage decentralization?
Technical Execution & Buffer Should we prioritize Superfluid streaming (which requires the 10% volatility buffer) or use standard Tally retroactive lump-sums (which saves the treasury the 10% premium but lacks continuous streaming)?

6. Governance & Implementation Timeline

Phase Dates Milestone / Action
Week 0 Feb 5 Forum thread discussions initiated; delegates provided data exposing current model flaws, which were explored further in community calls.
Week 1 Feb 9–13 Core Delegate Incentive Working Group (DIWG) formed; hosted Workshop Part 1 to explore tensions and options.
Week 2 Feb 16–20 Hosted Workshop Part 2; secured foundational consensus on the budget cap, baseline voting, and Dual-Pool structure.
Week 3 Feb 23–27 Published the Transparency Hub and updated the Miro board to track framework designs.
Week 4 Mar 2–6 Drafted the V1 SIP skeleton; currently undergoing DIWG review before posting to the forum as an open RFC.
Week 5 Mar 9–13 Gather and integrate delegate feedback from the RFC
Week 6 Mar 16–20 Buffer week for final adjustments before voting.
Week 7 Mar 23–27 Active voting week.
Launch April 1 Implementation for Q2 launch.

7. Costs

7.1 Program Manager Compensation Curia will serve as the dedicated Program Manager for the V2 framework. Responsibilities include maintaining the PRS data pipeline, dashboard, and publishing the quarterly report. For managing this operational and technical overhead, Curia will receive a lean retainer of $420 USD per quarter (representing exactly 10% of the total quarterly delegate payout budget, ensuring administrative costs remain strictly capped).

7.2 Technical Execution & Distribution Costs

The operational budget for distributing rewards remains contingent on the DAO’s preferred technical route (Superfluid streams vs. Tally onchain execution). If the community selects the Multisig/Superfluid model, a lean budget for gas and signer stipends will be introduced prior to the formal Tally vote. If direct Tally execution is selected, these monthly distribution costs will effectively be zero.

7.3 Retroactive Working Group Compensation This current proposal solely covers the forward-looking budget for the V2 Delegate Rewards program. Should this resulting framework be successfully adopted by the DAO, a separate, subsequent proposal may be submitted to retroactively reward the core DI-WG (Delegate Incentive Working Group) contributors for their time, research, and strategic design work.

8. Call to Action

This is a Request for Comment. No parameters are final until the community has engaged. Delegates and community members are invited to:

  • Comment below with feedback on any section of this proposal

  • Share your view on the open questions in Section 6

  • Attend the next community call to engage in live discussion


Tagging @Recognized_Delegates and @jensei

5 Likes
  1. I am a big fan of having high conviction threshold and think a million $SUMR is a starting point (we can revisit if MC changes).
  2. I am happy with a 80% voting threshold, I do not think a voting bonus should occur.
  3. I am happy with the 85/15; I think if you put alot of emphasis on forum contributions you will start getting alot of AI slop.
  4. I am OK with Labs team members receiving $SUMR for Pool B contribution rewards (forum activity)
  5. Not sure on this one yet; would like to hear back from other delegates.
4 Likes

We agree with the proposal for delegate rewards. It is well structured and will be essential to attract more delegates to participate in Summer’s governance.

Regarding the points raised in the proposal:

  • Voting Power Threshold: We believe that a value between 500K–1M SUMR is a reasonable threshold to qualify delegates for rewards. Other DAOs often set higher thresholds. In Lazy Summer, setting a tangible level that allows delegates (who wish to) to acquire governance tokens and participate in the delegate incentive program is a more appropriate decision.

  • 100% Voting Bonus: We believe that a bonus for delegates who reach 100% participation is not necessary. We have no opposition to it, but we do not believe it will meaningfully incentivize delegates to aim for perfect participation. On the other hand, the Contribution Pool from the Peer Recognition Score could be a good mechanism to encourage delegates to reach 100% participation.

  • Pool Split: We believe that distributing rewards in an 85/15 proportion better fits Lazy Summer. There will often be many operational and time-sensitive proposals. DAOs that require on-chain parameter adjustments depend on active delegate participation to vote on these changes, and therefore voting should remain the most important aspect of governance. Contributions beyond voting should certainly be rewarded, but the 85% allocation will also be fundamental to maintaining Lazy Summer’s economic security, while the remaining 15% will serve as an incentive for high-quality governance contributions.

  • Core Team Eligibility: We see no problem with the core team being eligible for rewards. Currently, they are among the main participants in discussions and are fundamental to keeping Lazy Summer operational.

  • Technical Execution and Buffer: We believe that retroactive distribution is the better option at this stage. It preserves DAO treasury resources during a sensitive moment and is operationally simpler. We have received governance participation rewards in other ecosystems, and retroactive distributions have worked well.

In addition to these points, we highlight the importance of transparency and the creation of tools or methods to visualize the criteria, values, and analyses used to distribute rewards to delegates. For example, a dashboard with data related to the Monthly Qualification Audit conducted by Jensei.

The key is ensuring that delegates have no doubts regarding their eligibility or the number of tokens they receive through the program. Other DAOs have faced problems with this in the past, creating friction and turning delegate rewards into the main governance controversy.

3 Likes

Really great work on the proposal!

Voting Power Threshold

Personally, I’d suggest setting the threshold at 1M SUMR to start. At the current price that’s only around $3k, and it helps not just with conviction but also with discouraging sybil delegator accounts created purely to extract value.

100% Voting Bonus

No objections from me.

Pool Split

Looks good.

Core Team Eligibility

I don’t see an issue here. If a team member submits a proposal on their own personal initiative rather than as part of their job, excluding them would feel unfair. I think it makes sense to let the team member decide whether to waive the reward depending on whether the work is related to their role.

Technical Execution & Buffer

What is the benefit of using a Superfluid continuous stream that justifies the added complexity and overhead for the Delegate Rewards multisig? The current approach using standard Tally proposals seems to work well in my opinion.

1 Like

I wanted to propose a change to the Pool B payout structure. Instead of splitting rewards evenly, it would be better to allocate them based on PRS ranking: 50% for 1st place, 30% for 2nd, and 20% for 3rd. The top contributor typically puts in significantly more effort than the others, so a proportional distribution creates stronger motivation and fairly rewards the level of contribution.

Also the link to the “full details on PRS” is missing. Could you please fix that @Curia

2 Likes

Voting power threshold - 1M SUMR seems reasonable here, as this will allow the rewards to be meaningful to those contributing the most to the quorum.

100% voting bonus - Given the size of Pool B, I don’t think it is sufficient to provide meaningful rewards for voting delegates.

Pool split - 85/15 is okay with me

Core Team Eligibility - I don’t see any problem with this, although I would suggest that any core Labs team members opt out if they believe their operational responsibilities might give them an unfair advantage here.

Technical Execution & Buffer - Retroactive lump sums, mainly to reduce admin, and keep the program simple.

Note: As a member of the DIWG, the above opinions are solely my own.

Thank you to @mastermojo, @Blockful, @Piter, and @Sixty for the feedback. The DIWG has reviewed these comments, and the alignment across the board is strong. Because the consensus is clear, I am summarizing the finalized parameters below:

Locked Parameters (Based on Consensus):

  • Voting Power Threshold: Locked at 1M SUMR. This establishes the high-conviction barrier we need and discourages sybil extraction.

  • 100% Voting Bonus: Removed. We agree with the feedback that Pool B is too small to dilute with participation bonuses. The strict 80% baseline is sufficient for quorum protection.

  • Pool Split: Locked at 85/15.

Refinements & Additions:

  • Core Team Eligibility: Core members will be eligible, but with a formal “Honor System / Opt-Out” clause. As Piter and Sixty suggested, team members are expected to self-assess whether their operational role gives them an informational advantage and opt out accordingly.

  • Pool B Payout Structure: Adopting Piter’s suggestion, Pool B will be distributed proportionally by PRS rank to the top 3 contributors: 50% for 1st place ($100), 30% for 2nd ($60), and 20% for 3rd ($40).

  • Transparency & Tracking: Agreeing with @Blockful, this is non-negotiable. A public Monthly Audit will be published so no delegate has to guess their eligibility or token amount.


Urgent Update: Technical Execution

We were initially leaning toward Tally for retroactive payouts, but due to Tally’s recent shutdown announcement, we are actively exploring alternative execution platforms.

Regardless of the platform we choose, we still need to solve the core economic mechanics: how to convert our capped USD budget ($4,200/quarter) into SUMR tokens. Because the token fluctuates, we must decide who absorbs the volatility risk. We have narrowed it down to three routes:

  • Route A: Quarterly-Funded Multisig (Dynamic Monthly Pay)

    A multisig is funded quarterly but recalculates the SUMR payout monthly to hit the USD target. It protects delegate pay, but risks emptying the multisig mid-quarter if the token drops (requiring an emergency refill vote).

  • Route B: Fixed Quarterly SUMR (Predictable Treasury Spend)

    The conversion rate is locked exactly once at the start of the quarter. This protects the treasury’s budget, but forces delegates to absorb all token volatility risk if the price crashes mid-quarter.

  • Route C: Monthly DAO Votes

    The exact conversion rate is calculated and voted on every single month without a multisig. This provides financial precision for both parties, but creates a recurring monthly administrative overhead for the DAO.

Open Questions for Community Discussion: As facilitators, the DIWG needs the community to signal their preference on these final mechanics before we draft the SIP:

  1. Which execution route should we take? Route A (Multisig), Route B (Fixed Quarterly), or Route C (Monthly Votes)?

  2. TWAP Window (If Route A or C is chosen): To calculate the dynamic monthly price, should we stick to the originally proposed 7-day TWAP, or adopt a 20-day mid-month TWAP (excluding the first and last 5 days of the month to avoid end-of-month volatility)?

All parameters are now locked except technical execution. I will update the draft to reflect these finalized parameters.

(P.S. The PRS link has been attached to the RFC and the framework can also be found here: Summer Forum Peer Recognition Score Draft v1)


Tagging @Recognized_Delegates and @jensei

1 Like

Thanks @Curia and the DIWG for a well-structured RFC and for summarizing the consensus quickly. The locked parameters look good to me. I want to contribute on the remaining open questions and add one idea.

Technical execution route: Route A (multisig) with Snapshot signaling

Given Tally’s shutdown, I’d advocate for Route A — a quarterly-funded Safe multisig with monthly USD recalculation — paired with Snapshot for off-chain coordination. This isn’t a new stack for the DAO; Snapshot is already live for signaling in Lazy Summer governance, and Safe is battle-tested execution infrastructure. Routing through monthly Snapshot temperature checks before each Safe disbursement keeps the process transparent without requiring a full on-chain governance vote every month (Route C), while avoiding the fixed volatility exposure that Route B places entirely on delegates.

The main risk with Route A is a mid-quarter SUMR price drop draining the multisig before the quarter ends. A simple mitigation: fund the multisig at the start of each quarter using a conservative SUMR price (e.g. the prior 30-day low rather than the TWAP), with a small buffer top-up mechanism triggered by governance if the price drops more than 20% intra-quarter. This protects both the treasury floor and delegate compensation stability without requiring emergency votes.

TWAP window: 20-day mid-month

I’d support the 20-day mid-month TWAP over the 7-day window. SUMR liquidity is thin enough that a 7-day window is meaningfully vulnerable to end-of-month price movements — either gaming or simply noise. Trimming the first and last 5 days of the month removes the most volatile periods and gives a cleaner conversion baseline. Yes, it adds a few days of calculation lag, but that’s a worthwhile tradeoff for a more manipulaton-resistant rate.

One additional idea: a PRS eligibility floor

The concern about low-quality forum posts gaming Pool B is worth addressing structurally. I’d suggest a light eligibility filter: to appear on the PRS leaderboard in a given month, a delegate must meet the Pool A voting threshold (≥80% participation) AND have at least one post that received recognition from two or more other recognized delegates. This avoids a scenario where someone qualifies for Pool B via accumulated low-effort likes while skipping governance votes — it makes voting participation a prerequisite for contribution rewards as well. The bar is intentionally low so it doesn’t exclude genuine contributors, but it filters out pure forum-farming.

On the framework review cycle

Lastly, I’d suggest the quarterly KPI report include an explicit decision checkpoint: if governance throughput drops below a threshold (e.g. fewer than 4 proposals in a quarter) or Pool A utilization falls below 60% of delegates, the DIWG should automatically trigger a framework review. Baking in a sunset condition avoids the inertia problem that let V1 persist despite the inverted pay-to-workload data.

2 Likes

Thank you @vumichien for your feedback, this has been instrumental in helping us finalize the proposal.

To summarize your input for our final consensus:

  • Execution: Route A (Safe Multisig + vote ) with a conservative 30-day low funding buffer.

  • TWAP: 20-day mid-month to prevent manipulation on thin liquidity.

Regarding the new structural additions:

  1. PRS Eligibility Floor: tying Pool B eligibility to the 80% voting baseline + peer validation
  2. Framework Review / Sunset Clause: automatic triggers if KPIs drop

We have officially integrated all of your suggested mechanics into the SIP draft. Thanks again for your contribution in this framework!

1 Like