OIP#4 Delegate Compensation and Delegate Reputation Score Integration for stOBOL

[coolhorsegirl]

Status: Final

Proposal Type: Contract upgrade

Abstract

This proposal introduces two upgrades to enhance the governance system for stOBOL:

1. Delegate compensation mechanism: A reward system that distributes rewards to active delegates from a dedicated pool, separate from the staking rewards.
2. Delegate Reputation Score (DRS) integration: A lightweight activity tracking and reputation layer, enabling transparency and accountability in delegate performance. Staking rewards for token holders and delegates can depend on delegating to an “active delegate” as determined by DRS.

This proposal - originally posted May 14, 2025 - has been updated to reflect community feedback. It lays the foundation for a system that can evolve in the future.

Motivation

The Obol Collective is committed to building a governance system that rewards active contribution over passive token holding. To realize this vision, Tally proposes to align incentives around meaningful participation in governance.

This proposal introduces two key upgrades to Obol’s staking and delegation flow: delegate compensation and Delegate Reputation Score (DRS) integration. Together, these mechanisms ensure that rewards flow toward the individuals and behaviours that sustain and improve the protocol.

• Delegates are rewarded for active participation—such as voting and protocol stewardship—through a separate compensation pool.
• Token holders earn staking rewards by participating directly or by delegating to proven, active delegates as measured by the DRS.

The goal is to introduce an integrated, high-integrity incentive structure that:

• Makes Obol’s governance more robust by rewarding verifiable contributions,
• Encourages long-term commitment by linking rewards to activity,
• Aligns token holder incentives with the protocol’s success,
• Establishes transparent reputationnal signals to help delegates stand out and voters make informed choices.

Whether or not we’re currently seeing participation problems, the core principle remains: no one should have to work for free, especially not long-term. Yes, the TGE moment creates short-term energy. But adrenaline fades, and when it does, clear structures matter.

The long-term vision is to gradually increase the value we place on delegate work over time. This proposal is framed as a first version, designed to pilot the system with 10% of rewards allocated to delegates. That balance may change in future governance cycles.

In the future, we expect delegate rewards to come from the same pool as staking rewards, with a fixed % redirected toward governance participation. For this initial period with an already live staking rewards pool, a separate reward pool helps isolate and test the mechanism.

We also acknowledge feedback that current delegate participation is healthy and that there’s no major problem to solve right now. That’s precisely why it’s a good time to build the right structure, before scaling issues emerge.

Some of the largest DAOs are now dedicating enormous resources to retroactively solve participation challenges. Obol has the opportunity to build that foundation upfront, leveraging lessons from those who came before.

This proposal is modular by design and can be improved in future iterations.

Specifications

Delegate compensation mechanism

We propose implementing a reward mechanism where a dedicated pool of rewards is distributed to active delegates.

• 165,000 OBOL tokens from a separate delegate reward pool (not the staking pool), to be distributed over 6 months (or until when the current reward pool will empty).
• Rewards distributed proportional to the square root of voting power, to reduce the risk of centralization and create a flatter reward curve.
• In future phases, rewards may be weighted directly by DRS.

Linear vs √Power Rewards

Here is a simplified example of the rewards distribution:

Delegate	Voting Power	Linear Reward	√Power Reward
A	100	55.5%	44.3%
B	50	27.7%	31.3%
C	30	16.6%	24.3%

This curve flattens the advantage of large delegates and better rewards smaller but engaged participants.

Goals

• Reward active participation in governance
• Reward token holders for delegating to active delegates.
  • Alternatively, token holders can earn rewards by participating directly.
• Support long-term commitment to Obol governance.

How it works

Obol would upgrade the existing staking system to add new requirements:

• Stakers would only be eligible for rewards if they’re delegated to an “active” delegate
  • “Active” would be defined as having a minimum DRS.
    • Obol Association will align with DRS Provider on how to calculate a delegate’s DRS. A first (subject to modification) calculation model is outlined below.
• 165,000 OBOL tokens (equivalent to 10% of the global staking rewards pool for the first 6 months of staking) from a separate delegate reward pool (independent of staking rewards) would be distributed to active delegates, proportional to their voting power.

DRS Integration

As part of this initiative, the Obol Collective is currently evaluating multiple potential scoring system providers, including but not limited to Karma and Curia. While both offer viable approaches to delegate reputation scoring, their integration timelines, oracle compatibility, and infrastructure readiness may vary. DRS will use a single oracle implementation per cycle. Karma and Curia have confirmed compatibility with Tally and can operate off the same version-controlled logic.

To ensure implementation proceeds smoothly post-approval, this proposal grants the Obol Association, in collaboration with Tally, the authority to select the most technically viable and aligned provider for the first deployment of the Delegate Reputation Score.

This flexibility allows the Collective to:

• Launch the scoring system without delays,
• Maintain compatibility with Tally’s staking and governance UI,
• Optionally rotate or expand to additional providers in future phases, based on performance and community feedback.
• Regardless of the initial provider selected, the DRS calculation logic will remain publicly auditable, version-controlled, and subject to future governance updates

Delegate Reputation Score (DRS)

DRS defines who is eligible to receive rewards and ensures that rewards go to delegates who are consistently participating. It is calculated as a moving average over the past 63 days (equivalent to three voting cycles), designed to reflect recent contributions rather than reputational inertia. Because DRS is based on a rolling 63-day window, scores naturally decay when delegates stop participating, ensuring that rewards reflect current, not historical, legitimacy.

To ensure transparency and fairness, the DRS will be based on a composite of measurable governance activities, with the following simplified structure inspired by existing systems like Curia and Karma:

DRS Formula:

DRS = (Voting Participation Score × 0.40)
		+ (Voting Impact Score × 0.10)
		+ (Voting Timeliness Score × 0.15)
		+ (Rationale Submission Score × 0.15)
		+ (Forum Score × 0.20)

