Hi everyone, We’d like to introduce an idea for cycle 3. This idea isn’t perfect, but it could be helpful to try. At least by sharing it here, someone might have an idea to improve upon it.
First, let’s recap the problem we’re trying to solve. As of cycle 2, we have 16 eligible delegates who will receive pay so long as they vote on most proposals and receive an additional bonus if they provide their rationale. While this has increased the number of active delegates and made it easier for the DAO to reach quorum, it doesn’t necessarily encourage delegates to perform.
Incentiving delegates to “perform” (provide value to the DAO) is difficult because “value” is subjective. That is why companies traditionally leave compensation up to HR, a compensation committee, or your boss.
If we want delegates to be incentivized to perform, we must introduce a subjective component into our compensation structure.
How this would work is we would have a pool of eligible delegates as we had with cycles 1 and 2, but rather than having fixed compensation, delegates would rank the performance of all eligible delegates each cycle, and the cumulative scores would determine how each delegate was ranked and, thereby, the compensation they would receive.
Of course, ranking delegates can be uncomfortable, so we propose a system that protects voters from their ballot submission. Here is how it would work.
- At the end of the cycle, eligible delegates would connect their wallet to a web app. This app would check to ensure the delegate/signer is eligible to complete a ballot.
- The signer will be asked to sign a message to prove who they are.
- Once the signer is authenticated as an eligible delegate, they will rank all eligible delegates from 1st to 16th. Once completed, they can click a submit button and be prompted to sign their ballot submission.
- An onchain transaction would be emitted with their selection, but it would come from a wallet managed by the application so that the ballot doesn’t link the delegate.
Because the ballots are submitted publicly, delegates can verify that their ballot was counted. Still, because the voter’s name and wallet aren’t associated with the ballot, the voter’s identity is protected. This leaves two trusted elements: the application’s responsibility is to ensure the same voter doesn’t vote twice, and the second is not to store any information connecting voters and their ballots.
To incentivize delegates to perform, the top delegates should be paid significantly more than even the 5th and 10th best-performing delegates. However, to provide some base compensation, all delegates below 10th will be compensated the same. As for why some ranks pay the same amount, as the rank decreases, we suspect delegates may feel the amount contributed between two delegates might be very similar.
Rank |
Pay |
Rank |
Pay |
1 |
$30,000 |
9 |
$15,000 |
2 |
$27,500 |
10 |
$12,500 |
3 |
$22,500 |
11 |
$7,500 |
4 |
$20,000 |
12 |
$7,500 |
5 |
$20,000 |
13 |
$7,500 |
6 |
$17,500 |
14 |
$7,500 |
7 |
$17,500 |
15 |
$7,500 |
8 |
$15,000 |
16 |
$7,500 |
As for implementation, the idea is purposely simple so that if delegates choose to experiment with this in cycle 3, there is enough time to build the MVP.
Here is a quick look at how a basic interface (delegate names entered randomly) for an MVP could look (thank you v0). Delegates would click and drag on each row until they were ready to submit.