Sorry, I seemed to have missed this, as I am mainly active and reading only on this forum… But from the link you provided, you seemed to have developed this Oxcart Method yourself some time ago.
It certainly uses a lot of impressive language, that I admit I have to digest a bit.
From what I understand so far, most of it seems to make sense to me and reflect the current way this proposal is going?
At full scale I have the feeling it might be too much for us at this time. But great to know that there are people deep into the governance questions and available in this community!
What would help me weigh the importance of your points atm would be a few bullets/screenshots on its practical application - I saw Arbitrum: Oxcart Delegation Engine is Live, are there any lessons learned there yet?
Are there others who could weigh in or have been part of creating this model?
Cheers!
Just managed to catch up with the discussion here. First of all, thanks @coolhorsegirl for the detailed proposal and @Leo-ObolAssoc for the response to the concerns laid out so far.
Overall, I support proactively implementing an incentive system to ensure the sustainable and continuous participation of the best delegates in the governance of the Obol Collective.
However, the details of its current form still need to be deliberated, and I’ll chime in with my thoughts on each of the 3 main discussion points below:
Is it too early to think about delegate incentivisation?
In my opinion, this is the right time to lay down a strong foundation for this goal, i.e., when we have organic, high-quality, and enthusiastic delegates who are actively participating in governance.
Most DAOs implement such measures when voter fatigue and apathy have already set in, resulting in the loss of quality + organic delegates to greener pastures and leaving space for more “mercenary” types of delegates to fill the space
I agree with @Ignas here
Overreliance on the “enthusiasm” of our delegates may also be a centralisation vector, where only the delegates who do not need to be compensated for their time remain
Unexpected/unbudgeted development costs
To be fair, the features in this proposal were mentioned in the previous proposal to enabling stObol under “Future Development”
That said, it might help for the Association to lay out a Governance Roadmap and estimate associated costs to implement each phase. We don’t have to decide on it now, but the delegates can start discussing the pros vs cons and whether the timing of each phase makes sense.
$65k does not seem too crazy for the entirely new custom feature that will be much more scalable than manual alternatives (e.g., scripts) if the Obol Collective owns the rights to the product. @Leo-ObolAssoc do you have a benchmark of how much similar solutions would cost in the market?
Otherwise, if this is something Tally can and plans to resell as a product, then I agree that the cost incurred by the collective should be much lower- e.g.,
(i) licensing or subscription fee, (ii) only subsidise a fraction of the build cost.
Happy to review an alternative proposal as well before making a decision.
Incentive structure
Paying both delegates and delegators from a separate pool from the staking rewards pool makes sense. Otherwise, stakers will be disincentivised to delegate and only stake.
One point I’d add here is to keep the scoring system fluid and adjustable by the Association for the first X months to prevent farming until we have reliable data showing that we have figured out the right formula.
This is because any known system will be subject to exploitation, and we have to be nimble enough to stay one step ahead of exploiters. Hence, I’d lean on giving the Association more flexibility during this early stage to figure out the right way to do things. To address centralisation concerns, we can decide on a time limit for the association to have full power to adjust the DRS.
Summing up my thoughts
- We should explore and implement delegate incentivisation today, while we have high participation rates from organic delegates
- It was expected that implementing a system for delegate incentivisation will come with additional costs
- However, the cost to develop the proposed system should not be fully borne by the Obol Collective if Tally is able to resell this system
- Let’s hear from Vista @enti on an alternative
- Paying both delegates and delegators from a separate pool from the staking rewards pool makes sense as we want to minimise the opportunity cost of delegation.
- The Association should be granted a time-limited flexibility to adjust the DRS during the initial phase
I’m not arguing this proposal anymore (at least not the notion of incentives, budget and others I still want to talk more) but I’ll just point out here that no DAO ever has failed to attract delegates and create a good governance on the basis of “late” incentivization. In fact I don’t recall any of the big DAOs of today doing it so soon. Lido, for example, just introduced it and it has top tier folks.
Doing these things too soon has a risk of not designing for the needs of Obol, which can become a bigger issue down the road. Think of technical debt for a codebase, but for a bureaucracy that rushed it and did not generate enough data to address real pain points and needs.
Thank you @coolhorsegirl for this thoughtful and well-documented proposal. We agree that systematic and structured compensation for delegates is critical to ensure continued high-quality governance, particularly as delegate apathy continues to grow across the DAO ecosystem. It is wise to address these structural issues before they become critical pain points.
That said, while we strongly support the intent and direction of this proposal, we have several points of feedback, especially around funding, metric design, and implementation clarity.
On the Need for Compensation and Apathy Mitigation
We’re aligned with the rationale for supporting active delegates. Compensation creates positive incentives, fosters accountability, and retains valuable contributors. With participation declining across many protocols, we believe the time to implement structured rewards is now, not once apathy has already eroded decision-making.
Concerns on Funding Model
While we’re excited to see Tally introduce native support for delegate compensation, the $65K implementation cost raises concerns. We’ve historically supported Tally’s work, particularly the novel governance staking infrastructure, because these systems had no precedents. In contrast, delegate incentive systems are now common across major DAOs, and can often be operated at significantly lower costs.
As other delegates have noted, we encourage Tally to reevaluate the proposed funding, especially in light of cost-effective alternatives implemented by protocols like Arbitrum or Uniswap.
Feedback on Delegate Reputation Score (DRS)
We appreciate the effort to quantify delegate contribution. However, we have several critical points on metric design:
- Merge “Number of Votes” and “Participation Rate”: After all the discussion, we’re still unclear on the added value of keeping these two metrics separate. Both track voting consistency. A single normalized metric like “votes cast / total proposals” would simplify the system and reduce redundancy.
- Replace “Voting Threshold Score” Mechanism: The current design penalizes delegates who vote after quorum is reached. This can create unhealthy dynamics, where large delegates “rush to vote” to capture rewards and squeeze out smaller ones. Rather than competition, we prefer non-adversarial mechanisms, such as time-decay models (e.g., those used in Arbitrum’s Security Council), which gently encourage early participation without introducing vote-racing.
- Reconsider Voting Power-Based Distribution: Rewarding delegates linearly based on voting power may entrench concentration and work against decentralization. Instead, we propose using the DRS score itself to allocate rewards. DRS already includes a weighted impact score, and its composite nature better reflects holistic activity than raw token weight.
- Add “Delegate Rationales” as a Scoring Component: Writing rationale posts is a foundational part of good governance. It’s surprising to see this missing in the formula. Rationales are a well-established standard across major DAOs and should be reflected in any scoring system that aspires to fairly evaluate delegate quality.
In Closing
We support the direction and goals of this proposal. However, after reviewing the structure in detail, we believe this implementation:
- Introduces unnecessary complexity in some scoring metrics
- Misses important ones like delegate rationales
- Comes at a higher cost than comparable incentive programs across the ecosystem
We’d be happy to support this proposal if adjusted to incorporate a more cost-effective funding model and a rebalanced scoring structure that better promotes diversity, transparency, and meaningful contribution.
Hey all, thank you for you feedback!
I will post an updated version of the above proposal tomorrow morning, but I wanted to explain a few changes you can expect to see:
- Reward distribution refined: 165,000 OBOL over 6 months, using a √voting power curve to reduce centralization.
- DRS lookback window shortened to 63 days (3 voting cycles) for more dynamic responsiveness.
- Obol Association will choose the most viable provider (Curia, Karma, etc.) post-approval, with logic remaining auditable and version-controlled.
- Full DRS formula included with five weighted components (participation, forum activity, etc.) and thresholds for “active,” “inactive,” and “ghost.”
- DRS and reward eligibility integrated into Tally’s staking and profile pages, with a leaderboard update to reflect DRS instead of raw voting power.
Additionally, I wanted to provide some more clarity on costs, as this has come up 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.
Hey all, the proposal has been updated in response to community feedback. Thank you and I look forward to continuing the conversation.
Please see the updated proposal above: [Draft] Delegate Compensation and Delegate Reputation Score Integration for stOBOL
And feel free to read my comment above for some extra context on the changes: [Draft] Delegate Compensation and Delegate Reputation Score Integration for stOBOL - #25 by coolhorsegirl
Thanks for updating the proposal. I feel comfortable with the current version and give my formal approval as an Obol delegate to move it to the actual voting.
Hey @coolhorsegirl, really appreciate the revisions in this draft; the direction looks solid. I’ve spent some time walking through each metric from an implementation angle and wanted to flag a few spots where a lighter calculation might keep the signals sharper and the implementation path easier. Feedback below, section by section:
Quick note on the Voting Participation Score calculation. Because the metric is already expressed as a percentage of proposals voted on within the 63-day window, it’s inherently on a 0–100 scale. Running an additional normalization step across delegates could unintentionally flatten meaningful differences, especially if overall participation rates cluster tightly (e.g., 80% – 95 %). In that case, normalizing would compress the spread and dilute the signal we’re trying to capture.
Suggestion: use the raw participation percentage directly as the score (then multiply by the 0.40 weight in the overall DRS). That keeps the component intuitive “I voted on 8/10 of eligible proposals, so my Participation Score is 80” and avoids an extra transformation layer.
Suggestion: instead of adding a separate “early-vote bonus,” treat timeliness as a straight percentage that starts at 100 if the vote is cast within the first 48 hours and then decays linearly to 0 by the proposal’s close. Compute this score for every proposal in the look-back window and then average those per-proposal values to get the delegate’s final Timeliness Score.
Example with a 5-day (120-hour) voting window
- First 48 hours → score stays at 100
- Remaining 72 hours → decay rate ≈ 1.39 points per hour (100 ÷ 72)
A vote cast, say, 60 hours after proposal voting start would earn roughly 72 points.
This keeps the math transparent, delegates know exactly how fast their score drops and avoids an extra “bonus” layer that might complicate the calculation. It also scales naturally to proposals voting periods.
Open to tweaks, but a simple linear decay like this should strike the right balance between encouraging early participation and not overly penalizing votes that are only slightly after 48 hours.
Adding a few implementation ideas for the Rationale Submission Score so it’s both workable now and extensible later:
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. Happy to prototype whichever timing model the community prefers!
Standardizing the rationale format
I suggest that the delegates could follow a short, required template when they post in the proposal thread, e.g.:
Vote: For / Against / Abstain
Rationale: <concise reasoning here>
A consistent header helps parsers separate rationales from general comments.
Verification:
We would also need a “wallet ↔ forum-account” verification thread so the system can match forum account and their rationale to their delegate wallet.
Future Iteration
Once the first version of the DRS are stable, we could test an AI classifier to score rationale depth and add a light quality multiplier.
Appreciating the clarity and responsiveness in the updated proposal. The shift to quadratic voting power, DRS modularity, open tooling, and rationales as a scored element all move the design into a more future-proof posture.
As we believe all feedback has been addressed and the community is well aligned around the goals. We, as Obol delegates with sufficient voting power, believe that this proposal is ready to move to a vote.
Thank you @Curia for the thoughtful and detailed feedback — I’ve now integrated each of your suggestions into the proposal above.
Specifically:
- The Voting Participation Score now uses raw participation percentages without normalization.
- The Voting Timeliness Score has been simplified to a linear decay model, starting at 100 for votes cast within the first 48 hours.
- The Rationale Submission Score now includes both the two-tier and linear-decay models for community input, and I’ve added a suggested standardized format for rationales.
Thanks for incorporating feedback around our key discussion areas @coolhorsegirl.
Also, great suggestions on the tweaks to the DRS formula @Curia. I agree that we should lean on simplicity and transparency for our first iteration and refine these with actual data according to the proposed mechanism.
I am comfortable with the implementation costs in principle, as these are custom development tailored to Obol’s needs and are not reusable by Tally for other DAOs.
I also understand that the @Leo-ObolAssoc and the Association have negotiated the best possible price with Tally and deemed the eventual price to be competitive.
Overall, I am comfortable with the updated proposal. As an Obol delegate with sufficient voting power, I believe that this proposal is ready to move to a vote.
Thanks for the quick update, @coolhorsegirl. I’m comfortable with the current draft and, as an Obol delegate holding sufficient voting power, I believe that this proposal is ready to move to a vote.
@coolhorsegirl and the Tally team have demonstrated their commitment by implementing a good chunk of the feedback, and I can recognize when a proposal is ready to be voted on, even if I don’t necessarily agree with it.
I am an Obol Delegate with sufficient voting power, and I believe this proposal is ready to move to a vote.
A well thought out proposal, reminiscent of the earlier Arbitrum program and good additions that they never implemented (but which are very important)
There are questions about the cost of implementing the rating
At the moment, the cost of running the program in Arbitrum is about $192,000 per year, i.e. 96,000 for 6 months (600k OBOL), and the OBOL program budget is significantly less.
I understand that these costs can be reduced, but I did not see that this is taken into account in the program (there is only development)
Second - an approximate calculation for one delegate:
Let’s assume that we have 20 active delegates with approximately the same vote power and rating. They should divide 27,500 OBOL among themselves (for 1 month), i.e. each will receive 1,375 (~$215)
I believe that this compensation for delegates will not provide much incentive to work and participate more than delegates do now.
Along with the operational costs that were not taken into account, perhaps the incentives for delegates can only decrease.
I think there are several options here:
- Increase the budget, but this will have a negative impact on stakers
- Reduce the number of delegates who participate in the program, but this will reduce the participation of those delegates for whom the amount of $215 is important.
Each option has its pros and cons
I think that’s good, though. Pilots are for testing and tuning the system, we can always spend more later (this is usd wise for delegates, but I agree delegate:stakers ratio isn’t great).
Also, I see a problem in the cost of working on a smart contract
- The cost of $35,000 is clearly an inflated amount.
What the contract should do:
– implement a function that collects data from the oracle by rating
– implement a function for calculating the distribution of funds between delegates according to their rating
For the most part, that’s all.
Is it really possible for a top programmer with a salary of $10,000 to do this contract for 3.5 months? I’m sure that this is very simple, the contract can be made several times cheaper, maximum 5-10 thousand dollars. - Audit - the same situation, maybe even worse, because having experience in audits, I understand that such a contract requires a maximum of 3-5 days, taking into account tests and writing a report. The cost of top auditors is $1,000 per day, so the cost of the audit should clearly not be $20,000. Maximum $5,000
- Also, we should remember OIP#1: Building and Enabling Staking for the OBOL Token, which claimed that stOBOL would have the ability to be managed through delegation (which did not happen). This means that part of the work that was supposed to be done in the first proposal is in fact transferred to this initiative. Therefore, this contract should cost even less
The bottom line is that this proposal needs to be adjusted to take into account the above!
TL;DR
- Support the principle of paying active delegates and adding a transparent Reputation Score.
- Reject the current $65 k implementation quote to Tally; they already monetize the same codebase across multiple DAOs.
- Amend the proposal: keep the pilot reward pool, run an open RFP for the build.
1 — Incentive design 
- 165 k OBOL over six months (≈$36 k) is a sensible test size.
- √-power distribution flattens whale dominance.
- DRS-gated rewards create a clear standard of “active” participation. (Obol Collective Community Forum)
2 — Implementation cost vs. value 
| Item | Quote | Notes |
|---|---|---|
| Smart-contract dev | $35 k | vanilla reward splitter + oracle hook |
| Audit | $20 k | high for such a simple circuit |
| UI work | $10 k | one screen inside Tally |
Total: $65 k—almost double the size of the actual pilot rewards going to delegates.
3 — Evidence of “multi-dipping”
Tally has charged other DAOs for virtually the same delegate-incentive or delegation tooling:
- Uniswap DAO – $250 k / yr for two years to “support and enhance” governance UI features (= $500 k total). (Uniswap Governance)
- Aave Grants DAO – $20 k one-off grant to integrate Aave’s governance contracts. (Aave)
- Lido DAO – $10 k research grant for delegation integration. (Lido Governance)
This establishes a pattern: Tally re-uses a single product line while billing each DAO as if the work were bespoke.
4 — Alternatives
- Public RFP – Put the spec on GitHub and solicit fixed-bid offers; Curia, Karma, or indie Solidity shops can likely deliver for <$25 k.
- SaaS-style contract – Pay Tally a low integration fee plus tiered per-delegate MAU if we actually scale.
- Open-source mandate – Fund one build, require MIT/GPL licensing so future DAO iterations cost $0.
5 — Amendment to put on-chain
Approve delegate-compensation pilot (165 k OBOL, 6 mo).
Replace Section “Cost” with:
- Create a two-week RFP for reward-split + DRS integration.
- Hard cap vendor payment at $25 k unless community vote raises it.
- All code MIT-licensed; Obol owns the repo.
6 — Bottom line
Pay delegates, not rent. Let’s pilot the incentive model but source the build competitively so future budgets reward governance work—not repeated vendor mark-ups.
From the above comment by @0xobol:
Reject the current $65 k implementation quote to Tally; they already monetize the same codebase across multiple DAOs.
I want to be very clear that this is untrue: The code developed for this project is completely new and is not under production or in production with any protocol.
OIP #4 Delegate Compensation and Delegate Reputation Score Integration (stOBOL) is published on Tally. The onchain voting starts on 2025-05-23T15:01:00Z→2025-05-28T15:01:00Z. You can vote onchain here.
So you are saying that staking for RARI and Arbitrum is a completely different code?
The source code of the contract is available on GitHub in the Tally repository:
GitHub - withtally/staker
I see that it is universal and suitable for any token