Each metric is normalized on a 0–100 scale and contributes to the total Delegate Reputation Score (DRS) according to its weight. These definitions are adapted from Curia’s scoring model and may evolve based on community feedback.

Classification:

• Active: Maintains over 65% DRS over the past 63 days (≈3 governance cycles)
• Inactive: Below 65% DRS
• Ghost: Has voting power delegated but has not voted at all

If necessary, the Association may update the DRS formula during this pilot phase, based on informal community consultation.

In the future, this formula is subject to change and can be updated through an OIP or by a working group appointed by the association through an OIP if judged necessary.

Possible future improvements include:

• Backup Delegations: allowing delegates to nominate fallback delegates while away, subject to DRS constraints.
• Delegator Diversity and Engagement Caps: to further mitigate whale dominance.

Score Components:

• Voting Participation Score (40% weight)

  • What it is: A combined metric that captures both how frequently a delegate votes and how engaged they are relative to the number of proposals they were eligible to vote on. It replaces and simplifies the separate “Number of Votes” and “Participation Rate” scores into a single, more intuitive component.
  • How it works:
    • Each delegate’s voting frequency is calculated as a percentage of all proposals they were eligible to vote on within the rolling 63-day window. This raw participation percentage (e.g., voting on 8 out of 10 proposals yields a score of 80) is used directly as the Voting Participation Score.
  • Why it matters: Raw vote counts can over-reward large or early delegates. Participation rate alone doesn’t capture effort in contexts where proposal volume varies. This unified score reflects a delegate’s sustained commitment to governance without overemphasizing raw numbers or diluting quality signals.

  We merged Number of Votes and Participation Rate into a single Voting Participation Score to avoid over-counting similar behaviors and to streamline the formula. This ensures we reward consistent, eligible participation without overweighting sheer voting volume.

• Voting Impact Score (10% weight)

  • What it is: Measures how much influence a delegate had in the votes they participated in.
  • How it works: For each proposal, it calculates the share of voting power a delegate used compared to the total votes cast. Then it averages that across all proposals and normalizes to 0–100.
  • Why it matters: This score distinguishes delegates who cast high-weight, meaningful votes from those with little impact, helping highlight influential decision-makers.

• Voting Timeliness Score (15% weight)

  • What it is: Time-decay model that rewards delegates who vote early, reflecting their proactive engagement. This method balances the encouragement of timely participation with fairness to all delegates.

  • How it works:

    • Votes cast within the first 48 hours receive a score of 100. After 48 hours, the score decays linearly to 0 by the end of the voting period. For example, in a 5-day (120-hour) voting window, the score decreases by approximately 1.39 points per hour after the initial 48 hours. This approach maintains transparency and avoids complexity introduced by additional bonus layers.

  • Why it matters: Rewards early and proactive governance participation. Discourages last-minute or opportunistic voting.

• Rationale Submission Score (15% weight)

  • What is is: A new scoring component within the Delegate Reputation Score (DRS) that rewards delegates for submitting written rationales on the Forum explaining their votes. This reinforces transparency and supports informed delegation decisions.
  • How it works:
    • Delegates receive points based on the timeliness of their rationale submissions:

Rationale Submission Timing-bonus options

Model	Rule	Notes
Two-tier (simple)	• ≤ 48 h after vote → 100; > 48 h, until proposal close → 50; None by close → 0	Clearest buckets but has a hard “cliff” at 48 h
Linear-decay with floor	Starts at 100 and drops hour-by-hour to 50 over the first 48 h (≈1.04 pt/h); Stays at 50 until proposal close; None by close → 0	Smooth curve, still gives partial credit late

Raw points from either model already sit on a 0–100 scale, ready to plug into the 15 % weight.

Standardizing the rationale format

Delegates shall follow this template when posting voting rationale:

Vote: For / Against / Abstain
Rationale: <concise reasoning here>

• Why it matters: Providing voting rationales is a governance best practice. It helps token holders understand the thinking behind a vote, increases trust, and reinforces a culture of accountability. This scoring mechanism encourages consistency without introducing heavy evaluation processes, with quality assessment to be considered in future iterations.

• Forum Score (20% weight)

  • What it is: Measures off-chain engagement in the governance forum (posts, comments, discussions).
  • How it works: Derived from multiple signals like number of proposal discussions joined, topics started, likes received, and reading activity. Normalized and simplified for the MVP.
  • Why it matters: Delegates who contribute in the forum often shape decisions early and improve proposal quality. This score rewards those who help make governance deliberative, not just performative.

Integration details

• Smart contract changes required to enable Oracle listener.
• DRS Oracle will score and flag “active” delegates based on voting and proposal participation.
• Tally will handle coordination and UI updates to integrate DRS into delegate profiles.

User interface

• Tally will add support for delegate compensation to the UI
  • Tokenholders would be able to see delegates’ DRS scores and eligibility statuses when staking

• Delegates would be able to see and claim their accrued rewards from their profile page

• These features would be live at both vote.obol.org/stake and tally.xyz/gov/obol/stake
• Eligibility requirements:
  • Must be deemed “active” by DRS Oracle (details below).

Technical scope

• Implement a new earning power calculator smart contract that sends rewards to active delegates
• Front-end UI components
  • Show eligibility and DRS when delegating
  • Let delegates see and claim their rewards
• Dependency, not included in scope: Obol to set up DRS Oracle
• Dependency, not included in scope: DRS Oracle to put scores on-chain

Forum Integration of DRS

In addition to incorporating DRS into staking and delegation flows, the Obol Collective is exploring ways to extend DRS visibility into the governance forum. This would allow delegates to link their forum accounts to their on-chain identities and display their DRS alongside posts and comments.

This feature would serve two purposes:

