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

Token House
43

Hey @cp0x, I think there may be some confusion between Tally Staker and the two staking enhancements outlined in this proposal: Delegate Compensation and DRS Integration.

Tally Staker - which also has plans to be enabled for Rari and Arbitrum - has already been deployed for Obol as a result of OIP#1: Building and Enabling Staking for the Obol Collective.

This proposal is in reference to two separate enhancements that would be custom-built for Obol, which have not been built for Arbitrum Rari, or any other DAO. We don’t have existing code for these two enhancements and would begin development once funding is approved.

2 Likes
44

I just caught up with the latest developments and I am happy to see all the ideas brought forward AND incorporated! Nice work as a collective!
For what it is worth: I am an Obol Delegate with sufficient voting power, and I believe this proposal is ready to move to a vote - and I’ll vote YES!

2 Likes
45

Vote

Decision

Against

Reasoning

I love the idea and discussions around this topic seem reasonable and fruitful.

However, I don’t think this is ready to agree with:

  1. The mentioned pricing seems inflated.

  2. It’s too early. OBOL delegates seem active in the forum and voting, and most are bringing in a lot of value to discussions around the DAO’s future and development.

  3. As far as I know @coolhorsegirl is part of tally and therefore has a conflict of interest that wasn’t layed out on the proposal.

  4. I don’t see any meaningful farming prevention.

That said, the terms on how delegates should be compensated are discussable, e.g. score system, amounts, etc. and seem already somewhat reasonable to me.

2 Likes
46

I’d like to directly address point 3, as I take any suggestion of a conflict of interest seriously.

To clarify: I posted this proposal as a representative of Tally. This is consistent with the norms across DAOs, where delegates often post proposals on behalf of the organizations they represent. I believe the context and content of the proposal itself make clear that it is a Tally initiative. From the proposal above (2nd line under “Motivation”):

To realize this vision, Tally proposes to align incentives around meaningful participation in governance.

The proposal also followed the Obol Collective standard governance process, securing approval from at least four of the top 100 Obol delegates (excluding myself, of course) before progressing to an onchain vote. It was ultimately put onchain by StableLab, an independent party.

2 Likes
47

All this said, I appreciate the feedback and will make sure to clearly state that I’m an employee of Tally in any future Tally-related proposals. Thank you! @stefa2k

2 Likes
48 
Vote:  Against

Rationale:

1 Like
49

Hi, I’m Raf, CTO of Tally.

Happy to provide more background on the scope and costs here. Our goal is to ship polished and secure product. This proposal’s budget was set up for that goal. Here’s more about the main drivers of the costs:

  1. The smart contract changes are not trivial. This change involves implementing a new earning power calculator (staker/src/calculators at main · withtally/staker · GitHub). Because this is a live system with money flowing through it, we want to make sure the devs have bandwidth to write a full test suite, simulate the new staking system, and handle potential oracle failure modes.The smart contract development scope also includes configuring and deploying this new earning power calculator, integrating it with the oracle, then making the DAO proposal to migrate to the new one.

  2. We take security seriously. The $20k audit budget is intended to allow the Association flexibility to have more than one audit if desired. Any unused audit budget would be returned to the Obol treasury.

  3. The app integration scope includes bespoke customizations to Tally’s delegate pages. These changes will require both frontend and backend work:backend integration with the scoring provider, new sorting features on the delegates page frontend customization of the scoring system new UI and web3 calls for delegates to claim their rewards. These are new features, not the existing ones built for Arbitrum, Rari or any other staking system.

  4. The proposal intentionally starts with relatively small incentives. Obol governance can always increase them later, once the incentives and their effect on behavior is better understood

2 Likes
50

Thank you for the detailed discussion and thoughtful suggestions, especially the focus on long-term sustainability of governance. I appreciate the effort that has gone into developing this initiative and the transparency with which it has been presented.

That said, I oppose this proposal at this stage and have already voiced my position in the Tally vote. My view is that other areas of the Obol protocol that can provide more immediate benefit to the ecosystem should be prioritized at this stage.

Delegates already receive a percentage of their stake, which I believe sufficiently covers the costs of participating in voting. Introducing additional incentives would likely not significantly increase participation, as the community has already demonstrated a high level of interest in the protocol’s development.

