Rewarding Active Delegates (RAD) Program

Abstract

We propose a program for rewarding active delegates focused solely on their voting record and making public their voting rationale. This is the first of a series of upcoming proposals under the umbrella of a DAO Incentive Program (DIP 2.1).

Motivation and Rationale

A delegate is defined as a party with voting power who votes on proposals. It narrowly focuses on voting and aiding sentiment analysis of why a proposal passed (or failed).

With this in mind, there are three overarching goals that this program is trying to achieve:

  • Increased active voting power. The total amount of active voting power is steadily increasing over time.
  • Reduce voter apathy. The share of active voting power compared to total delegated voting power is increasing over time.
  • Sentiment analysis. Sufficient publicly available information to aid understanding and gain insight on decisions made by the DAO.

This program can be considered successful if delegates are incentivized to continue participating and new delegates step up to participate in the DAO’s voting system. As well, if a proposal does fail, then the proposer should have the ability to gauge sentiment of various voters across the DAO based on the public feedback they leave on the forum.

Specification

This program is designed to be objective and on a per-proposal basis.

Eligibility requirements

Any delegate who has satisfied the following eligibility criteria can receive a payment provided that:

  • Actionable requirements:

    • They cast a vote on a proposal,
    • They publicly post rationale for how they voted and why (within 5 days of a proposal ending).
  • Prior requirements:

    • They have cast votes in at least 75% of all proposals in a given month,
    • They expressed interest to participate in the program and passed compliance requirements with the OpCo,
    • They have the minimum voting power (specified in budget),
    • Sufficient votes (FOR/ABSTAIN/AGAINST) cast that achieves quorum target*,
    • The proposal follows the process outlined in the Arbitrum Constitution.

Additionally, delegates must adhere to the program’s terms and conditions in order to remain eligible. Any proposals related to this program will not be eligible for rewards, to avoid any possible conflicts of interest.

*AGAINST does not typically count towards quorum, but for the purpose of this program, it will be included in the count towards quorum for the purpose of issuing rewards. The intention is to enable delegates to vote according to their preference such that ‘quorum’ is always hit even if not officially.

Incentive Budget per Quarter

Proposal type Incentive Budget Payout Cap Minimum voting power
On-chain constitutional quorum 15,000 USD 700 USD 200k ARB
On-chain non-constitutional quorum 7,000 USD 500 USD 200k ARB
Off-chain decision making (non-constitutional) 7,000 USD 500 USD 200k ARB
Off-chain election 7,000 USD 500 USD 200k ARB
Off-chain temperature check (non-binding) 5,000 USD 300 USD 200k ARB

Table 1: Incentive Budget from November 1st 2025 to January 31st 2026

Every quarter (3 months), the OpCo will decide an incentive budget that is paid on a per-proposal basis, with the following information:

  • Proposal type: Type of decision voted on by the DAO,
  • Incentive budget: Budget allocated to a single proposal,
  • Payout caps (per proposal): Maximum incentive grant a delegate can receive from this proposal,
  • Minimum voting power: A delegate must have at least this amount voting power at the start of a proposal’s voting period and must also maintain an average voting power at or above this threshold throughout the relevant month, to be eligible for rewards.

The budget is expected to be shared at the start of every quarter and to remain in effect for that quarter. This will provide delegates with predictability on the reward structure while allowing the payout strategies to change over time. For clarity, the proposal’s end date for voting (whether on-chain or off-chain) will be the date used to decide which payout strategy is used. All payouts will be issued in ARB tokens with a 7-day TWAP.

Table 1 provides the initial incentive budget that will be adopted if the proposal is passed. An illustration of how the payouts may look for the DIP 1.7 September Cohort and if all voting power was eligible for the program, can be found here.

Rewards are calculated relative to:

  • A delegate’s share of total eligible voting power,
  • The portion of the incentive budget remaining at the time of allocation,
  • A payment cap that limits the maximum a single delegate can receive.

This is designed to ensure the entire incentive budget for a proposal is fully allocated and the rewards are distributed fairly among the delegates.