• Help delegates verify their identity across platforms, increasing trust in discussion.
• Allow token holders to better contextualize forum participation with transparent reputation signals.

This integration is currently under technical review. If confirmed, it could be implemented either by Tally or funded through a small standalone grant, similar to the below proposed Telegram alert feature. A future update will provide details if this path is pursued.

UI and Notification Features

• Tally will replace the Top Delegates leaderboard with a DRS-based version, rather than sorting by raw voting power.

• Curia, Karma, and others may build complementary interfaces that enrich DRS displays drawing on both on-chain metrics and forum-based engagement data

• We are exploring a Telegram notification bot that alerts token holders when their delegate falls below the DRS threshold — making delegation more transparent and responsive. This feature could be built by Tally or developed separately through a small grant. This feature would help build trust in delegation by reducing the perceived risk of picking the ‘wrong’ delegate.

Review Cycle and Governance Flexibility

This proposal is structured as a pilot with a defined review window:

• The 165,000 OBOL pool will be distributed over 6-month, until the current reward pool is empty.
• Afterward, the DAO will:
  • Re-evaluate the efficacy of the system
  • Assess participation trends and feedback
  • assess whether the model improves legitimacy and delegation confidence
  • Consider improvements or expansion

Future changes and improvements may include:

• Adjust the reward percentage
• Merge rewards into the staking pool
• Update the DRS formula (e.g: DRS-weighted)
• Incorporate a notification system
• Peer-review-based assessment mechanism of the rationale submissions (as part of DRS)
• Forum integration of DRS
• Incorporating delegator diversity or engagement-weighted caps may be explored to further decentralize influence

Cost

Total: $65,000

• Delegate compensation implementation:
  • Smart contract development: $35,000
  • Smart contract audit: $20,000 — estimated; if additional audit funding is needed, Tally will submit a follow-up request
• Frontend development and QA: $10,000
  • Including DRS integration

While initial reward pool value is lower than implementation cost, the tooling is reusable across future cycles and proposals.

A note on cost, as it has surfaced a few times in comments:
While Obol is the first DAO to adopt this combination of staking rewards and DRS-based delegate incentives, it’s not necessarily bearing the full cost long-term.

• This implementation requires custom development tailored to Obol’s needs. That includes specific design, oracle integration, and UI work.
• The oracle for DRS is per-DAO — each new DAO that adopts staking + DRS will need its own feed integration, which is not directly reusable from Obol’s implementation.
• Each DAO has different requirements, and Obol’s solution is custom-built on a shared foundation (Tally staking contracts). This is typical for early integrations of a new product line, where the core system is extensible but tailored components are needed per implementation.

Action Plan

• May 14 - May 21: Post proposal on forum for feedback, get approval from 4 top-100 delegates
• May 22 - June 28: Submit proposal on Tally for on-chain voting
• May 29: Tally to begin technical development. During this time, Tally will also get to final alignement with Obol Association on (a) delegate reward pool specs and (2) definition of an “active delegate” by DRS.
• June 25: Begin audit for contracts
• July 16: Launch delegate compensation mechanism and DRS integration.

Conclusion

This is a measured first step toward building a governance system where effort, not only stake, drives long-term influence.

It’s also an opportunity to test legitimacy and transparency while retaining flexibility to evolve. Delegates, token holders, and contributors will shape the next version together.

Disclaimer

This proposal should not be relied on as legal, tax, or investment advice. Any projections included here are based on our best estimates and presented for informational purposes only.

[narko2t1]

I will only write my thought:
what is worse a delegate with less votes than a delegate with more votes? because you described this point so that it is the % of votes that will determine the award, if I understood correctly
but so, in general, good idea

[Curia]

Hey everyone, Varit here from Curia Lab. Thanks for putting together such a thoughtful draft. The compensation mechanism and the DRS integration both resonate with the approach we’ve been sharing in our own thread, so it’s great to see the ideas converge.

We already run a similar delegate data feed for Optimism foundation, so porting that infrastructure to Obol mainly means a few minor tweaks and swapping in whichever formula the community approves. Once live, the feed can be pulled straight into the staking contract or UI, keeping every delegate’s “active” status current.

I think we are aligned on the goal of maintaining one canonical score that any interface - Tally, Curia, Karma, or other tools can reference. After the formula is finalized, we also believed it should be open-source so anyone can review or extend it.

On top of the feed, we plan to add a complementary analytics layer that gives more context to the raw score: trend lines that show how performance evolves, percentile ranks and peer comparisons, quick links to each delegate’s forum contributions, and so on. Here’s the demo link

This would be how we envision our UI coexisting with Tally’s (and potentially other tools) while staying aligned on score data and delegate “status”. Tally would remains the place to delegate and vote, displaying the score as a badge with a tooltip that lists the formula reference and timestamp. Curia reads the same endpoint, mirrors the badge for consistency, and overlays the richer context. Every delegate page on Curia will feature a Stake on Tally button that jumps users straight back to the staking flow, and Tally can, if useful, link out to Curia for deeper analytics. Because both interfaces pull the identical payload from a version-pinned oracle, there’s no risk of drift - any version update shows up everywhere only after governance approval.

One source of truth, multiple complementary lenses: Tally for actions, Curia (or other tools) for insight and seamlessly linked so users never lose context.

[enti]

The following reflects the views of @vista ₊˚⊹

1. Too soon to compensate anyone

We said this with the proposal to introduce staking, and will say it again here.

With only 3 OIPs so far, designing and deploying such a heavy and expensive governance structure makes no sense, at all. This all seems like we’re moving towards a culture where things are done for the sake of doing them, instead of reacting to actual needs.

A version of this proposal will likely be implemented anyways given how things seem to have worked in the past, and there’s strong incentives for the delegates to vote in support of this. But we encourage everyone to think long term.

That said, let’s address some of the things in the proposal itself:

2. Incentives and structure

@coolhorsegirl