I propose to defer consideration of this proposal until more data is available on participation dynamics and specific governance issues. This will allow us to develop a more targeted system if one is found to be necessary. I am open to further discussion and consideration of alternative approaches that may better balance the costs and benefits for the Obol collective.

51

Thanks for taking the time to share your thoughts and for voting transparently. We appreciate the respectful tone and your focus on long-term sustainability. I’d like to clarify a few things that may have been misunderstood and offer some broader context.

“Delegates already receive a percentage of their stake…”

Just to clarify: delegates currently receive no additional staking rewards or incentives beyond what any tokenholder would get by self-staking. Currently, delegating only transfer (in the form of a loan) voting powers, but the token hodler still earn all the rewards. The mechanism proposed here introduces, for the first time, a direct reward stream tied to governance participation, measured through the Delegate Reputation Score (DRS). It’s a system designed to reward those who consistently show up, vote meaningfully, and contribute to the ecosystem’s growth as apposed to simply holding tokens.

“Incentives would likely not significantly increase participation…”

We understand this concern, and we’re not suggesting that incentives alone will solve all participation issues. What this system does is align tokenholder incentives with active delegation, making it more likely that governance power flows toward high-quality contributors rather than idle whales. And even if participation is healthy today, our goal is to ensure it’s sustainable and resilient over time.

On that note: we’ve already observed signs of governance risk emerging, including a large token acquisition and vote by a new participant with no delegate profile, no forum presence, and no prior voting history. This is a textbook example of a “governance sniping” or “vote-buying” attack where someone appears late in the process and influences outcomes without prior involvement or accountability.

This instance might change the outcome of this vote already and is a wake-up call. The proposed system helps mitigate this by:

  • Requiring sustained engagement to maintain a high DRS
  • Making staking rewards contingent on delegating to active delegates
  • Reducing the attractiveness of low-engagement delegates for those seeking to delegate

We’ve said from the beginning: this isn’t just about “rewards”, it’s about building strong, flexible foundations for governance before problems become systemic. We’re not trying to replicate mistakes seen in other DAOs. We’re still early, which gives us the agility to do this right and not when we’re forced to react under pressure.

We’re here to stay, and we’re aiming high. But no building can reach the sky without strong foundations.

Happy to continue the conversation and appreciate your engagement either way.

2 Likes
52

I was very surprised that this was the first priority after launch.
Like others, I have noticed the high cost of development. Perhaps this is a surcharge for speed.
The idea itself is good. But I assumed that in the next 6 months there would be completely different tasks.

1 Like
53

The following reflects the views of L2BEAT’s governance team, composed of @kaereste, Sinkas, and Manugotsuka, and it’s based on their combined research, fact-checking, and ideation.

First, we would like to thank @coolhorsegirl and the entire Tally team for initiating this discussion and driving innovation in governance systems.

We are voting FOR this proposal. However, to some extent, we acknowledge and agree with the voices in this thread that have expressed concern. We recommend that the Tally team and the Obol Association put extra effort into reporting and transparency for this initiative.

While we agree that the issues that this proposal addresses are not necessarily present yet in the Obol Collective, we’re seeing them all over the place in the DAOs we’re active in, and it is reasonable to assume that they will surface in Obol as well sooner or later. The most common issues we’re seeing are voter apathy, problems with reaching quorum, and a lack of feedback from top delegates. At some point, it’s becoming almost impossible for any proposal to pass unless someone who has a direct link with top stakeholders facilitates alignment and mobilizes delegates to cast votes.

We’ve spent a lot of time with the Tally team discussing their model of tying staking rewards to delegate responsibilities, and we consider it a worthwhile experiment for improving meaningful delegate activity. However, we’d like to point out that the proposed DRS model should be treated as a rather basic MVP that optimizes voting participation only; it might need a much more nuanced (probably even subjective) approach in the future.

Regarding the cost, we understand the concerns about the scope and pricing of this proposal. With the information currently available, we believe it’s impossible to form an opinion on the price offered. On the other hand, we don’t believe publicly negotiating the exact scope and price is the most effective approach. We recommend treating this amount as the maximum budget available for this development. We advise Tally to work closely with the Obol Association in an agile, time-and-materials-based way to ensure this budget is utilized as effectively as possible. Any remaining funds should either be returned to the Collective or used to develop additional scope.