The key finding is that the payout cap in the September Cohort effectively redistributes rewards across the delegate set and prevents concentration among those with the highest voting power. This mechanism ensures all participating delegates receive some reward. However, as the total eligible voting power increases to ~300m, the influence of the payout cap becomes less pronounced.

If we assume, in a given month, there are two temperature check proposals followed by a non-constitutional proposal and constitutional proposal, then the DAO as a collective will spend ~$32k.

Based on the DIP 1.7’s September Cohort data, we estimate the following payments for certain sized delegates:

  • Above 8 million votes will earn ~$1.8k,
  • Above 4 million votes will earn ~$1.6k,
  • Above 1 million votes will earn ~$900.

The estimates are subject to change based on participation by voting power. As more voting power participates, the rewards will be diluted, and it will be up to the OpCo every quarter to evaluate this data to set a new budget.

The following metric will be used to track the cost-effectiveness of the program:

  • Dollar spent per vote cast. A cost-efficiency metric that measures the total program expenditure divided by the number of votes incentivized. It represents how much funding is required to generate a single vote through the program.

Dollar spent per vote, alongside rewards on a per-proposal basis, enables the DAO to explicitly define a collective cost for the passage of a proposal. The program will need to find a balance that sufficiently rewards delegates to keep them engaged, and onboard newcomers, while keeping a keen eye on the collective cost to the DAO for the passage of a proposal.

Tracking of Rewards

The OpCo is responsible for keeping track of all rewards for delegate voting. It should be available on a public spreadsheet. For clarity, all records should be kept on a per calendar month basis, and payouts should be issued shortly after month’s end. If a proposal’s voting phase starts in one month and ends in the next, it will count towards the month in which it ends. When payouts are computed, the program manager (who could either be OpCo or another party) should accurately keep track of total accrued rewards and total payouts, to ensure only the difference carries over to the next month.

Delegates must earn at least $100 before a payment is issued. The allocation will carry over to the next calendar month, but it will expire after 3 months if the threshold is not reached. This is simply to avoid sending dust transactions alongside the overhead in doing so.

Safe-guard Budget

The OpCo reserves the right to offer bespoke incentive grant budgets for specific proposals. For example, if a proposal requires multiple temperature check proposals at the same time (like in the STIP), then all proposals may fall within a single bespoke incentive budget.

The OpCo may decide not to offer any reward. This should be taken in cases to prevent potential abuse such as an avalanche of unnecessary proposals or proposals that are deemed very minor in nature (including canceled proposals). If so, the rationale should be published prior or during the respective proposal’s voting phase.

Facilitated by the OpCo

The Arbitrum OpCo Foundation (“OpCo”) retains the authority to change any aspect of the program and any major change should be published to the DAO.

Additionally, the OpCo are in charge of hiring (and terminating) a program manager (if they choose to do so) with an appropriate service level agreement. It is expected that the program manager will handle the day-to-day operations, but rely on instructions from the OpCo.

This program will initially be run by the Arbitrum Foundation, but will be handed over with the OpCo as it ramps up its own resources to run DAO-programs. For clarity, anything that states “OpCo” in this proposal will be handled by the Arbitrum Foundation from the onset.

Participation Depends on Delegates being Non-Sybil and Human

The program’s goal is to activate unique and human delegates who will express their opinion through voting and sharing rationales. The program will exclude platforms that enable non-human activity (i.e., AI agents) or enable token holders who sell their votes for short-term profits. Additionally, no Arbitrum Aligned Entity nor the program manager will be allowed to earn any incentive payouts.

Budget

The Delegate Incentive Program multisig is holding approximately 7 million ARB. This program, alongside upcoming proposals under the umbrella of a DAO incentive program, will absorb the entire budget.

The OpCo will use this budget for:

  • Payouts related to the program,
  • Program manager compensation,
  • Other miscellaneous costs that arise.

The program manager’s compensation and scope of work will be announced if and when it is negotiated by the OpCo. This will be periodically reviewed by the OpCo and any changes will be published to the DAO.