• 165,000 OBOL tokens (equivalent to 10% of the global staking rewards pool for the first 6 months of staking) from a separate delegate reward pool (independent of staking rewards) would be distributed to active delegates, proportional to their voting power.

This represents a 90-10 distribution between stakers and delegates. Stakers being those who already are hold the token and are naturally incentivized to contribute (even without the staking component), and delegates being the ones who have to proactively work for the collective and on behalf of the delegators and token holders.

How does that make sense? It’s known that we’re not fans of hollow token staking, but at the very minimum the system should reflect the pressing needs and what’s valued, and saying we value parking a token in a contract vs folks committing resources to bring more value to the project is discouraging.

And then, 165,000 tokens at the current market price is ~36K. At 65,000 for this, we’re paying almost double for the development of the feature?

3. Development and costs

We were not expecting this proposal to come with associated costs, or at least not of this size. When reading this section below (and many other comments in the thread) from OIP#1 Building and Enabling Staking for the OBOL Token it doesn’t suggest that new features would have costs associated.

@coolhorsegirl

Other rules about staking rewards eligibility can be defined in future proposals, such as:

• Delegates could be eligible for a portion of the staking rewards based on how much voting power is delegated to them. This would ensure Active Delegates get paid for participating in governance.
• Token Holders could only be eligible for rewards if they are delegating to an Active Delegate. This proposal does not consider the definition of active delegate but the feature is available in the Staking contract, therefore it can be turned on in the future if Governance defines and approves it.

It’s hard to asses this given what the Association paid was not disclosed, but it’s not a good look that we were sold the staking contract as the unlocker for everything else, where in reality we have to keep paying to add things. I’m frankly disappointed.

On another hand, it’s not clear to me what’s the need to develop smart contracts for this. For the same price, and even less we could get ourselves, @Curia or any other to do a frontend that display metrics or even something as simple as a script that anyone can run and verify, then have a few folks on a committee execute a single transaction quarterly with the compensation.

If Tally wants this developed as part of their governance offerings, they should develop this themselves and at much offer Obol and other DAOs a more reasonable and productivized package, instead of asking us to cover for it as if it was a request and tailor-made solution.

4. Suggestions

If there’s demand from the collective to study and evaluate delegate compensation, we at Vista would be more than happy to come up with an extensive analysis and recommendations on governance updates based on historical data and needs, and welcome the participation from others.

For now we can’t see a way to justify the costs associated with this proposal, but happy to hear more from other delegates and the team at Tally.

[stefa2k]

Anaylsis

I agree with @enti entirely, well done response. To add to this, see my comments below.

@enti

And then, 165,000 tokens at the current market price is ~36K. At 65,000 for this, we’re paying almost double for the development of the feature?

This 165 000 token is for 6 months. But I agree, this seems like a bad cost benefit factor.

@enti

I’m frankly disappointed.

Me too, in more than one way.

@enti

If Tally wants this developed as part of their governance offerings, they should develop this themselves and at much offer Obol and other DAOs a more reasonable and productivized package, instead of asking us to cover for it as if it was a request and tailor-made solution.

I’d suggest an open call for a grant specifically for this. I outlined this already in my analysis on OIP3:

@stefa2k

Grants should be geared toward a goal; they shouldn’t be a goal itself.

@enti

If there’s demand from the collective to study and evaluate delegate compensation, we at Vista would be more than happy to come up with an extensive analysis and recommendations on governance updates based on historical data and needs, and welcome the participation from others.

This is how it should be done.

Other thoughts:

• Adding additional token to be unlocked will increase the selling pressure. Right now, the token price is not able to bear with additional inflation.
• We have a good amount of well-behaved delegates in here and I’d rather have us work without compensation for some time until we can actually reflect on how things should be rewarded (and having data on how things go) than having a system in place that I’m not happy with.
• There is nothing in this proposal to prevent farming. Big players will be rewarded more even if they just play the system with minimal efforts.

[coolhorsegirl]

Thanks so much @enti and @stefa2k for taking the time to share your thoughts. I want to offer a few clarifications and reflections to make sure intentions and context are fully visible.

1. On “Is it too soon?”

We understand why this may feel premature. It’s true that we’ve only seen 3 OIPs so far, and yes — this proposal is part of a broader structural effort. But that’s exactly the intent: we want to lay strong foundations now that support long-term governance health, rather than reacting in urgency 6 months from now if engagement starts to decay. This proposal directly supports the 2025 roadmap approved in OIP#3, including:

• maintaining sustained delegate participation,
• linking staking and governance more tightly,
• and reinforcing decentralized decision-making capacity early in the DAO’s lifecycle.

We believe this is about being strategic not procedural, building a base that scales, not an overcomplication.

2. On Incentives and Allocation Fairness

The 90/10 split was not chosen arbitrarily. It’s a first step, and up for discussion. The 165,000 OBOL proposed is a dedicated delegate reward pool, separate from the staker incentives, and can be adjusted in future cycles. We’re actively open to alternative ratios and if you have a number in mind that you feel better reflects what we should be valuing, we’d love to hear it. Crucially, staking rewards are now contingent on active delegation. That means tokenholders must delegate to “active” delegates (as defined by the DRS) in order to earn rewards shifting incentives toward real participation, not passive token parking.

3. On Costs vs Value

I urge delegates to think about this proposal as foundational tooling for Obol’s staking and governance system rather than a one-off spend. The contracts, UI, and DRS logic are designed to be reused and extended over time, supporting long-term participation and operational clarity across future cycles.

4. Why not just use scripts or a committee?

That’s totally valid as an option, and we explored it. But we chose to pursue a more native integration into Tally, because:

• It’s the canonical platform for staking and voting,
• Delegates already use it daily,
• And it ensures clarity, consistency, and trust in eligibility and distribution logic.