That said, we would like to point out that this will likely not be the last grant request for software development presented to the collective. Software development is an ongoing, never-ending process, and the downside of using niche software for operational purposes is that additional funding is needed over time to maintain and expand it.

However, if we believe that the DAO is set to support Obol protocol for years to come, it makes sense to invest in operational software that will help with optimizing operational efforts. And that’s how we see this initiative to tie certain delegate responsibilities (which can be changing with time) to staking and delegate rewards.

With that in mind, we would like to reiterate that it is crucial for the DAO and the Obol Association to establish a cooperation model with software providers that ensures effective usage of DAO funds and minimizes concerns about extractive behavior and misuse of funds.

4 Likes
54

The FranklinDAO Team will be voting against this proposal. We believe a delegate compensation program is premature given only a few governance proposals so far. We believe there is no immediate/short term problem yet to solve - we agree that this should revisited in the future. As delegates in Arbitrum, we’ve seen how Arbitrum’s delegate incentive program has been slightly gamed and led to increased misaligned participation, and don’t want Obol to fall into the same system.

1 Like
55

Thank you for your openness

  1. I looked closely at the new code that you plan to implement and I also remained with my opinion - these are very small changes for the proposed funds.
    Well, really, if we do not take into account all the Events and variable definitions that come at the beginning, then this is 200 lines of code, taking into account the second file - 250. So I am still inclined to consider this a very inflated cost. I understand that in crypto, everyone is accustomed to hundreds of thousands of dollars for various needs, but all costs must be adequate
  2. Regarding the audit, it is good that you offered to return part of the funds, but this point is not in the proposal for which the vote is being held
  3. Regarding the backend and frontend - I understand that this needs to be done, but the proposal only talked about the frontend, perhaps it was implied that the backend was initially implemented taking into account the future change, in fact, it is only necessary to add one parameter to the database
    Secondly, the front for a similar task has already been implemented, for example, for Arbitrum, i.e. you will not do it from scratch
  4. A good argument that this is only the beginning of incentives, but I also spoke not only about the current implementation and its cost - these are one-time costs, but also for the support of the data operator, such as Karma or Curia
1 Like
56

Good day, @kaereste
I see that you wrote that it is impossible to understand the cost of the work based on the data provided. In various DAOs, I always value your opinion

Please tell me, what data is needed besides a detailed description of the functions and the code provided on GitHub?

57

We’re voting FOR OIP-4.

At kpk, we view this proposal as a thoughtful and well-structured approach to incentivizing delegate engagement while maintaining transparency and accountability. The integration of the Delegate Reputation Score (DRS) and the use of a voting power curve are commendable steps toward reducing centralization and promoting active participation.

We appreciate the community’s extensive feedback and the proposers’ responsiveness in refining the proposal. The adjustments, such as shortening the DRS lookback window to 63 days and incorporating multiple weighted components into the DRS formula, demonstrate a commitment to adaptability and continuous improvement.

As @Stakesaurus aptly noted, “We should explore and implement delegate incentivisation today, while we have high participation rates from organic delegates.” This proactive approach ensures that we retain high-quality contributors before apathy sets in.

However, we acknowledge concerns raised by @Jose_StableLab regarding the funding model and metric design. Specifically, the suggestion to merge “Number of Votes” and “Participation Rate” into a single normalized metric could simplify the system and reduce redundancy. Additionally, incorporating “Delegate Rationales” as a scoring component would reinforce transparency and support informed delegation decisions.

We also recognize the importance of cost-effectiveness. As @0xobol highlighted, “Pay delegates, not rent.” Ensuring that the collective’s funds are utilized efficiently is crucial.

We see this pilot as a foundational step toward a more professionalized and accountable governance structure. We look forward to collaborating on future iterations based on the insights and data gathered during this pilot phase.

Thank you to all contributors for advancing this important initiative.

2 Likes
58

:loudspeaker: Implementation Update

We’ve just published a dedicated Delegate Reputation Score (DRS) Implementation Update covering how OIP#4 is being translated into practice.

This post includes:

  • Final details on how the DRS will be calculated
  • Adjustments made since the vote
  • An open question around how to distribute delegate rewards (linear vs square root)

We’ll use that thread to transparently document the process and share future implementation updates — but we ask to keep broader discussion and feedback going here.