[DRAFT] Experimental Incentive System for Active ArbitrumDAO Delegates
Non-Constitutional AIP
Abstract
We introduce an Experimental Incentive System aimed at the ArbitrumDAO delegates with a duration of six months. The goal is to assess the impact of the incentives on the active participation of the delegates. This proposal is subject to changes.
Motivation
Inspired by the positive feedback to our initial approach to the Delegate Incentive System, we now introduce an experimental version for ArbitrumDAO’s Incentive System.
As per our post [RFC-2] Delegate Incentive System for ArbitrumDAO, we believe it’s essential for DAOs to provide consistent, attractive, and predictable incentives to their delegates. To bolster governance, it’s vital that delegates, who guide and set the governance direction through their votes, remain active.
With the introduction of the ARB governance token, a primary goal was to enable decentralized protocol proposals and updates. ArbitrumDAO aims for decentralized decision-making: the community suggests changes, public debate ensues, followed by voting, and eventually implementation. With the rollout of the ARB token, it became clear that a secure and decentralized Layer 2 requires the elimination of centralized control points, ensuring trustless operation.
Rationale
Venturing into decentralized governance is challenging. It is a difficult task to engage ARB token holders in intricate governance processes. Historically, voter apathy has been a constant issue in large DAOs. Several reasons fuel this phenomenon: a disconnect with the issues at hand, complex voting systems, lack of information, or the belief that an individual vote is inconsequential.
To counteract this, the DAO introduced a delegate system. Yet, in doing so, an unresolved issue came to light: ARB holders often lack the time and means to engage deeply in governance.
Delegates aren’t just enthusiasts. They are individuals, organizations, or companies deeply committed to the protocol. They resonate with its objectives and bring their own visions to shape its future. They are more than mere technical experts; they are versatile teams, focused on comprehensively understanding a protocol. They delve beyond the technical, encompassing social and economic dimensions. Such teams invest resources in deep research for informed and effective decision-making.
It is easy to see from the above that, just as individual incumbents alone do not have the resources to carry out these in-depth analyses, neither do multidisciplinary teams. Quality time, which encompasses activities such as data analysis, research, deliberation, voting and effective communication, requires a significant dedication of resources to ensure its effective execution. Without this dedication, these critical tasks tend to be rushed or inadequately completed, which can have far-reaching consequences.
Compensating for this time is essential. Remuneration not only recognizes expertise and effort but also facilitates undivided attention to these tasks. Without compensation, the quality of work and its outcomes can suffer.
Raphael Spannocchi (Flipside Crypto) elaborates on this in a Medium post, emphasizing that the delegate role has become a full-time job. Compensation attracts talent and is pivotal for the protocol’s security. Paying experts ensures that proposals do not jeopardize the protocol’s integrity.
We strongly believe that achieving a decentralized and functional governance vote is unlikely without encouraging people to take on delegated responsibilities. Luckily, we get a lot of support from the community. But, as @Frisson points out, the tricky thing about incentives is how to pay for them. Also, we agree with @benhoneill that we should focus on what specific actions the community hopes to incentivize with these expenditures. Where we differ from his opinion is that we think voting and posting are the most important tasks.
In this initial phase of ArbitrumDAO governance, adaptability is key. We must experiment with incentives tailored to the needs of the Arbitrum ecosystem, being flexible and anticipating short-term changes, learning and adjusting as we go.
Delegate Incentive System
Before reading the proposal please not how we decided to structure it
This proposal is structured into four main sections:
- Option 1: This is our main proposal detailing all the specifications of the incentive system.
- Option 2: Introduces the implementation of “Karma” to automate certain processes. It’s important to note that this option entails additional costs.
- General Summary: An overview of the proposed items.
- Next Steps: Actions to be taken after considering the presented options.
The SEEDLatam team will be attentive to feedback from ArbitrumDAO. Our goal is to craft a proposal that optimally adapts to the governance needs.
Option 1 - Main Proposal
Specifications
Duration of the Incentive System
We’ve allocated an initial trial period of 6 months. This timeframe should allow us to gather initial metrics to gauge the system’s functionality and its anticipated impact.
Note: At the conclusion of this period, ArbitrumDAO will decide whether to continue with the program or not
Total Number of Delegates to Receive Incentives
We have set the number at 30 delegates. This figure isn’t based on specific reasoning, but we believe it’s a reasonable starting point.
Note: Following the program’s conclusion, should ArbitrumDAO wish to proceed, they may adjust this number up or down.
Funding
Payments to delegates should be both predictable and stable. Consequently, while we will quantify the costs in USD, we will process the payments in ARB tokens.
We’ve designated a total funding of 720,000 USD, represented in ARB tokens, solely to incentivize the delegates. Moreover, an additional 360,000 USD, in ARB tokens, will be requested to cushion any market fluctuations.
For price reference, please visit: https://www.coingecko.com/en/coins/arbitrum
Any surplus will be channeled back to the treasury.
Note: We assess this sum to be apt for our initial phase. Nevertheless, we welcome any suggestions or adjustments.
Delegate Selection Process
Tiers
We’ve established three levels for delegate qualification:
- Tier 1: This category includes only delegates meeting the following criteria:
- Voting Power: 30M ARB - 1M ARB
- Delegates to Receive Incentives: 10
- Budget Allocation: 360.000 USD (6000 USD per delegate per month)
- All-time Participation Rate (Tally): +75% (Excluding test votes or mistaken proposals)
- ARB Token Lock Requirement: +3,500 ARB
- Tier 2: For delegates that fit these standards:
- Voting Power: 999,999 ARB - 300,000 ARB
- Delegates to Receive Incentives: 10
- Budget Allocation: 240,000 USD (4000 USD per delegate per month)
- All-time Participation Rate (Tally): +75% (Excluding test votes or mistaken proposals)
- ARB Token Lock Requirement: +2,500 ARB
- Tier 3: Exclusively for delegates meeting the subsequent criteria:
- Voting Power: 299,999 ARB - 100,000 ARB
- Delegates to Receive Incentives: 10
- Budget Allocation: 120,000 USD (2,000 USD per delegate per month)
- All-time Participation Rate (Tally): +75% (Excluding test votes or mistaken proposals)
- ARB Token Lock Requirement: +750 ARB
Notes:
- So following this model, the top ten delegates - defined by their final score - within each range would be compensated, creating a multi-tiered competition between delegates
- Certain votes won’t be counted towards the Tally Participation Rate, as detailed in the following links:
Considerations on Tiers
The idea of setting the levels is to encourage delegates to seek more delegate votes or to set a healthy %VP for both themselves and the governance. But we know that this can lead to excessive accumulation of voting power in the future. For this reason we set a maximum cap on voting power.
In the future we can establish that above a certain maximum voting power, incentives will start to be subtracted. To avoid the accumulation of voting power. We can also link the tiers to certain parameters of the chain, to incentivize the constant growth of Arbitrum. As mentioned by @benhoneill in his comment.
For the moment we believe that it is not necessary to make the incentive system complex, we should try to start with a system as simple as possible, so that ArbitrumDAO members can evaluate if this type of incentive has a positive impact for Arbitrum.
Incentive Program Application
Delegates matching the tiered requirements must confirm their participation in the Incentive System in the forum (a dedicated channel will be established for this). They must post using the template provided below, within a 7-day application window.
Incentive Program Confirmation Template:
- Forum Username (Link):
- Locked ARB Token Address and Amount (Link):
- Twitter Profile (Link):
- Snapshot Profile (Link):
- Tally Profile with Exact All-time Participation Rate % (Link):
- Tier and Exact Delegated Token Amount (Use this Dune):
Note:
- Failing to send a confirmation message will exclude you from the incentive system, regardless of eligibility.
- The ARB token lock must remain in the address for the 6 month duration of the program.
- The ARB token lock is symbolic, affirming the delegate’s commitment to the Arbitrum ecosystem.
- Applicants should ensure accuracy in numbers and links, facilitating quicker verification.
Eligible delegates for the incentive program will be announced on the forum.
Scoring and Framework
To determine which delegates will be paid on a monthly basis, we will use a point system and a framework that will be made public.
Details: Terminology, Symbols, and Formulas
We explain in detail the framework and points system.
Tier 1:
- Delegates (DD): Delegates with right to access to incentives
- Ranking (TOP): Delegate’s position in this Dune table https://dune.com/pandajackson42/arbitrum-delegates-and-voting-power
- Funds USD (FUSD): The amount of USD allocated per month to the delegates’ payment
- Activity Weight (%): Represents the weight assigned to each key activity to be measured in delegates.
- Participation Rate (PR) - Weight 18: Percentage of the total participation of the thin member in the votes. This parameter is extracted from Tally. This is the only parameter that is not reset monthly.
- PR% formula: (PR * 18) / 100
- Snapshot Voting (SV) - Weight 18: Percentage of delegate participation in snapshot voting. This parameter is reset at the beginning of each month.
- Tn: Number of total proposals that were sent to snapshots for voting in the month.
- Rn: Number of actual proposals voted by the delegate in the month.
- SV% formula: (SV(Tn) /SV(Fn)) * 18
- Tally Voting (TV) - Weight 18: Percentage of delegate participation in on-chain voting in Tally. This parameter is reset at the beginning of each month.
- Tn: Number of total proposals that were sent to Tally for voting in the month.
- Rn: Number of actual proposals voted by the delegate in Tally in the month.
- TV% formula: (TV(Fn) - TV(Rn)) * 18
- Snapshot Communication Thread (SCT) - Weight 18: Percentage of communication threads with the justification of the delegate’s vote on the proposals sent to snapshot. This parameter is reset at the beginning of each month.
- Tn: Number of total proposals that were sent to Snapshots for voting in the month.
- Rn: Number of actual communication threads where the delegate communicated and justified his/her decision.
- SCT% formula: (SCT(Fn)/SCT(Rn)) * 18
- Tally Communication Thread (TCT) - Weight 18: Percentage of communication threads with the justification of the delegate’s vote over the votes in Tally. This parameter is reset at the beginning of each month.
- Tn: Number of total proposals sent to Tally for voting in the month.
- Rn: Number of actual communication threads where the delegate communicated and justified his decision.
- TCT% formula: (TCT(Fn)/TCT(Rn)) * 18
- Proposal Submitted Snapshots (PSS) - Weight 4: Percentage of proposals that the delegate sent to snapshot. This parameter is reset at the beginning of each month.
- Tn: Number of total proposals that were sent to Snapshots for voting in the month.
- Rn: Number of actual proposals that the delegate sent to Snapshots for voting in the month.
- PSS% formula: (PSS(Fn)/PSS(Rn)) * 4
- Proposal Submitted Tally (PST) - Weight 6: Percentage of proposals that the delegate sent to Tally. This parameter is reset at the beginning of each month.
- Tn: Number of total proposals sent to Tally for voting in the month.
- Rn: Number of actual proposals sent by the delegate to Tally for voting in the month.
- PST% formula: (PST(Fn)/PST(Rn)) * 6
- Participation Rate (PR) - Weight 18: Percentage of the total participation of the thin member in the votes. This parameter is extracted from Tally. This is the only parameter that is not reset monthly.
- Total Participation (TP): Sum of the results of activities performed by the delegate. A TP% of 100 indicates full participation.
- TP% formula: PR% + SV% + TV% + TCS% + TCT% + PPS% + PPT% + PPT%.
- Payment USD (PUSD): Final amount of USD the delegate will receive based on their TP%.
- PUSD formula: (FUSD * TP%) / 100
Parameter summary
- Activity Weight (%):
- Participation Rate (PR) - Weight 18
- Snapshot Voting (SV) - Weight 18
- Tally Voting (TV) - Weight 18
- Snapshots Communication Thread(SCT) - Weight 18
- Tally Communication Thread (TCT) (TCT) - Weight 18
- Proposal Submitted Snapshots (PSS) - Weight 4
- Proposal Submitted Tally (PST) - Weight 6
- Total Participation (TP):
- TP = PR% + SV% + TV% + TCS% + TCT% + PSS% + PST%
Tier 2 and 3
Weights change in these tiers because delegates do not have the ability to pass votes to Tally like Tier 1 delegates do.
Parameter summary
- Framework Tier 2
- Framework Tier 3
- Activity Weight (%):
- Participation Rate (PR) - Weight 19
- Snapshot Voting (SV) - Weight 19
- Tally Voting (TV) - Weight 19
- Snapshots Communication Thread(SCT) - Weight 19
- Tally Communication Thread (TCT) (TCT) - Weight 19
- Proposal Submitted Snapshots (PSS) - Weight 5
- Total Participation (TP):
- TP% formula: PR% + SV% + TV% + TCS% + TCT% + PSS%
- TP% formula: PR% + SV% + TV% + TCS% + TCT% + PSS%
Weight and activity considerations
The activities that have been considered in shaping the framework and scope are measurable activities that we believe can have a positive impact on governance.
We have distributed the weight equally among the activities, as we believe this is the fairest way to do so for the time being. With the exception of the PSS and PST parameters, we have given them a lower weight because there will be a limited number of delegates who can pass proposals to Snapshots and Tally.
Surely both the activities and the weightings are far from being the final parameters, ideally after this 6 months we should have a clear idea on how to modify certain parameters or which ones to add/remove.
Total Participation (TP)
The 10 delegates who conclude the month with a TP score of +60% will be the ones to receive incentives based on the result provided by the PUSD parameter.
Should there be more than 10 delegates with a TP score of +60%, only the top 10 scores will be selected.
If there are fewer than 10 delegates with a TP score of +60%, only those meeting the criteria will be compensated, and the remaining funds will be returned to the treasury.
In the exceptional circumstance where scores are identical or there are more than 10 delegates exceeding +90%, the entire month’s budget may be distributed amongst all delegates with such scores. This decision is at the discretion of the program administrator.
Additional Scores
Should a delegate propose or actively participate in an enhancement proposal for Arbitrum DAO and execute it, like the Arbitrum’s Short-Term Incentive Program (Arbitrum Improvement Proposal), they will be granted an additional +10% to their TP score for making a valuable contribution to the DAO. This could also be a governance process enhancement proposal or a template for grant selection.
Such scenarios are highly subjective and will be left to the judgment of the incentive system administrator. For this reason, we have not included it as a parameter within the table since it can be challenging to assess what genuinely adds value to ArbitrumDAO. Thus, we have decided to handle them this way.
Parameter Snapshot
When we refer to a month, we consider from the first day of the month 00:00 UTC to the last day 23:59hs UTC of each month. Within these days and hours, delegates have the opportunity to perform all actions to meet the parameters. The month’s activities conclude on the last day of the month, so delegates must be punctual.
Reset parameters
The following parameters are not cumulative and are reset to 0 at the beginning of each month:
- SV%
- TV%
- SCT%
- TCT%
- PSS%
- PST%
Delegate Responsibilities
Delegates are responsible for keeping track of their actions. At the end of the month, they have until the 3rd of the following month to submit a forum post with the following requirements:
- A copy (Link) of the framework with their activity data for that month.
- Additionally, the post must have a summary with all the links including:
- Snapshot voting link
- Forum post link explaining the reasoning behind the snapshot vote
- Tally voting link
- Forum post link explaining the tally vote reasoning
- Snapshot or tally link if any of the votes were forwarded to those platforms.
- The summary should also include:
- Delegate proposal links
- Links to any significant contribution (discussion, questions, suggestions, etc.) made to a proposal.
Note: Delegates failing to post the requested information will not receive incentives.
To avoid forum spam and disarray, we will ask the facilitators to add a channel for the incentive system, so delegates can input all their information there.
Incentive System Administrator Responsibilities
After the delegates post and present their results in the framework, the incentive system administrator has 10 days to gather all the information, review, verify, and unify it. Then, present all the unified data on the forum in the framework and attach a summary explaining that month’s final result.
Once the final result is presented, delegates have 2 days to file a claim in case of disagreement.
Dispute
Delegates have a 2-day window to dispute if they disagree with the results presented by the Incentive System Administrator.
To raise a dispute, they must do so via a forum post with the following template:
- Title: Dispute
- Username
- Reason for dispute (be detailed)
The system administrator must promptly address the issue, resolving it within a maximum of 2 days.
Incentive System Ban
Should a delegate or any community member attempt to deceive or game the incentive system, they will be banned. This decision is at the discretion of the program administrator.
We must remember that this system is experimental, and we hope for community members’ cooperation for its success. This could propel the governance of ArbitrumDAO.
Payment Execution
If all goes according to plan, payments to delegates are expected to be made between the 16th and 17th.
Payments will be made in ARB tokens. For the conversion from USD to ARB, we will use the reference price of: https://www.coingecko.com/en/coins/arbitrum
Once the payments are finalized, the administrator must publish in the forum a detailed summary of all transactions and the corresponding amounts.
It is imperative to clarify that the delegate will only be paid the amount in USD converted to ARB tokens, according to the PUSD parameter.
Considerations
Like every new and experimental system, there may be delays, so please be patient.
Incentive System Lifecycle
Based on the detailed description provided earlier, let’s outline a standard cycle of the incentive system.
Note: We assume that the delegates have already been filtered during the pre-selection stage and are aware of their tier.
Delegate Perspective
- The month starts on the 1st with the following parameters:
- PR% = 100%
- SV% = 0
- TV% = 0
- SCT% = 0
- TCT% = 0
- PSS% = 0
- PST% = 0
The only accessible parameter is PR = 100, extracted from Tally. All other parameters will be generated throughout the month.
- As governance proceeds, we can detect that on day 15, the status is:
- Proposals voted on in a snapshot.
- Proposal passed snapshot.
- Said proposal is now on Tally
All data has been entered into the framework, but I haven’t yet announced the votes, nor have I forwarded any proposals to snapshot or tally.
- By the 30th, the conditions are:
- Snapshot proposals, voted on.
- Rationales for my votes have been provided.
- Proposals voted on in Tally, and 2 are still being voted on (these won’t be accounted for this month).
- Rationales for my Tally votes have been provided.
- Snapshot proposals, voted on.
- Reviewed the data and submitted a post to the forum by the 3rd of the next month with a link to the above chart and attached a summary similar to the following:
- Vote 1:
1. Link with snapshot vote
2. Link with the post of the justification of my snapshot vote
3. Link with relevant comments
4. Link to Tally vote
5. Link with the post with the justification of my vote in tally
- Vote 2:
1. Link snapshot vote
2. Link with the post of the justification of my snapshot vote
3. Link with relevant comments
4. Link to Tally vote
5. Link with the post of the justification of my vote in tally
- Vote 3 :
1. Link snapshot vote
2. Link with the post of the justification of my snapshot vote
3. Link with relevant comments
- Voting 4:
1. Link snapshots vote
2. Link with the post of the justification of my snapshot vote
3. Link with relevant comments
4. Snapshot of the framework with the uploaded data and link
- These are all actions to be followed by the delegate. The following month the parameters will be reset, except for the PR.
Administrator Perspective
- Start of the month: Track delegate participation in governance.
- Last day of the month: Begin collecting delegate posts from the forum.
- Review all the information, check for accuracy, and compile into the framework.
- Establish the results within the given timeframe.
- If everyone agrees and there are no disputes, execute payments to delegate addresses on the 17th of the following month.
- Publish the detail of the payments made
Multisig Management
We propose to use a configuration similar to that of Plurality Labs.
Gnosis Zodiac OZ governor module
- DAO can clawback funds from multisig direct to its treasury with a vote
- Protects from a corrupted set of multisig signers
- This multisig will be configured with a Gnosis Zodiac OZ governor module looking at the Arbitrum token contract. This means that the DAO can at any point reclaim the funds in this multisig with a vote on Tally. (Quorum is set at 100 million ARB for non-constitutional vote)
Signatories
We propose that the signatories be:
- ArbitrumDAO governance facilitators.
- A SEEDLatam address
Note: The signatories of the multisig could also be other delegates with minimal voting power.
Who should be the incentive system administrator?
It is essential that the system administrator maintains a neutral position. We propose that the governance facilitators act in this role, with the support of SEED Latam. If the facilitators decide not to assume this responsibility, which would be understandable, SEED Latam is willing to assume the administration of the incentive program.
It is important to note that the entity administering the program is SEED Latam, not the Cattin delegation. If necessary, Cattin will refrain from participating in the incentive system during this six-month period to avoid any potential conflict of interest.
charla-general channel