Manual systems (e.g. off-chain scripts + multisig) are harder to audit, scale poorly, and often lead to governance fatigue or mistakes down the line. We’re aiming for long-term credibility.

5. Farming Risk & Influence Concentration

We fully share this concern and the DRS is intentionally designed to mitigate these risks:

• It’s not about voting volume alone.
• It incorporates early participation, forum activity, and cross-cycle consistency.
• A “big but passive” delegate will not pass the eligibility threshold.

That said, we’re calling this a v1. If farming or low-quality activity emerges, we’re open to:

• Minimum delegation thresholds,
• Sybil resistance layers,
• Or even rotating review panels.

The goal is not to reward whales it’s to incentivize active stewards of the protocol.

6. Final Thoughts

We completely understand the instinct to be cautious with compensation and complexity. But we hope it’s clear that this is:

• not about inflating systems,
• not about rewarding incumbents,
• but rather about building transparent, accountable infrastructure that scales.

We’re happy to treat this as a pilot. If it’s not working after 6 months we revisit it. But getting the feedback loop in place now sets us up to respond faster and better later.And finally: would welcome Vista’s contribution to a broader governance design or compensation model review. That would be incredibly valuable and fully aligned with what this system is meant to support.

[zwanzger.eth]

First of all, I like seeing this proposal is already discussed and critically reviewed
As of now, I am somewhere in between supporting the proposal and the criticism stated above:

1. Generally it is a good idea to compensate people that put effort into something, and I like the additional data points / transparency a lot, mainly for the stakers! I am sure it will motivate delegates to stay (more) on top of things, and take the guess work out of the delegation process. It would also make delegation process a lot easier and meaningful, and in turn also encourage people to (buy+)stake+delegate (and make it easy enough since we also threaten with removing their staking rewards if not participating actively or via delegate).

2. Timing: it might be a bit early with little data, but it is also good/vital to keep momentum early and define basic mechanics, to then refine later

3. Costs: while I cannot evaluate a proper price, these types of developments need to be paid, as we are early and building useful tools for decentralized governance. In that matter I’d believe whatever is used/developed should be open-source/shareable, and I’d appreciate insights into if/what % Arbitrum is contributing, as it seems they are also (planning to?) use such a system. Maybe sharing of costs would help.
   Arguing costs relative to the distributed delegate rewards does not make much sense imho, as development is one-off, while the other is of a recurring nature.

4. Incentives: I feel 10% of staking reward pools is a good starting ground, but ideally I’d want to see the compensation pool taken out of the staking rewards pool, as delegates are (also) serving other token holders. In this way, there would be no additional inflation for the markets to absorb. Might be difficult to achieve in this first round with staking rewards already set, but could be the agreed goal for the future.

5. Other specific feedback/considersations I’d like to see included:

• we should avoid centralization pressure on delegation, hence the “Top delegates” box on right side of Delegates screen should be carefully crafted. Likely the value/lines here should be based on DRS rather than size? Even though when looking to delegate I’d probably would look at a combination of the two to achieve maximum impact.
• I generally like the different aspects included into the DRS formula! One thing I’d change is remove " Voting Impact Score" maybe, as I understand the delegate rewards are proportional to % of delegations already? What I would like to see is some factor regarding number of delegations (=users delegating to delegate; in the spirit of “quadratic funding”), even though I am not sure if that should go into DRS or rather the reward allocation formula.
• Generally the formula might be a bit too complex to start? But if we keep it that way in principle, I’d put a bit more emphasis on forum and Voting Threshold scores vs Participation rate, to reflect the amount of work that goes into each.
• What happens to the delegations to non-active delegates, I understand they would not receive rewards (or partial?)? Do the proper delegations in consequence receive more rewards (might prevent them from banging the drum for participation), or would they go back to the treasury? Also not sure if possible but would be great to inform stakers in case their delegate has become non-active via Tally message (or Forum; at least opt-in notification).

Let’s build this in an awesome way for others to take notice and to reuse!

[zwanzger.eth]

This reaction was not part of my review here, as written in parallel. But I feel my points raised remain the same, even though it is good to see some principal alignment between the different people.

[zwanzger.eth]

I like the Curia data and demo - not sure if this level of detail will be needed or used much though. But thanks for sharing and engaging!

[dgusakov]

Thanks for the proposal!

In general, I find the proposal useful for Obol Collective governance. However, I have several concerns:

@coolhorsegirl

165,000 OBOL tokens (equivalent to 10% of the global staking rewards pool for the first 6 months of staking) from a separate delegate reward pool (independent of staking rewards) would be distributed to active delegates, proportional to their voting power.

The fact that incentives are proportional to voting power might encourage voting power centralization. I’m not sure if this is a desired outcome. A possible solution here is to introduce a non-linear proportion where the amount of incentives is calculated proportionally to the square root of the voting power.

@coolhorsegirl

In addition to incorporating DRS into staking and delegation flows, the Obol Collective is also exploring the integration of DRS into the governance forum. This would enable delegates to link their forum accounts to their on-chain delegate identities and publicly display their DRS alongside their posts and comments.

It might be challenging to accurately assess forum participation. Hence, I propose to reduce the weight of this aspect to 10% in favour of basic vote participation since I find basic vote participation crucial for actual governance.

[enti]

@coolhorsegirl

• maintaining sustained delegate participation,
• linking staking and governance more tightly,
• and reinforcing decentralized decision-making capacity early in the DAO’s lifecycle.

Why would pouring money into governance make any of these better? As far as I’m concerned delegate participation has not been an issue so far, and there’s no signs that it will be in the near to medium term.

Looks like a solution to a problem that does not exist for us.

@coolhorsegirl

separate from the staker incentives

This is confusing, is the funding for delegates coming from the 0.33% of supply approved in OIP#1?