We do not expect miscellaneous costs to be substantial. An initial budget of $50k per year will be allocated. If the costs exceed this budget, then the OpCo’s OAT must approve and notify the DAO.

Finally, a transparency report will be prepared and published every 6 months, to track total spend of any program that falls under the umbrella of a DAO Incentive Program.

Timeline

The intention is to have an off-chain proposal in the coming weeks and for the RAD program to run for 1 year. If the OpCo, based on feedback, deems the program is running well, it may authorise the program to continue operating beyond 1 year. If not, any excess funds will be returned to the DAO Treasury.

We will organize a governance call after Devconnect. This will provide sufficient time for comments on the forum alongside discussions at the event.

A non-constitutional quorum is required alongside more FOR than AGAINST votes for the proposal to pass.

If passed, the program will retrospectively take into account any proposals conducted after the 1st November 2025, and issue rewards in a timely manner.

5 Likes

on the forum?
on the snapshot and onchain vote reason fields?
on both?
on any of the above?

errr… the money in the DIP multisig needs to be returned to the DAO treasury ASAP, ideally in the next couple of weeks or so (after the October DIP1.7 results come out, which @SEEDGov is late on delivering as usual, and those rewards are paid to delegates), which means that the suggested governance process of this proposal is not correct. this proposal needs to go to an onchain vote to transfer the money from the DAO treasury to a multisig, ideally under the control of the OpCo only.

1 Like

Hi all!

I want to provide some context on what happened after the DIP 2.0 proposal failed.

We collected all the feedback from the temperature check vote and used that data to decide next steps. To summarise some of the key points:

  • Separate proposals for delegation and contributor incentives,
  • Remove Peer Assembly (viewed as too clunky / gate keeping),
  • Denominate in USD, but still pay in ARB,
  • Provide concrete numbers for kick-starting the first program to support delegates to decide,
  • Proposals should be streamed line and easy to digest,
  • Goals should be clearer.

Specifically for delegate incentives. The feedback focused on making participation as simple as possible with fewest barriers to entry.

After going through the feedback, we have decided to work on a series of proposals that builds up the incentive program for delegates and contributors. This first proposal, focused only on delegate voting, was put together with the intention of getting it online as soon as reasonably possible to ensure everyone has an opportunity to read it, discuss it, and provide their thoughts.

If it is approved, it is set to currently be retrospective back to the 1st November, although interestingly I’ve had discussions with several delegates now who believe that it might be better to have a detox period before restarting the incentive grant. I’d be interested to hear more thoughts on this on the forum or elsewhere.

Anyway, I hope this provides some transparency on how we approached this proposal, alongside the timeline for getting it online and next steps that we think are reasonable for getting a well-thought out incentive program up and running.

9 Likes

Thanks for the transparency on the iteration process. I’m supportive of this direction.

As someone who voted consistently and participated in the earlier DIP program, I found DIP 2.0 genuinely confusing and stepped back from active participation because the rules were hard to follow. The previous version also created an unintended problem where it incentivized discussions for the sake of discussion rather than meaningful engagement.

This approach, focusing on voting participation with clear barriers to entry, makes it easier to understand what’s expected and how to qualify.

On the retrospective question: I could go either way, but given we’re only looking at November, I think it’s reasonable to move forward with recognition for that period. I wouldn’t support going back further than that as it would add complexity.

Hope this helps. Thanks again for surfacing and to all of the people that have worked on putting this new structure together.

5 Likes

We will be hosting a governance call on this proposal on Friday, November 28.

The Rewarding Active Delegates (RAD) Program: Open Discussion #1
Friday, November 28 · 14:00 – 15:00
Time zone: UTC
Video call link: https://meet.google.com/wna-nyco-zxf

Hello! I have a few questions. Sorry for posting them this late into the open call for governance.

Have a first question related to the amount posted here, 32K each month. This would put the annualized expenditure at $384k/year

