OIP-4 Implementation Update #1 — Delegate Reputation Score (DRS) Details and Adjustments

General Discussions
1

As committed during the OIP-4 discussions and vote, we want to ensure that implementation remains transparent and accountable to the community. This post serves as the first public update on the implementation of OIP-4: Delegate Compensation and Delegate Reputation Score Integration for stOBOL.

We encourage all ongoing discussion to remain in the original OIP-4 thread to consolidate feedback and ensure context remains accessible. This post is strictly a factual update on how the proposal is being implemented, what has changed since the vote, and what the community can expect next.

We welcome input on this implementation, but to keep the discussion productive, we ask that feedback be:

  • Structured and justified — Please include the reasoning and/or data behind your concern.
  • Solution-oriented — If you raise a problem, we’d love to hear any ideas on how to address it.

We welcome feedback that helps improve the implementation, not to re-open a debate on whether OIP-4 should be enacted. That time has passed and OIP#4 was validated by vote.

Final Calculation Details

You can view the full formula and logic for the Delegate Reputation Score (DRS) here :backhand_index_pointing_right: DRS v1 Implementation Spec

Adjustments Since Vote

1. Scoring Period Adjustment

Originally, “active delegate” classification required a DRS ≥ 65 calculated over the past 3 governance cycles. We are making a small change and this now evaluates the average score over the last 5 proposals.

Why: This ensures the score reflects actual delegate behavior across real decisions, rather than an arbitrary time window. Since the number of proposals can vary significantly across cycles, using a fixed number of proposals offers more consistent evaluation.

2. Retroactive Bootstrapping

To avoid penalizing delegates for not anticipating scoring rules, the system will apply a simplified scoring logic retroactively to the five most recent proposals prior to DRS activation.

  • Each of these past proposals will carry a 20% weight.
  • If a delegate voted on 4 or more of the last 5 proposals, they will begin with a DRS of 80+ and qualify as active.
  • Starting from the next proposal, the full DRS formula kicks in. So progressively, the score will be based on 4 past + 1 new, then 3 past + 2 new, etc., until it’s entirely derived from live tracked behavior.

3. New Delegate Bootstrapping

New delegates should not need to wait five proposals to qualify and start to be compensated. For new entries:

  • The DRS is calculated over the number of proposals they were eligible to vote on.
  • If they’ve participated actively from their first eligible proposal, their DRS will be high enough to qualify immediately.
  • However, if early participation is poor, their score will drop quickly.

In UI: A visual tag will indicate delegates still within their “evaluation window” so token holders can assess their track record accordingly.

4. Update Cadence

The DRS will be updated once per governance cycle (every 3 weeks).

Why:

  • Allows complete view of voting impact, rationale submissions, and forum engagement across a full proposal lifecycle.
  • Prevents volatile mid-cycle updates and reduces delegation churn.
  • Promotes clearer decision-making by showing fully-formed scores.

Distribution Curve for Delegate Rewards - Request for Feedback

OIP#4 specified that once a delegate is classified as “active,” their share of rewards from the Delegate Rewards Pool would be proportional to the square root of their delegated voting power.

This approach was selected to:

  • Avoid hyper-concentration of rewards toward the largest delegates,
  • Support smaller delegates who maintain high DRS and act diligently,
  • Encourage a more pluralistic, non-linear distribution of influence.

However, following internal reviews and community conversations, some valid concerns were raised:

  • Square root-based distribution, while fairer in theory, may introduce attack vectors for Sybil behavior or farming incentives,
  • A linear distribution (1:1 with delegated VP) would be simpler and safer — but might overly reward the largest holders and discourage long-tail participation.

What we’re asking

We’re inviting you to share feedback on which model to adopt:

  • Should we keep the square root model, aiming for long-term fairness and decentralization, with a commitment to monitor and adjust if abuse occurs?
  • Or should we adopt a linear model from the beginning, prioritizing simplicity and minimizing Sybil risks?

This is a reversible decision (a “two-way door”) and can be updated later via governance. But since implementation will begin shortly, we’re asking for input by 2025-06-18T16:00:00Z .

Please respond in the OIP#4 thread with your thoughts. All feedback welcome.

Next Steps

We are now in the build and integration phase with Curia and Tally. Once live, the Association will monitor the system and assess:

  • If certain weightings (e.g. participation vs. rationale) need adjusting
  • If additional components should be integrated
  • If more granular or qualitative governance metrics should be introduced

We’ll report back regularly on progress and welcome suggestions from the community. We want to thank everyone again for the thoughtful feedback that shaped this design.

This phase is about building quality infrastructure together. Let’s keep the conversation focused, open, and collaborative.

6 Likes
3

Final Decision on Distribution Model

Following the feedback period and internal alignment, we’ve decided to move forward with the square root model for distributing compensations from the Delegate Rewards Pool. While we acknowledge concerns about potential Sybil incentives, we believe this model better reflects our long-term commitment to decentralization and support for high-performing smaller delegates. We will continue to monitor adoption and impact closely, and adjustments will be made based on feedback if needed.