In general, delegates can spend a big amount of their weekly time to a project (this also depends on how the governance is structured). Hence they should be compensated accordingly. My gut says it should be >= 70% delegate, and the rest for the staker.

But it’s very hard to come up with a reasonable ratio and projections given the workload and needs are unknown. And this is essentially why is a very premature proposal.

@coolhorsegirl

I urge delegates to think about this proposal as foundational tooling for Obol’s staking and governance system rather than a one-off spend. The contracts, UI, and DRS logic are designed to be reused and extended over time, supporting long-term participation and operational clarity across future cycles.

What other DAOs utilize a similar infrastructure for delegate compensation? As far as I know the organizations the Obol Collective looks up to did not need any of this to make sound incentive programs. This is literally a single transaction every month or transfer, and information that can be collected in a few lines of python code or similar.

@coolhorsegirl

Manual systems (e.g. off-chain scripts + multisig) are harder to audit, scale poorly

There’s no need to scale a delegate incentivization program. A handful of good delegates is multiple times better than thousands of them (from both effectiveness and cost).

Auditability is also not complicated at all? You either voted/participated or not. I’d also argue is easier for anyone to read SQL on Dune or Python on a Notebook than Solidity.

@coolhorsegirl

often lead to governance fatigue or mistakes down the line

Can you be examples of these governance fatigues or mistakes?

@coolhorsegirl

We fully share this concern and the DRS is intentionally designed to mitigate these risks:

I’d be very curious to read more on the design of other incentive programs, their good and bad sides and why this DSR prevents the risks you mention. It sounds a bit complicated to me, and I’ve seen simpler ones give very good results (like Lido’s, for example).

@zwanzger.eth

it might be a bit early with little data, but it is also good/vital to keep momentum early and define basic mechanics, to then refine later

I disagree, especially when it has to do with incentives. Obol needs to make sure it attracts folks that are really interested in the project, not those who come because there’s early incentives to take.

Throwing money at stuff has never, ever worked. Never.

@zwanzger.eth

Costs: while I cannot evaluate a proper price, these types of developments need to be paid, as we are early and building useful tools for decentralized governance. In that matter I’d believe whatever is used/developed should be open-source/shareable, and I’d appreciate insights into if/what % Arbitrum is contributing, as it seems they are also (planning to?) use such a system. Maybe sharing of costs would help.
Arguing costs relative to the distributed delegate rewards does not make much sense imho, as development is one-off, while the other is of a recurring nature.

I agree developments need to be paid, and if Arbitrum is also paying for this we should not pay full price, at all. Anyways, this development is not required to implement an incentive program if desired.

@zwanzger.eth

I feel 10% of staking reward pools is a good starting ground

I’m very curious to hear your rationale here. I don’t see how stakers are more productive than contributing delegates, and thus how such split is a better investment.

---

Agree with @dgusakov btw.

[zwanzger.eth]

@enti

@zwanzger.eth

I feel 10% of staking reward pools is a good starting ground

I’m very curious to hear your rationale here. I don’t see how stakers are more productive than contributing delegates, and thus how such split is a better investment.

My thinking was: The main benefit of staking should go to the token holders, and the “service provider” gets a fee - e.g. compare to Lido cost of 10% (5% to protocol, 5% to operators).

[enti]

You’re conflating things, this is my problem with token staking.

The protection mechanism of a L1 like Ethereum (which we call staking) to the distribution of new supply to a contract containing idle tokens (which we mistakenly call staking) is not the same.

Every single ETH issued is in reward of a very specific task (attestation, block proposal, sync committee, etc), and the stake is a disincentive to prevent agents sybiling the system and not completing their tasks or double signing. No work, no money. Attack and there’s a penalty.

All of these are key to the well-being of Ethereum. Not to mention they’re offset by the burning mechanism, but let’s leave that off the table assuming in this case it’s a lack of revenue from Obol for now.

What is so key for the well-functioning of the Obol Collective that token holders need to be paid for by parking their tokens on a contract? This is literally a Collective around Ethereum staking, we need to know our stuff better.

Governance is already protected by the linear relationship between # of tokens and voting power. The Association today still controls the token and contracts and will not enact a malicious proposal. And there’s no evidence that delegates require incentives to act on the well-being of the project.

If there’s ever a need to incentivize, or compensate delegates because it’s hard to reach quorum (like what happened in Lido), then delegates need a proper incentive structure (wether fixed or variable).

They’re the ones doing some sort of BD and crafting, voting and enacting proposals, token holders rip the benefits of those efforts already, why dilute the supply then?

Not coming at you, @zwanzger.eth. My previous experience in governance makes me be very insistent on the topic. After the Collective has run for some time Vista will do an exhaustive analysis to show why we say what we say.

[zwanzger.eth]

I hear you @enti, and appreciate your passion and a good discussion.
Your reasoning makes sense, however I think you might miss another important point: that staking is also a sink for token supply, or put differently a reason to hold the token and prevent token going to 0.
And hence in my view, the token holder put in their capital and delegates put in their effort - both needed, and one can discuss which is more valuable or should be rewarded more.
But my feeling is that at least in other areas of crypto and beyond, the capital is valued more (which I don’t necessarily like personally). I’d say the fact that we are amongst the first (to my knowledge) to implement DAO delegate rewards could be seen as supporting evidence?
And also the point was made that until now there wasn’t too much voting engagement needed could indicate that at least for now, the % of compensation should not be too high? But I would see potential to raise it in the future, and the decisions debated and decided early one arguably carry more weight than more routine matters down the line, so I am open to values between 10-50% of staking rewards (but ideally coming from same pool in order not to burn through treasury/create inflation).

[enti]

@zwanzger.eth

that staking is also a sink for token supply, or put differently a reason to hold the token and prevent token going to 0.

If the only reason folks hold something is because you pay them then it’s a signal of bigger issues and a question on the real need of a token.