As of today, we have in address for incentives around 7M arb equivalent to 1.5M usd, and arb at 0.21$.
While we could theorize that this monthly expenditure could be above or beyond, because is based on amount of votes and amount of delegates, we can say that this budget should last based on projection for 3 to 4 years.
In the even of ARB below 5 cents, this budget would instead only last for 1 year.

Was any thought put into this piece of feedback?

In my opinion, not only for this, but for any DAO program that requires to pay out in ARB, we should keep the reserve in stablecoin and buy back the ARB in the open market when is time to redistribute. It will introduce predictability in budgeting for long term program, and effectively negate any sell pressure for financing programs.
The main issue is operational; but with a more centralized approach like the one we are seeing is likely doable, if we do use twap prices for conversion at time of buyback that are “good enough” even in time of volatility.

We do have around 16200 in rewards distributed this way if we just assume that each delegates in the 18 list has 1M in voting power. Considering the names, that at 4M we have 1.6k in rewards and at 8M we have 1.8K in rewards, we can safely assume an average of 1.2k each delegates to round this at 21800 usd per september.

This is especially true due to this table

In here, I do see

  • a quarterly budget in USD
  • a payout cap in USD

But we have ARB token as reserve.There is a mismatch in this accounting and operational system that will lead to the problems we have seen in several programs such as the grant ones based and denominated in ARB.


On the table above I also have another question: what was the rationale to come down to these payouts for each proposal? Was it done through a study of history of previous set of proposals, was it done taking in account other grant programs in other DAOs, was it done taking in account budget and runaway?
It would be good to know the rationale behind, knowing that 1) is stated that all budget are studied and changed if any quarterly 2) we are seeing a tendency of having less votes 3) but also historically we have seen voting clusters in certain period.


Finally, want to cross post in relation to the proposal that me and @jameskbh posted in the forum related to the extention of previous DIP.
While I want to be clear that the proposal was crafted in a weekend, after asking if this or any other DIP proposal would have been voted before the Christmas pause and without knowing it would have been put up for public discussion, I don’t personally feel like is necessary to go for a contemporary vote of both. The goal of the extention was, as mentioned in the original post, to give time to AF and other to craft this very proposal.
It seems like it has internalized most of the feedbacks of delegates; would also add how it lacks a bit some details, like rationality for certain decision, simulation based on the past year of activity, and projection on the future in different scenarios, but this part is also partially compensated by the flexibility of having OpCo ability to change parameters on a per quarter basis and eventually hire a service provider for management.

My invite, for the foundation, is to put out any other detail regarding simulations, history, decisions that were changed, or any other piece of info related to this final version that can put all the delegates on the same page for a favourable vote if they deem the program good enough.

As I see it now, extention would go on vote in the following scenarios:

  • in case the RAD proposal is discussed, goes on vote on snapshot the 4th of december, and the 11th we see that the vote fails
  • in case the RAD proposals is not put up for a vote before the 11th of december (last legal date for votes accordingly to the pause we collectively decided upon that starts the 18th of the same month).

That said, there is no interest in having concurrent proposals here. Goal is not for advocating for different frameworks and scenario, but to have something good enough in place, where good enough means

  • consensus from most delegates
  • predictability of payout that allows to growth the stash of active delegates
  • avoid falling in an apathy of voters that, on a timeframe long enough, could create security issues.
4 Likes

Echoing @JoJo’s comment, if this proposal is mature enough to go to a vote soon and, as mentioned in the proposal text, is meant to secure continuity regarding rewarding voting activities, there is no need to have a vote on the other proposal.

Regarding the RAD proposal itself, it is missing a bit of granularity to prevent issues while the program is running, for example.

When mentioning the minimum voting power for eligibility (table below):

  • Are those 200k at the snapshot for that specific proposal?
  • Or by the end of the calendar month? (as the records should be kept by calendar month)
  • Or for at least XX days on that calendar month?
  • Or at the beginning of the quarter, when the threshold is defined?

Each of those questions requires a different level of tracking effort, which will affect the amount of work needed to comply with the rule.

Can you clarify this point?

