DIWG Update: Sync 2, RFC Feedback, PRS Parameters, Superfluid Partnership
Following the publication of the V2 Delegate Rewards RFC, the DIWG held its second working group sync. The agenda focused on reviewing the community’s RFC feedback, defining the Peer Recognition Score (PRS) parameters, and exploring a potential Superfluid partnership.
1. RFC Consensus
Based on overwhelming delegate support in the forum, the DIWG has officially locked the following parameters for the V2 framework:
-
Voting Threshold: Locked at 1M SUMR.
-
100% Voting Bonus: Removed. There will be no bonus from Pool B for perfect attendance.
-
Pool Split: Locked at 85/15.
-
Core Team Eligibility: Core team members are officially eligible for Pool B, as they are highly active and possess deep protocol knowledge.
-
Pool B Payout Split: We adopted the tiered distribution model for the top 3 contributors: 50% ($100), 30% ($60), and 20% ($40). We will review the effectiveness of this split after 3-6 months.
Link Here: [RFC] Delegate Rewards Framework V2
2. Peer Recognition Score (PRS) Parameters We spent a significant portion of the sync refining the actual math behind the PRS to ensure it is fair and logical.
-
Role Multipliers: Base weights are applied based on a user’s role. Recognized Delegates = 1.0x, Foundation/ Core Team = 2.0x, Proposal Author = 1.8x, and a proposed “Trusted Contributor” role = 1.5x.
-
Unverified Accounts Adjustment: Originally, unverified accounts had a 0.1x multiplier. Based on feedback noting that 80-90% of forum accounts are unverified, we are exploring raising this to capture valuable community engagement.
-
VP Component: To prevent large token holders from dominating the score just by liking a post, we are using a square root function to compress Voting Power weight. The VP Reference is set at ~7.31M SUMR. This is the mean VP of active voters (those who participated in at least 80% of proposals in the last 90 days). This will be recomputed every quarter.
-
Quality Filters: To qualify for a PRS score, a delegate must comment on at least 3 proposals. Furthermore, an “Author Acknowledgement Bonus” (+2 flat points) is awarded if a proposal’s author replies to your comment, signaling high-value input.
-
Education Initiative: For a deeper understanding of PRS, the WG suggested a possible 5 min explainer to help the community understand the mechanism once the SIP is live.
(Full draft here: [Summer Forum Peer Recognition Score Draft v1] )
3. Execution & Budget Mechanics As we finalize the execution layer, the WG debated how to convert our capped USD budget ($4,200/quarter) into SUMR tokens. Because the token price fluctuates, we must decide how often we calculate the conversion rate and who absorbs the volatility risk (the treasury or the delegates).
We narrowed it down to three potential routes:
-
Route A: Quarterly-Funded Multisig (Dynamic Monthly Pay)
A multisig is funded quarterly but recalculates the SUMR payout monthly to meet the USD target. It protects delegate pay, but risks DAO budget shortfalls. For example, if SUMR’s price drops 50%, the multisig must pay out twice as many tokens. It could run empty mid-quarter, requiring an emergency DAO vote to refill it.
-
Route B: Fixed Quarterly SUMR (Predictable Treasury Spend)
The DAO calculates the conversion rate once at the start of the quarter and distributes that fixed amount of SUMR every month. It protects the treasury’s budget, but forces delegates to absorb the price volatility. For example, if the locked rate is 1,400 SUMR per month and the token price crashes, delegates still only receive 1,400 SUMR, dropping their actual pay well below the USD target.
-
Route C: Monthly DAO Votes
The exact USD-to-SUMR conversion rate is calculated each month and bundled into the standard monthly disbursement vote without using a multisig. It provides financial precision for both the treasury and delegates, but requires continuous governance effort. For example, every single month, the DAO must draft, review, and vote on a new proposal to release the exact amount of SUMR needed for that month’s payout.
4. Superfluid Partnership Exploration Jensei brought up an excellent proposal regarding a deeper partnership with Superfluid.
- The Decision: The WG supports exploring this. However, to ensure the V2 framework ships on time, we will separate this into its own dedicated initiative to be explored after the current SIP is executed.
Next Steps
-
Update the transparency thread and link all related documents
-
Revise the RFC for final WG review, including the updated PRS parameters.
-
Finalize the exact SUMR conversion rate (7-day vs. 20-day TWAP) and execution route.
-
Format the finalized framework into a formal SIP and push it to a onchain vote.
Thank you to everyone who has participated in the RFC process. We are almost at the finish line!