Arbitrum invested an insane amount of time and resources to investigate this, and the results were not impressive. Moreover it has not even been implemented there yet… we’re just a smaller DAO being a guinea pig.

Anyways, I will not spend more time fighting staking, it’s already implemented. I’m coming now to the conclusion and angle that looking at delegate incentives as a function or share of stakers is a mistake. These are and require fundamentally different incentives and structures.

I’ll coordinate a call next week to discuss this for whoever wants to join, these decisions need more/better evaluation and processes.

[mmurthy]

gm! I’m Mahesh Murthy, founder of Karma. Thank you for considering us as a potential provider for scoring and DRS oracle system.

Over the past 3 years, we’ve built and are actively maintaining delegate reputation dashboards for Arbitrum, Compound, Moonbeam, SSV, EverClear and many other DAOs. You can find all of them here You can find all of them here.

We also built and currently manage Delegate Compensation tool for Arbitrum. We have also built the DRS oracle for Arbitrum and Rari DAO (both going live soon) to reward tokenholders.

Below are some of my thoughts on the proposal and the scoring logic:

1. In on our experience working with various DAOs, it’s best if scoring starts simple and gets iterated regularly (monthly or quarterly). The iterations and scoring changes should not go through governance vote everytime imho. Instead, a designated working group should have the authority to make changes quickly and refine the system.

2. We were first to integrate forum participation into delegate reputation scoring. Over the years, we have iterated on making it less gameable but now thanks to LLMs, it still gets gamed. I personally would not include forum scores in the tokenholder reward logic. This is because, the delegate score oracle writes scores to chain (to determine if delegate is active/inactive) on daily basis and it’s impossible to catch forum issues quickly. Also, the more complicated the scoring logic is, it’s harder to explain to tokenholders and could potentially result in lot of support/unhappy tokenholders.

3. Forum score should definitely be included in the delegate compensation because it is a strong signal of their contribution and also any issues can be caught and addressed before payouts happen.

4. I believe in the philosophy of crawl, walk, run. So, if the eventual goal is to have delegate compensation and tokenholder reward, it is better to get the system in place, start with reasonable amount and grow from there.

We’ve built and refined these systems across multiple leading DAOs, and we’d love the opportunity to bring that experience to Obol. Looking forward to collaborating and helping design a system that’s both robust and adaptable.

[Leo-ObolAssoc]

Thanks everyone who took the time to engage deeply with this proposal. I have read every post and I genuinely appreciate how thoughtful and constructive this thread has been. That level of engagement itself proves the strength of our early governance culture.

I want to take a moment to respond to the feedback in a structured way and share a bit more about the Association’s vision for what we’re trying to build together.

1. We’re here to stay.

This proposal isn’t a quick patch or a top-down push. It’s a long-term infrastructure investment and one we believe is necessary to make Obol governance sustainable as we grow.

We’re lucky to be launching this system early, while things are still relatively simple and before major coordination challenges emerge. Our aim is to start small, but build something that scales, modularly and iteratively.

2. Why now, if things are working?

I’ve seen the concern: “Do we even need delegate incentives yet?”

Fair question. Engagement is high now. But as @enti rightly noted, Arbitrum invested an immense amount of time and capital into understanding this after encountering the pain of under-incentivized, overburdened governance and decisions and execution bottlenecks. We’re trying to benefit from that hindsight.

Whether or not we’re currently seeing participation problems, the core principle remains: no one should have to work for free and especially not long-term. Yes, the TGE moment creates short-term energy. But adrenaline fades, and when it does, clear structures matter.

Let’s not wait for fatigue or apathy to creep in. Let’s build with foresight.

3. Reward split: why only 10% for delegates?

The 165,000 OBOL comes from a separate pool dedicated to rewarding active delegates during this pilot phase.

I absolutely agree that this ratio can evolve:

• In the future, rewards could and should come from the same pool as staking, with a fixed % redirected toward governance participation.
• Adjustments can be made through future OIPs or a designated working group that will be given the authority to make those changes.
• This system is modular by design, and we see the first 6 months as a testbed, not a final structure.

We welcome proposals to update the ratio, as long as they’re backed by data and community consensus.

4. Voting power vs influence: responding to @dgusakov

A concern was raised about the risk of rewarding delegates proportional to voting power, which could lead to centralization.

I agree this deserves consideration, and we plan to explore with Tally whether we can implement non-linear rewards using the square root of voting power. Here would be a simplified example:

Linear vs √Power Rewards

Delegate	Voting Power	Linear Reward	√Power Reward
A	100	55.5%	44.3%
B	50	27.7%	31.3%
C	30	16.6%	24.3%

This curve flattens the advantage of large delegates and better rewards smaller but engaged participants.

5. Clarifying the DRS and score structure

A few reminders and clarifications:

• Voting power is only 10% of the DRS. The rest is focused on:
  • Participation Rate
  • Voting impact (timeliness & weight)
  • Forum activity
• We’re considering a tweak to shift focus away from raw participation (which could be gamed) and toward meaningful engagement:
  • Drop Participation Rate from 55% → 50%
  • Increase Voting Impact Score to 15%
• We’ll keep the Forum Score at 20% for now, but we plan to share the full breakdown for transparency.
• This formula could be updated over time based on DAO feedback.

And importantly: ghost delegates won’t receive any rewards. If your delegation isn’t actively participating, rewards flow elsewhere (more rewards for the rest of stakers and delegates).

6. UI and delegation tooling

We plan to work with Tally to:

• Replace the “Top Delegates” box with one based on DRS, not raw voting power.
• Explore adding a Telegram bot or alert that notifies token holders if their delegate’s DRS falls below the active threshold.

These kinds of features help ensure better delegation hygiene, another layer of incentive alignment.

Final Thought

To be clear: this message is not meant to end the debate. We’d love to keep working with the community on this. It’s about coordination, not opposition.