3 Likes

Since the payment is per vote, and not for a specific voting participation % threshold like before, it only makes sense for it to be 200k ARB at the snapshot of each proposal voting period start time.
Which yeah, that opens the door to a bunch of possible shenanigans.

Also, in the same line of questioning, my question above and in the last call, still doesn’t have a definite answer.

the requirement for there to be a vote rationale posted for each vote, so delegates get paid, will incentivize delegates to post slop AI vote rationales and polluting the forum, just to get the reward.

so this criteria needs to be way more defined, because in one extreme if a delegate can get paid for voting with any vote rationale, without any subjective criteria to evaluate that vote rationale, then way more delegates than today will post way more AI slop comments on the forum, just to check that box.

I recommend that this program should drop this criteria entirely. So delegates would be paid for voting only, and it doesn’t matter if they vote with a rationale of “just because” or a fully fledged articulated rationale essay with over 400 words.

Otherwise, this program will need a team to subjectively assess the quality of the vote rationales and score them with rubrics and… we are back to DIP 1.5 when the results were taking 3 weeks to show up and the DAO was spending way too much money on the admin of this, supposedly simpler, program.

4 Likes

The proposal appears to have incorporated the delegates’ feedback after DIP 2.0 failed to pass governance. However, there are still some open questions regarding the decisions made within the RAD.

Payments Per Proposal

What is the rationale for making payments on a per-vote basis in governance?

We understand that OpCo will handle the operational side, but this structure may incentivize a higher number of votes (whether Temperature Checks or on-chain) purely to increase delegate compensation within the DAO — effectively creating a sybil vector for delegate remuneration.

While this could potentially strengthen the DAO’s economic security — with more people voting and helping to reach quorum — it may also end up consuming the entire budget allocated to the RAD, potentially exceeding the US$32K/month illustrated in the proposal.

In addition, clearer rules for compensation should be established, such as requiring a minimum level of participation in votes, as is already the case with DIPs. This would ensure that only delegates who consistently maintain a defined participation threshold remain eligible for compensation.

Has any simulation been conducted to demonstrate that this approach is more efficient than a fixed monthly payment tied to a minimum participation requirement from delegates?

Minimum Voting Power to Be Eligible

The minimum Voting Power (VP) required to be eligible for rewards is set at 200K $ARB. As discussed during the Arbitrum event at Devconnect, the goal was to strike a balance between the 500K $ARB threshold of the previous proposal and the previous 50K $ARB threshold.

However, this is still a high threshold for most delegates. When DIP 2.0 was proposed, there were already criticisms regarding the exclusion of many delegates from the incentive program.

We understand the logic of incentivizing wallets with higher VP to participate in governance, helping to reach quorum and keep the DAO operational. Nevertheless, this decision reduces incentives for broader participation in Arbitrum governance, effectively preserving the same 8 to 10 delegates who are paid to vote and engage in forum discussions.

As suggested by cp0x, a smaller incentive program for delegates with VP below 200K could be designed by OpCo or by the broader community. This way, the programs would be separated, but incentives for both large and small VP holders would remain aligned.

Another suggestion is to hold another “redelegation week”, as already done on Arbitrum. This would allow smaller delegates interested in participating to obtain more VP, receive incentives, and participate in governance.

The recording of The Rewarding Active Delegates (RAD) Program: Open Discussion #1 can be accessed here:

1 Like

Hi @paulofonseca, delegates will need to publicly post their rationales on the forum (either in the proposal’s thread or in their own delegate thread). Because rewards are distributed on a per-proposal basis, delegates should submit their rationales within five days of the end of each voting phase (we have updated the proposal accordingly). For example, if a proposal includes both a temperature check and a subsequent on-chain vote, delegates should provide their rationale for each phase.

Thanks for your questions, @JoJo.

As stated, this proposal aims to optimize for the dollar spent per vote cast. Accordingly, the remaining funds from DIP 1.7 have no impact on the budget outlined here. It will be up to the PM and OpCo to adjust the quarterly budget and payout strategies moving forward, taking broader macro conditions into account as well.