3 Likes
4

OIP-4 Implementation Update #2 – Reward Gating Changes & What Comes Next

As part of our commitment to transparent governance and keeping the community informed, we are sharing an update on the ongoing implementation of OIP-4. This follows from Implementation Update #1 where we covered final changes to the Delegate Reputation Score (DRS) model and onboarding logic.

TL;DR – Key Changes at a Glance

According to the implementation schedule outlined below, most of what was proposed in OIP-4 is launching as planned, including the Delegate Reputation Score (DRS) system, which will help inform delegation decisions, and the delegate compensation mechanism, which remains gated by DRS and is set to go live shortly.

However, one important change had to be made: staking rewards will not be gated by DRS, due to technical and architectural limitations.

After deeper technical review, we realized that gating rewards isn’t compatible with maintaining stOBOL as a fully composable, yield-bearing token. We believe the benefits of a liquid, DeFi-compatible staking asset outweigh the drawbacks of removing this gating mechanism.

The current plan still delivers on the core incentives outlined in OIP-4, even if the scope is slightly reduced. We believe that with DRS live and delegate compensation tied to it, we already have a meaningful framework in place to encourage good governance behavior and signal quality to token holders.

For now, we feel comfortable keeping things as they are. The structure is sound, and the incentives are aligned. If in the future we determine that an additional mechanism is needed to further reinforce governance alignment (for example, introducing a form of gating or signaling tied to DRS), we’re open to that discussion. Any change would of course go through the proper governance process, including open discussion and a formal vote.

But today, we believe the priority is to focus on growing the protocol with the Collective, leveraging the strong foundations we’ve already put in place.

What’s Next – Launch Timeline & Collective Participation

Here’s what you can expect:

  • Week of July 28:
    • DRS scoring will launch publicly on Tally and Curia
    • No rewards or delegation mechanics will be affected (for now)
  • Week of August 18:
    • Launch of Delegate Compensation, gated by DRS
      • Active delegates will be eligible to receive a share of the Delegate Rewards Pool

We’ll also share additional communication, guides, and a live AMA to help everyone understand what’s changing and why it matters.

1. No Gating of Staking Rewards via DRS – Why This Changed

Originally, the plan was to gate staking rewards behind the DRS system, meaning that only token holders who delegated to “active” delegates (those maintaining a DRS ≥ 65) would earn staking rewards.

After final implementation reviews with engineering and product partners, we came to an important realization:
While a single staking token (stOBOL) by itself does not currently enable gating of staking rewards without affecting DeFi utility and liquid staking composability, it is technically feasible to gate additional rewards using the autodelegate strategy, where stakers can receive supplementary rewards based on their delegate’s minimum DRS score.

To enforce reward eligibility at the contract level would require each staking position to be uniquely tied to a delegate’s DRS status. On the other end, keeping stOBOL yield-bearing by default makes it more attractive to hold, use in DeFi, and build with. This composability is key to unlocking integrations. The ability for stakers to earn yield regardless of delegation status is a feature, not a bug. Ultimately, this shift strengthens stOBOL as a utility token and helps bootstrap a more vibrant onchain economy for the Obol Collective.

We believe that this upside far outweighs the potential benefits of gating staking rewards by delegate behavior. And as you’ll see below, we’re not losing the governance signal but redirecting it in a more scalable, trustless way.

Instead of compromising on composability and liquidity, we’re choosing a more resilient and future-aligned path:

  • stOBOL remains fully fungible and yield-bearing by default
  • It encourages broader participation in staking and DeFi
  • No staking rewards gating via DRS
  • But… DRS will remain a core reputational and visibility system that incentivizes good delegate behavior and influences how delegations flow.

2. What Role Does DRS Still Play?

Even without direct gating of rewards, DRS still provides meaningful incentives:

  • Delegate Compensation will still be gated by DRS: only active delegates (DRS ≥ 65) will be eligible.
  • DRS remains critical for delegate visibility and influence
  • Delegations will still trend toward high-DRS delegates
    • DRS will be visible to stakers to inform better delegation choices
  • Token holders will be nudged in the UI toward active delegates

DRS is still a powerful mechanism to reward responsibility, signal trustworthiness, and help the collective grow with aligned governance.

3. Additional Implementation Notes

While the updates above reflect the most significant shifts in our launch scope and strategy, we also want to acknowledge two smaller (but important) implementation decisions that have been finalized:

Delegates Compensation Distribution — Square Root Model Confirmed

Following the discussion period, we’ve decided to stick true to the initial proposal and to move forward with the square root model to distribute compensations from the Delegate Rewards Pool.
This means that once a delegate is classified as active (DRS ≥ 65), their share of the pool will be calculated proportionally to the square root of their delegated voting power.
This model helps:

  • Support smaller but high-performing delegates
  • Prevent reward monopolization by a few large players
  • Encourage a healthier and more distributed governance system