This proposal is not about rewarding delegates for being delegates. It’s about incentivizing effort, recognizing quality, and building a culture of contribution that can scale.

[Ignas]

I’ll be frank: all DAOs struggle with voter apathy, concentration of voting power, and DAOs have become a source of funds for professional delegates to reap off.

The best the DAO could do at first, is to build a community of DAO delegates who understand how the protocol works.

However, delegation is a time consuming but important task. I think a payment for delegates is fair and the proposed budget is not big at all.

Those who say that the budget is big might underestimate the importance of a DAO. A strong DAO is your strongest community and a guardian of security. Remember how Compound DAO got attacked, just because delegates wouldn’t care to vote?

@enti

With only 3 OIPs so far, designing and deploying such a heavy and expensive governance structure makes no sense, at all.

But I believe that why now is the time to invest in building a solid foundation. If we wait until there are more proposals and more activity, it will be too late to onboard capable delegates and establish a reliable governance culture. We’ll be stuck playing catch up.

Tbh, most DAOs start very centralized (as team and foundation control the most VP). If we can speed up the decentralization from the start, it is a great decision.

And, incentives should not be distributed purely in proportion to voting power. Instead, we should design mechanisms that reward diverse opinions and meaningful contributions from delegates, this is how a healthy governance ecosystem grows.

[emjicy]

Hey gm fam, most know me by now, so here we go - in this post we’ll be looking clarify the long-term systems being encoded.

This assessment offers a constructive critique through the lens of the Oxcart Method (a legitimacy-first framework for decentralized governance) followed by actionable recommendations. We conclude with a forward-looking commitment to work directly with Tally, Karma, and Forse Analytics to help ground these systems in adaptive, composable legitimacy mechanisms.

This proposal rests on three implicit design assumptions:

1. Engagement decays without structured compensation.
2. Delegate legitimacy can be abstracted into a composite score.
3. Proportional rewards to voting power, bounded by DRS, reinforce rather than distort governance dynamics.

Each of these points presupposes a governance reality that may or may not yet exist. We recommend distinguishing clearly between retrospective response and prospective engineering. What is being proposed is not merely tooling it is a governance precedent .

The Oxcart Method frames governance as a dynamic field of trust flows , where legitimacy is earned, reconfigured, and visible across delegation chains. It emphasizes three key properties:

1. Legitimacy as a Function, Not a Title Compensation is a downstream effect of measured legitimacy , not a substitute for it. Prematurely attaching incentives to rigid scores risks freezing a dynamic trust ecosystem. Without time-sensitivity or feedback loops, this risks ossifying authority.
2. Delegated Power ≠ Legitimate Contribution Raw voting power is not a proxy for utility or stewardship. While the proposal wisely explores non-linear (e.g., √power) reward structures, further safeguards—such as trust-weighted delegation diversity and temporal engagement metrics—should be modeled.
3. Reputation Must Be Mutable A legitimate system accounts for legitimacy decay (inaction, misalignment) and replenishment (quality participation, responsiveness). DRS scoring must reflect present contributions, not accumulated reputational inertia.

Recommendations

To preserve governance legitimacy and adaptability, we suggest:

• Frame this as a legitimacy pilot , with a defined review window (e.g., 6 months) and intent to evaluate efficacy, participation shifts, and stakeholder perception.
• Modularize DRS architecture :
  • An on-chain active/inactive status oracle (binary eligibility)
  • A rich off-chain analytics layer visualizing:
    • Participation trendlines
    • Cross-cycle contribution decay
    • Peer benchmarking
    • Forum-linked accountability
• Reward delegated trust, not just size :
  • Incorporate metrics that weight delegator diversity or delegate entropy
  • Use engagement-weighted caps to mitigate whale behavior
• Build in legitimacy decay and thresholds from day one:
  • Create a decay function that scales down reputation in the absence of meaningful engagement
  • Ensure voting impact is time-sensitive and proportionally responsive
• Avoid over-rigidity in DRS formula evolution :
  • Empower a working group (not full DAO votes) to iterate the DRS logic
  • Ensure changes are transparent, versioned, and time-stamped

Collaborative Commitments

We at Oxcart intend to collaborate directly with Tally, Karma, and Forse Analytics to:

• Provide legitimacy modeling frameworks and simulations to support DRS evolution
• Explore ways to visualize cascading vote capital flows , enabling richer trust graphs for Obol’s governance
• Assist with designing non-linear reward curves and decay logic to preserve fairness and resistance to stagnation
• Align on how Forse Analytics dashboards can mirror the on-chain DRS status while surfacing nuanced, contextual delegate insights

We believe this proposal can become a milestone in DAO governance design if it remains adaptive, transparent, and rooted in legitimacy-first thinking** .

We submit this in the spirit of partnership and constructive iteration.

Respectfully,
– mel.eth

[zwanzger.eth]

Thanks @Leo-ObolAssoc for your well structured response, addressing most issues raised.
At least for the topics I raised, I see most addressed and are thankful for taking them into account!

@zwanzger.eth

Costs: while I cannot evaluate a proper price, these types of developments need to be paid, as we are early and building useful tools for decentralized governance. In that matter I’d believe whatever is used/developed should be open-source/shareable, and I’d appreciate insights into if/what % Arbitrum is contributing, as it seems they are also (planning to?) use such a system. Maybe sharing of costs would help.

This might be one aspect not yet addressed but might be simple, as at least AI query indicates that Tally systems are open source?

The other aspect potentially open was also mentioned by @emjicy

@emjicy

Incorporate metrics that weight delegator diversity or delegate entropy

Other than that, I am curious to see whether some of the early critics have been swayed be the context and modifications, and maybe see other chime in as well.
From my side, once some more feedback is gathered and incorporated this would be OK to go to vote, since it is meant to be a v1 of many future revisions.