To minimize the sale of ARB at this time, we prefer to follow the model used in the previous DIP, which maintained reserves in ARB and calculated payments using the 7-day TWAP.

When determining the incentive budget and payout cap for each proposal type, our goal was to tie rewards closely to actual DAO activity as well as the workload required to qualify for rewards—which is significantly lower than under DIP 1.7.

We also benchmarked against recent DIP 1.7 payout data. As shown in the simulations using September and October’s DIP 1.7 results, median earners from the September cohort would receive a similar amount (less compared to September data but more compared to October data) under the RAD Program.

Looking ahead, the PM and OpCo will review the data from the RAD Program and determine how and whether to adjust the budget on a quarterly basis. This data will also help inform the financial cost of pushing a proposal through the DAO, allowing the program to further optimize the dollar-spent-per-vote-cast metric.

Hi @jameskbh, thank you for your questions.

Delegates must meet the minimum voting power threshold at the beginning of each proposal’s voting period and (as you suggested) must also maintain an average voting power at or above this threshold throughout the relevant month. We have modified the proposal accordingly. The PM and OpCo will evaluate data from the RAD Program and may modify this clause in the future if needed.

The OpCo has the authority to update the program. If participants begin abusing it with AI-generated content, the OpCo can establish rules to address such behavior.

Thanks for your feedback, @blockful.

Because the RAD Program’s design is more objective than previous DIP programs, issuing payments on a per-proposal basis ensures that rewards closely reflect the amount of work conducted by delegates.

As stated in the proposal, the OpCo may choose not to issue rewards in certain cases to prevent potential abuse—such as an influx of unnecessary proposals or proposals considered to be minor in scope.

As suggested by @paulofonseca during the governance call (Rewarding Active Delegates (RAD) Program - #10 by Arbitrum), we have added a requirement that, in order to receive rewards, delegates must have cast votes in at least 75% of all proposals within a given month.

You can review the hypothetical RAD payout figures based on DIP 1.7 data from September and October. Looking ahead, if the RAD Program passes, the PM and OpCo will analyze data from its initial months to determine how and whether to adjust the budget and payout strategies.

4 Likes

there are a lot of delegates that already failed this requirement for the November proposals then, because they haven’t post the rationales within the 5 days after the voting period ending. This is too tight of a deadline and is not fair to apply it retroactively. Most delegates only post the rationales at the end of the month, or several days after the end of the month.

1 Like

:green_circle: Overall, this program is one of the most well-thought-out and objective:

  1. Only objective data is used – no subjective delegate assessments – which is essential for a program like this.
  2. They took into account numerous requests – they simplified the program and clearly spelled out all the conditions.

:red_circle: However, there are also some cons:

  1. The payment calculations are based on the worst program in my opinion, DIP 1.7, which has been constantly criticized for its unfairness. It would have been more appropriate to use at least version 1.5. Also, consider that the PM’s costs will be lower, and these funds can be allocated to delegates as well.

  2. Naturally, I calculated that at the moment, with 205,000 delegations, I will receive an average of $100 per month for voting. Therefore, perhaps now or in the future, we could distribute payments on a quadratic basis – at least present calculations based on these calculations to everyone so that everyone can compare and decide which option is better.

  3. I agree with Paulo regarding the new conditions. In general, any initiative that imposes conditions retroactively is a bad decision.
    Anything that deviates from the standard conditions and requirements previously applied should be adopted only after the voting on those conditions has concluded. for voting—this program is clearly designed only for large delegates. Therefore, perhaps now or in the future, we could distribute payments on a quadratic basis—at least present calculations based on these calculations to everyone so that everyone can compare and decide which option is better.
    We must either begin payments from the moment the proposal is accepted, or take into account the results of previous votes without additional conditions.

this is not entirely correct. this proposal still assigns subjective value to the vote rationale that delegates would have to post, in order to be eligible. and as long as that’s a criterion to get rewards for voting, this program is still not using “only objective data”.

Like I said previously here:

I disagree Paulo. While some delegates may post AI slop, I’m sure most will not do that, because it would damage their reputation (everyone will notice the slop).

Your suggestion (removing rationales from DIP eligibility) means that a lot of delegates would not reveal their reasons why they voted this or the other way. That is a far worse outcome than having a few slop posts here and there.

No solution is perfect, but it’s much better to require delegates to post rationales than not.

4 Likes

Meaning, exactly the situation we have today.
Delegates have not been incentivized to post their rationales since February when the DIP 1.5 became DIP 1.6, but still, most respected delegates continued to do so without any incentive.

Delegates that post their vote reasons, do it because they want to have a public track record of their votes and rationale, in order to attract more delegation for themselves. That’s sufficient motivation to post a vote rationale, after voting.

What we need to incentivize, which has never been properly incentivized in any version of the DIP, is BIG delegates giving feedback on proposals before they go up for a vote. This is so that proposal authors can include their feedback on the proposal and have a better chance of getting a proposal passed.

The only thing that incentivized this behavior was the timing criteria on the subjective assessment of forum comments on DIP 1.5/6/7. But first, this was a very small lever, and second, this incentive has never taken into account the size of the delegate providing feedback.

What we need is for BIG delegates to provide feedback on proposals as early as possible, and for them to be rewarded for that proportionally to their voting power. That’s the right incentive design that would fix that problem, but that’s obviously out of scope for a Delegate Incentive Program like this RAD one, that is supposed to only reward delegates objectively.

That’s why I’m saying that including the posting of a vote reason as a requirement for delegates to be rewarded for voting will lead to either:
a) Delegates posting AI slop just to collect the rewards.
b) Or the program becoming subjective again, where the OpCo or future PM will need to review all vote reasons from all delegates, and exclude from rewards the ones they find not worthy. Making this RAD program a subjective program like the previous DIP, which is against the self-defined goals for this program.