While we’ll keep monitoring for edge cases or unexpected abuse, we believe this model strikes a good balance between fairness and decentralization.

DRS Oracle Update Timing Aligned to Governance Cycle

We’ve aligned with Curia on a consistent schedule for publishing on-chain DRS updates via the oracle. This will ensure transparency and predictability in score calculations.
Here’s how it works:

  • Oracle updates will occur 6 days after the end of the submission window in each 21-day governance cycle.
  • This buffer ensures that all proposals, even those submitted at the very end of the window, have their full 5-day voting period completed before scores are finalized.
  • For example: if the submission window ends on June 18, the corresponding DRS oracle update will be pushed on June 24.

This cadence will be used going forward to avoid discrepancies and ensure accurate scoring across all eligible proposals in each cycle.

9 Likes
6

Hi @Obol-Association team,

Thanks for this second implementation update — the clarity and continued transparency are appreciated.

That said, I’d like to highlight an important governance point:

These Changes Merit a New Vote

While it’s great to see the proposal evolving through implementation feedback, the combination of changes introduced in Update #1 and this latest post diverges significantly from the original OIP‑4 that was voted on.

Specifically:

  • The DRS calculation methodology has undergone substantial change (e.g., scoring window structure, evaluation period for new delegates, cadence of updates).
  • Other minor, yet valuable additions like Retroactive Bootstrapping and Update Cadence.

These are core elements of the system and materially impact delegate incentives and governance dynamics.

Suggestion 1: Re-ballot the Updated OIP‑4

To ensure legitimacy and community alignment, I recommend putting the updated proposal — as it stands now — up for a fresh vote.

This would:

  • Provide clarity and confidence that the community supports the current implementation path.
  • Avoid future friction around “mandate drift” from the originally approved design.
  • Establish a precedent for major post‑vote adjustments being brought back to token holders.

Again, I appreciate all the work that’s gone into this process — and the intention to balance fairness, Sybil resistance, and usability. I just believe these shifts merit renewed community consent before full rollout.

Suggestion 2: Improve the proposals preparation process

While it is clear that some tech-specific details can inevitably occur during the implementation process, it looks reasonable to do a lightweight tech assessment of the proposals before putting them to the vote to avoid numerous updates to the already ratified proposals.

That said, I propose:
Establish a clear tech viability assessment stage during proposal discussions. The core Obol team can do this. In case of meaningful community disputes, external volunteers can be involved.

  • Put the proposals to the vote only after tech viability analysis and adjustments.

This reduces friction and the necessity to make changes to the previously ratified proposals.

Looking forward to the next steps!

4 Likes
7

I agree.

I also would love to see both suggestions of @dgusakov coming to life.

2 Likes
8

There are both advantages and drawbacks to auto-delegation, so I agree that this represents a significant change to the process. For that reason, I’m not opposed to holding an additional vote on the matter.

However, I would also like to clarify a few technical details:

  1. It would be helpful to conduct a preliminary evaluation now — perhaps Karma (or whoever is responsible for assessments) could calculate the current standing of delegates and show a simulation of how voting power would be distributed under the proposed model.

  2. The specific number of delegates to receive auto-delegation has not been stated.
    Uniswap has a similar system — they started with 10 delegates and gradually increased that number, which I believe is the right approach. Otherwise, the process risks becoming overly centralized.
    Some clarification on this point would be appreciated

2 Likes
9

Hey everyone – just a quick message to inform you that we’ve edited Implementation Update #2 to reflect the current scope and plans.

  1. The scope of OIP-4 remains almost entirely intact. Nearly everything outlined in the proposal will be launching over the next few weeks. The only adjustment is that staking rewards will not be gated via DRS, due to unavoidable technical blockers. We’ve updated the post to explain why this change was necessary and how it still fits within the intent of OIP-4.
  2. We’ve removed the section on reworking the Autodelegate strategy. After receiving community feedback and internal discussion, we believe this topic deserves its own focused debate and shouldn’t be bundled into the OIP-4 implementation update. While it’s an important conversation, it was never formally part of the original scope.

We’re now transitioning from the implementation phase to activation:

  • DRS will go live next week
  • Delegate compensation (by DRS) is launching next
  • Delegations and incentives are increasingly aligned with real governance contribution

With that foundation in place, we strongly suggest we take the time to monitor the system, evaluate what’s working, and resist the urge to tinker too early or too often. Constant tweaks, even if well-intentioned, could lead to governance fatigue and distract us from the broader goal: growing the protocol and the Collective together.

We’ll share more on that long-term vision in the upcoming Association AMA (details soon), but for now, let’s zoom out, celebrate the progress, and focus our Collective’s energy on growing Obol in the months ahead.

I encourage everyone to read the updated above post in which you will find our detailed reasonning and intentions for all the mentioned points.

9 Likes
10

100%, new vote required to crystallize these adjustments.

1 Like
12

This feels like a pragmatic and strong path forward. Protecting stOBOL’s utility in DeFi is absolutely the right long-term play

13

I agree we could do with a vote

3 Likes