I agree with this.

A delegate is not necessarily commenting on the proposal, but posting the rationale behind their own vote, which is a very personal statement. That rationale is very useful, especially if a proposal fails (like DIP 2.0), as it enables sentiment analysis / vibe checking.

Today, rationale posted by delegates, is pretty good and reasonable by them. If people have a change of heart and post AI slop, it will be obvious to everyone including OpCo/program manager. Subjectivity is not “is this the best rationale in the world” but “does it actually represent the delegates view?”.

4 Likes

Thank you for raising this point.

The requirement for delegates to comment their rationales within 5 days will not apply retroactively. Assuming that the RAD proposal goes to Snapshot today, for proposals that took place between Nov 1 and Dec 11, delegates will have until Dec 16 (5 days after the RAD proposal hypothetically passes), to comment their rationales.

2 Likes

I believe/hope that most people use AI before voting to sort through large texts, rather than afterward to simply justify their vote.
It’s difficult to verify, but it’s logical to do so.
Therefore, explanations may use AI data, but it’s not just junk.

I still believe this is a necessary measure to always understand why someone voted the way they did. Personally, I need this information; it’s how I assess the validity of delegates’ votes and draw my own conclusions.

Also, it’s not subjective: you’re free to write whatever you want there.

1 Like

how would you be able to tell that a rationale that is AI generated doesn’t represent a delegates view?

This criteria will lead to some legit delegate being excluded from getting rewards because their rationale is deemed not “good” enough by the PM.

So either there are very clear guidelines as to when to exclude delegates from getting rewards, like a binary check of “the delegate has posted any kind of rationale within the specified timeframe” or not, otherwise, we will get again into a subjective assessment of contributions.

I should also add that there have been many cases, in the past, of delegates posting comments on the forum at the time of voting saying “voted For and the vote rationale will be published later” and then editing that comment several weeks later to actually explain why they voted in that way. And since this proposal establishes a maximum period with which the delegate needs to post a rationale on the forum, the OpCo/PM should make sure to take into account this kind of behavior as well.

I hope that will be the case. And that nobody will be punished by writing certain types of rationales.